Re: what functions should we include in SPARQL 1.1?

> >   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. I also think 
that would make it simpler, in terms of that it might not be clear upfront which XPath/XQuery functions are supposed to be supported and which aren't, i.e. 
I am worried the recommendation of *some* fn: functions might be misunderstood that all fn: functions are to be supported, even if we explain the contrary 
it explicitly in the document. A fixed set of URIs in the SPARQL namespace (which can be left sounds more compelling to me, and IMO is easier to explain to users. 
BTW, that wouldn't preclude that some of the sparqlfn: URIs just redirect to fn: URIs, right?

If I remember correctly, Andy was more for keeping the XPath prefixes where possible, whereas, given the above arguments, I was more leaning
towards a single namespace for the set of SPARQL1.1 recommended functions. (Other) opinions?

Axel

On 8 Nov 2010, at 04:28, Andy Seaborne wrote:

> 
> 
> On 07/11/10 18:18, Axel Polleres wrote:
> > 1) As a *very minor* editorial issue, I think we should follow a uniform capitalisation of function names in the doc, cf.
> >
> > 16.4.22 STRDT
> >
> > vs.
> >
> > 16.4.6 str
> >
> > or is their a rationale behind different capitalisation here that I overlooked?
> 
> Noted.
> 
> 
> > 2) another minor comment, there are URIs for
> >
> >   STRLANG
> >
> >   -->  http://www.w3.org/TR/rdf-plain-literal/#plfn:PlainLiteral-from-string-lang
> 
> No. The return type is rdf:PlainLiteral.
> 
> The RDF namespace has been contaminated with a type that should not
> appear in an RDF document.  We should not worsen the situation.
> 
> The lexical form for rdf:PlainLiteral is singularly unhelpful and would
> require a change to SPARQL 1.0 to make str() work in anyway that is useful.
> 
> It is a shame that the language tag is handled by encoding into the
> lexical form, making a double layering and necessitating addition
> functions to undo the encoding, rather than defining value spaces for
> each language and having a lexical form in that language.
> 
> >   LANG
> >
> >   -->  http://www.w3.org/TR/rdf-plain-literal/#plfn:lang-from-PlainLiteral
> 
> No. The first arg of that function is an rdf:PlainLiteral. The return is
> xs:language, not a simple literal.
> 
> xs:language is not in "XML Schema Part 2: Datatypes Second Edition",
> only XSD 1.1, which is not yet a REC.
> 
> >   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.
> 
> regex is fn:matches (modulo the xs:string/simple literal thing).
> 
> Other builtins by keyword are all be necessary additions, I think, and
> need IRIs.
> 
> The operators are different because they are an extension point - an
> implementation can add new dispatches for errors.  That's how it's legal
> to have xsd:date support.  So you can't define the signature as a
> function.  While some symbol operators dispatched straight to XSD
> functions ("*", "/", "+", "-"), others go to different functions. e.g.
> This is significant for "=" and "!=" which end up at different XSD
> functions.
> 
>         Andy
> 
> >
> >
> > Axel
> >
> >
> > On 4 Nov 2010, at 01:34, Andy Seaborne wrote:
> >
> >>
> >>
> >> On 03/11/10 17:25, Paul Gearon wrote:
> >>> On Wed, Nov 3, 2010 at 10:39 AM, Paul Gearon<gearon@ieee.org>   wrote:
> >>> <snip/>
> >>>> Math/Logic
> >>>> Many of these are already covered, but I'd like to see:
> >>>>   if(cond, true-expr, false-expr)
> >>>> I believe this is already possible, but an if() function makes certain
> >>>> tasks much easier.
> >>>
> >>> Sorry, I forgot that IF has been included in the builtins already.
> >>> It's not documented yet, but I presume that it operates as I remember:
> >>>    http://www.w3.org/TR/2010/WD-sparql11-query-20100601/#func-if
> >>>
> >>> So please ignore that part of my earlier email.
> >>>
> >>> Regards,
> >>> Paul
> >>>
> >>
> >> Wrong version: http://www.w3.org/TR/2010/WD-sparql11-query-20101014/
> >>
> >> See
> >>
> >> http://www.w3.org/TR/sparql11-query/#func-if
> >>
> >> We should charge for saying "it's not done yet" - pay in HTML content to include.
> >>
> >>      Andy
> >>
> >>
> >
> >
>

Received on Tuesday, 9 November 2010 17:43:36 UTC