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

Re: TAG Issue proposal: URIs should not be hierarchical

From: Paul Prescod <paul@prescod.net>
Date: Mon, 28 Aug 2006 09:03:19 -0700
Message-ID: <1cb725390608280903l495f4746oe1c307325aef088e@mail.gmail.com>
To: "Fernando Franco" <avoid.spam.account@gmail.com>
Cc: W3C-TAG <www-tag@w3.org>, noah_mendelsohn@us.ibm.com
All of the participants in this discussion are independent actors who may
spend their time as they wish, but I see the discussion as entirely
academic. The most popular URI schemes ARE hierarchical because of the
existence of relative URIs. ".." means "up" which means hierarchy.

Relative URIs have proven to be extremely useful and helpful for hundreds of
thousands of Web authors. You have not made a case that relative URIs are
harmful or that the Web would be better off without them. In general, your
argument has not been grounded in any aspects of practicality whatsoever.

Furthermore, Microsoft has been promising to add a database layer (on top
of, not instead of) hierarchy for more than a decade. Please excuse me if I
don't believe that this year "must be" the year. ReiserFS has also been
around forever and has a hierarchical layer in any case.

On 8/28/06, Fernando Franco <avoid.spam.account@gmail.com> wrote:
> >> 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
> 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 17:20:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:13 UTC