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]> 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#> .
@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> ;
.
On 5 Nov 2025, at 15:36, Ad Reuijl <[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”:
Screenshot 2025-11-05 at 11.49.22.png
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:
Screenshot 2025-11-05 122010.png
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
Screenshot 2025-11-05 122354.png
Only one documents show up while there are many more applicable
to the class/shape Draaideur
Screenshot 2025-11-05 122549.png
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>.
Screenshot 2025-11-05 122354.pngScreenshot 2025-11-05
122549.pngScreenshot 2025-11-05 122010.png
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]
---
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/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]
---
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/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]
---
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/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].
To view this discussion visit
https://groups.google.com/d/msgid/topbraid-users/62a46b4c-8a35-44cb-91b7-196efdabf2f9%40gmail.com.
