W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2001

RE: What to do about namespace derived URI refs... (long)

From: <Patrick.Stickler@nokia.com>
Date: Fri, 8 Jun 2001 13:03:41 +0300
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA50795875C@treis03nok>
To: LMM@acm.org, sean@mysterylights.com, rden@loc.gov, timbl@w3.org
Cc: Patrick.Stickler@nokia.com, www-rdf-interest@w3.org


> This lets us leave namespace names as URI references by noting
> that the xmlns relationship doesn't link to the resource but
> to the 'namespace' corresponding to it, etc.

The problem though regardless of what kind of URI you use a namespace
URI, you still have no way of knowing how names within that namespace
correlate to the namespace "prefix". If you use fragment references to
identify names within a namespace (though see note 1 below), you must
arbitrarily select a particular MIME content type defined fragment
syntax to encode the full URIs of the Qnames of the names within the
namespace, or if you just use the path mechanism for hierarchical URIs
such as an http: URI, that is just as arbitrary, or if a URN (urn:)
scheme is used as the namespace URI, it could have any kind of syntax
for constructing sub-names and sub-namespaces -- and *no* application
which must figure out the full URI of a name within a namespace such as
from an RDF serialization can do that in any certain manner.

Given 

   <rdf:RDF ...
            xmlns:foo="{some URI}">
      <foo:bar>boo</foo:bar>
   </rdf:RDF> 

There is no consistent mapping from "foo:bar" to what the URI is
for the name 'bar' within {some URI}. It is not the concatenation
of {some URI} + '#' + 'bar', nor is it {some URI} + '/' + 'bar, 
nor simply {some URI} + 'bar'.

It may very well be that the namespace is a URN using a URN scheme
that uses parenthesized notation for taxonomies and that the *real*
universal, portable, consistent, and global identifier for the 
property in question of the following:

   <rdf:RDF ...
            xmlns:foo="urn:partax:foo">
      <foo:bar>boo</foo:bar>
   </rdf:RDF> 

is "urn:partax:foo(bar)". Now, just how do we get to triples of fully
qualified URIs from that fully valid serialization of RDF metadata?!

XML Schema would propose that we'd have "urn:partax:foo#bar". RDF
would give us "urn:partax:foobar" unless we played games with the
xmlns definition, but even there, the best we could achieve would
be "urn:partax:foo(bar" which is clearly *not* the same as the correct
"urn:partax:foo(bar)"!

The parenthesized syntax is defined by the 'partax' (Parenthesized
Taxonomy) urn syntax -- which is not explicitely known by the parser.

Furthermore, since we have a taxonomy, and the property 'bar' has
a controlled set of values, one of which is 'boo', what we really
need is a triple where the predicate is "urn:partax:foo(bar)" and
the object is "urn:partax:foo(bar(boo))". Now, it's a bit tough to
map the PCDATA "boo" to a resource since that would just be a literal
to RDF, so let's use an empty element:

   <rdf:RDF ...
            xmlns:foo="urn:partax:foo">
      <foo:bar><bar:boo xmlns:bar="urn:partax:foo(bar)"/></foo:bar>
   </rdf:RDF> 

Hmmm... interesting. The namespace for 'boo' is "urn:partax:foo(bar)"
but the URI for 'boo' is "urn:partax:foo(bar(boo))" which is 
arrived at not by concatenation but by insertion! 

In fact, the syntax for the partax URN scheme might in fact have
included the taxonomy root identifier in the parenthesized syntax,
giving us:

   <rdf:RDF ...
            xmlns:foo="urn:partax:(foo)">
      <foo:bar><bar:boo xmlns:bar="urn:partax:foo(bar)"/></foo:bar>
   </rdf:RDF> 

Where 

   foo:bar    ->    "urn:partax:(foo(bar))"
   bar:boo    ->    "urn:partax:(foo(bar(boo)))"

ALL of the above examples are fully valid use of namespaces, URNs,
RDF, etc. etc. Yet it does not work!

The fact that existing RDF applications using tricks of adding punctuation
to the ends of namespace URIs and specifically defining that the 
identity of names within that namespace follow the syntax derived
by straight concatenation does *NOT* demonstrate that the current practice
"works" for all anticipated SW applications.

The easy, though not so pretty, solution is to not use element or 
attribute QNames at all, but use fully specified URIs. Of course, that
would make it harder (though not impossible) to use XML as the serialization
mechanism.

Most of this mess (leaving aside the whole philosophical debate as to 
whether a URI ref should name an abstract resource as a disjunct issue) 
is that the XML Namespace rec does not define any relationship between a
namespace URI, a non-qualified a name defined within the context of
a namespace, *and* the full URI of the qualified name. The last part is
missing, and is unfortunately dependent on the URI syntax or MIME content
stream fragment syntax being utilized for the namespace URI.

It is because it is missing that there has arisen the conflict between
RDF straight concatenation and XML Schema '#' concatentation. The XML
Namespace spec doesn't say *how* to construct complete names, only
that the namespace should be used rather than the prefix. The language
"in place of" does though suggest concatenation (in which case the 
RDF interpretation is probably more correct that that of XML Schema), 
but that concatentation should be used is merely an interpretation,
not a mandate, and cannot in fact work for arbitrary URI or fragment
syntaxes.

Define a consistent method of going from QName to full name URI for
each URI/fragment syntax that is supported by all SW applications and 
we can all be happy campers...

(or at least a little bit happier ;-)

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 Friday, 8 June 2001 06:04:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:49 GMT