- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 22 Feb 2006 20:29:55 +0000
- To: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
-------- 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