- From: Rob Vesse <rvesse@yarcdata.com>
- Date: Fri, 22 Jun 2012 17:42:57 +0000
- To: "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
- Message-ID: <CC09FCAE.1112A%rvesse@yarcdata.com>
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 17:43:22 UTC