Different levels of SHACL (was: Quick Comments on https://www.w3.org/TR/2016/WD-shacl-20160814/)

On 23/09/2016 11:36, Peter F. Patel-Schneider wrote:
>
>> different levels of SHACL implementation
>>
>> There are several different kinds of SHACL implementations that are hinted
> at in the document.
>> "SHACL implementations may, but are not required to, support entailment
> regimes." "Access to the shapes graph is not a requirement for supporting
> the SHACL Core language." "This sections [sic] defines the built-in SHACL
> constraint components that MUST be supported by all SHACL validation
> engines." "Not all SHACL validation engines need to support this variable."
> "The same support policies as for $shapesGraph apply for this variable."
> "SPARQL engines with full SHACL support can install a new SPARQL function
> based on the SPARQL 1.1 Extensible Value Testing mechanism." "SHACL
> validation engines are not required to support any entailment regimes."
> "SHACL implementations with full support of the SHACL SPARQL extension
> mechanism must implement a function sh:hasShape, ...." "A SHACL validation
> engine MUST implement all constructs in the Core of SHACL (Sections 2, 3,
> 4). A SHACL engine MAY not implement the other parts of SHACL."
> "Implementations that cover only the the SHACL Core features are not
> required to implement these mechanisms or the sh:hasShape function." "SHACL
> validation engines MAY pre-bind the variable $shapesGraph to provide access
> to the shapes graph." "A SHACL validation engine MAY use such suggestions to
> determine which shapes graph to use for validating a data graph." "A SHACL
> validation engine MAY take this information into account to determine which
> shapes graph to use for validating a data graph that uses that ontology or
> vocabulary."
>> There needs to be a section that explicitly defines the different levels
> of implementation.
>>      Comment (HK): Not sure what to do about this. There is an almost
> infinite amount of combinations of these above, so one could define many
> dialects. But only one of them is the full SHACL. I would prefer all SHACL
> engines to support all these features but there was too much resistance,
> e.g. from those favoring a single-query-code-generation approach or working
> against SPARQL end points. The resulting mess is reflecting the
> heterogeneous nature of the SPARQL universe, whether we want it or not.
>>      Comment (DK): What if we created a section at the end of part II
> called "Optional features of the SHACL SPARQL extension mechanism" (or
> something similar) where we list all option features
>>      Comment (HK): Ok, I have added an appendix with the goal of
> enumerating all optional features. Could you double check this:
> https://github.com/w3c/data-shapes/commit/e198bc9689c95e89e8caeb8c3c787b9efa579856
>
> This does not appear to address my concerns.  How many different levels of
> SHACL implementation are there?  For examples, can a SHACL implementation
> implement SPARQL-based constraints but not access to the shapes graph, or
> some other random set of the optional parts of SHACL?

We have meanwhile added more prose to clarify that SHACL consists of 
SHACL Full and SHACL Core, see the end of the Terminology section in the 
current draft:

SHACL Code and SHACL Full
The SHACL specification is divided into two dialects.SHACL Coreconsists 
of frequently needed features for the representation of shapes, 
constraints and targets. All SHACL implementations must at least cover 
the Core.SHACL Fullconsists of all features of SHACL Core plus a 
collection of advanced features including SPARQL-based constraints, 
extension mechanisms to define new constraint and target types, 
user-defined functions and derived properties.


So, to answer your question, there are 2 levels of SHACL 
implementations. An implementation that does for example implement 
SPARQL based constraints but not the access to the shapes graph is still 
in SHACL Full. An engine that does support shapes graphs access would be 
in an extended space just like any engine that adds new SPARQL 
functions, OWL reasoning or whatever.

What else would need to be said on this topic to clarify this?

Holger