RE: Dedicated, Standardized URI Scheme for QNames?

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 21 August, 2001 23:06
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: Re: Dedicated, Standardized URI Scheme for QNames?
> 
> 
> > [...] the following accomplishes the same, but in a more
> > compact form:
> >
> >   <qn:title:http://www.w3.org/1999/xhtml>
> >      a :ExpEName .
> 
> So, if I wanted to point to the ExpAType QName, I'd have to 
> use the same
> URI?
> 
> <qn:title:http://www.w3.org/1999/xhtml>
>    a :ExpAType .

Are you saying that the same QName, used for both element and
attribute name in the same XML instance, will represent different
semantics?

Sorry, I'm just not groking why such a distinction is meaningful.
 
> Well, that's not going to work... what if you want to refer 
> to the ExpEName
> and ExpAType (element and attribute QNames) in the same 
> document (which is
> more than likely)?
> 
> Doing it the other way is non-ambiguous:-
> 
> <http://www.w3.org/1999/xhtml#element_title>
>    a :ExpEName;
>    :namespace <http://www.w3.org/1999/xhtml>;
>    :name "title" .
> 
> <http://www.w3.org/1999/xhtml#attribute_title>
>    a :ExpAType;
>    :namespace <http://www.w3.org/1999/xhtml>;
>    :name "title" .

Whoops! You changed something here.

Before, you had

> <http://www.w3.org/1999/xhtml#title>
>    a :ExpEName;
>    :namespace <http://www.w3.org/1999/xhtml>;
>    :name "title" .

and now you have

> <http://www.w3.org/1999/xhtml#element_title>
>    a :ExpEName;
>    :namespace <http://www.w3.org/1999/xhtml>;
>    :name "title" .

where did the "...#element_" come from?

Your namespace doesn't include that. Does that mean that
you're proposing a more complex QName to URI mapping function
that inserts '#' {type} '_' between namespace and name?

And yet that results in totally different URIs for what *should*
be a lexical identifier representing the same semantics, no?

How does that help us preserve consistency of resource identities
across XML serializations and sets of triples?

> > Since you *have* to define the contextual distinction of
> > element QName versus attribute QName, etc. explicitly
> > in the RDF, I see no reason why it is the qn URI that has
> > a problem. It offers no more nor less information in that
> > regard than the directly concatenated URI.
> 
> Except that you don't have to directly concatenate it, e.g. 
> in the example
> above, so no. It's not only certain URIs that can be used to refer to
> QNames of a given partition... it's any URI, as long as that URI isn't
> already being used to identify something.

Your first example also didn't directly concatenate that element vs.
attribute usage information -- and I see doing so as a mistake since
it does the very opposite of the current RDF mapping function by
creating a one to many mapping from single QName to multiple URIs 
depending on how the QName is used.

> [...]
> > I don't see how namespace partitions belong in the URI scheme,
> > since the URI scheme only defines *QNames* not how they are
> > used in any given model or instance.
> 
> As long as the information is in there somewhere, I don't 
> care too much
> (others may disagree with me here), but your scheme appears 
> to still have
> to use the same identifier for two totally separate resources. That's
> forbidden.

Are you saying that <foo:bar> and <... foo:bar="..."> constitute
two different resources? These seem rather to be lexical variants
of the same identity which represent the same resource.

> You could only fix it by either adding the partition 
> information to the URI
> scheme (noting that you'd have to add element and attribute QName
> information sometimes, per the XML Namespace specification), 


Are QNames used to identify elements in a different 'namespace'
(disjunct set) than QNames used to identify attributes? I guess
I need to re-read the NS spec...   

> or by dropping
> this diversion and using any suitable generic 
> URI/URI-Reference that the
> world has come up with to date.

Ahhh, you mean such as by using my second proposal, employing
the explicit mapping declaration, eh? ;-)

> > As far as I can tell, all you are doing is taking the existing
> > (broken) mapping function and making statements about
> > the derived URI.
> 
> Ugh, why do you keep getting stuck on that? I can use *any* 
> URI that I have
> the power to use! As long as it doesn't already identify something, is
> using an appropriate scheme, etc.

Yes. You can choose any URI for the namespace. And specify any legal name.
But, given the present RDF function, you cannot ensure that the URI that
RDF derives from that QName will not collide with some other URI derived
from a lexically different QName that someone *else* defined somewhere
else.

I thought my examples illustrated that point.

Just because you associate additional properties with the resultant RDF URI
does not mean that you're home free. You're not.

And I'm "stuck" on this because this *is* the issue at hand.

> > the elements
> >
> >   <foo:def xmlns:foo="urn:x:abc">
> >   <bar:ef xmlns:bar="urn:x:abcd">
> >
> > gives us
> >
> >   <urn:x:abcdef>
> >      a :ExpEName;
> >      :namespace <urn:x:abc>;
> >      :name "def" .
> 
> Not necessarily. I could invent any URI to refer to those QNames.
> 
> <http://urn.org/x/#abc_def>
>    a :ExpEName;
>    :namespace <urn:x:abc>;
>    :name "def" .
> 
> <http://urn.org/x/#abcd_ef>
>    a :ExpEName;
>    :namespace <urn:x:abcd>;
>    :name "ef" .

Sorry, you've completely lost me here. Just *where* are you
getting those URIs from?! All that an RDF parser is going to
give you is <urn:x:abcdef> in both cases. 

What you are then proposing is simply a more complex URI
generation function that adds extra information between the
namespace URI and the name -- but that is unnacceptable, as
is any function based on the namespace URI, as you cannot
ensure that you will maintain the integrity of the namespace
URI scheme syntax nor that your fragment syntax is valid.

It goes back to the issue that, even though RDF treats URIs
as opaque strings, they still have to be valid URIs, and higher
level agents may need them to be valid URIs to do useful things.

So the attitude that an RDF parser has carte blanche to do whatever
it likes in hacking up URI-like strings for universal identifiers
is IMO wrong and can result in alienation from the rest of the XML
world.

--

To summarize my views on this:

1. There should be a 1-1 mapping between QName and URI, and the URI scheme
   used should be the official and standardized URI representation for
QNames.

2. The single URI associated with a QName should reflect the QName structure
   and support fully bi-directional mapping between URI and XML
representation.

3. It's fine to make RDF statements about the nature of a QName, based on
its
   equivalent qn URI, but such statements should not contribute to the
uniqueness
   of that QName nor to the identity of the resource identified by that
QName.

4. If type (element vs. attribute) is a manditory property of the uniqueness

   of a QName (i.e. if a QName used for an element is lexically distinct
   from the same QName used for an attribute), then type should of course be

   reflected in the qn URI scheme (e.g. one could define the qn URI syntax
   as qn:{<namespace>}<type>/<name>, or anything similar that does the job).

   (though this last point of the absolute need for type distinction needs
to be 
   clarified -- at least for me ;-)

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 Wednesday, 22 August 2001 04:19:27 UTC