W3C home > Mailing lists > Public > uri@w3.org > August 2001

Re: QName URI Scheme Re-Visited, Revised, and Revealing

From: Sean B. Palmer <sean@mysterylights.com>
Date: Wed, 22 Aug 2001 14:36:59 +0100
Message-ID: <012601c12b0f$a39a8080$f2da93c3@Palmer>
To: <Patrick.Stickler@nokia.com>
Cc: <www-rdf-interest@w3.org>, <uri@w3.org>
> Hmmmm.... do we need then to use DAML equivalence
> constructs for basic RDF?! E.g.
>
>    <qn:{http://description.org/schema/}Creator>
>       daml:equivalentTo
>          <qn:{http://description.org/schema/}@Creator> .

No, because those QNames are in RDF, and RDF processors handle them by
concatenating them and forming a URI. The XML Namespace specification
defines a difference between the QNames, but it doesn't tell you how to
handle them. The RDF specification comes in and tells people what to do
with the QNames. It tells one to concatenate the QNames togther minus
partition information, to form a URI. There's no problem with that, except
there's no way to identify a QName as a first class object without some
extra properties, or a new URI scheme. So there's no particular need to map
every QName in XML RDF to your URI scheme - to do so would be silly - but
it doesn't stop people using it.

In other words, you've accomplished all that you want to accomplish simply
by inventing this URI scheme. If you force people to adopt it *instead* of
the concatenation mechanism in XML RDF, then you'll form an utter mess,
because the Semantic Web deals with URIs, and not just QNames. Using the
concatenation mechanism is an excellent and quick way to form those URIs
out of QNames. Your URI scheme is good (saves the need for even
decentralized QName properties), and I'm sure that I will be recommending
it to anyone that needs to map between QNames, define them using RDF, or
whatever. WAI PF have been looking for something like this for quite a
while. But RDF uses URIs and not QNames, and now that you've come up with
representing an XML QName (i.e. with all the details preserved as in the
XML namespace specification) as a URI, that's fine.

Now, there are only two errors with your URI scheme. The first is that the
characters "{" and "}" are disallowed in URIs per section 2.4.3 of RFC
2396. This can be easily gotten round by using "(" and ")" instead, e.g.:-

     qn:(http://www.w3.org/1999/xhtml)title

that's a shame because I often use "{}" for QNames.

The problem is more difficult. Namespaces are actually URI References, and
yet you need to include them in a URI scheme. URI References with a "#"
aren't allowed in URIs. In other words, the following is illegal:-

     qn:(http://infomesh.net/2001/08/example#)myElement

Because the "#" character is also disallowed by section 2.4.3 of RFC 2396.
Perhaps you can just %HH encode it?

     qn:(http://infomesh.net/2001/08/example%23)myElement

Which *should* be O.K., but it needs further discussion. Note that if your
namespace ends (or contains) a "%23", then you can escape the "%" to use
that; i.e. "%2523".

   qn = 'qn:' '(' absoluteURIexc [ '%23' fragment ] ')' ( elem | glob |
per )
   elem = NCName
   glob = '@' NCName
   per = NCName '@' NCname

BTW, I know that you've only just invented this scheme and so on, but once
people on uri@w3.org have discussed it, could you create an Internet Draft
of it, and send it to the IETF for consideration? Cheers.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Wednesday, 22 August 2001 09:36:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:29 GMT