- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 24 Sep 2016 18:37:53 -0700
- To: "public-rdf-sha." <public-rdf-shapes@w3.org>
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