W3C home > Mailing lists > Public > www-tag@w3.org > August 2006

Re: TAG Issue proposal: URIs should not be hierarchical

From: Fernando Franco <avoid.spam.account@gmail.com>
Date: Mon, 28 Aug 2006 09:09:01 -0300
Message-ID: <003701c6ca9a$e0f4c5f0$eb8c31c8@enterprise>
To: "W3C-TAG" <www-tag@w3.org>
Cc: <noah_mendelsohn@us.ibm.com>




>> Fernando Franco:
> > URIs are names.
> > Names are not hierarchical.
> > Ergo, URIs should not be hierarchical.

> Noah Mendelsohn:
> Well, I respectfully disagree.

You are of course entitled.
But wouldn't you agree the that at the very core of the activity of
assigning names, is disambiguation?


>In the real world, many names are hierarchical.

But that is accidental, non-essential, historical, particular. Non-inherent
to the reasons for the very existance of the activity called "naming".

> For example, my own name reflects a grouping by family
> (Mendelsohn) within which I have a given name (Noah).

We could call you "person: 3466599583744775", and other than being a little
awkward, it would work, it would serve just about the same core
functionalities.
Even better, if we require global uniqueness from the very start.

You favor genealogy based schemes? I favour karma-level based ones. Others
geographical (Mahmud-al-Baghdadi, Mahmud from Baghdad), others religious,
etc etc.
Best, imho, is an arbitrary name, usable as starting node to navigate in ANY
possible way in the ontology. The URI is not the place to describe the
thing, or its relationships.

>I strongly suspect that the files on your computer have hierarchical names.

True. But not because I wish it.
Me, and a *very* fast growing ton of others, can't wait the seconds to get
rid of them, once and for all. Please see:
Filesystem sacrilege (Charles Miller, january 2003)
http://fishbowl.pastiche.org/2003/01/19/filesystem_sacrilege

Other keywords: winfs, gnome storage, hans reiser (reiser4). More half-baked
attempts by the minute. It's floating in the air.

> Sometimes such
> hierarchies are used in part to facilitate location of the resource, but
> in other cases merely to facilitate management of the names (my name
> doesn't do much to help you find me).

Requiere uniqueness and it will.

> In any case, URIs are designed in part to make it easy to integrate into
> the web existing as well as new information in computer systems.

Hierarchical filesystems are about to be wiped from end-users minds. (at
least as a metaphore of "files" and "folders"). Instead, "resources" and
"relationships", location.independant (at least to the metaphore level).
Gmail's motto: "Search, don't file".
Etc.

> The hierarchical structure available for URI facilitates the mapping of
> existing hierarchical names, as well as the assignment of new ones.

Re: existing hierarchical names, see above. Re: new names, algorithms for
creation of new names with arbitrary characteristics can be programmed, not
too difficult, many already exist, most common cases are trivial.


> Not all names are or need be hierarchical, but experience with systems
such as
> DCE/COM/OLE that use GUIDs or UUIDs has shown that opaque monolithic names
> have disadvantages as well as advantages in terms of convenience, etc.

Such as?

> Also, in practice, even GUIDs and UUIDs exhibit structure internally that
> has  degree of hierarchy (blocks of names are handed out in chunks, and
> several bits are reserved for sub-assignment within the chunks.)

Clueless here about what GUIDs and UUIDs are. My fault. However...
If really low level stuff, perhaps they can be hidden from end-users.
If substructure makes sense, perhaps the correct level to handle would be to
declare a datatype to handle it. (newbie alert here, might *not* be making
sense on this)
Received on Monday, 28 August 2006 12:10:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:41 GMT