W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2012

Re: Proposal - Allow dynamic function calls in SPARQL 1.1

From: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 23 Jun 2012 09:29:26 +1000
Message-ID: <4FE4FFD6.9000601@topquadrant.com>
To: public-rdf-dawg-comments@w3.org
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.


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
Received on Friday, 22 June 2012 23:30:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:12 UTC