- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 21 Dec 2010 14:52:19 +0000
- To: Andy Seaborne <andy.seaborne@epimorphics.com>, Steve Harris <steve.harris@garlik.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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