aggregate-review-brainstorming

Ideas for how to support aggregate reviews via microformats.

Common themes amongst examples (that we might want to support)

• Aggregations of reviews always contain these two elements:
  • the number of reviewers
  • the average rating

• Other elements that occur in the example set include:
  • the number of reviews for each rating (i.e. 10 5-star ratings, 7 4-star ratings, etc)
  • recurring themes about the entity being reviewed (i.e. "romantic restaurant" or "love the chicken mole").
  • who are the reviewers (i.e. "critics" or "users"). Some sites (i.e. Rotten Tomatoes or GameSpot) have multiple sets of aggregate reviews to cover both critics and users.

• In addition, some elements already present in the hReview schema exist in aggregate reviews as well:
  • review summary/description
  • most recent date reviewed

Proposal discussed over IRC

What is the proposal?

• Define a new microformat for aggregate reviews (root class name "hreview-aggregate").
• The format will contain only value (the number of reviews) with a new property "count" and embedded hReview properties that contains details like the average review score, summary, and a reference to the object of the review.

This proposal should be written up on a separate page as a microformats draft, e.g. hreview-aggregate.

Why was this proposal preferred?

• Creating a new uF rather than extending hReview doesn't require branching the spec for hReview and provides clean separation in case we want to extend the new format to include other data in the future
• Supporting only the number of reviews (rather than scores per rating, etc) is probably sufficient for 80% of sites with aggregate reviews.

Other proposals suggested

1) Do nothing. Aggregation must be done by the microformats parser

• Pros: Doesn't require any change to the existing microformats definitions
• Cons: Very difficult for parsers. Reviews for a single entity are usually not limited to a single web page (there are typically no more than 5-10 reviews per page), so aggregating this data would require the parser to figure out which pages to crawl to assemble the aggregate scores.

2) Extend existing hReview format to include "reviewcount"

• Any hReview that contains a reviewcount field (which denotes the number of reviewers) would implicitly refer to an aggregation of reviews. The rating would correspond to the average rating of all individual reviews, summary/description refer to a summary of overall sentiments from the reviews, date refers to the most recent review's date.
• Pros: very simple addition to the existing microformat
• Cons: Mild overloading of what an hReview contains -- a review can now correspond to a single user's review or an aggregation of user reviews.

3) Define a new microformat type for aggregate reviews

• This type could contain the staples -- average review score and number of reviewers -- as well as some of the other sometimes-used features listed in the "common themes" section earlier.
• Pros: robust way to mark up many elements of aggregate review information
• Cons: some redundancy with hReview. Extending hReview might be sufficient

4) Do not use hreview classes in hreview-aggregate

• This causes a collision when hreview includes an hcard that contains review aggregates per google specification http://www.google.com/support/webmasters/bin/answer.py?answer=146645 . In that case, the hreview has its own rating, and a second rating imported via the include pattern.

Currently Yelp implements review aggregate as an hreview-aggregate block that include the entire hcard inside it, and the aggregate rating. Importing this hcard from an hreview using the include pattern, imports the rating as well.

• review-aggregate can be included INSIDE hcard block, or can surround that block.
• review-aggregate can point to a self contained hcard (include pattern):
  • Without repeating any of the information in the hcard
  • Without including empty links, example <a class="item include" href="#my_business_hcard"></a>
  • Without including links with duplicate redundant information that is part of the hcard, example <a class="item include make_me_invisible_to_user" href="#my_business_hcard">Business Name</a>
  • Without adding listing information, such as the type of listing: <span class="type">business</span>.
  • Without using non-semantic HTML, such as object tag.
• An hreview should be able to safely import an hcard that may contain hreview-aggregate without name collitions especially the rating tag.
• An hreview should be able to safely import an hcard that may contain nested elements of hreview-aggregate, such as count and average rating, without name collitions. If this is not possible, pages will have to default to non semantic HTML, and markup that contains a lot of hidden content, making them less accessible.

See Also

• Aggregate reviews: examples - formats
• hreview-aggregate
• hReview