#185: Added subClassOfInShapesGraph parameter

[HolgerKnublauch]

Closes #185

• See this document rendered online here

Added Andy and Ashley as reviewers too, to check if this is implementable from their engines point of view. The main difference is that instead of

?instance rdf:type/rdfs:subClassOf $class .

it would become

?instance rdf:type ?type .
GRAPH $shapesGraph {
    $type rdfs:subClassOf* ?class
}

And it's an optional feature...

[jeswr]

Suggested change

	from the <a>shapes graph</a> instead of the <a>data graph</a>.
	from the <a>shapes graph</a> in addition to the <a>data graph</a>.

Why omit consideration of rdfs:subClassOf statements in the data graph when this mode is enabled?

[HolgerKnublauch]

That COULD work too. I went with the simpler solution because querying a union graph would be more complex, and make optimizations harder. If we know that we only look in the shapes graph, all class closures could be pre-computed into HashSets, instead of having to walk the hierarchy over and over.

Also, what about undesirable cases where some subClassOf triples are in the data graph and others in the shapes graph. That sounds like a mess to me.

[HolgerKnublauch]

Are there realistic scenarios where people want to mix and match?

[jeswr]

Are there realistic scenarios where people want to mix and match?

I can imagine some cases e.g. having an upper level ontology in your shapes graph and then lower level ontologies in your data graph. I have no data on whether these appear in the wild.

[jeswr]

At risk of overcomplicating things - would it be worth inferenceDataInShapesGraph rather than subClassOfInShapesGraph; and using this feature to enable inclusion of other data for inference rules in the shapes graph?

[HolgerKnublauch]

@jeswr there is already sh:entailment to activate other inferencing. And it is under complete control of the user which graph to pass into the engine as shapes graph. That graph may have been pre-processed with OWL to infer additional rdfs:subClassOf axioms.

As the above IMHO doesn't need a formal parameter to the engine, I wanted to however spell out the new flag because it does need a parameter as it changes how some terms (SHACL Instance) behave.

[afs]

SHACL implementations can be parameterized

Where's the list of all parameters?

The whole "implementation controls" area seems to sit uneasily between implementation and standardization.

[afs]

Not sure if the discussion is best here or on #185.

Added a general comment on the issue -- #185 (comment)

[HolgerKnublauch]

I am not aware of other flags or parameters for the engine, but they could be grouped into an appendix if we define more.