Curiouser and Curiouser!

Bill Frisell working with John Zorn again. For us who've enjoyed the occasional blast of Zorn's band Naked City and the post Ornette freedoms of Masada, Masada Guitars is an intriguing prospect. Mark Saleski's review makes the album sound gentler than I'd have anticipated. Blogcritics: John Zorn:... [Dangerous thinking]

John Zorn, yeah!

Aggregator as archives, not only as instant readers..

Dave Winer: RSS readers that work like Usenet readers are a waste of time, imho. Aggregators should not organize news by where items came from, just present the news in reverse chronologic order.

I totally agree, this is why after trying other aggregators I came back to "Radio": it's just like reading a very large weblog updated by several people every hour, it's an activity we are familiar with and the ability that we have to scan titles and relevant information in a page makes this approach much more efficient than having to move from source to source. If an aggregator is meant as a way to take a snapshot of what's going on on hundreds of sources and quicky present it to us, I believe that presenting news in reverse chronological order is the way to go. But I also think that aggregators could be an interesting way to archive content, to let somebody quickly retireve something wrote sometime in the past. Archiving by author, again, does not make sense: most weblogging applications already do that, if I'm looking for something and I know who wrote it, I can simply look on the author's site. There are search engines, which are of course a good way to find information, but not always very efficient. There are cases when a directory might be more useful. We believe that archiving by topic in a directory could be a solution, and this is what we are trying to do. It's not for daily instant reading, it's to archive content. [Paolo Valdemarin: Paolo's Weblog]

I agree with Dave that organisation based upon source isn't a particularly useful innovation on it's own.  But if he means that aggregators shouldn't attempt to organise posts at all (other than by order of arrival) then I totally disagree.

I still use Radio as my aggregator but I am not happy with it.  It's just the most convenient reader I have found to date.  Why?  As I have said before, those readers actually made things less convenient.  For example one, I forget which, offered me the ability to group feeds into an outline structure.  This was good it meant I could keep my general news feeds aside from the feeds of people I know and so on.  But when I clicked on a folder of feeds, it didn't present me with a view of all the items from each of the feeds in the folder.  Now, why the hell not?  This feature alone would have allowed me to dump the Radio aggregator.

Also we are working on k-collector which is a server based aggregator that will group items together from a number of different feeds, but it does that using ENT topics.  This is integrated with our topic roll concept so that if you and I use topics from the same topic roll, our posts will appear together.  Once you see this working (and we hope to show you soon) you can see how powerful this becomes.

Paolo and I have been chatting over some more revisions to the ENT 1.0 spec.  In particular we have come across something that is awkward when it comes to user interface design.

Right now a cloud is identified by a unique URL, e.g.

Any topic from this roll can be uniquely identified as such, however a URL is not a very friendly thing to use in an interface as we have discovered implementing the interface for our k-collector proof of concept.

We're thinking up alternatives and have a number of approaches:

1. Add a description attribute to .
2. Add a description tag to .
3. Add a tag to the
4. Refer to the cloud's definintion for more info.

Options (1) and (2) are more or less the same.  We've been somewhat baised towards attributes in ENT so I guess (1) makes most sense.  It's also very easy to do.  The downside is duplicating the description in every tag.  But I guess nobody has complained about the duplication of the href.

Option (3) might make sense.  We could move all the cloud information here and just refer to it from the 's.  More efficient but it adds an extra burden on to processors.

Option (4) was initially my favourite.  It's probably the right thing to do(tm).  But it's problematic.  We support all different kinds of external resource in ENT including things like XTM which doesn't really have any notion of a description.  In addition it places a huge burden on processors who may otherwise not be interested in the external resource.

For this reason we will probably be adding a description attribute to the next draft of ENT (which will be published tomorrow).