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/