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 18:37:53 -0700
To: "public-rdf-sha." <public-rdf-shapes@w3.org>
Message-ID: <3a91c9b5-d920-d5fe-c90f-228fa56fcef6@kcoyle.net>
Thanks, Dimitris. I was looking for an example to see how conformance is 
worded. I'll have a look at the OWL profiles.

kc

On 9/24/16 1:35 PM, Dimitris Kontokostas wrote:
> On Sep 24, 2016 18:32, "Karen Coyle" <kcoyle@kcoyle.net
> <mailto: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 the
>>> 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.
>
> Dimitris
>
>>
>> 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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>> m: 1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Sunday, 25 September 2016 01:38:25 UTC

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