What’s needed in a review microformat

by greg on April 27, 2005

I’m following Tantek Çelik’s proposal for a review microformat with interest. If I was in the position to implement this, I’d happily participate. Since I’m not in such a position at the moment, one comment from the sidelines: any microcontent format worth its chops needs to include a clear specification of the rights granted by the original owner, and if these rights are for sale, specifies the amount and means of payment – or at least a pointer to that information. Without the accompanying rights and payment information, the reviews microcontent format will be subject to the same Schwimmeresque copyright problems that plague RSS feeds as a whole.

Reviews are a particularly valuable asset, since their value grows rapidly with aggregation. The value of a set of reviews rises faster than the number of reviews in that set – ten quality reviews of an item in one place are exponentially more useful than a single review. Quality reviews attract traffic, bubble to the top of search engines, and help their readers make informed buying decisions. Reading reviews moves a person one step closer to a purchase. Online merchants are therefore willing to pay good money to be a click away from where those reviews get read. No wonder Tantek’s so interested in doing this quickly – it’s potentially a huge source of income for Technorati. A consolidated set of reviews from across the blogosphere? Ka-ching! I don’t even need to mention this data’s value to market researchers.

This is a very, very smart idea on Tantek / Technorati’s part. An aggregated set of reviews would be super-useful – look at how much I use Google’s aggregated movie reviews. In fact, I’m looking forward to its development. However, it’s imperative that Technorati set up structures that enable profit sharing, and they should take a lot of heat if they establish a standard that doesn’t clearly respect a reviewer’s right to restrict their reviews’ usage or ask for a cut of the profits. Advertisers pay billions for well-qualified traffic – which makes review aggregation without compensation nothing less than exploitation. I’m not saying the aggregator shouldn’t be entitled to a share or even the lion’s share of the profits; they’re providing an essential value-add by collecting, aggregating, and hosting the data. But payment must be made to the participating content producers.

My thoughts on how to do this simply: extend the rel=”license” tag to include commercial uses, and have the URL referenced by the rel=”license” tag contain the publishers’ terms and conditions. These terms and conditions could just be plain text, or they could be placed in a microformat of their own – perferably one that’d allow a licensing contract to be set up with a simple computerized handshake, with no need for immediate human intervention. To allow the licensing microformat to be developed after the review microformat, and to ensure ‘bots looking for free content don’t have to go to another URL and parse a licensing page, the entire review could be encapsulated in a <span id=”notfree”> tag. Similarly, content designated noncommercial could be encapsulated in a <span id=”noncommercial”> tag. Once this is done, the challenge becomes one of normalization, so the data can be easily aggregated – which is why a microcontent standard for reviews should support a series of id tags for identifying key data fields: id=”partno”, id=”manufacturer”, id=”person”, id=”artist”, id=”title”, id=”partname”, id=”placename”, id=”address”, id=”city”, id=”time”, id=”event”, id=”director”… that ought to cover reviews of restaurants, plays, movies, events, individuals (dates, maybe?), consumer products, apartments, neighbourhoods, cities, and what-have-you…

{ 1 comment… read it below or add one }

Sean O'Rourke April 27, 2005 at 10:09 am

I have been thinking about this for some time, so it is cool to finally see it discussed. While it would be great for publishers to have a profit-sharing, I think the more likely scenario is traffic-sharing, which leads to indirect profit-sharing. A few of the challenges of automated profit-sharing:

1) Network Effect – or lack thereof. If implementation/negotiation is difficult, aggregation will fail the ‘critical mass’ test.

2) Source Quality – traffic-sharing will attract some spam over time, but profit-sharing could attract a flood of spam from Day One.

3) Source Issues – aggregators in some countries could be prohibited by law from paying publishers in other countries, for example.

4) Google – Froogle already aggregates reviews, and Google is none too keen on licensing, which could shape the aggregation landscape.

http://froogle.google.com/froogle/reviews?hl=en&fq=ipod&cid=919942312d354c8b

All of this is not to say you could not have the profit-sharing option, but it could eliminate the automated discovery and inclusion of sources. Who knows, perhaps that is the natural progression, and it is the automated crawling of un-reviewed sources that is not natural in this case…

However, if it turns out that traffic-sharing is the natural progression, there is still plenty of room for publisher control of content aggregation. Specifically, I’m thinking of a character limit on the main review section, and perhaps an optional no-aggregate attribute for each tag, for starters.

But no matter if it is profit-sharing or traffic-sharing, you are correct to highlight the key issue: both sides need to have the tools to negotiate a win/win aggregation relationship, of this is simply not going to work.

Leave a Comment

Previous post:

Next post: