W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

Re: pound sign vs. slash as final URI delimiter

From: Jon Hanna <jon@hackcraft.net>
Date: Tue, 17 Feb 2004 15:42:39 +0000
Message-ID: <1077032559.4032366f78246@>
To: rdf-interest <www-rdf-interest@w3.org>

> Yet another option may be to use URNs as resource identifiers, e.g.
> rdf:about="urn:test:123". One question in this context: Is it correct to
> say that the previously mentioned resource is '123' in the 'urn:test:'
> (or 'urn:test'?) namespace?

I'm not sure what the question is here. But I imagine that with
urn:isbn:0321185781 or URNs that are equivalent by the rules of that schem
(e.g. urn:isbn:0-321-18578-1) the resource is the book of with the ISBN of
0321185781. There's an answer, hope it matches your question!

URNs can have advantages to those who understand the scheme, especially in cases
where the scheme builds on a previous identifier scheme, as is the case with

Of course HTTP URIs have the advantage that even if the aren't intended
primarily to allow dereferencing, they can do so.
http://www.hackcraft.net/bookref/?urn:isbn:0321185781 is better than
urn:isbn:0321185781 to someone with no isbn-specific information, although it
is of less value to someone who does have such information.

One posibility is to use both together:
<qdc:Text rdf:about="urn:isbn:0321185781">
<dc:title>The Unicode Standard, Version 4.0</dc:title>

With that information you have both the URN that can be easily processed by an
ISBN-aware application, a HTTP URI that can be dereferenced by those that don't
(it have an RDF representation, though now I think of it I think I'll add that
some day soon).

Of course adding a HTTP URI means we still have the hash sign (why do American's
call U+0023 [#] "pound" anyway - is it because it could occupy the same code
point in an ISO 646 implementation that as U+00A3 []?). So while this might be
a way to deal with URNs it isn't a way to deal with URNs to deal with / vs. #

Jon Hanna
*Thought provoking quote goes here*
Received on Tuesday, 17 February 2004 10:42:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:49 UTC