Question about use of sh:path as render key in TopBraid EDG instead of PropertyShape identity

[Ad Reuijl]

Hi Holger,

I’m working with TopBraid EDG to manage both our ontology and instance data.
When creating or editing instances, I’ve noticed that the frontend rendering of form fields is driven by sh:path.

In my setup, I deliberately reuse the same property path in multiple PropertyShapes (for example, a single generic relation …:hasDocument), while distinguishing the semantics in the PropertyShape itself — through its sh:name, sh:group, sh:order, and, most importantly, the value constraints or target class.

Concretely, I want to use one general property like :hasDocument and let the associated node’s type determine whether it is a valid document type for a given asset type. For example:

What I observe is that, because the renderer uses sh:path as the unique key, these two PropertyShapes (which intentionally share the same path) are treated as one in the UI, rather than as separate fields — even though their semantics and value constraints differ.
This effectively forces me to define separate properties per document type, which is conceptually undesirable.

My questions:

1. What is the (historical or technical) reason for using sh:path as the determining key for rendering, instead of the PropertyShape identity itself?

2. Is there any configuration or supported pattern that allows the UI to render per PropertyShape, i.e., respecting sh:name, sh:group, sh:order, and sh:class/sh:node, even when sh:path is identical?

3. If not, would you consider supporting this as an optional rendering mode? For example:

   • “Render by PropertyShape (default key = PropertyShape IRI)”, or

   • an explicit annotation like dash:renderSeparately true.

4. Is there a recommended workaround within EDG (e.g., qualifiedValueShapes, or a etc) to achieve this behavior cleanly, without polluting the ontology with artificial, property-specific duplicates?

I’d really appreciate your insights or pointers to the reasoning behind this design choice.
here is an example of what is see in EDG



Only one documents show up while there are many more applicable to the class/shape Draaideur

Best regards,
Ad Reuijl
Linked Data Specialist / Semantic Modeller

Schiphol Group | Semtyx

[David Price]

I think the issue here is likely that in semantics-land folks say "properties are first class objects” and so the example approach violates that.

This land is largely based in set theory and logic, not programming languages.

e.g. in OWL if you assert P rdfs:range Report and P rdfs:range Manual you actually are saying that P values are in the intersection of Manual and Report.

Anyway… can handle the example in EDG/SHACL — follow the purple arrow :-)

It is possible to “further constrain” the sh:class of an inherited property in a new property shape. So:

 

• SomeClass sh:property a property shape with sh:path hasDocument and sh:class Document
• Document has sublcasses MaintenanceManual and InspectionReport
• SomeClass2 and. SomeClass3 subclass of SomeClass select the appropriate Document subclasss to further constrain hasDocument in the new property shapes in the subclasses.  

Below shows starting to further constrain “broader” in a subclass of “Concept”:

Cheers,

David

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/676f2b33-f5e7-4811-979c-4825c44089c6n%40googlegroups.com.

David Price, Semantic Solution Architect

UK +44 (0) 7788 561308

TopQuadrant.com

[Ad Reuijl]

Hi David, 

Thank you for your swift response!

I was aware of those possiblities in EDG of further constraining the inherited properties, however this is not exactly the problem i was encountering. 
The problem mainly occurs within the properties already bound to the shape (so not the inherited but the declared properties of the shape). 

When registering individuals/instances in the edg-datagraph (using my shacl based ontology), the EDG UI only renders the first propertyshape it encouters with the 'hasDocument' path as a renderred field (a field where i can enter data/ register the object of the triple).  

The other hasDocument propertyshapes are not rendered in the frontend because they have the same sh:path. Therefore it seems that the frontend rendering (using dash and shacl as ontologies for defining this rendering) only looks at the sh:path for defining whether there has to be an extra field rendered, and not the actual property shape. In other words, if i define 10 propertyshapes with the same sh:path it only renders the first shape it encounter, so i only get 1 field to add some data (even if those propertyshapes lead to different sh:class'es). 

I tried using specified sh:path's like 'dds:draaideurHasDocumentE21blablabla' and then it reders all the fields i am looking for, but this results into instances with a lot of different predicates, and that is something i dont want..

I hope i explained it a bit further, it is a bit hard, since english is not my native language, so please excuse my lack of expressive-power.

regards, 

and thanks for the effort!

Ad

Op woensdag 5 november 2025 om 13:33:07 UTC+1 schreef David Price:

[David Price]

Hi,

So I tried what I think is being suggested and it worked fine in EDG 9.0 (just released). Maybe this issue has been addressed in newer releases of EDG?

Cheers,

David

P.S. Schema here:

# baseURI: urn:x-evn-master:test_property_schema

@prefix dash: <http://datashapes.org/dash#> .

@prefix graphql: <http://datashapes.org/graphql#> .

@prefix metadata: <http://topbraid.org/metadata#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix sh: <http://www.w3.org/ns/shacl#> .

@prefix teamwork: <http://topbraid.org/teamwork#> .

@prefix test_property_schema: <http://example.org/ontologies/Test_Property_Schema#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

test_property_schema:Asset

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:label "Asset" ;

  rdfs:subClassOf owl:Thing ;

  sh:property test_property_schema:Asset-hasDocument ;

  sh:property test_property_schema:Asset-label ;

.

test_property_schema:Asset-hasDocument

  a sh:PropertyShape ;

  sh:path test_property_schema:hasDocument ;

  sh:class test_property_schema:Report ;

  sh:maxCount 1 ;

  sh:name "hasDocument" ;

.

test_property_schema:Asset-label

  a sh:PropertyShape ;

  sh:path rdfs:label ;

  graphql:name "labels" ;

  sh:name "labels" ;

  sh:or dash:StringOrLangString ;

  sh:singleLine true ;

.

test_property_schema:Charter

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:label "Charter" ;

  rdfs:subClassOf owl:Thing ;

.

test_property_schema:Project

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:label "Project" ;

  rdfs:subClassOf owl:Thing ;

  sh:property test_property_schema:Project-hasDocument ;

  sh:property test_property_schema:Project-label ;

.

test_property_schema:Project-hasDocument

  a sh:PropertyShape ;

  sh:path test_property_schema:hasDocument ;

  sh:class test_property_schema:Charter ;

  sh:maxCount 1 ;

  sh:name "hasDocument" ;

.

test_property_schema:Project-label

  a sh:PropertyShape ;

  sh:path rdfs:label ;

  graphql:name "labels" ;

  sh:name "labels" ;

  sh:or dash:StringOrLangString ;

  sh:singleLine true ;

.

test_property_schema:Report

  a owl:Class ;

  a sh:NodeShape ;

  rdfs:label "Report" ;

  rdfs:subClassOf owl:Thing ;

  sh:property test_property_schema:Report-label ;

.

test_property_schema:Report-label

  a sh:PropertyShape ;

  sh:path rdfs:label ;

  graphql:name "labels" ;

  sh:name "labels" ;

  sh:or dash:StringOrLangString ;

  sh:singleLine true ;

.

<urn:x-evn-master:test_property_schema>

  a owl:Ontology ;

  graphql:publicClass test_property_schema:Asset ;

  graphql:publicClass test_property_schema:Charter ;

  graphql:publicClass test_property_schema:Project ;

  graphql:publicClass test_property_schema:Report ;

  metadata:status metadata:UnderDevelopmentStatus ;

  <http://topbraid.org/swa#defaultNamespace> "http://example.org/ontologies/Test_Property_Schema#" ;

  rdfs:label "Test Property Schema" ;

  owl:imports <http://datashapes.org/graphql> ;

.

To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/f40783fd-ccde-4179-ae9a-33b056f6db51n%40googlegroups.com.

[Holger Knublauch]

Hi Ad,

I guess the larger answer is that it is not possible to re-declare the same sh:path with multiple different sh:names and even sh:class constraints at the same node shape or class. As David indicates, this only makes sense to narrow down in subclasses.

Keep in mind that all constraints *add up* which means when you constrain the values of ex:hasDocument to have sh:class ex:Class1 and sh:class ex:Class2 then the values must be at the same time instances of Class1 AND Class2. This is unlikely what you want. You can, however, do that in a subclass or sub shape when Class1 is a superclass of Class2.

If you really want to reuse the same property hasDocument and display it in different places, you can use sh:values to define two separate properties that “infer” the grouping that you want for display purposes.

Holger

On Nov 6, 2025, at 02:23, David Price <dpr...@topquadrant.com> wrote:

Hi,

So I tried what I think is being suggested and it worked fine in EDG 9.0 (just released). Maybe this issue has been addressed in newer releases of EDG?

To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/7E553C71-745F-45D1-9AB3-08F25BFAE8C6%40topquadrant.com.

[Ad Reuijl]

Thanks a lot for your responses and effort to help me!

regards, 

Ad

Op donderdag 6 november 2025 om 08:01:29 UTC+1 schreef Holger Knublauch:

[bjodev]

Hi Holger,

I'm a little surprised by that (assuming that I understood the discussion correctly).

I was assuming that it is safe and deterministic if I reuse the same owl:Property R via sh:path in two PropertyShapes A and B, provided that both PropertyShapes define a unique link between R and two *different* classes P and Q.

In other words:

    The relation P→R is defined and constrained by PropertyShape A.

    The relation Q→R is defined and constrained by PropertyShape B.

When I then process an instance of class P, I would expect the constraints defined by PropertyShape A to be applied. Correspondingly, for an instance of Class Q, I would expect PropertyShape B to guide the UI data acquisition and validation.

I thought this was the situation that Ad was describing — and I would expect this to work because it is deterministic. There is no reason why an instance of class P should take PropertyShape B into account for R or vice versa (unless, of course, the instance were declared an instance of both classes, but let's exclude that scenario for now).

The only requirement is a type definition for the instance. In the absence of a type definition, there is no way to determine which constraints should apply.

Cheers,

Bernd

Am 06.11.25 um 08:01 schrieb Holger Knublauch:

To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/A52040AD-7298-4A75-8605-21B2BA774B28%40topquadrant.com.

[Holger Knublauch]

Hi Bernd,

Yes that scenario would be OK and keep the property shapes apart.

But I understood Ad’s example as

:AssetShape a sh: NodeShape ;

sh: targetClass :Asset ;

sh:property :ManualProp, :InspectionReportProp

i.e. both properties are attached to the same NodeShape. In that case their semantics would be merged.

Holger

To view this discussion visit https://groups.google.com/d/msgid/topbraid-users/62a46b4c-8a35-44cb-91b7-196efdabf2f9%40gmail.com.