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

Re: Summary of the QName to URI Mapping Problem

From: Piotr Kaminski <pkaminsk@home.com>
Date: Wed, 15 Aug 2001 17:07:16 -0700
Message-ID: <00fc01c125e7$84425fa0$35254d18@gv.shawcable.net>
To: <www-rdf-logic@w3.org>
Dan Connolly said:
> The RDF spec includes an unambiguous QName -> URI mapping:
> uri(qname) = concat(nsname(qname), localname(qname))

The mapping mechanism is indeed unambiguously defined.  It can, however,
lead to invalid results.

Let's start from the following axioms.
1.  A QName identifies a (single) resource.
2.  A URI identifies a (single) resource.
3.  The goal of a QName -> URI mapping is to transform a QName into a URI
that identifies the *same* resource.

The above mapping doesn't achieve the goal.  An example follows that is
essentially equivalent to Patrick's, but I have a feeling that most of the
contention will be about the axioms above, especially (1).  One could take
the position that a QName is a purely syntactic construct, and doesn't
identify anything in and of itself.  I believe such an interpretation
contradicts the XML Namespaces recommendation, in spirit if not in letter.

Informal example to demonstrate why the mapping is flawed according to the
axioms:

xmlns:foo="http://ideanest.com/foo"
xmlns:bar="http://ideanest.com/foobar"

Then the following two QNames identify distinct resources; they do so
because they are different names, the namespace URI is mine, and I say that
the resources they identify are different.

foo:barcat
bar:cat

Yet, using the standard concatenation mapping, both QNames are mapped to the
same URI:

http://example.com/foobarcat

While this URI identifies some resource (by definition), it cannot identify
both of the (distinct!) resources identified by the two QNames
simultaneously.  Hence the mapping is deficient.

        -- P.

--
  Piotr Kaminski <piotr@ideanest.com>  http://www.ideanest.com/
  "It's the heart afraid of breaking that never learns to dance."
Received on Wednesday, 15 August 2001 20:04:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:40 GMT