This article is a stub. You can help the microformats.org wiki by expanding it.
<entry-title>h-review-aggregate</entry-title> h-review-aggregate is a simple, open format for embedding review information (of products, services, businesses, etc). Whereas h-review is intended for an individual review, h-review-aggregate is meant for summary information about a collection of user or critic reviews about an item.
- Per CC0, to the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2021-07-24, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0.
Here is a simple example showing aggregate review information for a restaurant:
Examples in the wild
Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.
For the stable features of this document, substantive issue filing, resolution, and edits may be done by filing an issue and discussing them on the issue and on #microformats #microformats chat with a link to the issue.
Because this is primarily a vocabulary specification, very few issues beyond the list of vocabulary have filed or required any lengthy discussion. If such a non-trivial issue arises in the future, use the microformats2-parsing change control process to resolve them.
In general, non-vocabulary related features or requirements should be avoided in this specification, e.g. changes to microformats2 syntax must be proposed as microformats2 parsing specification changes using the microformats2-parsing change control process.
Beyond that, the following requirements must be met for adding or moving features (e.g. properties and values) to proposed, draft, or stable:
- Proposed features must provide documentation of what specific real world use-cases they are solving, preferably with a link to a step-by-step user scenario, e.g. demonstratable using existing non-standard / single-site / single-implementation tools.
- Draft properties must in addition be published and consumed in the wild on the public web, demonstrate solving the use case for which they were proposed, and should provide citations of real world public web sites publishing and (other sites) consuming them, interoperably.
- Stable features (e.g. Core Properties) must in addition be published and consumed in the wild on multiple sites by multiple implementations (3+ different sites and implementations for publishing and consuming). When a draft property reaches a critical mass of deployment by numerous sites and implementations (far beyond 3+), due to network effects and backward compatibility considerations it effectively becomes stable, since it becomes increasingly difficult to change it in any way and have so many sites and implementations also change.
For creating an entirely new vocabulary, and more details about how to research existing values, properties, document examples in the wild, etc., see the microformats The microformats process.
Tasks for this page.
- copy h-review
- use root class name "h-review-aggregate" instead of "h-review"
- add "p-count", "p-votes" properties as defined in hReview-aggregate 0.2
- prune set of properties to those listed in hReview-aggregate 0.2
- change backcompat parsing for root class name to "hreview-aggregate"
- change backcompat parsing property class names to those listed in hReview-aggregate 0.2