sh:targetClass question

[Steve Ray]

The discussion you have been having regarding sh:targetClass reminds me of a problem I am having, as follows. 

I'm defining an abstract "mixin" shape, Connectable, that has various properties used by a number of target classes. I do not want to allow instantiation of Connectable, so I defined it only as a NodeShape, but not an owl:Class. (I cannot use the dash:abstract property without stepping outside strict SHACL). Then, I need other classes to have the equivalent of a sh:class constraint on properties that point to instances of all those target classes. I assume I cannot use sh:class as in the example below, since Connectable is not a class. I tried sh:node, since the documentation implies that's what I need, but I'm not getting the expected behavior.

Am I misunderstanding the use of sh:node?

s223:Connectable

a sh:NodeShape ;

...various properties

sh:targetClass s223:Device ;

sh:targetClass s223:DomainSpace ;

sh:targetClass s223:Sensor ;

.

s223:Device

a owl:Class ;

a sh:NodeShape ;

...

.

# Presumed invalid case

s223:SomeOtherClass

a owl:Class ;

a sh:NodeShape ;

sh:property [

sh:path s223:connectsFrom ;

sh:class s223:Connectable ;

...

#Expected valid case

s223:SomeOtherClass

a owl:Class ;

a sh:NodeShape ;

sh:property [

sh:path s223:connectsFrom ;

sh:node s223:Connectable ;

...

Steve

[Irene Polikoff]

What behaviour did you expect?

Since Connectable is just a shape and does not have any instances, then you can’t use it in sh:class. This constraint says that the value must be an instance of Connectable, which will always be wrong.

When you say sh:node s223:Connectable, it means that values should validate against the constraints defined for Connectable. For this scenario targets associated with Connectable are ignored since the constraint is already targeting - all values of s223:connectedFrom that belong to members of SomeOtherClass will be validated against the shape.

All instances of Device, DomainSpace and Sensor will also be validated against the Connectable shape - because of the target statements.

https://www.w3.org/TR/shacl/#NodeConstraintComponent

https://www.w3.org/TR/shacl/#focusNodes

--
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/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com.

[Steve Ray]

I forgot one detail, which is that I have a subClassOf hierarchy under Device, and the instances of any of those subClasses do not seem to validate against the Connectable shape. Does sh:node traverse the subClassOf hierarchy of the sh:targetClass values?

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3A11B544-71EA-48BD-B068-0BA71EBD5E1D%40topquadrant.com.

[Irene Polikoff]

Not sure I understand the question. 

sh:node :Connectable

Simply means that the values need to satisfy the constraints defined for :Connectable. If you have a type constraint defined for :Connectable (i.e., a property have that rdf:type must be some specific class), then it will be evaluated, but if you don’t, then, it does not matter what is the type of the value resource.

Given your model, there are two ways to identify nodes to validate against :Connectable - 1)values of :connectsFrom for instances of SomeOtherClass and instances of Device and other target classes. This includes instances of subclass.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86S_teBHHHDmhb13U1sQ4ctx197%3D2LLb60p8BtwiRK69A%40mail.gmail.com.

[Steve Ray]

Problem solved.

I think I was a victim of some caching of leftover definitions of some sort. Once I closed and re-opened TBC, my use of "sh:node s223:Connectable" worked as expected with instances of a subClass of Device.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BD2E5E3F-BD00-43F3-B46F-8FC49117B2AF%40topquadrant.com.

[Steve Ray]

I believe that I now understand everything you say regarding sh:node. I recognize that any instance that satisfies the constraints of the NodeShape will pass the sh:node constraint, thus not error is raised.

All was good until I found that I was hanging TBC. My hypothesis is that in determining satisfaction of the sh:node constraint, the engine had to examine all the properties of the NodeShape. Since some of those properties in turn contained sh:node constraints, it had to recurse in to check if those properties were satisfied. Since some of the instances pointed to each other, I figured I had sent TBC into an infinite recursion.

To check this, I built a toy example (attached) with a "sibling" relation with the same pattern. However, this example seems to validate just fine, without hanging. I'm wondering why the same infinite recursion is not happening. 

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BD2E5E3F-BD00-43F3-B46F-8FC49117B2AF%40topquadrant.com.

[Irene Polikoff]

https://www.w3.org/TR/shacl/#shapes-recursion

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86o-GWEYks1zFRu0KnN_QpkLE03yvdWMgmJnV3CmA_dnw%40mail.gmail.com.
<TestShNode.shapes.ttl>

[Steve Ray]

Thanks for the quick response. I'm unsure how TBC handles sh:node, since my toy example validates without errors, while my real code hangs forever. What is your intended TBC behavior? (Then I will dig in and try to figure out which of my examples doesn't work that way).

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/09E3A686-8FF7-449D-B639-5B906C0631AE%40topquadrant.com.

[Holger Knublauch]

In principle the engine has dedicated built-in logic to gracefully detect recursion. However there may be undetected scenarios where this does not work. I would need to see the example.

in general I hardly ever use sh:node as most use cases are better handled with sh:class. sh:node is ok for describing things but not so much for validation.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86ri3JpAarLqTT%3DutDBkS7k8hU0N20N%2BpCdroDg-sufgA%40mail.gmail.com.