More on attention formats (and OPML namespaces)
It was great to see Nick Bradbury start to talk about the same idea I was talking about earlier; a discussion about the attributes of attention we’d like to see collected:
“What I propose is that aggregator users and developers have an open discussion about what specific attention data could (and should) be collected by aggregators.”
To be honest, however, I was hoping for a less format-centric discussion of the issues than one centered around the assumption that OPML is the format of choice. Nick’s looking at this problem largely (though not exclusively) as an aggregator developer, which is only natural, since, um, he is one. And Dave has a valid point when he writes:
“The important thing is the ideas are now in circulation and we’re talking about pragmatic applications for attention that are possible today.”
All this is true. There’s tremendous value to be gained simply by analysing the attention data that our aggregators collect about us. What feeds do we read most often? When did we start or stop subscribing to them? And this is a set of metrics that’s already known and (with a little bit of work on what aspects to collect) acheivable now, or in the near future.
But I still maintain that this isn’t the whole attention story, and that as users and developers, by heading down this path without considering other needs we’re settling. It’s not that I believe that OPML is an unacceptable format for collecting attention data. In fact with Dave’s agreement to revisit the OPML Spec with regard to namespaces, I think OPML could provide a practical, if not elegant, place to collect that information. My concern is more that everything I’ve seen concerning OPML collection of attention data seemingly stops at the feed level. That’s only half the story. Heck, that’s less than half the story!
Focussing entirely on feeds is an understandable tack to take for Nick, whose job revolves around them, or Dave, who lives and breathes RSS. But as much as I love RSS (and I do dearly love RSS), my interconnected life extends far beyond the feeds I read. Even within the aggregator, ignoring the clicks loses much of the attention data I’m constantly supplying to my information collector of choice. Probably at least a 3rd of the information I read as a result of the feeds I subscribe to are contained in the links I click on from within those feed items. When we focus on just the feeds I read and how often I read them all of that information is lost. And that doesn’t even include all of the attention data I’m already giving up to Google, Yahoo, and their multitudinous search-brethren. Where’s that data going? Obviously Nick can’t help me with that. Can OPML?
As Joshua Porter says:
“In order to make attention more efficient, I need better answers in the form of helpful systems, like recommendation systems, and I need them yesterday.”
but basing those recommendations on just what I look at in my reader only captures part of the attention I’m paying, and that’s a huge loss. Dave’s right when he talks about practical solutions available now, but there’s at least one other existing model for this data and it’s collection (and yes, Ed, I know that AttentionTrust.org is neutral on the format question – well, at least the organisation is, if not some of its leaders).
I’m not specifically against OPML as the attention format, but here’s my root question: what makes OPML right for collecting all this data? We’ve heard that it’s already supported in aggregators, but as Danny Ayers mentions in the comments to Nick’s post; “existing aggregators already support RSS”. What that means to me (and I’m no aggregator developer, so I certainly could be wrong) is that aggregators already support XML, and if we can settle on a base format that’s agreeable to most then implementing it shouldn’t be that hard. So leaving aside existing support, what else makes OPML the right format to use? We’re already 2 or 3 steps down this path, and as I quote Dave saying before “one way to do something, no matter how flawed that one way is, is better than two, no matter how much better the second way is”. We have the opportunity to spend a little time making sure OPML is both the first and best way of doing this, or to define a format that is.
So can anyone else tell me – what makes OPML right?
RSS 2