Re: Different levels of SHACL

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> 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/e198bc9689c95e89e8
> caeb8c3c787b9efa579856
> >>
> >> 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
> >
>
>