- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 21 Dec 2010 11:32:25 +0000
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On 2010-12-20, at 18:37, Axel Polleres wrote:
>
> <p>The <code>encode</code> function is SPARQL's correspondent to the XPath <a href="http://www.w3.org/TR/xpath-functions/#func-encode-for-uri">fn:encode-for-uri</a> function and accepts simple literals as well as <code>xsd:string</code> typed literals as input. It returns a simple literal with the lexical form obtained from the lexical form of its input after translating reserved characters according to the <a href="http://www.w3.org/TR/xpath-functions/#func-encode-for-uri">fn:encode-for-uri</a> function. For plain literals with language tag or typed literals with types other than <code>xsd:string</code> it returns a <a href="http://www.w3.org/TR/xquery/#dt-type-error" class="norm">type error</a>.</p>
Why should encode_for_uri("colour"@en-GB) be a type error?
I can understand that encode_for_uri("1"^^xsd:integer) could/should be a type error, because you can't encode the integer one in a URI, but you can encode the English word "colour" in a URI.
There's arguably some information loss, as you lose the language tag, but as URIs can't capture language tags I don't see that as an issue (like STR() and simple literals).
- 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 11:32:59 UTC