W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

RE: [JavaScriptFunctions] any WG implementations / advocacy?

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 26 Mar 2009 13:17:49 +0000
To: Ivan Mikhailov <imikhailov@openlinksw.com>, Lee Feigenbaum <lee@thefigtrees.net>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3628DBCB8D4@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Ivan Mikhailov
> Sent: 26 March 2009 06:50
> To: Lee Feigenbaum
> Cc: SPARQL Working Group
> Subject: Re: [JavaScriptFunctions] any WG implementations / advocacy?
> Lee,
> My vote is -1 even if Virtuoso will support extended JavaScript in
> version 7. (More correctly, Virtuoso/PL will be extended in such a way
> that it will become a superset of JavaScript.)
> The reason is that we have no time to extend JavaScript spec with
> RDF-specific types and operators, including SPARQL invocation BTW. And
> even if we extend, the resulting language will require new runtime,
> blocking "two independent implementations".

I agree with this reasoning.

> What we can is 1) to note that there's a possibility in a distant
> future, so at least SPARQL syntax and keywords should not conflict with
> JavaScript, to make the future integration "peaceful" and 2) to mention
> some place like ESW wiki page as a placeholder for future proposals.
> Cheap and non-normative.
> Best Regards,
> Ivan.

As a matter of completeness in getting potential features covered: 

We have the necessary spec mechanism to attach extension code in FILTERs with URIs for function calls.  What is missing is the same spec framework (syntax, evaluation integration) for arbitrary code (c.f. stored procedures).  Defining the language API is much too large, but the same level of support as FILETR functions in the language might be 

Property functions are a way to do it but they are squeezing a mechanism into the existing syntax and they are limited in that the arguments can't be a graph pattern.  They are an odd way to write "CALL <uri>(a,b,c)" and return a table, just done so as to be syntax-compatible and in a style that is "RDF-ish".

More general would be 

  CALL <uri> {?s ?p ?o} (a,b,c)

to allow a graph pattern to be part of the arguments.
c.f. Feature:ControlOfInference applied to parts of a query.

Assignment involving calls to expression functions is also a small part of this.

(I am not offering to champion this.)

Received on Thursday, 26 March 2009 13:19:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC