Re: Different levels of SHACL

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
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 http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>