W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > February 2017

RE: Comment on Entailment Regimes

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Fri, 17 Feb 2017 10:48:06 +0000
To: Holger Knublauch <holger@topquadrant.com>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D2BCABA@dnbf-ex1.AD.DDB.DE>
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.



> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC