Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Mon, Aug 31, 2009 at 8:59 AM, Noah Slater <nslater@tumbolia.org> wrote:

> On Mon, Aug 31, 2009 at 08:39:30AM +0200, Sam Johnston wrote:
> > That's an interesting idea - expanding on it:
> >
> > Link: <http://example.com>; rel="ancestor"; gen[eration]="1"
>
> Not sure if you intentionally changed it to "ancestor" here, but I
> certainly
> wouldn't want to start mint a new relationship name when "up" already has
> some
> modest use in the wild.
>

Existing use equates "up" with "parent" does it not?


> > Generation would be 1 for parents, 2 for grandparents, 3 for
> > great-grandparents etc.
> >
> > Another thing I saw before - nobody mandates that ancestry information be
> > reflected in the URL path segments so the suggestion to "reverse
> engineer"
> > ancestors from the URL fails in my mind.
>
> I wasn't suggesting some new and wonderful technique here.
>
> The "/" character has special meaning within a URI, as do "." and "..", and
> as
> much as we like to tell ourselves that URIs are opaque, folk wisdom tells
> us
> that we can usually treat them like UNIX filenames.
>
> Power users "hack" URIs to navigate, and there are browser extension that
> automate it for everyone else. My suggestion to base the depth information
> on
> parsing the URI has some grounding in current practice.
>
> Sure, you could be pedantic, and use UUIDs for all your URIs. And if you
> did, I
> guess you'd have a bit of a problem trying to represent hierarchy depth in
> your
> relations. How common is this though? And moreover, you could use the order
> of
> the relation to indicate depth.
>

The case I was thinking of was mail archives which tend to be flat (with
messages numbered sequentially), where ancestry relates to threading. Anyway
there will always be an exception - we did consider using UUIDs to identify
resources for OCCI (but abandoned it along with other restrictions, like the
ones you propose, on the URL structure).

Sam