Re: Different levels of SHACL (and a new undefined notion and misuse of MAY)

There are quite a few optional ways to do things, but the only optional
features appear to be access to the shapes graph (which is still in a mess as
far as I can tell), accessing other graphs, parameter type checking, and
recursion.

The conformance section looks better, but there is no definition of what
"validation in the SHACL ... Language" actually is.

I did notice that "point to one or more graphs" is undefined.  This needs to
be fixed.

The MAY in 4.8.3 needs to be converted to may.  Even better would be to
convert it to some other word.  Similarly for the MAY in 4.10.

peter


On 09/24/2016 06:54 AM, Dimitris Kontokostas wrote:
> Hi Peter and thanks again for your feedback,
> 
> I removed
> <https://github.com/w3c/data-shapes/commit/d4b64fda059c16d8b41554bdae4873e68e1229b6>
> the "List of Optional SHACL Features and Dialects" section, Although it seemed
> like a good idea at fist creates some confusion and duplication
> The conformance section (still draft) specifies that 
> - part A defines all features for SHACL Core and SHACL Core processors and
> - part B defines all features for SHACL Full and SHACL Full processors.
> Optional features for Core/Full are specified within the spec with MAY/SHOULD
> or prose etc
> Would this be sufficient?
> 
> I would also welcome any feedback you have for the conformance section.
> 
> Thanks,
> Dimitris
> 
> On Friday, September 23, 2016, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     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
>     <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 Saturday, 24 September 2016 21:57:53 UTC