- 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