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