Our echoes roll from soul to soul,
And grow forever and forever.
Blow, bugle, blow, set the wild echoes flyingfrom Lord Tennyson’s “The Splendor Falls”
If one could typographically represent a blur, then that’s what I would use now to annotate the Echo Project – an online, collaborative, and extremely fast paced effort to define a conceptual data model of a weblog, and then to define politically neutral interoperability functionality, such as weblogging API and syndication format.
The effort has had some discussion in weblogs, beginning with Sam Ruby and continuing elsewhere, but much of the work has occurred in the project wiki, a collaborative editing environment.
One only has to look at the change log to see the number of edits to realize that this is not an environment for the cautious, the tame, or the wiki-challenged (or for those who want to sleep or eat, either). I’m not necessarily cautious or tame, but I do raise my hand for being wiki-challenged. Still, there are points that are solidifying out at the wiki, and I thought to duplicate these here in a format that, if nothing else, will help me understand what it’s all about.
The motivation: (also see wiki:Motivation) I don’t think there’s a one of us who enjoys the battles about weblogging APIs, or RSS, or import/export between weblogging products. Though it is the techies who have to deal with the specifics, these discussions impact us all. Every time a battle rages, we have to stop what we do, which is writing our weblog essays and entries, and add support for yet another button, link, or must have dohicky.
We have to support both RSS 2.0 and RSS 1.0. We have to be able to move our Blogger posts to Movable Type, and our MT posts to pMachine. We have to support comments/trackback/RSS/whatever, because people want to respond, comment, suggest, rant, praise, read, and read more easily.
Still, there are the webloggers, or personal journalists, or what have you that don’t and won’t support these things. They make their pages by hand, eschew comments, and answer with “track who?” This effort doesn’t impact on them, nor should it – the motivation behind this effort isn’t to create a jail about what we do, and how we do it. It’s to provide guidelines for the toolmakers so that all the tools we use, regardless of the tools we use, work together.
The conceptual data model. The question really is, what pieces of data are mandatory in order to meet the needs of a weblog entry? Cutting through the tool specific needs, the group seems to have settled on the following data items and their associated definitions:
Author: There is exactly one Author of an Entry, and that Author is identified by a non-empty name and an optional URI of a person, organization, or system. (A UniformResourceIdentifier (URI) is a short string that identifies a Web resource).
Permalink: The persistent URL for the entry on the Web. There is some debate still going on with this, but looks like ‘permalink’ is really being redefined to be a unique identifier of the weblog entry; and that both a URL and a URI (Unique Resource Identifier) will be required. For instance, this weblog entry has a URL for the individual item (page), and also a post or entry identifier, which would be the URI.
Publication date: This is the date the entry was “published”; the date used to decide where the entry goes in Movable Type and Blogger. The use of the weblogging tools is, I’m assuming nothing more than a reference point. This definition could use some work, but the consensus seems to be heading towards the date that the blogger specifies the entry was published, not the tool and not an automatic timestamp.
Content items: There can be more than one content item and associated with each is: media type (i.e. JPEG, MOV), language (i.e. ENGLISH), and the actual content. There was at one point debate that a welog entry doesn’t have to have any content, but I think that got shot down.
There’s discussion still continuing on these items, but it does look like we’re starting to see some stability. Someone even created an example data page, and as this shows, the only items still being debated are having a last modified date, and that URI of the entry (itemid). Additionally, someone else created a entry model that seems to have captured all the data being discussed, not just the required. If you’re not a techie and want to see what’s happening in a nutshell – go here.
Now, these are the required items, but not the only items. However, the other data items are considered extensions, and therefore optional. This includes:
license – copyright of item (see Creative Commons)
security – PGP Key
metadata – title, subtitle, summary, optional timestamps, version id, and all contributors (in case there are additional authors)
I’ve only quoted the extensions where consensus has been reached. There are other efforts.
Now, what’s next? After the data is agreed on?
Well there’s a Road Map that details what’s to happen. Taking a snapshot, it says:
- Decide on the conceptual model of a log entry. ConceptualModel
- Decide on a syntax for this model. SyntaxConsiderations (You are here.)
- Build a syndication format using this syntax.
- Build an archiving format using this syntax.
- Build a weblog editing protocol using this syntax (the Echo API).
What does this mean to you, the weblogger? Especially if you’re not into the technology? Well, if all major vendors of weblogging products– and that includes aggregators, weblogging tools, weblog search and popularity sites – buy into this the following could happen:
– Syndication Both RSS 1.0 and RSS 2.0 would be replaced by the Echo syndication syntax, and you would only have to provide one syndication file. In addition, aggregators would only have to code to one syndication format. If there’s any pushback here at all, it’s that the tool vendors will most likely want versioning on this process, as well as some slow down – none of them wants to spend their lives recoding for daily updates.
– Import/Export All weblogging tools would support the same import/export format, which means you could easily move between different versions of weblogging tools. To my friends in the audience moving from Blogger to MT or other tools now – your job would be much easier.
– Common API All weblogging tools and perhaps peripheral tools would support a common API. This means, at a glance, we could post trackbacks to all weblog posts regardless of toll. But more, this also means that you could use any weblogging tool front end to post weblog posts to any weblogging back end. This opens the door to a new set of tools, as well as new technologies to work on top of them – audio/video posts, posting from email, posting from your phone, and so on.
This is the biggie. This is the grand banana. This is where the rubber hits the road. Here’s a scenario for you: you’re on a road trip and you’re writing to your desktop weblogging front end tool (someone else is driving we hope). You put the post in send mode and when you computer finds a passing WiFi signal, quick as can be, your entry is posted. Or don’t bother with the computer, post with your cellphone. Of find a kiosk at a rest area along the way, and send a post, annotated with your map location.
Doesn’t matter your tool – works with all of ‘em.
Of course, this is all supposing that our fictitious weblogger is a wee bit obsessive, and not that any of us are – not us – but it is fun to think of the fanciful situations in which a person could post, isn’t it?
Mine is that I’m in a deep submersible, hunting the Colassal Squid, and I’m blogging the encounter just as I’m about to be swallowed. No! Wait! After I’ve been swallowed!
“May be quiet for a while, I was just swallowed by a squid…”
