- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 21 Dec 2010 14:49:34 +0000
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 2010-12-21, 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).
Aggregates over unbounds is really a side effect of the fact that evaluation of an unbound is an error. I don't think it's ideal, but it would be quite messy to define an alternative evaluation semantic for aggregates.
There's an analogy around e.g. Sum({"12", 12}) and Sum({"twelve", 12}), but I feel that there's potentially a genuine source of errors there, which isn't the case in URI encoding literals with language tags.
> SPARQL 1.0 has regex(<uri>,..) is something that is quite common - SPARQL requires a STR().
Yep, and that trips up users a lot, but there's a more substantial difference between "http://example.com/" and <http://example.com/>, than "foo" and "foo"@en", in my opinion.
> 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.
Why? Hashes won't roundtrip anyway, by definition, and "0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33"@en is gibberish.
The very fact that we had to invent language to distinguish simple literals, and plain-literals-with-languge implies to me that we shouldn't be treating them so distinctly.
- Steve
--
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203 http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 21 December 2010 14:50:09 UTC