- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 2 Oct 2016 05:21:59 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: "public-rdf-sha." <public-rdf-shapes@w3.org>
OK. That change removes: Recursive use of functions is undefined: If a SPARQL-based function contains calls to other functions so that the same function with the same combination of parameters would be visited twice then the result of the function call is undefined. An implementation may either return no result (unbound) or terminate the surrounding SPARQL query with an error. so that now this would, I guess, require that such situations cause infinite recursion. Does the working group as a whole accept this substantive change to SHACL? Peter F. Patel-Schneider Nuance Communications On 10/02/2016 05:15 AM, Dimitris Kontokostas wrote: > Correct, it was on the "on undefined in SHACL" thread > https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Sep/0062.html > > On Sat, Oct 1, 2016 at 11:46 PM, Peter F. Patel-Schneider > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > I was wondering which email from Holger is related to the original message I > sent. You state there is one in the sentence I copied just below without > saying which one it is. > > > Your comments for recursion on section 9.4 were addressed by Holger in a > separate email > > peter > > > On 10/01/2016 01:38 PM, Dimitris Kontokostas wrote: > > Hi Peter, > > > > I am not sure to which comment you refer to here. > > > > Thanks, > > Dimitris > > > > On Sat, Oct 1, 2016 at 6:32 PM, Peter F. Patel-Schneider > > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote: > > > > Could your provide a pointer to the message from Holger so that the full > > record of this comment is retained? > > > > Thanks, > > > > peter > > > > > > On 09/26/2016 02:17 AM, Dimitris Kontokostas wrote: > > > Thanks for your feedback Peter, > > > > > > I moved > > > > > <https://github.com/w3c/data-shapes/commit/f80725b162937683cc2f8aaecf497f2e0a3339c8 > <https://github.com/w3c/data-shapes/commit/f80725b162937683cc2f8aaecf497f2e0a3339c8> > > <https://github.com/w3c/data-shapes/commit/f80725b162937683cc2f8aaecf497f2e0a3339c8 > <https://github.com/w3c/data-shapes/commit/f80725b162937683cc2f8aaecf497f2e0a3339c8>>> > > > the recursion definition to section 3.1.1 and adjusted the definitions a bit. > > > I also made a request to revisit issue-22 since property paths already provide > > > an easy way to define recursion in SHACL > > > https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0054.html > <https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0054.html> > > <https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0054.html > <https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0054.html>> > > > > > > Your comments for recursion on section 9.4 were addressed by Holger in a > > > separate email > > > > > > Let me know if this resolves your issue > > > Dimitris > > > > > > On Fri, Sep 23, 2016 at 8:00 PM, Peter F. Patel-Schneider > > > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> > > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>>> wrote: > > > > > > Following up one of the recent responses to my comments on Shapes > > Constraint > > > Language (SHACL) lead me to look at how recursion works in Shapes > > Constraint > > > Language (SHACL), W3C Editor's Draft 22 September 2016. > > > > > > > > > Here is the initial discussion of recursion, from Section 4.8.1. > > > > > > "A shape may refer to itself directly or indirectly via sh:shape, > > > sh:filterShape, etc. Such a shape is said to be recursive. The > > meaning of > > > non-recursive shapes is always well-founded. In contrast, the > > meaning of a > > > recursive shape may not be well-founded. The handling of recursive > > shapes in > > > SHACL is left to implementations. Some implementations MAY > reject shapes > > > graphs containing recursive shape definitions. Some > implementations MAY > > > report a failure if a recursion has been detected at > validation time." > > > > > > This is the wrong place for the initial discussion of > recursion. First, > > > sh:filterShape was discussed much earlier, in Section 2.2. > Second, the > > > discussion of recursion deserves not to be buried within the > > discussion of > > > sh:shape. > > > > > > The definition of recursive shapes is much too sloppy. What is > > covered by > > > the "etc."? Is > > > s:s1 rdf:type sh:Shape ; > > > rdfs:comment s:s1 . > > > a recursive shape? > > > > > > What is the process for rejecting a shape graph containing > recursive > > shape > > > definitions? The term "reject" occurs only in this one place. > > > > > > What does well-founded mean here? > > > > > > The meaning of "a recursion has been detected at validation > time" has > > > several problems. Validation time is not defined. What counts as > > detecting > > > a recursion is not defined. > > > > > > > > > > > > Here is another aspect of recursion in SHACL, from Section 9.4. > > > > > > "Recursive use of functions is undefined: If a SPARQL-based > function > > > contains calls to other functions so that the same function > with the > > same > > > combination of parameters would be visited twice then the > result of the > > > function call is undefined. An implementation may either return no > > result > > > (unbound) or terminate the surrounding SPARQL query with an > error." > > > > > > It is not that all recursive use of functions is undefined. > What is > > > undefined here by the more detailed description is a call to > the same > > > function and with the same parameters within another call. It > > appears that > > > this is an attempt to prevent infinite recursion. Such calls, > > however, need > > > not lead to infinite recursion if uncaught, even in a limited > > language like > > > SPARQL. Nor is it that all cases of infinite recursion > involve calls of > > > this sort. As detecting such calls is neither necessary nor > > sufficient to > > > prevent infinite recursion it is puzzling as to why a complex and > > > potentially expensive mechanism is being described, and maybe even > > mandated. > > > > > > > > > Peter F. Patel-Schneider > > > Nuance Communications > > > > > > > > > > > > > > > > > > -- > > > Dimitris Kontokostas > > > Department of Computer Science, University of Leipzig & DBpedia > Association > > > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > > http://aligned-project.eu > > > Homepage: http://aksw.org/DimitrisKontokostas > <http://aksw.org/DimitrisKontokostas> > > <http://aksw.org/DimitrisKontokostas > <http://aksw.org/DimitrisKontokostas>> > > > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > > > > > > > > > > > -- > > Dimitris Kontokostas > > Department of Computer Science, University of Leipzig & DBpedia Association > > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://aligned-project.eu > > Homepage: http://aksw.org/DimitrisKontokostas > <http://aksw.org/DimitrisKontokostas> > > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > > > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu > Homepage: http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT >
Received on Sunday, 2 October 2016 12:22:30 UTC