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 uri-based mechanism for expressing the nature of the relation.
This is an updated version of PaceLinkRelMechanism
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 the use of terms constructed as URIs can allow arbitrary but unambiguous relationship identification, avoiding naming clashes.
The link element in this form can be directly 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, 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. Also 'title' is undiscussion. What have the Romans ever done for us?
<entry> <id>http://example.org/blog/post123</id> <title>Fear of Vegemite</title> <link rel="http://xmlns.com/foaf/0.1/depiction" type="image/jpeg" href="http://rdfweb.org/people/danbri/2001/09/cam/danbri-vegemite.1000843912.jpg#" title="danbri with yeast extract" /> ... </entry>
to-do - example expressing info in http://del.icio.us/rss/
<entry ...> ... <link rel="http://xmlns.com/foaf/0.1/topic" href="http://del.icio.us/omit35/blog_mp3" /> <link rel="http://xmlns.com/foaf/0.1/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.
Revised from PaceLinkRelMechanism, DannyAyers 2004-10-10
See also PaceRelationshipConstruct, PaceLinkRelExtension, PaceLinkRelMechanism