Re: Proposal - Allow dynamic function calls in SPARQL 1.1

Thanks Lee

Yes this answers my comments

Rob

From: Lee Feigenbaum <lee@thefigtrees.net<mailto:lee@thefigtrees.net>>
Date: Tuesday, July 10, 2012 7:31 AM
To: Cray Employee <rvesse@yarcdata.com<mailto:rvesse@yarcdata.com>>
Cc: "public-rdf-dawg-comments@w3.org<mailto:public-rdf-dawg-comments@w3.org>" <public-rdf-dawg-comments@w3.org<mailto:public-rdf-dawg-comments@w3.org>>
Subject: 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<mailto: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