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

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 >

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/

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

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.

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.