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: Alexandre Passant <alexandre.passant@deri.org>
Date: Thu, 11 Nov 2010 07:58:14 +0800
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
Message-Id: <148F2C58-D190-433E-868E-F9EB9A381D8F@deri.org>
To: Axel Polleres <axel.polleres@deri.org>

On 11 Nov 2010, at 01:14, Axel Polleres wrote:

> 
> On 10 Nov 2010, at 17:05, Andy Seaborne wrote:
> 
>> 
>> 
>> 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?
> 
> Yes. 
> 
> 1) owl:sameAs is one possiblity. 
> We could describe such things in the sparqlfn: namespace document, right?
> 
> 2) Alternatively/additionally we could also redirect that URI to the fn: one.
> To be discussed.
> 
> 3) this one is more speculative... could we also do something similar to RDFa's namespace profiles?
>   (this is more a question than a proposal so far, because I don't know/understand that mechanism well enough yet)
> 

Good idea, and that would be nice if we can use term mappings in similar profiles.
(e.g. fooBar rather than having to check if thats fn:fooBar, sparql:fooBar or myRDFStore:fooBar) 
If not, we'll still have 2 URI prefixes.

Alex.

> 
> 
>> 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".
> 
> It's simply weird for users IMO, if they have to use prefixes for some 
> of the default supported functions, but not for others.
> 
> best,
> Axel
> 
> 
>> 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
>>>> 
>>> 
>>> 
>> 
> 
> 

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Received on Wednesday, 10 November 2010 23:58:55 GMT

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