sh:targetClass question

8 views
Skip to first unread message

Steve Ray

unread,
Jun 23, 2021, 1:20:07 PMJun 23
to TopBraid Suite Users
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

unread,
Jun 23, 2021, 2:47:34 PMJun 23
to topbrai...@googlegroups.com
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.


--
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

unread,
Jun 23, 2021, 3:00:20 PMJun 23
to TopBraid Suite Users
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




Irene Polikoff

unread,
Jun 23, 2021, 3:09:10 PMJun 23
to topbrai...@googlegroups.com

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.


Steve Ray

unread,
Jun 23, 2021, 6:23:02 PMJun 23
to TopBraid Suite Users
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




Steve Ray

unread,
Jul 2, 2021, 10:50:28 AMJul 2
to topbrai...@googlegroups.com
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




TestShNode.shapes.ttl

Irene Polikoff

unread,
Jul 2, 2021, 11:09:57 AMJul 2
to topbrai...@googlegroups.com

Steve Ray

unread,
Jul 2, 2021, 11:52:20 AMJul 2
to topbrai...@googlegroups.com
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




Holger Knublauch

unread,
Jul 2, 2021, 6:40:43 PMJul 2
to topbrai...@googlegroups.com

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

Reply all
Reply to author
Forward
0 new messages