- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 16 Mar 2010 09:25:38 -0400
- To: Marcelo Arenas <marcelo.arenas1@gmail.com>
- CC: Juan Sequeda <juanfederico@gmail.com>, public-rdb2rdf-wg@w3.org
On 3/16/2010 7:40 AM, Marcelo Arenas wrote: > On Tue, Mar 16, 2010 at 2:03 AM, Lee Feigenbaum<lee@thefigtrees.net> wrote: >> On 3/15/2010 11:55 AM, Marcelo Arenas wrote: >> >>>> + the ability to project expressions from queries rather than variables >>>> only >>> >>> I don't understand this functionality. Maybe Lee could gives us an >>> example of such a query. >> >> In SPARQL 1.0, the only thing that can be projected from a query are >> variables: >> >> SELECT ?var1 ?var2 ?var3 >> WHERE { >> ... ?var1 ... ?var2 ... ?var3 ... >> } >> >> In SPARQL 1.1, any expression can be projected into a result set: >> >> SELECT ?var1 (?var2 + 2 AS ?sum) (fn:myCrazyFunction(?var3) AS ?crazy) >> WHERE { >> ... ?var1 ... ?var2 ... ?var3 ... >> } >> >> Lee > > Thanks for the example, now the functionality is clear. Whether this > is expressible in FOL depends on the functions that are used. For > example, ?var1 + ?var2 AS ?sum is not expressible in FOL if + is not > part of the language; if + is not included as a built-in predicate (or > function) in non-recursive Datalog with safe negation, then the above > functionality of SPARQL 1.1 will not be expressible in the mapping > language. I still haven't read the papers that Juan cited, but I'm guessing then that a similar caveat was already true about the expressivity of SPARQL 1.0, given that FILTERs can make use of an extensible set of functions? I suppose just about any route we go for the mapping language will involve having to pick out a core set of functions/operators that can be used in transforming vales... Lee > > All the best, > > Marcelo >
Received on Tuesday, 16 March 2010 13:26:12 UTC