W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: Different levels of SHACL

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 24 Sep 2016 08:32:42 -0700
To: public-rdf-shapes@w3.org
Message-ID: <31abc815-f82c-ae94-994a-73ffe7a99577@kcoyle.net>


On 9/23/16 10:39 AM, Peter F. Patel-Schneider wrote:
> Yes, but is there the supported possibility of only implementing some of the
> SHACL Full constructs?  If so, which ones?

Are there other W3C standards with "levels" of conformance?

kc

>
> 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
>>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Saturday, 24 September 2016 15:33:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC