Alex Barnett pointed to Nick Bradubury’s vision for attention data in OPML. As might be expected, I’m not sure how much I agree with what Nick proposes. My objections, though, have nothing to do with OPML as a potential format, for attention data or anything else. I think OPML’s grand, and it has many uses, and one of them might even be for attention data, but I think that remains to be seen.

I think that bears repeating. I think OPML is grrrrrreat! It has many useful uses Perhaps even for attention data. What Nick proposes, though, is potentially short-sighted and certainly limited by Nick’s own admitted context, that of aggregator developer.

Let’s take a look at a real-world example - me. Here’s my (slightly outdated) OPML File. OK, lots of feeds, right? And I read something from most of them every week. Here’s a smaller version of just the few feeds I try to read every single day.

Now look at the attention data that AttentionTrust’s attention recorder is recording for me. My online click-attention file currently has more than 10000 rows, and that’s just since 2005-11-16, so about 2 weeks’ worth of data. Here’s a representation of that data. That’s a lot of clicks, but probably not as many as some other users of the extension, or of subsequent tools, will collect. And it’s pretty revealing as well; not this representation, but the data behind it tells a lot about me - a darn site more about me than my OPML file reveals.

Here’s where I think Nick is wrong. Personally, I want the data the AttentionRecorder is collecting to be used, but I don’t want to freight porting my feeds from one platform to another with those additional 10000+ rows of data. In fact, there’s no real reason for my aggregators to know about all of that data ¹. What I want is for my agregator and other tools that pay attention to my attention to know about the aggregation of that data - the information contained therein [if the distinction's unclear - and it shouldn't be - see Data versus information]. Sometime, hopefully soon, there are going to be tools that take the data about what I’m clicking on and analyze it - come up with useful information about my attention that’s encapsulated in that scattered and relatively useless data represented in the link above.

Once we have a way to get that information in a format that can be published and shared, then we’ll see the incredible value we can acheive from the coming attention economy and attention tools. We’ll see benefits from sharing what we’re paying attention to with our partners in commerce, the vendors we do business with. And we’ll see benefits as our tools become more capable of getting us information we want to pay attention to - commercial information, new feeds, whatever. And that’s the information I can agree with Nick on, that we could, and perhaps should, publish alongside (or within) our OPML files that can be moved between aggregators and elsewhere. I want all my aggregators to know about my attention information, NOT my attention data.

If we accept that distinction I think we can agree that we still need a way to handle that data. OPML may well be the right format, and so might Attention.xml, or RSS, or AttentionDataXMLFormat or something yet to be seen. But what Nick is talking about is only a subset of that data, and I think we need to start talking about it more generally. Browsers will (and can right now) collect this data, and so, eventually, will operating systems and email applications and cell phones and word processors. None of them speak OPML any better than they speak any other format, and that doesn’t make OPML the wrong format per se, or the right one. Aggregators are going to have to play here too, since so much of our attention data will be collected there, and I’m beginning to think that all of this means that there won’t be one data format we can use across attention-aware platforms. Perhaps that doesn’t matter, but I, for one, think it’s unfortunate.

We’ve at least begun talking what we want to collect about these attention tidbits (here, here, and maybe here - what have I missed?). Maybe that’s all we can hope for right now. But please, Nick and other aggregator developers, don’t make me move huge files from aggregator to aggregator just to keep them in synch - even transferring all the attention data my aggregators would be able to publish from one to another is too much (except as noted below). And please also, don’t make me import and export that data - subscribe to it. The day is swiftly approaching when aggregator usership will explode, and usage choices are going to be made on the ability to effortlessly keep things in synch across platforms.

¹ There’s another kind of attention data that’s suitable for publication between aggregators, potentially within OPML, and that’s the read-item information that will tell one aggregator not to show me items I’ve read elsewhere. OPML could be suitable for that, though I might argue that an extension to RSS (another format that aggregators already understand) might be more suitable - since it already has a vocabulary for items. Here I don’t really care about the format that much. I’m really just a user of aggregator functionality and have no plans to develop anything on that platform, so as long as it works, seamlessly, I’m largely format agnostic.