- From: Jonathan Borden <jborden@mediaone.net>
- Date: Tue, 22 Jan 2002 14:08:03 -0500
- To: "Brian McBride" <bwm@hplb.hpl.hp.com>, <www-rdf-comments@w3.org>
- Cc: <www-tag@w3.org>
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