The IANA link registry is a good enough place to hold this information, although it may be made even more easy to manage than to write to iana-assign for a new assignment. Whether that is a Wiki or something else, that could be discussed.
Oracle is certainly interested in putting together some kind of adjectives on Atom resources so that we can better predict the kind of operations that can be performed. For example, the edit and edit-media relations actually mean something beyond other link relations because I can actually manipulate those resources.
Likewise, the hierarchy-ID attempts to define a few new semantics for Atom resources that are, for lack of a better word, highlighted as being "master" or "detail" resources. The IETF RFC list is as good a place as any for recording these adjectives and the meanings of these. If there is a way to annotate link entries with such additional semantics so that we can use them even when people create separate rel values, we would love it.
Of course, I am approaching this from the perspective of a general library that wants to interpret standardized Atom extensions so that we can play a role when we are disconnected from the server. My blog talks a lot about this in the context of AtomDB [1].
Curious to hear what others think. Thanks to Eric for bringing this up and looking at it from a different angle.
Nikunj On May 14, 2009, at 11:18 AM, Erik Wilde wrote:
hello.i know this is a bit off-list, but i am looking for pointers and thoughts and opinions, so i thought i'll give it a try anyway...the recent discussions around link relations indicate a general interest to identify link semantics, right? and there seems to be a more general issue of not only identifying link semantics, but maybe generally possible RESTful interactions via links. for example, HTML forms use form/@enctype as a hint for what encoding has to be used for a form submission, and AtomPub uses collection/accept to indicate the MIME type(s). HTML forms use form/@method to indicate the supported HTTP method, in AtomPub it is implicit. in HTML and AtomPub, links are identified by the schema, but not in the markup.what i am wondering: would it make any sense to come up with something like xml:id for links? something that allows XML vocabularies to be generically RESTful by making links discoverable and also exposing some minimal information about how to access those links? after all, hypermedia is one of the core constraints of REST, and ironically, XML does not have a way of identifying links.for link relations, should there be just one well-defined list of values with a registry? should there be extensibility on a per application basis, via things like QNames or CURIEs (both of which have their issues because they're often not supported well in implementations).maybe we're all still traumatized by HLink, or REST does not need any generic link recognition and link-enabled vocabularies are good enough. right now, i am just interested in some feedback about the general idea of "making links and some link semantics discoverable".thanks and cheers, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 [email protected] - http://dret.net/netdret UC Berkeley - School of Information (ISchool)
<<inline: oracle_sig_logo.gif>>
Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650 506 0679 | Blog: http://o-micron.blogspot.com
Oracle Advanced Development Projects 500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
<<inline: green-for-email-sig_0.gif>>
Oracle is committed to developing practices and products that help protect the environment