Re: Proposal - Allow dynamic function calls in SPARQL 1.1

Just a +1 from here. We have a built-in spif:invoke(?function, args...) 
in the TopBraid libraries that performs the same role as Rob suggests. 
Would be good to have this standardized instead.

Thanks,
Holger


On 6/23/2012 3:42, 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