RSS history via state transfer

Mark Nottingham created RSS History, in order to help distinguish the various ways in which an RSS feed can be interpreted. A very useful feature, for sure, but I think I have a better idea about how to do it.

If you think of a blog in terms of one agent receiving a compound document containing representations of individual items, the “h:overwrite” semantic should be reproducable simply by telling the receiving agent what resource (item) that data is a representation of; the only possible way the receiving agent can interpret this, is that the more recent representation “overwrites” the older one. In other words, we just need to give the item a URI ( preferably without a fragment identifier, though I suppose it could work with them – I’ll have to think more about that).

Similarly, the “h:add” semantic would be the result of not including the URI, giving the receiving agent no choice but to interpret that data as additional data, rather than replacement data.

“h:none” should be a special case of the overwrite semantic, so that if a single RSS document contains two representations of the same resource, that the “most recent” one overwrites the older one. Of course, this requires that the channel posess some sort of ordering semantics. I’m no RSS whiz, but the only example of this I know of is RSS 1.0 when it talks about using rdf:Seq (sequence) rather than rdf:Bag to contain items. So you’d need to use a rdf:Seq if you wanted a feed like this. Makes sense.

As a proposal, I guess this boils down to using rdf:about/GUID on items when you want replacement (perhaps in the future, i.e. if you don’t use the URI now, you can’t replace later)), don’t when you don’t (or even better, use a different URI), and use rdf:seq when order matters within a channel, even for intra-channel replacement. Oh, and use RDF 1.0. 8-) This has the downside that existing aggregators will likely change behaviour based on the same input, but I don’t think it’s too much of a surprising change. I think the gain in functionality, simplicity, and visibility is worth it, but I’m not an author of an aggregator so I might be missing something.

Leave a Reply

Your email address will not be published. Required fields are marked *