W3C home > Mailing lists > Public > www-rdf-logic@w3.org > August 2001

Re: Summary of the QName to URI Mapping Problem

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Thu, 16 Aug 2001 10:40:31 -0400 (EDT)
Message-Id: <200108161440.f7GEeVP06240@pantheon-po02.its.yale.edu>
To: www-rdf-logic@w3.org

   > Obviously, QNames are playing a very different role here than in XML.

   [Dan Connolly]
   Er... different than in XML? The above _is_ XML, as well as RDF.

   The use of namespaces in RDF is one of the many uses of namespaces
   in XML.

I wasn't making a formal claim.  Obviously, RDF is syntactically legal
XML.  It's just that it took me a while to figure out the "normal"
roles of names in XML, and another while to figure out their normal
roles in RDF, and yet another to realize that, while there is some
overlap, the two sets of roles are distinct.

   >  But there's no rule for where
   > to break it, and, as Patrick pointed out, if you do it the wrong way
   > you get ambiguities.

   What ambiguities? concat(nsname, localname) is completely

Okay, I give in on this issue.  I don't really care about the
ambiguities (and I am not knowledgeable enough to take a side in the
ongoing debate).

What I care about is that 

> RDF requires that when a certain designator is moved from one place
to another that it change syntactic shape, in ways that are

> QNames are second-class citizens, in that they can only appear in
"tag position" as it were.

We can't change the rules for XML at this point, but we could allow
QNames anywhere a URI is allowed.  If that were done, I would probably
adopt a coding style in which all URIs were moved to the front of a
document and defined as QNames, so that URIs wouldn't have to appear
throughout the document.

[Is this thread on the wrong mailing list?  It has little to do with
logic.  If so, I apologize.  Someone let me know by separate e-mail.]

                                             -- Drew
Received on Thursday, 16 August 2001 10:40:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:36 UTC