The Atom Syndication Format 0.3 pre-draft includes description of the 'rel' attribute on the <link> element (i.e. <link rel="..." href="...">), which serves to describe the nature of the relation between the entry in question and a related resource.
The purpose of this proposal is to add a namespace-based mechanism for expressing the nature of the relation.
(Note - the original version of this proposal used the RFC 2731 mechanism for relationship namespace qualification. In the light of QNames in attributes in XHTML, it makes a lot more sense to use that form of namespace-qualification.)
Closed (superceded by PaceFieldingLinks)
Currently the relation has to be selected from a restricted list of possible values (start, next, prev, comments, service.post, service.feed, service.edit, alternate, related, transform, icon, source, via)*. There are numerous other relationships that could occur. In the current situation either the list will grow indefinitely or be closed arbitrarily. There is no compelling reason why the choices should be restricted to a specified list except for a danger of clashes between names. Fixed structural elements (the <link> construct) can be used to identify the entities and relationships in a constrained fashion, and XML namespace-qualified terms can allow arbitrary but unambiguous relationship identification, avoiding naming clashes.
If namespaces are used as described, the link element can be mapped onto RDF properties, providing a huge gain in interoperability and existing properties (such as foaf:depiction in the example below) could immediately be used within Atom.
* since the time of writing the list has grown to 19 terms that have got as far as recording on LinkTagMeaning. Various other (latest - 'about') have cropped up on list.
Essentially the current rel value list stays as it is, but extensions must be tied to a namespace (the current list would implicitly be tied to the Atom namespace).
<xxx> <link rel="yyy" href="zzz" title="aaa" /> </xxx>
Will be defined as expressing a directed relationship yyy between entities xxx and zzz (the subject xxx will most commonly be an entity defined in the Atom spec). yyy and zzz will be URIs (or be resolvable to URIs*), unambiguously identifying the relationship and object. The title, aaa can provide a label for the relationship.
Note that the 'href' name might be less than ideal - most of the time this won't be a clickable link.
*** OLD: Update references to link element in format RFC and API RFC to include the RFC 2731 mechanism along the lines of this proposed definition.
<feed ... xmlns:foaf="http://xmlns.com/foaf/0.1/" ... > ... <entry> <id>http://example.org/blog/post123</id> <title>Fear of Vegemite</title> <link rel="foaf:depiction" type="image/jpeg" href="http://rdfweb.org/people/danbri/2001/09/cam/danbri-vegemite.1000843912.jpg#" title="danbri with yeast extract" /> ... </entry> ... </feed>
to-do - example expressing info in http://del.icio.us/rss/
<entry ...> ... <link rel="tx:topic" href="http://del.icio.us/omit35/blog_mp3" /> <link rel="tx:topic" href="http://del.icio.us/omit35/music" /> ... </entry>
Validation based on the ennumerated value list would have to be modified/removed to avoid false negatives, although other applications that use the listed values will not need modification.
An additional attribute 'rev' i.e. <link rev="..." href="..."> has also been proposed, to enable the description of the same relationship but with the roles of the entry and the resource identified in 'href' reversed. It's probably a good idea, but isn't much use without the namespace extension mechanism, so is left for discussion at a later date.
The announcement that the next version of HTML is going to use QNames in rel puts this question to bed, I think. Using anything else in Atom would be hard to defend.
See also PaceRelationshipConstruct, PaceLinkRelExtension, PaceLinkRelUri