[CLOSED] Re: SPARQL: arguments for built-in calls to generic? [OK?]

Seaborne, Andy wrote:
> 
> 
> Arjohn Kampman wrote:
>> 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,
> 
> I forwarded this to the working group with some discussion:
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0418.html
> 
> The working group discussed this but there was no enthusiasm for such a 
> change.
> 
> For the query writer, trying to give some type safety at this one point 
> when there is no just assurance from elsewhere in the grammar, did not 
> seem like a significantly useful change.  The grammar would be 
> noticeable more complicated because it isn't just FunctionOrVar each 
> time but FunctionOrVar + appropriate kind of literal.
> 
> For the implementer, these built-ins still have to be able to deal with 
> the full set of RDF terms being passed to one of the built-ins.
> 
> Any implementation can choose to issue warnings for this situation, or 
> any other construction in a query, that the implementer wishes to bring 
> to the application writer's attention.  Such a pass over the query after 
> parsing is a  common way to do this rather than in the parser.
> 
> 
> I hope this addresses your comment - please let us know if it does.  You 
> can help our issue tracking system by prefixing the subject of your
> response with [CLOSED] (where this subject has [OK?]).

I understand the time constraints, therefor [CLOSED]. My only worry is
that, as the grammar leaves everything wide open, query optimization
becomes a lot more complex. To name just one example: with the current
grammar even the flags for a REGEX can be a variable. I don't quite see
the use case for such a thing.

Regards,

Arjohn Kampman

-- 
arjohn.kampman@aduna.biz
Aduna BV - http://aduna.biz/
Prinses Julianaplein 14-b, 3817 CS Amersfoort, The Netherlands
tel. +31-(0)33-4659987

Received on Wednesday, 15 March 2006 14:28:54 UTC