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

on undefined in SHACL

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 23 Sep 2016 10:01:37 -0700
To: public-rdf-shapes@w3.org
Message-ID: <6a2293ca-b663-2cf9-609b-6ac0274539b6@gmail.com>
Following up one of the recent responses to my comments on Shapes Constraint
Language (SHACL) lead me to look at how undefined works in Shapes Constraint
Language (SHACL), W3C Editor's Draft 22 September 2016.

Undefined is used in two places in the SHACL document.

In Section 9.4, for functions:

"For ASK queries, the function's return value is the result of the ASK query
execution, i.e. true or false. For SELECT queries, the function's return
value is the binding of the (single) result variable of the first row in the
result set. Since all other bindings will be ignored, such SELECT queries
SHOULD only return a single result variable and at most one row.
Also note that the result variable may be unbound, making the return value
of the function undefined.

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."

The first bit about ASK-based functions means that these functions cannot
have an undefined value.  This goes counter to the detection of infinite
recursion that appears to be required for functions.

In Appendix A, for sh:hasShape

"None of the parameters can be unbound. The result of the sh:hasShape
function is either true, false or undefined:
- [...]
- undefined if during the execution a failure has been reported. This result
indicates a failure. Implementations MAY for example use this to report
infinite recursion."

sh:hasShape is a SPARQL function.  SPARQL functions do not return undefined.

Peter F. Patel-Schneider
Nuance Communications
Received on Friday, 23 September 2016 17:02:09 UTC

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