top bar
QuickTopic free message boards logo
Skip to Messages

TOPIC:

ThreadsML???

Introduction
This is a continuation of a discussion about ThreadsML started over a year ago. Marc Canter resurrected it with an introductory email and has been pushing it along since then.
 
Reference links:
ThreadsML.org
Early definitive statement in the older discussion
An early JOHO article by David Weinberger
(not accepting new messages)
  Messages 284-281 deleted by author between 07-10-2008 08:24 AM and 04-03-2005 08:15 PM
280
Danny Ayers
06-26-2003
04:32 AM ET (US)
> Sorry I haven't posted back on this yet. I'm taking a few days
> off in celebration of the release of QT Pro
> (http://www.quicktopic.com/gopro). I'll be back soon;

Congratulations!

Cheers,
Danny.

PS. I recommend traveller's rehydration powders for hangovers ;-)
279
Steve YostPerson was signed in when posted
06-25-2003
03:22 PM ET (US)
I should also mention that the just-announced QuickThread (http://www.quicktopic.com/cgi-bin/quickthr...l=/em/H/mXbfHC2srY3) serves as a good example of what *could* be accomplished natively by email clients and *any* web board/mailing list if they both supported ThreadsML.

As it is, you forward your batch of emails to new@quicktopic.com and we automatically create a QuickTopic forum from them.
278
Steve YostPerson was signed in when posted
06-25-2003
03:18 PM ET (US)
Sorry I haven't posted back on this yet. I'm taking a few days off in celebration of the release of QT Pro (http://www.quicktopic.com/gopro). I'll be back soon; Sam Ruby's work sounds interesting.

-Steve
277
Marc Canter
06-24-2003
05:39 PM ET (US)
Here here - these are good times for open standards.

My own personal needs revolve around getting a face or image associated with a channel into the spec - so aggregators can give a visual clue to folks - who's channel it is.

Images could also get formerly associated with posts as well - though this is more problematic. Mainly because we can standardize on 32x32 or 48x48 for identifier images - while content images need to be a wide range of sizes and shapes.....

Anyway back to the relationships between PIE and ThreadsML.

How 'bout one of you - go and post something about 'our' schema - and extend a collaborative effort to Sam and his efforts?

- Marc

< replied-to message removed by QT >
276
Danny Ayers
06-24-2003
05:10 PM ET (US)
In case anyone in RSS-land hadn't noticed, Sam Ruby's set up a Wiki to work on a conceptual model of a (web)log. Quite a mixed bag of luminaries have asserted their support. This may lead to a successor to RSS that everyone can agree on (working title is 'Pie' as in 'easy-as'), or it may just be an interesting exercise in analysis and group dynamics. Either way it's significant to the ThreadsML initiative - if something does come out of it, ThreadsML needs to be able to operate with it from day 1. The analysis will be worth watching as it certainly treads into ThreadSpace, we could learn here. I have plenty of personal reservations, but I've been reading Sam's blog long enough to trust his approach (smart guy too), and I think this is almost certainly a (rare) case of it being better to influence things from within.

Sam's trying to address one issue at a time on his blog (just started with the about/link/guid/URI stuff) :

http://www.intertwingly.net/blog/

The Wiki's at :

http://www.intertwingly.net/wiki/pie/

Particularly significant to ThreadsML is the 'Related' stuff - "An Entry exists in an environment of Web Pages, Weblogs, other Entries, Channels, Threads, etc. If we want to fully model Entry, Entry should know how it relates the environment." :

http://www.intertwingly.net/wiki/pie/Related

Cheers,
Danny.
275
Marc CanterPerson was signed in when posted
06-15-2003
02:24 PM ET (US)
Howdy folks. Happy Father's Day.

Check this out:
http://radio.weblogs.com/0122611/outlines/Conversation.html

It's a WebOutliner doc - saved off as a read-only form - which maps out how WebOutliher would edit ThreadsML files. Re-entrant conversations.

There's also instructions in here - for adding your own input into this conversation. Sorry it's not ThreadsML compliant - yet. But you'll get the idea of how exciting this is.
Edited 06-15-2003 02:25 PM
274
Marc Canter
06-14-2003
04:26 PM ET (US)
Yes - there is some overlap - but also with our People's DNS efforts - as well.

Basically you've speced out a cool new tool.

We put that into the category of "go for it - dude!" We support 100%.
- Marc

< replied-to message removed by QT >
273
David H. Deans
06-14-2003
03:09 PM ET (US)
Hello folks, Ben Hammersley sent me over here.

I've posted a brief description of what I refer to as a "GypsyBlogger" application, and associated "Blogger Caravans" here http://www.erablog.net/blogs/dhdeans/

Note, the "trackbacks" link leads to further closely associated comments on other sites. At the AlwaysOn site, be sure to page down to the "member comments" section, and that's where I reference my dialogue with Ben.

If there's a good parallel with your ThreadsML project, then let me know. If not, please excuse this interuption.
272
Steve YostPerson was signed in when posted
06-11-2003
11:24 AM ET (US)
Off topic: I've put this topic into QuickTopic Pro mode (sneak preview for you all). That's visible to participants in two ways: you can upload pictures, and there's a topic introduction at the top of the page. (I could customize the look too, but will defer that for now). I'm doing a beta soon, so you may soon see other QuickTopic forums with the QuickTopic Pro logo at the top.

If you'd like to participate in the beta, let me know at syost@quicktopic.com.

Excuse the thread interruption.
271
Marc Canter
06-10-2003
03:59 PM ET (US)
Yes and thank you VERY MUCH for your work on said specs.

:-)

< replied-to message removed by QT >
270
Danny Ayers
06-10-2003
03:36 PM ET (US)
hehe

The URI http://purl.org/threads has been confirmed as ours, with myself and Steve as maintainers.
At the moment, as a URL it will/should redirect to threadsml.org (doesn't seem to have gone through the system yet). Eventually I suppose it should resolve to the spec(s).



< replied-to message removed by QT >
269
Marc Canter
06-10-2003
01:09 PM ET (US)
And I'd be honored - in the true spirit of chaordic principles - to welcome Steve and Danny as our 'maintainers'.

I just hope they don't evolve into 'containers'.

Or even worse - the dreaded - 'sustainer'.

Maybe now - the humble Mr. Hammersley can take that spec, read it and spit out some more details for our web site.

- Marc

< replied-to message removed by QT >
268
Steve Yost
06-10-2003
08:05 AM ET (US)
Excellent, Danny. I'll be happy to be listed as maintainer. I just registered at purl.org. Username is steve-yost.
> once they've confirmed it would be good to add another person as
> another maintainer - Steve? You'd just have to register at
> purl.org, if you haven't already.
267
Danny Ayers
06-10-2003
05:19 AM ET (US)
Hi folks,

I've updated the sample in the strawman vocabulary [1] on the Wiki following Steve's suggestions (I'd got the FOAF way out), also tweaked it (e.g. inserted the missing RDF namespace ;-) so it's now valid RDF according to the W3C's validator [2].

I've submitted a request at purl.org to use the obvious namespace:
http://purl.org/threads

once they've confirmed it would be good to add another person as another maintainer - Steve? You'd just have to register at purl.org, if you haven't already.

I've still not got any further with the person-grouping stuff (I was meant to be writing an article about RDF grouping last week too), but that's very much on my list for the next couple of days.

Cheers,
Danny.

[1] http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary [2] http://www.w3.org/RDF/Validator/
266
Steve Yost
06-08-2003
06:27 PM ET (US)
Rick Thomas wrote:
> ...This suggests that a hierarchy is not an adequate model.

True, and fortunately Danny Ayers' recent proposal does allow for multiple parents. See http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary
265
Deleted by author 06-08-2003 04:23 PM
264
Danny Ayers
06-03-2003
12:18 PM ET (US)
Whoops!
You're quite right.

For some, e.g.

  <foaf:Person foaf:name="Lena">

I think this would be valid as an alternative, but like you suggest for the readers benefit it'll be better as

  <foaf:Person>
  <foaf:name>Lena</foaf:name>
...
  </foaf:Person>

This one :

   <foaf:email rdf:resource="lena@twounlimited.com" />

I believe is simply *wrong* - the resource should be a URI, so again the literal format above is better (not wrong!).

That's what comes from not consulting the manual...

Cheers,
Danny.


< replied-to message removed by QT >
263
Steve Yost
06-03-2003
12:01 PM ET (US)
Danny wrote:
> Attributes? I've just looked at my FOAF and it starts like this
> :
> <foaf:Person>
> <foaf:name>Daniel Ayers</foaf:name>
> <foaf:title>Mr</foaf:title>
> <foaf:firstName>Danny</foaf:firstName>
> ...
>
> So the values all seem to be literal text (if anything, I'd have
> though the nesting would have caused problems).
>
Ah. Should we change the wiki to match that then? Or am I mis-reading it?
As I realized, since dc:contributor is in the <items> element, RSS readers are not reading dc:contributor now, so it's really not an issue. But yes, we can hope they'll accomadate the FOAF if it's there. I'd be more confident if FOAF wasn't just "the best choice at the moment". So I'd want to make FOAF optional for dc:contributor, with plain text an alternate. Thoughts?
262
Danny Ayers
06-03-2003
07:58 AM ET (US)
> Actually, thinking about Danny's proposal a little more, I'm
> confusing the dc:contributor element with the dc:creator element
> in the individual post. The dc:contributor item should be
> considered optional -- shouldn't we specify which elements are
> required and which are optional? And it won't break RSS readers.

That sounds very reasonable. Feel free to edit the Wiki.
Personally I'd probably go for making the minimum of the elements mandatory, with the idea that a little data is better than none at all.

Cheers,
Danny.
261
Danny Ayers
06-03-2003
07:58 AM ET (US)
> I'd like to try implementing the strawman proposal Danny
> proposed at
> http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary,

cool!

> but I haven't heard back about the usage of foaf for the
> dc:contributor element.

Looking into it, I'll get back to you, but for now at least use your best guess.

> My concern is that the foaf element will break existing RSS
> readers, which at best will ignore tags that it doesn't
> recognize, and therefore simply not find anything in the
> dc:contributor element, since all of foaf's data seems to be
> represented as XML attributes rather than text elements (or is
> there an alternative?). If that's the case, I must ask for an
> alternative or eliminate the foaf element.

Attributes? I've just looked at my FOAF and it starts like this :
<foaf:Person>
<foaf:name>Daniel Ayers</foaf:name>
<foaf:title>Mr</foaf:title>
<foaf:firstName>Danny</foaf:firstName>
...

So the values all seem to be literal text (if anything, I'd have though the nesting would have caused problems).

I think we should consider it a bonus if current RSS readers can view the data, rather than a requirement. I reckon that if the data is available in a systematic format, then the tool builders will adjust accordingly. We certainly need a way of identifying the people, and FOAF looks the best choice at the moment.

Cheers,
Danny.
260
Steve YostPerson was signed in when posted
06-02-2003
11:18 PM ET (US)
Actually, thinking about Danny's proposal a little more, I'm confusing the dc:contributor element with the dc:creator element in the individual post. The dc:contributor item should be considered optional -- shouldn't we specify which elements are required and which are optional? And it won't break RSS readers.
259
Steve YostPerson was signed in when posted
06-02-2003
11:14 PM ET (US)
Mark Woodward, I read your thoughts at http://stopwar.us/threadsml.html. You could probably do much of what you want if your forum site simply supported RSS, but ThreadsML would obviously be applicable for representing the threaded discussions.
258
Steve Y.Person was signed in when posted
06-02-2003
11:10 PM ET (US)
I'd like to try implementing the strawman proposal Danny proposed at http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary, but I haven't heard back about the usage of foaf for the dc:contributor element.

My concern is that the foaf element will break existing RSS readers, which at best will ignore tags that they doen't recognize, and therefore simply not find anything in the dc:contributor element, since all of foaf's data seems to be represented as XML attributes rather than text elements (or is there an alternative?). If that's the case, I must ask for an alternative or eliminate the foaf element.
Edited 06-02-2003 11:10 PM
257
mwoodwarPerson was signed in when posted
05-31-2003
05:14 PM ET (US)
Thanks for the welcome Steve. I've posted in the wiki (will parade my ignorance and say that this is my virgin wiki post...hope it came out ok).

In case it didn't, you could have a look at my thoughts on including a ThreadtoRSS element at http://stopwar.us/threadsml.html


Mark
256
Jon Lebkowsky
05-31-2003
04:59 PM ET (US)
> Oh, and hello, Jon. So you *are* reading :-) Glad to have your eyes
> and mind on this.

I'm getting the posts via emails but I was out of the loop for a while, several irons in the fire. I've just printed the 77-page ANS paper & want to read it, then go over the stuff in the threadsml wiki and look for the resonance that Marc's seeing.
255
Steve Yost
05-31-2003
04:29 PM ET (US)
Welcome, Mark! With 10 years of experience, you can probably come up with some good use cases, or just validate the ones we have. Feel free to leave commentary or add your own ideas at the wiki in the use case area: http://www.quicktopic.com/cgi-bin/thwiki.pl?UseCases

Oh, and hello, Jon. So you *are* reading :-) Glad to have your eyes and mind on this.


Mark wrote:
> Hello there, I am new to the discussion but very much interested
> in ThreadsML (am drinking the kool aid as we speak)....
254
mwoodwarPerson was signed in when posted
05-31-2003
02:41 PM ET (US)
Hello there, I am new to the discussion but very much interested in ThreadsML (am drinking the kool aid as we speak).

I learned about this at the OSCOM conference from Jon Udell, and think that it is a significant, and much needed piece of work.

Though not a programmer, I have spent the better part of 10 yrs in some way managing online discussion forums, and am willing to help in whatever way I possibly can. In the meantime, I wanted to say hello from the Nashville area...and will continue reading.

Mark

ps The online outliner is really boss
253
Marc Canter
05-29-2003
07:28 PM ET (US)
Just so you know - I'm gonna be talking a lot over the next week or so about something called the ASN (Augmented Soical Networks.) I'll be bringing up ThreadsML as much as I can - taking ALL of your names and efforts in vein.

JUST KIDDING!

No I just wanted you all to know that there are LOTS of folks who want and who can profit and prosper from something like ThreadsML - and we're all "rooting" for yah!

:-)

So the ASN is a dream-like scenario that a few folks are theorizing. And so I'm part of a group that is challenging the premise of just sitting around talking. We're saying: "well what IF you had the resources, brains, money and support?"

So ThreadsML comes in play here. Nobody doesn't want it - let's put it like that.
252
Jon Lebkowsky
05-28-2003
03:34 PM ET (US)
> woe...woe is me...this referred-to-message-removing is *really*
> annoying. I'm losing track of threads. Also, not being able to
> change the subject line...lost, adrift in a sea of mails.

Dude... you need threadsml!

~ jon
251
Marc Canter
05-28-2003
03:12 PM ET (US)
Facts:

1. Yes that's why we need ThreadsML and are here in the first place.
2. The Wiki lives as a breathing, seething beast. Feel free to throw away all of it and start over (at least the page I created - for the purposes of the web site getting fleshed out.)

3. It's gonna take one session of just reading through everything - to get a synonymous trail going. There's nothing we can do about that.
4. Buono fortuna.

< replied-to message removed by QT >
250
Ben Hammersley
05-28-2003
02:25 PM ET (US)
woe...woe is me...this referred-to-message-removing is *really*
annoying. I'm losing track of threads. Also, not being able to change the subject line...lost, adrift in a sea of mails. I want my metadata back.

Also, could changes to the wiki, or a notifier of such, be posted to the list. I'm offline a lot of the time at the moment, and can't keep up with distributed conversations. (Therein find a use case for
ThreadsML)

Anyway, yes, I'll load the old faithful and see what I can tap out for the good Doctor...
249
Marc Canter
05-28-2003
02:04 PM ET (US)
In the sense of:

"who's doing what?"

"why is it such a hodge podge?"

"am I missing something here?"

or

"what am I supposed to do?"

Consider all that crap fodder and source material. I tried going through recent posts - culling what seemed like juicy tid-bits - to me.
But step back, take a deep drag on that infamous pipe of yours and just do your thang. :-) Please.

Give us some words that:
 - explains what the goals of ThreadsML are
 - what we've come up with so far (may want to check with Steve Y on that)
 - what work is in progress
 - what we can expect as far as a roadmap
 - you know - all that "marketing stuff that humans need" kind of communication stuff..........

And then send that to the good, kind Dr. Weinberger.

:-)

Maybe we can even get Paolo to create a good logo for us.

:-)

- Marc

< replied-to message removed by QT >
248
Ben Hammersley
05-28-2003
01:51 PM ET (US)
I have editor access there... wassup with that page?

On Wednesday, May 28, 2003, at 17:40 Europe/Stockholm, QT - Marc Canter wrote:

>
< replied-to message removed by QT >
247
Marc Canter
05-28-2003
11:40 AM ET (US)
Dudes,

Does anybody know anybody at Syndic8?

http://www.syndic8.com/feedinfo.php?FeedID=26156

- Marc
246
Danny Ayers
05-26-2003
04:10 AM ET (US)
No idea - I'll ask on rss-dev...

< replied-to message removed by QT >
245
Steve YostPerson was signed in when posted
05-25-2003
06:29 PM ET (US)
How well (and how) does the use of foaf elements for dc:creator and dc:contributor interoperate with existing RSS readers?
244
Danny Ayers
05-25-2003
08:05 AM ET (US)
I've put the strawman on the Wiki as "ThreadsVocabulary", please hack away :
http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsVocabulary
243
Ben Hammersley
05-25-2003
06:27 AM ET (US)
On Sunday, May 25, 2003, at 03:28 Europe/Stockholm, QT - Jay F wrote:
> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> can you think of a better name for tdb:threadHead ?
>
> I think "head", to many people, suggests "header". However, it
> probably would suggest the right meaning to everyone who has
> worked with CVS.
> threadBegin is the other one I like a lot.

thread:firstPost

Obvious... :-)
242
Jay FPerson was signed in when posted
05-24-2003
09:28 PM ET (US)
> can you think of a better name for tdb:threadHead ?

I think "head", to many people, suggests "header". However, it probably would suggest the right meaning to everyone who has worked with CVS.

I was thinking of: threadStart.

This came to mind because, in online forums / discussion moderation, it is common to see "topic started by . . ." or, as on QuickTopic, "start a new topic".

Here are some other possibilities:

threadBegin
threadBirth
threadEnter
threadInception
threadKickoff
threadOrigin

threadBegin is the other one I like a lot.
241
Marc Canter
05-24-2003
08:45 PM ET (US)
OK - so I guess I'll just keep trying, and use the validator to test with........

- Marc "arrows in the back" Canter

< replied-to message removed by QT >
240
Danny Ayers
05-24-2003
05:20 PM ET (US)
> Right, both are optional--either one or both could be used, so:
>
> (optional) I am part of a thread that starts at: some-uri
> (optional) I am responding to (my parent is): another-uri

The second is covered by tbd:parent(s)

The first - can you think of a better name for tdb:threadHead ?

Cheers,
Danny.
239
Danny Ayers
05-24-2003
05:20 PM ET (US)
> Sablotron XSLT transformation error on line 7: XML parser error
> 4: not well-formed (invalid token).

> Is there supposed to be something else in there I'm missing?
> What gives?

I tried it at the W3C's RDF validator

http://www.w3.org/RDF/Validator/


from the URL, it fails (IOException while reading URI at character 249 using encoding null.)

copy & pasting the source, it works.

My guess is there's a junk EOF character or something crept in. Weird.
> P.S. THEN I'm gonna ask you how to add names to my "trusted
> network".

First you'll need a little black book and some invisible ink...
238
Jay FPerson was signed in when posted
05-24-2003
04:08 PM ET (US)
In reply to Danny's comment in /m235:

>I hadn't thought of identifying the head of the thread, but
> for the branch idea I guess that's what would be
> happening. In fact both parts could be optional - "I am
> the head of a new thread". Yep, I reckon this is worth pursuing.

Right, both are optional--either one or both could be used, so:

(optional) I am part of a thread that starts at: some-uri
(optional) I am responding to (my parent is): another-uri
Edited 05-24-2003 04:09 PM
237
Marc Canter
05-24-2003
03:45 PM ET (US)
Hey Danny - thanks for the FOAF bookmarklet.

Since I know FOAF is not directly related to this list, however this issue is relevant to the acceptance and pickup of ANY standard (such as ThreadsML) I'm gonna use this list reply to ask:

"why do I get this error code?"

Error
Unable to parse FoaF (http://blogs.it/0100198/gems/FOAF.rdf).

Sablotron XSLT transformation error on line 7: XML parser error 4: not well-formed (invalid token).

=======================

???????????????

If you look at my FOAF.rdf file - it looks fine to my naked eye. That's what FOAFmatic gave me.

http://blogs.it/0100198/gems/FOAF.rdf

Is there supposed to be something else in there I'm missing? What gives?

- Marc

P.S. THEN I'm gonna ask you how to add names to my "trusted network".



< replied-to message removed by QT >
236
Danny Ayers
05-24-2003
03:42 PM ET (US)
> > I know, early on in this dicussion, RSS was definitely a
> context
> > in which threads were imagined. But, I am asking:
> >
> > Is ThreadsML (at least, phase 1) really just the "threads
> module
> > of RSS"?
>
> Pretty much, but only in that RSS 1.0 is a major vocabulary of
> RDF. I'd go further, though, and say it's a profile too.

Can I add that it will also be an ontology (just don't tell Shelley!).
> Mandating use of the dc elements is absolutely key.

+1.

Cheers,
Danny.
235
Danny Ayers
05-24-2003
03:41 PM ET (US)
> The thread lists each post in the header, and each post lists
> any parents or children it may have. By suggesting this, are you
> imagining this kind of scenario:
>
> 1. a post ken1 is made, starting a thread
>
> 2. a reponse, lena1, is made indicating ken1 as parent and
> "tracking back" to ken1 who adds lena1 as a child
>
> 3. a response, ken2, is made indicating lena1 as parent and
> "tracking back" to lena1 who adds ken2 as a child
>
> -etc.

Yes and no I suppose - I wasn't really thinking that far ahead, just trying to see what you'd need to represent the thread in an RSS friendly fashion. But I'm sure the way you describe it would be a possible scenario.
> Is this correct: this would allow one to store, with/in each
> post, a bit of ThreadsML that represents just the post and any
> parents and children--and from this, an application could
> assemble (aggregate) a complete ThreadsML thread? For example,
> the ken1 post could store with/in it this plus some minimal
> header:



> <item rdf:about="http://example.org/ken1"&___GT___;
> <title>Start of thread</title>
> <content:encoded><![CDATA[<p>Honey, I'm
> home!</p>]]></content:encoded>
> <link>http://example.org/ken1</link&___GT___;;
> <dc:date>2003-05-17T12:45:59+01:00</dc:date>
> <dc:creator>
> <foaf:Person foaf:name="Ken">
> <foaf:email
> rdf:resource="ken@twounlimited.com" />
> </foaf:Person>
> </dc:creator>
> <tbd:parents />
> <tbd:children>
> <rdf:Seq>
> <rdf:li
> rdf:resource="http://example.org/lena1"; />
> </rdf:Seq>
> </tbd:children>
> </item>

Ouch, that got escaped for Outlook...I think I recognise it though. Yep, although I think the centralised server idea is a good one, I reckon setting things up so that they *can* be pretty loosely distributed would leave the options open.

> One of the things I wonder about in this is what exactly the
> start of a thread is. I mean, in general, does a thread always
> have a singular start? Can a post in the middle of a thread be
> the start of a new thread? How would that be expressed?

Interesting thought. Like a CVS branch, then - I don't see why not. We'd need an extra term or two to express this, but it could well be useful later.

> With the iCite net, I am designing it to allow for any child
> post to declare any post in the hierarchy of parents the start
> of the thread. So each post says:
>
> I am part of a thread that starts at: some-uri
> (optional) I am responding to (my parent is): another-uri
>
> Leaving out the optional second declaration would suggest a
> "flat" conversation type thread, where the sequence of posts
> could only be determined by each post's timestamp.
>
> Any thoughs on this?

I hadn't thought of identifying the head of the thread, but for the branch idea I guess that's what would be happening. In fact both parts could be optional - "I am the head of a new thread". Yep, I reckon this is worth pursuing.

Cheers,
Danny.
234
Danny Ayers
05-24-2003
03:32 PM ET (US)
> Could we Bag up the dc:contributors? (I'm still unclear on
> repeating elements in RDF. Danny heeeeeelllllppp)

I'll read up a bit - see if there are any discernable best practices. There's the containers (Bag/Seq/Alt), collections (first (rest)) or just repeated individual properties to choose between... I'll stick this on the faq to-do list while I'm at it...

> Also, I'm concerned that wrapping <rss:items> to <tbd:Thread>
> will break anything that currently uses XML tools to parse RDF.
> I know they're bad and naughty and ripe for a spanking, but we
> need to
> preserve compatibility with RSS 1.0.

Having 'channel' instead? Hmm - suppose so, though it does make it look more like a pig, I might just shoot a mail to rss-dev to try and get a better picture of weak links.

> Inside the FOAF stuff, I'd *love* to see <rdfs:seeAlso>.

Heh, so foaf:* sounds alright then? Again I suppose it would be best to do it in a way that didn't offend too many old-fashioned newsreaders (remember Reginald Bosenquet?).

Cheers,
Danny.
233
Ben Hammersley
05-24-2003
02:30 PM ET (US)
On Saturday, May 24, 2003, at 02:03 Europe/Stockholm, QT - Jay F wrote:
> I know, early on in this dicussion, RSS was definitely a context
> in which threads were imagined. But, I am asking:
>
> Is ThreadsML (at least, phase 1) really just the "threads module
> of RSS"?

Pretty much, but only in that RSS 1.0 is a major vocabulary of RDF. I'd go further, though, and say it's a profile too. Mandating use of the dc elements is absolutely key.
232
Ben Hammersley
05-24-2003
02:29 PM ET (US)
On Saturday, May 24, 2003, at 10:04 Europe/Stockholm, QT - Danny Ayers wrote:

<a whole world of snip/>

> <dc:contributor>
> <foaf:Person foaf:name="Lena">
> <foaf:email rdf:resource="lena@twounlimited.com" />
> </foaf:Person>
> </dc:contributor>
>
> </tbd:Thread>

Could we Bag up the dc:contributors? (I'm still unclear on repeating elements in RDF. Danny heeeeeelllllppp)

Also, I'm concerned that wrapping <rss:items> to <tbd:Thread> will break anything that currently uses XML tools to parse RDF. I know they're bad and naughty and ripe for a spanking, but we need to
preserve compatibility with RSS 1.0.

Inside the FOAF stuff, I'd *love* to see <rdfs:seeAlso>.
231
Ben Hammersley
05-24-2003
02:29 PM ET (US)
On Saturday, May 24, 2003, at 10:04 Europe/Stockholm, QT - Danny Ayers wrote:

> In the example below I've got the parents/children in Seqs - I'm
> not sure this is actually necessary. Do they need to be ordered?
> Would Bag do? Would something like this be better? :

Bag is best, I think. The Seq will undoubtedly be wrong in anything but the simplest case. Besides, because we are mandating use of dc:date, the app can create a timeline sequence quite easily, if the user wants that view. (Personally, I switch between different sequencing all the time, from time to author, to subject and back again.)
230
Jay FPerson was signed in when posted
05-24-2003
02:11 PM ET (US)
Thanks for the example Danny! I have some comments / questions:

The thread lists each post in the header, and each post lists any parents or children it may have. By suggesting this, are you imagining this kind of scenario:

1. a post ken1 is made, starting a thread

2. a reponse, lena1, is made indicating ken1 as parent and "tracking back" to ken1 who adds lena1 as a child

3. a response, ken2, is made indicating lena1 as parent and "tracking back" to lena1 who adds ken2 as a child

-etc.

Is this correct: this would allow one to store, with/in each post, a bit of ThreadsML that represents just the post and any parents and children--and from this, an application could assemble (aggregate) a complete ThreadsML thread? For example, the ken1 post could store with/in it this plus some minimal header:

<item rdf:about="http://example.org/ken1"&___GT___;
   <title>Start of thread</title>
   <content:encoded><![CDATA[<p>Honey, I'm home!</p>]]></content:encoded> <link>http://example.org/ken1</link&___GT___;;
   <dc:date>2003-05-17T12:45:59+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Ken">
         <foaf:email rdf:resource="ken@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents />
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/lena1"; />
      </rdf:Seq>
   </tbd:children>
</item>

One of the things I wonder about in this is what exactly the start of a thread is. I mean, in general, does a thread always have a singular start? Can a post in the middle of a thread be the start of a new thread? How would that be expressed?

With the iCite net, I am designing it to allow for any child post to declare any post in the hierarchy of parents the start of the thread. So each post says:

I am part of a thread that starts at: some-uri
(optional) I am responding to (my parent is): another-uri

Leaving out the optional second declaration would suggest a "flat" conversation type thread, where the sequence of posts could only be determined by each post's timestamp.

Any thoughs on this?
229
Steve Yost
05-24-2003
11:32 AM ET (US)
Just a quick reply to say thanks for the work, Danny, and comments Ben. I'll read in more detail when I get a chance later this weekend.

>
< replied-to message removed by QT >
228
Danny Ayers
05-24-2003
09:19 AM ET (US)
PS. I just remembered Benja Fallenstein's got an informal urn registered (urn-5) which he's using for his Fenfire/Gzz 'Xanadu in RDF' app - it's based on random numbers. Might be a possible.

http://www.iana.org/assignments/urn-informal/urn-5
227
Danny Ayers
05-24-2003
09:17 AM ET (US)
> I can't check if anything exists already, but we do definitely
> need a formal scheme for creating a URI for a single IM
> message, email, or
> message-from-as-yet-unknown-device.

Good point, although I don't think the scheme's an earth stopping issue - it's only part of the identifier, the only definite requirement is that it's unique. If we need to know the transport/format or whatever (probably a good idea) that should go elsewhere. An hash of the content would probably be a good way of getting the uniqueness - there are plenty of off-the-shelf tools/algorithms.

I doubt whether there's a scheme that adequately covers
message-from-as-yet-unknown-device though maybe one of the existing URNs [1] might do (not got time to check the RDFss right now). If there's nothing too close, I guess we could always register an informal URN namespace. I can't see the use of a proper scheme making much difference to any implementation (except perhaps breaking some regex based toys). Anyhow, in the interim the http:// scheme is probably adequate for ID.

So I'd suggest either

http://blah/123123hashofthecontent123123

or

urn:blah:123123hashofthecontent123123

Cheers,
Danny.


[1] http://www.iana.org/assignments/urn-namespaces
226
Ben Hammersley
05-24-2003
08:52 AM ET (US)
Running this through my head, we need to find/invent/build-on a URI scheme for messaging systems other than those that are web based.
For the uninitiated, a URI is a Unique Resource Identifier. They look like URLs, (in the xxxx://yyy.zzz.aaa type format) but DO NOT have to actually resolve. This is important to remember.

The URI is absolutely key to ThreadsML as it is the only real way of identifying each message. With a web based thread the URI can be as simple as the permalink to the message (as long as the permalink is unique forever more) but with IM or email, it's not so simple. We need to look at how we're going to form URIs for an IM message, for example, otherwise we won't be able to do the great feature of threadsml: thread portability.

Now, for reasons too long and dull to go into, I'm writing this mail offline and will send it later in a burst of sendmail, so I can't check if anything exists already, but we do definitely need a formal scheme for creating a URI for a single IM message, email, or
message-from-as-yet-unknown-device.

Perhaps
http://www.threadsml.org/$originatingserve...$/$timesinceepoch$/ $hash$

so,

http://www.threadsml.org/mail.benhammersley.com/ben/123456789/
lsdufg43b34r86tf

http://www.threadsml.org/toc.oscar.aol.com...mmersley/123456789/ fsdhfaffd

which would definitely be unique and identifying. But there may be something already in existence. Perhaps for email, IRC and Jabber, but probably not AIM or SMS or MSN Messenger. If they don't exist already, we'll have to invent them - not a bad thing.

thoughts anyone?
225
Danny Ayers
05-24-2003
04:04 AM ET (US)
It's a man and he's made of hay.
(I had pollen-induced insomnia last night, gave me time to think about this)
"ThreadsML: a /rather/ good extension to RSS"

Namespace :
xmlns tbd = "http://purl.org/to-be-decided"

Vocabulary :

tbd:Thread (class)

rss:item (class)
rss:items (property)

tbd:parents (property)
tbd:children (property)

dc:creator (property)
dc:contributor (property)
dc:date (property)

content:encoded (property)

foaf:* as required

----
Thread is the big boss - a thread will contain the whole, errm, thread.
Ok, RSS item is reused to represent individual messsages or posts, items to represent the sequence of posts in chrono order - the timeline. This should give existing RSS apps a chance of displaying ThreadsML without
modification. Ideally we would define a term in our own namespace - perhaps a subclass of rss:item, but then the namespace would confuse the
aggregators.
The only problem with this is the mandatory requirements of rss:item : title and/or description and maybe link I think - maybe we use dummies?
tbd:parents/tbd:children - poor names, but we need something that avoids confusion with nextByDate/previousByDate.

In the example below I've got the parents/children in Seqs - I'm not sure this is actually necessary. Do they need to be ordered? Would Bag do? Would something like this be better? :

<item rdf:about="http://example.org/lena1">
...
   <tbd:child rdf:resource="http://example.org/ken2" />
   <tbd:child rdf:resource="http://example.org/henna1" />
   <tbd:child rdf:resource="http://example.org/senna1" />
...
</item>

----

Anyhow, here's minimal example :

<rdf:RDF xmlns="http://purl.org/rss1.0"
         xmlns:tbd = "http://purl.org/to-be-decided">

<tbd:Thread>
   <items>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
         <rdf:li rdf:resource="http://example.org/lena1" />
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/lena2" />
      </rdf:seq>
   </items>
</tbd:Thread>

</rdf:RDF>

The Seq above shows the timeline.

---

Full example :

<rdf:RDF xmlns="http://purl.org/rss1.0"
         xmlns:tbd = "http://purl.org/to-be-decided"
         xmlns:dc = "http://dublincore.org/dc"
         xmlns:foaf = "http://purl.org/firthofforth"
>

<tbd:Thread>

<!-- metastuff about the thread -->

<items>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
         <rdf:li rdf:resource="http://example.org/lena1" />
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/lena2" />
      </rdf:seq>
</items>

<dc:contributor>
   <foaf:Person foaf:name="Ken">
   <foaf:email rdf:resource="ken@twounlimited.com" />
   </foaf:Person>
</dc:contributor>

<dc:contributor>
   <foaf:Person foaf:name="Lena">
   <foaf:email rdf:resource="lena@twounlimited.com" />
   </foaf:Person>
</dc:contributor>

</tbd:Thread>

<item rdf:about="http://example.org/ken1">
   <title>Start of thread</title>
   <content:encoded><![CDATA[<p>Honey, I'm home!</p>]]></content:encoded> <link>http://example.org/ken1</link>;
   <dc:date>2003-05-17T12:45:59+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Ken">
         <foaf:email rdf:resource="ken@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents />
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/lena1" />
      </rdf:Seq>
   </tbd:children>
</item>

<item rdf:about="http://example.org/lena1">
   <title>blah</title>
   <content:encoded><![CDATA[<p>You're late!</p>]]></content:encoded> <link>http://example.org/lena1</link>;
   <dc:date>2003-05-17T12:46:00+01:00</dc:date>
   <dc:creator>
      <foaf:Person foaf:name="Lena">
         <foaf:email rdf:resource="lena@twounlimited.com" />
      </foaf:Person>
   </dc:creator>
   <tbd:parents>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken1" />
      </rdf:Seq>
   </tbd:parents>
   <tbd:children>
      <rdf:Seq>
         <rdf:li rdf:resource="http://example.org/ken2" />
         <rdf:li rdf:resource="http://example.org/henna1" />
         <rdf:li rdf:resource="http://example.org/senna1" />
      </rdf:Seq>
   </tbd:children>
</item>

</rdf:RDF>
224
Jay FPerson was signed in when posted
05-23-2003
08:03 PM ET (US)
Wow, this discussion can really move in a couple days when it gets a little momentum!

So, is the focus now defining the threads markup wholly within the constraints of RSS?

I know, early on in this dicussion, RSS was definitely a context in which threads were imagined. But, I am asking:

Is ThreadsML (at least, phase 1) really just the "threads module of RSS"?
223
Marc Canter
05-23-2003
04:27 PM ET (US)
One wants to stay away from hype - 'cause I happen to know that Danny Ayers is here and if you piss HIM off, then you're in trouble.

:-)

Anyway - associating ourselves with RSS - when we have MR RSS himself - the good Ben one here - is obvious. (or as I call him "Big Ben".) It's OK if I'm bigoted here - as people called me "Big Mac" - for years. (Marc Aaron Canter) - which of course put us in good graces with Apple when it came to being the 10th Mac developer back in '83.

:-)

< replied-to message removed by QT >
222
Steve Yost
05-23-2003
04:04 PM ET (US)
> Call it:
>
> "ThreadsML: an extension to RSS"

Hey, it's Marketing. Shouldn't it be

"ThreadsML: a good extension to RSS"

See, I'm not in Marketing. All I could come with is 'good'.
221
Marc Canter
05-23-2003
04:00 PM ET (US)
Marketing department votes:

Fine.

Call it:

"ThreadsML: an extension to RSS"

< replied-to message removed by QT >
220
Steve Yost
05-23-2003
03:57 PM ET (US)
> I think we've got all the bits we need - so I guess first we
> either need to do a strawman prototype or formalize the
> requirements, heh, can I guess which way this will go...

You got it! Show us the prototype!

> > BTW, the OWL would be for anyone using the old module who
> wants
> > a semantic mapping, right?
>
> I'm happy to go for the OWL birthing (assuming the beak's the
> right way up). The way I imagine it working is with the layering
> :
>
> (1) informally specified : compatibility RSS 2.0 (kind of)
> (2) specified as RDF vocabulary/RSS module : (1) + compatibility
> RSS 1.0 + general RDF
> (3) with OWL : (1) + (2) + stricter RDF/reasoning etc

Sounds good!

>
> Any app that didn't get 3 could still operate on 2, any app that
> didn't get 2 could still operate on 1, though 1 would probably
> just be a "display text" kind of level, and the apps that could
> do groovy things with (3) are still on the drawing board...

My guess is that many existing apps would find themselves at (1), but I see your point :-)

>
> I'll be happy to do an XSLT RSS 2.0 -> RSS 1.0 mapping as well.

Great idea. Surprised it hasn't been done. Or do you mean just for the ThreadsML extensions?

Geez, can we call it that now -- an extension to RSS?
219
Deleted by topic administrator 06-24-2008 02:19 AM
218
Marc Canter
05-23-2003
03:41 PM ET (US)
Now that's to presume (and I don\t wanna come off as anti-FOAF at all - as much as anti-hype) that FOAF exits as well.

I have just undergone an intense three day "what the fuck is FOAF" effort. And dudes let me tell you here - it ain't much.

The FOAFnaut doesn\t work, the FOATamatic gave me a FOAF record - which is now dutifully embedded into the header of my blog's HTML page and "now what?"

Where are the apps that do something with FOAF? Where is the spider crawling the web detecting FOAF-ites?

Am I missing something here?

For all the TALK about FOAF - what's the benefit? Am I crazy or what?
I like the icon-logo though - that's cool! But there ain;t much there besides that..........

< replied-to message removed by QT >
217
Danny Ayers
05-23-2003
03:38 PM ET (US)
> > (in fairness, sure, we could change it, but making one from
> > scratch with the proper schema behind it and suchlike is
> > probably easier. Danny could probably give birth to
> some OWL
> > without much discomfort or squawking, and do that and some
> > proper documentation would be bliss. I'll document, whence
> the
> > time comes.)
>
> Sounds good. Want to take a shot at it? This is just for the
> threading 'overlay', agreed? Anyone else want to participate in
> creating (vs reviewing) the new module?

I think we've got all the bits we need - so I guess first we either need to do a strawman prototype or formalize the requirements, heh, can I guess which way this will go...

> BTW, the OWL would be for anyone using the old module who wants
> a semantic mapping, right?

I'm happy to go for the OWL birthing (assuming the beak's the right way up). The way I imagine it working is with the layering :

(1) informally specified : compatibility RSS 2.0 (kind of)
(2) specified as RDF vocabulary/RSS module : (1) + compatibility RSS 1.0 + general RDF
(3) with OWL : (1) + (2) + stricter RDF/reasoning etc

Any app that didn't get 3 could still operate on 2, any app that didn't get 2 could still operate on 1, though 1 would probably just be a "display text" kind of level, and the apps that could do groovy things with (3) are still on the drawing board...

> > Actually, this is a good idea if we want to make it RSS2.0
> > compatible too.
>
> Excellent.

I'll be happy to do an XSLT RSS 2.0 -> RSS 1.0 mapping as well.

Cheers,
Danny.
216
Danny Ayers
05-23-2003
03:29 PM ET (US)
Bravo!

< replied-to message removed by QT >
215
Danny Ayers
05-23-2003
03:29 PM ET (US)
> That's fair enough for me. I mean, yes, it can be done with 2.0
> - no question about that. It's just that it will be, almost by
> definition, not very useful for anything but parse-and-display.
> For
> parse-and-display, 2.0 is the mackdaddy. It's simple to
> understand and throws through XML::Simple like a hot cat
> through butter. But for smooshing with other vocabularies,
> putting into rdf databases, doing advanced queries and all that
> funky stuff, it's not even in the game. But, anyway, Onwards!

I think it'll be easy enough to knock together an RSS 2.0 mapping through which it would be possible to do all the wonderful things, as long as the content producers were prepared to follow guidelines. But RSS 2.0 wasn't designed for heavy lifting so because of that, and not because of any intention here, it would be a lot more work for app builders to go that route.
For example, there isn't any consistent way of identifying people within RSS 2.0, but RSS 1.0 can plug in FOAF right away, thanks to the shared model.
> In a total sidetrack, I've been listening to Carmen all
> afternoon, and it has come to my attention that the great
> heroine of French Opera is a bit of a bitch. I just wanted to
> share.

Heh, thank you for sharing that. I must admit I chuckled when I found out that Rigoletto's "La donna é mobile" is all about how fickle women are (yes, I did get a slap).

Cheers,
Danny.
214
Danny Ayers
05-23-2003
03:19 PM ET (US)
> Danny wrote:
> > IMHO, definitely. I don't think the whole kitchen sink is
> needed
> > (as in Thread Description Language [1]) but then I think it
> > needs to be made clearer than the Annotation and Threading
> > modules. (can always include owl:equivalentTo if needed!).
>
> I'm not sure what you mean by clarity here. My concern is mostly
> that we're co-opting the Annotation module for something that
> wasn't its 'true' intention. Is that what you mean? The
> Threading module, I think, is clear enough in its semantics and
> usage.
>
> >
> > It needs to work both ways in such a way that the whole graph
> > could be drawn starting at any given point (in theory at
> least),
> > and ditto the timeline.
>
> With the idea that a threading structure is an overlay on top of
> a linear timewise structure, we can say that child and parent
> items aren't necessary unless there are more than one child, or
> if the child or parent are contained elsewhere. This means that
> apps need to add the virtual parent-child relationship if it's
> not explicit, but it seems that any app that's reading ThreadsML
> is reading and building and internal sequence anyway.
>
> Or do you mean to say that I should be able to pluck an item
> from the middle of any ThreadsML file or resource and put it in
> isolation, and find its parent/children from there? If so, then
> couldn't we say that whomever does the plucking needs to add the
> parent/children data to the isolated item?

Errm, sorry, don't worry about it - I'm just confusing things unnecessarily ;-)


> > Having the messages as class instances
> > and the arcs between them as properties will also make it
> > straightforward/transparent to extend the language e.g. A
> > childOf B ..later.. A agreesWith B.
>
> I need more RDF education to decipher this w.r.t how properties
> (vs. class instances) buy extensibility. Care to educate me here
> or point me somewhere?

Again, I'm just confusing things here. All I meant was that if we start with something like

A tml:childOf B

where A and B are resources (i.e. have URIs) then later it'll be possible to add other relationships on top like

A xyz:agreesWith B

The RDF Primer is probably the main reference - pretty long but pretty much covers everything.

Cheers,
Danny.
213
Steve YostPerson was signed in when posted
05-23-2003
03:05 PM ET (US)
Go, Marc!

... though compatibility isn't an operatic tale of subterfuge. (Not that you meant that -- just riffing on your theme.) It just makes cool stuff work :-)
Edited 05-23-2003 03:06 PM
212
Steve Yost
05-23-2003
02:59 PM ET (US)
> (in fairness, sure, we could change it, but making one from
> scratch with the proper schema behind it and suchlike is
> probably easier. Danny could probably give birth to some OWL
> without much discomfort or squawking, and do that and some
> proper documentation would be bliss. I'll document, whence the
> time comes.)

Sounds good. Want to take a shot at it? This is just for the threading 'overlay', agreed? Anyone else want to participate in creating (vs reviewing) the new module?

BTW, the OWL would be for anyone using the old module who wants a semantic mapping, right?

>
> Actually, this is a good idea if we want to make it RSS2.0
> compatible too.

Excellent.
211
Marc Canter
05-23-2003
01:59 PM ET (US)
When you join the Opera cult and take the red pill - you're required to take Italian, German and French - in that order.

Though Germond and 'La Toreador' is a required item in all baritones reptoire - I never made it to the third year of that torture ("tell us Mr. Canter - WHY do you insist on taking these COMPUTER courses (said in the most snobby tone you've ever heard) ....when you should be up to 3rd Mozart counterpoint by now?")

So needless to say - I don't speak French. "Ma Io Italiano no so bene" and "Und meine Deutsch ist nicht do gut"

But Carmen IS beautiful, and I would HOPE she is a bitch! How would you like it if all those dicks were trying to poke you all the time!
Anyway back to the issue at hand.........

......... supporting installed base aggregators is just a polticial move to get us in the game. Once we're there you simply say "if you want these advanced features - guess what?

You gotta move on up baby..........(don't get me started singing the "Good Times" theme song)

< replied-to message removed by QT >
210
Ben Hammersley
05-23-2003
01:57 PM ET (US)
On Friday, May 23, 2003, at 19:51 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> Perhaps. I'm just looking at this now, oddly enough. Proper
>> answers in the morning, but my initial reaction is that
>> simplicity is the key here. We can track both ways using
>> mod_threading and mod_annotate, but it's not clear. Maybe it
>> would be worth just creating another module that makes sense
>> when you read it:
>>
>> <thread:child rdf:resource=""/>
>>
>> <thread:parent rdf:resource=""/>
>>
>> <thread:child>
>> <rdf:seq>
>> <rdf:li rdf:resource=""/>
>> </rdf:seq>
>> </thread:child>
>
> Are there any implementors of the current mod_threading spec? If
> not, why not just modify it? How does this work?

As a member of the secret cabal that is the RSS-Dev working group, I can tell you that no one really knows. Yoohoo! Aaron? Are you awake out there?

(in fairness, sure, we could change it, but making one from scratch with the proper schema behind it and suchlike is probably easier. Danny could probably give birth to some OWL without much discomfort or squawking, and do that and some proper documentation would be bliss. I'll document, whence the time comes.)

Actually, this is a good idea if we want to make it RSS2.0 compatible too.
209
Steve Yost
05-23-2003
01:51 PM ET (US)
> Perhaps. I'm just looking at this now, oddly enough. Proper
> answers in the morning, but my initial reaction is that
> simplicity is the key here. We can track both ways using
> mod_threading and mod_annotate, but it's not clear. Maybe it
> would be worth just creating another module that makes sense
> when you read it:
>
> <thread:child rdf:resource=""/>
>
> <thread:parent rdf:resource=""/>
>
> <thread:child>
> <rdf:seq>
> <rdf:li rdf:resource=""/>
> </rdf:seq>
> </thread:child>

Are there any implementors of the current mod_threading spec? If not, why not just modify it? How does this work?
208
Ben Hammersley
05-23-2003
01:49 PM ET (US)
On Friday, May 23, 2003, at 18:57 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> Ben, while we have your attention, what do you think of the
> current proposed spec with regards to parent/child
> relationships?
>
> http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66
>
> In light of your concern over the purity of semantics (which I
> think is legitimate in the cause of the semantic web), I
> particularly wonder about the use of the annotation module to
> express child-to-parent relationships. The thing is, we want to
> be able to track both ways. Should we add another module?

Perhaps. I'm just looking at this now, oddly enough. Proper answers in the morning, but my initial reaction is that simplicity is the key here. We can track both ways using mod_threading and mod_annotate, but it's not clear. Maybe it would be worth just creating another module that makes sense when you read it:

<thread:child rdf:resource=""/>

<thread:parent rdf:resource=""/>

<thread:child>
<rdf:seq>
  <rdf:li rdf:resource=""/>
</rdf:seq>
</thread:child>


The whole range of agreesWith disagreesWith chidesAt isSarkyAbout stuff is great - but perhaps a second stage of implementation. ie it should supplement, and not replace the <thread:child> <thread:parent> elements.
207
Steve Yost
05-23-2003
01:48 PM ET (US)
Danny wrote:
> IMHO, definitely. I don't think the whole kitchen sink is needed
> (as in Thread Description Language [1]) but then I think it
> needs to be made clearer than the Annotation and Threading
> modules. (can always include owl:equivalentTo if needed!).

I'm not sure what you mean by clarity here. My concern is mostly that we're co-opting the Annotation module for something that wasn't its 'true' intention. Is that what you mean? The Threading module, I think, is clear enough in its semantics and usage.

>
> It needs to work both ways in such a way that the whole graph
> could be drawn starting at any given point (in theory at least),
> and ditto the timeline.

With the idea that a threading structure is an overlay on top of a linear timewise structure, we can say that child and parent items aren't necessary unless there are more than one child, or if the child or parent are contained elsewhere. This means that apps need to add the virtual parent-child relationship if it's not explicit, but it seems that any app that's reading ThreadsML is reading and building and internal sequence anyway.

Or do you mean to say that I should be able to pluck an item from the middle of any ThreadsML file or resource and put it in isolation, and find its parent/children from there? If so, then couldn't we say that whomever does the plucking needs to add the parent/children data to the isolated item?
> Having the messages as class instances
> and the arcs between them as properties will also make it
> straightforward/transparent to extend the language e.g. A
> childOf B ..later.. A agreesWith B.

I need more RDF education to decipher this w.r.t how properties (vs. class instances) buy extensibility. Care to educate me here or point me somewhere?
206
Ben Hammersley
05-23-2003
01:40 PM ET (US)
On Friday, May 23, 2003, at 19:28 Europe/Stockholm, QT - Marc Canter wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> I don't know - maybe something like 75% of all RSS channels.
>
> That's what we call "installed base" where I come from.
>
> I thought you showed how - using a similar technique to ENT -
> that we COULD do this with RSS 2.0. Fill in the void. Use the
> namespaces. I don't know call me crazy, but it just seems like
> heading out ONLY with a RDF/RSS1.0 implementation is
> gonna........
>
> Well let's just say - be non-diplomatic, leave behind a number
> of aggregator vendors and.........be decidedly
> non-standard-like.
>
> Speaking of knicker twisting........


That's fair enough for me. I mean, yes, it can be done with 2.0 - no question about that. It's just that it will be, almost by definition, not very useful for anything but parse-and-display. For
parse-and-display, 2.0 is the mackdaddy. It's simple to understand and throws through XML::Simple like a hot cat through butter. But for smooshing with other vocabularies, putting into rdf databases, doing advanced queries and all that funky stuff, it's not even in the game. But, anyway, Onwards!

In a total sidetrack, I've been listening to Carmen all afternoon, and it has come to my attention that the great heroine of French Opera is a bit of a bitch. I just wanted to share.
205
Marc Canter
05-23-2003
01:28 PM ET (US)
I don't know - maybe something like 75% of all RSS channels.

That's what we call "installed base" where I come from.

I thought you showed how - using a similar technique to ENT - that we COULD do this with RSS 2.0. Fill in the void. Use the namespaces. I don't know call me crazy, but it just seems like heading out ONLY with a RDF/RSS1.0 implementation is gonna........

Well let's just say - be non-diplomatic, leave behind a number of aggregator vendors and.........be decidedly non-standard-like.

Speaking of knicker twisting........

< replied-to message removed by QT >
204
Ben Hammersley
05-23-2003
01:24 PM ET (US)
On Friday, May 23, 2003, at 19:01 Europe/Stockholm, QT - Danny Ayers wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> ThreadsML should enable us to
>> only send the diffs - just as QT is working now.....
>
> Right, interesting point. I think this could relate to the
> skeleton vs. skeleton + content I muttered about earlier. A
> skeleton could contain the structure (list/tree/graph of item
> URIs) without the content. Serving the skeleton first at update
> time would make it easy to only deliver content diffs.
>
>> - scenarios that can be built with BOTH RSS 1.0 and RSS
>> 2.0
>
> I do have a personal preference here, but trying just to be
> pragmatic, the RSS 2.0 spec doesn't define *anything* about
> extensions, whereas RSS 1.0's extensions have to be defined in
> terms of the RDF model. It will be easier to go from
> tightly-specified to loosely specified, so the RSS 1.0 would be
> the appropriate starting point. Also, as Ben is pointing out, it
> slips in with existing generic RDF apps a dream.

Not wanting to start the whole argument up again in yet another mailing list, but is there a concrete reason for wanting to work with RSS 2.0? I'm not saying that in a fit of anti-Winer playa hatin', I'm asking because as Danny says, RSS 2.0 is really loose. You get neither the tight semantics, nor the generic RDF compatibility, and the only thing you gain, perhaps, is some simplicity. Simplicity, I have to say, which seems curiously useless, as no one will be handcoding this apart from me. For a bet. When I'm drunk.

It seems to me we're just duplicating effort (and not just with fitting threading into RSS, but also fitting a semantic basis into 2.0) for no real reason.
203
Danny Ayers
05-23-2003
01:16 PM ET (US)
> Ben, while we have your attention, what do you think of the
> current proposed spec with regards to parent/child
> relationships?
>
> http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66
>
> In light of your concern over the purity of semantics (which I
> think is legitimate in the cause of the semantic web), I
> particularly wonder about the use of the annotation module to
> express child-to-parent relationships. The thing is, we want to
> be able to track both ways. Should we add another module?

IMHO, definitely. I don't think the whole kitchen sink is needed (as in Thread Description Language [1]) but then I think it needs to be made clearer than the Annotation and Threading modules. (can always include owl:equivalentTo if needed!).

It needs to work both ways in such a way that the whole graph could be drawn starting at any given point (in theory at least), and ditto the timeline. Having the messages as class instances and the arcs between them as properties will also make it straightforward/transparent to extend the language e.g. A childOf B ..later.. A agreesWith B.

[1] http://www.eyrie.org/~zednenem/2002/web-threads/

Cheers,
Danny.
202
Danny Ayers
05-23-2003
01:01 PM ET (US)
ThreadsML should enable us to
> only send the diffs - just as QT is working now.....

Right, interesting point. I think this could relate to the skeleton vs. skeleton + content I muttered about earlier. A skeleton could contain the structure (list/tree/graph of item URIs) without the content. Serving the skeleton first at update time would make it easy to only deliver content diffs.

> - scenarios that can be built with BOTH RSS 1.0 and RSS
> 2.0

I do have a personal preference here, but trying just to be pragmatic, the RSS 2.0 spec doesn't define *anything* about extensions, whereas RSS 1.0's extensions have to be defined in terms of the RDF model. It will be easier to go from tightly-specified to loosely specified, so the RSS 1.0 would be the appropriate starting point. Also, as Ben is pointing out, it slips in with existing generic RDF apps a dream.

> - but before I go - may I make a request?
> - could folks go to the SSA Wiki and leave some
> BLOODEY
> endorsements for your standard of choice?
> - us marketing folks need support in the ant
> colony

Ooo-ooh! (1960's British comedy drama queen voice), don't get your knickers in a twist, I'll have a look when time permits dear...

Cheers,
Danny.
201
Steve YostPerson was signed in when posted
05-23-2003
12:57 PM ET (US)
Ben, while we have your attention, what do you think of the current proposed spec with regards to parent/child relationships?

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66

In light of your concern over the purity of semantics (which I think is legitimate in the cause of the semantic web), I particularly wonder about the use of the annotation module to express child-to-parent relationships. The thing is, we want to be able to track both ways. Should we add another module?
200
Steve YostPerson was signed in when posted
05-23-2003
12:50 PM ET (US)
Ben wrote:
> Our messages crossed - that's precisely what you do, yes.

I love it!


Marc wrote:
> - it seems to me that the entire content of a
> sub-thread needs to be in the RSS feed

Yes, I think we agree that it will be in the dc:content element, which won't be available to RSS aggregators *now*, but wouldn't it be cool if it were an option that if the dc:content data were there it could be displayed at the users' option. [It would be up to the RSS-reader app writers to do this.]

and Marc wrote:
> - take for example how Joi does his 'RSS comments'
> feed. I get an entire copy of ALL the comments and
> the source post -EVERY TIME another comment is
> left! ThreadsML should enable us to only send the
> diffs - just as QT is working now.....

I interpret this only as saying that ThreadsML captures each comment as a separate item. It's up to the apps that generate ThreadsML to do things like parsing reply-to emails to strip out the chaff as QuickTopic does.
Edited 05-23-2003 12:51 PM
199
Ben Hammersley
05-23-2003
11:55 AM ET (US)
On Friday, May 23, 2003, at 17:45 Europe/Stockholm, QT - Marc Canter wrote:

> - woe be it to us - to break any of the "installed" base
> of RDF
> - DC compliant apps. But don't get me started on this
> 'so-called' installed base of FOAF compliant apps and services.
> I mean "really" (said we a scorning British accent).......

You have to distinguish between FOAF or RSS specific apps, and the whole framework of RDF apps in total. FOAF, RSS1, ThreadsML,
MusicBrainz, whatever, are all just vocabularies - and the toolkits we can use to build apps to service specific vocabularies all depend on the conventions being the same. It's not so much breaking an installed base of apps, as breaking the installed base of toolkits and libraries.
Complying with the rest of ye olde semantic web, however, would be a big win. I mean, really! (sung to the tune of the Toreador Song)
198
Marc Canter
05-23-2003
11:45 AM ET (US)
OK - as long as the marketing departments requirements are met:
 - it seems to me that the entire content of a sub-thread needs
to be in the RSS feed

 - take for example how Joi does his 'RSS comments' feed. I get
an entire copy of ALL the comments and the source post -EVERY TIME another comment is left! ThreadsML should enable us to only send the diffs - just as QT is working now.....

 - scenarios that can be built with BOTH RSS 1.0 and RSS 2.0

 - there obviously will be BOTH creators and contributors - so we need to track them both

 - woe be it to us - to break any of the "installed" base of RDF
- DC compliant apps. But don't get me started on this 'so-called' installed base of FOAF compliant apps and services. I mean "really" (said we a scorning British accent).......
 
 - marketing dept sign-off

 - but before I go - may I make a request?
  - could folks go to the SSA Wiki and leave some BLOODEY
endorsements for your standard of choice?
  - us marketing folks need support in the ant colony

:-)
 

< replied-to message removed by QT >
197
Ben Hammersley
05-23-2003
11:34 AM ET (US)
On Friday, May 23, 2003, at 17:29 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> Danny, thanks for clearing that up.
>
> Also, I had a shower thought on dc:contributor vs dc:creator
> that works for everyone:
>
> For each post taken in itself, the author is the creator (of the
> post) so we use dc:creator for that (and thus retain RSS-reader
> compatibility). For the entire thread, there's the thread's
> creator and all the contributors, so within the <channel>
> elememt we include dc:creator and bag of
> dc:contributors.
>
> Does this sound good?

Our messages crossed - that's precisely what you do, yes.
196
Ben Hammersley
05-23-2003
11:31 AM ET (US)
On Friday, May 23, 2003, at 16:12 Europe/Stockholm, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
>> You want to support both. There's the originator of the
> thread
>> (creators) and those who add on (contributors.)
>>
>> :-)
>
> I don't know how to take the smiley, but I'll assume it's a
> serious suggestion. My point is that RSS aggregators -- a useful
> consumer of ThreadsML -- won't be able to display the poster's
> name if it's
> dc:contributor. And while the authors of the Dublin Core thought
> the distinction between creator and contributor was valuable
> enough to include it, I don't think the fine points of the
> semantics win over compatibility with existing apps in this
> case.
>
> This one of the trickiest parts of spec-making. More opinions?

I have to totally and completely disagree. Sacrificing the complete dublin core semantics for the benefit of the current crop of apps is distinctly short sighted. We'd seriously regret it in six month's time.
Plus, and this is a VERY KEY POINT :) we must not forget that the apps we're talking about are not just the current crop of Readers. The beauty of using RDF is the ability to feed it into other existing RDF applications and databases. Those apps and databases will not respect any adulterated form of the DC semantics, and so we'd be breaking a lot of functionality.

Anyway, creator and contributor are used in entirely different ways: in an RSS 1.0 feed representing a message thread (with each <item> being a new message) contributor would be used inside the <channel> section of the feed, with its values corresponding to the creator values of each <item>. I.e. Marc Canter is a Contributor to this conversation as a whole, but the creator of this small individual section. You use both. Does that make sense?
195
Steve Yost
05-23-2003
11:29 AM ET (US)
Danny, thanks for clearing that up.

Also, I had a shower thought on dc:contributor vs dc:creator that works for everyone:

For each post taken in itself, the author is the creator (of the post) so we use dc:creator for that (and thus retain RSS-reader compatibility). For the entire thread, there's the thread's creator and all the contributors, so within the <channel> elememt we include dc:creator and bag of
dc:contributors.

Does this sound good?

< replied-to message removed by QT >
194
Danny Ayers
05-23-2003
10:27 AM ET (US)
> which works nicely to show the whole message in an aggregator,
> and while that's cool in that it lets you use the aggregator as
> a full reader, I'd be concerned that not everyone would want
> that effect, or at least they'd want the choice.
>
> There aren't any extra capabilities in the content module, but
> its express purpose seems to be to hold the full content as
> opposed to a description or excerpt.
>
> If I'm wrong about these assumptions, though, let me know -- I'm
> no expert on current usage.

RSS 2.0 [1] defines <description> as "The item synopsis.", RSS 1.0 uses Dublin Core [2] which has "An account of the content of the resource."
Some folks do put the full content into description, but I think this is a really bad idea - it's one thing not using metadata, it's another to use metadata and mangle the semantics. Some of the vanilla XML lobby (e.g. Sam Ruby) have been talking about including full content in an <xhtml:body> in RSS 2.0, which complicates matters because its usage isn't actually defined anywhere, but at least that's better than misusing <description>. A few folk are strongly in favour of providing the full-content somewhere, e.g. Phil Ringnalda, a few folk, e.g. Bill Kearney, are worried that the additional network load of providing full-content 'naively' will be costly to content providers.

If you're writing an app that consumes RSS, then you probably have to take the worst-case into account, such as badly formed XML. But using data in way that operates best with the specs and doesn't encourage abuse means that we have at least a chance of getting data that can be used in apps more sophisticated than today's.

Cheers,
Danny.

[1] http://backend.userland.com/rss
[2] http://dublincore.org/documents/dces/
193
Marc Canter
05-23-2003
10:17 AM ET (US)
Ugh - yes I'm sorry I see you have a serious issue and I'm futzing around with smiley faces.

This fork in the road was coming.

We need to collect input from Ben, Matt, Paolo, Mark, Danny, David and others......

< replied-to message removed by QT >
192
Steve Yost
05-23-2003
10:12 AM ET (US)
> You want to support both. There's the originator of the thread
> (creators) and those who add on (contributors.)
>
> :-)

I don't know how to take the smiley, but I'll assume it's a serious suggestion. My point is that RSS aggregators -- a useful consumer of ThreadsML -- won't be able to display the poster's name if it's
dc:contributor. And while the authors of the Dublin Core thought the distinction between creator and contributor was valuable enough to include it, I don't think the fine points of the semantics win over compatibility with existing apps in this case.

This one of the trickiest parts of spec-making. More opinions?
191
Marc Canter
05-23-2003
09:52 AM ET (US)
You want to support both. There's the originator of the thread
(creators) and those who add on (contributors.)

:-)

< replied-to message removed by QT >
190
Marc Canter
05-23-2003
09:51 AM ET (US)
Perhaps Ben can shed some light on this. My get tells me Radio handles this differently.

< replied-to message removed by QT >
189
Steve Yost
05-23-2003
09:42 AM ET (US)
Mark wrote:
> And I understand (as
> March alluded to) it has become used by bloggers to embed the
> entire content of each post (in the <description> tag).
> ... Perhaps what I am missing is the
> "extra capabilities" that the content module provides -- what
> are examples of such capabilities?
>

I wasn't aware that blogging tools typically use the <description> tag to house the entire message. My default Movable Type 2.51 template for RSS1.0 shows this:

<description><$MTEntryExcerpt encode_html="1"$></description>

while your modified one has

<description><$MTCommentBody encode_xml="1"$></description>

which works nicely to show the whole message in an aggregator, and while that's cool in that it lets you use the aggregator as a full reader, I'd be concerned that not everyone would want that effect, or at least they'd want the choice.

There aren't any extra capabilities in the content module, but its express purpose seems to be to hold the full content as opposed to a description or excerpt.

If I'm wrong about these assumptions, though, let me know -- I'm no expert on current usage.
188
Steve Yost
05-23-2003
09:42 AM ET (US)
In looking at the MT template though, I want to reconsider my use of dc:contributor as the name of the author. Just for compatibility with RSS readers (given our recent reasoning on momentum) I think I should change it to dc:creator. Even though in a discussion the participants are really contributors more than creators, I think in this case compatibility might win over pure semantics. What do you think?
187
Marc Canter
05-23-2003
01:17 AM ET (US)
OK dudes

I've collected some juicy bits and two screen shots at:

http://www.quicktopic.com/cgi-bin/thwiki.pl?WebSiteCopy

Feel free to take this raw stuff, copy edit it, and turn it into some spiffy web site language. Now is the time for wordsmiths to do their thing.

Ben & David - this means you.

We need a site that says:
 - what ThreadsML is
 - it's status
 - our evolutionary approach
 - some use cases
 - what the evolutionary phases will be
 - and an FAQ

Seem reasonable?

- Marc
186
Mark Carey
05-22-2003
05:15 PM ET (US)
>ThreadsML's purpose is to allow saving or moving the >entire contents of a thread (and having the capability for >representing the branches that threads have, unlike plain >RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives >us compatibility with the RSS usages, and using a separate >content module lets readers/importers that support it add >extra capabilities.

That helps, but it doesn't fully answer my question. I understand that the original intent of RSS was to provide excerpts with links to "full stories". And I understand (as Marc alluded to) it has become used by bloggers to embed the entire content of each post (in the <description> tag). My question was/is: what extra benefit is derived from placing the entire message within a <content> tag (like the QT feed) versus placing the entire content within the description tag (as I have done)? With the message in the description tag, I can use existing aggregators to read entire threads, but I can't read data in the content tag. Perhaps what I am missing is the "extra capabilities" that the content module provides -- what are examples of such capabilities?

Thanks,

Mark
Edited 05-22-2003 05:34 PM
185
Marc Canter
05-22-2003
03:17 PM ET (US)
This is a perfect explanation of the ThreadsML logical strategy.
1. Leverage existing standards where possible
2. Get others to work on an a piece of an inter-locking puzzle
3. Focus on real-world examples
4. Enables LOTS of cool new stuff

So the issue of embedding ALL the content into the RSS feed may seem strange, but it's exactly that sort of un-anticipated usage of
technology - that Clay Shirky talks about - that separates the ants from the robots.

The analog inside of us - looks at what's available and we say
(collectively) "what's the shortest distance to get us from here to there?"

RSS (in whatever form) has always seemed to be to be the bext transport vehicle - because it's already being used - as an amazing standards for content syndication.

But why stop there?

Paolo and Matt haven't stopped? Ben hasn't stopped? Steve hasn't either.........

< replied-to message removed by QT >
184
Steve YostPerson was signed in when posted
05-22-2003
02:04 PM ET (US)
Mark, here's my take on this:

RSS1.0 was intended for syndication, where usually the end-user will be reading a list of headlines and brief descriptions and going to the orignal posting site to read the full content.

ThreadsML's purpose is to allow saving or moving the entire contents of a thread (and having the capability for representing the branches that threads have, unlike plain RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives us compatibility with the RSS usages, and using a separate content module lets readers/importers that support it add extra capabilities.

BTW, given the amount of "resources" available to work on proofs of concept, I'm really glad that we're building on RSS, since there are already interesting uses and lots of apps for that. It'll provide some necessary momentum.
183
Mark Carey
05-22-2003
11:40 AM ET (US)
>Technical summary:
>Use RSS 1.0 and require the standard Content module.

Okay, I have taken a quick look at this. I also subscribed to the feed for this thread with Newz Crawler -- the content data doesn't show -- couldn't find a preference to make it show.

Please excuse my ignorance, what is the benefit of using the content module and why is this "required" in the current proposal?

TIA for educating me,

Mark
182
Mark Carey
05-22-2003
11:25 AM ET (US)
>Nice! Are you putting the entire contents of each post in >the <description> element? It would be great if you could >use the content module
>(http://web.resource.org/rss/1.0/modules/content/) and put >your full text in there. That would be a step closer to >the current proposal for ThreadsML >>(http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66).

Yes, I am putting the entire contents into <description>. As I said, I am fairly new to these formats, so I just used the MT layout. I will take at the content module URL to learn more about that. I am using Newz Crawler 1.4, and when I learn more about the content module, I will comment on that ;-)
181
Steve Yost
05-22-2003
10:56 AM ET (US)
Mark Carey wrote:
> I have set up autodiscovery on my individual archive pages
> (these pages include all comments + the orginal post, so it
> seems the best basis for the "conversation" thread). Using a
> desktop aggregator, this works very well -- I can subscribe to
> threads that I want to monitor (I put them all in a
> "Conversations" folder).

Nice! Are you putting the entire contents of each post in the <description> element? It would be great if you could use the content module
(http://web.resource.org/rss/1.0/modules/content/) and put your full text in there. That would be a step closer to the current proposal for ThreadsML (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66).

What aggregator are you using? Is it something you can hack to display message content as a <content> element?

I've just updated QuickTopic's RSS1.0 output to use the content module as described at the above URI (did I miss this originally or has it changed?). Previously it was given as a bag of items -- this is less complicated. You can of course see this thread as close-to-ThreadsML (RSS1.0-compatible) by adding .rss to the end of a QT topic URI, e.g.:
http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss
180
Mark Carey
05-22-2003
09:44 AM ET (US)
Following up on my earlier message, I have created an MT template that produces an RSS 1.0 feed of a thread. It is based entirely on the default "RSS 1.0" template that comes with MT v2.63 -- I just used MT tags to change the content between the RSS tags, I didn't modify the RSS tags at all. I say "RSS 1.0" in quotes because I am still learning about these formats -- I don't know enough to say that the MT format is "valid" (Marc will tell me that this is why we need a validator ;-)

I have set up autodiscovery on my individual archive pages (these pages include all comments + the orginal post, so it seems the best basis for the "conversation" thread). Using a desktop aggregator, this works very well -- I can subscribe to threads that I want to monitor (I put them all in a "Conversations" folder). Aside: I often find that blog comment discussions are often left hanging. Someone posts a comment, the author might respond, but often times the comment-maker does not return to discover the response (it can be hard to remember and track all the blog comments you have made). Even the ability to subscribe to threads using a desktop aggregator has significant value.

Of course, the next step would be to aggregate such feeds into a forum-like web interface....

Here are some screen shots and links to what I have done so far.
179
Marc Canter
05-21-2003
06:34 PM ET (US)
Going once.....

Going twice.......

Oh well - I guess we'll have to do it ourselves.......

< replied-to message removed by QT >
178
Steve Yost
05-21-2003
06:03 PM ET (US)
Those pesky resources. Anybody with resources out there to levitate us from the Land of Theory?
177
Marc Canter
05-21-2003
05:30 PM ET (US)
HHhhhhmmmm - that would assume:
 - resources
 - we grok what ThreadsML is
 - resources

Did I forget to say "resources?"

:-)

< replied-to message removed by QT >
176
Steve Yost
05-21-2003
05:21 PM ET (US)
> We'll ready to hand the WebOutliner source to anybody who wants
> to use it - within a month. Then someone can EDIT a ThreadsML -
> in an abstract sense - and send it/route it - anywhere.

Cool. Will it import and export ThreadsML at the time of release? RSS1.0, RSS2.0, or both?

Shall I write an importer for QuickTopic?
175
Marc Canter
05-21-2003
05:08 PM ET (US)
We'll ready to hand the WebOutliner source to anybody who wants to use it - within a month. Then someone can EDIT a ThreadsML - in an abstract sense - and send it/route it - anywhere.

< replied-to message removed by QT >
174
Steve YostPerson was signed in when posted
05-21-2003
05:05 PM ET (US)
I like your graphic too, Marc, and I want to get there. I think we can show something useful before we have APIs, just in the form of import/export.

But enough talk -- let's freakin' do it! Who wants to export, who wants to import? Export is easy, so I can have that done quickly in QT, in RSS1.0 or RSS2.0. I'll write an importer too, if someone wants to export.

This isn't to say that the spec is done, but for myself, it'll give me a kick in the pants in helping define the spec if I have someone to work with. It's lonely all alone in my basement :-)
173
Marc Canter
05-21-2003
03:19 PM ET (US)
Well you're right. I apologize - I was being too optimistic.

Should I take off all other systems besides QuickTopic and one other topic guinea pig?

:-)

< replied-to message removed by QT >
172
Mark Carey
05-21-2003
01:39 PM ET (US)
No, I didn't miss it. It's a good graphic. In fact, its this graphic which lead to to make my point. The graphic is entitled "near term", but it also includes things like APIs, repositories, IM, Yahoo! Groups, and "tools". All great things, but my point was just that I think these should be part of a subsequent "release".

If indeed the current thinking is to first implement and deploy a very simple system (with real users), then I did miss that. :-)
171
Marc Canter
05-21-2003
11:38 AM ET (US)
Yup - I know you missed this, so I won't hold it against you:

http://broadbandmechanics.com/media/artwork/ThreadsML.jpg

:-)

That's 'kind' of what this chart says.....

Aggregator and Validator are needed day one........ and an outliner.
- Marc


< replied-to message removed by QT >
170
Mark Carey
05-21-2003
11:28 AM ET (US)
Marc writes:
>Cool dude - that's the "conversation aggregator" I >indicated someone should do.

Right. However, the point I was trying to make is more of strategic one. Rather than treating the aggregator as component is a larger system, why not treat it (first) as a short-term implemenation goal? If a simple system can be created quickly that will attract real users, it would many benefits:

-press/blog exposure - with a real system, more people become aware and talk about ThreadsML (both techies and non-techies)
- the above can also help attract technical talent and financing, etc.
-real user experience - this is the best way to understand the features and use-cases that are relevant to real people
-an established beta platform for testing versions of newer, more advanced versions of ThreadsML

>Are you saying you'll do it?
I don't think I have the expertise to "do it" :-) I am just starting to learn about some of these things. If anything, I might try to hack something together as a proof-of-concept (if, indeed, such proof is required), but it would be far from "production-quality"....
Edited 05-21-2003 11:29 AM
169
Marc Canter
05-21-2003
09:27 AM ET (US)
Roger wrote.....

> How does it make things better for me as a user to
> cut-n-paste-n-edit in a hypothetical nice tool? Why not just
> cut-n-paste to the destination and be done with it?

Danny replied.....

I should've been clearer - the nice tool could use a graphic
representation of the thread. A tree or gaph.

Marc wrote......

........you mean like a webOutliner - available for anyone to use - right now? :-)

==========================================
Roger wrote.....

> Right now, today, if for some unknown reason I wanted to expose
> an IM conversation to the world, I'd copy it into a message on a
> board. The board would spit it out as HTML, as RSS, a blog
> entry, and as email. Why do I need ThreadsML when I have what
> you're describing without it?

Danny replied.....

Would it identify the people involved in the conversation
separately? Perhaps automatically link to their FOAF profiles?
Enable the continuation of the conversation thread transparently
on the board?

Marc wrote.......

Enable folks to go back and insert further comments - at any stage of the conversation? Annotate any point (node) in the conversation with audio, photos or video? How 'bout link dynamically to several email accounts simultaneously? Or archive the whole thing to a shared
database - for ALL to access? Link the conversation into other
conversations (or just PORTIONS) of other conversations. The benefits are tremendous - we just need to get there!

Roger wrote.....

> But the rest just looks like a way to
> complicate existing processes with no payoff for the user.

Marc replies.....

Dude - if what we're saying here doesn't appear to be a benefit,
then,,,,,

,,,,,well what can we say. Sorry. But it's apparent to us all - that it does.




< replied-to message removed by QT >
168
Danny Ayers
05-21-2003
04:31 AM ET (US)
> Danny: "But that's looking at the situation from the current
> point of view, sans ThreadsML. The operations in that last
> sentence could be done neatly in a nice tool. Here's a scenario
> : IM interview with celebrity (you'll do, Marc ;-) captured with
> ThreadsML tool, fluff ridded with a few mouse-select-deletes,
> single button press publishes it to message board, RSS feed,
> blog or whatever."
>
> How does it make things better for me as a user to
> cut-n-paste-n-edit in a hypothetical nice tool? Why not just
> cut-n-paste to the destination and be done with it?

I should've been clearer - the nice tool could use a graphic representation of the thread. A tree or gaph.

> Right now, today, if for some unknown reason I wanted to expose
> an IM conversation to the world, I'd copy it into a message on a
> board. The board would spit it out as HTML, as RSS, a blog
> entry, and as email. Why do I need ThreadsML when I have what
> you're describing without it?

Would it identify the people involved in the conversation separately? Perhaps automatically link to their FOAF profiles? Enable the continuation of the conversation thread transparently on the board?

> I understand Steve's import/export and archiving goals. They
> make sense to me. But the rest just looks like a way to
> complicate existing processes with no payoff for the user.

What I suggested here doesn't complicate anything - it's just using the same kind of modelling for different purposes. Just because we can copy and paste IM text now, doesn't mean that with more sophisticated modelling (i.e. ThreadsML) we couldn't reuse the data in other ways.

Cheers,
Danny.
167
Roger Benningfield
05-21-2003
04:22 AM ET (US)
Marc: "This is all really obvious to me."

I'm rapidly coming to the conclusion that it isn't obvious to me because our world-views are incompatible. [grin]

For example, I ask how X helps make a user's life easier. Your response is that it won't, except maybe eventually, if a lot of other things happen. To you, playing with the possibilities inherent in X seems interesting. To me, that means I need to skip X and move to something that will actually put a smile on a real user's face.

All of which leads me to believe that about all I have to contribute here is stop-energy, and who needs that, right? My apologies for cluttering up the place. [grin]

--
Roger
166
Marc Canter
05-21-2003
02:59 AM ET (US)
This is all really obvious to me.

And I'm glad you asked this question:

"How does it make things better for me as a user to
cut-n-paste-n-edit in a hypothetical nice tool? Why not just
cut-n-paste to the destination and be done with it?"

=========================================

This is why I clearly delineated our roles as early adopters - through these crucial first two phases of this ThreadsML process. Tasks that may make no sense on the short term, are the only way we can iterate and let this standard evolve - in the right way.

What we as early adopters have to keep our eye on - is the prize. Sure Steve and David's early stage import/export requirements is a nice start, but it's only a start, not the destination!

By taking a rough, simple, early stage state of the spec - like what Steve Yost is developing - and connect that to another tool (Topica or phpBB or a Jabber client) we've got a situation where real conversations can take place!

And we know what happens when that takes place. NEW ideas and insights appear! By putting up with the inconvenience of cutting and pasting - for a while - I think we can come up with a BUNCH of killer features beyond import/export.

IMHO

- Marc



< replied-to message removed by QT >
165
Roger Benningfield
05-21-2003
02:39 AM ET (US)
Danny: "But that's looking at the situation from the current point of view, sans ThreadsML. The operations in that last sentence could be done neatly in a nice tool. Here's a scenario : IM interview with celebrity (you'll do, Marc ;-) captured with ThreadsML tool, fluff ridded with a few mouse-select-deletes, single button press publishes it to message board, RSS feed, blog or whatever."

How does it make things better for me as a user to cut-n-paste-n-edit in a hypothetical nice tool? Why not just cut-n-paste to the destination and be done with it?

Right now, today, if for some unknown reason I wanted to expose an IM conversation to the world, I'd copy it into a message on a board. The board would spit it out as HTML, as RSS, a blog entry, and as email. Why do I need ThreadsML when I have what you're describing without it?

I understand Steve's import/export and archiving goals. They make sense to me. But the rest just looks like a way to complicate existing processes with no payoff for the user.

--
Roger
164
Marc Canter
05-20-2003
09:38 PM ET (US)
Cool dude - that's the "conversation aggregator" I indicated someone should do.

Are you saying you'll do it? Work with Steve Yost on it?

Then we need someone to build a validator for ThreadsML. Any takers or are all of you just lurkers?

:-)

- Marc

< replied-to message removed by QT >
163
Mark Carey
05-20-2003
06:50 PM ET (US)
After I blogged about Blog Conversation Aggregation yesterday, Marc clued me in on ThreadsML. Thanks, Marc.

I have just read all 162 messages in this thread in one sitting (phew) -- a good example of why this type of conversation is better than email.

After reading all of this, it sure seems like there is lot of potential. One thing that I would like to see is a phased approach to ThreadsML. For example Version 1.0 could have very simple, linear thread syndication and aggregation, while versions 2 and 3 could start to get into more complex areas (tree-threading, topic categorization, etc.) My vision of a version 1.0 is similar to what I described in my blog. Here is a little elaboration:

Though I am new to Movable Type, It seems fairy easy to create and RSS template for my comments. It could probably be very similar to the "default" rss template that ships with MT. Just as blog feeds are aggregated, why not comments(conversations). When I envision an aggregation service, it appears just like a discussion forum: a list of threads with a subject and the number of messages. Clicking a thread would result in the retrieval and parsing of the RSS feed for display in a forum format. At that is need is a trackback-like system for pinging the aggregator for new threads and new comments. Note that this simple system doesn't need special "thread" tags, as each thread has its own feed, uniquely identified by its URI. This also does not addressed categorization -- this could eb done manually in v1.0, and improved by forum "moderators" who re-categorize threads.

Future versions could add many of the great features being discussed here, but it seems like my v1.0 is not far from reach. Am I wrong?

Regards,

Mark
162
Marc Canter
05-20-2003
02:33 PM ET (US)
YES!

< replied-to message removed by QT >
161
Jay FPerson was signed in when posted
05-20-2003
02:28 PM ET (US)
Relative to IM as a possible factor in ThreadsML, I recently started experimenting with IM to post to my blog (via blojsim, http://blojsim.sf.net ), and the success of this experience suggests to me that a "ThreadsML bot" could be invited to join IM chats and convert the chat into ThreadsML.

This would be sort of automated copy-and-paste from IM into a probably forum / message board format. I do think that the transient nature of IM conversations means that the messages need to be copied out of the IM streams and into some repository (that could either be in ThreadsML format or could be reference-able by ThreadsML).

Another similar method would be IM clients that log messages in ThreadsML format.
160
Steve YostPerson was signed in when posted
05-20-2003
02:00 PM ET (US)
Hey, thanks for the critical thinking *and* the visionary stuff. It pries me with a crowbar out of a pragmatist funk :-)
159
Marc Canter
05-20-2003
01:55 PM ET (US)
That's why this statement:

"If you've ever needed to move a threaded discussion from one site to another, you know why. More exciting, ThreadsML would let users move discussions from email to IM to a discussion board to chat, etc."
.....is on the web site.

That's what we're trying to do. It's a simple reduction of a lot of functionality that I think we can propagate - but for now - we need to be able to do something like that.

- Marc

< replied-to message removed by QT >
158
Marc Canter
05-20-2003
01:19 PM ET (US)
Steve wrote....

BTW, just as a nit, I'm not sure the IM-to-messageboard example is really all that compelling. If I really had the kind of IM conversation I wanted to capture and get more structured commentary on, I'd probably simply copy/paste it to a text editor, get rid of the fluff, then post it as part of an introductory message to a message board or email.
Going from email to a message board, from one board host to another (I may like one's features more), or archiving and intelligently
search-engine indexing, or RSS-like feeds all sound much more
interesting to me.

Then he wrote.....

Supporting both does add another dimension to the support-level-space, though: if you consider the import-only, import-and-export, roundtrip import/export levels I mentioned earlier to be one dimension, then RSS1.0/RSS 2.0 adds another dimension.

As a typical implementor, I'm willing to try both for my app, but I want to see if either is favored in actual implementations.

==============

In the time it took me to copy and paste these two separate replies into one post and now comment on it - is what I think we'll (as early
adopters/creators) have to put up with - to achieve a higher goal.
I imagine that ThreadsML can give birth to many new kinds of tools - which eventually - will do the cutting and pasting for us -
automatically. That means new kinds of email and IM clients and new kinds of mail/message servers will all need to be produced - intertwined with new kinds of aggregators and integrated user experiences (all ThreadsML compliant.)
 
I don't see any other scenario. We can continue to use old model tools and patch-quilt them - like QuickTopic or some Jabber client - but we'll always have to cut and paste somewhere to achieve this idealistic vision of interop conversations.

Once we've got a great handle on the capabilities of ThreadsML - THEN I think the new kinds of tools will start to appear. But we have to stop thinking about "does it make sense for me to use IM to start a
conversation or am I replying from an RSS feed?"

If I was a betting man - here's how it would work:

 - Phase I - spec implemented in existing tools
  - some level of cut & paste required
 - Phase II - prototype new tools created
  - work with those old tools
  - conversation germs still cut and pasted
  - but auto-conversations now possible (for the first
time!)
 - Phase III - critical mass of new kinds of tools available
  - auto-conversations can happen - entirely with new
tools
  - pressure builds on old tools to "upgrade"
 - Phase IV - nirvana
  - giant serpent comes to shelter us from the storm
  - repeat

Perhaps the Chandler effort will get us there quicker - but for now, suffice is to say that a format, spec, APIs and data structure FIRST need to be tried out. Tires kicked. Give it a ride around the block.
In this first phase of implementation - a validator will be needed to see if we're building these threads correctly. Example shared databases all driven by REAL content REAL conversations will also be needed. As you all know I will ALSO be pushing for including media in these new kinds of conversations.

So phase I needs some experiments, proof of concepts, basic interop - even if it needs a helping hand. Nothing wrong with us humans getting involved - once in a while.


< replied-to message removed by QT >
157
Chris Dent
05-20-2003
01:19 PM ET (US)
On 20 May 2003, QT - Roger Benningfield wrote:

> I can't imagine any scenario where I would willingly import an
> IM conversation into a message board environment. Unless your
> idea of a "message board" is extremely minimalist, inflicting
> the habits and rhythms of IM conversation on the users of a
> board would be something akin to communicative violence.

I have to agree with this, which makes me think there are some
divergent views over what a ThreadsML is for. I'm sorry if some
of the following is ignorant, I've only been following along for
a short while.

When I first heard of the ThreadML, I thought of them as memex
style trails for conversations. Data structures that point to
existing conversational pieces in multiple media, are used for
making reference, and do not themselves contain the content, only metadata. In essence they are simply a graph of URIs with a
little sugar to help it be usable. The graph is manipulated and
shared by various tools that understand it. The key, though, is
that data generation happens after the conversation--maybe just a few seconds, maybe years--as an either automatic or manual sort
of refactoring and what is created is something that is separate
and standalone.

Another vision that I've sort of seen on this list is that
ThreadsML is the management interface to participating in,
migrating and importing active threads through variuos media. In
this model the data generation is concurrent with the
conversation. This drives the need for things like APIs and/or
service attributes in the markup.

I imagine the former model to be more flexible and more
encouraging of unintended consequences. If threads represented in ThreadsML are pointer based and can effectively be exchanged, it
should be possible to go to an existing conversation, either
select parts of it or create a new addition, and then register
those parts with a Thread. If a Thread doesn't exist, you can
make one. If someone else likes it, they can add to it or copy it and do things with it.

Trackback style registration works a little like this now, except it doesn't yet have the tree like nature of a thread.

This model, though, doesn't quite sound like what's desired out
of ThreadsML, based on the web page: "If you've ever needed to
move a threaded discussion from one site to another, you know
why. More exciting, threadsML would let users move discussions
from email to IM to a discussion board to chat, etc."

--
Chris Dent <cdent@burningchrome.com> http://www.burningchrome.com/~cdent/ "It's music for people who believe in peace, freedom and equality, but don't want to confront its foes." -- The Filthy Critic
156
Danny Ayers
05-20-2003
12:57 PM ET (US)
> BTW, just as a nit, I'm not sure the IM-to-messageboard example
> is really all that compelling. If I really had the kind of IM
> conversation I wanted to capture and get more structured
> commentary on, I'd probably simply copy/paste it to a text
> editor, get rid of the fluff, then post it as part of an
> introductory message to a message board or email.

But that's looking at the situation from the current point of view, sans ThreadsML. The operations in that last sentence could be done neatly in a nice tool. Here's a scenario : IM interview with celebrity (you'll do, Marc ;-) captured with ThreadsML tool, fluff ridded with a few
mouse-select-deletes, single button press publishes it to message board, RSS feed, blog or whatever.

I expect there will be plenty of useful applications we haven't yet thought of - I've just thought of another - have you seen the Daily Chump, where you can post to a blog from IRC? There's effectively ongoing conversation with collaborative blogging in parallel. ThreadsML could be used to integrate the blog chat logs.

Cheers,
Danny.
155
Steve Yost
05-20-2003
11:26 AM ET (US)
I wrote:
> The scenario I've imagined is that I start a conversation in the
> medium that suits me best for the moment, then the conversation
> evolves into something else. A quick IM session might end up
> with lots of valuable information you want to share with a
> larger audience. So you move it to another place, and the
> participants move along with it (and, if the conversation is
> tactfully moved, presumably their rythms and habits adapt to the
> new medium). So the medium for the conversation can fit the
> *changing* dynamics of the conversation.

BTW, just as a nit, I'm not sure the IM-to-messageboard example is really all that compelling. If I really had the kind of IM conversation I wanted to capture and get more structured commentary on, I'd probably simply copy/paste it to a text editor, get rid of the fluff, then post it as part of an introductory message to a message board or email.

Going from email to a message board, from one board host to another (I may like one's features more), or archiving and intelligently search-engine indexing, or RSS-like feeds all sound much more interesting to me.
154
Marc Canter
05-20-2003
11:16 AM ET (US)
Gosh - this is not to say that AN ENTIRE IM session would want to be part of a message board, or sent as an email - but man oh man - I can certainly imagine situations where 'pieces' of a conversation (in whatever form they were created in) - should/would/could - be
sent/imported/exported elsewhere.

My experiences using this mail list and having it "mirrored" to QT proves that. With similar rules (type above the ----original
message------ line, tools to help convert these 'pieces' (select which sections you want imported/exported) and some nice UI to go along - with the right impetus and compunction - and I think it's possible.

By jove I think it's possible (I'm trying to make these messages more palatable for our British and Aussie friends........)

:-)

- Marc

< replied-to message removed by QT >
153
Steve Yost
05-20-2003
11:15 AM ET (US)
Roger wrote:

> Y'know, it's that kind of thing that leaves me feeling a bit
> skeptical about some aspects of ThreadsML. Mailing list threads
> do not equal message board threads do not equal IM
> conversations. They're all radically different beasts, enabling
> dramatically different *kinds* of conversations.
>
> I can't imagine any scenario where I would willingly import an
> IM conversation into a message board environment. Unless your
> idea of a "message board" is extremely minimalist, inflicting
> the habits and rhythms of IM conversation on the users of a
> board would be something akin to communicative violence.

The scenario I've imagined is that I start a conversation in the medium that suits me best for the moment, then the conversation evolves into something else. A quick IM session might end up with lots of valuable information you want to share with a larger audience. So you move it to another place, and the participants move along with it (and, if the conversation is tactfully moved, presumably their rythms and habits adapt to the new medium). So the medium for the conversation can fit the *changing* dynamics of the conversation.
152
Marc Canter
05-20-2003
11:12 AM ET (US)
MY lightbulb went off during Ben's session at ETCON - when he showed both RDF/RSS 1.0 and RSS 2.0 (using ENT) extensions. I think the message was clear there - that it's possible to implement ThreadsML - with EITHER approach.

Please correct me if I'm wrong - Ben or Steve?

- Marc

< replied-to message removed by QT >
151
Roger Benningfield
05-20-2003
10:49 AM ET (US)
Marc: "can create ThreadsML complaint threads - EQUALLY - with no implied prejudice or one-upmanship - because it was created in a message board or mail list, as opposed to an IM client or digital lifestyle aggregator."

Y'know, it's that kind of thing that leaves me feeling a bit skeptical about some aspects of ThreadsML. Mailing list threads do not equal message board threads do not equal IM conversations. They're all radically different beasts, enabling dramatically different *kinds* of conversations.

I can't imagine any scenario where I would willingly import an IM conversation into a message board environment. Unless your idea of a "message board" is extremely minimalist, inflicting the habits and rhythms of IM conversation on the users of a board would be something akin to communicative violence.
150
Danny Ayers
05-20-2003
04:14 AM ET (US)
Some random morning thoughts :

Perhaps the service description could just be supplied as a URI for each post :

service="http://blogger.com"

an app could then use XML-RPC or whatever as needed.

It's probably worth distinguishing between the original version of a post and those in thread clones :

origin="http://qt.com/2003-05-20/stuff"

It might be useful to allow two different representations of the thread : full (with content) and lite (? or skeleton?) with pointers to the individual post contents.

Although IMHO it would be easiest to use RDF/XML, I'm guessing this isn't likely to be the consensus. Whatever, I think it will be very useful to be able to define the language in RDF terms, i.e. providing a mapping to the RDF model, as this not only helps in making the spec unambiguous, it will also make interop a lot easier (e.g. being able to map to dc:creator for a post's author). ThreadsML is about describing resources, so the Resource Description Framework should at least be considered ;-)

Cheers,
Danny.


< replied-to message removed by QT >
149
Marc Canter
05-19-2003
07:18 PM ET (US)
Yes - anything at any time - is a good thing!

I still owe the group proper explanation/descriptive text for goals, use cases, etc.

Go for it!

- Marc

< replied-to message removed by QT >
148
Jay FPerson was signed in when posted
05-19-2003
07:14 PM ET (US)
Sorry to get too complicated in my last post--though I think it served to get across the point that ThreadsML needs to have a kind of clear philosophy about how it relates to these URI / API / protocol matters.

I would like to start doing some mockup markups of threads to try to illustrate how URI / API / protocol matters might be accounted for, or where they might be left out, or how they might be left out. I think it would be great if others joined in on this.

Has anyone done any mockup markup for ThreadsML yet, that I could build on?

Could we do these mockups on the ThreadsML wiki? (Can we enter XML tags in the wiki without it breaking, or should we escape them?)

Do you think it would be useful to do mockups now, or is this premature / not useful?
147
Marc Canter
05-19-2003
04:32 PM ET (US)
Good point

There should be some low- hanging fruit - easy to grok - "built-in" functions - which all apps should/would support.

I know that seems to contradict what we were just saying, but not that big of a deal. Is it?

< replied-to message removed by QT >
146
Danny Ayers
05-19-2003
04:27 PM ET (US)
> I just wanna know one thing - how come this post:
> (http://dannyayers.com/2003/05/19/qt-19-52.htm) is on a separate
> webpage?

Seemed a quick way of making the point...

> Do I hear "content aggregator" coming down the pike? Some new
> kind of cool new what-sa-ma-callit?

Nope, not this time.
But how would ThreadsML deal with every new kind of cool new
what-sa-ma-callit?
145
Marc Canter
05-19-2003
04:14 PM ET (US)
OK - cool

What products support it now and what are their APIs?

:-)

< replied-to message removed by QT >
144
Matt Mower
05-19-2003
03:50 PM ET (US)
Hi guys,

Okay. I'm not looking to prevent conversation about a ThreadsML API. I guess I'm just not interested in the API at this point, where I am interested in what the data will look like. When I hear talk of the API I just have visions of the ocean bubbling away.

BTW: Has anyone read Paolo's idea[1] for adding source GUID's to RSS feeds as an extension?

Regards,

Matt

[1] http://blogs.law.harvard.edu/crimson1/2003/05/17#a282
143
Steve YostPerson was signed in when posted
05-19-2003
03:02 PM ET (US)
Marc wrote:
> coordinate all those APIs - so everyone else can find them in one place - and support them accordingly.

I like that idea! How about doing that on the http://www.threadsml.org page right now?
142
Marc Canter
05-19-2003
02:36 PM ET (US)
Steve wrote.....

....but they'd need to write to each supported app's XML-RPC, SOAP, HTTP POST, or whatever API..

Marc replies....

I don't see anything wrong with that. A role of a ThreadsML alliance (notice a trend here?) might be to coordinate all those APIs - so everyone else can find them in one place - and support them accordingly.
< replied-to message removed by QT >
141
Marc Canter
05-19-2003
02:33 PM ET (US)
I just wanna know one thing - how come this post:
(http://dannyayers.com/2003/05/19/qt-19-52.htm) is on a separate
webpage?

Do I hear "content aggregator" coming down the pike? Some new kind of cool new what-sa-ma-callit?

What's up with this?

< replied-to message removed by QT >
140
Danny Ayers
05-19-2003
02:08 PM ET (US)
It's a bit carping/politically motivated, but Tim Bray posted a very handy little REST synopsis a few days ago:

http://tbray.org/ongoing/When/200x/2003/05/12/SoapAgain

little follow-up

http://tbray.org/ongoing/When/200x/2003/05/14/Technorati2




< replied-to message removed by QT >
139
Danny Ayers
05-19-2003
02:04 PM ET (US)
http://dannyayers.com/2003/05/19/qt-19-52.htm

< replied-to message removed by QT >
138
Steve YostPerson was signed in when posted
05-19-2003
01:57 PM ET (US)
Note to self: learn about REST:
http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html
http://internet.conveyor.com/RESTwiki/moin.cgi
137
Steve Yost
05-19-2003
01:44 PM ET (US)
Matt Mower wrote (among other things):
> It seemed to me that the idea of ThreadsML was to create an ML,
> i.e. a mark-up language.

From my perspective, this still holds, true, but I think we're seeing that many of the use cases beyond the original 2 use cases ("import/export" and "reading a multi-hosted thread through a single app or site") involve inter-app communication. I definitely agree that there's a lot of value in just nailing the markup language, and as far as I'm concerned there's nothing impeding us from doing that right now.

But I also think it's worthwhile discussing APIs, etc., especially because they're wrapped up with other interesting use cases.

So far I see several possible phases of spec and conformance.

With the ThreadsML data standard, apps can support:
1. Export-only
2. Export and Import, but not round-trip (i.e. import, export, re-import of the same thread)
3. Export/Import with round-trip.

[There's also import-only, with the attitude "I'll take your threads, but you can't take 'em back", but what user wants that?]

Even with just the data standard, and some RSS-like ways of getting ThreadsML content either through regular publication to fixed URIs, or dynamic updating to fixed URIs, people can write very interesting apps that could allow posting to threads from a single interface, but they'd need to write to each supported app's XML-RPC, SOAP, HTTP POST, or whatever API.
Beyond that, we can work towards a common API. But again I don't see any need to prevent conversation about that now.
136
Marc Canter
05-19-2003
01:33 PM ET (US)
I think having a ThreadsML data structure is important too - maybe it's just RSS - with some fancy something or other - but it's gotta be something that can be backed up, archived, searched, moved around - and we can't do that to lots of different things.

ThreadsML threads have to be in a ThreadsML format.

Correct?

That then goes along with a bunch of ThreadsML APIs - which (eventually) can get stored in a persistent repository and be discoverable.

Correct?

< replied-to message removed by QT >
135
Matt Mower
05-19-2003
01:21 PM ET (US)
Hi folks,

I admit I've been pretty busy so I've had to skim a bit here and there. Maybe I missed something important?

It seemed to me that the idea of ThreadsML was to create an ML, i.e. a mark-up language. A way of representing threaded communications that would permit interchange between all kinds of applications. Did I miss the announcement of that because I'm seeing a lot of conversation about API's now. I'd prefer to get the ThreadsML data right and worry about how to cart it around the internet later.

Once people have actually tried doing it for real, then we will begin to see what sort of shapes the API's will have to take. Anything else is putting the cart before the horse.

Maybe I'm off base, if so just tell me to shut up.

Regards,

Matt
134
Marc Canter
05-19-2003
01:08 PM ET (US)
OK - the marketing dept is gonna speak up again (this is of course without permission from other members of the marketing dept - but we're all just ants here anyway, so..............)

Obviously ThreadsML can't do everything itself.

The particular point that got us all going today is how many APIs get piled INTO the spec - versus a reference table - to point at a
particular set of APIs for each app.

I hate to play devil's advocate, but when I read what Danny said:
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.

I get nervous.

OF COURSE we want to be able to create new posts to a thread! I go to an existing conversation, I wanna add my 2 cents, I GOTTA be able to do that!

Now the issues are (I think):
 - which app do I use to do that with - well my business guy hat
on says "if the app is smart enough or supports the right features, than you can."
 - does that mean that the ThreadsML data carries around
something that enables an app to add a thread. I'd say no. It's the ThreadsML APIs - which are SUPPORTED by these new kind of apps - which enable adding new posts (again - maybe I'm just dumb - but there's nothing wrong asking dumb questions..........)
 - but what does that have to do with the ThreadsML data itself?
 - something in there HAS to be able to support a multi-vendor
universe - where all sorts of apps, tools, systems, etc. - can
contribute EQUALLY
 - can create ThreadsML complaint threads - EQUALLY - with no
implied prejudice or one-upmanship - because it was created in a message board or mail list, as opposed to an IM client or digital lifestyle aggregator.

Does that seem right?

< replied-to message removed by QT >
133
Steve YostPerson was signed in when posted
05-19-2003
08:52 AM ET (US)
I agree as well that it's better to keep it simple. But you knew that :-)

The issue of API discoverability is covered by other specs, as is authentication (something we haven't talked about much before in relation to APIs). I think they're separable from ThreadsML.

So maybe the imagined central app that lets me view all my 'feeds' needs app-specific API handling internally. I think that's a reasonable compromise that doesn't negate it as a valid use case.
132
Matt Mower
05-19-2003
06:35 AM ET (US)
> > >>>>> 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.
>

I agree with Danny. ThreadML is going to be complex enough without trying to encompass the multiple ways in which applications might accept new threads. Not to mention all the new ways we haven't thought of yet!
Cheers,

Matt
131
Danny Ayers
05-19-2003
05:37 AM ET (US)
> >>>>> 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
130
Marc Canter
05-18-2003
11:51 PM ET (US)
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
129
Jay FPerson was signed in when posted
05-18-2003
10:18 PM ET (US)
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.
128
Danny Ayers
05-16-2003
05:51 AM ET (US)
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 >
127
Steve Yost
05-15-2003
08:44 PM ET (US)
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 >
126
Jay FPerson was signed in when posted
05-15-2003
06:53 PM ET (US)
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.
125
Steve Yost
05-10-2003
10:50 PM ET (US)
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!).
124
Marc CanterPerson was signed in when posted
05-10-2003
08:41 PM ET (US)
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.......
123
Steve YostPerson was signed in when posted
05-09-2003
02:20 PM ET (US)
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.
122
Jay FPerson was signed in when posted
05-09-2003
01:09 PM ET (US)
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.
121
Steve Yost
05-09-2003
09:20 AM ET (US)
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?
120
Danny Ayers
05-09-2003
06:17 AM ET (US)
> 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.
119
Jay FPerson was signed in when posted
05-09-2003
02:33 AM ET (US)
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)?
118
Jay FPerson was signed in when posted
05-09-2003
02:03 AM ET (US)
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.
117
Peter Kaminski
05-08-2003
11:43 PM ET (US)
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
116
Steve Yost
05-08-2003
11:21 PM ET (US)
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.
115
Jay FPerson was signed in when posted
05-08-2003
09:50 PM ET (US)
I don't know if this is covered already in everyone's consideration: but I think it would be good if each single post/comment in a thread could be represented "on its own" in ThreadsML.

The use case I am thinking of is the need to extract only one post (at a time) from an entire thread, possibly with some header info about the entire thread.

Maybe this needs to be a separate, but related, volucabulary -- ThreadsExtractsML (or TEML)? ;-)

A service that could make use of ThreadsML online could, for example, reference a post via a permalink that returns a single post marked-up in ThreadsML.

BTW, on my blog, I am doing permalinks for each entry's RSS versions besides doing a RSS feed of recent posts. For mechanisms that do aggregation based on things other than most recent posts, isn't it necessary to be able to consistently address each item? I can address each HTML post on QuickTopics in this way (like /m115).

Also, don't know if this is of interest, but I am posting more about the iCite net now, including a description today on iCites and online discussions at http://icite.net/blog/example/?permalink=online_discussion.html
Edited 05-08-2003 09:50 PM
114
Ben Hammersley
05-08-2003
04:24 PM ET (US)
Aye, Cap'n


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

>
< replied-to message removed by QT >
113
Marc Canter
05-08-2003
02:11 PM ET (US)
Anyone wanna participate in fleshing out the site - besides me and the good Doctor?

- Marc

>
< replied-to message removed by QT >
112
Steve Yost
05-08-2003
01:20 PM ET (US)
> I've posted a draft of a threadsml page at
My only comment for now is thanks very much for setting this up, David!
111
David WeinbergerPerson was signed in when posted
05-08-2003
12:24 PM ET (US)
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...
110
Marc Canter
05-08-2003
10:04 AM ET (US)
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.........]
109
Marc Canter
05-08-2003
09:42 AM ET (US)
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 >
108
Steve Yost
05-08-2003
09:07 AM ET (US)
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.
107
Ben Hammersley
05-08-2003
04:40 AM ET (US)
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 >
106
Marc Canter
05-07-2003
05:13 PM ET (US)
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>
Edited 05-08-2003 12:53 AM
105
Steve Yost
05-07-2003
03:26 PM ET (US)
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.
104
Steve Yost
05-07-2003
02:38 PM ET (US)
> 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.
103
Danny Ayers
05-07-2003
02:31 PM ET (US)
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 >
102
Danny Ayers
05-07-2003
02:29 PM ET (US)
> > > 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.
101
Steve YostPerson was signed in when posted
05-07-2003
02:01 PM ET (US)
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
100
Steve Yost
05-07-2003
01:49 PM ET (US)
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.
99
Ben Hammersley
05-07-2003
01:48 PM ET (US)
yeah, pretty much

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

>
< replied-to message removed by QT >
98
Steve Yost
05-07-2003
01:41 PM ET (US)
> > > "and contribute to ... in the application of my choice"
> > > -requires more than a data standard. Needs a common
> > > protocol for posting messages.
> >
Ben wrote:
> > 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?
97
Steve Yost
05-07-2003
01:19 PM ET (US)
Peter wrote in /m90:
> I'd also like to make sure the data standard is recursive; i.e.,
> the thread atoms can be either messages or the head of another
> thread (to allow for forked threads, or things like comments to
> blog posts).

Would you allow that this can be accomplished with parent and child references within each (or any) message? 'Comments to blog posts' hints at recursion more than forked threads, but could those comments be considered simply a fork from this perspective? Hmm, in one imagined application -- rendering a weblog through a different UI -- you'd want to distinguish the comments from the blog entries. But from the conversation perspective, it's all one. Hmmmm.
96
Shelley (Burningbird) P
05-07-2003
01:14 PM ET (US)
But again, this is all data, you're just extended the search paramaters. Geography, member of FOAF file, whatever

Whatever
95
Ben Hammersley
05-07-2003
01:11 PM ET (US)
On Wednesday, May 7, 2003, at 07:06 PM, QT - Shelley (Burningbird) P wrote:

>
> Also, on the search, by compound search, Ben, I'm assuming you
> mean and'd or or'd keywords.
>

more than that. I'm talking about "find me a message containing keyword 'xxx' where the creator is within three degrees of my social circle, lives in Europe, has a blog that has been updated within the past week, and is online via AIM right now."
94
Shelley (Burningbird) P
05-07-2003
01:06 PM ET (US)
Actually, one of the main reasons I brought up trackback was to demonstrate the problems and confusion the non-tech people had with this implementation, and how you're facing as much of a challenge with your stuff. But, such is life.

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.

Are you talking about thread identifiers, or are you talking complete messages? Any discussion about what happens to edited messages in one copy of the thread compared to another?

Also, on the search, by compound search, Ben, I'm assuming you mean and'd or or'd keywords.

We talked this before, but have you all decided what your test prototype of this specification is going to be? I'm assuming QuickTopic as one, but any idea of what the second application will be?
93
Ben Hammersley
05-07-2003
01:04 PM ET (US)
On Wednesday, May 7, 2003, at 06:49 PM, QT - Steve Yost wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> Ben wrote:
>> an API to the centralised app would be sufficient
>
> Can you elaborate on your idea of "the centralized app" and how
> it relates to the thread content (which resides where in this
> scenario?)?

Sure - I mean something like Quicktopics or YahooGroups. Now, the common protocol for posting messages to these can be ordinary email, but there are also web-based forms. I can see where an API would be good too.


>> search engine could the a central repository itself.
>
> If you mean 'could be the central repository' then you're
> referring to something like Google's cache or the terabyte
> host(s) mentioned previously, right?

Yes. For something like a shiny RDF search engine (of which more later), having the central app ping it with RDF snippets representing each new message as it comes in would have advantages.
92
Danny Ayers
05-07-2003
12:59 PM ET (US)
> > I want to delineate those three things:
> >
> > "archiving, as per David's problem"
> > -acheived by a data standard alone
>
> Indeed so.

Yup.

> > "UI choice, in that I want to be able to
> > read...in the application of my choice"
> > -assumes a model like that used by RSS, where
> > supporting services periodically publish updates
>
> or produce the file dynamically, but yes.

Yup.

> > "and contribute to ... in the application of my choice"
> > -requires more than a data standard. Needs a common
> > protocol for posting messages.
>
> an API to the centralised app would be sufficient

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.

> > "firm ample bosom of metadata to facilitate
> > compound searching"
> > -requires the tight buns of in-situ persistence or
> > copying to a central repository
>
> yes, though of course the pert and supple search engine could
> the a central repository itself.

I think an approach of "don't throw anything away unless you have to" to metadata could probably capture the best of both worlds.

...engines...mmm...

> > Correct?
> >
>
> by jingo, I think he's got it...

Woo-hoo...

Cheers,
Danny.

> _________________________________________________________________
> QT Forum: http://www.quicktopic.com/em/H/mXbfHC2srY3/m89
> Unsubscribe: http://www.quicktopic.com/em/X/mXbfHC2srY3
> Current email group: aaron@theinfo.org, aversa@unsl.edu.ar,
> ben@benhammersley.com, cjustice@vignette.com,
> danny666@virgilio.it, info@icite.net, jamesd@socialchange.net.au,
> jamie@fentonia.com, jito@neoteny.com, jonl@polycot.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,
> rcaccappolo@mail.ivillage.com, rossmay@earthlink.net,
> self@evident.com, shelleyp@burningbird.net, steve.cayzer@hp.com,
> steve@quicktopic.com
> Start your own topic in 20 seconds: http://www.quicktopic.com |QT
91
Steve YostPerson was signed in when posted
05-07-2003
12:49 PM ET (US)
Ben wrote:
> an API to the centralised app would be sufficient

Can you elaborate on your idea of "the centralized app" and how it relates to the thread content (which resides where in this scenario?)?

> search engine could the a central repository itself.

If you mean 'could be the central repository' then you're referring to something like Google's cache or the terabyte host(s) mentioned previously, right?
90
Peter Kaminski
05-07-2003
12:44 PM ET (US)
Yes. I'd like to see something that encapsulates the full contents of a thread, supporting the Import/Export use case. It should also be able to encapsulate and copy a distributed threaded comprised of Trackback entries.
I'd also like to make sure the data standard is recursive; i.e., the thread atoms can be either messages or the head of another thread (to allow for forked threads, or things like comments to blog posts).

Pete
89
Ben Hammersley
05-07-2003
12:34 PM ET (US)
On Wednesday, May 7, 2003, at 06:19 PM, QT - Steve Yost wrote:
> Thanks, Ben (and waiting for more).
>
> I want to delineate those three things:
>
> "archiving, as per David's problem"
> -acheived by a data standard alone

Indeed so.

> "UI choice, in that I want to be able to
> read...in the application of my choice"
> -assumes a model like that used by RSS, where
> supporting services periodically publish updates

or produce the file dynamically, but yes.

> "and contribute to ... in the application of my choice"
> -requires more than a data standard. Needs a common
> protocol for posting messages.

an API to the centralised app would be sufficient

> "firm ample bosom of metadata to facilitate
> compound searching"
> -requires the tight buns of in-situ persistence or
> copying to a central repository

yes, though of course the pert and supple search engine could the a central repository itself.

> Correct?
>

by jingo, I think he's got it...
88
Steve YostPerson was signed in when posted
05-07-2003
12:19 PM ET (US)
Thanks, Ben (and waiting for more).

I want to delineate those three things:

 "archiving, as per David's problem"
 -acheived by a data standard alone

 "UI choice, in that I want to be able to
  read...in the application of my choice"
 -assumes a model like that used by RSS, where
  supporting services periodically publish updates

 "and contribute to ... in the application of my choice"
 -requires more than a data standard. Needs a common
  protocol for posting messages.

 "firm ample bosom of metadata to facilitate
  compound searching"
 -requires the tight buns of in-situ persistence or
  copying to a central repository

Correct?
87
Ben Hammersley
05-07-2003
12:05 PM ET (US)
Absolutely, unreservedly, yes.

My goal is Total Thread Portability - supporting three things:
archiving, as per David's problem, UI choice, in that I want to be able to read and contribute to threads in the application of my own choice, and finally, a firm ample bosom of metadata to facilitate compound searching (find me X that has Y of Z, A of B, C of D and E of F).
The Portability aspect of this need not make it a decentralized
application, just that should we want to move the centre, we can.
On Wednesday, May 7, 2003, at 05:55 PM, QT - Steve Yost wrote:
>
<snippapoolza/>

> Everyone: Do we have agreement that we need at least the data
> standard that encompasses the full contents of a thread,
> supporting the Import/Export use case?
>
86
Steve YostPerson was signed in when posted
05-07-2003
11:55 AM ET (US)
Shelley, thanks for getting me to finally read enough about TrackBack to understand it. Again, to its credit, I could grasp it in 10 minutes or so. Things like the MT trackback-enabled bookmarklet can help it catch on by reducing the number of user steps.

The distributed, peer-to-peer in-situ nature of conversation threading using TrackBack prompts me to review ThreadsML's history through use cases:

The original use cases for ThreadsML (being original doesn't make them more important, but they are important to me) are centered around Import and Export of a thread (http://www.quicktopic.com/cgi-bin/thwiki.pl?ExportAndImportThread), firstly to support David's Complaint (lost uni-hosted conversations: http://www.hyperorg.com/backissues/joho-jun17-01.html#threads) and secondly to allow upgrading a conversation from one format (e.g. email, if an email client supported it) to another (e.g. a WebCrossing bulletin board or a QuickTopic or a Groove discussion). They involved saving or moving a thread wholesale from a single location to another, and presumably the participants follow [assuming the thread is still active]. In these cases a data standard that describes a full thread is sufficient.

The next logical set of use cases considered what happens next. The thread continues to evolve. Can it continue in two places? (Yes, we say, without thinking too much about cases where it would.) When it does, can it be pieced together by superposing the two (or N) instances of the thread? Yes: http://www.quicktopic.com/cgi-bin/thwiki.pl?SearchEngineUseCases (2nd bullet).

The Search Engine case is also just one way of addressing the discovery issue first raised by Shelley in /m33. It also assumes persistence in-situ (neglecting Google-wise caching).

TrackBack as an example of threading deals with each *message* as a (potentially) separately hosted entity, forming a whole-thread entity that is fragile in terms of persistence. It's about *weaving* a thread from distributed messages. (Thanks again to Shelley for honing in on persistence in /m44. ) As such, it doesn't address the original use cases. But in fact the ThreadsML data standard could be the format used to copy [and persist] distributed threads formed by TrackBack entries.

Everyone: Do we have agreement that we need at least the data standard that encompasses the full contents of a thread, supporting the Import/Export use case?

Items in green added in edit
Edited 05-07-2003 12:01 PM
85
Shelley (Burningbird) P
05-07-2003
07:01 AM ET (US)
I also want to point out Blogmatrix, at http://www.blogmatrix.com/. Another company providing yet another set of the same type of functionality to the blogging community.

They track threads, but they're not using trackback -- so now we have the ping for trackback and this blogthread thing (check out my separated by birth twin brother's site at http://emptybottle.org/ to see what I mean).

And this is just within the weblogging medium -- start adding in threads for QuickTopic, and Yahoo, and email, and weblogs, and .... the techies are going to tweak once too much, and you're going to see massive pushback on the part of the non-tech community.

Less Tweaking. More talking. That's what Blogging Unlimited was for, and my own RDF experiment with poetry -- right now, people in my comments are defining my next move, because I shut up, and am encouraging them to talk.

Sorry, but this whole site, blogmatrix, is bringing the worst out in me at the moment.
84
Shelley (Burningbird) P
05-07-2003
06:44 AM ET (US)
Have been heads down in poetry. Catching up:

Re /m74 and parent/child threads in Movable Type: Yes this is fully implemented in Trackback, not just MT. Even the stand alone TBs have this capability.

The power of TB was the ability to ping the parent when a new child is added, without the parent having to do anything. Other functionality then allows us to 'backtrack' -- make a call on someone else's TB server to get a list of the trackbacks for a specific item, including our own. Sam Ruby took this and basically follows the tree, up or down. Piece of cake, using standard technology.

Best of all, this is a pure distributed solution, which can be centralized at any of the nodes in the thread -- another feature in TB allows one to basically serialize any thread at any point. Hardly anyone uses this though - most people are satisfied with immediate trackback, or backtrack -- immediate parent or children.

Re /m75, a centralized repository has always been an issue in this. But you know, you don't have to maintain all nodes on the thread, just the topmost node (if you trust the persistence of each node). If each node then maintains its own trackbacked entries (the children, so to speak, though I think children is the wrong term), you can do as I and Sam do -- walk the line.

Re /m76 -- all one ever needs in a threaded system is three things: the ability to be pinged by new children (trackback), the ability to get the children information (which we're using for both backtrack and listing the children out at a parent), and the ability to find the top node. We can do this by discovering any node in the thread and following it up, but only if the functionality exists that says, "here is the parent node(s) referenced in this material".

The technology is dead simple -- it's discovery and persistence that's the problem. You take one of the nodes down, that's all she wrote.

re /m77 -- yes, saw your move. You know, my mama would say that was rude (she says with a smile). I have to push back a bit on ThreadsML, primarily because it's ignoring some of the implementations that already exists. Such as Trackback. Rather than focus your threading effort on a specification -- which will push away the non-techs, and you don't want that -- focus it on the end results. Threads. Or specifically, persistent threaded communications.

Again, and no offense to Steve here, you're focusing on a specific implementation when you reference Quick Topic.

Need to move this up a level, and get the non-techies involved. Not just as 'marketing dweebs (Hi David)'. Put this all into a context of overall accomplishments, and then show the Quick Topic ThreadsML thing as a prototype -- don't focus on Quick Topic, ThreadsML and then build a user requirement around it.

You all saw what happened with Trackback -- people love it, but they don't understand it, and because of this, it's not being utilitized fully. Can't just shove a confusing blur of technologies at folks. Gradually, bring them in. Lure them in. "Here nice user, user, user. I have a new treat for you."

re /m78 -- yup, me and Sam are the only know backtrack implementors. Not sure why because its very popular at my site.

Regarding ping at central location. Ah, you know how slow these pings are? How much they're timing out? What happens when you time out? How do you incorporate an additional ping to a centralized authority? And, well, you know me -- all them pitfalls.

First, create the thread (done with trackback).
Next, persist all nodes.
Finally, discovery of top most thread would be a great next move.


re /m80 -- I think you caught it right, Marc -- you tried to force a change of venue, away from something people are comfortable using. Can't force people to buy into technology. Trackback was a perfect example in how to roll out, and not roll out, new social software.

re /m82, Steve I think you're making this more complicated then it need be. Again, time to take a look at the implementation of Trackback. How do you know a thread has reached a termination point? When no trackbacks are attached to it. Any node can be described this way, and this isn't a trackback concept -- universal.

You know, Trackback is a lesson, which you all should be looking at. The only problem with it now is that people are still intimidated by it (something to keep in mind), and if one node disappears, the thread is lost.
Edited 05-07-2003 06:51 AM
83
Steve Yost
05-06-2003
11:59 AM ET (US)
>
> Confusing - you mean like trying to transition a group of 20
> people who are used to using their own tools and environments -
> to someplace completely new?

Yes, though it need not sound as radical as that. In this case, it was simply a matter of what happens when people hit the reply button in email. Another experience I had years ago: we tried to use NNTP-based discussion groups at work for design discussions, because they had the advantage of keeping conversations in one place and letting people subscribe/unsubscribe according to their interest. It failed because there was *one* engineer out of 20 who didn't want to use it -- he didn't want to have to look anywhere besides his email. Because his participation was important, we stuck to email.

>
> I'm convinced the REAL challenge in all this work - are the
> socio issues, not technical. We're all smart people - but it's
> the snake oil that has to look like ice cream that's the
> challenge.

Darn right. Or following the above line, that new snake oil has to be available at the ice cream store where people already go. (whew, stretching that metaphor thin)
82
Steve Yost
05-06-2003
11:50 AM ET (US)
Good to have you back, Ben!

Ben wrote:
>
> Regarding Parent and Child, I'm trying to be really careful here
> - Parent is cleancut and immediately do-able. Child is
> different,
> however, because it suggests a mechanism for telling the Parent
> that the child exists. In other words, a Child cannot be
> created without the creator having knowledge of the Parent -
> knowledge that can be passed on with the Child - but a Parent
> is fundamentally unchanged by the creation of the Child.
> ...

In one thought experiment, the model is the following:

>>>>
Threads can be copied from one place to another.

Threads have a recognized origination point or system or host, where it's likely that the thread will continue to evolve* (do we use this knowledge for anything beyond this advisory fact?)

A copied thread can also continue to evolve at its copied-to location (if the host supports it).

There's usefulness in an overseeing application that spans all the homes of a set of threads, enabling users to read and traverse the thread regardless of its home. The app can do this by copying the thread repeatedly or by relying on its in-situ presence. It can get refreshed by spidering or by explicit pings.

[*unless someone declares it dead. Maybe we should have a terminated-thread indicator, which would apply only to the host where it resided]
>>>>

The overseeing app is what could know about both parents and children (there could be many of these over-apps).

It's maybe useful to compare this with Usenet. Usenet (and I'm no expert) is sort of peer-to-peer among servers, i.e. when you make a post, it gets posted to the server you're connected to first, then that gets copied elsewhere to peer servers (more here:
http://www.smr-usenet.com/tech/how.shtml).

The proposed model above is in contrast to Usenet, i.e. there's no *responsibility* for distributing threads around, but the uberapps certainly add value. Without them, ThreadsML still provides the ability to save a thread with the assurance that it can be moved to another host or medium (David W's original motivation for ThreadsML when his CoolBoard service went away), and to move a thread wholesale from email (if email clients support it) to QuickTopic to Topica to WebCrossing (noting the social difficulty of moving the people along with it).

What do you think?
81
Marc Canter
05-06-2003
11:25 AM ET (US)
When weaving the quilt of life, it makes sense to try a few things out first - before assuming that all our brilliant ideas - are actually half as smart as we think they are.

That's my Threads metaphor for the day......

>
< replied-to message removed by QT >
80
Marc Canter
05-06-2003
11:22 AM ET (US)
Confusing - you mean like trying to transition a group of 20 people who are used to using their own tools and environments - to someplace completely new?

I'm convinced the REAL challenge in all this work - are the socio issues, not technical. We're all smart people - but it's the snake oil that has to look like ice cream that's the challenge.

:-)

>
< replied-to message removed by QT >
79
Steve Yost
05-06-2003
11:15 AM ET (US)
Marc, you dawg. You're a genius at getting someone's attention when they should be coding :-)

> As part of that effort, I attempted to get to know Steve Yost's
> new QT features yesterday - casting myself as the guinea pig.
> Being a real-time use case is always handy for actually
> understanding what the hell it is that humans wanna do.
>
> Needless to say it was ugly. I tried to move a Yahoo Group
> thread to QT - without asking or telling anyone. Replys qucikly
> came in (which I am still waiting to reply to - thanks ShellY) -

There were two aspects: 1., I think you wanted to move the specific topic *out of* Yahoo groups, and 2., you CCed 40 others in the email -- a sort of email tributary to the Yahoo Groups flow. The first part socially didn't work because people who are at Yahoo Groups get their email from YG and naturally reply to that.

The second part, where we moved the 40 CCed email participants transparently to a sort of instant QuickTopic mailing list (like we've done here -- I'm calling it QuickThread, BTW), worked technically, but we don't have a reading on the social aspect -- nobody replied either through QT or regular email.

In any case, it *is* a good case study of the important social/technical aspect of social software: it's very difficult to move a live conversation (the interacting people, not the content) from one place to another, and that's very applicable here to guide our use cases.

>
> Anyway - I digress.......
>
> So here's a logistical - move forward roadmap:
> ...

Sounds great to me!

Steve
78
Danny Ayers
05-06-2003
10:58 AM ET (US)
Indeed you do make sense. Sometime while you were galavanting I suggested that thread preservation might be possible using something like trackback, but when an item is added to a thread the linkage gets recorded at *both* ends.

Shelley pointed out that someone (?) had already cracked backtrack (?) in MT.

A server could be pinged at the same time, to provide Marc's archive. But it does get a bit more confusing if you want to push the records further up/down the tree though... maybe time to get the felt-tipped pens out...
77
Marc Canter
05-06-2003
10:55 AM ET (US)
You make smashingly good sense sir. In fact so much good sense that I will take your return - as a milestone to try and turn this ad hoc collection into something "meaningful"

I have spent some time, since returning from ETCON - understanding the issues, politics and logistics of getting ThreadsML to work.

As part of that effort, I attempted to get to know Steve Yost's new QT features yesterday - casting myself as the guinea pig. Being a real-time use case is always handy for actually understanding what the hell it is that humans wanna do.

Needless to say it was ugly. I tried to move a Yahoo Group thread to QT - without asking or telling anyone. Replys qucikly came in (which I am still waiting to reply to - thanks ShellY) - but it quickly became apparent why the good Dr. Weinberger is hesitant to just abruptly move a conversation to a different system - ad hoc. (Or maybe that's a ad hominem? My Latin is limited to operatic terms, so..........and ordering Iatlian food.....or flirting with Italian hottie....)

Anyway - I digress.......

So here's a logistical - move forward roadmap:

- Dr. Weinberger and myself cast ourselves into the role of marketing dweebs and we build a site which we can point people to.

- this site describes the goals of ThreadsML and points to topics, threads, specs, examples, Wiki, etc.

- we (colectively) then target a second tool - which we get to work with Steve Yost - to interconnect QuickTopic to

- perhaps we can also connect these two working commercial tools with exeprimental code - coming out of the RDF world

- then we make sure a REAL spec - encompasing both short term implementationa and long time goals - evolves

Make sense?
76
Ben Hammersley
05-06-2003
10:44 AM ET (US)
On Monday, May 5, 2003, at 09:50 PM, QT - Danny Ayers wrote:

> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> Hi Chris,
> It looks like I've missed some developments, I'd better visit
> the Wiki. But anyway, in answer to your challenge : "How do you
> reference transitory thread content with full history in
> context?"
>
> 1. You acknowledge that you can't
> 2. Work around 1. ;-)
>
> Distributed redundancy I suppose is the key. Somewhere I posted
> a note suggested that every post in a thread keeps a record of
> immediate parent and child posts (Shelley then said this had
> been implemented with Movable Type). This means everything is
> duplicated. I guess that if each post selectively maintains more
> than this (siblings too? how?) then that might be a possible
> solution.

Regarding Parent and Child, I'm trying to be really careful here - Parent is cleancut and immediately do-able. Child is different,
however, because it suggests a mechanism for telling the Parent that the child exists. In other words, a Child cannot be created without the creator having knowledge of the Parent - knowledge that can be passed on with the Child - but a Parent is fundamentally unchanged by the creation of the Child.

In a closed system, like a single blog, adding this data to the parent isn't a problem. But once you start to have distributed conversations, if you insist on Parents listing their kids, you will need some form of notification system. (Trackback springs to mind here, actually).

Once you have thrown all the entries into a smoosh'o'rdf then this ceases to be an issue (as logically isChildOf is reversed to
isParentOf) but without doing that you can never be sure that the Parent knows of all of its Children.

Siblings embody the same problem.

Do I make sense today?
75
Marc Canter
05-05-2003
04:54 PM ET (US)
I think this is where having a centralized repository comes in handy.
Wouldn't it be true that if one copy of each response was kept in a standard format, on a centralized repository (somewhat like QuickTopic is doing right now - but in an open format - with data structure and APIs available to multiple tool vendors - we could get rid of redundancy and enable an open marketplace for shared conversations?

That's one of the underlying goals of ThreadsML - right?



>
< replied-to message removed by QT >
74
Danny Ayers
05-05-2003
03:50 PM ET (US)
Hi Chris,
It looks like I've missed some developments, I'd better visit the Wiki. But anyway, in answer to your challenge : "How do you reference transitory thread content with full history in context?"

1. You acknowledge that you can't
2. Work around 1. ;-)

Distributed redundancy I suppose is the key. Somewhere I posted a note suggested that every post in a thread keeps a record of immediate parent and child posts (Shelley then said this had been implemented with Movable Type). This means everything is duplicated. I guess that if each post selectively maintains more than this (siblings too? how?) then that might be a possible solution.
73
Chris Justice
05-05-2003
03:23 PM ET (US)
Ok, hi all! First and foremost, I am a total amateur and was invited to the site by David. I am very glad to see an initiative in this area. I am not sure at what point you are in the discussion but I thought I would chime in.

My challenge in the threading world: "How do you reference transitory thread content with full history in context?"

Essentially, this means how can you retain the history of a discussion if you are not sure if the related discussions will be present indefinitely?

I have started a XML markup to capture distributed thread history information but I was curious if anyone else had discussed this issue?
Edited 05-05-2003 03:25 PM
72
Marc Canter
04-30-2003
10:48 PM ET (US)
Hey Jay,

Welcome. Had a great talk with Steve today and David's got the site happening. Ben's still flying back (I think) or at least hasn't shown up here - yet.

Come on over to www.socialsoftwarealliance.org and join up as well!
Where are you based?

- Marc

>
< replied-to message removed by QT >
71
Jay FPerson was signed in when posted
04-30-2003
10:34 PM ET (US)
Hi,

I am working on a project called the iCite net (just starting to post info today on it at http://icite.net ) that, I think, is complimentary to ThreadsML and to ENT, and vice versa.

the iCite net includes a DNS-like service (called iCNS, or CNS if you need a TLA) that is especially for both topics and identities.

iCites are not tied to a particular markup vocabulary, but they are structured to consume and produce threads. So, I hope to see the iCite net develop to both generate iCites by consuming RSS + ENT feeds and ThreadsML marked up pages, and also to publish RSS + ENT feeds and pages marked up with ThreadsML.

I have been following this ThreadsML discussion since Jon Udell mentioned it in his "The Future of Online Community" blog post, and it is great that it has picked up again. ENT is a great development too!

Hope to connect more with everyone about this here and through the Social Software Aliance.

Jay
70
jonlPerson was signed in when posted
04-30-2003
10:18 PM ET (US)
How about some more use cases?

http://www.quicktopic.com/cgi-bin/thwiki.pl?UseCases
69
Marc Canter
04-30-2003
10:05 PM ET (US)
> The new nameservers kicked in today. I'm a little wrapped up at
> the minute, but when I get a chance I'll put in a link to the
> wiki, as a start. I'm totally open to suggestions about this, of
> course.
>
>

Cool dude - Since Steve's efficient email cleanser-upper has removed the original outline I put up - I guess you'll have to scroll down the page to find out my requests.

I'd say maybe a chart showing all these sorts of sources creating ThreadsML compatible "stuff" - and then showing where all these ThreadsML "things" could go to - would be a nice way to start.

Wanna draft that and I'll naively render it?
68
Steve Yost
04-30-2003
09:45 PM ET (US)
> - so what is the "xxxx" magic code to send a post to
> this list.
>

Marc, the email address for this QT topic is in the From address: qtopic+em-mXbfHC2srY3@quicktopic.com

So you can send to that address 'cold' (i.e. other than a reply) if you want, and it'll get posted and emailed out to the list too.
67
David Weinberger
04-30-2003
09:39 PM ET (US)
The new nameservers kicked in today. I'm a little wrapped up at the minute, but when I get a chance I'll put in a link to the wiki, as a start. I'm totally open to suggestions about this, of course.


-- 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 >
66
Marc Canter
04-30-2003
06:34 PM ET (US)
I was hoping for:
 - a web site to reference to point people to - when saying the term ThreadsML
 - this would be a marketing vehicle - it's goal - to explain to
non-participants in the process - what we're doing, what we're striving for, our schedule, our goals and pointers to the actual work
 - this would be a helpful exercise for the Dr. and myself - to both see what it's like working together (as I've stared in awe at what he and the "other Doc" have been able to accomplish.....)

So there must be some magic juju there and I want some of it.

Here's a dumb question:
 - So I've been cc:ing two different lists (the SSA and the Bloggers list) - and I wanted to send on post to this list as well
 - so what is the "xxxx" magic code to send a post to this list.

- QT topic em-mXbfHC2srY3 - is this it?

- Marc



>
< replied-to message removed by QT >
65
jonlPerson was signed in when posted
04-30-2003
05:56 PM ET (US)
David, what d'you want to do with threadsml.com and .org? Perhaps you should point it at the wiki at http://www.quicktopic.com/cgi-bin/thwiki.pl?ThreadsML? Or the SSA page? - whichever source seems authoritative...?
64
Steve YostPerson was signed in when posted
04-29-2003
10:52 PM ET (US)
Another link: the Social Software Alliance Wiki page on ThreadsML: http://www.socialsoftwarealliance.org/ssa-...index.cgi?ThreadsML

Thanks Peter!
63
Shelley (Burningbird) P
04-29-2003
07:53 PM ET (US)
I'm not going away, guys, just lurking rather than throwing in the poo poos. (Danny, that's an old-world phrase you can get behind; I learned about 'stop energy' when an online person told me that's what I do, spread stop energy.)

I tend to see the problems and instinctively yammer about them. But sometimes there's as many solutions as problems, so need to focus on these; or, at least, quietly lurk until you guys have coalesced a bit more.
62
David Weinberger
04-29-2003
06:40 PM ET (US)
www.threadsml.com and www.threadsml.org will be available in 24 hours or so.


-- 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 >
61
Danny Ayers
04-29-2003
02:51 PM ET (US)
Shelley - he's right you know! Pipe away!

Stop energy (apart from being one of those rather new-agey sort of phrases that makes us stuffy old-world types shuffle uncomfortably a little when we use them) is energy too ;-)
60
Marc Canter
04-29-2003
01:57 PM ET (US)
NO! Please do! We need as wide of a constituency as possible. Keep piping up!

I don't consider stop energy a bad thing, as it helps us fine tune our bulldozers!

>
< replied-to message removed by QT >
59
Shelley (Burningbird) P
04-29-2003
12:41 PM ET (US)
Danny:

Shelley, it's very good that you're raising all the issues, but personally I think you underestimate how much of the necessary infrastucture is achievable with tweaks on what we've already got (and I didn't even know how far trackback had got). Putting it another way, I'm sure it'll be a lot of work (as usual), but I don't think any of that work will be particularly difficult. Anyhow, with Marc's phases and the Wiki we have a route to finding out...

Shelley:

Danny, I'm not part of this, I know that. I shouldn't have even commented here, this is a group that has a momentum and doesn't need stop energy from the outside. My apologies for commenting in such a way that it seemed as if I was casting doubts on the achievability of the goals of this group. And I'll stop with my stop energy, so to speak.

Good luck to all of you.
58
Marc Canter
04-29-2003
11:10 AM ET (US)
OK - we got a thread about threads, a second linked in thread and a wiki.

Now how 'bout a web site - to aggregate pointers and all the press we're gonna get. I guess that could be a group blog - as well.

Dr. Weinberger since you are in possession of the domain, it's time for YOU to do something!

And maybe (if we ask nice) and wait till after his birthday, Paolo will do a logo.......
57
Marc Canter
04-29-2003
11:03 AM ET (US)
I'm posting directly inside of QT - just to get a flavor for "different platforms". I won't have a copy of this in my inbox - I guess the real questions is - will it get sent as email to everyone on the list?

Testing......

Time to go to the Wiki.... and imagine that being connected as well. Everyone say Happy Birthday to Paolo!
56
Danny Ayers
04-29-2003
04:53 AM ET (US)
Marc, you do your stuff well - nice summary. The proposed phases make a lot of sense, and I'll certainly +1 there.

Shelley, it's very good that you're raising all the issues, but personally I think you underestimate how much of the necessary infrastucture is achievable with tweaks on what we've already got (and I didn't even know how far trackback had got). Putting it another way, I'm sure it'll be a lot of work (as usual), but I don't think any of that work will be particularly difficult. Anyhow, with Marc's phases and the Wiki we have a route to finding out...

Steve, excellent to see the Wiki - I don't think I've ever seen such well timed deployment!
Good to see the new DC elements in QT too (ai!).

Someone (Steve?) thanks a million for the link to the threading standard thread, I'd missed this.

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/p88.78

...and I didn't mention ontologies once ;-)
55
Marc Canter
04-28-2003
11:53 PM ET (US)
> I propose that the above be considered required elements for ThreadsML.

All in favor - say ai! AI!

The ai's have it!

>
> I also added one element on the channel:
> dc:publisher, being the name of the place where the thread was
> originally published. Consider this optional.

I think this maps well to ENT's <cloud> - the source of topics.......
54
Steve Yost
04-28-2003
11:41 PM ET (US)
53
Steve YostPerson was signed in when posted
04-28-2003
11:29 PM ET (US)
Baby steps:
I've added more Dublin Core elements to QuickTopic's RSS1.0 implementation:

Two elements on each message:

dc:contributor, representing the author of the message
dc:identifier, being the unique message identifier that was discussed at length in the other ThreadsML topic.

I propose that the above be considered required elements for ThreadsML.

I also added one element on the channel:
dc:publisher, being the name of the place where the thread was originally published. Consider this optional.

Given these additions and a tiny bit more coding in QuickTopic, I can now do a nice little trick: present a QuickTopic thread using an XSL template:
http://www.quicktopic.com/em/H/mXbfHC2srY3.rss?xsl=/bare.xsl
(The XSL file is here: http://www.quicktopic.com/bare.xsl. Try using one of your own! Replace /bare.xsl with a URL pointing to your own XSL file. Note AFAIK this technique only works well in IE5.5+; The browser is doing the XSL transformation, and Mozilla doesn't seem to handle the "disable-output-escaping" attribute in the XSL file.)


But the hard work of adding threading remains. Though I think this should be optional (threading isn't needed for simple export of a linear thread like QuickTopic's), the concrete example is obviously necessary. I'll starting by linking another QuickTopic topic to this one and use that as a test case for threading among different forums (as though the secondary thread were on another site).
Edited 04-28-2003 11:50 PM
52
Steve YostPerson was signed in when posted
04-28-2003
09:11 PM ET (US)
Marc, your post /m49 says so much that rings true with me in the approach and the reminders of motivations. Excellent! It's great to have your constructive energy applied to this.

I'd only add a meta-level to "do it, do it, do it till you're satisfied", i.e. we may see fit to alter Phases II, III, etc. after we're done with phase I.

One more thing I'd like to see at Phase I is a good set of use cases. And this reminds me of something I almost forgot about (geez):

Way back when I put together a wiki for ThreadsML. I think it's had contributions from Bayle Shanks, Marc Adkins, Peter Kaminski, and myself. Let's use that for adding use cases and anything else we want to store in a less linear, more-linked fashion. Here's the page for Use Cases. You can explore from there and add as you see fit. Note there's also a QuickTopic forum linked there just to discuss the wiki itself.

http://www.quicktopic.com/cgi-bin/thwiki.pl?UseCases
Edited 04-28-2003 09:28 PM
51
Marc Canter
04-28-2003
08:11 PM ET (US)
Just starting to even realize it's possible............[time stamp]
> -----Original Message-----
> From: QT - Shelley (Burningbird) P

> Actually, I'm a person come lately to this, and don't really
> want to be disruptive. Well, any more disruptive than I have
> been.
>
> Was mainly curious as to what you all were hoping to accomplish.
> Thanks for the summary, Marc.
50
Shelley (Burningbird) P
04-28-2003
07:52 PM ET (US)
Actually, I'm a person come lately to this, and don't really want to be disruptive. Well, any more disruptive than I have been.

Was mainly curious as to what you all were hoping to accomplish. Thanks for the summary, Marc.
49
Marc Canter
04-28-2003
06:37 PM ET (US)
In the spirit of summation - I've just returned from lunch (here in SF) and it's time to summarize today's 'threads':

Shelly has been asking for implementation details
Danny clearly is a semantic engineer and loves to talk about ontologies and RDF
David Weinberger is excited
me - I'm just trying to make sure something happens
Paolo and Matt and working, Ben is flying back and Steve's got some cool code working (for years now - right?)

So here's my proposal for moving forward:

Yes we should start-off slow and build a protocol and format - once we figure out what that is and what it supposed to do! There are a number of other things possible (and desired)- then the existing ThreadsML spec, goals and scope. But my gutt tells me it's all centered around core issues and technology solutions.

But there are social - human issues as well - and that why we have to make sure - up front - we're all singing from the same hymn book - "what do we want to have this standard enable?"

So I propose:

Phase I:
 - establish an initial spec (or at least range of goals and scope) - get on the same page with each other
 - commence various experiments - with ENT and the existing ThreadsML RDF spec
 - build various prototypes showing real functionality (interop, centralized discovery mechanism, persistent RSS feeds, re-entrant conversations, conversion from one format to the next and so on...... (using TopicExchange, QuickTopic, k-collector, LiveTopics and whatever else we can get our hands onto)
 - while that is all going on - lots of healthy discussion should commence, as to what's possible...
  - in other words, make sure that we always come back to - "what do HUMANS want to do!"
  - we don't want to necessarily use this as a pedantic playground for applied research
 - and (in the spirit of the SSA's charter) we include humans - users - customers into the mix - listening to their requests, needs, etc. - all along the way...... [I hereby appoint David Weinberger and myself as representatives of the human race....]

Phase II:
 - once we have a first pass spec - I think Shelly's issues will become clear:
  - any sort of evolution of conversations MUST include persistence (some sort of storage of the conversations - however they're used and wherever they came from)
  - that some form of discoverability - registry - centralization services -w ill also be required
 - and other issues (topics embedded, DRM, adwords, commercial issues, more far reaching functionality) will be also need to be addressed
 - and we can THEN deal with implementation, standards, alliance building and the implied politics
 - who knows, we might even talk to a few BigCos - as well

Phase III: (as the song goes.....)
 - come on and do it, do it, do it till your satisfied (whatever it is) do it, do it till your satisfied


>
> That's what you're all looking for as a first implementation --
> exporting and importing the XML? And then later you'll bake a
> DNS like repository or system for these threads. That's the
> goals right now?

yup - for now!

>
> This would mean, then, that there is no discovery of a
> conversation, which defeats the purpose of all this, doesn't it?

Well to get to Nirvana you gotta be a good person first. You don't get Nirvana without paying some dues first. The TopicExchange has a simple directory now - no reason to say automatic discovery won't happen later, but first things first - Why? What? Who? Then we can get to how.

>
> However, if the conversation is about embedding this as new info
> in RSS, which doesn't persist, why would you want to do this
> without some form of data persistence incorporated?

WE WILL! Once we get a format established!

Does that make sense? - slap me if I'm wrong?


> > > 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 meta-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.
> >
>
> Try this once again, a bit more slowly please.

Sure no problem - I actually enjoy this sort of discourse......

.....first of all let me say that you referred to data that Google will start indexing and that we should make sure to "get it right!" YES! That's the Phase I I refer to above. Now.

Let's see how this 'could' work. After that initial Phase I work is done, we can then properly approach persistence, discoverability, etc.


> What exactly do
> you mean by 'flow blog posts into new kinds of aggregators'? An
> aggregator is nothing more than a way of showing the RSS
> information in human format. These don't persist the data
> either. Were you thinking of something like conversation
> aggregators that show that a discussion about a certain topic is
> happening, but without concern about search on this and without
> persisting it?

YES - that should be ONE usage scenario.

Let me summarize. I have experienced in my life several times where a standard or a tool produced unexpected results. In fact over and over again Clay Shirky and the social scientists keep talking about this. The blogosphere in general (it could be argued) is a random occurrence, certainly not planned by Dave Winer or Evan Williams.

So as we approach a ThreadsML standard, I'm not afraid to create apparently diametrically opposed notions or oxymorons - which may just work themselves out.

=======================

back to something else Shelly said....

But what if the thread is not preserved? If the plan is to look
at throwing this into RSS, the thread is no preserved. Unless I
read the earlier stuff incorrectly.

Even if a thread is preserved as an exported XML file, how
exactly would a server ping along the line work? Or are we
talking about storing this information in a data store locally,
RDF implemented or not, and then wrapping this with a service
that can search for threads/topics among its own store?

=======================

It's really fortunate that we're all pretty smart and that Ben was able to see the connection between the current idea of ThreadsML and what ENT is. That said.......XML storage seems in order. A format that acts as BOTH an interop and persistent object store.

This has ramifications way beyond just threads and conversations.
=======================

And finally....... [again from Shelly]

the power of RDF most likely won't come into play with TheadsML and ENT, but if the folks want to play around with the existing RSS
1.0, it can't hurt. Other than adding more bytes and burden to
the RSS files.

========================

Ok - so let me try and frame it from your point of view:
 - instead of playing around with "just" RDF, we'll also try doing something with simple old ENT
 - the best part will be - that something might even get done
 - THEN (as I hope the results from Phase I will bear fruit) - we'll have a format to store, some examples of usage scenarios to study, iterate on and get feedback from
 - THEN (as the ants go marching) NEW ideas will arise - which may or may not necessitate expanding the spec, changing the scope, iterating the ideas
You ask all the right questions - but if we can agree to the criteria I list as Phase I - we can at least commence on that........
48
Shelley Powers
04-28-2003
05:38 PM ET (US)
> heh, cool! But remind me again why we're talking about threads
> and not topics?
>

Sorry, ThreadsML tends to make me think of threads, not topics. Topics are multi-threaded so one should focus on a higher level.

> > However, based on this, there is nothing in this that allows
> one
> > to designate a 'topic'. We all know that the category is
> > useless. Would we use the title?
>
> What am I missing here?
>
> Ok, there are issues of detail - use a globally defined topic
> for the whole thread, and have problems if the subject mutated
> along the way; use per-poster recording of the topic
>
> item1 topic http://blogx.org#coycarp
> item2 topic http://blogy.org#goldfish
>
> but isn't this pretty much orthogonal to the threading
> dimension?
>
> > And, this just allows people who are thread aware to follow
> the
> > thread. This doesn't allow for discovery of threads, except by
>
> > stumbling across them while reading blogs, etc.
>
> Which is an indexing problem - orthogonal again! If you can
> discover one item in a thread and the thread is preserved then
> you can discover them all. A server ping somewhere along the
> line, perhaps?
>

But what if the thread is not preserved? If the plan is to look at throwing this into RSS, the thread is no preserved. Unless I read the earlier stuff incorrectly.

Even if a thread is preserved as an exported XML file, how exactly would a server ping along the line work? Or are we talking about storing this information in a data store locally, RDF implemented or not, and then wrapping this with a service that can search for threads/topics among its own store?

> > Still, why not follow through on Trackback, which is already
> 80%
> > implemented?
>
> Yep.
>

Trackback won't work for topic, though, only thread.

> > > I think the natural interconnectivity of the web might be
> > enough
> > > in itself, but you could also ping a centralised server with
>
> > the
> > > RDF snippet corresponding to the join in the thread too.
> > >
> >
> > Again, this is doable, if one has the space and a very
> efficient
> > search engine.
>
> The explicit data is available to the server thanks to the ping.
> The storage and indexing could take place at that point in time,
> so effectively all that has to be done to search is a DB query.
>

Don't see this. There's a lot of assumptions and architecture that must be in place just to support "the ping". When you talk about DB query, you're talking then that all participants who support the threads, must have a data implementation in place to support all of the rest of this. Sort of like everyone has to install Redmond. Or similar. This is beyond 'just' another table in MT, and its all beyond most of the other tools, blogging or not.
> But it can be done with trackback too, as Ben
> > Trott has
> > demonstrated.
>
> I don't follow..?
>
> > > Spidering/scraping email archives would produce a lot of
> > threads
> > > thanks to the mail's inReplyTo, but this could be augmented
> if
> > > you could persuade people to add a special tag in their post
>
> > > somewhere e.g. thread:IAgree could be picked up by a spider
> > and
> > > a triple generated:
> > >
> > > thisMail IAgree previousMail
> > >
> >
> > Mail. What you do you mean by mail. Do you mean, QuickTopic
> > mail? Outlook mail?
>
> Electronic mail. Email.
> In the worst case, with generic mail clients I'm suggesting that
> the user adds simple markup manually to their mail, in the best
> case - I don't know, the user picks from a drop-down list in
> their QuickTopic web interface.
>

But how do we get from point A to point B with this? Again, the
infrastructure support for this is almost impossible to imagine.

> [snip]
> > > structures needed for threads. Before I'm accused of
> personal
> > > bias: although I think RDF would be the best and probably
> > > easiest solution, it certainly isn't the only possible
> > solution.
> > > XTMs or even a completely new language could do the job.
> > >
> >
> > And I have to push back at RDF. Why do you see this needing to
>
> > be RDF, Danny?
>
> I said "it certainly isn't the only possible solution"!!
>
> If it's because we already have RSS 1.0 and we're
> > used to it, and it's a data model that handles namespaces and
> > has existing technology to support it, well then that's cool.
>
> These are factors that make me think that RDF might be the
> easiest approach. Added to that, RDF is cute and cuddly ;-)
>

RDF is cold blooded and demanding, superior and arrogant, and a thing of pure rose crystalline beauty. I think RDF is one of the best things since sliced bread, but I know its not for the average everyday flat hierarchy brain dead data model use.


> > But we all agree there isn't any semantic richness to this
> > thread structure. Correct?
>
> I have no idea. The talk of topics being one of the outstanding
> issues suggests it might be.
>

Not necessarily. If its topics have threads have knots, that's not semantically rich. If its topics have other semantically related topics and other associated data, then we're talking different. But I think this gang is talking the former, not the latter.

> Or do we want semantic richness? If
> > so, then we don't have it from current possible vocabularies.
>
> Again, I haven't a clue. I certainly misunderstood what the
> problem is. There is a lot of richness in existing vocabularies,
> but what are we trying to say?

I'm probably saying what people here aren't interested in. I'm curious as to what the first prototype, implementation of this all is going to be. And my point on data mainly is that the power of RDF most likely won't come into play with TheadsML and ENT, but if the folks want to play around with the existing RSS 1.0, it can't hurt. Other than adding more bytes and burden to the RSS files. Just don't expect 'semantic richness' because you're using RDF/XML and can break the data down into a triple. My mom can't even type into a computer and can break a statement down into a triple given a little help. That doesn't mean that she understands the semantic web.

Shelley
47
Danny Ayers
04-28-2003
02:52 PM ET (US)
[another mail went into the void - maybe I shouldn't be doing reply-to-all...]

> This has already been implemented via trackback in MT. I have
> trackback and backtrack which shows both directions. Sam Ruby
> took it further and allows one to traverse the distance all the
> threads in either direction.

heh, cool! But remind me again why we're talking about threads and not topics?

> However, based on this, there is nothing in this that allows one
> to designate a 'topic'. We all know that the category is
> useless. Would we use the title?

What am I missing here?

Ok, there are issues of detail - use a globally defined topic for the whole thread, and have problems if the subject mutated along the way; use per-poster recording of the topic

item1 topic http://blogx.org#coycarp
item2 topic http://blogy.org#goldfish

but isn't this pretty much orthogonal to the threading dimension?
 
> And, this just allows people who are thread aware to follow the
> thread. This doesn't allow for discovery of threads, except by
> stumbling across them while reading blogs, etc.

Which is an indexing problem - orthogonal again! If you can discover one item in a thread and the thread is preserved then you can discover them all. A server ping somewhere along the line, perhaps?

> Still, why not follow through on Trackback, which is already 80%
> implemented?

Yep.

> > I think the natural interconnectivity of the web might be
> enough
> > in itself, but you could also ping a centralised server with
> the
> > RDF snippet corresponding to the join in the thread too.
> >
>
> Again, this is doable, if one has the space and a very efficient
> search engine.

The explicit data is available to the server thanks to the ping. The storage and indexing could take place at that point in time, so effectively all that has to be done to search is a DB query.

But it can be done with trackback too, as Ben
> Trott has
> demonstrated.

I don't follow..?
 
> > Spidering/scraping email archives would produce a lot of
> threads
> > thanks to the mail's inReplyTo, but this could be augmented if
> > you could persuade people to add a special tag in their post
> > somewhere e.g. thread:IAgree could be picked up by a spider
> and
> > a triple generated:
> >
> > thisMail IAgree previousMail
> >
>
> Mail. What you do you mean by mail. Do you mean, QuickTopic
> mail? Outlook mail?

Electronic mail. Email.
In the worst case, with generic mail clients I'm suggesting that the user adds simple markup manually to their mail, in the best case - I don't know, the user picks from a drop-down list in their QuickTopic web interface.

[snip]
> > structures needed for threads. Before I'm accused of personal
> > bias: although I think RDF would be the best and probably
> > easiest solution, it certainly isn't the only possible
> solution.
> > XTMs or even a completely new language could do the job.
> >
>
> And I have to push back at RDF. Why do you see this needing to
> be RDF, Danny?

I said "it certainly isn't the only possible solution"!!

If it's because we already have RSS 1.0 and we're
> used to it, and it's a data model that handles namespaces and
> has existing technology to support it, well then that's cool.

These are factors that make me think that RDF might be the easiest approach. Added to that, RDF is cute and cuddly ;-)

> But we all agree there isn't any semantic richness to this
> thread structure. Correct?

I have no idea. The talk of topics being one of the outstanding issues suggests it might be.

 Or do we want semantic richness? If
> so, then we don't have it from current possible vocabularies.

Again, I haven't a clue. I certainly misunderstood what the problem is. There is a lot of richness in existing vocabularies, but what are we trying to say?

Cheers,
Danny.
46
Shelley Powers
04-28-2003
01:39 PM ET (US)
>
>
> --QT-------------------------------------------------------------
> Note: replies go to the entire group (see below)
> -----------------------------------------------------------------
>
> [sorry if you get this twice, but my last couple of posts seem
> to have evaporated]
>
> > 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.
>
> May I?
>
> A starter, anyway:
>
> Person A makes a statement, which is recorded as a blog item.
> For convenience I'll label the URI of this statement A.
>
> Person B comments on this item, directly on the site. This is
> recorded as B inReplyTo A in the RDF store maintained on A's
> site (in practice, right now, this would probably be another
> table in their Movable Type database installation dedicated to
> thread tracking).
>
> Person C comments on A, on their own blog. When this is recorded
> a trackback ping is sent to A. A records this as a regular
> trackback AND as C inReplyTo A in the extra table.
>
> This is the important bit : if C is threads-enabled, then C
> records the thread too, as C inReplyTo A. i.e. the connection is
> recorded at both ends.
>
> This recording-at-both-ends means that the whole thread can be
> reconstructed from any point in the thread. Ok, if there are
> leaves are 'threadbare' then they might be ignored, but existing
> trackback/link-following may well help here.
>
> I think there are only a few tweaks needed to get a basic system
> working from MT as it stands, though it would be cool if the
> blog-entry form had some extra checkboxes that corresponded to
> the semantics available in ThreadsML (is there
> 'emphaticallyDisagree'? - whatever). This would almost certainly
> call for an extra MySQL table behind the scenes.
>

This has already been implemented via trackback in MT. I have trackback and backtrack which shows both directions. Sam Ruby took it further and allows one to traverse the distance all the threads in either direction.
However, based on this, there is nothing in this that allows one to designate a 'topic'. We all know that the category is useless. Would we use the title?

And, this just allows people who are thread aware to follow the thread. This doesn't allow for discovery of threads, except by stumbling across them while reading blogs, etc.

Still, why not follow through on Trackback, which is already 80%
implemented?

> I think the natural interconnectivity of the web might be enough
> in itself, but you could also ping a centralised server with the
> RDF snippet corresponding to the join in the thread too.
>

Again, this is doable, if one has the space and a very efficient search engine. But it can be done with trackback too, as Ben Trott has
demonstrated.


> Spidering/scraping email archives would produce a lot of threads
> thanks to the mail's inReplyTo, but this could be augmented if
> you could persuade people to add a special tag in their post
> somewhere e.g. thread:IAgree could be picked up by a spider and
> a triple generated:
>
> thisMail IAgree previousMail
>

Mail. What you do you mean by mail. Do you mean, QuickTopic mail? Outlook mail?

> if your clients are really willing then you could refer to links
> in email in a scrapable fashion, e.g.
>
> Regarding this post,
> thread:IAgree http://dannyayers.com/archives/001231.html
> I usually agree with myself.
>
> btw, I'm not sure if everyone in this topic has encountered it
> before, but a lot of work has been done around the Topic Map
> domain on dialog mapping - try searching on these terms and
> 'Jack Park', and I think there are some links in my IBIS doc -
> http://purl.org/ibis (a not-unrelated spec, that my be useful in
> joining domains together).
>
> --- later ----
>
> > > 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
>
> I'd be skeptical about whether a predominantly centalised system
> would work, in terms of adoption and scalability. If the thread
> data was recorded local/nearby to the thread item's own content,
> then the load would be distributed, which is scalability dealt
> with. If it was done in a fashion that started simple, then the
> effort needed to enable this in blogging tools would be minimal,
> and the adoption aspect would be dealt with - people would get
> it with their tool.
>
> Note that a centralised searchable directory of threads could be
> created as a side effect of the distributed system - tools could
> just ping the mother ship.
>
> > > - 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.
>
> OPML is a non-starter - it's effectively impossible to validate
> and would be hopeless at representing the general graph
> structures needed for threads. Before I'm accused of personal
> bias: although I think RDF would be the best and probably
> easiest solution, it certainly isn't the only possible solution.
> XTMs or even a completely new language could do the job.
>

And I have to push back at RDF. Why do you see this needing to be RDF, Danny? If it's because we already have RSS 1.0 and we're used to it, and it's a data model that handles namespaces and has existing technology to support it, well then that's cool. But we all agree there isn't any semantic richness to this thread structure. Correct? Or do we want semantic richness? If so, then we don't have it from current possible vocabularies.

<snip>

Shelley
45
Danny Ayers
04-28-2003
01:22 PM ET (US)
[sorry if you get this twice, but my last couple of posts seem to have evaporated]

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

May I?

A starter, anyway:

Person A makes a statement, which is recorded as a blog item. For convenience I'll label the URI of this statement A.

Person B comments on this item, directly on the site. This is recorded as B inReplyTo A in the RDF store maintained on A's site (in practice, right now, this would probably be another table in their Movable Type database installation dedicated to thread tracking).

Person C comments on A, on their own blog. When this is recorded a trackback ping is sent to A. A records this as a regular trackback AND as C inReplyTo A in the extra table.

This is the important bit : if C is threads-enabled, then C records the thread too, as C inReplyTo A. i.e. the connection is recorded at both ends.

This recording-at-both-ends means that the whole thread can be reconstructed from any point in the thread. Ok, if there are leaves are 'threadbare' then they might be ignored, but existing trackback/link-following may well help here.

I think there are only a few tweaks needed to get a basic system working from MT as it stands, though it would be cool if the blog-entry form had some extra checkboxes that corresponded to the semantics available in ThreadsML (is there 'emphaticallyDisagree'? - whatever). This would almost certainly call for an extra MySQL table behind the scenes.

I think the natural interconnectivity of the web might be enough in itself, but you could also ping a centralised server with the RDF snippet corresponding to the join in the thread too.

Spidering/scraping email archives would produce a lot of threads thanks to the mail's inReplyTo, but this could be augmented if you could persuade people to add a special tag in their post somewhere e.g. thread:IAgree could be picked up by a spider and a triple generated:

thisMail IAgree previousMail

if your clients are really willing then you could refer to links in email in a scrapable fashion, e.g.

Regarding this post,
thread:IAgree http://dannyayers.com/archives/001231.html
I usually agree with myself.

btw, I'm not sure if everyone in this topic has encountered it before, but a lot of work has been done around the Topic Map domain on dialog mapping - try searching on these terms and 'Jack Park', and I think there are some links in my IBIS doc - http://purl.org/ibis (a not-unrelated spec, that my be useful in joining domains together).

--- later ----

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

I'd be skeptical about whether a predominantly centalised system would work, in terms of adoption and scalability. If the thread data was recorded local/nearby to the thread item's own content, then the load would be distributed, which is scalability dealt with. If it was done in a fashion that started simple, then the effort needed to enable this in blogging tools would be minimal, and the adoption aspect would be dealt with - people would get it with their tool.
 
Note that a centralised searchable directory of threads could be created as a side effect of the distributed system - tools could just ping the mother ship.

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

OPML is a non-starter - it's effectively impossible to validate and would be hopeless at representing the general graph structures needed for threads. Before I'm accused of personal bias: although I think RDF would be the best and probably easiest solution, it certainly isn't the only possible solution. XTMs or even a completely new language could do the job.

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

I don't think it's either/or between a threads interchange standard and ThreadsML - ThreadsML does a fair job of modelling most/all the relationships that you'd be likely to want to represent. A basic t.i.s. could simply demand just a single, simple 'inReplyTo' (or whatever) relationship, formatted in whatever fashion was deemed appropriate. This would be mappable to the corresponding term in ThreadsML. I personally think the easiest way of implementing a t.i.s. *would* use a subset of ThreadsML, but again this isn't the only option.

Cheers,
Danny.
44
Shelley Powers
04-28-2003
01:14 PM ET (US)
----------------------------------------------------------------- >
> 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.
>

So if I understand this then, your interest at this time is just to define the elements within the XML vocabulary so that one could export a file with the XML for this, and import it. In other words, from this list, we would have thirty something knots in the thread, one for each message, and exporting this file would show these knots. Someone else could import this into something, and then do what, add more new knots?

Thats what you're all looking for as a first implementation -- exporting and importing the XML? And then later you'll bake a DNS like repository or system for these threads. That's the goals right now?

This would mean, then, that there is no discovery of a conversation, which defeats the purpose of all this, doesn't it?

However, if the conversation is about embedding this as new info in RSS, which doesn't persist, why would you want to do this without some form of data persistence incorporated?


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

Try this once again, a bit more slowly please. What exactly do you mean by 'flow blog posts into new kinds of aggregators'? An aggregator is nothing more than a way of showing the RSS information in human format. These don't persist the data either. Were you thinking of something like conversation aggregators that show that a discussion about a certain topic is happening, but without concern about search on this and without persisting it?

Shelley
43
Marc Canter
04-28-2003
01:04 PM ET (US)
> 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).

What I like is the balance of expertise and naivete - being contributed. Me - I'm just the marketing guy. But we're asking all the right questions right now!

>
> See embedded comment.
>
> -- David W.
>
> > I vote for:
> >
> > - a DNS-like open repository of thread
> > "pointers"/topics/meta-data - which enables folks to not only
> > track the threads - 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...


No - you're right on! I secretly hope that once Nic Nyholm is done baking a DNS-like system for identity for us, we'll be able to repurpose that for ThreadsML. In the mean time - you're right, we can't afford to wait for that.......

And I think we should approach Prospero - as they have a critical mass of message boards - and with one win, could get A WHOLE LOTTA folks tied in.
42
David Weinberger
04-28-2003
12:50 PM ET (US)
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
41
Marc Canter
04-28-2003
12:21 PM ET (US)
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
40
Shelley (Burningbird) P
04-28-2003
11:45 AM ET (US)
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?
39
Marc Canter
04-28-2003
11:42 AM ET (US)
> 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.

:-)


>
38
Marc Canter
04-28-2003
11:42 AM ET (US)
> 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.

:-)
37
Steve YostPerson was signed in when posted
04-28-2003
10:32 AM ET (US)
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.
36
Steve Yost
04-28-2003
08:44 AM ET (US)
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.
35
Steve YostPerson was signed in when posted
04-28-2003
06:25 AM ET (US)
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.
34
Marc Canter
04-28-2003
12:34 AM ET (US)
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
>
33
Shelley (Burningbird) P
04-27-2003
10:13 PM ET (US)
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.)
32
Marc Canter
04-27-2003
04:57 AM ET (US)
Here's my post on Ben's session. It includes notes of what people think ThreadsML should do.
31
Marc Canter
04-16-2003
11:54 AM ET (US)
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 >
30
Cayzer, Steve
04-16-2003
10:09 AM ET (US)
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 >
29
Myk Melez
04-15-2003
06:29 PM ET (US)
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
28
Peter Kaminski
04-14-2003
11:20 PM ET (US)
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
27
Marc Canter
04-14-2003
01:45 PM ET (US)
I would say Matt is the expert on that.

- Marc

>
< replied-to message removed by QT >
26
Danny Ayers
04-14-2003
01:38 PM ET (US)
Matt - just acknowledging you have a good point, I'm not 100% convinced, but then we can't be 100% certain of anything anyway ;-)


< replied-to message removed by QT >
25
Steve YostPerson was signed in when posted
04-14-2003
01:32 PM ET (US)
Sure sounds like the best possible outcome, Marc. I need to learn more about the diffs and similarities between RDF/RSS1.0 and ENT/RSS2.0. A little homework for me.
Edited 04-14-2003 01:33 PM
24
Marc Canter
04-14-2003
01:15 PM ET (US)
GREAT!

This (I think confirms my theory that we (collectively) could move forward implementing something new like ThreadsML - BOTH RDF/RSS1.0 AND ENT/RSS2.0.
Correct?

And that TopicRolls and Clouds (as ingeniously designed by Matt and Paolo) can be a bridge between these two implementation worlds.

Correct?

- Marc

>
< replied-to message removed by QT >
23
Marc Canter
04-14-2003
01:12 PM ET (US)
Good morning everyone - late night on the West Coast - but now I've caught with all the traffic.

Here's my replies to all the subjects:

- by definition - interest in ThreadsML is back - thanks to this
interchange.

- I think we can keep discussion of ENTs relevance to ThreadsML going, but it's obviously a tertiary importance to the core issues of each:

 - Matt and Paolo have just announced ENT - so they're heads down trying to get a new kind of aggregator released - their next tasks will be to evangelize ENT to the other aggregator tool vendors, all the while keeping a mind open to what's possible

 - TopicRolls and the concept of "clouds" are a clear way to bridge between any and all implementation using ENT today and any RDF - semantically inclined functionality and frameworks - moving forward. The key is end-user's investments in building their "digital lifestyles" around these new sort of software tools, and I think TopicRolls and Clouds are exactly appropriate places for transitioning forward - if and when that is required.
- that said - I've fascinated in the pure functionality of what ThreadsML can enable.

 - but as usual, for us to take any conceptual discussion forward, get it implemented and then place that functionality into the hands of end-users - is the key goal
 - so to that ends I proposed that the ThreadsML efforts be "flowed" through ENT
 - this might BOTH get us to our goals (see below) AND keep the channels open moving forward

==============

That said - here's what I think would be most powerful.

 - it's clear tome that RDF-RSS is a religious matter - and especially since this week is Passover, which then naturally leads to Easter, in the spirit of Jesus, and to avoid any Bosnia's, Iran-Iraq, African genocide, terrorist incidents or major rolling of the tanks - I think we should all be especially careful not to let this discussion end-up in some religious dispute. Each to his use. Vive le defrance!

 - it's clear to me that RDF DOES now have momentum - and that the ball is in Danny's, OSAF, the W3C, T B-L and the rest of those (notice I didn't say REST-ful ones :-) folks - to put their money where their mouth are...... (I for one am pretty excited about the possibilities!)

 - and I'd venture to bet that these RDF folks are probably pretty busy doing just that

 - and Matt and Paolo are pretty busy too

 - so then it falls onto the shoulders of the message board folks - symbolically represented by Steve - to try and see if there's some overlap/cross-over possibilities between what ThreadsML is today as defined as a RDF framework - and what can be done with good-old simple, hardwired framework that it is - RSS/ENT.

  - also just as clearly is the goal to keep 100% backwards compatibility so all those aggregators keep on rocking the end-user's worlds, and keep on providing new areas of functionality to humans. This is key. So that's another reason why namespaces - as they're implemented in RSS 2.0 makes sense. Nobody here wants to break anything, and if we're to leverage all those aggregators and aggregators users - this is also a requirement.
 - as I implied above - the REAL goal would be to get ThreadsML to work with BOTH an RDF/RSS1.0 AND a ENT/RSS2.0 implementation scheme. THAT would really rock the house, make all parties happy and...... nullify any potential religious warfare.

Does that make sense?

- Marc

BTW Our (Broadband Mechanics) goal is to create new kinds of front-ends and new kinds of aggregators - that would pull in Threads from iVillage, Slashdot, QuickTopic and all sorts of message boards into one place - in other words message/thread aggregation.

Venturing into this area naively I thought 'all' we needed was an: - open data structure
 - open API that all tools would adopt (post, read, etc.)

But clearly we're all poised to go beyond that. I just wanna make sure the simple goal of aggregating messages happens - so we can do for messages, what RSS/RDF did for news feeds.

That's the overall goal - new functionality for humans - NOW!
22
Steve YostPerson was signed in when posted
04-14-2003
01:11 PM ET (US)
Ben, thanks -- this sheds a lot of light on the issue for me.

The situation sounds very good to me. It sounds like app writers were able to conform to reading RSS 1.0 fairly simply, without writing themselves into a corner -- they can add more semantic processing if they wish later (presumably by rewriting non-user-visible layers, or using libraries when they're available). Meanwhile, content producers can produce whatever richness they're motivated to. The great bottom line is that the spec becomes a non-issue in bridging the two, leaving it to the market to determine that.

It sounds like Shelly Power's book will be good to help understand RDF. Hopefully it will motivate people to write software libraries. Oversimplifying, RDF needs its James Clark.
21
Ben Hammersley
04-14-2003
12:45 PM ET (US)
Nothing would break, that's true. The namespacing does that trick - same as in 2.0, actually. The question, however, is whether any
existing RSS aggregators actually aggregate 1.0 as RDF, i.e. by parsing it into triples, or building an RDF database, and then querying that database for the display. As far as I know, none do. They just parse 1.0 as if it were 2.0, by simple XML handling, or even RegExps.

The ramifications of this are quite plain: extensions are ignored unless the software is set up to see them, rather than the ideal situation where the data is thrown into an RDF soup, and it's just a matter of using a different query to get at it. It's this soup-ability that gives RDF the edge, imho, if only the documentation was there. Shelley Power's new book should help a lot.


On Monday, April 14, 2003, at 06:00 PM, QT - Steve Yost wrote:

>
< replied-to message removed by QT >
20
Steve YostPerson was signed in when posted
04-14-2003
12:15 PM ET (US)
Libraries supporting RSS 1.0:

Perl: http://perl-rss.sourceforge.net/
PHP example, not library: http://www.sitepoint.com/article/560/1
Java: Jena:
  preview 2 released: http://www.hpl.hp.com/semweb/jena2.htm
  RSS 1.0 parsing: http://www-uk.hpl.hp.com/people/bwm/rdf/jena/rssinjena.htm

I'll update this post as I find more. I couldn't find one for c-sharp. Any other favorites?
Edited 04-14-2003 01:17 PM
19
Steve YostPerson was signed in when posted
04-14-2003
12:00 PM ET (US)
Would it be practical for someone to write a library that's specific to a particular RDF usage (like proposed ThreadsML) that doesn't cover RDF generally?

Also, a major concern is that an implementation doesn't break existing tools that might use it effectively.

As an example that covers both of these items, it seems that lots of RSS aggregators support RSS 1.0. [I'd really like a table of popular aggregators and their support. Here's one: http://blogspace.com/rss/readers
]

It's my understanding that any extension that's based on RSS 1.0 would not break existing apps that support RSS 1.0. True?
Edited 04-14-2003 12:10 PM
18
Danny Ayers
04-14-2003
11:35 AM ET (US)
> Looks like your post crossed mine on the wire, Danny. Thanks.

heh, and again.

> I wonder: regarding software libraries, is there a big leap from
> supporting the namespace extension of RSS 2.0 for ENT to
> supporting RDF in general? (I think you implied that there
> isn't).

Aah, scratch any implication to be found along those lines. The point I was trying to make was that what probably scares most potential RSS 1.0 users away is the ugly syntax of RDF/XML, which usually begins with lots of namespace declarations, and features prefixed:elements and even the rare prefixed:attributes all over the place. These are actually artifacts of XML not RDF, it's just that they don't appear in RSS 2.0, until you add extensions.

To support RDF in general, you would really be talking about supporting the model. This could be a big leap. I guess it depends a lot on how people are modelling things already - e.g. if their RDBMS tables are fairly well normalised then it should refactor without too many tears.

Cheers,
Danny.
17
Matt Mower
04-14-2003
11:23 AM ET (US)
Hi Danny,

[Note: I started drafting this message before the last flurry of posts by Danny & Steve - I think it's contents are still pretty relevant]
> [snip re. types]
> I'll be interested in seeing what you've come up with for
> this. Your remark "...we introduced Types as a way to create
> relations between posts..." does make me wonder though -
> ThreadsML offers a way of creating relations between posts
> using an existing framework for expressing relations, even if
> you didn't find ThreadsML the language suitable you could
> still use the relationship framework (RDF). The ENT idea I
> can see as a neat way of introducing an important bit of
> semantics into RSS 2.0 (something else I'd run a mile from
> ;-) but extending this idea further really does sound like
> there might be wheel-reinvention going on. I hope & trust
> you'll convince me otherwise ;-)
>

I can see where you are coming from, it's a concern for us too. But I don't think there is too much to be worried about.

My view is that RDF is a great way of doing things as long as it is wrapped with 1st rate tool support and matched with applications that warrant it. So far as I can tell both of those are near to non-existant right now and RDF remains primarily the domain of "those people who are interested in RDF and think it is a good idea," with a few exceptions.
Back when Paolo and I were tossing this idea around we carefully thought over "are we re-inventing RDF" and came to the answer: "no." ENT is, by comparison, pretty simple/limited compared to RDF. But right now I think simplicity is more valuable than power. We are still in the early stages of building the semantic web and, really, the applications we have don't *need* RDF's power right now. We think ENT is "just good enough" to launch a raft of exciting applications.

I fully expect though, that those applications will grow too big for ENT and simple "hard-wired" standards like it. But this demand will, perhaps, lead to an awakening about RDF. It's time will have come because there will be applications that justify it's complexity & the perceived benefits of those applications will be enough to overcome the inertia involved in getting started with it. And, hopefully, by that time the RDF folks will have delivered much more solidly on the tools front ;)

In short my belief is that simple, focused, standards now will pave the way for the adoption of more powerful standards later. Also, as I have stated before[1], I don't think that RDF will really hit a home run until OWL is ready for prime-time.

Regards,

Matt

[1] http://matt.blogs.it/2003/04/08.html#a856
16
Steve Yost
04-14-2003
11:10 AM ET (US)
Looks like your post crossed mine on the wire, Danny. Thanks.

I wonder: regarding software libraries, is there a big leap from supporting the namespace extension of RSS 2.0 for ENT to supporting RDF in general? (I think you implied that there isn't).
15
Steve YostPerson was signed in when posted
04-14-2003
11:06 AM ET (US)
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)?
14
Danny Ayers
04-14-2003
11:04 AM ET (US)
> I like quite a few things I read in the ENT spec, especially the
> pragmatic approach revealed in lines like these:

I agree - this aspect is impressive.

But:
===
> It is our position that the chief reason for the lack of
> widespread support of the existing standards is their perceived
> complexity.
===

I reckon this analysis probably is spot on, but shouldn't the appropriate response be an attempt to change the perception, rather than creating a new standard - doesn't this just add to the (real) complexity? (I could be wrong, see below)

> [To this I'd add the secondary result of lack of
> software library support. Has this changed recently?]

A few people are trying to directly address the issue, but I don't think there have been any major revolutions, though the attention Movable Type's been getting is probably significant.

===
> By using a namespace, non-ENT compliant RSS aggregators may
> safely ignore the ENT elements and attributes and the topic
> information contained within them.
> ===

If you compare an RSS 1.0 feed with and RSS 2.0 feed, the scariest part for a newcomer is probably the use of namespaces in 1.0. Perhaps their use in places like ENT will sweeten this - so that a side effect of RSS 2.0 + ENT might be greater willingness to consider the RDF framework...

> I'm not yet up on RSS 2.0 (and BTW I'm certainly not the most
> qualified to push in any particular technical direction here.)
> Thinking about immediate applicability (a big boost for
> momentum), can anyone comment on current support for RSS 2.0 in
> software libraries, and in applications like RSS aggregators?

I think it can be checked somewhere around syndic8.com, but I think support for basic RSS 2.0 syndication/viewing is fairly universal (it varies little from the previous Userland specs). I don't know what the situation is regarding namespace-identified extensions (like ENT), though I'm fairly confident that 'rare' would be a good estimate.

Cheers,
Danny.
13
Steve YostPerson was signed in when posted
04-14-2003
10:37 AM ET (US)
I like quite a few things I read in the ENT spec, especially the pragmatic approach revealed in lines like these:
===
The goals of ENT are to:
1. be as simple to implement as possible
2. represent topics sufficiently that they be useful in enabling smart aggregators (e.g. filtering, recombining feeds, etc...)
--
It is our position that the chief reason for the lack of widespread support of the existing standards is their perceived complexity. [To this I'd add the secondary result of lack of software library support. Has this changed recently?]
--
By using a namespace, non-ENT compliant RSS aggregators may safely ignore the ENT elements and attributes and the topic information contained within them.
===

I'm not yet up on RSS 2.0 (and BTW I'm certainly not the most qualified to push in any particular technical direction here.) Thinking about immediate applicability (a big boost for momentum), can anyone comment on current support for RSS 2.0 in software libraries, and in applications like RSS aggregators?
12
Steve YostPerson was signed in when posted
04-14-2003
10:17 AM ET (US)
Matt wrote in /m6:
> One thing I haven't come across so far is any
> explanation about why the previous initiative fell
> short. Can anyone summarise? Are there any lessons
> to be learned? Have we?

I'd say it was nothing more than lack of a consistent push on my part, my attention being pulled back to QuickTopic core features. I think the participants were in agreement about the fundamental issues. Divergences happened around details, and there was a little defocusing around tangential issues and applications.

I'm even more confident now that with enough attention and agreement on (and focus on) the problem we're trying to solve, we can create an extremely useful standard here.
11
Danny Ayers
04-14-2003
09:36 AM ET (US)
Ciaio Paolo,

> Looks like we might be able have some parts of the aggregator up
> and running by the conference time. We won't be able to
> participate (unless we win some money within the next few days),
> but I guess this is not going to be a big problem.

This is great - any URLs to look at already?

...

> The first one is the usage of TopicRolls. They are basically a
> way to syndicate lists of types and topics and can be used in
> several different ways. We have thought of a couple of them, but
> most probably other will follow, maybe moving away from OPML
> which is the format which we are currently using.

It would be great to see TopicRolls appearing in a fashion comparable to blogrolls (especially with tools like blogrolling.com to help).
Personally I'd run a mile from OPML -
see http://dannyayers.com/archives/001119.html

[snip re. types]
I'll be interested in seeing what you've come up with for this. Your remark "...we introduced Types as a way to create
relations between posts..." does make me wonder though - ThreadsML offers a way of creating relations between posts using an existing framework for expressing relations, even if you didn't find ThreadsML the language suitable you could still use the relationship framework (RDF). The ENT idea I can see as a neat way of introducing an important bit of semantics into RSS 2.0 (something else I'd run a mile from ;-) but extending this idea further really does sound like there might be wheel-reinvention going on. I hope & trust you'll convince me otherwise ;-)

Cheers,
Danny.
10
Paolo Valdemarin
04-14-2003
08:56 AM ET (US)
Looks like we might be able have some parts of the aggregator up and running by the conference time. We won't be able to participate (unless we win some money within the next few days), but I guess this is not going to be a big problem.

The basic idea is to start showing some practical applications of the protocol in order to have others thinking and possibly implementing.

There are a few interesting things that can be discussed about ENT, besides the protocol.

The first one is the usage of TopicRolls. They are basically a way to syndicate lists of types and topics and can be used in several different ways. We have thought of a couple of them, but most probably other will follow, maybe moving away from OPML which is the format which we are currently using.

The other front is on the aggregator side. Once we start collecting posts and organizing them according to topics, there's something more to do than simply sorting posts using topics. This is why we introduced Types as a way to create relations between posts.

In other words, if a post contains these topics:
  • places:San Francisco, Gradisca d'Isonzo, London, Somewhere in Sweden
  • people:Marc Canter, Ben Hammersley, Paolo Valdemarin, Matt Mower
  • companies:Broadband Mechanic, Evectors, Novissio


We could create relations between all these and all the other ones already existing in a directory, thus allowing to navigate trough posts in a completly new way (btw: this is what our aggregator will ultimately do).

But the kind of relations that can be created between topics and types is still to be completly explored and could probably create some very interesting results, especially if applied to existing archives.
9
Ben Hammersley
04-13-2003
04:30 PM ET (US)
On Sunday, April 13, 2003, at 10:03 PM, QT - Marc Canter wrote:

> sounds like a plan - I'm trying to get either Matt or Paolo to
> show up.
> this is during your mail bot session?

Yes, precisely. There's much intertwingley goodness to be had when you start treating email, and mailing lists specifically, as
just-more-data. I'd wager that in total there is a great deal more meaningful signal in the collected listservs and majordomos of the world than the web. The more technical or complex a subject, it seems to me, the more it gravitates towards old school mailing lists, and the further it retreats from the web. Why this is I'm not sure, but
releasing the trapped knowledge in all those old list archives seems a very noble cause. And to do that, we need something like ThreadsML.
Or I might be talking cobblers. Anyone?
8
Marc Canter
04-13-2003
04:03 PM ET (US)
sounds like a plan - I'm trying to get either Matt or Paolo to show up.
this is during your mail bot session?

>
< replied-to message removed by QT >
7
Ben Hammersley
04-13-2003
09:01 AM ET (US)
I can do one better than that. I'm speaking there on this very sort of thing. I'm planning on talking about ThreadsML (and now ENT). Perhaps making it into more of a discussion type affair would be good? Also attending are some Latent Semantic Indexing people, and the guys from Waypath, so we might be able to touch on a great deal of good stuff regarding fitting threads into ontologies, and representing such.
Personally I think retrofitting existing content into an ontology is the Really Big Problem we're going to have to face sooner rather than later. Might as well start talking about it.

On Friday, April 11, 2003, at 07:54 PM, QT - Marc Canter wrote:
>
> I also suggested a BOAF at ENTCON (Dr. Weinberger is into it) -
> anybody else interested in attending?
>
> - Marc
> =================
>
> ThreadsML never picked up sufficient steam, but I believe that
> it or something like it is needed more than ever. a BOAF at
> Emerging Tech sounds like a great idea. Count me in.
>
>
> -- David W.
6
Matt MowerPerson was signed in when posted
04-12-2003
06:20 AM ET (US)
Hi folks,

I was feeling pretty ill yesterday when Marc pointed me to this thread so I'm just catching up. Also I missed ThreadML before so it's a 106 messages I'm reading!

From what I can see though ThreadML seems to be a good idea and, if it's based upon RSS, an idea whose time has come.

One thing I haven't come across so far is any explanation about why the previous initiative fell short. Can anyone summarise? Are there any lessons to be learned? Have we?

Regards,

Matt

p.s. The ENT spec URL should be

http://www.purl.org/NET/ENT/1.0/

which is it's permanent URL. The URL via my blog is where the document lives right now but the above PURL will always point at the latest version of the spec.
5
Marc Canter
04-11-2003
01:58 PM ET (US)
wow 2 mentions of Blue Oxen in one day - quite a day for them.

I'd like to point to Matt and Paolo's new ENT spec:

http://matt.blogs.it/specs/ENT/1.0/

as much as I'd like to see RDF succeed, it's still pretty daunting and complicated - despite the W3C's upcoming efforts at education.

ENT is an RSS extension and something any software developer can add in very quickly. It would also be 100% compatible with any paralell RDF or XTM efforts. That's KEY!

I propose that "we" use ENT as a mechanism for flowing threads through. It would take an alteration of the current ThreadsML spec - but something well worth it.

- Marc

>
< replied-to message removed by QT >
4
Marc Canter
04-11-2003
01:54 PM ET (US)
Cool.

I'm funneling David's reply - and mine - via this email - onto the QuickTopic site.

This would be ONE example of how a ThreadsML might provide cool new functionality.

I used today - as the day that Matt and Paolo shipped the first draft of ENT (East News Topic)

http://matt.blogs.it/specs/ENT/1.0/

as I believe THAT is how ThreadML will get implemented! 'cause without categorizing and flowing threads into ontologies or facet maps - what's the point?

I also suggested a BOAF at ENTCON (Dr. Weinberger is into it) - anybody else interested in attending?

- Marc
=================

ThreadsML never picked up sufficient steam, but I believe that it or something like it is needed more than ever. a BOAF at Emerging Tech sounds like a great idea. Count me in.


-- David W.

=================

>
< replied-to message removed by QT >
3
Danny Ayers
04-11-2003
01:42 PM ET (US)
re. QT : nifty footwork!

re. ThreadsML

Although I have some reservations about the spec in its current form, it certainly would be great to see some smarter applications appear!
Steve Cayzer has been working in the Semantic Blogging domain recently, and has surveyed what's out there - I'm cc'ing him in the hope he has comments re. ThreadsML.

My main reservation: personally I think the ThreadsML tries to do too much in one place, and runs the risk of the semantics being spread thin (if you see what I mean ;-) In particular I think the cataloguing terms (Topic, hasTopics, categoryOf etc) could be better defined separately from the thread terms (Post, agreesWith, commentsOn etc). The overlap between these two sets and other schema (e.g. the RSS taxo module, the ClaimMaker vocab) could make mixing messy.

Having said that, the way ThreadsML stands in its current form is probably already pretty close to the sweet spot for well-defined/easily-used. If there's a general hubbub of approval to the spec as it stands, I'll happily go with the flow and do what I can to support it in whatever apps I work on.
(just a random thought - I wonder if the Topic side could be linked to the RDF representation of Topic Maps work...that could pull in a whole community...)

btw, there seems to be loads of structured discussion related discussion, see for example :
http://collab.blueoxen.net/cgi-bin/wiki.pl

Evidence that it's an idea who's time has come, perhaps?

Cheers,
Danny.






< replied-to message removed by QT >
2
Steve YostPerson was signed in when posted
04-11-2003
01:02 PM ET (US)
As far as I know, the effort stands at the proposal you referred to, Marc (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq). Can we get agreement on that? If so, it may be just a matter of specifying that more formally and taking the proposal to a larger group for approval. Can someone say how that's normally done, at least for reference later?

This is good timing for me, becuase once I get QT Pro released (a few weeks from now), I want to implement ThreadsML in QuickTopic. Once the standard is in place, there are lots of possibilities -- one I'm thinking of is providing very flexible viewing of any thread through XSL.

Thanks for resurrecting this, Marc. I'd let it lay idle for awhile while working on other things.

Whoops, the proposal is here: http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66
Edited 04-11-2003 01:17 PM
1
Marc Canter
04-11-2003
12:55 PM ET (US)
Hey,

Pete Kaminski just alerted me to the effort and ideas behind something called ThreadsML http://www.quicktopic.com/7/H/rhSrjkWgjnvRq - but I can't find anything since Nov. '02. Discussions also seem to have gone silent on the RSS-DEV list about this idea.

I've been able to find this defintiive statement by Steve Yost:
http://www.quicktopic.com/7/H/rhSrjkWgjnvRq?m1=66&mN=66

and an early article:
http://www.hyperorg.com/backissues/joho-jun17-01.html

a RDF proposal:
http://web.resource.org/rss/1.0/modules/threading/

and an excellent analysis by Ben Hammersley:
http://rss.benhammersley.com/archives/000035.html

there's even a domain - which has been abandoned:
http://www.threadsml.org/

I assume a lot of these thoughts and insights have been beaten to death and discussed (via QuickTopics of course) and that everyone is just sick of it by now. But now that we're about to embark on a whole new thing - thanks to Matt and Paolo with ENT (Easy News Topics.) Having topics in an RSS feed and compatible with RDF and XTM is a great step forward.

Whether it be a multimedia conversation (as I theorized), a traditional discussion forum (use.net, Brainstorms, Yahoo Groups, Slashdot, iVillage, whatever) or something like what SocialText is developing.....

.... having an interchange standard for threaded discussions - forums - would be killer!

We're building new kinds of tools - to create new kinds of communities and man, could we use an interchange standard for threads.

- Marc

P.S. BOAF at Emerging Tech?