RE: Addressing the QName to URI Mapping Problem

> -----Original Message-----
> From: ext Brian McBride [mailto:bwm@hplb.hpl.hp.com]
> Sent: 21 August, 2001 13:33
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-rdf-comments@w3.org; www-rdf-interest@w3.org
> Subject: Re: Addressing the QName to URI Mapping Problem
> 
> 
> Hi Patrick,
> 
> Thank you for this contribution.  A lot of careful thought 
> has gone into it
> and we are grateful.
> 
> For the momement I have listed this message under 'further 
> discussion' of
> the following issues:
> 
> http://www.w3.org/2000/03/rdf-tracking/Overview.html#rdfms-uri
> -substructure
> http://www.w3.org/2000/03/rdf-tracking/Overview.html#rdfms-qna
> mes-cant-represent-all-uris
> http://www.w3.org/2000/03/rdf-tracking/Overview.html#rdfms-qna
> me-uri-mapping
> 
> This will ensure that it is fully considered by the WG.

Thank you.
 
> Some questions of clarification follow.


Please be advised that my posting to www-rdf-comments was not intended
to be "standalone" but merely a mechanism for bringing these
issues under "official" focus and directing the core working group to prior
and extensive discussion about them -- hence the terseness and lack of 
prolific examples.

 
> Patrick.Stickler@nokia.com wrote:
> 
> [...]
> > Claim 1: An XML QName functions as a universal identifier.
> 
> It has been said that a fundamental principle of the web is 
> that resources
> are identified by URI's.
> 
> What do qnames identify?  

Whatever they are specified as identifying by the creator
of the qname.

I don't see
"namespace" + "name" -> "namespacename" as being any
richer or more informative a resource identifier as
"namespace" + "name" -> "qn:{namespace}name".

In either case, one is simply creating a URI which serves
as nothing more than a lexical mechanism for string
equality tests. What they identify is what the "owner"
of the qname says they identify.

However, in the latter case, using an explicit qn URI,
we don't get unintended collisions which degrade the
integrity and uniqueness of those identities.

> What are the properties of these 
> identifiers? > Where are these properties specified?

What are the properties of *any* URI? Simply that which
is defined for the URI scheme, or attributed to the
owner/creator of the URI, no?

I don't really follow what you are asking, at least
insofar as it relates to the present RDF methodology
of deriving URIs via concatenation.

The bottom line is we're dealing with unique, opaque
strings used as universal identifiers -- and we need 
mechanisms which preserve that uniqueness. Despite the
fact that some applications can look into those strings
and possibly dereference them to content or extract
structure or information from them is beside the point
insofar as their role in an RDF graph is concerned. No?

And if we choose to employ syntactic shorthands in the
serialization (i.e. namespace prefixes), then there should 
be a consistent, standardized 1-1 correspondence between 
those identities in XML space and in RDF (triples) space.

So there are two choices: (1) forgo the use of QNames
entirely for resource identity in RDF serializations, or
(2) define an explicit mapping solution between QNames
and resource URIs which is fully bi-directional and
preserves the integrity of identifier uniqueness.

Presuming that choice #1 is the least attractive, both my
proposals attempt to accomplish #2.

> Are there examples 
> where the same
> qname identifies different things?  

I've provided several possible scenarios. Do I know of actual
cases? No. But just because someone hasn't fallen into a hole
doesn't mean we shouldn't cover it up, eh?

> Can you provide examples 
> where QName's
> are used as universal identifiers.

I understand the XML Namespace spec as attributing a set of 
characteristics to QNames which also correspond the concept
of universal identifier. I also point you to James Clark's
comments on that matter, and to the numerous comments in the
rdf discussion lists that indicate that this is a common
understanding of the nature of QNames.

Can you provide arguments or examples that would demonstrate
that QNames should *not* be considered universal identifiers?
(other than "because the RDF spec says so")

> [...]
> > Claim 3: Direct suffixation of name to namespace URI can result
> >          in ambiguity and therefore the integrity of knowledge
> >          is not preserved.
> 
> By direct suffixation, I take it that you mean the function 
> which turns
> a qname into a URI by concatenating the URI-REF associated with the
> namespace prefix with the localname part of the qname.

Correct.

The namespace URI is taken as a base, and the local name is suffixed
to that base, such that the resultant URI belongs to the same URI 
Scheme as the namespace URI.

> > 
> > Claim 4: Direct suffixation of name to namespace does not preserve
> >          the uniqueness of QNames and therefore is in violation of
> >          required behavior defined by the XML Namespaces 
> specification.
> 
> This one I don't quite follow.  Imagine a function TOURI 
> which transforms
> qnames to URI's.  Where in the namespaces spec does it say that all
> such functions must be 1-1.  

I believe that this is quite clear in the NS spec. I honestly can't
believe that I keep hearing this argument so often during these
discussions. Where does it say, or even imply, that it might be
acceptable to lose the distinction between any two different QNames?
To do so is contrary to the very *purpose* of the NS spec! Which
is to ensure the explicit disjunction between lexical identifiers
intended to bear different semantics!

> Lets take another example.  Lets say 
> there is a function HASNAMESPACE which maps qnames to 
> uri-refs.  The value
> of that function is the uri-ref associated with the namespace 
> prefix of the
> qname.  Does that function contradict the namespace spec?  If 
> it does not,
> what is it that makes TOURI different?

I don't follow this second example. Sorry. If it maps from qnames
to uri-refs, then how can it take only the namespace uri? If you
mean it first maps the ns prefix to the ns uri and then derives
a uri from the ns uri and name, then no, the existence of a
function itself to provide that mapping does not contrict the
NS spec (and I never said it did) -- only that I think it is to
be expected that the distinctness of qnames would be preserved
by such a mapping in the resultant uri -- i.e. such a mapping 
*would* be expected to be 1-1.

I repeat my previous response to this issue:

> ... the present method employed
> by RDF to map QNames to URIs results in the potential loss of 
> a distinction (be it syntactic or semantic) between QNames having
> different namespaces -- a distinction which is IMO defined clearly
> in the XML NS spec. 
> 
> The present treatment of QNames by RDF, therefore, does not simply 
> extend or add to the functional layer defined by XML Namespaces,
> but rather weakens or violates that layer by failing to maintain such 
> QName distinctions. 
> 
> As such, RDF (mis-)uses QNames in a way that is not compatible with
> the XML Namespace spec.

I.e. the XML Namespaces spec says (IMO) that two QNames which differ
in namespace or name are two different lexical identities, and since
it is permissible for me to assign different semantics to each such
unique lexical identity, for RDF to loose that distinction is IMO wrong.

> > 
> > Claim 5: Direct suffixation is not compatible with all possible URI
> >          schemes and therefore introduces an unreasonable 
> discrimination
> >          against some forms of namespace URIs.
> 
> For completeness, please could you provide an example.

See the provided references. I did not wish to repeat, yet again, all
of the examples I have provided over the past few months. But here's
just one (which should be enough) extracted from the threads:

... [it] doesn't work for any URI scheme which has bracketed notation
syntax, e.g. my example urn:partax URI scheme for parenthesised
taxonomies, where 

   xmlns:foo="urn:partax:(foo)"
   xmlns:bar="urn:partax:(foo(bar))"
and
   foo:bar needs to map to the resource urn:partax:(foo(bar)) and 
   bar:bas needs to map to the resource urn:partax:(foo(bar(bas))).

Thus, neither "urn:partax:(foo)bar" or "urn:partax:(foo(bar))bas"
correspond to a known resource. 

Playing my own "devil's advocate" I will point out that the proposed
explicit qn URI approach also fails to provide this mapping, but at 
least in the case of a qn URI, we *know* that we are dealing with a 
QName as opposed to some invalid and unknown urn:partax URI resulting
from direct concatenation. 

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 Tuesday, 21 August 2001 07:41:16 UTC