Inferencing, sh:entailment, and strategies for describing entailment satisfaction #219
Description
This is an expansion of a use case suggested in this comment. The summary is that there may be value in defining a "partner" predicate to sh:entailment for custom entailment regimes.
Suppose I have a shapes graph that I expect to run against a knowledge graph (ABox & TBox) with the expectation of RDFS inferencing having taken place before the shapes start reviewing.
My understanding is much of RDFS and OWL entailment can be accomplished with what is in the 2017 state of the SHACL-AF document, by my current understanding of the mutual coverage of SPARQL CONSTRUCT and SHACL-AF expressions. As an example, I have a script that runs parts of RDFS entailment by running a sequence of CONSTRUCT queries implementing some of the rules from here. This CONSTRUCT query entails types from rdfs:domain.
Separate thought, which will converge: sh:entailment, given in the 2017 state of the SHACL document, Section 1.5, specifies how a shapes graph can require a certain entailment regime, and what should happen if the SHACL processor doesn't self-declare as supporting the requested entailment regime.
So, this shapes graph ...
@prefix ex: <http://example.org/shapes/> .
<http://example.org/shapes>
a owl:Ontology ;
sh:entailment <http://www.w3.org/ns/entailment/RDFS> ;
.... is supposed to trigger a failure from the processor if the processor doesn't declare support for http://www.w3.org/ns/entailment/RDFS.
Coming together: Should part of the Inferencing working group's output be a graph implementing RDFS entailment, so that any processor could have a "default" ruleset to follow or use for consistency checking with their own implementation of RDFS entailment?
A benefit would be that the inferencing group could use this a way to test specification behaviors around sh:entailment, like non-standard IRIs that might be used in less broadly adopted shape graphs.
For instance, a user might like to require some graphs they work with use some, but not all, of RDFS entailment, because their application requirements might not support literals in the subject position, which can be caused by rule rdfs4b.
An IRI the user's organization defines to specify this degree of entailment should be usable with sh:entailment, but then their SHACL processor would need to be made aware of the IRI.
If a shapes graph could declare that it satisfies an entailment, then this opens a way to demonstrate custom entailment regimes.
Say I have an entailment regime of just wanting rdfs:subPropertyOf expansion on IRI-identified properties.
@prefix ex: <http://example.org/shapes/> .
<http://example.org/rules/NamedSubProperty-as-SPARQL>
a owl:Ontology ;
rdfs:seeAlso <https://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules> ;
rdfs:seeAlso <https://www.w3.org/TR/rdf11-mt/#patterns-of-rdfs-entailment-informative> ;
# Suggested new property
sh:satisfiesEntailment <http://example.org/entailment/NamedSubProperty> ;
.
# A SHACL rule would be written here to implement just RDFS rule rdfs5 / OWL-RL rule prp-spo1.I could satisfy that custom entailment two ways, one using SPARQL Rules, one using Triple Rules (as currently described in the SHACL-AF document). These could be done in separate graphs, either of which could fully satisfy the custom entailment, and could be selected by the end user or processor based on known tuning for SPARQL or for rules.
Should the above be worked through with the Inferencing group?