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
> On Nov 9, 2025, at 23:50, bjodev <[email protected]> wrote:
>
> 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:
>> 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 <[email protected]>
>>> <mailto:[email protected]> 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?
>>>
>>> <Screenshot 2025-11-05 at 16.18.34.png>
>>>
>>> Cheers,
>>> David
>>>
>>> P.S. Schema here:
>>>
>>> # baseURI: urn:x-evn-master:test_property_schema
>>>
>>> @prefix dash: <http://datashapes.org/dash#> <http://datashapes.org/dash#> .
>>> @prefix graphql: <http://datashapes.org/graphql#>
>>> <http://datashapes.org/graphql#> .
>>> @prefix metadata: <http://topbraid.org/metadata#>
>>> <http://topbraid.org/metadata#> .
>>> @prefix owl: <http://www.w3.org/2002/07/owl#>
>>> <http://www.w3.org/2002/07/owl#> .
>>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>>> <http://www.w3.org/2000/01/rdf-schema#> .
>>> @prefix sh: <http://www.w3.org/ns/shacl#> <http://www.w3.org/ns/shacl#> .
>>> @prefix teamwork: <http://topbraid.org/teamwork#>
>>> <http://topbraid.org/teamwork#> .
>>> @prefix test_property_schema:
>>> <http://example.org/ontologies/Test_Property_Schema#>
>>> <http://example.org/ontologies/Test_Property_Schema#> .
>>> @prefix xsd: <http://www.w3.org/2001/XMLSchema#>
>>> <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://topbraid.org/swa#defaultNamespace>
>>> "http://example.org/ontologies/Test_Property_Schema#";
>>> <http://example.org/ontologies/Test_Property_Schema#> ;
>>> rdfs:label "Test Property Schema" ;
>>> owl:imports <http://datashapes.org/graphql>
>>> <http://datashapes.org/graphql> ;
>>> .
>>>
>>>
>>>
>>>> On 5 Nov 2025, at 15:36, Ad Reuijl <[email protected]>
>>>> <mailto:[email protected]> wrote:
>>>>
>>>> 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:
>>>>> 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
>>>>>
>>>
>>>>>
>>>>>
>>>>>> On 5 Nov 2025, at 11:32, Ad Reuijl <[email protected] <>> wrote:
>>>>>>
>>>>>
>>>>>> 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:
>>>>>>
>>>>>> What is the (historical or technical) reason for using sh:path as the
>>>>>> determining key for rendering, instead of the PropertyShape identity
>>>>>> itself?
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>> --
>>>>>> The topics of this mailing list include TopBraid EDG and related
>>>>>> technologies such as SHACL.
>>>>>> To post to this group, send email to [email protected] <>
>>>>>> ---
>>>>>> 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 [email protected] <>.
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/topbraid-users/676f2b33-f5e7-4811-979c-4825c44089c6n%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/topbraid-users/676f2b33-f5e7-4811-979c-4825c44089c6n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>>>
>>>>>
>>>>> David Price, Semantic Solution Architect
>>>>> UK +44 (0) 7788 561308 <tel:+44%207788%20561308>
>>>>> TopQuadrant.com <https://www.topquadrant.com/>
>>>>
>>>>
>>>> --
>>>> The topics of this mailing list include TopBraid EDG and related
>>>> technologies such as SHACL.
>>>> To post to this group, send email to [email protected]
>>>> <mailto:[email protected]>
>>>> ---
>>>> 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 [email protected]
>>>> <mailto:[email protected]>.
>>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/topbraid-users/f40783fd-ccde-4179-ae9a-33b056f6db51n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/topbraid-users/f40783fd-ccde-4179-ae9a-33b056f6db51n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>> David Price, Semantic Solution Architect
>>> UK +44 (0) 7788 561308
>>> TopQuadrant.com <https://www.topquadrant.com/>
>>>
>>> --
>>> The topics of this mailing list include TopBraid EDG and related
>>> technologies such as SHACL.
>>> To post to this group, send email to [email protected]
>>> <mailto:[email protected]>
>>> ---
>>> 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 [email protected]
>>> <mailto:[email protected]>.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/topbraid-users/7E553C71-745F-45D1-9AB3-08F25BFAE8C6%40topquadrant.com
>>>
>>> <https://groups.google.com/d/msgid/topbraid-users/7E553C71-745F-45D1-9AB3-08F25BFAE8C6%40topquadrant.com?utm_medium=email&utm_source=footer>.
>>
>> --
>> The topics of this mailing list include TopBraid EDG and related
>> technologies such as SHACL.
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>
>> ---
>> 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 [email protected]
>> <mailto:[email protected]>.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/topbraid-users/A52040AD-7298-4A75-8605-21B2BA774B28%40topquadrant.com
>>
>> <https://groups.google.com/d/msgid/topbraid-users/A52040AD-7298-4A75-8605-21B2BA774B28%40topquadrant.com?utm_medium=email&utm_source=footer>.
>
>
> --
> The topics of this mailing list include TopBraid EDG and related technologies
> such as SHACL.
> To post to this group, send email to [email protected]
> ---
> 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 [email protected]
> <mailto:[email protected]>.
> To view this discussion visit
> https://groups.google.com/d/msgid/topbraid-users/62a46b4c-8a35-44cb-91b7-196efdabf2f9%40gmail.com
>
> <https://groups.google.com/d/msgid/topbraid-users/62a46b4c-8a35-44cb-91b7-196efdabf2f9%40gmail.com?utm_medium=email&utm_source=footer>.
--
The topics of this mailing list include TopBraid EDG and related technologies
such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/topbraid-users/9EA9EF03-B4CC-4E8A-B76D-B093335D46DE%40topquadrant.com.
