This is an idea for weblog-based group-forming that originates from [Seb's Open Research]
Seb wanted a system where people can categorise their posts and put them in a global index. Automatic "topical, shared blog" generation, powered by TrackBack or RadioUserLand's [multi-author weblog tool]. Or something like that.
This idea sparked the creation of the GroupFormingMailingList in October 2002. The List begat the GroupFormingCommunity a month later.
PhillipPearson, in December 2002, eventually built the TopicExchange, which has nicely solved Seb's problem.
How it works
- You make a post in your favourite blogging tool.
- You classify your post as belonging to a topic, with a plain-English name. Perhaps a description as well.
- The topic gets created somewhere, and given a blog and RSS feed.
- Your blogging tool leaves a link to the topic blog somewhere around your post, so visitors can see it.
- Now, anyone subscribed to the topic (that's you, anyone else who has linked a post to the topic, or anyone who has subscribed with RSS or somesuch) sees this topic in a drop-down list next to the text entry box in their blogging app whenever they post.
This is very similar to TrackBack. Most of it is TrackBack. The cool thing is that is will be easy to use. Currently TB requires you to create a whole new blog for each topic. This sort of thing would require one mega-blog server that would only work accept posts via TB.
[Comments on Seb's blog]:
- JohnRobb suggests that you can do this with categories in RadioUserLand: Seb, why don't you create a category specific weblog on the topic? If multiple people with weblogs want to do the same with the topic, you can subscribe to those category specific weblogs and publish them as a multi-author category weblog with Radio. Very simple.
Read the link above for the rest of it. As he says, this approach is a good bootstrap, but IMHO there are still too many steps required for this to be 'ridiculously easy'. It requires everybody involved to create a new category, and the category 'owner' has to poll all their RSS feeds regularly to pick up the info. -- PhillipPearson
[New post from Seb]
- Of course, one way to see it is that we're just reinventing unmoderated USENET newsgroups - with the critical difference that we're doing away with the politics that cause the group creation bottleneck over there.
Is that what we're doing? Like unmoderated newsgroups, except restricted to blogs and without any restrictions on group creation. I think the original thing here is that the connections should be easy. Easy for bloggers, that is, and hard for spammers. -- PhillipPearson
[More comments on Seb's blog]:
- How about instead of calling them topics or focal points, call them ideas. Subjects, topics, stories, events, these are some of the focal points of group discussion. I believe "idea" is sufficiently broad to encompass all of said types. The subject "banjo in pop music" can be discussed as "the idea of banjo in pop music" and still be an idea.
- I'm dubious of implementing such a good idea in a Radio-centric way. This fragmentation of topics is precisely the rub of the Semantic Web, and while it's possible to reap many of the benefits though other means, holding out will be worth it.
- -- [Eric Hanson]
I don't see why a central server is needed at all. RidiculouslyEasyGroupForming is a great idea, but it can happen using only MeatBall:PeerToPeerSyndication. If you write about a "topic", and so does someone else, then just exchange posts; don't just send them your post, but send them other posts that you have heard on the topic, i.e. route. A network will rapidly form.
This is now exactly like UseNet?, except that it is ridiculously easy to form a new group, and you may as well even reuse some if its protocol, if convenient (I don't know about the UseNet? protocol myself). You don't have to worry about the load on a central server. And there is much more room for innovation.
I would also attach some sort of hop count to each message. I.e. if your group is called "XML", do you really want everything that anyone thinks has to do with XML to come to you? There will be too much traffic. With a MeatBall:PeerToPeerSyndication scheme, you can say things like "I trust Bob's judgement on what is interesting about XML, and I trust his friends , but if you keep going forever there is too much junk. I'll drop everything with a hop count of more than 2". You end up getting a MeatBall:WebOfTrustModeration scheme pretty cheaply.
Hmm. How about if the server is just a Perl script that you can leave on your server. Perhaps a plugin to Movable Type that extends TrackBack?
The important thing to consider here is usability. Everyone uses BloggerApi? clients with Blogger because they can just enter their username and password and get going. To do the same with RadioUserLand requires you to set up three config items and know that the local XmlRpc URL is http://127.0.0.1:5335/RPC2, which is too hard. It's that sort of thing I want to avoid. If it's possible to get it going without that (i.e. with something like RSS autodetection or TrackBack RDF links), that's fine by me.
My own MeatBall:FuzzyCommunity ideas follow a similar course to this, as well as the MeatBall:SyndicatedCommunity idea.
A little interjection before work starts getting duplicated - the topics being described sound very like those of Topic Maps, which is a well-established system (XTM is an ISO standard). Things might get messy using the XTM XML syntax directly, but this stuff can already be represented easily in RDF - maybe best through one of the translations of TMs to RDF schema.
Matt Mower [notes] that this relates to his [BlogPlex] idea (weblog neighbourhoods). He also mentions [XFML]. Thinks we need more metadata on weblogs before it's possible. WeblogMetaDataInitiative?
We've been discussing what we called BlogThreads (very close to RidiculouslyEasyGroupForming, I think, but threads are more explicit) and Shelley Powers' proposed implementation of the server (dubbed ThreadNeedle?) here: http://www.quicktopic.com/14/H/P96CAYje2yc. I made a few suggestions that align with the simplicity proposed here. They're in messages , , and . I especially like the idea in  where the thread server locates the proper thread using HTTP_REFERER information.
sounds neat. I think there are a couple of related ideas here with a few dimensions of variance:
How is the information transmitted?
- The weblog owner decides which threads are shared, and which topics they belong to. Their weblog software can either be a client to some meta-server, or they can distribute threads peer to peer. The latter is standard MeatBall:PeerToPeerSyndication, and is like USENET.
- Or, the weblog owner must have software that supports RidiculouslyEasyGroupForming, but he or she need not decide which threads are shared, or under which topics. The individual posters can make that decision. I don't think this has been discussed yet, but it's a logical intermediate.
- Or, the weblog owner and the weblog software need not even know about RidiculouslyEasyGroupForming. Groups are formed either by posters submitting topics to a 3rd-party server (perhaps using SteveYost's great, easy-to-use idea in ), or by a 3rd-party server crawling known weblogs and looking for connections.
What is the granularity of relationships? Threads or messages.
- Entire threads could be marked as part of a specific conversation.
- Or, individual posts could "point" to other posts to indicate that they are related; the thread relationships could be derived from that later.
Just untyped relationships, or assignment to defined topics?
- We could start with only relationships between threads or between messages, and then later find clusters of related ones and call them groups.
- Or, we could manually attach some sort of "topic" to various threads. Their would be a semantics attached to topics; the interrelatationships between nearby topics could be explicitly represented with a Topic Map.
Assume a central server to host some topics. There can be multiple topic servers, but I don't think this will work with a client app controlling everything. RadioUserLand will need to have an executable part that runs on the server. Maybe on the CommunityServer?
The server has a database which contains:
- Topics: each topic has a description and an ID.
- Posts: each post belongs to a topic. (Should it be possible for a post to have multiple topics?) Each post has a source URL, showing where it came from, because we're tracking blog entries here.
The server generates the following on demand, perhaps caching them or generating static HTML as required:
- Blogs: The last few posts on a topic (SELECT * FROM posts WHERE topicId=foo ORDER BY postDate MAX RESULTS 10). Perhaps do the whole calendar thing as well. [b2] provides all this; it could be used as a front end (note: GPL).
- RSS feeds: the last few posts on a topic.
The server would have some XmlRpc methods:
- blogTopics.createTopic( string topicName ): Create a new topic
- blogTopics.addPost( string topicName, string postUrl, string postId ): This notifies the server that a new post is available somewhere. The server should fetch the document at postUrl and look for the post specified by postId. (This is a vague attempt at security; is it worthwhile, considering it would be possible to fool the server by puttting in invisible text?)
- blogTopics.getTopicList(): Get a list of available topics. (This could be a static file somewhere instead, for speed).
- See http://topicexchange.com/doc/xmlrpc for what the real XmlRpc methods look like.
See also [ThreadNeedle discussion], and [ThreadsML Wiki] (ThreadsML? is a
superset of RSS 1.0).
I'm fairly convinced that ownership (and group ownership) can be well gained implementing features containing facets of GameTheory? .
- what do you mean, exactly?
(with encouragement to post by SteveYost)
Here are some thoughts about the differences between the topic-based model (RidiculouslyEasyGroupForming) and the conversational model (BlogThreads, [(ThreadNeedle)].
They are both good, they aren't the same, and they have different strengths and weaknesses.
Topics are great for aggregate blogs that assemble posts about [city events] or [hiking trails] or some other focused subject.
Threadneedle is better for aggregating a human conversation, whose topic meanders under a named thread.
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).
A wonderful application for RidiculouslyEasyGroupForming networks would be an [All Consuming] companion site that would enable an aggregate blog of book-related posts.
So, one blog that would aggregate the posts on Smart Mobs and Lessig's Code and whatever other books the BlogMob? is reading.
Does anyone want to take a crack at this? I'll be travelling in the coming week, but will have some time after that.
... oh, and we can call it RidiculouslyEasyBookGroupForming? :-)
P.S. Some implementation thoughts:
Use a bookmarklet to catch the ISBN number (as in LibraryLookup?) and then use the mt.setPostCategories? command in the MetaWeblog? API to create a post categorized by "BookClub?" and by ISBN.
Then syndicate and aggregate by category.
Congrats to Phil
on the release of the Internet Topic Exchange! - Marc Canter