Aye, Cap'n


On Thursday, May 8, 2003, at 08:11 PM, QT - Marc Canter wrote:

>
< replied-to message removed by QT >

Anyone wanna participate in fleshing out the site - besides me and the good Doctor?

- Marc

>
< replied-to message removed by QT >

> I've posted a draft of a threadsml page at
My only comment for now is thanks very much for setting this up, David!

I've posted a draft of a threadsml page at http://www.threadsml.org, and a re-direct at .com.

It's minimal because it's just a starting point for your comments...

I'm not sure why I'm mentioning this, but I suspect it might be useful information for those of you trying to create ThreadsML, etc.. I think no mater what you do, the underlying problems are going to be the same, or to state it slightly differently, the issues are inherent in this problem domain. The problem won't be solved by a clever spec [I'm not accusing anyone of thinking this!], but maybe it can be solved by good user interface design.

Regards, etc...
David P. Janes

[marc] That's a great endorsement to what Clay said in his keynote. There's technology and there's people (their behavior patterns, social norms and group aesthetic.) Social software needs to being BOTH those into perspective and create balance.

LinkedIN is a great example of ONE kind of social interaction. The system walks humans through the process of creating business relationships.
Jonathan Peterson just pinged me - asking about Dan Bricklin. He wants to meet him. In our existing world - I'd send an email to Dan, cc:ing Jonathan - hoping that it makes it through Dan's spam filters. With LinkedIn - Jonathan requests making a contact with Dan, I vouch for Jonathan and the system takes care of the handshaking, verifying, asking permission, politely knocking on Dan's virtual door, etc.

This will be fun to see if it works.

And that's just one sort of human behavior quantified in technology.
This editing, pruning, interacting and filtering of conversations is another.

[This BTW is exactly the post I want to post on all three boards.........]

God - I hear the strains of "kum bah yah" whistling off in the distance!
Agreed!

Just because we HAPPEN to be using an outliner as ONE (or shall I say - the first) viewpoint editor for ThreadsML, doesn't mean:
 - a) that ThreadsML IS an outline structure
 - or
 - b) that an outliner is the ONLY way to edit, create, manipulate ThreadsML threads

OK?

And while we're on the subject:

 - Phil Ringnalda brought up a good point - the importance of having a ThreadsML validator. I checked with Paolo and they intend on building an ENT validator - just as soon as their initial demo is done and they've returned from BlogTalk. So while we relish input and great ideas, pragmatism also reins supreme - and as long as we're doing all this stuff "on a wing and a prayer" - that'll have to be the best we can do. So "who" wants to do a ThreadsML validator?

 - I was struck like a lightening bolt during Ben's presentation (which Lisa Rein has on video - BTW) when Ben starts talking about parents and children and showed that inside of an RDF 'file'. "But wait", my little brain said - "that's a hierarchy - outliners are hierarchy editors!"

But I know life is just never that clean. Danny Ayers also complained that outlining doesn't do "justice" to representing and editing conversations - and I think we're all in violent agreement. [[[[Watch carefully how this works.....]]]]]]

So we're (Broadband Mechanics) going to give the community all this code and then I'd like to ask someone to come up with an editor that DOES represent the possibility of editing conversations, fulfilling all our lifetime dream and aspirations.

If outlining is not perfect - which I actually tend to agree with - well then, what is?

OK - so everyone hold hands in a virtual circle and sing......

>
< replied-to message removed by QT >

Right. Threads is threads, and outlines is outlines. If you can create a thread in an outliner, it's a nice demo of the flexibility of the outliner.
> Although we'll be using an outliner, and although a message
> thread looks very much like an outline, it doesn't necessarily
> follow that the data structure should be an outline.

this all sounds good to me, though with one caveat:

Although we'll be using an outliner, and although a message thread looks very much like an outline, it doesn't necessarily follow that the data structure should be an outline.

My concern here is that perhaps a) employing an outliner as a test app sticks us with developing an outliner markup based system and b) whether, if we do that, does making threadsml a new outliner markup based system restrict ourselves in any way.

Remember, one goal is to make the threads application agnostic. Whilst some people have the big time outline religion thing going on, I don't like them at all. The joy of a threadsml would be to let the
Outlinistas use their tools, and me use mine, and you use yours, without it mattering a jot. Let's remember that whilst we work on the data structure.

Note, this isn't the usual anti - OPML rant, so let's no do that debate either: I could be referring to any strict outline markup.


On Wednesday, May 7, 2003, at 11:13 PM, QT - Marc Canter wrote:

>
< replied-to message removed by QT >

Edited by author 05-08-2003 12:53 AM
OK - here's my 2 cents to the discussion - a ThreadsML deployment strategy diagram. It's something that can be worked on - together - on the near term.

For it's part - Broadband Mechanics will contribute an on-line outliner which can be used to edit ThreadsML conversations. There would also need to be a new kind of 'conversation aggregator' created - which would act sort fo like a debugger/development tool - at least.

So the idea is that ThreadsML is both a data structure and a set of APIs. The MetaConversationAPIs. Lots of existing kinds of tools and platforms can be modifie to support this format and protocols. New kinds of tools would be created and LOTS of new functionality could be offered to end-users.

First two new tools are: an outliner that can edit ThreadsML conversations. Disparate pieces from different origins can be edited and output in compatible ThreadsML format. Second tool: an aggregator for displaying links to a wide range fo threads. Similar to k-collector - for ThreadsML. Also see Paolo's upcoming WWWW interface.<p>
Here's the chart link <img src="http://broadbandmechanics.com/media/artwork/ThreadsML.jpg"</a>

I really like this piece by Paul Philip, pointed to recently on David Weinberger's blog:
http://www.paulphilp.com/longharvest/archives/000030.html

Most of it applies to any attempt to create a new technology standard.

> I agree that supporting the modification/deletion of messages
> could mean a lot of extra work for little benefit, but it just
> occurred to me that there's something of a precedent for that
> too : CVS. Maybe worth thinking about once the rest's in
> place...

Are you implying versioning of messages? If so, then whew, yes, that's even more extra work (for especially questionable benefit in this context IMHO). I recall that WebDAV, which had versioning as a goal from the start, was actually really just WebDA for a long time because the Versioning part of Distributed Authoring and Versioning was really hard to do.

I agree that supporting the modification/deletion of messages could mean a lot of extra work for little benefit, but it just occurred to me that there's something of a precedent for that too : CVS. Maybe worth thinking about once the rest's in place...


< replied-to message removed by QT >

> > > an API to the centralised app would be sufficient
>
> OK, good. API, which would subsume protocol.
>
> Then Danny wrote:
> >
> > Hmm - what about the flow of info between the individual
> message
> > nodes? If there is a general data model (as above) the perhaps
> > the same basic API could be used irrespective of the target.
>
> I don't get it. Can you elaborate?

When an item is added to a thread, the parent/siblings/children may need to be notified as well as the centralised server. I was thinking that the same mechanism used to notify the central server could be used to notify the host of the parent item etc. It may not be needed - it could already be on the same server or trackback might serve the same role, but it shouldn't be any extra effort for the API to support this.

I wrote:

> Astute! We'd actually considered two levels of support:


Actually it was three levels (see the bottom of the message, but most of it is relevant here):

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

And the wiki entry I mentioned is here:
http://www.quicktopic.com/cgi-bin/thwiki.p...tsOnEditingUseCases

Shelley wrote:
> So you all are
> saying that any application that calls itself
> threadsML enabled must support export of the conversational
> thread to a standard output format (there's your data), and
> reimport of same. And that the application must be able to merge
> imports.

Astute! We'd actually considered two levels of support: one which supports round-trips (export and subsequent import of a thread with changes, merging with local changes), and one which only handles one-way in either direction (but presumably can recognize an attempt at re-import and do what it wants).
> Are you talking about thread identifiers, or are you talking
> complete messages?

Complete messages, each with a unique ID.

> Any discussion about what happens to edited
> messages in one copy of the thread compared to another?

Coincidentally I posted on the wiki yesterday about that, saying edits needn't be handled, with the understanding that if you (as the message poster) really want to assure your changed message will propagate, then post a new message. This keeps things relatively simple, while allowing for extension later to support editing if need be.

yeah, pretty much

On Wednesday, May 7, 2003, at 07:14 PM, QT - Shelley (Burningbird) P wrote:

>
< replied-to message removed by QT >