[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: straw poll: "parent" vs. "in-reply-to"
It's hard to vote in the straw poll when there isn't a clear definition
of what <parent> or is <in-reply-to> is supposed to be. At first I
thought it was just a way to show comments in a particular thread but
I've seen some claims in theis thread that it can be used to trace
conversations across weblogs which is very different. In the latter case
I believe both <parent> and <in-reply-to> are bad names.
--
PITHY WORDS OF WISDOM
Anything that begins well, ends badly. Anything that begins badly ends
worse.
This posting is provided "AS IS" with no warranties, and confers no
rights.
> -----Original Message-----
> From: owner-atom-syntax@xxxxxxxxxxxx
> [mailto:owner-atom-syntax@xxxxxxxxxxxx] On Behalf Of Ken MacLeod
> Sent: Monday, June 21, 2004 6:23 PM
> To: atom-syntax@xxxxxxx
> Subject: straw poll: "parent" vs. "in-reply-to"
>
>
> "Bob Wyman" <bobwyman@xxxxxxxxxx> 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
>
>