Re: Link Relations: up/down vs parent/child vs ancestor/descendant etc.

On Sep 8, 2009, at 10:08 AM, Sam Johnston wrote:

> Evening all,
>
> I am busy designing a protocol for cloud computing[1] and want  
> clients to be able to discover children of a given resource in order  
> to navigate a tree structure. I had been considering defining a new  
> "collection" link relation but then found draft-divilly-atom- 
> hierarchy which defines a "down" relation.

This seems like a common purpose and I am glad you are discussing this  
on the ML.

>
> My concern is that the terms "up" and "down" are ambiguous in this  
> context and indeed we may end up defining [URI] relations for "up"  
> and "down" as state changes for network resources. Furthermore there  
> has been come commentary/confusion of late around the use of  
> multiple attributes (e.g. "up up up") and now seems as good a time  
> as ever to clarify given we have the link relation I-D and HTML 5 WD  
> on the table at the IETF and W3C respectively.

The draft-divilly-atom-hierarchy is aimed at strengthening the current  
registration of 'up' to encourage unrelated uses to use other values.  
As you may know the use of multiple link@rel attribute values is  
prohibited in Atom, and, hence, is not relevant to Atom. I do  
understand that some formats that do allow these kind of multiple  
valued attributes.

In any case, it would be good to discuss this now considering that  
Link Header [1] is in Last Call and proposes to take over Atom's link  
registry and HTML5 has also proposed a link registry. As it pertains  
to Atom, we have had a spirited discussion about the meaning and use  
of up and down. We could also call it 'asc' and 'desc' in case there  
is difference of opinion about the use of up and down in HTML as  
opposed to other formats.


>
> I wonder whether it would be possible to instead use "parent" and  
> "child" (for first generation relationships) or "ancestor" and  
> "descendant" (for more generic n-generation relationships, where n  
> is specified as an attribute like "level=2")? This is simple and  
> self-describing and could resolve the issue once and for all.  
> Alternatively the terms could be abbreviated to "asc" and "desc"  
> respectively (as in "ascend" and "descend").

You can look at the archives of this and the atom-protocol ML to see  
the various options we have considered for dealing with various levels  
of hierarchy. An approach we have favored to deal with multiple levels  
of hierarchy is a combination of hierarchy links "up" and "down" and  
inline representation. That allows one to expand as many levels as  
they like while retaining the exact relationship between entries and  
avoiding an infinite number of rel values.

>
> I also wonder whether "collection" isn't a bad idea anyway -  
> consider a resource describing a bookshelf where the collection  
> consists of books.

The term collection is already used in Atom by Atom Publishing  
Protocol [RFC5023].

>
> Sam
>
> 1. http://www.occi-wg.org/
>

Nikunj
http://o-micron.blogspot.com

[1] http://tools.ietf.org/html/draft-nottingham-http-link-header-06