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

Re: Different levels of SHACL

From: Dimitris Kontokostas <jimkont@gmail.com>
Date: Sat, 24 Sep 2016 23:35:58 +0300
Message-ID: <CA+u4+a1VjLP1mFDjAsWdrOgD0owFDpAoEJAD21=dvvq6_OvqOg@mail.gmail.com>
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: "public-rdf-sha." <public-rdf-shapes@w3.org>
On Sep 24, 2016 18:32, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
> On 9/23/16 10:39 AM, Peter F. Patel-Schneider wrote:
>> Yes, but is there the supported possibility of only implementing some of
>> SHACL Full constructs?  If so, which ones?
> Are there other W3C standards with "levels" of conformance?

It might not be directly comparable but I am only aware of OWL that defines
3 (sub) profiles El, RL and QL.

However, OWL defines OWL full in one document and all the sub profiles in a
separate document.


> 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
>>>> at in the document.
>>>>> "SHACL implementations may, but are not required to, support
>>>> regimes." "Access to the shapes graph is not a requirement for
>>>> the SHACL Core language." "This sections [sic] defines the built-in
>>>> constraint components that MUST be supported by all SHACL validation
>>>> engines." "Not all SHACL validation engines need to support this
>>>> "The same support policies as for $shapesGraph apply for this
>>>> "SPARQL engines with full SHACL support can install a new SPARQL
>>>> 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
>>>> engine MUST implement all constructs in the Core of SHACL (Sections 2,
>>>> 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."
>>>> validation engines MAY pre-bind the variable $shapesGraph to provide
>>>> 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
>>>> validation engine MAY take this information into account to determine
>>>> 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
>>>> 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
>>>> dialects. But only one of them is the full SHACL. I would prefer all
>>>> engines to support all these features but there was too much
>>>> e.g. from those favoring a single-query-code-generation approach or
>>>> 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:
>>>> This does not appear to address my concerns.  How many different
levels of
>>>> SHACL implementation are there?  For examples, can a SHACL
>>>> implement SPARQL-based constraints but not access to the shapes graph,
>>>> some other random set of the optional parts of SHACL?
>>> We have meanwhile added more prose to clarify that SHACL consists of
>>> 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
>>> features including SPARQL-based constraints, extension mechanisms to
>>> new constraint and target types, user-defined functions and derived
>>> So, to answer your question, there are 2 levels of SHACL
implementations. An
>>> implementation that does for example implement SPARQL based constraints
>>> 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 20:36:28 UTC

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