Summary of the QName to URI Mapping Problem

Since some of the key points of this issue seem to be getting obscured by
the meat of the various threads covering this topic, and divergences from
or other discussions related to this topic, I wanted to try
to give a summary of those key points, with some limited comments, in the
interest of maintaining clarity and focus in these discussions.

--

Firstly...

The QName to URI mapping issue is totally unrelated to all of the following
issues (all of which have cropped up here or there in the recent
discussions):

* Name versus Location and whether 'URL' vs 'URN' should have any official
  meaning with regards to URI schemes.

* The persistence of uniqueness or any other characteristics of a particular
  URI scheme used to represent the identity of RDF resources, which might
  motivate the selection of one URI scheme over another for use with RDF.

* The pros and cons of anonymous nodes, RDF collections, and other graph
  related issues (except for when anonymous node-based representations are
  proposed as solutions to the QName to URI mapping problem).

Though all of the above are interesting and important issues, they are
not what is summarized here; and none of them IMO are critical to the
success of the SW as I believe the issue detailed here is.

--

A. QNames are neither URIs nor URI references:

Even though QNames include a URI as a component, representing the namespace
of the QName, the QName itself is not equivalent to a URI, nor is there any
clear, explicit function for deriving a URI or URI ref from a QName defined
by the
XML Namespace spec. Any such QName to URI mapping function is outside the 
scope of the XML Namespace spec as it is presently written.

--

B. The RDF QName to URI mapping function is broken and unreliable:

The RDF spec and the XML Schema spec are the only places I am aware of where

any such QName to URI mapping function is defined. 

The scope of the XML Schema function (which is ns:name -> ns#name) is 
limited solely to XML Schema instances and ID attribute values within those 
instances, and is not sufficiently broad to address all combinations of URI 
schemes and MIME content type fragment syntaxes. So it can be disregarded.

The scope of the RDF function (which is ns:name -> nsname) is supposed to
apply to all cases, for all URI schemes, yet unfortunately, because the
partition between the namespace and name is lost, can produce collisions
resulting in ambiguity (which is anathema to the SW).

I.e. if 'ns1:' = "urn:x:abc" and 'ns2:' = "urn:x:abcd"
     then both 'ns1:defg' and 'ns2:efg' are mapped to
     the same URI "urn:x:abcdefg"! Yet these are clearly
     separate resources per their disjunct QName identities

(the fact that the above example is contrived in no way lessens the
 seriousness of this problem)

What is interesting is that, if XML Namespaces did not exist, then RDF
would either have to:

1. Require that all property identities be defined with full, explicit URIs,
   just as it is necessary to do so with subject and object resource
identity.
   (which presently cannot be done, given the limitations of the defined
    XML serialization model)

or

2. Employ an element name to URI mapping construct similar to my proposed
   rdf:Map element.

However, XML Namespaces came along at just the right (or wrong) time and
so RDF was able to require that all property element names be QNames and
could derive (in most cases) something that looks like a URI from direct
concatenation of namespace + name. This has simply resulted in the whole
QName
to URI mapping problem being hidden from view -- so long as namespaces
end in '#" or '/' and only concatenative syntax URI schemes are used; which
has been the case since nearly everyone using RDF has simply been using
HTTP URLs with HTML/XML fragment syntax.

--

C. No QName to URI mapping function is workable for all SW contexts: 

If the entire scope of any arbitrary URI scheme being used for namespaces 
or for resource identity is taken into consideration, the RDF mapping 
function is clearly woefully inadequate. Nor can a single, reliable function
be defined that will be compatible for any arbitrary (possibly yet
undefined)
URI scheme or MIME content type fragment syntax. Therefore, the QName to
URI mapping must be defined for each QName irrespective of any URI scheme
or any MIME content type fragment syntax.

--

D. RDF must have an explicit QName to URI mapping construct:

The fact that Namespaces exist actually does not change the above two
choices that RDF must make (it has only postponed the realization that
such a choice *has* to be made).

RDF must either:

1. Sidestep the QName to URI mapping problem entirely
   by redefining the serialization model to require explicit URIs for
   property identity in serialized instances (bringing it closer in
   nature to e.g. BSWL or NTriples).

or 

2. Adopt an explicit QName to URI mapping construct to bridge the
   gap between Ontologies and resource identities within the knowledge
   base and serializations of those ontologies and resource identities.

Since QNames are not going to go away (nor should they) and since also
QNames are much easier for humans to work with than full URIs (I wish
RDF would allow QNames also in attribute values for subject and object
URIs as does XML Schema...), and since RDF is unlikely to change in a
way that does not maintain backwards compatibility with current systems,
the first option above is not feasible.

Therefore, the second option is left. My proposal suggests one possible
way to define such an explicit mapping construct, in a fully backwards
compatible manner, with the added benefit of XML literal to RDF resource 
mapping as well as basic RDF literal data type validation. I'm sure there 
are other ways to achieve the same end, and I welcome discussion of any
alternatives. 

The bottom line is that *some* such solution has be adopted, and soon.


Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Wednesday, 15 August 2001 06:24:08 UTC