Evening all, FYI - there's been some discussion about OCCI dependencies on other lists but I've been avoiding cross-posting given the audiences are quite different. The latest is about wiring resources together using generic link relations as it's preferable that we avoid rolling our own standards where we can use ones that already exist. Sam ---------- Forwarded message ---------- From: Sam Johnston <samj@samj.net> Date: Tue, Sep 8, 2009 at 7:08 PM Subject: Link Relations: up/down vs parent/child vs ancestor/descendant etc. To: Atom Syntax <atom-syntax@imc.org>, HTTP Working Group < ietf-http-wg@w3.org> 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<http://tools.ietf.org/html/draft-divilly-atom-hierarchy> which defines a "down" relation. 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. 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"). I also wonder whether "collection" isn't a bad idea anyway - consider a resource describing a bookshelf where the collection consists of books. Sam 1. http://www.occi-wg.org/