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?

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

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.

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 >

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.

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.]

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.)

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...

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.

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: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?

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/

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.

> 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

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?

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.