Re: Proposal - Allow dynamic function calls in SPARQL 1.1

Hi Rob,

Thanks for the comment.

The WG discussed your suggestion and agrees that it would be a valuable 
addition to SPARQL. As you surmised, we're not going to be able to 
include it in the current round of standardization, however, so we did 
add it to the future items list at 
http://www.w3.org/2009/sparql/wiki/Future_Work_Items .

If you or any other vendors have experience implementing this feature, 
it would be great to learn about that either on this list or at 
public-sparql-dev@w3.org so that we can hopefully have implementers 
proceed along similar lines in advance of future standardization.

Please let us know if this response acknowledges your comment.

thanks,
Lee
On behalf of the SPARQL WG

On 6/22/2012 1:42 PM, Rob Vesse wrote:
> Hi All
>
> This comment/proposal was motivated by something interesting I saw 
> Paul Gearon tweet:
>
> "Sad that SPARQL defines [70] FunctionCall ::= iri ArgList instead of 
> [70] FunctionCall ::= VarOrIri ArgList so many missed opportunities!"
>
> I'm not sure if redefining like so is necessarily a good idea because 
> it may make the syntax a little more convoluted.   Also this change 
> only affects FILTERs where you'd probably want to make a more general 
> change in [118] PrimaryExpression to enable this everywhere.
>
> However I do see the potential value of his comment which is in 
> allowing the bindings generated so far to determine which functions 
> are actually called, particularly this has major benefits and uses in 
> rule based languages built on top of SPARQL such as SPIN.
>
> To this end I would like to propose a new built-in CALL which could be 
> defined as part of [120] Built In Call as 'CALL' ExpressionList
>
> The interpretation of the CALL function would be as follows:
>
>   * If there are no arguments then returns unbound
>   * If there are one/more argument treat the first argument as
>     identifying the function to be called and all remaining arguments
>     as the arguments to that function
>
> I would suggest that at a minimum compliant implementations must 
> accept first arguments whose values are URIs (when 
> expressions/variables are resolved to their values) as valid function 
> identifiers.  Extensions may treat literals and blank nodes as valid 
> function identifiers if they desire but I suspect it would be better 
> to explicitly forbid this.  The behavior in the event of an invalid 
> function identifier would be to give an error.
>
> I am fully aware that it is late in the day to be proposing new 
> features for the specification and so would be quite happy to accept 
> the WG just choosing to put this proposal on the future work list so 
> vendors can choose to implement it as a standard extension and have 
> this be considered for future rounds of standardization instead.
>
> Best Regards,
>
> Rob Vesse