I see that Holger has responded. I put a reply together hours ago and forgot to send it.
It overlaps with what Holger said, but I think it adds something new, so I am sending it - even though it is redundant. > On Jul 12, 2021, at 10:13 AM, Tim Smith <[email protected]> wrote: > > 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. Yes, it is that. The point Holger and I were making is that sh:name is not the name of the property shape itself - it is the name of the path in the context of the shape. Whether it is a simple path or complex, does not change this. To name the property shape, use rdfs:label. > 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). You could, but a) this label may not exist - there may be no triples with the property as the subject when you use SHACL, they are often not necessary; 2) sh:name overrides the property label even if it exists > 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.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. >From SHACL perspective, sub property does not mean anything, but, of course, >you can do sub properties if you find documenting this useful > 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. Right. So, there are two possible situations here: 1. Using a property in a context of an application where for a given class there is only one possible set of values for the property For example, if you are describing an Investor, you only care about them owning investment instruments. If you are describing Pet Owners, you only need to care about them owning pets. >From the data creation perspective, these would be two different >apps/interfaces. This is well supported by defining different shapes for the >same property. These concerns are orthogonal and you never bring these two models together to support data creation and validation. If you need to bring the data together - for query, reporting, etc., you would simply use a more generic shape for owns. And this would be OK since you will not be authoring based on this shape. One could wonder if you should be using the same property in this case since the objects of owning are so different, but nevertheless … There could also be a situation where you would want to further restrict the set of values for a property as you go down the class tree. For example, what could be an input and what could be an output may change as you go down the class tree. This would work without using qualified value shapes. Of course, having 1000 different input and output properties is probably excessive. However, using just one may not be the right solution either. I can’t say much more without better understanding your information and requirements. 2. Using a property in a context where for members of a given class there are multiple different sets of values for it - AND - you want to differentiate it for a user, as they create data For example, instead of letting a user to enter any investment instruments in the “owns" slot, you want them to have separate form fields to enter stocks separately from bonds, separately from commodities, etc. Data will be using the same property, but the UI will separate the data entry according to possible values. In this situation, qualified value shapes give you a way to enumerate different value classes, but: 1. There is no out of the box data entry UI to facilitate this experience You attached a screenshot with the model, but I think your requirements are primarily about data creation and what is displayed on a form for that, and not so much what is shown on the class form. Correct? Right now: If you do not have a class constraint in the general shape on “owns”, then the value selector will simply let you pick any resource - provided you specified the sh:nodeKind constraint. Otherwise, it does not even know that this supposed to be a resource as opposed to a literal If you have a class constraint with the general parent class e.g., Investment Instrument, then a user gets to select any investment instrument. Data validation will use qualified value shapes, but the form generator will not. 2. If you can specify a common super class in the sh:class constraint e.g., Investment Instrument, then, even from the data validation perspective, qualified value shapes may not give you anything special. The only situations where they are useful are when: There is no natural superclass for all possible objects You have some specific cardinality constraints or other constraints that are different for different shapes. For example, all investors in your world must have some stocks, they could also have bonds, etc., but stocks are required. Holger said "we had other customers or projects with heavy usage of qualified value shapes recently, with similar requirements”. Thus, we will be improving the UI. In doing this, we need to be clear on requirements. I believe the other customers Holger talks about primarily care about the UI for creating the qualified value shapes, while your requirements are strongly about the data entry based on the qualified value shapes. Is this the case? > > 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] > <mailto:[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] >> <mailto:[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] > <mailto:[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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.com > > <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.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/B63E565B-D074-4408-A953-08F0085315B5%40topquadrant.com.
