Edited by author 06-18-2001 04:33 PM
This is a spot for discussing the threading standard Steve Yost has proposed. An article in JOHO talked about it:
http://www.hyperorg.com/backissues/joho-jun17-01.html.

Dave, what about Radio Userland (http://radio.userland.com/)? All of the threads are in XML, XML-RSS is fully supported (and them some) -- it would really seem to fill the bill. Plus, you could set up your own feed, so there wouldn't be such a drought between tasty drips from your incomparable lips (!?>).

Stan

Edited by author 06-18-2001 07:54 PM
Doesn't Steve Yost cover this issue where he says (on his FAQ page):
"You can get something like threads -- branching a new topic from another -- if you use the "Start your own topic" link on your topic page, and select the "Link previous topic to new topic" checkbox. When you do that, a message gets created in the first discussion space that links to your new discussion, effectively branching off there. A link appears in your new discussion space back to the previous discussion, so you can easily jump between the 2 topics."
My first impression is this would improve on the usual threading where so often people ramble into a new direction but leave an older (now inappropriate) Subject heading on their messages: the dreaded "off-topic" malady.
Cheers, and thanks Dave for introducing QuickTopic in JOHO.
Bruce

RE: #2, Stan.

Which bill are we filling? Sorry, I have the attention span of a gerbil.

Stan, RSS (RDF Site Summary) is great for syndicating newsfeeds and similar sources like weblogs, and Radio Userland is great for gathering and publishing these feeds.

However, the message thread standard discussed here is about the following:
taking a thread of messages already posted among several people using a single app (like email or a bulletin board), and copying that entire thread to another compatible application or service.

Each thread consists of messages written by several people. We want to be able to save it and use it somewhere else, exchange it directly between two cooperating apps, or just archive it in a standard format.

Here's an example scenario: I'm in an IM session with someone, and the conversation ends up worth saving, and I'd like to involve other people too. So I save it (my IM client keeps a message log and allows me to save the thread in the standard format). I then create a Quick Topic forum pre-loaded with that conversation (QT supports the thread standard, allowing upload and download), and invite others. (Even better scenarios involve direct communication between IM and QT, or between email and a BBS, etc.)

In David's case, his web BBS went out of business (as many have), leaving him to copy and paste his messages; with a thread exchange standard, he could have saved them to disk in one step and uploaded them elsewhere.

The main questions in defining a thread exchange standard seems to be these:
What are the core set of attributes that make up a message thread? What are optional attributes that certain applications might want to support? For example, core attributes would probably include message author, message posting date-time, and message body. An optional attribute would be message title (note that RSS requires title, link, description, etc. because they're core to syndication).

Should the standard allow representing a hierarchy of threads? These occur often on threaded bulletin boards, newsgroups, and even in email (though they get pretty cumbersome in email).

I could really use the help of an expert in defining XML DTDs. I've created one before, but for a broad-based standard like this, an expert is called for.

Edited by author 06-19-2001 12:15 AM
David, the W3C Note that you cite in your article is about ways to use HTML to do the gawd-awful kinds of "threading" (really quoting) we all do in email when we reply and quote the previous message with '>' indentations or whatever. Here's the relevant excerpt:

Some applications of HTML Threading include (but are not limited to):
A mail UA may allow the user to specify and attach their own personal style to text that they author. (Note that this may be overridden, ignored, or even made invisible by the recipient.)
Formatting may be used to distinguish text written by various authors, or that originated in different messages. This formatting information may be provided by the sender of the message, or provided locally by the UA.

So that's an entirely different beast, and your proposal at the Kit Kat Club is still the world premiere.

Edited by author 06-19-2001 01:37 AM
I'm a little confused here: Hasn't USENET been threading messages (and cross-threading) for nearly 3 decades? years ago I built a prototype forum for a large telco and used NNTP as the underlying technology; the forum was really nothing more than the formatted display of multi-part mime messages (ClariNET was a contemporary example applying this to the news portal idea).

I figured people could use it like a blog (we didn't have that word then) or use a newsreader (which far too many still don't know how to launch let alone use) or they could even keep in the discussion via email/usenet bridging. Best of all worlds, I though, and yet, I couldn't interest any of my big clients ("No one uses USENET!") and in all the years since, I've only seen one other site use this method (a Linux news site).

what was so terribly wrong with using NNTP?

I do like the idea behind quicktopic, although I'd want an opensource implementation before I bet the farm on it (so I don't get caught out like a certain subscriber of CoolBoard that I know ;) ... and if I had the code, I'd be very interested to see how it might integrate with the RSS-based Peerkat to produce forums which have no central host.

RSS 1.0 has a proposed construct ("mod_threading") to describe the thread parent/child relationship structures. The key question (as Steve says below) is whether RSS has enough, or too many, other attributes.

My feeling is that, using Dublin Core, it certainly has enough expressivity; and that although the item title in RSS is a required element, a blank title is OK.

Threading spec: http://groups.yahoo.com/group/rss-dev/file.../mod_threading.html

Edited by author 06-19-2001 10:14 AM
Gary, let me be lazy and quote the NNTP RFC: "NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news".

As we'd apply it here NNTP (network news transfer protocol) could be used as a protocol for transferring threads of messages between apps, but what we really want is a spec for statically representing a thread, either on disk or as a payload during a bulk transfer. NNTP deals with nice things like only sending new messages, only sending headers, etc. The related RFC 850 specifies (among other things) how threads are actually represented: using the 'References' field in the message header. 'References' is an optional field, BTW, and it's up to the app to represent a thread using it. Here's relevant text from the RFC:

The purpose of the References header is to allow articles to be grouped into conversations by the user interface program. This allows conversations within a newsgroup to
be kept together... User interfaces may not make use of this header, but all automatically generated followups should generate the References line for the benefit of systems that do use it...

All told, RFC 850 looks like a good model to work from, choosing items as applicable from its required and optional fields. I like this: "The primary consideration in choosing an article format is that it fit in with existing tools as well as possible." That specific goal applies here; it's just a slightly different set of tools.

[Update: RFC 855 is superseded by RFC 1036]

Seems that we need a really clear statement of the goals and non-goals. For example, do we want the NNTP-like capability of choosing a range of messages by date, so we could support updating a thread from one app to another? That's the domain of a protocol, which we'll inevitably come to. We should work on the format first (RFC 850 came before NNTP [RFC 977]). Right?

Good grounding in related history is important. So thanks for making me take a closer look at NNTP & family sooner rather than later, Gary.

Next I'll look at your reference, Hugh. Though I think RSS is solving a different problem, I may find that Dublin Core (a good name for a nerdy drink -- Guiness and hard cider?) is applicable, though RDF and its meta-specs have made my head hurt (much like that drink would...).

I thought the Dublin Core was a standard for documents with an eye towards their management, including making them findable via metadata. Our semi-pre-proposed threading standard is more about messages and, especially, about their threaded relationships. The closest I can see in the Dublin Core Metadata Element Set is "relation":

 ---
  Definition: A reference to a related resource.
  Comment: Recommended best practice is to reference
               the resource by means
               of a string or number conforming to a formal
               identification system.

 ---
http://dublincore.org/documents/dces/

While msgs would obviously need an identifier pointing to the thread in which they're contained, we also need (or so we're claiming) a standard way of expressing the thread itself. For example, a thread can have an owner, may be open or closed, may have an expiration date, etc.

So, while I'm all in favor of building on existing work, and while I've long admired the aims of the Dublin Core group, I'm not sure I see a strong connection. Unless I'm missing something and/or things have changed. (Usually one of the previous two conditions obtain. Sigh.)

Edited by author 06-19-2001 11:29 AM
Here's a try at a philosophical summary:
A conversation, consisting of a set of messages among several people on a particular topic, is potentially an asset that's worth preserving. We want to assure that any participant in a conversation can easily save the whole conversation in one piece in a standard format. We expect these benefits:

• The ability to archive a conversation for later reference.
• The ability to transfer the conversation as a whole from one tool to another. Reasons may be that another tool becomes more appropriate (e.g. for widening the audience), or that a particular tool (e.g. a web service) becomes unavailable.

Does that capture it, David?

An open question is how we define the continuity and bounds of a conversation. A conversation is explicit in IM (all the messages in a session) and in Quick Topic (all the messages in a topic designated by the URL).
It may also be clear in large-scale web-based discussion forums where one explicitly posts within a specific topic area.
It's less clear in email and news, because a conversation thread is actually pieced together and represented by the client application (the email client or newsreader), using the optional 'In-Reply-To' or 'References' header fields, or if they are unavailable, the 'Subject' field. But because they *do* manage to do this, they can presumably allow the user to select an entire thread and export it in a standard format.

A related question regards the branching of threads within a conversation. What do we want to capture -- only a single linear thread, or a set of message nodes in a tree structure? In email and news, a tree structure is inevitable -- more than one message will have the same messageID in its 'References' field (i.e. the same parent message). Supporting email is reason enough to support the full tree structure.
Here's a proposal: Applications that can't represent a tree should "do their best" to represent it^*. That would mean that a round-trip (e.g. email to a BBS and back) might not preserve the original thread structure. The one-way interoperability is more important than round-trip preservation.

David, this may mean that messages simply have parent message IDs, not a thread ID, though the entire conversation would of course be encapsulated in a single bounding structure. WDYT? The other attributes you mention: owner, open/closed state, expiration date, are useful -- I think they'd be Optional attributes.

^*Quick Topic, for example, would represent threads using pseudo-threading: creating new topics that link to the main topic -- see the FAQ (bottom of page).

Good job capturing it. I'd add one more benefit bullet: The ability to extract additional value from the conversation, e.g., making it searchable or integrating it into knowledge systems. [Yes, I used the dreaded phrase "knowledge systems." Now I have to wash my mouth with a cleansing sorbet.]

Put aside the architectural question for the moment (because I am supremely unqualified to comment on it). It seems to me essential for "marketing" purposes -- and for clarity of purpose -- that we think of this as a standard for threads, not messages. I would think that this means that there should be a separate entity called a thread that has certain properties, including an ID, a title, permissions, etc. It may well be that the elegant way to architect this is to devolve those properties to the messages and thus not require that there actually be a thread-in-itself (Kant is spinning in his grave), but the user will think of the overall object as a thread even if it's just a linked list of msgs.

Further, yes, I think it has to capture all the msg nodes in a tree structure. The standard needs to be as robust and useful as possible so no discussion application will be left behind; this will be a measure of its success. I suspect that there's some fiendishly way enabling a simple architecture to capture indefinite complexity (the RDF standard does this, I believe), but that's not my department (says Werner von Braun)...

I am now done pontificating on that about which I know naught.

Yes, definitely, it's a standard about threads -- perhaps we should say conversations, since the things of interest may contain several branching threads. Anyway, it's the ordered aggregation of the messages that has the value. Let's keep that clear when conveying the marketing message (please pass the sorbet).

Is a conversation a first-class thing-in-itself? Does a conversation have an ID? Here's a thought experiment. Let's say you pick up an email thread that started last week and export it to a knowledge base. Next week I pick up a branch of the same thread that's diverged to another topic, but which contains some of the messages that you picked up. I export it to the same knowledge base. Your *framing* of one conversation and my *framing* of another conversation each added value to the respective set of messages. We'll probably each attach different keywords to our conversations and file them differently. Our knowledge base may want to recognize somehow that there are messages in common between the threads, or it might not -- that doesn't seem to be primarily important.

So we can think of these overlapping message *frames* (the conversations) as different entities, though we may (or may not) want to recognize the messages they contain as overlapping.
I still don't know if a conversation needs a unique ID (as messages do) -- what would the ID uniquely identify? My act of framing it? I guess so, especially when I've attached descriptive metadata.

Hmm, given the above arbitrary framing, I don't think that open/closed, author, or expiration date are useful after all. What do you think? The thing is, some tools (like QT and IM) start with a concrete conversation boundary -- others don't.

IMO, if I clip a branch of a threaded discussion and stick it on a different board or even stick it onto another branch on the same board -- something that I don't think any board lets you do now (?) -- I'd maintain that we now have two distinct threads. Yes, it would be good to know that msg B is a copy of msg A and that msg A lived in Thread A. But that's a complication that's at the fringe of what we're trying to capture.

I want to come back to the marketing side of this. We're proposing a way of preserving those things called "threads." As a user, I may want to do some operations on those threads such as delete them, rename them, store them, mark them closed, etc. Whether the architecture maintains a sep. thing called a "thread" is way beyond my competence. Whatever works ... so long as the end user gets a presentation of a thread-in-itself, even if it's totally derived from the metadata of its constituent msgs.

Edited by author 06-25-2001 10:31 AM
RadioUserland has been mentioned here before. I just wanted to add that it not only supports RSS but also OPML, an XML format made to handle outlines. It might be a start since it's threaded by nature.

See http://radiodiscuss.userland.com/howToUseTheOutliner

I think there's a page dedicated to OPML but I can't access any Userland sites right now.

Update: Userland is back online, here's the link: http://www.opml.org/

Thanks to Steve for inviting me to take part in this discussion. I've done a lot of work building formats in XML, RDF and RSS and I'd love to help out with the format. My initial thoughts (which seem to coincide with some of the other comments in this thread) is to go with RSS 1.0. Here's an excerpt from my message to him:


The first thing that comes to mind is to use RSS 1.0[1]. It's a
widely accepted standard for syndication, supported by tons of
platforms and products which means that you'll be able to follow
discussions in the format with tools like Meerkat, Radio
UserLand, Headline Viewer, etc.[2]. It's also supported by
ForumZilla[3], a discussion system for Mozilla as well as built
into SlashCode (the software that powers Slashdot and other
similar sites). It'd also give you a lot of parser support from
tools like XML::RSS, and Orchard-RSS.

RSS already has a comprehensive content module[4] capable of
sending content in all sorts of different forms. There's also
been some work on a threading module, which, if you're
interested in going ahead in this direction, I can try to
collect them and put them together into a module draft.

[1] http://purl.org/rss/1.0/
[2] http://blogspace.com/rss/readers
[3] http://www.zapogee.com/forumzilla/
[4] http://purl.org/rss/1.0/modules/content/

Aaron, looks like there's just a few of us subscribed (I get to look behind the scenes and see who :-), including David, so let me just ask what you think of my statements in message 5.

I assume you mean the issues you raised about RSS requirements. You wrote:

note that RSS requires title, link, description, etc. because they're core to syndication

First, RSS doesn't require description. Second, it's easy to automatically generate a title based on other things (time, participants, or just plain "Untitled") as well as *some* sort of link, for those feeds for which this doesn't make sense. I think the benefits of using the RSS format outweigh these costs.

Let's go with that thought and see what RSS does for us, keeping our goals in mind: a format for saving an entire thread of messages from one of several kinds of discussion apps, with the ability to import it into another discussion app.

There are the runtime goals (what the standard accomplishes for users of the apps that support it), and the adoption goals (the standard is more useful as more apps adopt it).

RSS has a great adoption advantage in already existing and being supported by several interesting (albeit syndication-oriented) apps.

My hesitation is the runtime goal -- i.e. what RSS is intended for. Syndication is about periodically gathering summaries of the latest items from one publishing node and publishing them within another.

But people use RSS for other things (probably following the same reasoning we're using here: it's out there and it works), and that's one thing that caused the push to RSS 1.0, using RDF instead of a DTD, as Edd explains here: http://www.oreillynet.com/pub/a/network/20...zine/rss_intro.html.

Edd's article helps me in another area too: my big concern about crafting a DTD is how to allow for extensibility and how to carefully choose which items are optional. RDF allows that more flexibly it seems, at the cost of introducing a new meta-level of description. Aaron, were you a part of the decision making regarding the move to RDF? What were the considerations?

---

OK, now let's flip and ask from the other side: if we were to create a DTD, is it feasible to produce a DTD that's flexible enough? Can DTDs be extensible? That's where your XML expertise is needed, if you'll allow the thought experiment of a non-RSS solution for a moment.

You know, I always work best with an example. Aaron, can you (or Dan Brickley, who's joining us -- welcome, Dan!) do a stab at an RSS example of, let's say, part of this thread?

You'll of course make some assumptions in mapping, so don't treat it as a formal proposal. I'd mostly like to get a better idea of how you use RDF to be flexible.

If you want to do it, say so first so you don't both spend your time on it (unless you want to of course -- it'd be interesting to see the variations).

First, yes, I was part of the decision to use RDF. The questions were whether there was the software base to support it (a major pro for RDF is the fact that Mozilla supports it natively), the benefits it gave us, etc. At the time I played Devil's Advocate and tried to convince them not to use RDF. (Needless to say, I wasn't too convincing.) Since we adopted RDF, I've begun to like it more and more, and now I am a member of the W3C's RDF Core Working Group.

DTDs are not really extensible. There are many "hacks" to add extensibility onto them, but they were designed in a time where one organization published a schema and you followed it... or else! Since then we have XML Schemas and Namespaces, which allow the freedom and extensibility that most applications. So yes, you'd certainly be able to build the threading standard out of XML Schemas and Namespaces, but XML Schemas are rather complicated, and I haven't been able to really study them so I can't help you too much there.

One of the big benefits of RDF in a threading scenario, is how it provides distributed and decentralized power in a very easy-to-use way. Because it's all based upon URIs, it would be easy for someone else to make their own feed which referred back to a URI in someone else's as its parent. So, in other words, they could respond on their site to a discussion on someone elses. This would allow other people to easily join in on a discussion in a decentralized manner. Obviously, the format could still maintain privacy, etc. through other means.

I'll start in on an RSS model of this discussion -- it shouldn't be too hard.

Edited by author 07-24-2001 11:58 AM
Here's a short example. You'll have to imagine that there are more items (one for each message posted). Let me know if things don't make sense:


<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:c="http://purl.org/rss/1.0/modules/content/"
  xmlns="http://purl.org/rss/1.0/">


<channel rdf:about="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss">
  <title>Threading Standard (JOHO)</title>
  <link>http://www.quicktopic.com/7/H/rhSrjkWgjnvRq</link>;
  <items>
   <rdf:Seq>
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p20.20" />
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p19.19" />
   <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p18.18" />
   </rdf:Seq>
  </items>
</channel>

<item rdf:about="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p20.20">
  <title>Steve Yost: Threading Standard (JOHO)</title>
  <link>http://www.quicktopic.com/7/H/rhSrjkWgjnvR...0</link>;
  <dc:date>2001-07-24T5:29Z</dc:date>
  <c:items><rdf:Bag><rdf:li><c:item>
  <c:format rdf:resource="http://www.isi.edu/in-notes/iana/assignmen...dia-types/text/html" />
  <rdf:value><![CDATA[
You know, I always work best with an example. Aaron, can you (or Dan Brickley, who's joining us -- welcome, Dan!) do a stab at an RSS example of, let's say, part of this thread?<br />
<br />
You'll of course make some assumptions in mapping, so don't treat it as a formal proposal. I'd mostly like to get a better idea of how you use RDF to be flexible.<br />
<br />
If you want to do it, say so first so you don't both spend your time on it (unless you want to of course -- it'd be interesting to see the variations).<br />]]>
   </content:item></rdf:li></rdf:Bag></content:items>
   <thr:parents>
    <rdf:Bag>
     <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p19.19" />
    </rdf:Bag>
   </thr:parents>
</item>

...

</rdf:RDF>


Hmm, QuickTopic seems to have lost the spacing... but you get the idea.

> One of the big benefits of RDF in a threading scenario, is how
Did you mean RSS?

> Because it's all based upon URIs, it would be
> easy for someone else to make their own feed which referred back
> to a URI in someone else's as its parent.

That's a really interesting capability, but not part of what we're initially after. Of course we should think forward, but balance that with the immediate task at hand: importing and exporting of entire threads between apps. Which reminds me, there was something in one of Edd's papers about a 15-item limit. Is that true and applicable here?

BTW, to me "feeds" implies dynamically changing threads. We need to deal with discussions that may be long-finished. But there *is* also the question of what happens on successive imports (see previous messages): Should matching by the importing app eliminate duplicates? Should the exporting app be able to export certain date/time ranges? The answers needn't be in the standard itself (which is a format standard), but they should be considered in the assumed usages.

> I'll start in on an RSS model of this discussion -- it shouldn't
> be too hard.

Great! I look forward to it.

No, I really meant RDF. It's a benefit RSS gets too, since its based on RDF.

The 15-item limit is no longer true. It was an artifact of Netscape Netcenter, which has been deprecated.

Feed is just the generic term for an RSS file.

Duplicates can generally be easily recognized by their URI, and eliminated. Time ranges sound like an interesting feature, but I wouldn't say they're mandatory.

And I've posted the RSS version below.

Excellent, Aaron -- your example really helps. Looks like we're just about done!

Seriously (not that the above isn't necessarily true), you now have my full attention about its applicability. I'm convinced I should read up thoroughly on RDF and RSS to tow my end of the conversation. I'll be away for two weeks, probably disconnected. Can you recommend a set of pages to read?

I have a rusty familiarity with XML, even designed a DTD (pre-namespaces) about 4 years ago. I have only a cursory understanding of namespaces and RDF.

One small question about your example: when bringing it up in IE, it complained:
Reference to undeclared namespace prefix: 'thr'. Line 31, Position 14
<thr:parents>

Is thr a new namespace you're positing for this usage?

> Can you recommend a set of pages to read?

Well, for RDF and the Semantic Web, I'm all too eager to suggest my own:
http://logicerror.com/semanticWeb

For RSS, the spec is probably your best bet, but some of the
resources at:

http://blogspace.com/rss/resources

might be useful, although many are out of date.

> One small question about your example: when bringing it up in
> IE, it complained:

Oops, there should be a:

xmlns:thr="http://purl.org/rss/1.0/modules/threading/"

up with the namespaces.

Edited by author 07-24-2001 01:37 PM
Now that I've understood your RDF, I'm going backstage to remove the formatting that makes this page so wide (the bane of these web boards -- I could parse every message searching for long words and do the wrapping, but I'm concerned that would impact scalability too much).

(And you'll note that the spacing comes back. Quick Topic preserves the spaces, but your browser doesn't when it sees a pre tag, and QT doesn't mess with anything inside pre tags.)

Given Aaron's RDF example, let me ask an obvious/dumb question. I think we want to have thought through a default set of metadata about the thread itself as an object. E.g., a thread may be owned, may be open or closed, may have start and end dates, etc. RDF enables that list of metadata to be extended, but I assume (in the form of a question) that we want to propose a default list. Yes? No? Huh?

Yeah, for our format it's probably good to propose a required list of metadata. We can say that metadata that meets this standard is a "ThreXML file" or something.

Oops. Before where I said semanticWeb readings, I meant to point to:

http://logicerror.com/semanticWeb-long

As an exercise, I've gone ahead and implemented RSS following the example you gave, Aaron. You can see the rss by just tacking .rss onto the end of any QT URL. For example this topic:

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss

If you're using IE, you should should see the nice collapsible XML representation.

It currently ignores any message ranges you provide and always gives the entire list -- that can be easily fixed. I'm not sure it always does the right thing in the CDATA sections. Feel free to create your own topic and try to break that.

I also ignored the thr: section because I'm not sure your example conveys the meaning of "parent" that we want. Wouldn't it refer to a parent thread, where the current thread was branched from another one?

A starting point at least!

OK, so we're done! Excellent! :)

Now comes the hard part: Naming it.

threXML.com and .org are available
threadsML.com and .org are available

I prefer the threadsML because it's explicit and has a whiff of marketing cleverness about it. (I'm in favor of marketing cleverness.) In fact, I just registered it -- to protect it, not to preempt the discussion. (I suffer from Impulse Registration Syndrome.)

> I also ignored the thr: section because I'm not sure your
> example conveys the meaning of "parent" that we want. Wouldn't
> it refer to a parent thread, where the current thread was
> branched from another one?

Well, you probably know more about QuickTopic threading than I
do, so I'll let you make the decision.

> A starting point at least!

More than a starting point, I think it's a great step forward!

> Now comes the hard part: Naming it.

threadsML sounds fine to me.

Edited by author 07-26-2001 11:26 AM
Aaron, I'm looking through the rss-dev documents at http://groups.yahoo.com/group/rss-dev/files/Modules/.

Would one possible outcome here be simply the definition of a new module, say for example mod_messagethread, with its own messagethread namespace? I'm looking at mod_slash as an example; it simply introduces four elements of its own, and shows an example of their usage in context with other existing elements.

It may be the case that we don't even need any new elements -- we might simply define the semantics of using the existing elements in the message-thread-exchange context. Right?

BTW, gotta go soon, so I might not see your answer unless it arrives here by noon EDT.

Yes, you are right on.

> Right?

Straight on.

Delurk: threadsML & threadsML.com sound good to these ears too.

[Side note to those suffering from IRS: Tnx to a pointer from the Keithster, I've found that I can score good cheap domain from dotster.com w/o all the ugly a-holity of NotworkSolutions. Probably not nooz 2 u.]

Aaron, in reading at least two of the RSS 1.0 documents, there's a mention of RSS being applied to threaded messages. Are you aware of any preceding usages or at least contexts in which it was discussed?
(BTW I'm still away, but connecting occasionally.)

> Aaron, in reading at least two of the RSS 1.0 documents, there's
> a mention of RSS being applied to threaded messages. Are you
> aware of any preceding usages or at least contexts in which it
> was discussed?

Yes, and I discussed them earlier in the thread. (In summary:
the Mozilla client, and similar projects.)

I'm having trouble finding an RSS 1.0 reader that will work for QT, after trying several at
http://blogspace.com/rss/readers

I picked up the ForumZilla extension, but it won't show up as advertised under the Tasks menu of Mozilla.

Amphetadesk won't show the feed from my test topic. (It claims to support RSS 1.0, so I'm wondering if it's my RSS text that's the problem).

Feedreader crashed.

Figby had results similar to Amphetadesk.

Userland's RSS validator complained about a missing description element, but it apparently only supports 0.9x versions of RSS.

Help?

It would be desireable if any corporate required disclaimers, could be omitted from the "thread".
Have many threads, where the disclaimers exceeds the
message content by order of magnitude.

Disclaimers by reference! In fact, we could do the world a favor by writing a generic disclaimer -- disclaim everything from innocent mistakes to original sin -- and post it somewhere with a short url.

I'll work on it :)

Edited by author 09-10-2001 02:13 PM
David, thanks for inviting me. Without wanting to derail what looks like progress here...

I wanted to contribute that Andrius Kulikauskas of the Minciu Sodas laboratory < http://www.ms.lt/ > has done a fair amount of work thinking about how to create an interchange mechanism between personal knowledge management systems like TheBrain, MindManager, etc. and the companies that make them that is probably pertinent to the discussion here. Part of that work is the 0.1 draft of MindSet < http://www.ms.lt/mindset.html >. I think there may be more; I'll invite Andrius to see if he has more to add.

Just a tiny bit more expansively, some of my own thought on the ordering of small information nodes (like messages in a thread, or "thoughts" in TheBrain): I'd like to be able to link them in different sorts of structures such as those in MindSet, and be able to choose from a variety of ordering styles when viewing/browsing them, such as the examples listed at < http://www.usemod.com/cgi-bin/mb.pl?IndexingScheme >.

Pete < http://www.istori.com/peterkaminski/ >

I worry that this may expand the project to the breaking point, for TheBrain allows completely arbitrary linking of its elements. But it sounds as if we ought to keep this in mind so that the threading standard could perhaps be expanded to cover cases like TheBrain.

Or am I overstating the difference in the two models?

David Weinberger writes,

>Or am I overstating the difference in the two models?

Yes. And no. :)

I would envision this threading model as a special case/subset of a more general information node/link structure, so I would design it in that context.

OTOH, I think a reasonable threading model that is useful and used now is a terrific goal, and while I've only skimmed all the messages in this topic, it looks like you're on the right track.

I guess I would counsel a little research on knowledge representation before getting too far down the development track, but to then push all that back and go ahead and get things done.

In that spirit of research, perhaps I can contribute a little more entropy (but please don't let this derail development!):

TouchGraph < http://www.touchgraph.com/ > is in active
development. Wouldn't it be cool to be able to represent a set of threads in it?

Stephen Danic, developer of Lucid Fried Eggs < http://www.memes.net/ > seems to have a ThoughtStream-format XML export option; see for instance < http://ms.memes.net/index.php3?request=exportXML > or (a much longer one) < http://www.memes.net/index.php3?request=exportXML >.

Hypermail < http://www.hypermail.org/ >, a venerable old tool that turns individual RFC822 messages into a set of hypertext.

CritSuite < http://crit.org/ > supports annotation of arbitrary web pages; this is similar to "replying" to a web page. It has the ability to be fine-grained -- wouldn't it be cool if replies in a thread could similarly be fine-grained references to the original?

Phylogeneticists use various methods "parsimony methods" <
http://helix.biology.mcmaster.ca/721/outline2/node50.html > to
reverse-determine a hierarchical tree of ancestors based only on examination of the extant descendants. I can imagine an analysis tool that helps produce a better thread hierarchy based on similar methods.
A list of "Tools for Organizing Thoughts," (TheBrain, MindManager, etc.) at Minciu Sodas: < http://www.ms.lt/ms/projects/toolkinds/organize.html >.
Doug Engelbart / Foresight Institute web enhancement project: <
http://www.bootstrap.org/colloquium/sessio...ssion_04_jones.html >, < http://www.foresight.org/WebEnhance/ >.

Xanadu < http://www.udanax.com/ >: Here Be Dragons.

Pete

Hi Peter, David, Steve, All,
     I think this ThreadsML is a great idea.
     I've organized Minciu Sodas, a laboratory for "caring about thinking", serving and organizing independent thinkers. Our first endeavor was to develop an import/export standard for tools for organizing thoughts, and we got some funding from http://www.thebrain.com and http://www.mindmanager.com The idea is that we should be organizing thoughts instead of documents, and that, for example, the tens of thousands of thoughts that Jerry Michalski has invested in his PersonalBrain should be free to move amongst various tools.
     So far we've had some good (and basic) ideas for a draft http://www.ms.lt/mindset.html but no success at implementation or funding. For us, I think the trick is to find a very simple application that has mass appeal. That's why I think ThreadsML is great, because it affects a lot of people.
     The angle that I tried, through the Infrared Data Association, http://www.irda.org was "IrDAKiss". The idea was that we should have a way of sending organized clusters of file attachments (via email, floppy, Palm, etc.). I thought that this might appeal in IrDA because they've sold hundreds of millions of devices, but actual usage is in the low percentiles, especially across differing devices. My reasoning is that beaming is a hassle, and should be done for packages that have great personal value, because they've been put together with care. Beaming is a social act, a "kiss", hence "irdakiss". Beaming is the most personal way of transfering electronic information. Anyways, I was able to start up an IrDA working group IrFLOW (Flow of Experiences) for this, but couldn't find any real interest, so it was stopped. But I think sending clusters of file attachments is another example of how a standard for small clusters could open up the way for large masses of semi-organized thoughts.
      Another example (with mass appeal) is organizing boomarks.
      Myself, I'm interested in an all encompassing standard, but happy for any progress made. I don't know, though, if anything less can actually work.
      Partly because what I learned (from IrDAKiss) is what I really want is a modeling language, rather than an import/export format. Mindset addresses that, it says that there can be many different implementations, the key is to describe, and educate ourselves, as to the different ways that we make use of structured information, based on the structure that our minds put on it. (Note that you can't figure out the structure just by looking at it - because what looks like a sequence may be intended to be a hierarchy or network, etc. or what looks like a circle was intended to be a sequence).
      Best wishes, I'm interested if we can help, and I've informed our working group OurOwnThoughts@yahoogroups.com
      Andrius Kulikauskas
      Minciu Sodas
      http://www.ms.lt

Another small contribution. Ka-Ping Yee, the guy behind CritSuite, proposed a small hack for threaded email lists to make them easier to display. (I'm explaining this from the memory of seeing him present it a year or two ago, so I hope it's close to what he meant!)

It consists of two ideas, the first being that if you take the first (real) sentence of a reply, you generally get a pretty good message summary. Even better summaries, if you let users see that's what you're going to do.

The second is what Ping called "criticons"; he uses the same ones as at crit.org: + means support, - means criticism/issue, # means comment, and ? means a query. Basically, you train users to put a criticon at the (real) beginning of their replies.

Once you've done that, you can post-process to get something like he mocked up at < http://web.lfw.org/ping/criticons/ > -- a cool summarized hierarchy at the left. The right panes are the message view of the currently selected message.

Pete

Edited by author 09-14-2001 12:10 AM
Hooray, I finally had a moment to get Userland's RSS validator (which validates for .91, I believe) to work with QT's RSS. Peter, I was actually motivated to do this by a mention of you on another list.

Part of the quote: "With mirroring, XML, peer-to-peer, and other technologies it should be possible to disseminate credible information across multiple sites in order to reduce to the load on well-popularized sites such as the redcross.org."

So I'd like to offer Quick Topic as a possible resource. I'm not sure it's ideal (who knows, maybe it is) for the uses you have in mind, but let's talk about it offline (syost@quicktopic.com), or start another topic here.

To see the RSS using IE, just add ".rss" to any QT discussion URL.

All that was needed beyond the previous version was a description element for the channel. It's strange that W3C's experimental validator still complains about the c: namespace not being recognized. I think it's adequately declared as the content namespace.

Edited by author 09-14-2001 12:12 AM
I've read your other posts Peter and Andrius. I haven't had a chance to think about them or explore. Intriguing though. Off-topic, I've always thought that QT would be a good way to add possible discussions to any thought-node in The Brain. I mentioned it to Jerry Michalski, but he didn't pick up on it.

Edited by author 09-14-2001 09:31 PM
Cool! The test thread is now showing up at My Userland's aggregator:

http://my.userland.com/viewChannel$4644

Thanks to Jake at Userland for putting it through the approval process.

Now to make those headlines a little more interesting... :-)

I'm wondering if I should include the first sentence as a description.

Here are some properties a thread-object (say, do we still get to use the "threadsML" moniker for this thing?) might want to preserve. (I've put the iffier ones are towards the end.)

thread name (human readable!)
thread owner/administrator
thread start date
thread closed/open (= new msgs accepted or not)
thread closed date
thread/msg public/private
who has permission to read thread/msg [I don't know how to handle this]
who has permission to contribute to thread/msg [ditto]
attachments
language
description/topic
category
rating [R, PG-13, etc.]
sponsor
importance [urgent, etc.]

Just a starter list...

Oh dear! Somehow or other I got knocked off the notify-by-email system for this thread. I'd thought the project had died but I'm glad to see there's still life.

My friend Morbus Iff (creator of AmphetaDesk) pointed me here, and also pointed out that Steve has a session at the P2P Conference scheduled:

http://conferences.oreillynet.com/cs/p2pweb2001/view/e_sess/2125

I'm hoping to attend that conference (I'm definitely interested in it now), so let me know if there's anything I can do and feel free to post an update on how things are coming.

Good to hear from you, Aaron. Hope to see you there -- my mug is on this page; so you might have a chance to spot me in the crowd: http://www.quicktopic.com/acknowledge.html

I'll be there around noon on the 7th and flying out that evening.

Edited by author 11-04-2001 09:57 AM
I've asked the conference folks to post the abstract too, but here it is for now (thanks to David for editorial work):

Message threads -- conversations -- are at the core of much of the Internet's value, but until now they haven't been given the status of objects. The lack of a message thread exchange standard has kept the Net's conversational currents apart. An implemented standard will make it easy, for example, to escalate any instant messaging session or email interchange into any threaded discussion forum. In this session, we will for the first time discuss "threadsML", a standard under development that will give us the power to save any conversation, move it to another venue, share it as a whole, aggregate it with other message flows, attach it to any web object, or intelligently archive it for reference ("grassroots knowledge management"). This session will present the status of threadsML and will discuss the role of distributed web services in supporting the intended result of universal flexible, portable conversations.

Forgive me if I'm restating the obvious...two points...

First, I've always thought that individual messages should be able to live on more than one thread. For example, a thread is started by a newbie to ask "how to X". Discussion ensues and someone finally writes up a "good" answer. An administrator should be able to link that good answer into a FAQ thread for permanent reference, without removing it from the thread on which it first appeared.

Second (which I think you are already considering), is that it should be simple to CC: the thread on an email and have the email added as a message to the thread.

/m96 The inclusion of a msg on more than one thread is an important feature for the std to capture. It should be able to share the msg as a link or as the actual content.

The second point you raise is important but, as I understand it, is a feature to be implemented by an application (say, a mail reader or discussion manager). Since threadsML would capture the addresses of the contributors to the thread, the information would be there for the application to use in the way you describe.

Edited by author 11-18-2001 03:02 PM
Hello All,
I am very interested in the issues being discussed here. Instead of writing a very long intro post, let me give the basics. I will stay up to date on new postings and try to be as active as I can.

My company is http://www.GAZM.org . Our tagline is "Constant Intellectual Stimulation." Our first website went live in January of 2001 (http://www.GAZM.org/Previous). It went offline with the Sep 11 attacks (the server was down there). Instead of rushing to get the site online I took a month to rethink things. The previous site was Flashy, got a lot of press (http://www.GAZM.org/news.html) and some cool partners (New Line, 20th Century Fox, Absolut, etc.). However, it didn't really achieve my vision for the company.

I want GAZM.org to be a place where people can share and collaborate on their creativity and imagination. I want to make money by creating strong relationships between users and companies. For example, our first partner, HMV Record Stores, instead of putting up a crappy ad saying "come buy music," launched on GAZM the world's first "Living Music Chart." Users voted on a constantly-changing music chart and the top 5 vote-getters every 2 weeks went on sale in all HMV stores (in special GAZM displays). It was very cool and got a lot of attention - moreso than any run of the mill ad campaign would ever get.

Right now - I am no longer working with those who worked on the previous site. I built what you see now online MYSELF. I am neither a programmer nor a designer. I am now interviewing and working with professionals to make it better and improve upon the technology. This new site is getting daily what the old site would get in a week. People like it. The site allows anyone to upload their creations and leave any message they want. No accounts, no ads, no crap. Obviously as part of the process I will have to introduce things like accounts and ads but I never want to repeat the old site's short-comings.

So what I am most interested in researching are interesting navigation methods for user uploads and using ThreadsML for a more robust discussion forum (instead of the current glorified guestbook).

Ok, sorry for writing such a long post after I said I wouldn't. I hope I was able to convey who I am and what I'm looking for. GAZM is a playground for the mind and I am open to experimenting with interesting and provocative navigation and inspiration technologies.
All the best,
Jacob Shwirtz
AIM: Shwirtz

Jocob, what I saw was impressive (to say the least :)

If you have an email list regarding your sites, please do put bernies@mergetel.com on it. I'd like - often need - to be reminded of those websites I'd like to return to.

Hi,
ThreadsML is really a good idea. I also saw the XML format(RSS 1.0 with some namespaces) that QuickTopic is supporting right now.
I have a question regarding this standard. This standard can only support a message board that don't have multi-level threads (I mean, no sub threads), like the ones in QuickTopic. But say, if I already have a message board which has this sub-threads format then how can I use this standard.
Please let me know that whether this Threading standard has multi-level threads support.

Thanx in advance,
Amit

Amit ( /m60 ) - Yes, the aim of threadsML is to support hierarchical, nested, multi-level threads as well as flat threads such as QuickTopic. That support will be in the very first version of the standard.

Hello,

In the next few weeks my website will be making the giant leap from ASP to PHP. In translating the existing code we will be adding a slew of new features. I am wondering if this process can include a migration to ThreadsML. Here is my non-programmer head speaking - is the standard ready to be implemented? Is it still "under construction"? Is it ready for me to actually use on my user-generated content website?

Keep fighting the good fight,
Jacob Shwirtz
http://www.GAZM.org

The standard is still under construction, but don't let that stop you. I recommend early experimentation similar to what's implemented here (add .rss to any topic URL and you'll see). This represents individual linear threads. Tracking inter-thread relationships will likely be just a superset of that.

Edited by author 02-28-2002 06:27 AM
I know I'm late in the discussion, but I think David's article touches upon a great point. In my few years' work within KM, I have arrived at the conclusion that the survivability and portability of a discussion thread is a critical success factor of any online community.

As a matter of fact I've been working for some time on a discussion engine which would store everything in XML - and only in XML, one thread per XML file, in human-readable file structure, to support that principle.

The advantages are obvious:

1. Wanna move threads to another site? Just grab all your XML files and off you go.
2. Wanna move a thread to an FAQ? Just copy the thread file to the FAQ directory and it's done.
3. Wanna make a personal backup of a forum? FTP down your XML files. Ready!
4. Wanna start a thread with a news article? Just copy that article to the forum directory and you have your thread.

For those who are interested, I there is a test version going "Live" at http://ipmsstockholm.org/forum/test/ Most messages there are in Swedish, but please feel free to test and your own messages if you like. If there is more interest, I can also show you my XML storage format.

Martin Waligorski
mailto:martin.waligorski@guide.se

Edited by author 02-28-2002 09:07 AM
I like the sentiment behind your implementation, Martin. We're here to propose and work for agreement on an XML standard so threads can be exchanged between all complying apps. You'll see in this thread that we're heading towards an implementation based on RSS 1.0, which is RDF-based.

Any contributions you might have on the standard in particular are welcome.

This has nudged me to post a summary of where I think we are -- coming shortly.

Edited by author 05-22-2003 10:33 AM
It's time to go further with a concrete proposal. Awhile back, David Weinberger, Rael Dornfest and I had an impromptu conference call to gather agreement on the motivations and priorities for the standard. My notes are slim, but one key point was how to deal with threading. Some applications implement branched threads and other like are linear or have pseudo-threading like Quick Topic.

Technical summary:
• Use RSS 1.0 and require the standard Content module. (for example see Quick Topic's current RSS format). Optionally use the Dublin Core module for added details.
• For optional threading, use the proposed Threading module to represent parent-to-child relationships and use the Annotation module to represent child-to-parent relationships. [Its description answers any reservations about its name: "Provides support for resources that annotate, follow-up to, or reference other resources." (my italics)] If you want to support threading, both are required, but support for threading is optional.

Question: Where applicable we want to represent relationships within the XML file rather than pointing back to the original resource (so the file alone would be sufficient for an import operation). How does a child node refer to another item within the same file? How does it refer to a specific item in a different resource file? I guess it comes down to "what's the granularity of a resource in the RSS 1.0 framework"?. (The same question applies to parent pointers.)

Use case
ThreadsML should be able to support the following:
A user exports a thread from a source application that supports threading. He defines its boundaries in whatever way the the application provides. The thread may include forked branches, i.e it may have a non-linear, branched structure (though there is an underlying chronological sequence of messages). The export is saved to a file.

a. He then imports that thread file to a destination application. The destination application only supports a linear representation, so it presents the messages chronologically. At the thread boundaries (in this case before the first and after the last message), Previous and Next links in this application can optionally direct the user to particular messages in the source application from which the thread was originally exported (i.e. there should be enough information in ThreadsML to support this).

b. Later, the user exports another thread from the source application, picking up chronologically exactly where he left off before, and imports it to the destination application. The destination application recognizes the first item in the new import as the successor to the last item in the previous import and represents this appropriately to the user.

This is all an extension of the conversation I mentioned, and while it owes almost everything to the other participants, they aren't accountable for my extrapolations from it. This is all flexible and in the works. Feedback is welcome. I'm especially hoping to hear from you, Aaron, but all others too.

Hmm, actually looked (albeit briefly) at the specifications you reference.

So...is an RDF channel the equivalent of a QuickTopic? Then in a channel are elements...which (with the threading module) can have children. So at this point we have the single-level equivalent of QuickTopic. If I understand...and I'm really skimming this stuff quickly.

I'm not seeing the equivalent of a "Thread" object, but then perhaps that isn't actually necessary. You can always think of the threads as being defined by all messages that have no parent messages (roots of the lattice, as it were). But wouldn't there be a need for information attached to the threads themselves, necessitating actual thread objects?

Then I keep thinking that there absolutely must be some sort of unique ID for messages/threads. Otherwise what happens if a user imports the same message/thread twice into his/her repository? You don't want stuff duplicated, right?

But then I start thinking about what to use for a unique ID and my head starts to spin. The closest I get is some sort of URL (from the RDF/channel/BBS, whatever) coupled with a unique sequence number that can only be generated (supposedly) by the owner of the URL. So the user then imports messags with URLs not connected with the user. And if the user is bad and removes them...well then my head actually hurts.

Regarding the "how does a child node refer to another item in the same file question," it seems like there is plenty w/in XML to provide for that. I've approached XML by way of XSLT, mostly, but certainly the use of ID and IDREF attributes allows items in an XML file to be linked during XSLT processing. Shouldn't this be sufficient? Especially if we assume unique message IDs? Then there's the whole XLink thang, about which I understand little.

But it is late and I'm probably not thinking this through. Interested in any thoughts whatsoever, glad to see some progress continues.

Edited by author 04-01-2002 09:15 PM
Marc, sorry it's taken awhile to get back to you on this.

A thread for our purposes is any arbitrary linear time-sequential series of messages in a particular forum on a particular topic. It can have zero or more branching points within it, and not all messages on all branches need be included. For example, let's say we have a tree-structured thread with many small branches and sub-branches. I can pick up all the messages from 3-Jan-2002 to 4-Apr-2002 on one arbtirarily selected depth-first traversal through the tree and call that a thread. I can also pick *all* the messages between those dates and call it a thread, though it has many branches. The idea is that I should be able to export an import either of these structures.

Yes, there's a need to identify each message in a thread. That's currently done via the identifiers in the <items><rdf:Seq> section of the document. Each item in the sequence has a URI (e.g <rdf:li rdf:resource="http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p1.1" />). That works fine for Quick Topic, where each message does have a URI. But what about email, for example? In email, each message has a Message-ID, which would suffice for tracking successive import/exports.

The purpose for the ID is to manage successive export/imports from one particular source to one particular destination (e.g. email to Quick Topic), not to be able to (for example) transport threads arbitrarily to many services and gather them up again later. So a globally unique ID isn't necessary.

Are we being too short-sighted or just expedient? If we need to, can we choose a unique naming later? Duplicate messages with different IDs will be floating around in various services. Is that OK? Maybe we should say that the original ID (which may be service-specific) should at least be preserved and identified as such. I like that. So, say I start with email, move the thread to QT, then move it on to Topica. The export from QT should include the original email Message-IDs.

Oh, and regarding intra-file parent-child node references, yes XML has ID and IDREF. My question is what we include in our particular threadsML schema in this regard.

Thanks for your thoughts, and for helping to keep *this* thread moving.

*thread-merging from offlist discussion - the formatting may go astray.*

> Have you had any more thoughts about the unique naming? I'm especially
> interested in the ideas around moving from one service to another.
> Say, taking a thread from email, to Quicktopic, to a blog, to IM and
> back to email again. Off the top of my coffee addled brain I can see
> all sorts of very interesting visualisation applications here -
> graphically travelling down threads, and so on. As the thread gets
> longer and more branched, the very structure gets as interesting as
> the content.
>
> Again, off the top of my head, giving a *topic* a guid would allow for
> multiple services to syndicate conversations off each other. Add in
> Publish and Subscribe, and you could follow a slashdot thread (which
> itself is a branching of a quicktopic discussion) using an IM client,
> which is talking to a usenet gateway... Ahh - braindumpy, that, but it
> could be very powerful. Especially if you add in enough dc and rdf
> stuff and make them searchable: "find me all the conversations where
> Rael and Dave discussed football" "find me all the conversation
> points, where Rael replied to Dave in Spanish, about the History of
> the Walkman, and where he was using Jabber"
>
> Gnutellaish searching between conversation services: ooooh.

And my email response:

Yes! In fact I've been mulling about the necessity of the similar tools
among weblogs: e.g. the ability to search in weblog-only space or following
links in both directions. For weblogs these exist (and I think they ought to
be snapped up by Google). For web-based message threads, they should exist,
including the idea of thread-hopping you mention. The example of searching
you give is an great (if extreme :) specimen of the intelligent search I'm
thinking of.

Given your input in addition to Marc's, I'm starting to think that it's worth the trouble(?) of adding to the RSS spec to allow for unique IDs (unless there's a module that includes one now). The IDs could be just GUIDs or they could contain information about the originating site. Maybe a separate identifier should denote the orignating site.

Ben Hammersley writes,

>very interesting visualisation applications here graphically travelling
>down threads

Alex Shapiro has a very nice applet for generalized visualization of networks that might be nice for a highly-branched, multi-service group of related threads: TouchGraph <http://www.touchgraph.com/>;.

It's inspirational, at least, to play with such a nice visualizer -- my favorite application so far is the Google Similar Pages Browser.

--
Pete
http://www.istori.com/peterkaminski

If one of the goals is to grab any arbitrary set of messages (say by topic and time frame) and call that a thread than I wonder if we _can_ assign an ID to a thread. It's like assigning a unique ID to a SQL query.

I think we can only assign an ID to a thread that is published somewhere. That is to say, if I have a forum and I decide that these 18 messages constitute a thread it can have an ID which is a combination of my forum's ID and some unique identifier in the context of my forum. Or I can allow any top-level message (not in response to an existing message) to define a new thread. Or whatever.

If you then come along and pull a subset of my thread, that query is not in itself a new thread. If you then publish the results of that query on your own forum then it becomes a new thread, but in the context of your forum.

A little like the distinction between an XML node or document and an XML node list, which is somewhat ephemeral.

---

I have also been thinking about graphical tools for viewing threads and messages. Here's an additional twist:

Consider mind maps and other graphical idea organizing tools. Wouldn't it be great if a set of messages on a forum (possibly/probably in multiple threads or even in multiple forums???) could be viewed/organized as a mind map?

Use case: we all decide to actually build the specification for ThreadML. We go in and organize all the message traffic herein into a mind map (or whatever model makes the most sense). We then add messages to the nodes in the mind map, filling in the (now obvious blanks). From there we create a second projection of the underlying data, which is an outline of the projected specification document. After that, writing the document should be easy (or at least not so hard).

I found a nice site with a lot of different "mind map-like" diagrams but I can't find the linkage right now.

> If one of the goals is to grab any arbitrary set of
> messages (say by topic and time frame) and call that a
> thread than I wonder if we _can_ assign an ID to a
> thread.

I think you can - you just have to make the ID extensible:
the id represents not just the message's URI, and it's position in the thread and the UID of the discussion itself (ie. the ultimate root post), but also the UID of the most root-post post on that system...

So if I grab a branch of a thread and use it elsewhere, it may look like a new thread - it may even act like a new thread, but the UIDs of new messages would contain the UID of their post-split root post, which in turn contains the UID of the original root post.

This would also allow the newly created thread, made from the cutting so to speak, to eventually be reassociated with the genuine root post, with everything in its right place.

Does that make sense?

> I think you can - you just have to make the ID extensible:
> the id represents not just the message's URI, and it's
> position in the thread and the UID of the discussion
> itself (ie. the ultimate root post), but also the UID of
> the most root-post post on that system...

I'm probably not following you, but it sounds like the UIDs would keep getting longer and longer. Or that they would refer to previous UIDs (which would in turn refer to other UIDs) which would mean that the entire set of UIDs would need to exist forever or the ancestral data would be lost.

I agree that we want to keep the provenance [sic] of each message and thread and so forth. I'm just unsure how it happens efficiently.

Perhaps an example would clarify this? In your copious free time. ;)

> I'm probably not following you, but it sounds like the UIDs
> would keep getting longer and longer.
>
> Perhaps an example would clarify this? In your copious free
> time. ;)

You're right - they would keep getting longer and longer. But they would never be that long, and the additional utility would be of greater value than the cost of another 20, say, characters.I'll try and get an example going. But even with enormous amounts of thread branches, I've a feeling it could be done with a minimum of fuss. It just needs an *evil*
encoding scheme. Well, it's worth a thought or two anyway. I'll give it a go.

Question for everyone: how many characters should a UID have max? 20? 50? 100?

Edited by author 05-06-2002 03:51 PM
Try this on for size...

Let's say I have a forum at http://www.Doorways.org/Forum/DarkKnight. On the forum are a ton of messages which would be identified as http://www.Doorways.org/Forum/DarkKnight/0001 or some such. These are unique IDs. Thread IDs would look like http://www.Doorways.org/Forum/DarkKnight/Thread/0001. Again, unique IDs.

You come along and ask for all messages from http://www.Doorways.org/Forum/DarkKnight/Thread/0023 from April of 2002. You get back a structure like:

  <thread id="http://www.Doorways.org/Forum/DarkKnight/Thread/0023">
    <message id="http://www.Doorways.org/Forum/DarkKnight/0691">
      Yeah, well Batman could beat up the Green Lantern
      ANY day!
    </message>
  </thread>

Now you put the messages on your site, under your forum: http://www.ComicNerds.net/Forum/Batman/Thread/0187.

Let me suggest that you store, for each message, the _original_ id (e.g. http://www.Doorways.org/Forum/DarkNight/0056). This original ID should _always_ remain with each message since it unique identifies it across all time and space. So if a third party grabs your 0187 thread including my message they'll get something like:

  <thread id="http://www.ComicNerds.net/Forum/Batman/Thread/0187">
    <message id="http://www.Doorways.org/Forum/DarkKnight/0691">
      Yeah, well Batman could beat up the Green Lantern
      ANY day!
    </message>
    <message id="http://www.ComicNerds.net/Forum/Batman/0123">
      Green Lantern would whip his butt!
    </message>
  </thread>

So if the thread eventually makes its way back to the original http://www.Doorways.org/Forum/DarkNight forum the message(s) that have originated there will be re-matched properly.

What happens if the original forum is disbanded? Well, the URL is still unique. The message is uniquely identified. If it shows up on some other site from two different message pulls it will not be duplicated. Keep in mind that XML namespaces work this way, they don't necessarily represent an actual data object on a site (though they often do point to a schema file), the URLs just specify unique IDs for the namespaces.

The only problem I see here is if the forum is _restarted_ and the same unique URL is assigned to a new message. Of course, this could be easily handled by simply checking messages with matching IDs to see if they actually match.

Now I don't see this scaling to thread IDs. For one thing, the query may only pull part of a thread. For another, the thread changes over time (I'm assuming that the message doesn't, but that's probably open for discussion). So if you pull my entire Thread/0023 and place it on your site as Forum/Batman/Thread/1117 it shouldn't necessarily have an original ID of DarkNight/Thread/0023.

Off topic, but easier...

Since blogthreads are neither simply chronological nor hierarchical, a map that shows all the links among them is likely to become less useful as it becomes more comprehensive. Once y'all have solved the hard problems, do you think it'd make sense to consider having an attribute that codes for "direct reference" or "main reference" or some such? For example, if C replies to the outrageous lies in A, but in passing mentions that B's blog entry also shows that A is lying through his teeth, it'd be nice to know that even though C mentions both A and B, C is really replying to A.

Other attributes that capture relevancy and popularity (e.g., "found this blog entry helpful" as per a discussion with Ben Hammersley) would be useful for whatever apps decide to make these threads visible. It might be useful to have some set of such attributes built in, in addition to of course having the standard be extensible. But this is why I don't write standards.

> It might be useful to have some set of [link] attributes
> built in, in addition to of course having the standard be
> extensible. But this is why I don't write standards.

XLink will provide a lot of extra information on links. For example, an XLink can have a "role" attribute that specifies a URL that identifies some aspect of how the link would be used (TBD, so far as I know).

On the down side, XLinks are _really_ complicated to use and probably force a bunch of other design decisions. Like how would they be specified when submitting a message.

Right, following a nice cigar and a walk of the dog, here's my tuppence worth for the night:

First, some assumptions:

1. At the time of writing, a message knows only his parents. It can have no knowledge of his children.
2. A message has One parent.
3. Parsers can traverse the message tree.
4. The only thing you are sure to know at the time of writing your message is a) The Parent Message, b) The Thread ID and c) The Time 5. You can only look back in time

Soooo....

We define these terms (keeping with the tree metaphor for now, and in this hierarchy)
1. The Root UID - Which is the same as the Message UID of the First Post
2. The Cutting UID - Which is the Message UID of the First Post *known to the new host*, when part of the thread has moved to a new host 3. The Parent UID - The Message UID of the Parent Post
4. The Message UID
5. The Time

For the First Post of the thread, all of 1-4 are the same. The Root UID never changes for any of the messages.

Ok, so the first message is this:
<item>
<root uid="http://example/1"/>
<cutting uid="http://example/1"/>
<parent uid="http://example/1"/>
<message uid="http://example/1"/>
<time value="202002T202020Z"/>
<title>...
<link>...
<description>...
</item>

And the second message is this:

<item>
<root uid="http://example/1"/>
<cutting uid="http://example/1"/>
<parent uid="http://example/1"/>
<message uid="http://example/2"/>
<time value="202002T202520Z"/>
<title>...
<link>...
<description>...
</item>

And the third, in reply to the second:

<item>
<root uid="http://example/1"/>
<cutting uid="http://example/1"/>
<parent uid="http://example/2"/>
<message uid="http://example/3"/>
<time value="202002T203020Z"/>
<title>...
<link>...
<description>...
</item>

Now say this goes on for a while, and some rascally blogger comes along and grabs a chunk of the thread, and posts it to their site. The next reply at that site would be:

<item>
<root uid="http://example/1"/>
<cutting uid="http://rascallyblogger/1"/>
<parent uid="http://example/47"/>
<message uid="http://rascallyblogger/1"/>
<time value="202002T212020Z"/>
<title>...
<link>...
<description>...
</item>

And the next one there:

<item>
<root uid="http://example/1"/>
<cutting uid="http://rascallyblogger/1"/>
<parent uid="http://rascallyblogger/1"/>
<message uid="http://rascallyblogger/2"/>
<time value="202002T202020Z"/>
<title>...
<link>...
<description>...
</item>


And so on.

To reinsert this cutting, or to make sense of it, all the parser has to do is transverse the tree back up to the Cutting UID, where it finds the cutting point (The Cutting UID's Parent UID) and then continue on its way.
If messages are lost, well you're stuck anyway, but at least you have the Root UID and Time to give you a clue as to the general idea.

If you want to refer to more than one site in the reply, that's cool - use the DC:isRelatedto or DC:refersTo - that's fine, as threading is inherently 2 Dimensional you can't give more than one Parent.

If you want to give some form of approval metric - as per David
Weinberger's message - then insert this as a sub-element inside the element you are referring to eg:

<root
uid="http://example/1"><approval:metoo>true</approval:metoo></root>
This can, of course be used on all the URLs you refer to:

<root
uid="http://example/1"><approval:metoo>true</approval:metoo></root> <parent
uid="http://rascallyblogger/1"><approval:metoo>false</approval:metoo></p arent>
<dc:isRelatedto
rdf:about="http://othersite"><approval:metoo>true</approval:metoo></dc:i sRelatedto>


Erm...that's all I've got so far...
Thoughts?
Ben

Edited by author 05-06-2002 10:53 PM
Ben and Marc, your examples help a lot (being a bear of little brain, I work best with something concrete). One telling statement was this:

> On the down side, XLinks are _really_ complicated
> to use and probably force a bunch of other
> design decisions.

... from which I'll take the lesson "don't let ThreadsML become too complicated, (like XLinks) or people won't want to implement it" :-)

Let's revisit the use case that Ben started with:
> ...giving a *topic* a guid would allow for
> multiple services to syndicate conversations off each other.

Syndication implies to me that there's an authoritative source for the items, and others are simply re-publishing. For that I don't think thread IDs are necessary, only message IDs that identify the source. Syndication only requires a publishing schedule, which is covered by the RSS 1.0 Syndication module. So let's isolate "syndication" as a use case and say we've got it covered. Is that correct?

Then, there's this:
> Add in Publish and Subscribe, and you could
> follow a slashdot thread (which
> itself is a branching of a quicktopic
> discussion)...

This implies that a thread can be appended at its copied-to site (a QT-originated thread, copied to and appended at Slashdot, in this case). So far message IDs will still suffice. One question at this point: can a thread be spliced into an existing thread in its new home, i.e. can it be re-parented? I think not. A defining use case: I do a web-wide search using a search engine that understands ThreadsML and I find a message in a thread. I should be able to follow the thread up and down its hierarchy (at the search site); going down along different branches may lead to different sites, but going up should lead only to one site. Note that given the unique message IDs, the search engine recognizes identical messages and gives me the best one (probably at the originating site unless it's down).
So, at the destination site of a thread transfer, the thread should be considered some kind of root.
Does that make sense?

And finally, Ben adds
> you could follow a slashdot thread
> ...using an IM client, which is talking
> to a usenet gateway...

The IM client implies what I meant way way back by "tool independent messaging" (I think I said that here). That implies to me an inter-tool protocol for live connections, which is beyond the data standard for exchange. But you could say that the data standard will be the payload of the protocol, so should support live inter-tool messaging. Let's say I'm reading and posting to a particular Slashdot thread via IM. The IM client gets the thread from Slashdot (starting with some date and message ID) and populates the IM client. I then post a message. Do I need a thread ID? I think I just need a parent message ID when posting. The parent message ID that Slashdot provides should (by our definition) be sufficient for Slashdot to locate it and post a reply.

Marc added another use case:
> So if the thread eventually makes its way back
> to the original http://www.Doorways.org/Forum/DarkNight
> forum the message(s) that have originated there
> will be re-matched properly.

That is, a round trip back to the originating site. This is similar to successive export/imports in the same direction between two sites, in that proper matching has to occur. Again, message IDs suffice, I think.

What's required for some of these cases is that the importing site maintain the original IDs of the imported messages if it ever exports them again. Should we make this a requirement for anyone to claim full compliance? It adds a storage onus. I don't think it should be a requirement because I think basic one-way, one-time export/import is a big value at a reasonably low cost to implementors. So maybe we should have different levels of support:
ThreadsML export (hohum)
ThreadsML import (hmmm)
ThreadsML round-trip (maintains message IDs) (woooo)

Note that the search engine example (a pretty powerful application, I think) requires that sites be able to deliver up ThreadsML with original message IDs. So ThreadsML round-trip (maybe we should call it ThreadsML Complete) is at least strongly encouraged for web-based sites.
Does this make sense, or do I have a big blind spot?

It's late and the last two messages require some in-depth thought so this isn't my full response thereto. ;)

I think that Steve and I are both saying that unique message IDs solve most of the issues. It's the idea of moving threads around that makes head-scratching.

I'm going to go out on a limb and suggest that the entire concept of a thread is a single example of a view or query on a set of messages. That is to say, if we consider a forum to be equivalent to a relational database table, then a thread is a formalized view on a forum in the same sense that a SQL query can be formalized as a view on a table.

What I want to point out is that threads are only one possible example of such a view. Another might be an outline. Or a Wiki. Or a mind map or other graphical overlay.

So what would it mean to take a collection of records from a table in my database and give it to Steve? Would the query on my database equal the result of the same query on his? And if so at the time the new records are entered, what about a week later, after new records are entered to both databases? The answer is going to tend to be 'no', and I think the same holds through for moving threads.

Moreover, the most useful forum software is going to allow me to go in and change threads. So after Steve takes all the threads on Pizza out of my recipe forum I may go back and re-classify some of the messages he took as Calzone recipes and move them to a different thread. So now some of the messages he took are marked with an originating thread that no longer contains those messages, even in the originating forum.

Another angle is Ben's assumption that a message has only one parent. I actually assume the opposite. My example is a thread on a computer-related site. A question is asked, beginning the thread. Over a week 22 messages respond and the last one actually sums up the issue very nicely. As a forum moderator, I want to be able to place the summation message onto a separate FAQ forum or thread, but I don't want it to disappear from the original thread. Thus it has two parents (and may live on multiple forums, as well).

What I'm trying to get at here is that threads are ephemeral and tracking the messages by originating thread may not make a lot of sense. Unique message IDs are doable and necessary, but thread IDs are problematic and of limited utility.

In addition, re-reading my example above, it may be that even the concept of a forum (or topic in QT) is similarly arbitrary. But I'll not go there just yet...

---

BTW, just because XLinks are complicated is not a definitive reason to avoid them. I agree, it's a telling statement (and a knee-jerk reaction). They're complicated because they're powerful. I brought them up because they seemed to answer the question posed.

What we may need to do is provide uplevel and downlevel options. If you go downlevel, you get the usual HTML anchor tag with no frills. If you go uplevel you get XLink links with full specificity. Of course, that's even more complex...so I think I'm fried and I'm a'gonna stop now.

> Another angle is Ben's assumption that a message has only one
> parent. I actually assume the opposite. My example is a
> thread on a computer-related site. A question is asked,
> beginning the thread. Over a week 22 messages respond and
> the last one actually sums up the issue very nicely. As a
> forum moderator, I want to be able to place the summation
> message onto a separate FAQ forum or thread, but I don't want
> it to disappear from the original thread. Thus it has two
> parents (and may live on multiple forums, as well).

Just quickly, before I have any coffee this morning, this is incorrect: the FAQ post does not have two parents - it might have two children, but that's not the same. The FAQ's post's one singular parent is the message it replied to, which is message 21 in the previous thread in this example. Its children live in different neighbourhoods, that's all. This is not a problem under my scheme (in fact, it's the whole point of it). Moving a message to a separate thread just starts another Cutting UID.
So the original message 22 (the above example) is this:

<item>
<root uid="http://example/1"/>
<cutting uid="http://example/1"/>
<parent uid="http://example/21"/>
<message uid="http://example/22"/>
<time value="202002T202020Z"/>
<title>...
<link>...
<description>...
</item>

And the FAQ thread root post would be:

<item>
<root uid="http://example/1"/>
<cutting uid="http://faq/1"/>
<parent uid="http://example/21"/>
<message uid="http://example/22"/>
<time value="202002T202520Z"/>
<title>...
<link>...
<description>...

Note that the Parent UID is the same in both these cases.

And any subsequent FAQ post would be:

<item>
<root uid="http://example/1"/>
<cutting uid="http://faq/1"/>
<parent uid="http://example/22"/>
<message uid="http://faq/2"/>
<time value="202002T202520Z"/>
<title>...
<link>...
<description>...
</item>
</item>

Mmm sweet sweet caffeine,
Ben

Edited by author 05-09-2002 09:23 AM
Marc, your suggestion of a thread as a database query is a really useful talking point, because it forces a better definition of the domain we're considering.

I'd like to say that, for our purposes, the discussion domain we're considering (from which we extract threads) is not an arbitrarily sortable set of messages -- that they do indeed have a definite inherent sequential order, and for that reason each message is at least *potentially* a reply to a previous one. (In a branched threading model, each one is more specifically a reply to its parent.) We might be able to superimpose different views on top of it, but they're secondary views.

I think if we try to accomodate a more general domain than that, it forces ThreadsML to be more complex than we want.

I think a message has one parent at any specific time (and in almost all cases to date, the parent doesn't change). If a discussion tool were to allow reparenting of an entire thread (I don't know of any that do), then if its designers wanted to support round-trip (again I think there's a lot of usefulness short of supporting round-trip, and most tool designers will start short of that), then it would need to keep track of thread reparenting and do the appropriate mapping.

All that said, I still think message IDs suffice.

Another point worth summarizing: if round-trip is to work (and I still need convincing that it's a primary goal of the spec), it requires that

1. Every non-originating host of the message thread needs to preserve message IDs between the import and the export, and the originating host of course shouldn't change message IDs.
2. The originating host of the thread needs to preserve the original sequence of the thread (no reparenting), or at least be able to re-map it via message IDs (and that gets hairy, but since nobody does reparenting, it's not a big problem.)

What do you all think? Is that satisfactory? I'm continually trying to balance forward-thinking completeness with the likelihood of getting the spec implemented by a few important players.

And thanks again. This exchange is really useful.

Ben, I must be thick, or just lazy. I still don't see the need for a cutting uid. Can you give me the specific use case?

> Ben, I must be thick, or just lazy. I still don't see the
> need for a cutting uid. Can you give me the specific use
> case?

I think so. Imagine a thread. Take this one, for example. Now say I want to take this posting, and move it over to my own site, and use it to start a separate thread. That's cool - and by giving it a separate Cutting UID, it allows that new cutting to be semantically linked with this main thread here at Quicktopic:

A reader of my site, looking at a message at the cutting thread, can then go either

A) straight to the message referred to by the Cutting UID - ie the message I transplanted - and hence from there (via it's Parent UID) to the original conversation at the point just before cutting it.

Or

B) Straight to the original Parent of them all - represented by the Root UID.

Or

C) one up, to the Parent UID

This might seem a little like overkill - in that in simple cases, just tranversing up the tree will get you everywhere quickly...But, the longer the thread, the less fun that is - and having a cutting UID allows you to take cuttings of cuttings of cuttings. An additional line, or hopping across hundreds or <item>s?

Well, I think that's right, anyway. Ah. Yes.

Ben

Well, I'm still convinced that threads are an artifact and it is important for messages to be sited in more than one thread if necessary. Note that my first (?) posting here (/m56) states this second point and there was even a message (/m57) agreeing with me (which happens oh so rarely ;). It's something I feel strongly about.

On the other hand, we are talking about ThreadsML, not MessageML. Perhaps I'm holding out for functionality that rightfully belongs in a different standard.

One way to look at that would be to examine the way XHTML is breaking down into core functionality and extensions. So everyone would implement the core behavior but extensions would be available as required for additional behavior.

Consider doing the same here:

    MessageML core message format and IDs
      InstantML extension for instant message behavior
      MindMapML extension to organize messages into
                       mind maps
      OutlineML extension to organize messages into
                       outlines
      ThreadML extension to handle thread behavior
        MThreadML thread behavior with multiple ancestors
      WikiML extension to handle Wiki-like behavior

For me, this is perhaps the core of the issue. Threads are one way of organizing messages. It is the most prevalent, and people are going to keep building forums that way for a long time. It's a natural and useful organization.

But what happens when we want to cut out messages from this QuickTopic and move them to a Wiki where we're building use cases for the spec? What happens when we want to organize the Wiki messages into an outline for the spec? How can we support moving messages between different organizational structures in a meaningful manner?

On the other hand, as you say, trying to think too far ahead may paralyze the entire process.

Looking through old links, I found a couple of examples of other people thinking about how thread archives should/could work. While perhaps not of immediately specific applicability, I think both of the following present thinking useful to the discussion here:

Ping et al.'s Criticons / Discussion Mapping for Mailing Lists -- some thoughts about automatic overviewing of threads, and gentle hints posters could give such a system:
example: http://web.lfw.org/ping/criticons/
description: http://web.lfw.org/ping/pubs/chi-2002-mailmap.pdf

"Robust" pointers to documents or even intra-document locations, including some ideas and technology for the case when the location pointed to isn't under your control and may change:
document ("robust hyperlinks"):
http://www.cs.berkeley.edu/~phelps/Robust/index2.html
intra-document ("robust locations"): http://www9.org/w9cdrom/312/312.html
---
Pete
http://www.istori.com/peterkaminski/

Edited by author 05-09-2002 10:30 PM
[Boy that was confusing as first written. Let me revise:]Ben, the parent ID of the first message in the ThreadsML file is its original parent's ID. So your site, if it wished to, could allow navigation back there somehow. If your site wished to represent it with a new parent that's on your site, it could provide that natively, regardless of ThreadsML. However, it's worth clarifying that if your site were to later export that thread somewhere, it should include the original IDs, *including* the original parent ID.

Now I think I may have unintentionally graduated from thick to stubborn :-)

---

Marc, by using RDF-based RSS1.0 as our basis, we do in effect have the ability to create these variations. So we can say that we're focussing on the ThreadsML variation right now, and this amounts to specifying the usage of modules (and maybe inventing a new one) that layer over the core RSS1.0 modules.

When we're done (or even before then) someone else can specify all the other things you mention, also based on RSS1.0.

I originally had qualms about using RSS1.0 as the basis because it's about message summaries and syndication, but I was convinced that the modularity of it and the fact that existing tools are available were winning factors. /m66 gets specific about module usage.

Does that address your points?

Probably...I just keep avoiding really learning about RSS. Every time I try to read the specification I get lost. It keeps looking like a specification for a specification...like a double-de-referenced pointer...and my little brain gets boggled.

Edited by author 05-09-2002 10:24 PM
Yes, sometimes it seems as though people are trying to out-meta each other :-) I had that reaction too on first reading about RDF. The meta stuff goes higher than that, too, but I won't go there.

David Weinberger blogs humorously about the "I'll see your meta and raise you one" phenomenon today, recommending it to young essay writers: http://www.hyperorg.com/blogger/archive/20...chive.html#85074433

The best way to understand, for me, is by example. I was most clued in when Aaron first gave me an example (way early in this thread), and you can of course see one by just adding .rss to the end of the URL for this thread.

Oh, yeah, blogs...yet another variant on a collection of messages...

Might be good to start this process by generating all the use cases we can think of and drawing the line 'twixt in and out. Would probably work well in a Wiki.

Speaking of which, seems to me Wikis allow editing of existing messages. Wow, what does that imply? Uh, oh, I've Meta'd out again...

Well, blogs are covered. They're the original usage for RSS. (That and news sites). Wikis, I think, are outside the domain of interest of ThreadsML. (Aside: there's a cool module for one of the Wikis that creates RSS for the latest-changes page of the Wiki.)

Edited by author 05-09-2002 10:57 PM
But you mentioned setting up a wiki. That's probably a good idea at this point. I'll set up a Wiki here at quicktopic.com for it. I'll probably use UseModWiki because I already have it installed for the old version of my weblog (http://www.quicktopic.com/blurcircle -- the wiki is linked at the right hand side). Any objections?

[One thing you'll note is that my blog wiki doesn't allow edits. That's my hack, which I'll of course remove for the ThreadsML Wiki.]

OK, here's the Wiki: http://www.quicktopic.com/cgi-bin/thwiki.pl. Let's see how this goes. I'm not sure how soon I'll have a chance to do the organization.

The problem with considering blogthreads -- much as I'd *love* to see them covered by threadsML -- is that they are definitely hyperlinked, not hierarched (??): one entry may be the originator, but after that entries can have more than one parent.


-- David W.
-----------------------------------------------------------
David Weinberger* 'zine: www.hyperorg.com
self@evident.com blog: www.hyperorg.com/blogger
Home: www.evident.com cluetrain: www.cluetrain.com
                         new book: www.smallpieces.com
                         speaking: www.hyperorg.com/speaker

*Elevator statement on file with building supervisor

>
< replied-to message removed by QT >

Ooh - a plethora of messages. Eeek.

Well, let me work through them, but I just noticed the word Wiki - and I thought I'd quickly point out there is a very nice RSS1.0 module for Wikis - http://www.usemod.com/cgi-bin/mb.pl?ModWiki

It's not been announced to rss-dev, but it is in use, and it does have some very nifty features.

Are we at the point where someone can actually start writing the standard itself?

I'm thinking we're close. If not, some formalisation might help further discussion anyway.

I've got the time: if no one else wants to, I'd be happy to put
something together over the next few days.
On that point, is anyone else going to be at the O'Reilly conference this week?

> -----Original Message-----
> From: QT - David Weinberger
>
> Are we at the point where someone can actually start writing
> the standard itself?

Ben, as an author, your editing skills (in addition to technical) would be very welcome. I'd like to collaborate on it -- I think that what I proposed in /m66 forms the basis strictly in terms of modules, but there should be more elaboration of use cases and specifics of the message ID discussion we've had. Sound good? Can we agree to drop requirements for thread ID and cutting ID? When the proposal is ready, I think the best way to formalize it in terms of modules is through the RSS-DEV mailing list, as has been done for other modules. Right, Rael?

But the real test will be to get other vendors to look at it and agree. Anyone want to volunteer for that? I wish we had more input from them up to this point (we've invited them at the beginning and after /m66).

I won't be at the conference. Wish I could.

David Weinberger writes,

>Are we at the point where someone can actually start writing the
>standard itself?

Before we do that, it would be great to have a list of all the operations someone would do with the standard. These are the "use cases."

Marc has started the first one on the wiki
<http://www.quicktopic.com/cgi-bin/thwiki.pl?UseCases>;,

>GrabAThread: get an entire thread of messages.
>
>Grab an entire thread of messages from the top to the end.
>
>As distinct from getting just a subset of messages on a thread? Or is that
>a sub-case of this one?
>
>Want a response that includes the source forum, some thread ID (?), and a
>set of messages.

This one needs to be fleshed out a bit more, but each one we add will make it easier to flesh out the others.

If you know an operation that isn't in the list, it's okay to just post a summary here; someone can pick it up and expand on it on the wiki.
A use case document, BTW, would be a great thing to run up the flag pole. It would make it easy for other vendors and users to say it looks like the right requirements, or not.

--
Pete
http://www.istori.com/peterkaminski

So I started thinking, "if I were a 'bot coming up to a discussion system, what would I want to be able to do?"

This seems like a list of operations one level up from the intent of ThreadsML. ThreadsML is here, under "thread exchange/retrieve all messages...", but there's a lot of other stuff, too.

Sorry for meta-stasizing, but maybe some of these operations are modules that would make ThreadsML work better and should be part of the standard or family of standards.

Structural Description -- what threading capabilities does this board have?
* return internal thread storage model (none, discussion board, blog, wiki, etc.)
* return display threading model -- how do users see threads?
* return support for threading model conversion (i.e., even though I'm a wiki, I'll pretend to be a blog if you want)

Discovery -- how do I know a thread is there?

* list all threads in date range
* list all threads started by author xyz
* list all threads which contain author xyz
* list all threads with subject keywords x, y, z
* list all threads with body keywords x, y, z

("list all" means something like "retrieve the subject/title and pointer to a thread")

("keywords" must include the capability to search for a full/partial URL)
Intra-thread Navigation -- given one message in a thread, discover all the other messages having a thread relationship to it

* list all threads that message x is part of
* retrieve pointer to starting message of thread/branch
* count how many messages are part of a thread

Thread Exchange -- standardized representation of threads for export/import
* retrieve pointers to all messages in a thread
* retrieve one message in standardized format
* retrieve all messages in a thread in standardized format
* create new thread/branch by posting thread in standardized format
Linking Notification -- backlinks to meta-discussions that include this thread
* create link (+message?) to another service+thread that refers to this thread
--
Peter Kaminski
http://www.istori.com/peterkaminski/

Maybe we also want to know:

PERMISSIONS

* Thread owner(s)
* Thread administrators(s)
* Thread is open/closed to additions
* Messages may be edited (by whom?)

METAMETADATA

* Thread start date (may be different from date of first msg?)
* Thread close date (when last msg could be accepted)
* Thread description/summary
* Thread keywords
* Thread primary language

I don't pretend to know if these have any place in the standard itself.
-- David W.
-----------------------------------------------------------
David Weinberger* 'zine: www.hyperorg.com
self@evident.com blog: www.hyperorg.com/blogger
Home: www.evident.com cluetrain: www.cluetrain.com
                         new book: www.smallpieces.com
                         speaking: www.hyperorg.com/speaker

*Elevator statement on file with building supervisor

>
< replied-to message removed by QT >

Edited by author 05-12-2002 09:08 PM
I'll agree with Peter by repeating myself from /m99:

I think that what I proposed in /m66 forms the basis strictly in terms of modules, but there should be more elaboration of use cases and specifics of the message ID discussion we've had.

I just added the use case from /m66 to the Wiki. There are others to glean from the round-trip discussion. I'd like to hear more about what the bots you mention in /m101 are doing Peter, i.e. what the humans at the end of the line are doing with the data (though machine-centric use cases are valid too, if that's what you've got).

Another use case, from /m80:

One question at this point: can a thread be spliced into an existing thread in its new home, i.e. can it be re-parented? I think not. A defining use case: I do a web-wide search using a search engine that understands ThreadsML and I find a message in a thread. I should be able to follow the thread up and down its hierarchy (at the search site); going down along different branches may lead to different sites, but going up should lead only to one site. Note that given the unique message IDs, the search engine recognizes identical messages and gives me the best one (probably at the originating site unless it's down).

I'll post that to the Wiki too.

Peter, I think the other major areas you mention -- Structural Description and Discovery -- are valid but they are indeed apart and separable from ThreadsML, and I don't think their definition would have any impact on ThreadsML, so I'd like to stay focused on that here.

David, there are some use cases implied in your suggestions, and I'd like to hear those. Some specific reactions:

If threads are portable, open/closed state is mutable at each of the host sites. Should we consider all core data, just like message IDs to be immutable (i.e. it should stay with the thread, unchanged, wherever it goes), and thus consider any site-to-site mutable data to be non-core?

Keywords, description/summary, and primary language imply an archiving/indexing application, which I think is the other most important use case (besides one-way trasfer of a thread from one forum to another).

Looks like Google is a step closer to "I find a message in a thread. I should be able to follow the thread up and down its hierarchy (at the search site)". See Keyboard Shortcuts at http://labs.google.com.

Edited by author 06-15-2002 11:17 PM
Shelly Powers has announced in her blog that she is starting a service that will create blogthreads:

http://weblog.burningbird.net/archives/000281.php

Edited by author 06-16-2002 10:43 AM
<de_lurk>
Hi All... Been following this with as much comprehension as I can muster for a non-RDFer. But /m105 roused me to some curiosity as to how blogging might interact with the Threading Standard being discussed here.

I speak as one who has definitely not acquired the "blogging meme." I've read a few and enjoyed 'em (David W's and Dan Bricklin's come to mind), and I think I "get" the blogrolling concept -- at least as well as someone who's been into e-communities for awhile (since email in '72 and since DECnotes in '89) but who's spent exactly 73 minutes reading, contemplating and being baffled by the popularity of blogs.

Why this Threading Standards effort? Methought it sprang from http://www.hyperorg.com/backissues/joho-jun17-01.html#threads wherein David pled for a portable representation of threads -- not so much that they could be navigated portably or abstractly, but so that they could be exported and imported cleanly across a variety of different discussion-enabling environments. Like out of CoolBoard and into anything. N'est-ce pas?

Now it may well be -- and it's a loverly outgrowth of groundbreaking work that this often happens -- that new purposes are discovered for a new technology. This is my dim understanding of what Steve mentions in /m104 -- "Google is a step closer to "I find a message in a thread. I should be able to follow the thread up and down its hierarchy (at the search site)"." So if this happens, cool!

But now I see /m105 which caused me to attempt to re-awaken my original attempt to find out why blogs are so popular. Bricklin's explanation resonated with me -- people write for other bloggers, and/or to make their blogs or websites better search targets, and/or to spark off new acquaintances, and/or to add new "blog-rollers" to their mutual-reference lists. Cool. I'm sure that's not everyone's reason, but hey, blogs are popular... Not my cuppa, but of course fine.

So now this notion of "blogthreads" comes up, whose purpose, as near as I can grok from Powers' description, is "Technology to enable community" whereby a posting in one person's blog riff on subject X can be automagically linked to another's followup in their blog, and so on. Thru some stuff I didn't understand, the Topic originator declares the start of a new Thread, and links it to the "Needley Page." Others wishing to follow that thread while writing their blogs insert some sort of (again-ill-understood-by-me) marker indicating that their own blogged stuff is a followup. And so it goes.

Anyone wishing to get a birds' eye view of the discussion would, presumably, get it from the Needley Page. One could navigate thereto from individual blogs, upon seeing that peoples' posts were explicitly marked as being responses to an ongoing discussion.

So, I'm asking myself, if this is technology to enable community, what's the advantage of building this community from a bunch of (pace Weinberger) blogs loosely joined? Is it that each blogger can continue to feel in control of, and continue to write into, the blogging environment of their choice, with their own tools, color-schemes, page-layouts, user-navigation graphics, and the like? So that they can continue to post their individual, trenche-de-vie minutiae, current events and Great Thoughts, and every so often return to multi-sided discussions on common questions of the blogging community within which they normally cross-read? So that they, when they wish to slough off the minutiae and see what one another are saying about, say, Identity or whatever other topics under common, multi-blog discussion, they can go to the Needley Site and see what's new, who's saying what?

If that's the design goal (in other words, if I'm not totally offbase), then it seems that the Needley Site is a means of enabling bloggers to construct a virtual meeting place while retaining control over those parts of their blogs that are not Needley-linked.

Leading me (pardon my longwinded wind-up) near to posing my question about blogthreads. (I hasten to add that I know that this is not a notion proposed by anyone who's written in this QT, so I can't really expect you to defend Powers' service-to-be, unless you want to...)

As I said, I've been part of asynchronous discussion communities for awhile. The addictive charm of those environments, to me, is that they're "e-places" where people explicitly "meet" to exchange ideas. They may freely create new threads and stay updated on which postings are unseen by them -- at least the good tools encourage that -- but the environment handles threading in a consistent-within-the-tool way. So -- what is the benefit of being able to explicitly link blogs? Instead of the Needley Site, why not just have a community site, or (maybe) a bunch of 'em, where any blogger who's interested can go write their current thoughts?

I am definitely missing something. If the advantage of blogthreads is that individual blogs can retain their own internal "stream-of-blogger consistency" while being part of a larger whole, well -- maybe. But (and pardon me if this is totally antediluvian) it seems to me on the basis of my own experience that electronic forums, peopled by many interested asynchronous writers in virtual conversation in the same e-space, are likely to be inherently more interesting, easy-to-follow, and vibrant than the blogs of those same writers, linked up into "virtual virtual conversations" across as many e-spaces.

In other words, BBSes (of most formats) seem SO much more fun than blogs (to me). Maybe I just don't have as much that's original to say, outside of what I say to and the conversations I have with others. Perhaps the charm of blogthreads is to be able to continue producing scads of other interesting stuff, while also intermixing reactions to other ongoing cross-blog conversations.

Is it a control thing? That people aren't willing to trust a common site for their discussions (witness CoolBoard's demise)?

Having barged in here, I am perfectly willing to get this 'splained to me in small words so's I'll understand. No hard feelings! :-)
</de_lurk>

---

And now for something COMPLETELY different. I just noticed that /m105 by David Weinberger is showing me signed in as Dan Kalikow the little
Edit
Delete
options! This definitely should not be. FWIW I am signed into QT via RCN cable using a LINKSYS router/firewall, running MSIE 6.0.2600.0000 under Win2K. Proof: I have just edited /m105 with the following:

---

OBTW, please buy my book: http://www.amazon.com/exec/obidos/ASIN/073...103-7507267-5287829 :-)

---

Weird. This is David W and I was presented with the edit/delete buttons for Dan K's msg. What is this, some stinkin' wiki?? :)

(Meanwhile, I also see the edit/delete buttons for /m105 which is indeed mine.)

WRT /m106:

I think about your msg as asking two questions: What are the differences between the blog world and other online communities, and what are the advantages of the blog world?

#1: The form of a blog typically is more like a newspaper column or journal entry than like a message in a dialogic (yech) community. A blog is a persistent space where I get to talk about what I want. I may choose to respond to someone else but I haven't run into any blogs that *only* do that. More likely, I'll write a brief essay on a topic. And, yes, a blog page is *mine*; the fact that I get to format it as I want counts. Blogs are what homepages were originally intended to be.

#2: The advantages are those that accrue to essays and columns as opposed to more epistolary forms. Is this better than a dialogic community? No, but it's different and has its own rewards.

You say: "...electronic forums, peopled by many interested asynchronous writers in virtual conversation in the same e-space, are likely to be inherently more interesting, easy-to-follow, and vibrant than the blogs of those same writers..." As you say, that is your experience, and clearly it's your preference. Take out the "inherently" and there's no argument. Or, leave it in and acknowledge that some writers are better at dialogue than at columns, and again there's no argument.

Defend the "inherently" and we can have an argument :)

/m107 NoNo -- I came here for abuse!! (-: which I think would be especially apt, considering the inordinate length of my /m106 :-)

I'll think more on this by tomorrow AM.

Edited by author 06-22-2002 04:17 PM
Since the subject of blogthreads has come up (/m105), I'll briefly mention some of my own ideas on the subject. David Weinberger's frequent references to conversational threads among weblogs got me thinking about how nice it would be if some service could collect weblog threads automatically and provide overviews, links to responses, and so forth. This is slightly lower-level than ThreadsML (as I understand it), since its purpose is to extract the threads from the raw materials rather than present an already-known thread.

The big stumbling block was figuring out how to break weblogs into individual posts, since every weblog has a different coding pattern. However, there's a simple coding convention that's compatible with nearly every weblog style and invisible to users: enclose each post in a labeled div element. Once that's done, weblog-aware services can read a weblog archive or main page, determine what posts it contains, associate a URI reference with each post, and figure out what links the post contains.

You can use that to build a graph of weblog posts which will correspond pretty well to the discussion thread. If person A writes a post, and person B responds to that post, person B just has to include a link to person A's post. There's no need for RSS feeds or explicit RDF threading information, just a coding convention and a simple spider.

What's really cool about the idea (in my opinion, at least) is that it's not limited to weblogs. The same convention can be applied to message boards or even web-based mail or Usenet archives, and a reader could potentially follow a thread between multiple weblogs, message boards, and archives.

My latest attempt to explain this in more detail is at http://www.eyrie.org/~zednenem/2002/web-threads/ .

/m106

Here we are, having a conversation now that's cross-Quick Topic.

(My mind just exploded.)

I'll take David W.'s answer (/m107( and expand on it if I may.

I think of cross-blogging communications as having roots that preceed electronic media - the letter. In times past, we wrote long, complicated, and detailed letters as a means of communication with each other, a fact that has helped us learn much of history (for instance about the Civil War). The writer would spend time and consideration preparing their communication, and the form, material, writing spoke as much as the words themselves.

Weblogging has not only digitalized the concept of the letter, but opens doors to new voices to join in the letter-writing exchange.

Those of us who get involved in complex cross-blogging conversations usually spend a considerable amount of time thinking about how to respond, what to say. We carefully craft the response - usually. The level of effort and detail is much more than would occur in something such as, well, Quick Topic. Usually.

In addition, and the reason I don't care for aggregation - the weblogger has a unique style and look to their weblogs that is part of the message. It's equivalent to the handwriting, materials, etc of long ago writing. The weblog is part of the message.

Think of the weblog as being the avatar in this electronic conversation.

I hope this isn't too far offtopic :

I'd add to what Shelley and David have said about ThreadNeedle and blogs, just off the top of my head, my take on it : that in the online 'asynchronous discussion communities' that Dan mentioned below, you have represented yourself through the things you say and have said in that community. There may have been an additional body of work, but this was secondary to the text-representation of yourself that accreted, word by word, as a result of your participation. This is a trivial observation, I know. But your avatar was effectively yourself as you chose to represent yourself via your comments and conversations.

When we talk about a weblog, though, I think it's profitable to talk about two separate entities created as an adjunct of our online presence, at least the one that derives from the weblog itself : the (for lack of a better word) publication and the person.

Now certainly, the 'publication' is a mirror, to whatever extent, of the person writing it. We see many weblogs that stop here at this point, that have no commenting systems enabled, or that pay little attention the 'community', that are traditional web logs (ie collections of links with minimal commentary) or diaries or photoblogs or warblogs or god knows what...but that are intended less as manifestations of the person behind them than publications about that person or their interests.

Another dimension, though, comes in with weblogs that have comment threads, that encourage and participate in conversations with other weblogs/webloggers. In this situation, the weblog not only becomes a publication about something (which might, in the case of more diarist-type blogs, be the person who is writing it) but a representation, an avatar of that person. The weblog itself becomes an active extension of the weblogger's identity (I wish I'd thought about this during the recent conversations around the blogs about 'identity'. Ah well.) The weblog is something that is carried with them (or is an extension of their identity online...? I'm not sure about this bit at all), and the cross-blog conversations that occur as a result of this, in posts and their comment threads, are in a way a new and larger version of the sort of discussion types we're historically used to, that Dan mentioned in his earlier post. A version that carries a body of work, a more deliberate one, along with the community member.

Does this make sense? I'm riffing here, and I have to admit that I haven't read David's book yet, so the sort of thing I'm trying to get a handle on (and communicate at the same time) might be old news.

Anyway (*takes a breath*) - I see these weblogs, the blogs that are not only 'publications' about something but also representations of the personality behind the words (and are this way because the weblogger has comments threads and/or engages in cross-blog conversations in their main posts and/or blogrolls people (the use of the word 'people' here is deliberate) as an acknowledgment of community), avatars that engage in conversation, to be the audience at which Shelley's ThreadNeedle is aimed. And I think (hope) that the service might be a major step forward, if it reaches critical mass.

i posted some stuff to the associated wiki

http://www.quicktopic.com/cgi-bin/thwiki.pl?RecentChanges

Hey, it's time I post notice here for you subscribers who might not have seen David Weinberger's blog: ThreadsML discussion is active again, over here now:
http://www.quicktopic.com/em/H/mXbfHC2srY3/