RE: Comment on Entailment Regimes

Hello Holger,

On Friday, February 17, 2017 5:19 AM, Holger Knublauch [mailto:holger@topquadrant.com] wrote:

> Your description of the situation is correct. As you have suggested, I
> have moved the Appendix A into section 1.5, see
> 
> https://github.com/w3c/data-

> shapes/commit/a98a3e54d17f15418dde487198d0462af02c68b6
> 
> The reason why it ended up in an appendix in the first place was that we
> felt it neither belonged into SHACL Core nor SHACL-SPARQL. But it does
> indeed belong into both, and I agree that that flow has improved now. On
> this occasion I have also added the formal syntax rule for
> sh:entailment's node kind and have attempted to address the question
> about multiple values. The intent of the current prose is to indicate
> that all inferred triples must be present for all entailment regimes.
> 
> If you have further suggestions on this aspect, please suggest specific
> changes to the wording. If you have further comments on other topics
> (good or bad), please keep them coming.

I have one small change proposal. In the last paragraph of §1.5 it says:

[[
Otherwise, the SHACL processor MUST provide the entailments for any of the values of sh:entailment in the shapes graph, [...]
]].

I'd propose to change this to
[[
Otherwise, the SHACL processor MUST provide the entailments for all of the values of sh:entailment in the shapes graph, [...]
]]

I'm not a native speaker of English, but to me saying "all of the values" feels better than "any of the values", the latter somewhat implying that the processor can just pick one.

Best,

Lars

> 
> On 16/02/2017 19:25, Svensson, Lars wrote:
> > Hello all,
> >
> > Looking at the current editor's draft [1] I have a question / comment on the use of
> entailment in SHACL processing.
> >
> > §1.5 [2] states normatively that "SHACL uses the RDF and RDFS vocabularies, but
> full RDFS inferencing is not required" and then goes on _non-normatively_ to talk about
> the property sh:entailment and how SHACL processors may support RDFS entailment
> (or any other kind of entailment).
> >
> > When I first read this, I felt confused since the normative part says that RDFS
> inferencing is not required but that SHACL processors MAY support it, leaving me
> wondering if that meant that different processors might come to different results
> depending on whether they support inferencing or not. The answer came further down
> in Appendix A [3] where it is stated that "if an entailment regime is provided in the
> shapes graph which is not supported by the SHACL processor, the validation MUST
> produce a failure" which is clear enough.
> >
> > I would find it easier for the reader, though, if you would remove Appendix A and
> move its contents to §1.5 so that you have all the information about entailment in one
> place. Further, there seems to be no formal definition of sh:entailment in the
> document. The property is only mentioned in the non-normative part of §1.5 and in
> Appendix A (which I don't know if it's normative or not: Are appendices normative?). I
> guess that it is (theoretically) possible to ask the SHACL processor to use more than
> one entailment regime (e. g. RDFS [4] and D-entailment [5]) but that the support of
> that is implementation-specific. It would help, though, if there were a (non-normative)
> note about that in the spec, too.
> >
> > [1] https://w3c.github.io/data-shapes/shacl/

> > [2] https://w3c.github.io/data-shapes/shacl/#shacl-rdfs

> > [3] https://w3c.github.io/data-shapes/shacl/#entailment

> > [4] https://www.w3.org/TR/sparql11-entailment/#RDFSEntRegime

> > [5] https://www.w3.org/TR/sparql11-entailment/#DEntRegime

> >
> > Thanks,
> >
> > Lars
> >
> > *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
>

Received on Friday, 17 February 2017 10:48:42 UTC