EDG does not display sh:qualifiedValueShapes properly
Tim Smith
a sh:PropertyShape ;
sh:path df:owns ;
sh:description "Ensures there is one and only one instance of Movie Company owned by this instance."@en ;
sh:group tosh:PropertiesPropertyGroup ;
sh:name "Movie Company" ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
sh:class df:MovieCompany ;
] ;
.
Holger Knublauch
Hi Tim,
we had other customers or projects with heavy usage of qualified
value shapes recently, with similar requirements and complaints.
So I certainly want to improve this space. However, it's not
trivial as qualified value constraints are an outlier compared to
other types of SHACL constraints. But let's look at your details
for a second.
Hi,
As mentioned in another thread, I am trying to use sh:qualifiedValueShape to ensure the correct number and type of instances are objects of a specific property. EDG does not seem to support sh:qualifiedValueShape correctly. Below are a number of issues I have encountered.
First, when adding property shapes of the form below to a class,
df:HoldingCompany-owns-MovieCompany
a sh:PropertyShape ;
sh:path df:owns ;
sh:description "Ensures there is one and only one instance of Movie Company owned by this instance."@en ;
sh:group tosh:PropertiesPropertyGroup ;
sh:name "Movie Company" ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
sh:class df:MovieCompany ;
] ;
.
EDG displays them as datatype properties and displays the cardinality incorrectly, ignoring sh:qualifiedMin/MaxCounts. I had to add the property shape via the source code panel as there was no way to do so via the UI.
Yes, editing support for QVCs is poor. Even if we added the four sh:qualifiedXY properties to the form, users would still need a dedicated editor for the inner shape, which is usually a blank node. A form-based user experience will struggle to be both user friendly and flexible to cover all use cases. The best we could do is improve support for selected patterns, and the scenario with an inner sh:class constraint is by far the most common scenario that I have seen here.
On your screenshot above, I disagree though that the cardinalities should be based on qualifiedMaxCount. It is perfectly legal to have an unlimited number of values and yet a limited qualified number of values. So I guess the best thing we could do here is to use sh:qualifiedMinCount.
The larger problem is that these QVCs don't fit under "Properties" or "declared properties". It should really be "Property Shapes" instead, yet not everybody will understand this. These are the problems that we as UI designers are facing with QVCs, and there is no easy solution.
Anyway, I have opened a new ticket to make this better. See below
for quick fixes.
Second, when I add an instance of Holding Company and I do not populate the df:own property, as expected, I get violations. However, the violations reference the blank node inside the property shape (bnode for sh:qualifiedValueShape). I can click through to discover what shape is causing the error. I think it should tell me the name of the shape in the violation.
I had an old ticket for exactly this which I have now reopened and may address for 7.1. In the meantime, it will render better if you add rdf:type sh:NodeShape to the inner shapes:
Third, and most significant to the user, as shown above, EDG is putting both violations with the Movie Company Property Shape even though they are differently named shapes with different URIs. I know why it is doing this - both shapes have the same sh:path - df:owns. However, in this case, using the sh:qualifiedValueShape statements, EDG should be able to determine which instances go with which property shape. Lumping them all under the first one (alphabetically) is misleading at best.
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. Look at this alternative:
df:HoldingCompany-owns-MovieCompany
a sh:PropertyShape ;
sh:path df:owns ;
sh:description "Ensures there is one and only one instance of
Movie Company owned by this instance."@en ;
sh:group tosh:PropertiesPropertyGroup ;
sh:name "owns" ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
a sh:NodeShape ;
rdfs:label "is a Movie Company" ;
sh:class df:MovieCompany ;
] ;
.
which renders quite nicely, I believe:
(In this case you don't even need the rdf:type sh:NodeShape triple).
Having said this, the tool should be smarter and derive such
display labels on the fly - as I mentioned above I have reopened a
ticket for that.
Fourth, after adding an instance of both Racing and Movie Company, when I try to add them to the Movie Company property on the Holding Company 1 form, the form only let's me enter a text value - if you recall #1 above - EDG is expecting a datatype property. So it's consistent but incorrect. The only way to add them is to use the source code editor..
Fifth, when viewing a property shape that uses sh:qualified*, the only way to see the sh:qualified* properties is to enable "view undeclared properties". Also note there is no way to see the contents of the sh:qualifiedValueShape property on the form, only the bnode. Selecting Show Details from the dropdown gives "No suitable view shape found". Screenshot below.
I suggest you change these property shapes completely. You will notice that something is wrong because you have duplicated sh:group triples in both. This info doesn't belong there. Instead, use one general property shape for the owns property itself, and then two smaller property shapes that are ONLY about the QVCs:
df:HoldingCompany
a owl:Class ;
a sh:NodeShape ;
rdfs:label "Holding Company" ;
rdfs:subClassOf owl:Thing ;
sh:property df:HoldingCompany-owns ;
sh:property df:HoldingCompany-owns-MovieCompany ;
sh:property df:HoldingCompany-owns-RacingCompany ;
.
df:HoldingCompany-owns
a sh:PropertyShape ;
sh:path df:owns ;
sh:class owl:Thing ;
sh:group tosh:PropertiesPropertyGroup ;
sh:name "owns" ;
.
df:HoldingCompany-owns-MovieCompany
a sh:PropertyShape ;
sh:path df:owns ;
sh:message "There must be one and only one instance of Movie Company owned by this instance."@en ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
rdfs:label "is a Movie Company" ;
sh:class df:MovieCompany ;
] ;
.
df:HoldingCompany-owns-RacingCompany
a sh:PropertyShape ;
sh:path df:owns ;
sh:message "There must be one and only one instance of Racing Company owned by this instance."@en ;
sh:qualifiedMaxCount 1 ;
sh:qualifiedMinCount 1 ;
sh:qualifiedValueShape [
rdfs:label "is a Racing Company" ;
sh:class df:RacingCompany ;
] ;
.
With that approach, the input field for owns should allow you to select an instance, and the error message will be exactly what you want:
Using sh:description is not correct because that should be the description of the property itself, not the property shape. However, using sh:message is ideal.
I have just created a little ModifyAction using Active Data Shapes that may help you with this pattern. Download the attached file and owl:import it into your Ontology. When you select any NodeShape/class, you will find a new item "Create qualified value shape" in the Modify menu. Click this and fill in the template:
Are these issues, particularly number 3, something that I can fix? It feels like support for sh:qualifiedValueShapes in the UI was missed as an oversight. I have an internal EDG demo next Friday and I would really like to showcase these SHACL capabilities. The attached file is an export of the EDG ontology asset that I created for this email.
Not really an oversight, simply too complex to fully support. Maybe the changes above will make your demo work better until we had time to improve the out-of-the-box tooling.
Holger
Thank you for your consideration,
Tim
--
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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BqAQw5r8pXbG1jXSQbxJqcCMCe%3DL5Uj6jishboZaVAxQ%40mail.gmail.com.
Irene Polikoff
Tim Smith
--
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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com.
Holger Knublauch
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.
Yes, on a branch for 7.1 I have implemented this (more useful) display:
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.
I am aware that other projects (esp in the engineering space) are using qualified value constraints like you intended to. We will improve tool support as described above. With that, what other obstacles would remain for you?
Having said this, "normal" properties will win in most cases. Simpler to define and faster to query (with "owns" you'd need FILTERs everywhere). So while you may need to define 1000 properties, you will now need to define 1000 QVC property shapes. Is this really an improvement?
Holger
Thanks for the always informative discussion,
Tim
--On Fri, Jul 9, 2021 at 10:08 PM Irene Polikoff <ir...@topquadrant.com> 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 <hol...@topquadrant.com> 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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com.
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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.com.
Irene Polikoff
On Jul 12, 2021, at 10:13 AM, Tim Smith <smith...@gmail.com> 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.
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.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.
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.
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 experienceYou 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.
Anyway... I will explore other ways to achieve my objective. Maybe some custom UI elements are warranted.Thanks for the always informative discussion,TimOn Fri, Jul 9, 2021 at 10:08 PM Irene Polikoff <ir...@topquadrant.com> 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 <hol...@topquadrant.com> 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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com.
--
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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.com.