This Pace specifies an "in-reply-to" relation for referring to the atom:entry "this" entry responds to (the "parent entry").
Revised: 19-Jul-2004 by KenMacLeod
Many entries are related to other entries as replies. Examples:
Comments on a post are replies to the post
Trackbacks on a post are replies to the post
Comments in a threaded comment system can reply to other comments
Google Groups now offers Atom feeds of Usenet groups. Usenet is threaded; posts can reply to other posts
Many people who maintain "recent comment" feeds currently put a link to the parent post within their content element (rendered as part of the HTML content), but it would be more useful to make this relationship explicit in a separate element.
The proposed relation would provide a way for feed publishers to establish that an entry replies to another entry, by linking to its parent entry. It would be up to each client to decide whether to render this relationship, and if so, each client can decide on an appropriate UI.
See MessageThreading for references on message threading.
See http://imc.org/atom-syntax/mail-archive/msg05639.html for an example thread and comparison with "entry feeds" and wfw:commentRss.
See atom-syntax thread for the discussion that prompted clarifying the relation name from "parent" to "in-reply-to". Subsequent discussion also strongly objected to implicit support of "distributed" replies, so this proposal constrains the defined behavior to only single feeds where all entries are present.
JournURL JournURL support
A threading plugin exists for Movable Type. http://mt-plugins.org/archives/entry/threadedcomments.php
Postnuke/PHPNuke does threading. Probably a bunch of other CMSes as well.
Manila sites: Hack The Planet
The new Google Groups 2 beta has atom feeds. See http://groups-beta.google.com/group/comp.lang.python/feeds for an example.
Add the following to section to the protocol draft -00 section, 3.4.1 rel:
[[ note: link construct markup and location of normative specification (protocol or format) are currently under discussion. This proposal is written in the style of the -00 drafts.]]
[[ note to editor: the definition of this is adapted from RFC 2882, sec 3.6.4]]
The "in-reply-to" URI will contain the atom:id URI of the entry to which this one is a reply (the "parent entry"). An atom:entry MAY have one "in-reply-to" link, but MUST NOT have more than one. Clients MAY use this link to display nested entry threads.
The "in-reply-to" URI can refer to an atom:entry or other resource that is not within the same atom:feed, however the mechanism for resolving these URIs is outside the scope of this document. An "in-reply-to" link that cannot be resolved SHOULD be considered as if the "in-reply-to" link were not present.
For example, if this entry is a comment on a previous entry, the "href" attribute URI will be the atom:id URI of the previous entry. If this entry is a comment in reply to a previous comment (in a threaded comment system), the "href" attribute URI will be the URI of the previous comment.
<entry> <title>First post!</title> <id>tag:example.com,2004-01-01:/blog/1</id> <author><name>Jim</name></author> <issued>2004-01-01T00:00:00Z</issued> <modified>2004-01-01T00:00:00Z</modified> <link rel="alternate" type="text/html" href="http://example.com/blog/1"/> </entry> <entry> <title>First comment!</title> <id>tag:example.com,2004-01-01:/blog/comments/1</id> <author><name>Joe</name></author> <issued>2004-01-01T00:01:00Z</issued> <modified>2004-01-01T00:01:00Z</modified> <link rel="alternate" type="text/html" href="http://example.com/cgi-bin/display-comments.cgi?post=1"/> <link rel="in-reply-to" type="application/atom+xml" href="tag:example.com,2004-01-01:/blog/1"/> </entry>
This proposal does not add any requirements for feed publishers. It allows publishers to explicitly state cross-entry relationships, but does not require them to do so. It allows clients to expose relationships between entries in their UI, but does not require them to do so.
See also : ThreadsML
Changes from 21-Jun-2004 (diff):
rename "parent" to "in-reply-to"
constrain defined behavior to "same feed", while leaving open future specification
remove description of linking to alternate media types
I think Atom should use the Dublin Core element <dc:relation>, as its semantics is already defined there. <dc:relation> also has the bonus that it defines other relation issues, like IsBasedOn (supersedes or «re-issuance» of resources) and such.
atom:in-reply-to: the atom:id URI of the entry to which this one is a reply (the "parent entry")
is a refinement of
dct:references: The described resource references, cites, or otherwise points to the referenced resource.
which in turn is a refinement of
dc:relation: A reference to a related resource.
Thus, atom:in-reply-to is a dc:relation. In the Dublic Core mapping we can indicate that atom:in-reply-to can be interpreted as a dct:references.