fwd from Atom WG list: "parent" vs. "in-reply-to"

The Atom WG list (an RSS-like snydication format plus HTTP-based editing
protocol) is discussing possibility of 'in reply to', 'parent' etc
relations. Annotea cropped up, and Ken just circulated this handy survey
of similar concepts so I thought I'd pass it along here. 

Dan

----- Forwarded message from Ken MacLeod <ken@bitsko.slc.ut.us> -----

From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 21 Jun 2004 20:23:05 -0500
To: atom-syntax@imc.org
Subject: straw poll: "parent" vs. "in-reply-to"
Message-ID: <m3n02w4c92.fsf@bitsko.slc.ut.us>


"Bob Wyman" <bobwyman@pubsub.com> writes:

> Ken MacLeod wrote:
> > As I read it, rel="parent" is a threading relation, 
> > "this entry continues the conversation in that entry".
> 	If it is a threading relation, why not use more traditional
> threading terminology like "in-reply-to" ... Why wouldn't Atom use
> the same words as mail does? Is there a difference in the concepts?

"parent" has been used traditionally on the wiki[1,2,3] and of course
in PaceLinkParent.  Since I too prefer "in-reply-to", or anything more
specific than "parent", I think it would be good to have a poll on
this.

I'm +1 on "in-reply-to" (moreso than "references")

I've collected some links on threading that may provide some
background.  I didn't find any adopted specs that use "parent", but
newer proposals, like ThreadML, RSS/RDF Threading module, and our
wiki, all seem to lean toward "parent/children".  If anyone has more
links, please post them!

RFC2822 -- Internet Message Format
http://www.ietf.org/rfc/rfc2822.txt
Section 3.6.4. Identification fields
defines "In-Reply-To" and "References"

    The "In-Reply-To:" and "References:" fields are used when creating
    a reply to a message.  They hold the message identifier of the
    original message and the message identifiers of other messages
    (for example, in the case of a reply to a message which was itself
    a reply).  The "In-Reply-To:" field may be used to identify the
    message (or messages) to which the new message is a reply, while
    the "References:" field may be used to identify a "thread" of
    conversation.

RFC1036 -- Standard for Interchange of USENET Messages
http://www.ietf.org/rfc/rfc1036.txt
Section 2.2.5.  References
defines "References"

    This field lists the Message-ID's of any messages prompting the
    submission of this message.  It is required for all follow-up
    messages, and forbidden when a new subject is raised. [...] If
    there is no "References" line on the original header, the
    "References" line should contain the Message-ID of the original
    message (including the angle brackets).  If the original message
    does have a "References" line, the follow-up message should have a
    "References" line containing the text of the original "References"
    line, a blank, and the Message-ID of the original message.

Dublin Core -- DCMI Metadata Terms
http://dublincore.org/documents/dcmi-terms/
defines "relation" (generic)
defines "references" (more generic than in-reply-to or parent)

    The described resource references, cites, or otherwise points to
    the referenced resource.

W3C -- Annotea Protocols
http://www.w3.org/2001/Annotea/User/Protocol.html#ReplyProtocol
defines "inReplyTo" and "root"

    Annotations are commonly thought of as comments that people can
    make about a Web document. To facilitate discussion about Web
    documents through the use of annotations, the Annotea protocol
    includes a separate class of resource called Reply. Replies are a
    mechanism that allows people to publish replies to annotations;
    for example, they allow someone to reply to a comment. Replies can
    also be made to other replies and thus promote threads of
    discussion. Moreover, as each reply is identified with a unique
    URI, the Annotea protocol also permits a client to annotate a
    reply.

    * "t:inReplyTo" whose value is the URI of the resource the user is
      replying to (in this case, either an annotation or another
      reply).

    * "t:root" whose value is the URI of the resource naming the start
      of a discussion (in this case, the annotation that was first
      replied to). This is used to identify a given discussion thread.


D. J. Bernstein -- Threading: Message-ID, References, In-Reply-To
http://cr.yp.to/immhf/thread.html
background info on in-reply-to and references in mail and UseNet

ThreadsML
http://www.threadsml.org/
http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML
defines "Thread" construct with a sequence of complete thread resources
defines "parent" and "children" properties for each resource
Are there any implementations?

RDF Site Summary 1.0 Modules: Threading
http://web.resource.org/rss/1.0/modules/threading/
defines "children"
Never adopted as it requires the parent to always know its children,
which is not practical in a distributed environment.


There are also specs which have further refinements of replies, such
as "agree" or "disagree", including IBIS and Annotea:
http://ideagraph.net/xmlns/ibis/
http://www.w3.org/2001/12/replyType (RDF schema that defines
  "seeAlso", "Agree", "Disagree", and "Comment")

  -- Ken

[1] http://intertwingly.net/wiki/pie/IsaCommentAnEntryDiscussion
[2] http://intertwingly.net/wiki/pie/RelatedDiscussion
[3] http://intertwingly.net/wiki/pie/LinkTagMeaning

----- End forwarded message -----

Received on Tuesday, 22 June 2004 04:42:54 UTC