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

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.

But again, this is all data, you're just extended the search paramaters. Geography, member of FOAF file, whatever

Whatever

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

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?

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.

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

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?

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

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

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?

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

Edited by author 05-07-2003 12:01 PM
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

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.

Edited by author 05-07-2003 06:51 AM
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.

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