Russell Beattie

So I've been exploring some ideas that I figured I'd write about here to see what's being done out there that I don't know about. The idea can be summed up in a phrase: "What's Notes is New Again." Right now blog tools allow you to create a "post" which is usually comprised of just a few fields: title, content, date, and maybe categories or tags. I've seen some other fields like media links as Enclosures (essential for podcasting), geotags for location, and there's been a sputtering effort to add in the iCal namespace for calendaring, but all these seem to be in separate worlds. In other words, you'd have a feed that's generally one thing or another, and not really combined into one thing. What I'm thinking about is a way of looking at "posts" or in RSS nomenclature: "items" as containers for arbitrary data in labeled fields, in a way that can be easily extended and re-used. Sort of like a "note" in Lotus Notes.

What prompted me to write this post was Mike's post about Elle's experiments with "Structured Blogging" which seems to be a similar concept. Also, after seeing the various types of fields that is stored in 37Signals' Backpack service, it seems a no brainer to enable more weblogs to capture this sort of information.

Now I know the "right" way to do something like this is using formal extensions to XML like namespaces, or the already formalized system like RDF. But I'd like to see something even more simple and "backwards compatible." The idea would simply to be able to put in a number of arbitrary field/value tags into any item that could be displayed as text if the aggregator doesn't understand what the fields actually do. In other words, every Item would continue to have a Title and Description, but it would also have an arbitrary number of Fields which look something like:

<fieldset name="Calendaring" refId="http://www.russellbeattie.com/calendarstuff">
<field name="date" value="05/13/2005" />
</fieldset>

Almost like namespaces, and almost like RDF I know - I'm sure it's like I'm recreating the wheel, but this is what makes the most sense to me. Now, one aggregator sees this set of fields and just says "oh, I know how to format this thing" and presents a calendar widget with the date highlighted. Another aggregator would have no clue and just presents the data at the bottom of the Content in Field Name: Field Value.

This is the key difference in this plan - the ability to see the data in human readable format if the aggregator doesn't have any idea how to process those fields. This is sort of how Lotus Notes worked. You could create Forms which would be able to display and add fields of data to a Note. Then you could create Views which displayed all the Notes in various ways organized by the Fields. The thing about Lotus Notes is that each Note could have an arbitrary number of fields, which made it very powerful.

Imagine in your aggregator you could receive not only "Posts" but forms as well. And calendaring info, and images, etc. And this stuff wasn't just HTML formatted inside the Description tag, but actually processable by the aggregator itself. I guess then the Aggregator becomes a Universal Data Reading Client instead. On the other side of the equasion, I currently have a weblog which has only one way to create new items, a button called "New Post" which has just two fields, Title and Content. Now what would happen if I added more ways to create items: "New Calendar Item" and "New Review" and "New Classified", etc. Each one of these extra types of posts would all have Title and Content, but they'd also have fields filled with additional arbitrary information which was included in the RSS also. If your aggregator didn't understand these fields, they could just display them.

So how do the aggregators "know" how to process the fields? Well, they don't automagically - the developer of the aggregator will decide to support some sorts of fields and just display the others. I can imagine some systems building a plug-in architecture which could read the various Fieldsets, but in general we'd all probably just do our best. Sort of how aggregators work right now.

-Russ