Re: RDF Issue #rdfms-qname-uri-mapping

For what it's worth, here are my thoughts on the objection-to-resolution...

At 04:51 PM 1/21/02 -0500, Jonathan Borden wrote:
>I find this unacceptable for the following reasons:
>
>1) I have received nor have I found a proper analysis or explanation for the
>decision on any of the RDFCore WG archives. I will outline my objections to
>the three issues raised below.

I can't fully answer this, but I thought the message from Brian went a fair 
way...

>2) The problem is that there is much talk in RDFCore and WebOnt WGs about
>leveraging XML Schema datatypes for both RDF and WOL. At the surface this
>seems an entirely reasonable and desirable thing to do. The problem is that
>XML Schema identifies types by QName, and unless there is a reasonable
>translation between QNames and URIs, RDF is likely to become more broken
>with time.
>
>Since my proposed solution, Henry Thompson has explained to me how the
>issues with QNames and URIs are even deeper than I first assumed, namely
>that one cannot generally derive a proper URI which corresponds to the QName
>that XML Schema uses to identify a particular type. It seems to me that the
>RDFCore and XMLSchema WGs (at the very least) ought to develop a common,
>reasonably acceptable convention as to the mapping between QNames and URIs.
>Perhaps this is an issue that the TAG ought to consider (because it is a
>really basic architectural issue). I have cc:'d both Henry Thompson and Tim
>Bray. If either of these individuals agree that this issue ought to be
>closed, then I will find that acceptable and will withdraw my current
>objection.

The forward transformation from QName -> URI is clear and unambiguous per 
the original RDF specification.  It is the reverse transformation that is 
problematic.

There are a number of reasons why the reverse transformation may be 
desirable, but I don't think any are critical to correct handling of RDF.

(Though if TAG come back and say that this really is an important issue, 
and propose a reversible mapping, then I think that we should reconsider -- 
in the spirit recommended by DanC that backward compatibility 
considerations should not prevent adoption of the proper solution for 
solving problems going forwards.)

> >      1. Such a change would be a major change to the
> >         mapping of  RDF/XML syntax to the model and
> >         would be beyond our charter.
>
>The RDF 'model' itself has undergone major change indeed it has been
>completely rewritten. If it is not beyond the charter to completely rewrite
>the 'model' how could the model-syntax mapping possibly be beyond the
>charter?

The model may have been re-written, but we have really worked to render the 
intent of the original document, as closely as we could determine it.  The 
driving motivation was "no change", but making the description clearer and 
less prone to inconsistent interpretation.

> >      2. It would cause the same RDF/XML to generate a
> >         different  graph from existing versus revised
> >         implementations
>
>The same is true for many of the changes, even trivial changes which have
>already been decided upon. This is exemplified by the following trivial RDF
>1 example:
>
><rdf:Description about="http://example.com">
>     <rdf:type ID="baz" resource="http://example.org/bop"/>
></rdf:Description>
>
>since the new syntax does not interpret the unqualified attribute "about"
>the same as "rdf:about", this example which was valid RDF 1 is not valid RDF
>1.1 or whatever the current drafts are intended to be.

This example may be subject to some continuing debate, but the intent was 
that changes were introduced when we believed that the existing 
specification was subject to inconsistent interpretations.

> >      3. Existing code may generate wrong (illegal)
> >         graphs for some RDF/XML.
>
>see above, same story.

Expanding on the previous comment: where existing code interprets the old 
specification in a consistent way, we have tried not to disturb that.  But 
some changes have been justified by placing considerations of 
interoperability (i.e. consistent behaviour among conforming 
implementations) over considerations of backward compatibility with every 
existing implementation.

#g


------------
Graham Klyne
GK@NineByNine.org

Received on Monday, 21 January 2002 18:16:10 UTC