Article Opinion <a

 
Hallo.! Gutes Neues Jahr 2008.!

test bugaga

Steve, Adina

Currently ThreadNeedle is just the immediate levels of a trackback. Pulling in their associated comments might be too much, but it is a good idea. For this to work we need to be able to access the comments for a particular thread without having to scrape the HTML. We probably could use MT's code, but a better approach would be to have comment's perma=linked, and then return comment links with the RSS associated with each person's post.

It's a start, and what we have now requires little or no work on the part of the person having the conversation, which is what I was hoping for. Still, there is a requirement of TB support.

Adina, agree with your assessment on topic and threadneedle. One is subject, which can have many conversations; the latter is a conversation, which could range over many subjects (usually only one, though).

Steve suggested that I crosspost some thoughts about the differences between the the conversational model (ThreadNeedle) and the topic-based model being discussed in RidiculouslyEasyGroupForming Networks.

They are both good, they aren't the same, and they have different strengths and weaknesses.

Threadneedle is better for aggregating a human conversation, whose topic meanders under a named thread.

Topics are great for aggregate blogs that assemble posts about city events, or hiking trails or other specific subject.

A topic-focused blog won't get you a human conversation (that would be ai-complete). A human conversation won't get you a subject-organized index (not without editing after the fact).

The original post and some more thoughts on the topic are here.

Edited by author 01-12-2003 04:26 PM
Reasonable concern; a tool that takes a savvy person an hour to install probably won't get critical mass adoption yet.

The LazyWeb seems to be working pretty well, though.

* Nice plug-ins get integrated into MovableType, Radio, and other tools.
* Hosted services help those who want less complicated software they don't have to install.
* Bookmarklets provide one-click access to blog features.

If ThreadNeedle works, even as a demo for the cogniscenti, the LazyWeb will move the project forward.

"With enough eyes, all features are shallow" -- Clay Shirky

Adina, I agree that something that approximates real-world social networks, in that a disrupter can be ignored by the group who adhere to their conventions, is useful.

But that's not the problem I see here. My concern is that someone who'd ordinarily be welcomed into the conversation can break the thread by not adopting the technology. Even people responding to her who use the technology can't repair the thread -- every link is important. So in a situation like this, I think it's essential that the technology be extremely easy to adopt for the non-technical person.

Shelley, does the blogthread engine capture only trackback entries or can it also be configured to pick up comments?

Could a comments engine be modified to support thread discovery also?

- Adina

Steve, I think this may be a feature, not a bug. If a post in a thread is pathological (trolls, flames), it stops propogating. Threads die when participants stop participating.

Individual-driven moderation is a core difference between blogconversation and usenet.

This may have an opposite result from usenet anarchy. Usenet's openness makes conversations vulnerable to its most aggressive and crazy members. Blognet's decentralized control may make conversations more controlled, but more closed, because it's easy to ostracize pathological posts, or posts expressing strong differences of opinion.

More like village, for better and worse.

I haven't yet read all the way through the posts on Shelley's proposed architecture to understand exactly how this would work.

> If people don't want the functionality enough, then they
> don't need to use it.

The thing is, I think we (blog authors) are assuming that it's really the *readers* of the blogs that want the blogthread function. And these readers are foiled if any of the bloggers in a chain doesn't use it.

> As to the question about how will people see this stuff? There's
> two specialized RDF-to-XHTML pretty printers (one for PostCon
> and one for ThreadNeedle) that someone calls passing the
> appropriate rdf file as part of the URL. These pretty printer
> pages (PHP to start, then JSP, eventually CGI) display the Post
> Content information or the ThreadNeedle thread. How this page is
> called is up to person -- they can add a link within a template

It sounds like blog readers will usually need to click a link to separate pretty-printed XHTML page to see if there are any blogthread links. Yikes.
I'm monopolizing as usual here. Any comments from the other seven subscribers?

Steve, this is a modular app -- anyone can write a mighty bot if they want, pull stupid bot, put new bot in.

If people want PostCon and/or ThreadNeedle functionality, they're going to need to read the docs in how to use it, and install it and any necessary libraries. That could take up to an hour. If people don't want the functionality enough, then they don't need to use it. I'm not being defensive here -- just very matter of fact. I'm learning that sometimes you can't please the people no matter what you do, so don't waste calories you don't need to.

Making the bot smarter won't make the install easier. You still have to install the apps, read the docs, make some tweaks.

Now with the SOAP interface and open API, no reason an app can't incorporate the use of basic PostCon/ThreadNeedle functionality; apps such as MT or Radio or whatever; then the users won't have to do anything other than installing the outer app. But I can't tell Ben and Mena or Ev or Dave that they have to incorporate this.

(It wouldn't take much for anyone familiar with the blogger api and Radio's stuff to be able to wrap this. Still, someone will have to download it, install it, and read the apps for how to make it work, wrapped or not.)
As to the question about how will people see this stuff? There's two specialized RDF-to-XHTML pretty printers (one for PostCon and one for ThreadNeedle) that someone calls passing the appropriate rdf file as part of the URL. These pretty printer pages (PHP to start, then JSP, eventually CGI) display the Post Content information or the ThreadNeedle thread. How this page is called is up to person -- they can add a link within a template (the rdf file will have consistent naming based on web page with addition of pstcn or thrdndl qualifiers -- 000345.htm, 000345pstcn.rdf,
000345thrdndl.rdf using MT scheme.)

No reason why you all can't modify RSS files to add this in, except that it's outside the scope of RSS. Still have to have bots to traverse the URLS, but it might be easier to get people to modify their RSS templates. If no one uses the ThreadNeedle functionality of PostCon, I'll probably just pull it someday. But it's the PostCon app and file that's of interest to me -- ThreadNeedle is just another consumer of the data.

Still, I'm pretty sure I'll get users of the app. It's not going to be that difficult to install -- no more difficult than putting in a MT plugin.
As for your comment about a bot looking for the markup in the file, some confusion here, which was my doing. I'm not modifying the HTML of the source of the weblog posting or the static web pages. I'm building a separate RDF file. I'll be using MT tags to build this file, possibly, (might be using the MT API directly), but not embedding anything other than links (link to the associated RDF file, and a link to the pretty printer to see the PostCon data if they person wishes). There will be no RDF or markup contained in the XHTML or HTML page, per RDF group recommendations, and per XHTML validation specifications. If you scrape the page, you'll have to use a traditional HTML scrapper, find the post or relevant material and pull the links.
>
>
< replied-to message removed by QT >

Thanks for the further explanation, Shelley.

I have to say I'm concerned about the fact that this requires a non-techie to do an hour's work, and that if not all thread participants do it, the thread breaks. I hope I'm proven wrong, but it would be contrary to my experience with social apps: if a new technology must be used unanimously to be effective, it's very hard to get the necessary momentum.

For this reason, I'd like to at least allow for a backup approach: a "mighty bot" searches the blog content itself for the special markup (the one you'll use to generate the PostCon RDF) and builds the thread. So the smarter the bot can be, the less the average user needs to do technology-tweaking (not everyone gets the same thrill from it that we do :-).

One more question having to do with the special markup: how will readers of blogs know there's a blogthread?

Feel free to defer answers until your book is ready (and good luck with that).