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

Re: rq25.xml String functions definitions - first shot (ACTION-350)

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 21 Dec 2010 14:52:19 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <30517498-FFCF-450E-9651-09179BBD8697@deri.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>, Steve Harris <steve.harris@garlik.com>
I see the following two options to go ahead:

1) allow PLWL as input, and then also return PLWL (ie applying encode() only to the lexical form and leaving lang tag untouched, i.e.
    encode_for_uri("Los Angeles"@en)  -->	"Los%20Angeles"@en
2) leave it "as is" i.e. require workaround encode(str()) for Steve's use case

Andy, would 1) work for you? 
Or, Steve, is the encode(str()) workaround sufficient for you to leave the def. "as is"? 

Axel (no particular preference)

On 21 Dec 2010, at 14:09, Andy Seaborne wrote:
> On 21/12/10 11:32, Steve Harris wrote:
> > Why should encode_for_uri("colour"@en-GB) be a type error?
> I'm reasonably neutral on this specific item but I'd like to address in
> terms of the overall style.  Adding str() is not much of a burden and
> elsewhere the argument has been made that casts and other functions are
> needed  (e.g. aggregates over unbounds).
> SPARQL 1.0 has regex(<uri>,..) is something that is quite common -
> SPARQL requires a STR().
> In other functions If the primary argument is a
> plain-literal-with-language (PLWL), other functions return a PLWL.

> The hash functions should defintiely distinguish simple literals and PLWL.
>         Andy
Received on Tuesday, 21 December 2010 14:52:50 UTC

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