Paul has volunteered (was Re: Overloaded URIs must GO!)

[Didier PH Martin]

Hi James,

[Explanation....]

Indeed we have here two problems:

a) a unique identifier
b) a location

The former as used in your user example do not need to have a location but a
"unique name". The latter obviously a "place where something is stored".

We face here the classical URL, URC, URN triad. The best configuration
being:

a) a name to uniquely identify things (U_niversal R_esource N_ame)
b) a set of properties attached to this name (U_niversal R_esource
C_haracteristics)
c) one of these properties is a location (U_niversal R_esource L_ocation)

For people versed in directory services concepts or Grove concepts (recently
a copycat of groves: information sets) and more generally in object concepts
will recognize the classical problem of classes, instances and properties
(property sets being constrained or not by a schema)

It seems that for the problem we try to resolve URNs brings better results.
Why?

a) a URN could used as a unique identifier . i.e. a "name"
b) later on, this name could be used to find a "place" where something is
stored with a name resolution mechanism. One officially proposed at IETF is
the DNS. Other resolution mechanisms could also created and URNs are not
solely restricted to DNS name resolution.

Ideally, we should evolve toward directory schemas where "names" posses
"properties", one or several of these properties could be "locations".
For instance, today, LDAP directories elements could be reached with a
"LDAP" URL. This URL is a query to the directory service and the URL's
schema indicates obviously the LDAP protocol. This URL could be replaced by
a URN like in the example below:

URL -> LDAP://ldap.itd.umich.edu/c=us

into

URN -> URN:LDAP:c=us

What's missing now is a common name space like actually found with DNS.
Originally, the X500 name space was intented for this purpose. Today, we
have to specify the target LDAP server in the query URL. In URN we may not
have to do so. We would have to just enter, like for DNS name spaces, the
nearest LDAP directory in the system configuration (we do that today for
DNS). Waht's missing today, is a way for LDAP server to share part of a more
global name space. However, several groups are working toward that goal (not
always in concert, but we progress).

We are slowly, but surely progressing toward the following structure:

Objects uniquely identified by names (URN)
properties associated to this object (URC)
one of these property is a location (URL)

Conclusion: it is better to use URNs than URLs. However "names" have to be
thought with evolution in minds. So that one day, they could be used to
retrieve the properties associated to this name. One of these properties
being the location where the document is located. The document may be the
complete documentation concerning a particular document architecture. To put
in a name a "place" won't assure longevity to a name and it would be funny
to observe how incongruous we are because a main selling point for XML is
the document longevity :-)). However, it is possible to have unique names
wihout having to use URLs like for instance a combinaison of a name and a
date (the probablility that two persons have the same name and date is quite
low). A unique identifier like for instance RPC UUID. A Creator's name +
date + doctype (here again we reduce the probablity of name collision). And
I am sure that with the brain power we have here a better schema could be
invented than the one I proposed.

So hname makes sense as long as we find a good naming schema with low name
collision probability. Later on, this "hname" name space (in the URN sense)
could be resolved in a "place" where the doc architecture is stored.

regards
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)