Re: QName URI mapping

Your comments are quite on target, Jonathan.

This is an issue that I have repeatedly ranted about in the past,
and have done alot of thinking and hacking to find an optimal

It is my opinion, which may or may not be shared by others, that
the entire QName -> URI problem with RDF is simply a direct consequence
to using QNames to denote resources in the XML serialization which in
the RDF graph only have URIref denotation, and that design decision,
while adding a certain degree of openness, flexibility, and
readability to the serialization of RDF statements, was not an
optimal design choice.

QNames are only an issue for RDF serialization, and in fact are not
addressed in the MT at all, by intent.

Therefore, I see the solution to this problem as defining a new
XML serialization for RDF which does not employ QNames for denoting
resources, but uses only URIrefs.

This would avoid RDF having to support content-specific QName to
URI mappings or resort to problemmatic and simplistic direct
concatenation, and would also provide for full round-tripping, since
clearly, if no mapping occurs, you get out what you put in.

Such a serialization would also facilitate the use of validating
XML editors for RDF serialized knowledge regardless of ontology,
as the only element and attributes in such a serialization would
be those needed to represent RDF statements -- with all application
specific vocabulary relegated to attribute values and/or data content.

For now, however, I don't see that this QName -> URI mapping
problem can be solved in terms of the present RDF/XML serialization,
and as the present Core WG is not able under its charter to provide
a new serialization, this matter must be left for a future WG
or a future phase of the present WG (which I hope will commence very
soon as this is a non-trivial issue).



On 2002-01-23 7:37, "ext Jonathan Borden" <> wrote:

> Graham Klyne wrote:
> "
> The forward transformation from QName -> URI is clear and unambiguous per
> the original RDF specification.  It is the reverse transformation that is
> problematic.
> "
> To be clear, while I would prefer that a bidirectional mapping be possible,
> just as I would _greatly_ prefer that the RDF model <-> XML mapping be
> bidirectional and roundtripable, there are issues with the simple forward
> transformation.
> In particular the model XML Schema uses for use of a QName as a type
> specifier is that the namespace name/URI is like the 'base URI' of the
> schema (quotes because it is not quite that simple but nonetheless) and that
> the localname is used as a locator for the type declaration within the
> schema module. In URI terms, XML Schema thus treats the localname LIKE a
> fragment identifier. It is not exactly a fragment identifier for several
> reasons, namely that no fragment identifer syntax is (yet)defined for
> application/xml and particularly because the localname maps to the XML
> Schema "name" attribute which is not ot type ID.
> For this reason I have issues with the forward QName -> URI mapping if this
> is a simple string concatenation.
> For the vast majority of RDF namespaces, perhaps all of the deployed RDF
> namespaces, simple concatenation is exactly the same as treating the
> localname as a fragment identifier (it comes after the '#') but for XML
> namespaces in general this is not the case. RDF does not require its
> namespaces to end in '#' hence one of the reasons for the incompatibility.
> I cannot say for sure that this incompatibility is entirely the 'fault' of
> RDF (although the mapping is perhaps too simplistic), rather a breakdown in
> communications and coordination between the RDF WG and other WGs more
> intimately involved in XML activities. It is not important to me where this
> incompatibility gets fixed, and since it is a basic architectural issue I
> agree with Brian and Tim Bray that the TAG ought be involved in this issue.
> For that reason alone, I would prefer that the issue not be closed for the
> moment.
> Jonathan

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email:

Received on Wednesday, 23 January 2002 04:35:35 UTC