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

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 "" and <>, 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
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