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

Re: function library summary and issues

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 17 Nov 2010 15:10:12 +0000
Message-ID: <4CE3F054.900@epimorphics.com>
To: Axel Polleres <axel.polleres@deri.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>

On 16/11/10 18:33, Axel Polleres wrote:
> Hi all,
> we only started to discuss function library today, so let me try to summarise:
> We aim to include:
> 1) the functions/operators already there in the query draft in sections 17.4.1 - 17.4.24
> 2) the fn: functions and operators from Lee's mail, cf. http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0188.html
> 3) Rand() as per steve's mail
> Side issues around that which I am aware of:
>    cf. http://www.w3.org/2009/sparql/meeting/2010-11-16#line0289
>    As for 2) there were some discussions about concat still, with three alternatives:
>    - take fn:concat "as is" i.e. only accepting xs:AtomicTypes castable to xs:string
>    - define our own, which would only allow strings

Clarification question: allow only simple literals?

>    - define our own, along with implicit use of STR() on the arguments

Specifically, what do we want to happen for:

PREFIX ex: <http://example/ns#>

fn:concat(ex:, "foo") --> ???

> * URIs/namespaces:
>    cf. http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0242.html
>    How about the URIs for the functions we recommend?

Did you mean "define", not "recommend"?  We should provide an IRI for 
each keyword-function.  These are in the spec and required.

>    - do we define a new namespace for all new functions (which is the default, i.e. makes fnsparql: functions usable without the prefix)?

Mixes two things, confused by the fact there are is only a need for IRIs 
for functions that already have a keywords for them.

Yes to a namespace.

No to a general, open ended mechanism beyond that for fnsparql: callable 
without prefix name or IRI.  (messes up the grammar - e.g. select(?x, ?y) )

>    - can we define a "namespace profile" a la RDFa?

Not completely clear to me what is proposed.

Queries should be self contained and not require a query processor go 
out to the web to resolve a profile, nor have profiles hardwired.

> * Do we want to adopt/re-use more RIF functions?
>    cf. http://www.w3.org/TR/rif-dtb/

Are you proposing more functions be added to the list in:

If so, which? And for each, same definition or similar functional (our 
IRI) but done in an XSD compatibility way?

I thought your argument for RIF having it's own namespace was that the 
evaluation model was different from XSD.

Received on Wednesday, 17 November 2010 15:10:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:02 UTC