Re: on recursion in SHACL

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>> 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>>
>     > 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>
>     >
>     > 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>>> 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>
>     > 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 Saturday, 1 October 2016 20:46:55 UTC