[Fwd: SPARQL: arguments for built-in calls to generic?]

-------- Original Message --------
Subject: SPARQL: arguments for built-in calls to generic?
Date: Wed, 22 Feb 2006 15:46:35 +0100
From: Arjohn Kampman <arjohn.kampman@aduna.biz>
Organization: Aduna BV
To: public-rdf-dawg-comments@w3.org

 > Most of the built-in calls defined in the grammar in "[57] BuiltInCall"
 > operate on arguments of type Expression, which includes boolean and
 > mathematical operations. Most of these built-in calls, however, only
 > produce results when operating on IRIs, literals and/or blank nodes.
 > IMHO, it would be better to enforce this through the grammer, preventing
 > people from writing expressions that are correct syntactically, but not
 > semantically, like "lang( 3 + 4 )" and "isBlank(?var = foo:bar)".
 > Changing this production rule to the following should prevent such
 > expressions:
 >
 > FunctionOrVar ::= IRIrefOrFunction | Var
 >
 > BuiltInCall ::= 'STR' '(' FunctionOrVar ')'
 >               | 'LANG' '(' FunctionOrVar ')'
 >               | 'LANGMATCHES' '(' FunctionOrVar ',' String ')'
 >               | 'DATATYPE' '(' FunctionOrVar ')'
 >               | 'BOUND' '(' Var ')'
 >               | 'isIRI' '(' FunctionOrVar ')'
 >               | 'isURI' '(' FunctionOrVar ')'
 >               | 'isBLANK' '(' FunctionOrVar ')'
 >               | 'isLITERAL' '(' FunctionOrVar ')'
 >               | RegexExpression
 >
 > RegexExpression ::= 'REGEX' '(' FunctionOrVar ',' String ( ',' String )?
 > ')'
 >
 >
 > Considering that the spec is already in Last Call, I hope this comment
 > doesn't come too late.
 >
 > Regards,
 >
 > Arjohn

Arjohn suggests grammar changes to exclude some situations where evaluation is 
going to produce a type exception.

The changes aren't sufficient: sometimes a constant is legal and the kind of 
constant depends on the function.

datatype("foo"^^ex:type) is ex:type
isLiteral(<x>) is false.

and are currently legal (and can be evaluated at query compilation time).  So, 
for each FunctionOrVar it would be FunctionOrVarIRI, FunctionOrVarOrLiteral, 
and others in various combinations.

It would lead to changes in results of queries, albeit ones the human might 
spot anyway:

regex(?x, "abc") && LANG(<a>)  is currently true for ?x being a suitable plain 
literal or xsd:string.  It would become illegal.

At query evaluation time, the built-in functions would still need to handle 
mistyped values from variable bindings, expressions and particularly function 
calls.

BOUND already just takes a variable in the current grammar.


 > RegexExpression ::= 'REGEX' '(' FunctionOrVar ',' String ( ',' String )?
 > ')'

This is a noticable change.  The F&O equivalent function fn:matches does allow 
a variable in 2nd or 3rd positions.    I have seen REGEX used where the regex 
was in the data and the string to be matched was fixed.

 >               | 'LANGMATCHES' '(' FunctionOrVar ',' String ')'

again, a variable (or other expression) is permitted as second argument.


I don't see that there is sufficient value in addressing some cases of static 
type checking, enumerating the cases of which constants are possible, when 
other situations of type checking are allowed.  The built-in function 
implementations have to cope with the runtime situation of being passed the 
wrong type anyway.

Personally, I more worry about the introduction of an irregularity that makes 
building the query string programmatically harder.  For example, LANG(?x) is 
legal but substituting textually <abc> for ?x is not when at run time ?x might 
be bound to <abc> and so lang(?x) is called legally.


There is nothing to stop a query processor issuing warnings in situations it 
detects as being possibly wrong.

	Andy

Received on Wednesday, 22 February 2006 20:30:20 UTC