W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: what functions should we include in SPARQL 1.1?

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 10 Nov 2010 09:05:16 +0000
Message-ID: <4CDA604C.6010400@epimorphics.com>
To: Axel Polleres <axel.polleres@deri.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>


On 09/11/10 23:24, Axel Polleres wrote:
>
> On 10 Nov 2010, at 04:02, Andy Seaborne wrote:
>
>>
>>
>> On 09/11/10 17:42, Axel Polleres wrote:
>>>>>     which we may want to reuse, or should we uniformly refer to the
>>>>>
>>>>>        http://www.w3.org/2009/sparql-functions#
>>>>>
>>>>>     for all functions (also the xs: ones?
>>>>
>>>> Reuse where possible.
>>>
>>> Remembering that we had this discussion partly before, one argument against reuse and for uniformly using a single
>>> namespace was that this single namespace would indicate exactly the interchangeable functions within the SPARQL1.1 spec
>>> and that these functions then would be usable without a namespace prefix as simple keywords of the language.
>>
>> Must have missed that - I don't recall a proposal to make the names
>> keywords in the language for all mandatory functions from F&O - is the
>> proposal to add new keywords for all required functions, then map to
>> IRIs (sparqlfn:) and owl:sameAs to fn:.
>
> that'd work for me.

It was a question - is that the proposal you are making?  It's not 
support - when there is a detailed proposal on the table I'll decide.

I don't recall it coming up before and I don't understand the argument 
for adding more keywords to the language (it's a grammar change albeit 
with no issues arising). An open set of keywords based on prefixless 
usage is a problem for the grammar, e.g. function called "select".

Using the same URIs if it means the same thing makes more sense to me 
but the net effect of your proposal is that I-as-implementer will have 
to add IRIs both ways round.

Since sparqlfn: will not be needed (if there are SPARQL-unique 
functions, they have keywords so you don't need IRIs anyway), the 
argument for one namespace does not work for me.  If an implementation 
adds an extra fn: not in the required set, then doe sit also appear in 
sparqlfn: - presumably not but then the app writer sees fn: but not 
sparqlfn:.

It will be a bit more diffcult to work with service descriptions if 
inference is needed.  Leigh Dodds' survey uses use of fn: and of 
per-system naming.  The expecations of all fn: have not arisen in my 
experience in practice - documentation helps: 
http://openjena.org/ARQ/library-function.html

	Andy

>
> Axel
>
>>
>>          Andy
>>
>> PS
>> http://spreadsheets.google.com/pub?key=0AkNZYESXv3IndGwyRkRXZ2hES0RjM0c3MHhLa05vTmc&gid=0
>>
>
>
Received on Wednesday, 10 November 2010 09:05:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT