review-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(issue resolutions accepted.)
Line 55: Line 55:
** add this to [[hatom]] as well!
** add this to [[hatom]] as well!
* permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
* permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
 
* add [[include-pattern]] support to allow multiple reviews for the same item to not repeat the item info.
Informative improvements:
Informative improvements:
* Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag.  E.g. what does Food:18/30 mean?
* Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag.  E.g. what does Food:18/30 mean?

Revision as of 22:53, 22 February 2006

Review Brainstorming

There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the brainstorming and ideas resulting from analysis of review examples from real world sites for the design of a simple reviews microformat. -Tantek

Contributors

Copied from reviews-formats which itself was contributed from Technorati Developer's Wiki: ReviewsFormats)

  • Tantek Çelik
  • Niall Kennedy

See Also


Thoughts on a Microformat for a review

Thoughts towards a simple microformat subset of earlier efforts, sufficient to express 80/20 of real world review examples on the Web.

Common review fields

  • item
    • optional:type of item (business, Web page/site, product, event, person, place, file, text)
    • name/title of item being reviewed (string | ["hCard"] if business or person)
      • optional:URL (all additional information should be somewhere else, not in the review itself)
      • optional:image (URL)
  • reviewer (["hCard"]|name|email|URL)
  • review publication/authoring date (ISO8601 datetime)
  • rating 1 to 5 (default max = 5, default min = 1)
  • optional:tags (keyword,rating)*
  • optional:comments (string)

See hReview for the result and evolution of these thoughts on a microformat.

hReview 0.3 thoughts

This iteration of hReview is directly in response to hreview-feedback and hreview-issues. See those documents for more details.

Changes from hReview 0.2:

  • MUST (instead of SHOULD) use hCard for the item description of a business
  • reviewer changes
    • make reviewer *optional* per feedback from Ryan King and Mark Nottingham
    • If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer. If there is no "reviewer" outside either, then use the <address> for the page.
    • MUST (instead of SHOULD) use hCard to represent reviewer information
  • SHOULD use hCalendar to represent an item of 'type' 'event'
    • Accepted. We considered making this a MUST, and postponed it to the next version, based on publication experience with 0.3
  • add one decimal digit of precision to ratings' numerical values.
  • use the "value" construct from hCard (as it is used in "tel" properties for example) to more explicitly markup the rating value when also providing (marking up) the best/worst of a rating. need to also provide an example that does so.
  • add rel-license to indicate the license of the hReview as a whole.
    • add this to hatom as well!
  • permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
  • add include-pattern support to allow multiple reviews for the same item to not repeat the item info.

Informative improvements:

  • Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. what does Food:18/30 mean?