- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 17 Nov 2010 15:10:12 +0000
- 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: > > * CONCAT: > 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: 2010OctDec/0188.html 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. Andy
Received on Wednesday, 17 November 2010 15:10:50 UTC