A Review of hReview

microformats may well represent a path from where we are today to the [lowercase] semantic web. If so, one of the first waypoints along such a path could be the emergence of aggregators capable of taking advantage of suitably marked-up content.

Applying a 'microformat' approach to tagging, Technorati introduced the rel="tag" approach to marking-up tags. Technorati also supply the corresponding aggregation service, e.g. see posts tagged with microformat. Given this minimalist approach to tagging, the hReview specification comes as something of a surprise. It seems to represent a format developed independently of the environment in which it is most likely to be used.

The rel="tag" approach makes a major, simplifying assumption. This is that the tag refers 'to a major portion of the current page (i.e. a blog post)'. I am assuming that it could apply equally to a blog entry in an RSS/Atom feed. Thus an aggregator can associate a tag with two pieces of metadata obtained from its context, namely:

• title: the title of the web page/blog entry
• permalink: the URL for a web page or the 'alternate' link for a blog entry

This approach can be extended in a minimal way to support reviews, all that is required is:

• review: a mechanism to indicate this web page/blog entry is indeed a review.
• review-target: a mechanism to identify what is being reviewed.

The first requirement could be handled with a tag. Obviously not the hreview tag itself, but maybe a this_is_an_hreview_2(*) tag. I've added the '_2' because clearly this doesn't represent an hReview in any formal sense. With such an approach the underlying assumption is that the review is the enclosing web page/blog entry. However the hReview specification wants to identify the limits of a review far more explicitly by having an enclosing element with a class="hreview" attribute. Although this permits multiple reviews per web page/blog entry, it seems to raise the bar unnecessarily.

The second requirement is more complex. The hReview specification says that a "universal object identifier" is out of scope. I can understand the reluctance to get into the quagmire of trying to define a universal identification scheme, but it does seem essential to the entire process. Furthermore a 'good-enough' solution to get things started would appear to readily at hand: by adding rev="review" to a hyperlink, a web page/blog entry indicates that the destination of that hyperlink is the subject of the review. The linked page SHOULD exist and it is the linked page that identifies the reviewed item. The link label provides an optional human readable version, e.g.

<a href="http://www.imdb.com/title/tt0083658/"
   rev="review">Blade Runner</a>

<a href="http://www.amazon.com/exec/obidos/ASIN/0345404475/"
   rev="review">Do Androids Dream of Electric Sheep?</a>

<a href="http://developers.technorati.com/wiki/hReview"
   rev="review">hReview</a>(*)

If one wanted to pursue the tagging parallel to its own English-contorting conclusion then you could use rel="review-target" instead, thanks to Edward O'Connor for putting me straight on this.

Obviously reviews of the same item should link to the same page. Providing a general purpose solution to this problem is not trivial. However offering a set of conventions that cover a large percentage of cases is very much easier, especially if we are prepared in the short-term to single out and use indexes such as Amazon and IMDb. Looking forward, some of the 'value-add' of an aggregator would be their ability to identify 'related' review items.

The hReview specification goes on to detail a good number of the components typical to a review, including a star rating scheme. All of this builds on other microformat work where possible. For example the reviewer is identified using an hCard. But it also seems to be reinventing some mechanisms. Permalinks are implemented by using a rel="self bookmark" attribute on a hyperlink that exists somewhere inside the class="hreview" element that points back to itself. While this opens up publishing reviews in simple web pages, it seems overkill for blog entries where a permalink mechanism already exists.

Obviously we all expect 'review' tools to be folded into blog authoring software once a consensus emerges. For example a separate field to input the name of a film/book/album that determines and validates a 'universal object identifier' before the review is published. See Alf Eaton's rvw! tool that posts reviews to del.icio.us for a taste of things to come. Nevertheless I can't help but think that I should be able to trivially publish a review today with my current blog authoring software if I'm prepared to add a few angle-brackets here and there. By way of experiment I have generated an example of a minimal hReview according to the approach outlined above. I'm not sure I would be able to do the same thing with the proposed hReview specification except with considerably more effort.

---

(*) obviously this post contains components sufficient to represent a review.