Shape hierarchy

[Tomasz Pluskiewicz]

Hi

I'm trying to figure out the best way to validate requests using SHACL where the shapes from a hierarchy, defined as rdfs:Class + rdfs:subClassOf and each shape has an implicit target.

# shapes graph

<Child> a rdfs:Class, sh:NodeShape ;

  rdfs:subClassOf <Parent> .

<Parent> a rdfs:Class, sh:NodeShape .

# data graph

<> a <Child> .

I saw this comment and it makes most sense with a data graph possibly retrieved from a store with reasoning enabled. That would provide a full information derived from the subclass statements.

However, in my HTTP request scenario, I only get the explicit rdf:type triple and for practical reasons want to avoid using a reasoner in the API code. Thus, only the <Child> shape's constraints will apply. It would be similar in a web UI.

The shapes graph and data graph are separate and I'd like it to stay that way.

I'm looking at two ways for approaching this:

1. Copy all rdfs:subClassOf statements into the data graph for the sole purpose of running the validation.

2. Gather the super classes for every shape and add them as `sh:and` lists to the sub classes.

I'm leaning towards the latter, where the result would add the following to the shapes graph

<Child> sh:ad ( <Parent> ) .

Would that be equivalent to the built-in support for rdfs:subClassOf? Is it something a SHACL validation processor could do by default?

Best,

Tom

[Holger Knublauch]

Hi Tom,

what you describe is the usual design that we are promoting and using at TopQuadrant: Keep ontology and instances separate, and use implicit targets (i.e. classes that are also sh:NodeShape). For validation to work best, we simply have the instance graphs owl:import the schema graph(s), and use a Jena MultiUnion (or OntModel) to provide a logically merged graph consisting of both instances and classes. This means that the requires rdfs:subClassOf triples will always be present and consistent. Also the rdf:type triples of the classes/shapes, although those are only really needed in the (logical) shapes graph.

So instead of copying any triples, have you considered running the validation over the union graphs? This should take care of things and completely avoid any need to do (RDFS) inferencing - the SHACL standard prescribes that engines will do a simple form of class inheritance automatically, regardless of the chosen inference regime.

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/b7011fd4-7920-4238-b931-9410a55fd723n%40googlegroups.com.