Re: New Terminology Section


As I understand it, RDFS inferencing is one way to address this. However,
RDFS inferencing would do more than what is specified here. "Doing more˛
doesnąt create a problem, but, on the other hand, it is not required.

Another way to address this is to run a query as follows:

SELECT ?resource

?class rdfs:subClassOf* example:Class1 .
?resource a ?class .


Running this query would not change any graphs. As an aside, RDFS
inferencing is also often done without modifying any graphs. Inferences
are calculated on the fly when users/systems query data without any
materialization of inferred triples. At least, this is how triple stores
that support RDFS inferencing typically work.

Does your concern have to do with where the rdfs:subClassOf triples come
from - would they exist in the data graph, would they exist in the shapes
graph? They could be in either. If no subclass triples are there, then the
first triple match simply binds ?class to example:Class1 and the query
result is the same as if we were only looking for nodes that are connected
to example:Class1 via rdf:type link.

It doesnąt seem to be a role of SHACL to mandate where these triples
should be located. If they are available in either of the graphs, a SHACL
engine should take them into account. If they are not available, than it
doesnąt take them into account.

In our experience, users typically put the subclass triples into the
shapes graph. At the same time, they need flexibility to do whatever fits
their architecture and processes.

Irene Polikoff

On 5/9/16, 1:47 PM, "Karen Coyle" <> wrote:

>The types of a node are its values of rdf:type as well as the
>superclasses of these values.
>This conflates two different relationships: the relationship of a
>subject to a class (as defined in RDF/RDFS), defining the subject as an
>instance of the class; and the sub-/super-class relationships between
>classes. I dont' see how this can be achieved without inferencing.
>If we assume some pre-processing of the data graph to include the
>superclasses, then type is precisely as it is defined in RDF - there are
>just more type statements in the graph.
>As stated, this is quite an expansion of the meaning of type. In
>addition, it appears to require modifications to the data graph to
>include the super classes of each class (presumably up to and including
>I think it would be best if SHACL defined the shape and data graphs as
>immutable, thus expecting that all operations read but do not modify the
>graphs. I thought we had come to that conclusion.

Received on Monday, 9 May 2016 19:15:00 UTC