Policy for expression evaluation for call-by-URI.

[afs]

Now we have a populated /ns/sparql, all operators and functions in SPARQL can addressed whether there is a keyword or not.

Should they be callable? e.g. sparql:bound(expression).

At the moment they are not callable because of 17.2 Expression Evaluation - 3rd bullet.

[afs]

SHACL node expressions benefit from all functional-forms being callable as URIs.

At the time of writing, the working drafts are not yet on /TR/ but is viewable at raw.githack.com -- SHACL 1.2 Node Expressions.

SHACL node expression issue : w3c/data-shapes#455
SHACL node expression PR : w3c/data-shapes#511

[hartig]

At the moment they are not callable because of 17.2 Expression Evaluation - 3rd bullet.

Mmh. The 3rd bullet says the following.

Apart from the functional forms BOUND, COALESCE, IF, IN, NOT IN, logical-or (||), logical-and (&&), logical-not (!), NOT EXISTS, and EXISTS, all functions operate on RDF Terms and will produce a type error if any arguments are unbound.

It is not clear to me how this bullet makes them not callable. Andy, can you give me hint?

[Tpt]

It is not clear to me how this bullet makes them not callable.

I guess the issue is that following the bullet <http://www.w3.org/ns/sparql#bound>(?thisVariableDoesNotExist) will produce a type error whereas BOUND(?thisVariableDoesNotExist) returns false.

[hartig]

It is not clear to me how this bullet makes them not callable.

I guess the issue is that following the bullet <http://www.w3.org/ns/sparql#bound>(?thisVariableDoesNotExist) will produce a type error whereas BOUND(?thisVariableDoesNotExist) returns false.

If that's the issue, then this would mean that the IRI http://www.w3.org/ns/sparql#bound does not actually identify the functional form BOUND but, instead, identifies some function that is not defined in the spec, right?

The corresponding part of sparql-ns.ttl (i.e., lines 84-87) looks as follows.

sparql:bound rdf:type sparql:FunctionalForm ;
    rdfs:comment "This form checks whether a variable is bound (assigned a value) in the current solution." ;
    rdfs:isDefinedBy <http://www.w3.org/TR/sparql12-query/#func-bound> ;
    .

According to this, the IRI http://www.w3.org/ns/sparql#bound is supposed to identify the functional form BOUND.

I guess the issue is that, by Section 17.6 Extensible Value Testing, if an expression mentions a function by an IRI, it is assumed that this really is a function and not a functional form. In this sense, the 3rd bullet does indeed become relevant.

[rubensworks]

Should they be callable? e.g. sparql:bound(expression).

The benefit is clear to me (wrt SHACL), and I don't see a good reason why this can not be supported (for expressions).
Implementors basically only need to ensure there is a mapping between the URI and regular name of an expression.

Since all operators are also named by URI now, I wonder if these should also become callable? (e.g. {} sparql:union {})
This will have some bigger implications though (e.g. for parsing), so I wouldn't do it if there's a real need for it.

[TallTed]

@rubensworks —

I wouldn't do it if there's a real need for it

I think you meant, "I would do it only if there's a real need for it"

[rubensworks]

Ah indeed, that's a typo, thanks for the correction @TallTed.