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
On 8/04/2021 10:14 pm, Tomasz Pluskiewicz wrote:
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
<https://github.com/TopQuadrant/shacl-js/issues/22#issuecomment-580498030> 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
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/b7011fd4-7920-4238-b931-9410a55fd723n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/b7011fd4-7920-4238-b931-9410a55fd723n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/256daa55-bc7a-2d22-34a5-d290a397f712%40topquadrant.com.
