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

Brian,

I will reply to several messages at once:

> >At 10:15 PM 21/01/02 +0000, Brian McBride wrote:
> >
> > >You may be interested in this
> > >
> > >  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jan/0188.html
> > >
> > >which also suggests that refining the definitions of and relationships
> > between resources, URI's, URI refs and namespaces is a task for the TAG.

I wholeheartedly agree.

> I will note your objection.  However, if you feel sufficiently strongly
> about this to break consensus, you owe us clear reasons why you cannot
live
> with this decision.

First I don't think I am breaking consensus, indeed I cannot find any
specific evidence that a consensus exists that the RDF mechanism for
creating a URI from a QName is in fact the appropriate one. Aside from the
fact that this is how RDF 1 does it, I would like to see what arguments are
made in favor of the current mechanism. Are such arguments reasonable to XML
and the Web in general. Indeed if the main argument _against_ making a
change is that this is how things are currently done, then if a change is
not made now, when I submit it is possible, the situation will only worsen
in the future, when concerns regarding 'legacy RDF applications' may have
some real substance.

This issue is a fundamental one to the RDF/XML syntax, and even non-XML
syntaxes namely N3 and N-triples which leverage the XML QName.

The RDF Model Theory employs URIs as the words of the RDF language.
XML+Namespaces employs QNames as the words of the XML language. Case in
point: XML Schema which names its types _not_ with URIs but with QNames.

The aim of the RDF XML Syntax is to translate between an XML representation,
whose (in infoset terminology) element information items are named by a
namespace name and a local name i.e. a two part name, into RDF triples which
are composed of URIs. The most fundamental part of this mapping is the
function that accepts a two part name (represented by a QName) and returns a
URI.

From an architectural point of view, this mapping function should be
defined, not differently and in a conflicting manner by each W3
recommendation, but rather in a logical and consistent fashion.

XML Schema datatypes are an example. They are inarguably named by and
referenced by their QName in XML Schema. Both the RDFCore and WebOnt WGs
have much discussion about datatypes and the desirability of leveraging the
XML Schema datatypes for RDF and the web ont language (whatever that is
defined as). Yet if there isn't a consistent way of translating a QName
datatype name into a URI, how can RDF leverage such datatypes? The result is
that the name that RDF uses for something is different than the name that
XML Schema uses for the exact same thing.

Case in point: "xsd:int": (this example is direct from
http://www.w3.org/TR/xmlschema-2/#built-in-datatypes)

"Each built-in datatype in this specification (both ·primitive· and
·derived·) can be uniquely addressed via a URI Reference constructed as
follows:

the base URI is the URI of the XML Schema namespace
the fragment identifier is the name of the datatype
For example, to address the int datatype, the URI is:

http://www.w3.org/2001/XMLSchema#int


On the other hand the RDF behavior of simple concatenation gives the URI:

http://www.w3.org/2001/XMLSchemaint

It is not reasonable, to me, that such a fundamental issue as the mechanism
of assigning a URI to a QName should be different between Recommendations.
This is an architectural problem and we have seen the disagreements and
arguments that can ensue for years after such issues are allowed to slip by
(e.g. xml-uri@w3.org)

I have advocated, along the lines of considering the namespace name the
'base URI' and the local name the 'fragment identifier' inserting a '#'
between the two when the last character in the URI is an alphanumeric. On
the other hand, Henry Thompson has convincingly demonstrated to me that this
does not completely solve the issue with respect to XML Schema, but he can
explain that particular issue better than I.

The bottom line is that, however this is resolved, I consider this a
fundamental architectural issue that ought not be whitewashed  over.

Jonathan

Received on Tuesday, 22 January 2002 14:10:04 UTC