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”: > > > [image: 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: > [image: 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 > > [image: Screenshot 2025-11-05 122354.png] > > Only one documents show up while there are many more applicable to the > class/shape Draaideur > > [image: 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> > . > [image: Screenshot 2025-11-05 122354.png][image: Screenshot 2025-11-05 > 122549.png][image: Screenshot 2025-11-05 122010.png] > > > David Price, Semantic Solution Architect > UK +44 (0) 7788 561308 <+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.
