I would say Matt is the expert on that.

- Marc

>
< replied-to message removed by QT >

A few of us are proposing a "Social Software Alliance" to help coordinate and evangelize the sorts of standards needed for social software (like, for instance, ThreadsML or ENT).

Here's a pre-release/draft Call For Discussion:

<http://www.socialtext.net/ssa/>;

That's a wiki; if you'd like to edit, there's a free registration page at <http://www.socialtext.net/ssa-registration/>;.

There's also a mailing list:

subscribe: blank email to social-subscribe@lists.polycot.com
archive: http://lists.polycot.com/cgi-bin/ezmlm-cgi/2/

Comments/edits welcome! We have a conference call / online chat tentatively set for this Friday, April 18th (time TBD) to hash it out some more.

Pete

QT - Steve Yost wrote:

>I should add the following to my enquiry about RSS 2.0, just to
>balance the issue. As the ENT spec mentions, we're always trying
>to balance simplicity and flexibility. The flexibility of
>RDF-based 1.0 was what sold me on that approach, but the
>likelihood of success is, I still think, greatly dictated by the
>availability of software libraries (in popular languages) for
>reading and writing it.
>
>So I'll reiterate: what libraries are now available for
>reading/writing RDF (or specifically RSS 1.0)?
>
The Mozilla Application Framework includes an RDF parser and aggregator:
http://www.mozilla.org/rdf/doc/

In future releases Mozilla will allow web scripts to access these RDF services:

http://bugzilla.mozilla.org/show_bug.cgi?id=122846

-myk

Hi Danny et al,

I don't really have much to add to what you say.
We found the ThreadsML spec[1] pretty attractive for balancing usability & complexity.
OTOH, we felt that the 'fit' between the ontology and our use case was a bit ungainly.

In particular, we want to connect blog entries, items that the entries are about, and annotations on those entries.
Forcing all these entities to fit the concept of a 'Post' (especially in the sense of posts belonging to a well defined topic container) feels a little unnatural.

Our current inclination is to use ThreadsML as one of a number of pluggable options.
We'll certainly follow developments on this group with interest, and we're happy to share thoughts/ontologies as and when they become available
Cheers

Steve


< replied-to message removed by QT >

is there any standards (or a proposal) for comments? As a data structure?
Steve's needs seem clear (and backed my many other requests)

:How can we extend the concept of blog comments?

At a minimum:
 - store comments with associated blog posts
 - notify me when someone leaves a comment

And perhaps:
 - tie comments into a more general message board system

These simple needs should be covered by ThreadsML. I know there's a difference between a protocol and data structure and...

....WHAT YOU DO WITH IT.....

but perhaps we can break a few rules and actually put our minds into the needs of the end-users and say.....

YES - this is ONE of the things ThreadsML is all about.

:-)

You say tomato (RDF) - I say toMAHto (ENT/RSS) but it's all the same outcome.

:-)

- Marc


>
< replied-to message removed by QT >

Here's my post on Ben's session. It includes notes of what people think ThreadsML should do.

My my, look at what I stumbled on. Hope all don't mind butting in.

Gentlemen from all this activity, can I deduce that you're trying to decide whether to incorporate ThreadsML capability into RSS 2.0, or into RSS 1.0?

Personally, I think you'd have better luck going with ENT, as long as you can get RSS 2.0 pulled into a separate specification body. The use of RDF within RSS has always been overkill -- RSS by its nature is transitory, and RDF is the fundamental data model meant for building ontologies which persist. Ben knows wherefore I'm coming from with this. There is no true semantics with RSS -- its a brain dead data model.

The ENT _vocabulary_ (this is not a model), seems simple, clean, easy to implement if you can get all the publication tools to generate the vocabulary items, and -- big and here -- the people who write the content to categorize and do all the work necessary to make this work. Folks have had trouble with Trackback, and that's also a dead simple concept. The concept behind ThreadsML -- or recording threaded communications -- is more complex.

Then you have the issues of storage, which was always the problems I had with ThreadNeedle -- I wanted something that was non-centralized. Your approach requires centralization, unless you want to restrict discovery of conversations by happening on to one node in the thread, such as we have with Trackback now. Even with bots, the bots have got to return home to some mama. You'd have to have someone willing to put up about a terrabyte database to do this properly. Marc, I saw your goals -- man, even a terrabyte won't cover it.

Remember, that every time someone starts a conversation, you have to record it just in case someone else continues it. (Unless you again, don't care except for certain coversations.) For instance, I have people trackbacking to items I created 5 months ago. That is a lot of data. And you have to persist it, because the RSS (RDF or not) file is not persistent. You could embed this XML vocabulary into an HTML document, but we all know what a pain that is. However, this would persist the info. But this might allow you to store just the first node in the thread, and save space. Lots of work, though.

Even with the use of bots, you're still centralizing this. Correct? I don't quite see here, there is a lot of side threads, how you all plan on handling the persistent data issue. Sorry if this is clear to you all. I know I'm a self-invitee late comer.

(As an aside on the book, and thanks to whomever mentioned this (Danny? Ben?), I covered over 60 APIs and what not focused on RDF -- the technology is there, we just haven't been promoting me. My bad, too, on this. What I hope comes out from the book is decent ontologies from many different domains, we have the APIs now. RDF doesn't need another inappropriate use to live down.)

wow - intelligent, in-depth analysis and criticism. Compared to the last time I saw your name - this is really refreshing!


>
> Gentlemen from all this activity, can I deduce that you're
> trying to decide whether to incorporate ThreadsML capability
> into RSS 2.0, or into RSS 1.0?


I'd say (idealistically) wouldn't it be cool to implement ThreadsML in both?


>
> Personally, I think you'd have better luck going with ENT, as
> long as you can get RSS 2.0 pulled into a separate specification
> body.

Do you mean 'technical' body or some sort of 'standards' body or a business entity?


> The use of RDF within RSS has always been overkill -- RSS
> by its nature is transitory, and RDF is the fundamental data
> model meant for building ontologies which persist. Ben knows
> wherefore I'm coming from with this. There is no true semantics
> with RSS -- its a brain dead data model..

Agreed - but you should have seen Jo Walsh's presentation at ETCON. There are LOTS of people using RDF - so vive le defrance, god bless them, more power to them. There is PLENTY of functionality and flexibility in RDF to implement a ThreadsML type interop. But it also makes sense to use ENT as well. No reason not to make sure we float something that works with both.


>
> The ENT _vocabulary_ (this is not a model), seems simple, clean,
> easy to implement if you can get all the publication tools to
> generate the vocabulary items, and -- big and here -- the people
> who write the content to categorize and do all the work
> necessary to make this work. Folks have had trouble with
> Trackback, and that's also a dead simple concept. The concept
> behind ThreadsML -- or recording threaded communications -- is
> more complex.


Yes and I think it's important to keep in mind that ThreadsML is not Trackback. We have the ability of baking this into a new generation of tools, and completely hide all the technical mumbo jumbo. I still don't really understand Trackback - you know why? I don't use MT. And because of that - I don't have a direct feedback of it's functionality.

One thing we have to consider and conspire on - is how we'd introduce this to the world. Perhaps it's actually more than one name - more than one way that it's benefits are received by the end-users. The same
interop/protocol/data structure/service - can be utilized in many ways.

>
> Then you have the issues of storage, which was always the
> problems I had with ThreadNeedle -- I wanted something that was
> non-centralized. Your approach requires centralization, unless
> you want to restrict discovery of conversations by happening on
> to one node in the thread, such as we have with Trackback now.
> Even with bots, the bots have got to return home to some mama.
> You'd have to have someone willing to put up about a terrabyte
> database to do this properly. Marc, I saw your goals -- man,
> even a terrabyte won't cover it.


More like 20 Terrabytes - just to start. Everywhere I look I see billionaire yuppies starting moon projects, buying houses, making charitable donations, etc. What would be more beneficial and charitable than to sponsor an open conversation server?

I figure between the Internet Archive, Google, Sun, Oracle, Macromedia, Adobe, HP, IBM, Microsoft and [insert here] we should be able to get as much storage and bandwidth that we need. Oh yah - Sony, Phillips, NEC, Fujitsu, Nokia, Samsung, etc.

And I think there's some sweet spot between centralized servers and LOTS of them - storing different KINDS and TYPES of conversations - based upon geography, scope, constituency, government, religious, commercial or education affiliation. In fact - it's a balance between decentralized and a central DNS-like interchange/registry - that I think will be required.

>
> Remember, that every time someone starts a conversation, you
> have to record it just in case someone else continues it.

HHmmmm - don't think we'll tackle audio - just right yet. But I DO think we can do this with that old fashioned stuff called text. And structured text and data structures - as well.


> (Unless you again, don't care except for certain conversations.)


The idea is - that new kinds of tools would enable these new kinds of conversations. All the old message boards, IM clients, email clients, blogs and text editors will remain "old school".

So I imagine that this sort of spooling, archiving, linking, hyperlocking, whatever that entails - will be on a case by case basis. But YES - in certain situations (school lectures, business meetings, flirting scenarios, affinity groups) I do see EVERY conversation being turned into a persistent, re-entrant file/structure.


> For instance, I have people trackbacking to items I created 5
> months ago. That is a lot of data. And you have to persist it,
> because the RSS (RDF or not) file is not persistent.


One good thing would be to get rid of redundancy and save only the diffs. Here's an example.

Joi Ito started playing with his RSS feed after he read Ben's book [thanks Ben.] He created an alternative feed - which includes both the comments and trackbacks in it. So every time someone leaves a comment or adds a trackback to one of Joi's posts - you get an entirely new copy of the whole thing - the post, ALL the comments and ALL the trackbacks.

This is obviously what we DON'T want.

If you read this post:

http://blogs.it/0100198/2003/04/27.html#a989

...you'll see that what people MOST want is interop - to flow the threads between different tools, different platforms/machines or different usage scenarios. This is totally do-able with both RDF and RSS2.0/ENT.
> You could
> embed this XML vocabulary into an HTML document, but we all know
> what a pain that is. However, this would persist the info. But
> this might allow you to store just the first node in the thread,
> and save space. Lots of work, though.

I'm hoping to keep HTML as a display format - and stay away from it like the plague. Details like this will flow - when we can agree upon a range of scope and implementation spec.

>
> Even with the use of bots, you're still centralizing this.
> Correct? I don't quite see here, there is a lot of side threads,
> how you all plan on handling the persistent data issue. Sorry if
> this is clear to you all. I know I'm a self-invitee late comer.


I need to spend some time matrixing all the feature requests we got at ETCON - but I'll pick up on the work we've done already - on what we call Multimedia Conversations:

a) a conversation - thread of thought - starts as an email interchange, IM session, chat session or message board thread. That thread gets "converted" or input into a tool that supports threadsML. This is the point when the thread (which can be a single 'post' or entire sequence of posts) gets stored on a server. That may be an open, public server - or as locked up as possible. The technology should be security scheme agnostic.

b) at this point - many things can happen.
 - The thread can continue onto or shall I say 'into' many other tools, systems or environments.
 - The thread can be transformed into visualizations, media sequences, interactive interfaces - all sorts of new wacky stuff

c) at any point - a conversation should be re-entrant - so that anybody (or in a more controlled manner) can jump into 'the middle' of a thread - instead of always appending to the end.

d) Threads/Conversations should be sortable/searchable by name, topic, chronology, size, media type associated with it, etc.

e) These conversations would be stored on shared servers (ala TopicExchange or blaxm!.) A distributed model could be used to mirror or proxy the conversations throughout the WWW.

http://blogs.it/0100198/stories/2003/01/20...aConversations.html
NOTE: Many of the usage scenarios that people requested had to do with data interchange between different tools or systems. So putting the thread into some standard form - seems to me to be half the battle.


>
>
> (As an aside on the book, and thanks to whomever mentioned this
> (Danny? Ben?), I covered over 60 APIs and what not focused on
> RDF -- the technology is there, we just haven't been promoting
> me. My bad, too, on this. What I hope comes out from the book is
> decent ontologies from many different domains, we have the APIs
> now. RDF doesn't need another inappropriate use to live down.)
> _________________________________________________________________
> QT Forum: http://www.quicktopic.com/em/H/mXbfHC2srY3/m33
> Unsubscribe: http://www.quicktopic.com/em/X/mXbfHC2srY3
> Current email group: aaron@theinfo.org, ben@benhammersley.com,
> danny666@virgilio.it, info@icite.net, jamie@fentonia.com,
> jito@neoteny.com, judell@mv.com, kaminski@istori.com,
> marc@broadbandmechanics.com, marc@prec-it.com, matt@novissio.com,
> mgraham@mail.ivillage.com, myk@melez.com, myk@zapogee.com,
> paolo@evectors.it, rael@oreilly.com,
> rcaccappolo@mail.ivillage.com, rossmay@earthlink.net,
> self@evident.com, steve@quicktopic.com
> Start your own topic in 20 seconds: http://www.quicktopic.com |QT
>

I'd like to take a stab at an ENT implementation, just to provide myself something concrete to work with, and to have an idea of what it would be to support both (for myself and others).

You've probably all seen the current placeholder RSS for QuickTopic:
http://www.quicktopic.com/em/H/mXbfHC2srY3.rss. I worked from an example provided by Aaron Swartz to quickly implement that.

Could someone provide an ENT example of this thread? Just the first few messages, even.

I should start this post by saying that I've just read the ENT and RSS2.0 docs in the last hour, and I think I get just about all of it. It's good that they're this easy to understand.
[For easy reference: http://www.purl.org/NET/ENT/1.0/ and
http://backend.userland.com/rss]

I see now that asking for an ENT implementation example of ThreadsML is premature, and probably just off base. That's because ENT itself, being the addition of topic-map data to RSS2.0, doesn't include all the kinds of data that ThreadsML needs. In particular, we need the inter-message linking and full-content that are covered here:
http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66
So Marc, as I understand it, you're suggesting not that ENT handle ThreadsML, but rather that ThreadsML be implemented as an RSS2.0 extension like ENT is.

Since the current proposal for ThreadsML is a collection of RSS1.0 modules and specification on how to use them in that context, they can easily be used in the RSS2.0 context as well (right?). That makes it easy for the app that exports ThreadsML to support both.

I like RSS2.0's simplicity and directness, which work because it's clearly targeted at specific applications. It seems like a slight stretch to apply this to discussion threads -- take for instance the <comments> element, which would be deprecated in this usage (similarly, maybe the ENT spec should suggest a usage for RSS2.0's <category> element when using the ENT extension). But again, I'm for the pragmatic approach: ease and likelihood of implementation.

This does seem like a good time to take a stab at both for QuickTopic.
Regarding terabytes of storage, etc: it's worth pointing out that central storage isn't necessary, given that many threads are stored in a
"permanently" accessible place. The proposed spec deals with linkage from a portion of a thread stored somewhere (say a web-based email archive) to somewhere else like QuickTopic. That's not to say a vast repository wouldn't be useful, at least for Google-like caching or Internet-Archive-like archiving.

Speaking of Google, there's the What Will Google Do question. With respect to ThreadsML, it would be great if they and other search engines supported thread traversal (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m103). Regarding ENT and Google, it would be great if Google supported that too. As I mentioned on my blog in February
(http://www.quicktopic.com/blog/archives/000219.html#000219 see 'Blog topics'), I'm intrigued by such a prospect.

Clarification: when I said
> This does seem like a good time to take a stab at both for QuickTopic.
I meant that I should try implementing the current proposal for ThreadsML for QuickTopic as both RSS1.0 and RSS2.0 extensions. Maybe someone could write/modify an app to import/consume one or both of these. This would help flush out any issues with the current proposal.

> Clarification: when I said
> > This does seem like a good time to take a stab at both for
> QuickTopic.
> I meant that I should try implementing the current proposal for
> ThreadsML for QuickTopic as both RSS1.0 and RSS2.0 extensions.
> Maybe someone could write/modify an app to import/consume one or
> both of these. This would help flush out any issues with the
> current proposal.


Cool dude - go for it - I'll make sure either Matt or Paolo are supporting you (if you need it.) eVector's (Paolo's company) has an ENT aware reader/aggregator called K-Collector. It should be able to read your ENT feeds.
http://blogs.it/0100198/2003/04/27.html#a992

What you need to do is to the extensions/changes/additional features required for ThreadsML and hand that code to Matt and Paolo. They'll bake it into the two basic apps they've got:
 - LiveTopics
 - K-Collector

then we get that code to Phil Pearson - and his TopicExchange - and we'll have three ThreadsML aware apps! Meanwhile I really DO need to sit down and matrix out the requests - made last week - and act like a marketing guy and make sure it all works "from the user's point of view".

This BTW this is exactly what the folks at the SSA BoaF were insisting - that the engineers listen to the humans. So regard me as their advocate (well I guess Dr. Weinberger gets that title - more than me.) Afterall - he DOES have the domain name afterall.

:-)

> I should start this post by saying that I've just read the ENT
> and RSS2.0 docs in the last hour, and I think I get just about
> all of it. It's good that they're this easy to understand.
> [For easy reference: http://www.purl.org/NET/ENT/1.0/ and
> http://backend.userland.com/rss]

Coolio

>
> I see now that asking for an ENT implementation example of
> ThreadsML is premature, and probably just off base. That's
> because ENT itself, being the addition of topic-map data to
> RSS2.0, doesn't include all the kinds of data that ThreadsML
> needs. In particular, we need the inter-message linking and
> full-content that are covered here:
> http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66
> So Marc, as I understand it, you're suggesting not that ENT
> handle ThreadsML, but rather that ThreadsML be implemented as an
> RSS2.0 extension like ENT is.

Bingo - nail on the head - exact-de-mon

>
> Since the current proposal for ThreadsML is a collection of
> RSS1.0 modules and specification on how to use them in that
> context, they can easily be used in the RSS2.0 context as well
> (right?). That makes it easy for the app that exports ThreadsML
> to support both.

Bingo again - man you're matching all the #'s this morning!

>
> I like RSS2.0's simplicity and directness, which work because
> it's clearly targeted at specific applications.

I guess that's why it's called EASY News Topics!


> It seems like a
> slight stretch to apply this to discussion threads -- take for
> instance the <comments> element, which would be deprecated in
> this usage (similarly, maybe the ENT spec should suggest a usage
> for RSS2.0's <category> element when using the ENT extension).
> But again, I'm for the pragmatic approach: ease and likelihood
> of implementation.

Welll dude - I kn wo things are moving fast now - but believe it or not there MAY be some other usage scenarios and features that you MAY have not thought of - or have currently implemented. :-) SO give me some time (like till next week - I have to go to Chicago this week) and we'll make sure all those requests made last week during Ben's session - can get implemented as well. [That's what I call 'matrixing' the features......]

Taking your current spec and "implementing" it with RSS2.0/ENT - is a great first step.

Who knows - maybe by then, we'll convince Dave Winer to help.

:-)

>
> This does seem like a good time to take a stab at both for
> QuickTopic.

Cool - as I said in the pther post - k-collector is a new kind of aggregator, LiveTopics brings topics to Radio and could be thought of as a ENT generator and TopicExchange is a - well I guess you'd call it a shared repository.

So we got teh makings of some cool interchange. This is excactly what Matt and Paolo anticipated. They've been doing the 'mundane' stuff first, but they hoped that cool and new things (like ThreadsML) could ALSO leverage ENT.

And you're doing it!

One thing to take into account - if the connection that we're making RIGHT NOW with this mail list splattering itself into QT. Make SURE that kind of functionality gets implemented FIRST!

:-)


> Regarding terabytes of storage, etc: it's worth pointing out
> that central storage isn't necessary, given that many threads
> are stored in a
> "permanently" accessible place. The proposed spec deals with
> linkage from a portion of a thread stored somewhere (say a
> web-based email archive) to somewhere else like QuickTopic.


Amen brother. We can eventually bake this sort of funcntionality into smart "virtual storage" systems (object stores) which will take care of all the moving around, decentralized, distributed nature kind of stuff - that should sit ON TOP of the ThreadsML interop.

But without the basic building blocks of flowing a thread between disparate tools, systems and environments - we can never have a virtual file storage - so GO FOR IT!

We're changing the world here :-)

Thanks to Ben again.....



> That's not to say a vast repository wouldn't be useful, at least
> for Google-like caching or Internet-Archive-like archiving.

Or many, many vast repositories!


> Speaking of Google, there's the What Will Google Do question.


That's why Joi has been making sure to befriend Evan - as we knew that when the Neoteny investment was announced, they're more or less raising the bar and taking the Blogosphere to a new level. So communication between vendors will be even MORE important.

Joi approached Winer too - BTW.


> With respect to ThreadsML, it would be great if they and other
> search engines supported thread traversal
> (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m103). Regarding
> ENT and Google, it would be great if Google supported that too.
> As I mentioned on my blog in February
> (http://www.quicktopic.com/blog/archives/000219.html#000219 see
> 'Blog topics'), I'm intrigued by such a prospect.

:-)


>

First, clarification -- when I say conversation, I meant among weblogs, quick topic, wikis, etc. Not audio.

I'd say before you think about adding yet more data to RSS files that get consumed by a plethora of bots on a minute by minute basis, you think of a interim architecture for a prototype that you all think you can create without having to get Google and Sony involved.

Steve, you mention that centralized data store isn't necessary, because many of the threads are permanently accessible -- then how does one find them? Can you walk through an implementation scenario for say, a multi-post weblog topic with comments, perhaps throwing in QuickTopic and a yahoo newsgroup item.

Let's be real about this -- use specific tools. What would the tools need to do, and what would the people need to do. In your spec, you say 'export the thread' -- what does this mean? Exactly what would be the physical implementation of same?

You're being so damm pragmatic and specific - I love it!


> First, clarification -- when I say conversation, I meant among
> weblogs, quick topic, wikis, etc. Not audio.

Ok - so going back to your point - the issue is that as 10's of millions of conversations are flowing, and a lot of them (not necessarily ALL of them) will be stored - whether on a centralized or distributed (or both) series of repositories, THEN we gotta worry about RIGHT NOW the issue of......
I guess that's the one time (taking the dumb network, world of ends POV) that centralized servers come in handy - to navigate, discover and interconnect disparate conversations together. LOTS of rules, restrictions, constitutions, security layers, PETs and encryption realities will have to be instituted to pull this off - but first things first - let's get the base interop working.

>
> I'd say before you think about adding yet more data to RSS files
> that get consumed by a plethora of bots on a minute by minute
> basis, you think of a interim architecture for a prototype that
> you all think you can create without having to get Google and
> Sony involved.

Well I'd say that ENT (though not in flux - certainly isn't 'done' yet.) It can embed topics fine and help flow blog posts into new kinds of
aggregators - but I'd hate to see it stop at that. So as far as
'protoyping' goes, Steve is gonna take a stab at implementing a
'ThreadsML'-like approach with ENT and we'll see what happens after that.
When it comes to the medta-data, internal bits, data that Google is gonna scarf - I think we can spend some time (like a week or two) thinking about that issue as well.

Anything - in particular - we should "watch out for?"


>
> Steve, you mention that centralized data store isn't necessary,
> because many of the threads are permanently accessible -- then
> how does one find them? Can you walk through an implementation
> scenario for say, a multi-post weblog topic with comments,
> perhaps throwing in QuickTopic and a yahoo newsgroup item.

:-) This is fun!

>
> Let's be real about this -- use specific tools. What would the
> tools need to do, and what would the people need to do. In your
> spec, you say 'export the thread' -- what does this mean?
> Exactly what would be the physical implementation of same?


I vote for:

 - a DNS-like open respository of thread "pointers"/topics/meta-data - which enables folks to not only track the trheads - but also discover them in the first place

 - a data structure that specifies how a "generic conversation" would look like (OPML based?) - so whether it's a weblog post, comment on a weblog post, email excerpt, IM or chat session, or a particular piece of structured text (coming out of my new-fangled tool) - there's a common format where all this stuff gets converted into or out of.

 - clear usage sceanrios schemas. In other words - a) in the case of a a single topic being converted into a message board item, this is teh blah blah blah - while b) threaded IM or chat sessions should convert into blah blah blah to do blah blah blah, while on the other hand, c) doing remote posting (via IM or email) to a message board, would use the blah blah blah methodology......

 - IOW all centered around a common format, but using different kinds of schemas and APIs.


BTW Steve - bug in QT - when I click on the button "25-35" to see Shelley's earlier point - that link is broken.

- Marc

I'm excited to see this thread picked up again, so to speak. Thanks to y'all (and a big hug to Marc for pushing this forward so
enthusiastically).

See embedded comment.

-- David W.

> I vote for:
>
> - a DNS-like open respository of thread
> "pointers"/topics/meta-data - which enables folks to not only
> track the trheads - but also discover them in the first place

 
> - a data structure that specifies how a "generic
> conversation" would look like (OPML based?) - so whether it's
> a weblog post, comment on a weblog post, email excerpt, IM or
> chat session, or a particular piece of structured text
> (coming out of my new-fangled tool) - there's a common format
> where all this stuff gets converted into or out of.

ThreadsML started out to be this data structure. With it, one could decide to build a DNS-like open repository. But even if no one decides to do that, threadsML would still accomplish (what I take to be) its primary objective: enabling two compliant apps (say, QuickTopic and Topica, both of which have expressed an interest in supporting the standard) to import/export threads. For example, each would add a button to enable a user to export the current thread (or perhaps the entire discussion board) in threadsML and a button to import a discussion that'd been saved in threadsML.

I point out this obviousness because I don't want to tie threadsML to the creation of a directory of threads. Much as I'd love the latter, it's a much bigger and riskier project than coming up with a threads interchange standard.

If I've got this wrong, I'm sure you'll straighten me out...

 
> - clear usage sceanrios schemas. In other words - a) in
> the case of a a single topic being converted into a message
> board item, this is teh blah blah blah - while b) threaded IM
> or chat sessions should convert into blah blah blah to do
> blah blah blah, while on the other hand, c) doing remote
> posting (via IM or email) to a message board, would use the
> blah blah blah methodology......
>
> - IOW all centered around a common format, but using
> different kinds of schemas and APIs.
>
>
> BTW Steve - bug in QT - when I click on the button "25-35"
> to see Shelley's earlier point - that link is broken.
>
> - Marc
> _________________________________________________________________
> QT Forum: http://www.quicktopic.com/em/H/mXbfHC2srY3/m41
> Unsubscribe: http://www.quicktopic.com/em/X/mXbfHC2srY3
> Current email group: aaron@theinfo.org,
> ben@benhammersley.com, danny666@virgilio.it, info@icite.net,
> jamie@fentonia.com, jito@neoteny.com, judell@mv.com,
> kaminski@istori.com, marc@broadbandmechanics.com,
> marc@prec-it.com, matt@novissio.com,
> mgraham@mail.ivillage.com, myk@melez.com, myk@zapogee.com,
> paolo@evectors.it, rael@oreilly.com,
> rcaccappolo@mail.ivillage.com, rossmay@earthlink.net,
> self@evident.com, shelleyp@burningbird.net,
> steve@quicktopic.com Start your own topic in 20 seconds:
http://www.quicktopic.com |QT