W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011


From: Sandro Hawke <sandro@w3.org>
Date: Wed, 30 Mar 2011 07:44:20 -0400
To: Dan Brickley <danbri@danbri.org>
Cc: RDF WG <public-rdf-wg@w3.org>
Message-ID: <1301485460.2139.646.camel@waldron>
On Wed, 2011-03-30 at 11:59 +0200, Dan Brickley wrote:
> As I understand / dimly remember, the RDFCore round of specs tried
> their best to anticipate the IRI specs, but could only make normative
> reference to the URI spec.
> http://www.w3.org/TR/rdf-concepts/
> "Note: this section anticipates an RFC on Internationalized Resource
> Identifiers. Implementations may issue warnings concerning the use of
> RDF URI References that do not conform with [IRI draft] or its
> successors."
> ...whereas http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
> does not mention IRIs.
> Meanwhile http://www.w3.org/TeamSubmission/turtle/ "Turtle uses IRIs
> as term identifiers."
> For JSON my assumption has been that we would use IRI. Can this be confirmed?
> At the POI WG F2F we are looking at an example link to the page for
> Amsterdam in the Korean Wikipedia. I hope these come through the list
> OK.
> 1. the pretty link appears in Korean script (to me at least).
> {
>     "url": "http://ko.wikipedia.org/wiki/암스테르담"
> }
> 2. if this is escaped so as to be a pre-IRI URI, we get instead an
> ugly string, twice as many chars:
> {
>     "url": "http://ko.wikipedia.org/wiki/%EC%95%94%EC%8A%A4%ED%85%8C%EB%A5%B4%EB%8B%B4"
> }
> I'm agnostic for now, on question of where-or-whether this stuff gets
> canonicalised. But I would like to express a preference that verbose
> URI escape sequences are not imposed on eg. Korean URLs like the one
> given here.

I agree (1) is better.  I seem to recall that one of the important
things is to be sure you know which side of the %-encoding process you
are on, and "url" incorrectly suggests you're on the URI side, but maybe
it's still the best option. 

    -- Sandro
Received on Wednesday, 30 March 2011 11:44:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC