Thanks Holger and Irene. Perhaps I have been trying to stretch SHACL in ways it was not intended. I had interpreted sh:name to represent the name of the path *in the context* of the property shape. If it is intended to universally be the name of the path, then we can just use the label of the property (assuming the path is not a property path). However, this does present some display issues when using multiple shapes against the same property. Here is "Holding Company" in EDG using Holger's more efficient approach as shared above. Now there are three declared properties (shapes), all shown as "owns". I do think in the context of the property shape that is being displayed, we should have the cardinality displayed based on the shape.
[image: image.png] On a broader note, I know my potential EDG users will never know the difference between properties and property shapes. e.g. What appears in the "declared properties" group are shapes. Thus I have been trying to use shapes as a way to drive the UI, but maybe in a way that is contrary to the standard. Let me briefly explain. A very common ontological modeling use case is deciding what property to use. I, and others, try to limit the number of properties by using "generic" properties that convey the correct semantics, e.g. the "owns" property in my example. However, this may be too generic for the user that is viewing or creating instances, especially when there are conditions on the set of objects. e.g. must be one Racing and one Movie company. QVCs enable capturing the correct semantics. In addition to capturing the semantics, in many cases I want to show the users what objects adhere to the semantics defined by each QVC, not simply a list of all things that are an object of "owns". As I understand it today, the only solution is to create subproperties of df:owns and create property shapes for each new property. I don't want to go down this path if at all possible since it will lead to property explosion where I'm creating a property for every "generic" property/class combination, e.g. df:ownsRacingCompany, df:ownsMovieCompany, etc... I did this for a control system ontology and I ended up with nearly 1000 properties where all I really needed was edg:input and edg:output because I needed to be able to show the user the possible set of inputs and outputs and what was connected (or not) to each of them. To me this was an example of the UI driving the model. Anyway... I will explore other ways to achieve my objective. Maybe some custom UI elements are warranted. Thanks for the always informative discussion, Tim On Fri, Jul 9, 2021 at 10:08 PM Irene Polikoff <[email protected]> wrote: > To add to what Holger said, this is the reason sh:name exists. If this was > the label of the property shape, then there would be no need to define a > new property. One could simply use rdfs:label - as Holger’s example shows. > > Sh:name was created because it is not the label of the resource that is > the subject of the sh:name triples. Instead, it is a display label for the > path. > > On Jul 8, 2021, at 9:34 PM, Holger Knublauch <[email protected]> > wrote: > > I don't agree on that and believe your use of sh:name does not align with > how the standard intended it to be used. sh:name is supposed to be the > display label for the property, e.g. "owns" and not the label of the > property shape. The label of the property shape should be in rdfs:label, > like you would do it for node shapes. > > > -- > 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 on the web visit > https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com > <https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com?utm_medium=email&utm_source=footer> > . > -- 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 on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.com.
