Re: Different levels of SHACL

Yes, but is there the supported possibility of only implementing some of the
SHACL Full constructs?  If so, which ones?

peter


On 09/22/2016 10:04 PM, Holger Knublauch wrote:
> 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 Core consists of
> frequently needed features for the representation of shapes, constraints and
> targets. All SHACL implementations must at least cover the Core. SHACL
> Full consists 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
>

Received on Friday, 23 September 2016 17:39:57 UTC