W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

on recursion in SHACL

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 23 Sep 2016 10:00:42 -0700
To: public-rdf-shapes@w3.org
Message-ID: <ab287a21-51c9-c30f-2b38-23037a0cd3fd@gmail.com>
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
Received on Friday, 23 September 2016 17:01:16 UTC

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