Hmm. I wonder if another way of thinking of this is a “world of ends” type argument with the data-format playing the role of the network-protocol and programs playing the role of the “ends”.
The SemWeb argues for smart protocols (ie. semantics in the file-format) whereas the SynWeb argues that semantics belongs at the edges : in the programs that produce and consume them.
The OPML format doesn’t know or care whether it’s carrying a playlist, a blogroll, a blog, a subscription-list etc. It just concentrates on allowing the data to be moved from one program to another. Meanwhile, the OPML editor is continuously being upgraded to know how to get more “meaning” from the outlines it creates.
Why is it “better” for the meaning to reside at the edge?
a) edge points can be upgraded individualistically. If I want OPML to represent my attention data I just have to upgrade to the new version of FeedDemon which will support this. If I want to upgrade to a new version of a specially crafted Attention RDF I have to get the whole network to buy-in.[1]
b) The corollary of that is that if you’re crafting a model like Attention RDF, it’s really important to get it right. Because upgrading is such a pain. On the other hand, it’s far less important to get attention in OPML perfect from the start. It can be continuously tweaked with new releases of the software.
This again reflects on the question of “applications”. OPML as a format is worse than Xoxo or some other XML. But it’s gonna be the winner here as long as Dave Winer can keep up the development momentum in the OPML editor and the rivals don’t offer a compelling alternative.
Les Orchard writes a great concept demonstrator but then abandons it. [Danny] does a lot of coding. But because [he's] focused on putting the semantics into the protocol, [he does’t treat his] programs as the primary vehicle for getting his meaning into the world.
If I want to use Attention RDF as a user, what do I do? Wait around until people have thrashed out the spec on the wiki and then install a very generic RDF database and query language? Why wouldn’t I rather follow regular updates of an existing, already useful tool, which is promising to add this functionality in small sips over time?
[1] I recognise the usual respost : about atomicity of SemWeb tags which means it isn’t an all-or-nothing thing. It’s just that I don’t see that this actually helps here.
For example, what would be an incremental roadmap for geting to widespread Attention RDF adoption?
We can’t say “well, we’ll roll out the att:readtimes tag to begin with, and then once people have started using that and seen the benefits, we can add att:lastread.”
But that’s exactly what a program-oriented SynWeb strategy can do. “We’ll start with ‘rank’ in the next version of the code, and then go from there.
In an earlier comment, I'd said something to the effect that there was an 80/20 rule. If 80% of potential users were satisfied with a format, that would make for a viable standard.
Danny asked :
There should be plenty of data points, but thinking about it they’re rather hard to pin down.
So here’s an interesting one I thought of : 8-bit ASCII - where the second 128 chars are indeterminate and available to be adapted by whichever country or special interest that wants them. There’s lots of incompatibility as people try to pass files containing accented vowels from one country or operating system to another. But ASCII is a phenomenally succesful standard despite all this potential for error. Most of the time, most people, stick within the working subset.
Danny also wonders about Atom :
It’s hard to predict e.g. whether Atom will totally supercede RSS 2.0 or fall by the wayside itself
I don't really have a strong intuition about this either. My guess is that Atom will do well in the things where it doesn’t compete directly with RSS, such as the API. And Atom Syndication will be parasitic on the degree to which people buy-in to the Atom community for these other reasons.
RSS (in some mangled form) will become core to MS, and will be with us for a long time. Aggregator writers will keep finding work-arounds that make RSS do anything that Atom can do.
No comments:
Post a Comment