SHACL Question

[Tim Smith]

Hi,

I have a need to model this constraint in SHACL:

An Entertainment Holding Company must own one and only one instance of EACH of the following classes: Movie Company, Racing Company, and Streaming Company in order to be a valid instance of Entertainment Holding Company.

This is an example of a valid instance:

Any more or less than 3 st:owns triples or more or less than 1 instance of the three classes listed above should be a violation.

I have tried numerous ways to model this behavior without success.  SHACL seems to iterate through each object of the st:owns property where I'm making a statement about the set of st:owns objects.  I encounter this type of problem frequently so I'm hoping there is a pattern I can apply as a generic solution.  Something like sh:and but where sh:and would look across all objects of sh:path.

Am I missing something simple?  The one solution that I know works is the one that I cannot use - creating a new property and property shape for each class  e.g. st:ownsMovieCompany.  If this is the only solution, then I can never use a "generic" property like "owns", "category", etc....  This will result in a property explosion and would rapidly become unworkable in industry-sized models.

Thanks in advance for your input,

Tim

[Holger Knublauch]

Hi Tim,

have you tried https://www.w3.org/TR/shacl/#QualifiedValueShapeConstraintComponent with min count and max count 1 and sh:class? You need three property shapes on the same property.

Holger

--
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/CAF0WbnKXEb%2BArirQXCq9w5ZH-Y7b%3DX7apZge%2BU_UxCnFVznxPw%40mail.gmail.com.

[Tim Smith]

Hi Holger,

I had not tried sh:qualifiedValueShape.  After adding three sh:property statements for the st:owns property, it worked mostly as expected.  I added a fourth property shape to ensure that st:owns has only instances of the three classes as the object.  Otherwise, once the three qualifiedValueShapes were satisfied, I could add anything using st:owns without a violation.

Now I've hit another wrinkle, I need the validation of st:Entertainment_Holding_Company to be recursive, meaning that all values upon which st:Entertainment_Holding_Company is dependent must also be valid, even if they are two, three, or more hops away in the graph.  I.e. The graph pattern I'm defining is not just a single instance and its nearest neighbors.  Thus, it's not sufficient to say:

      sh:qualifiedValueShape [
          sh:class st:Streaming_Company ;
        ] ;

I need to be able to trigger the validation of the st:Streaming_Company instance such that if that instance is invalid, the st:Entertainment_Holding_Company instance is also flagged as invalid.  In other contexts, I have been able to use sh:node in place of sh:class in order to get this recursive validation behavior.

      sh:qualifiedValueShape [
          sh:node st:Streaming_Company ;
        ] ;

However, in this case, using TBC/ME 7.02, changing one of the three property shapes to sh:node generates violations for the other two property shapes.  Changing all three generates a violation for all three qualified property shapes.  Example below.  Is this the expected behavior?  Is it possible to get recursive validation to enable validation of "large" graph patterns?  This is a key capability to being able to evaluate SysML models for completeness and accuracy.  Example RDF file attached (with sh:node in the property shapes).

Thanks for your input,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bd4c0653-340d-f188-bf20-95582b4656f6%40topquadrant.com.

[Holger Knublauch]

Hi Tim,

your example has sh:qualifiedValueShapesDisjoint true on all three cases, but they are NOT disjoint. All that the three helper shapes verify is that the values of rdfs:label are strings. Nothing else. The constraint applies to all instances.

Did you probably expect that sh:node would also implicitly check for the rdf:type? It doesn't. The fact that for example st:Streaming_Company is both sh:NodeShape and owl:Class doesn't make a difference for validation, it is only used for targeting of nodes.

So you would need to add constraints on rdf:type, e.g. using sh:class. In the attached version I have removed the disjoint statements and instead added three sh:class constraints. This is producing no violations.

Not sure if this exactly what you want to test, but maybe one step closer. Keep in mind that deep sh:node structures may badly impact performance and cause problems with recursion.

Maybe what you really want would be to leave the sh:class constraints in instead of sh:node, but then when a user validates the root instance (e.g. on a form) it should also walk into adjacent instances and check their constraints using class membership?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2ByHvjQgEMmshwqNgG4Bt-Fn1_0SfTJJhDmPUSDyJQD1Q%40mail.gmail.com.