Jay, I'm not clear on how a separate vocabulary might be necessary, if we're talking only about the data standard. Are you talking instead about an API that could extract a single message? Or maybe a usage convention (like the usage convention for RSS that says you update your RSS with recent messages periodically or make it dynamically available)?

Considering only the data standard, the only issue would be construction of the parent and child pointers, which might not necessarily be present in a single message record within a ThreadsML instance. But these could be added by looking at neighboring messages before extracting to individual message files. (I think I need a better picture of who's doing the extracting and from where.)

Here's why the parent/child pointers might not be there: I recall that in a phone conversation with Rael Dornfest, David Weinberger and me months ago, we suggested that parent-child pointers would be optional on each message, the default being that the messages in one ThreadsML instance are considered to be a linear time-sequential thread. Rael suggested that parent-child relationships in a tree might be considered [conceptually only, not in the layout of data] overlaid information on top of the time-sequential message flow.

Jay's question raises a pretty good issue: if a thread in ThreadsML is a collection of messages, than how are messages defined? As a subset (or superset) of RFC 822/1036/1123/2822? Plus MIME extensions? Blogger API / MetaWeblog API? Son-of-RFC-1036, etc. (For even more mail message metadata stuff, see DJ Bernstein's "Internet mail message header format" collection, <http://cr.yp.to/immhf.html>;.)

Another question: do we have enough collected thoughts to start drafting something spec-like on the ThreadsML wiki, so I can see the ThreadsML structures on one page? Or do we have that already and I'm just missing something?

Pete

Steve, I was partially joking about a separate vocabulary (you know, everything having to have its *own* ML), but I mentioned it because I wasn't sure to what degree can a ThreadsML document be stripped down and still be valid.

So, I meant to suggest that having a bit of ThreadsML that is as minimal as the markup of a single post (plus maybe a little more) and is still valid ThreadsML would be useful.

I think the alternatives are: 1) always starting with a whole thread when working with a valid ThreadsML document or, 2) having another vocabulary (that ThreadsML transforms into and out of) for just posts "on their own".

What I would suggest is, I think, the same thing you are saying: allow for sufficient optional elements that a minimal document (almost) as small as a single post is valid ThreadsML.

To echo Peter's question: since there isn't a standard markup definition of "a post", an important use of ThreadsML could be as "a vocabulary for indiviudal message/posts and for the collection of those posts into threaded conversations".

Peter, I think, as a markup language, ThreadsML can define a schema for messages/posts. I don't know if it needs to tackle things at the MIME level or API level. Of course, services that use ThreadsML need to *know* how the ThreadsML schema might map to an API like Blogger or a MIME type like text/html or a POP3 message.

One more comment to add to Peter's:

One thing maybe relevant to ThreadsML with regards to both APIs and MIME types is URIs plus protocols.

If a post is one part of a multipart email message or in the middle of a HTML page or accessible through the Blogger API at a particular URL, does ThreadsML need to be able to describe all of those types of URIs plus protocols?

If so, how does that affect the schema (e.g., what elements are needed to indicate that a post comes from a particular URI using the blogger.getPost method)?

> I think the alternatives are: 1) always starting with a whole
> thread when working with a valid ThreadsML document or, 2)
> having another vocabulary (that ThreadsML transforms into and
> out of) for just posts "on their own".
>
> What I would suggest is, I think, the same thing you are saying:
> allow for sufficient optional elements that a minimal document
> (almost) as small as a single post is valid ThreadsML.

Steve referred to to the timeline aspect. I think what we're looking at as a basic datastructure is a (time-ordered) list. So a single post (+ a little bit) would be a thread, would be a list of one item. I like the idea of conceptualising the tree (/graph) information as being an overlay on top, as this offers alternatives for its representation (notably it doesn't tie you to one big map or distribution between the items).

> To echo Peter's question: since there isn't a standard markup
> definition of "a post", an important use of ThreadsML could be
> as "a vocabulary for indiviudal message/posts and for the
> collection of those posts into threaded conversations".

Yep, and I think these terms should be potentially mappable to those of Threads Description Language and IBIS.

> Peter, I think, as a markup language, ThreadsML can define a
> schema for messages/posts. I don't know if it needs to tackle
> things at the MIME level or API level.

These aspects could be built in parallel, they'd all be needed in an implementation. How specific/general things needed to be could be decided afterwards...

Of course, services that
> use ThreadsML need to *know* how the ThreadsML schema might map
> to an API like Blogger or a MIME type like text/html or a POP3
> message.

I think it will be important to consider such mappings to enable easy interfacing and in turn help encourage adoption.

Cheers,
Danny.

Excellent stuff. I see two issues that need addressing in these recent messages.

1. Representation of individual messages in ThreadsML (apart from the act of extracting a single message). I especially think the MIME consideration might be important with the recent advent of audio blogging. Should we simply say that, for purposes of the markup language, message content is an opaque blob? We can probably learn from the history of how MIME made its way into email standards (more reading for me -- pointers to other discussions, or your own perspective, are welcome).

2. How individual messages or specific ranges of messages might be extracted from a thread. This is in the domain of APIs or URIs-plus-protocol. My penchant for simplification says "defer discussion for now" given my focus on the data standard, but it's worth exploring, maybe just to flush out more use cases.

Regardging URIs-plus-protocol, or addressability, I'm imagining a ThreadsML exporter that supports, for example, extraction of a range of messages via a URI. Is that what you have in mind, Jay?

Peter, the most concrete proposal to date is here:
http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66. Yes, it's time to gather this into the wiki.

Did I miss anything?

I think it might be useful, for a moment, to talk about a post in terms of it being an entity that has relationships.

The post would have entity attributes (some optional) like creator, subject, body, created timestamp, and last modified timestamp. Then there are relational attributes (some or all optional) to things like other posts and threads.

I think with MIME types, there are at least two options that ThreadsML could support:

1. have MIME type be an attribute of a post (i.e., the body of this post is an image/jpeg)

2. have an "attachment" relation of a post, and the attachment has a MIME type (i.e., this post has attached a chunk of data that is an image/jpeg)

Probably supporting both options would be best. The second option could allow someone to work with the "text only" portion of a ThreadsML document, which could come in handy if the thread includes huge amounts of audio/video data.

With all the relations, there are potentially URIs that point from the post to another post, or to a "parent" (thread), or to an attachment. Another relation I was implying in my previous messsage (/m119) was from a post to its source location(s) on a network.

ThreadsML could be unconcerned with expresing the concept that a ThreadsML document is made up of parts that come from potentially different locations, but I got the sense everyone is thinking about it as being a way to bring together pieces in this way. Is this correct?

If so, then ThreadsML needs to be able to express / describe the types of addresses at which posts and threads live. And, I was suggesting this is probably URI-plus-protocol-stuff in order to account for things like XML-RPC.

(Is there a way to represent, say a blogger.getPost XML-RPC call in a single URI, like xml-rpc://server/bloger/getPost?id=1 ? Maybe there is a need for a standard XML-RPC URI to be created?)

Steve, I think this addressability could be useful for both importing and exporting support.

In terms of expressing relations to locations, a post potentially could be related to:

-other data in the same ThreadsML document (another post, an "attachment")
-a URI (a parent thread, a source location)
-a URI + protocol-stuff (same as above)

I think, with these matters, much of this stuff could be optional. So, ThreadsML could go through some versions, where version 1 covers the more obvious required and optional elements, and some of these more complex optional elements could be added later without changing what is in version 1.

Jay, thanks for your incisive thoughts. I hope to get back to this soon -- just wanted to let you know I read it and think it's valuable.

Frustration - one of the wonderful things about dealing with trhee different Wiki's simultaneously (SSA, ThreadsML, Joi's) - is that they're all slightly different.

So:
- how do I log onto the ThreadsML Wiki
- there is no "New Page" - even though I myself have created a new page there before
- this is what we mean by "hard to use"
- this Wiki should have a shortcut "punctuation guide" - like the SocialText Wiki does - so if you get lost or confused - answers are close by.......

Marc wrote:
> - how do I log onto the ThreadsML Wiki
> - there is no "New Page" - even though I myself have created a
> new page there before
> - this is what we mean by "hard to use"
> - this Wiki should have a shortcut "punctuation guide" - like
> the SocialText Wiki does - so if you get lost or confused -
> answers are close by.......

Marc, I've added a few clarifications to the bottom of the front page of the ThreadsML wiki. Hope this helps.
http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML

Clearly we should all standardize on Socialtext's Nice Little Wiki (it *is* nice!).

I have been thinking more about representing the "post address", trying to account for cases where a post is addressible via a URI vs the cases were a post is addressible via a RPC interface (e.g., XML-RPC or SOAP, through a Blogger or other API).

So, at this point, I am thinking the idea of RPC "addresses" is probably something to revisit in the future for ThreadsML, because I haven't found or figured out a standard way to do this--or even seen others working on this.

I am working on something around this for the iCite net, and have written about it most recently here: http://icite.net/blog/200305/rpc_address_idea.html

I would apprecaite any feedback in general on this, and I hope this consideration is useful in the definition of ThreadsML.

Jay, I found your thoughts about APIs and protocols useful. And in response to the general idea that it's not so easy to create a generalized API and protocol, I tend to think in my boringly pragmatic way: what tools want to talk to what other tools, and what do they want to do (and what do people want to do with them)?

Here's one use for a general API: I want to have my own desktop (or web-base) console from which I not only track all the conversations and other 'feeds' I'm involved or interested in, but where I can I want to be able to participate in them from the same interface: My Universal Remote for discussions.

>
< replied-to message removed by QT >

It's still very much a work in progress, but in my Ideagraph app I can get a graphic view from a blog's RSS feed with each post showing up as a node. What I'd like to be able to do is to select a node and choose 'Get thread' (or whatever) and have this open up a new tree/graph view containing all the posts as nodes with the arcs between them showing the relationships between the posts (agree/disagree etc, if available).

Just remembered there's already a tool that does something very similar - David Jane's blogmatrix :

http://www.blogmatrix.com/blogtrack?thread=984883

(needs SVG plugin/viewer)

Cheers,
Danny.


< replied-to message removed by QT >

Steve, thanks for suggesting your example of a desktop thread reader / poster as a way to talk about the URI / protocol concerns in a more pragmatic way.

Imagining your example, I have to assume that some threads one might participate in will require interactions / protocols more complex than a single URI. Many can be represented like (mock excerpt example):

<thread id="1234">
  <--this post lives at-->
   <post uri="http://someURI/12345" method="http_get" />
  <--add a new post at-->
   <newpost uri="http://someURI/newPost" method="http_post" />
</thread>

But, when there is an RPC interface being used, those single URIs above are replaced by API-specific sets of parameters.

One question I am thinking about in general is whether, or how much of, the API-specific sets of parameters should be represented in ThreadsML vs only being in application specific data stores.

A simple example is that your application needs to be able to post to a discussion using the Blogger API, which uses XML-RPC.

One way to do this would be to have some reference, stored in the application, between the thread and an application-stored profile describing the API-specific parameters (server name, end point, username, password, blogID) needed to create a post.

Another way to do this is having all of those parameters stored in the ThreadsML in some way--the advantage of doing this being that the ThreadsML is *complete* and could effectively be more portable.

I like the latter approach, and think it could be workable-- perhaps simply by allowing ThreadsML to support namespaces that would allow different API-specific parameters to be plugged-in through different namespaces.

I can try to create some mock examples of this approach.

There is another approach I am thinking about for the iCite net, which is having a URI from which API info can be obtained (kind of like Really Simple Discoverability, or RSD--though I am thinking of calling what I am working on Less Simple Discoverability, or LSD ;-).

Again, I can try to mock up an example of how this might look in ThreadsML.

But, I wanted to let everyone know that I am trying to work towards some useful potential conclusions / variations with regards to this for ThreadsML, and appreciate any feedback.

Jay wrote.......

One question I am thinking about in general is whether, or how
much of, the API-specific sets of parameters should be
represented in ThreadsML vs only being in application specific
data stores.

A simple example is that your application needs to be able to
post to a discussion using the Blogger API, which uses XML-RPC.

One way to do this would be to have some reference, stored in
the application, between the thread and an application-stored
profile describing the API-specific parameters (server name, end
point, username, password, blogID) needed to create a post.

Another way to do this is having all of those parameters stored
in the ThreadsML in some way--the advantage of doing this being
that the ThreadsML is *complete* and could effectively be more
portable.

Marc replied........

>>>>> Sounds WAY too complicated - to me. But I'm just a marketing-CEO
weasel.

>>>>> All ThreadsML threads should understand the same vocabulary. If
we start referencing lists of references or verbs = Oi.

- Marc

> >>>>> Sounds WAY too complicated - to me. But I'm just a
> marketing-CEO
> weasel.
>
> >>>>> All ThreadsML threads should understand the same
> vocabulary. If
> we start referencing lists of references or verbs = Oi.

I agree with the weasel ;-)
To get at an existing thread, all that should be needed is (RESTful) http gets. I'm not sure that the ability *to create* and add a currently non-existent post to a thread is necessary or desirable. Post creation is completely open-ended (blogger, email, QT...), so I reckon the creation of the posts should be left to the other systems, and for ThreadsML, pointers to the (readable) leaves of the thread should be enough.

Cheers,
Danny