Microformats Wiki - User contributions [en]

hcard-supporting-user-profiles

2009-06-12T03:44:14Z

Elli: Addes supporting site sustainlane

{{TOC-right}}
<h1>hCard supporting user profiles</h1>
Welcome! If you have an account on any of the following services, you already have an [[hcard|hCard]] which you can provide to other services to import or subscribe your profile information. The ability to syndicate your profile from the service of your choice is a key component of [[social-network-portability]].

== Services with hCard profiles that also provide OpenID ==
The following web sites support both hCard on user profiles and the ability to use your user profile as an [[OpenID]]. Alphabetically sorted. Feel free to add sites with hCard profiles that are also OpenID URLs here. Please include a link to the site home page (or [[implementations]] entry).

<div style="font-size:larger">
* http://claimid.com/images/badges/claimidclear10x10.gif [http://claimid.com/ ClaimID]
* http://identoo.com/images/icons/services/identoo.gif [http://identoo.com/ Identoo]
* http://pulse.plaxo.com/pulse/img/event_icons/LiveJournal.gif [http://livejournal.com LiveJournal]
* [http://myopenid.com MyOpenID]
* http://pulse.plaxo.com/pulse/img/event_icons/plaxo.gif [http://www.plaxo.com/ Plaxo]
* http://technorati.com/tools/mozsearch/technorati.png [http://technorati.com/ Technorati]
* [http://videntity.org/ Videntity.org]
* http://www.betaid.org/i/icn_betaid.png [http://www.betaid.org Beta ID]
</div>

== All services with hCard profiles ==
The following web <span id="Services_with_hCard_profiles">sites support hCard on their user profiles</span> and are thus suitable for importing/subscribing to other sites that support hCard. Sites that you can also use as your [[OpenID]] are annotated with a OpenID icon http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif following the name of the site.

Alphabetically sorted. Feel free to add all sites with hCard profiles here. Please include a link to the site home page (or [[implementations]] entry), and instructions for retrieving your user profile URL on that site. If the site's user profile URLs can also be used as OpenIDs, please add the OpenID icon http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif following the name of the site.

<div style="font-size:larger">
* [http://3eep.com/ 3eep] - each user's public profile is located at <nowiki>http://3eep.com/users/userNameHere</nowiki>
* [http://www.artistserver.com/ ArtistServer] - each user's public profile is located at <nowiki>http://www.artistserver.com/userURLHere</nowiki>
* [http://www.bragster.com/ bragster] - each user's public profile is located at <nowiki>http://www.bragster.com/member/username</nowiki>
* http://claimid.com/images/badges/claimidclear10x10.gif [http://claimid.com/ ClaimID] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - each user's public profile is located at <nowiki>http://claimid.com/userNameHere</nowiki>
* http://identoo.com/images/icons/services/corkd.gif [http://www.corkd.com/ Cork'd] - login and copy the URL which should start with <nowiki>http://www.corkd.com/people/</nowiki>
* http://pulse.plaxo.com/pulse/img/event_icons/Digg.gif [http://digg.com/ Digg] - e.g. http://digg.com/users/tantek
* [http://djangopeople.net/ Django People] — profiles are at djangopeople.net/username e.g. http://djangopeople.net/simon/
* http://identoo.com/images/icons/services/dopplr.gif [http://www.dopplr.com/ Dopplr] — Example public profile: http://www.dopplr.com/traveller/adactio - non-public profiles may require login to view.
* http://pulse.plaxo.com/pulse/img/event_icons/Facebook.gif [http://facebook.com/ Facebook] - not sure how to find someone's public profile URL, e.g. [http://www.facebook.com/people/Andrei_Zmievski/502957990 Andrei Zmievski] but when found it appears to have support for valid fn+photo properties. Note [[hcard-supporting-user-profiles-issues#Facebook|issue(s) with Facebook hCard profiles]].
* [http://ficlets.com/ Ficlets] — profiles are located at ficlets.com/authors/username e.g. http://ficlets.com/authors/adactio
* http://pulse.plaxo.com/pulse/img/event_icons/Flickr.gif [http://flickr.com/ Flickr] - login, click "Your Photos", click "Profile", and copy the URL which should start with <nowiki>http://flickr.com/people/</nowiki>
* [http://gaia.com/ Gaia Community] - e.g. http://sphorbis.gaia.com/ - built by [http://www.zaadz.com Zaadz]
* [http://google.com Google] - view your profile at http://www.google.com/s2/profiles/me
* [http://huffduffer.com Huffduffer] profiles are located at <nowiki>http://huffduffer.com/username</nowiki> — Example public profile: http://huffduffer.com/clagnut
* http://identoo.com/images/icons/services/identoo.gif [http://identoo.com/ Identoo] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - e.g. [http://identoo.com/dirk.olbertz sample profile]
* http://idleaf.com/favicon.png [http://idleaf.com idleaf] - profiles are located at <nowiki>http://idleaf.com/IDENTITY_ID</nowiki> - e.g.: http://idleaf.com/ID4184
* http://identoo.com/images/icons/services/imthere.gif [http://imthere.com/ ImThere] - profiles are located at <nowiki>http://imthere.com/users/USERNAME</nowiki>
* http://jaiku.com/images/icons/fav-jaiku.gif [http://jaiku.com Jaiku] — profiles are located at username.jaiku.com e.g. http://adactio.jaiku.com/
* [http://jpgmag.com/ JPG Magazine] - each user's public profile is located at <nowiki>http://jpgmag.com/people/userNameHere</nowiki>, e.g. http://jpgmag.com/people/jpd
* [http://www.keevu.com Keevu.com] - profiles are located at <nowiki>http://www.keevu.com/users/USERNAME</nowiki> - e.g.: [http://www.keevu.com/users/zheileman Zheileman]
* http://pulse.plaxo.com/pulse/img/event_icons/LastFM.gif [http://www.last.fm/ Last FM] - profiles are located at <nowiki>http://last.fm/user/USERNAME</nowiki>, includes fn, photo, url.
* http://pulse.plaxo.com/pulse/img/event_icons/LinkedIn.gif [http://linkedin.com LinkedIn] - login, click on "[http://www.linkedin.com/myprofile?trk=tab_pro My Profile]" in the top blue bar, then click on "[http://www.linkedin.com/myprofile?editwp=&trk=tab_web Public Profile]" and copy the URL in the page after "Your current URL is:" which should start with <nowiki>http://www.linkedin.com/pub/ or http://www.linkedin.com/in/</nowiki>. Note: LinkedIn profiles include an [[hresume|hResume]] for you in addition to your hCard.
* http://pulse.plaxo.com/pulse/img/event_icons/LiveJournal.gif [http://livejournal.com LiveJournal] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif (see also [[implementations#LiveJournal|LiveJournal]] implementation page entry) - login, click on the "Profile" link, and copy the URL which should start with <nowiki>http://USERNAME.livejournal.com/profile</nowiki> where USERNAME is your LJ username. E.g. [http://daveman692.livejournal.com/profile].
* http://pulse.plaxo.com/pulse/img/event_icons/Magnolia.gif [http://ma.gnolia.com/ Ma.gnolia] - each user's public profile is located at <nowiki>http://ma.gnolia.com/people/userNameHere</nowiki> . Note: [[hcard-supporting-user-profiles-issues#Magnolia|issue(s)]].
* http://www.mixx.com/images/buttons/mixx-button4.png [http://www.mixx.com Mixx] - profiles are located at <nowiki>http://www.mixx.com/users/USERNAME</nowiki> e.g. http://www.mixx.com/users/jgarber
* [http://myopenid.com MyOpenID] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - profiles are located at <nowiki>http://USERNAME.myopenid.com</nowiki> e.g. http://tantek.myopenid.com/
* [http://www.nsyght.com/ Nsyght] - Visit your profile page. Should look like this: <nowiki>http://www.nsyght.com/friends/[username]/</nowiki>, e.g. [http://nsyght.com/users/lisa sample profile].
* http://www.bkmks.com/icons/nytimes.com.gif [http://timespeople.nytimes.com/ NYTimes TimesPeople] - e.g. http://timespeople.nytimes.com/view/user/19390043/1/index.html
* [http://www.obsidianportal.com Obsidian Portal] - Your profile page is located at <nowiki>http://www.obsidianportal.com/profile/USERNAME</nowiki>, e.g. [http://www.obsidianportal.com/profile/Micah Micah's profile].
* [http://www.osocial.net/network/ OSocial Network] - add the [http://www.osocial.net/network/app/osocialnetwork.xml OpenSocial application] into your social network, then in OSocial.net Web site you will be able to get your hCard profile
* http://pulse.plaxo.com/pulse/img/event_icons/plaxo.gif [http://www.plaxo.com/ Plaxo] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - create a nickname in your settings, then go to NICKNAME.myplaxo.com (e.g. http://joseph.myplaxo.com) and copy the URL
* http://pulse.plaxo.com/pulse/img/event_icons/Pownce.gif [http://pownce.com/ Pownce] - login, click on the "Home" link at the top, and copy the URL.
* http://www.syncup.com/SupWeb/ajax/images/16pxSyncUpIcon.gif [http://www.syncup.com/ SyncUp] - create a free account, choose what information to expose to public or specific people, then get the hcard in your profile page
* [http://www.qmpeople.com/ qmpeople] - Uses hCard+XFN for profiles (<nowiki>http://www.qmpeople.com/users/[username]</nowiki> - e.g. [http://www.qmpeople.com/users/laserion laserion])
* [http://radar.net/ Radar] - http://radar.net/people/radarname
* [http://www.revish.com/ Revish] — profiles are located at revish.com/people/username e.g. http://www.revish.com/people/adactio
* [http://rosebleed.net/ Rosebleed] - your profile URL is <nowiki>http://rosebleed.net/users/profile.php/</nowiki> followed by your username, e.g. [http://rosebleed.net/users/profile.php/silvermoon82 silvermoon82].
* [http://www.getsatisfaction.com/ Satisfaction]
* http://skateboardspot.info/image/icon/favicon.png [http://skateboardspot.info/ skateboardspot.info] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif (The site doesn't provide, but supports OpenID to login and register) — Log in, and click on your username in the top right corner. You'll see your user page which also is your hCard. Just copy the URL and you're done.
* [http://www.sustainlane.com www.sustainlane.com] - Profile at <nowiki>http://www.sustainlane.com/members/[user id]</nowiki> [http://www.sustainlane.com/members/4YHJXMST4S1B3NZT1HCSB4OAIVYD Example]
* [http://tangler.com/ Tangler] - click on a person's profile to navigate to their profile which is marked up with hCard <nowiki>http://www.tangler.com/people/id/</nowiki> - where "id" is the user number of that person.
* http://technorati.com/tools/mozsearch/technorati.png [http://technorati.com/ Technorati] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - login, click on the "Signed in as username" username link at the top right of the page, and copy the URL which should start with <nowiki>http://technorati.com/profile/</nowiki>
* [http://threadless.com/ Threadless] - select "My Account" and then "Profile Page". URL looks like <nowiki>http://www.threadless.com/profile/123987/username</nowiki>
* [http://www.travellerspoint.com/ Travellerspoint] - In use on all member profiles. URLs look like <nowiki>http://www.travellerspoint.com/member_profile.cfm?user=UsernameHere</nowiki> (e.g., [http://www.travellerspoint.com/member_profile.cfm?user=Peter Peter])
* http://pulse.plaxo.com/pulse/img/event_icons/Twitter.gif [http://twitter.com/ Twitter] - login, click on "Your profile" at the top, and copy the URL
* http://pulse.plaxo.com/pulse/img/event_icons/Upcoming.gif [http://upcoming.yahoo.com/ Upcoming] - login, click on the "Welcome, username!" username link at the top right of the page, and copy the URL which should start with <nowiki>http://upcoming.yahoo.com/user/</nowiki>
* [http://videntity.org/ Videntity.org] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - e.g. http://danda.videntity.org/
* [http://www.vimeo.com/ Vimeo] — e.g. http://www.vimeo.com/user196031
* http://openid.net/wp-content/uploads/vox.png [http://vox.com/ Vox] http://openid.net/wp-content/uploads/2007/10/openid_small_logo_white.gif - profile URL is <nowiki>http://USERNAME.vox.com/profile/</nowiki> e.g. http://daveman692.vox.com/profile/ (note issue: empty "n" property. fix: remove "n" from class attribute).
* [http://www.yedda.com/ Yedda] - e.g. http://yedda.com/people/8625713501419/ built by [http://www.zaadz.com Zaadz]
* [http://www.easthampshire.org/ easthampshire.org] - hCard on events and events map - e.g. http://easthampshire.org/eventdetail/wine_society_evening/1372606 and http://easthampshire.org/eventmap/wine_society_evening/1372606 built by [http://www.callendercreates.com Callender Creates]
* [http://www.dandyid.org/ DandyID.org] - hCard on user profiles, and a hCard widget for users blogs/sits/etc. (login to see the widget). Profile e.g. http://www.dandyid.org/beta/users/user_id/3
* ... add more sites (alphabetically sorted please) that support hCard, including instructions for finding and copying your profile URL.
</div>

=== offline sites ===
Sites that supported hCard user profiles that have gone offline, perhaps permanently.
* [http://consumating.com/ Consumating] - login, click on your name or "My Profile" link, copy the URL which looks like <nowiki>http://consumating.com/profiles/userNameHere</nowiki>
** supported hCard profiles at least from sometime in 2006 to 2008-03-15 when the site went offline.

== Services that import hCard profiles==
The following web sites support importing your existing hCard user profile, e.g. from the above sites, or your own page. Feel free to add sites supporting hCard user profile import to the appropriate section here. Please include a link to the site home page, and instructions for how to import your existing hCard user profile to the site.

=== import and subscribe on sign-up ===
Site(s) that allow you to import ''and'' subscribe to your hCard user profile when signing-up.. Alphabetically sorted.
* [http://getsatisfaction.com/ Satisfaction Inc.] - go to [http://getsatisfaction.com/people/new their sign in and registration page], choose the service of your existing profile or "'''Other...'''" and enter your profile URL (which you can retrieve as described above), and click "'''Get Profile'''". Then check "'''[x] Subscribe to this profile'''". Note: [[hcard-supporting-user-profiles-issues#Satisfaction|issue(s)]].

See [[subscribe-to-hcard]] for more notes on implementing subscribing to a user's hCard to automatically update their profile information.

=== import on sign-up ===
Site(s) that allow you to import your hCard user profile to sign-up. Alphabetically sorted.
* [http://www.bragster.com/ bragster] - go to [http://www.bragster.com/signup the sign-up page], click on the service logo of your existing profile, or the microformats logo for 'other' and enter your profile username (or URL for 'other') (which you can retrieve as described above).

=== import anytime ===
Sites that let you import your external hCard profile information anytime.
* [http://php-profile-importer.origo.ethz.ch/ PHP Profile importer] - Open Source PHP and JavaScript profile importer, there is also a [http://proofile.org/profile_importer_demo demo available].
* [http://www.proofile.org proofile] - [http://proofile.org/register Sign up] for an account and view the [http://proofile.org/edit/profile edit profile] page, enabling you to import from any hCard annotated URL. Full hCard is supported.
* [http://www.dandyid.org DandyID] - import a hCard supporting url after signing up, for auto-filling user info. DandyID also renders detailed hCards on user profiles.

=== subscribe anytime ===
Sites that let you subscribe to your external hCard profile information anytime.
* None currently.
=== delegation ===
Sites that support fully delegating to your external hCard profile.
* None currently.

== For more information ==
Want to implement hCard on your site so you can list it here?

See the [[hcard-user-profile-authoring|hCard user profile authoring]] page for how to mark-up a user profile with hCard.

Join the [http://microformats.org/discuss microformats community], in particular the #microformats IRC channel on irc://irc.freenode.net#microformats and the [http://microformats.org/mailman/listinfo/microformats-dev/ microformats-dev mailing list], and send a message stating that you'd like to add hCard to the profiles and hCard+XFN supporting friends lists to your website.

Please also consider implementing [[hcard-xfn-supporting-friends-lists|hCard+XFN friends lists]].

See [[hcard-supporting-user-profiles-issues|hCard supporting user profiles issues]] for issues, problems with implementations.

== see also ==
* [[subscribe-to-hcard]]
* [[hcard-xfn-supporting-friends-lists|hCard+XFN friends lists]]
* [[social-network-portability]]
* [[user-interface]]
* [[hcard|hCard]] ([[hcard-authoring|authoring]], [[hcard-faq|FAQ]])
* [[xfn|XFN]]
* [[data-portability]]

container-brainstorming

2009-06-11T16:49:10Z

Elli: Grammar fix

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property
* Alternatively, siblings cannot override properties of other siblings. Example: hcard of reviewer inside hreview cannot override any property of the item hcard (a sibling of the hreview). When a sibling specifies a property of another sibling, it is ignored (Example: hreview contains availability, availability is ignored).

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container microformat with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T16:44:56Z

Elli: Grammar error

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property
* Alternatively, siblings cannot override properties of other siblings. Example: hcard of reviewer inside hreview cannot override any property of the item hcard (a sibling of the hreview). When a sibling specifies a property of another sibling, it is ignored (Example: hreview contains availability, availability is ignored).

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container to add microformats with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T16:44:19Z

Elli: Fixed explanation of shared aspect

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property
* Alternatively, siblings cannot override properties of other siblings. Example: hcard of reviewer inside hreview cannot override any property of the item hcard (a sibling of the hreview). When a sibling specifies a property of another sibling, it is ignored (Example: hreview contains availability, availability is ignored).

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container to add microformats with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T16:43:49Z

Elli: /* Shared Aspects of Containers */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property
* Alternatively, siblings cannot override properties of other siblings. Example: hcard of reviewer inside hreview cannot override any property of the item hcard (a sibling of the hreview). When a sibling specifies a property of another sibling, it is ignored (Example: hreview contains availability, brand is ignored).

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container to add microformats with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T15:11:00Z

Elli: Added suggestion that siblings cannot override other siblings

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property
* Alternatively, siblings cannot override properties of other siblings. Example: hcard of reviewer inside hreview cannot override any property of the item hcard (a sibling of the hreview). When a sibling specifies a property of another sibling, it is ignored (Example: hreview contains brand, brand is ignored).

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container to add microformats with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T15:03:15Z

Elli: /* hreview rating and hreview-aggregate rating use different names */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
====Problems====
* This may not be necessary for pages that can use a container to add microformats with minimal impact to the xhtml structure. Pages that cannot use container structure and use includes may still need a solution.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T15:00:00Z

Elli: /* hcontainer */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>. This is similar to <code>hreview-set</code> proposal, with specific handling of aggregates.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>

<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>

<div class="hcontainer">
<div class="hreview-aggregate">
<h1 class="item vcard fn">name</h1>
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T14:55:45Z

Elli: /* item as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
====Problems====
* This defines two microformats that can be parent child of each other in both directions (<code>hreview</code> and <code>item</code>).
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T14:51:48Z

Elli: /* hcard as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hCard as a container ===
<code>vcard</code> block can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>vcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
Another option is that a vcard that contains other microformat must also specify additional tag, such as <code>hcontainer</code>, <code>item</code> or similar.
====Problems====
* <code>hreview</code> already contains child hCard. Since it can inherit aspects of hcard from its parent, there will be duplicate values. This makes the job of the parser more complex, and requires additional rules, such as "an hreview inside an hcard ignores all hCard properties that are not contained in it", etc.
* Include pattern from hreview to the container hCard can cause circular references, requiring more rules in the microformat specification and more rules for the parsers to follow.
* Generally it seems to me (Elli) that this pattern will require many parsing rules. Things are not "atomic". It also forces a rigid structure on the xhtml, which may defeat the purpose of containers.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T14:40:06Z

Elli: Fixed brokem classes in examples

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="vcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="vcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="vcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T05:30:42Z

Elli: /* item as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T05:30:05Z

Elli: /* hcontainer */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an item), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, similar examples can be written for products and events.
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T05:26:08Z

Elli: /* Reviews and review aggregate of the same item */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>. Putting the reviews and review aggregates as siblings inside the same container, can solve this problem.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, a similar example can be written for hproduct. <source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T05:22:11Z

Elli: /* hreview rating and hreview-aggregate rating use different names */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, a similar example can be written for hproduct. <source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating. This is not really a container proposal, but it addresses issues of the hreview-aggregate which is currently a container for item.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:43:35Z

Elli: /* hreview rating and hreview-aggregate rating use different names */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, a similar example can be written for hproduct. <source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>

<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">

<span class="rating">3</span> stars

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:39:47Z

Elli: /* hcard as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> do not need to specify item.
This also extends to other microformats that can may contain reviews, such as hproduct.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, a similar example can be written for hproduct. <source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>
<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">...

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:34:55Z

Elli: /* hcontainer */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> to not need to specify item.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
When a container includes <code>hreview</code> or <code>hreview-aggregate</code>, it also requires a child <code>item</code>.

In the example below, the item is hcard, a similar example can be written for hproduct. <source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>
<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">...

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:33:12Z

Elli: /* hcontainer */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> to not need to specify item.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview">...</div>
</div>
</source>

=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>
<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">...

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:27:37Z

Elli: /* hcard as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
<code>hcard</code> can contain associated information like reviews and aggregates. <code>hreview</code>s inside an <code>hcard</code> to not need to specify item.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>

=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview"> ...</div>
</div>
</source>
=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>
<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">...

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:26:12Z

Elli: /* item as a container */

<entry-title>Containers</entry-title>

This page exists to brainstorm around the concept of ‘containers’ in microformats.

==What's a Container?==

A ‘container’ is a root element that contains multiple microformat items within it. It groups those items together, but could also be used to provide additional or shared semantics between those items.

Some microformats already define containers: <code>vcalendar</code> [[hCalendar]] is a container for events, the <code>hfeed</code> container in [[hAtom]] contains entries, [[hAudio]] has a concept whereby <code>haudio</code> concepts may be nested, and an [[hCard]] <code>vcard</code> may be a container for <code>agent vcard</code>s.

==Why is this being explored?==
There are a number of use cases for making better use of these container semantics, both in microformats like hCalendar that already have containers, and [[hReview]], where no current container concept exists.

== examples ==
As always it helps to start with examples of markup from actual websites that are already publishing container semantics. If this section gets too large, perhaps we can move it to [[container-examples]].

=== container of reviews ===
The following website(s) contain a list of reviews which could/would benefit from a way of marking up not just the reviews as hReviews, but also the set of them as reviewing the same item.
==== SustainLane ====
http://www.sustainlane.com/ has pages that show multiple reviews of the same item. e.g.

http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

==== Yelp ====
http://yelp.com/ has pages that show multiple reviews of the same item. e.g.

http://www.yelp.com/biz/coffee-to-the-people-san-francisco

==Use cases==
Here are some example use cases for sharing properties from a container into multiple child microformats:

===Multiple reviews of the same item===
As demonstrated by the above real world examples, many sites publish a page for a single item, listing multiple reviews of that item (e.g. Amazon, Kelkoo, Yelp, Yahoo! Location etc.). The item appears once at the top of the page. The reviews follow. [[hReview]]'s current requirement is that the <code>item</code> be referenced from every review using the include-pattern. This requires duplicating some amount of content (most logically, the name of the reviewed item). This has raised objections by implementers, and usually imposes a CSS-dependency to hide the repeated content.

===Reviews and review aggregate of the same item===
Same as above, a single page includes a few reviews and a single reviews aggregate for a single business. In some implementations (yelp) the aggregate result number is contained inside the <code>hcard</code>. Reviews that use the include pattern to include the <code>hcard</code> of the business, are also including a second <code>rating</code> microformat, resulting in two ratings for the same <code>hreview</code>.

===Shared hCalendar Properties===
Yahoo! TV Listings marks up television programme listings using hCalendar. The <code>location</code> field of the event is the channel on which the show is broadcast: e.g. <code><span class='location'>BBC 1</span></code>.

* ‘BBC 1’ is the heading for that channels listing page. The information is published ''once'' in the page.
* Each scheduled programme on the page is a <code>vevent</code>
* Using current hCalendar semantics, the <code>location</code> must be included in every <code>vevent</code>

With the ‘BBC 1’ content at the top of the page, not part of the programme content, the content either has to be repeated and hidden in the presentation layer, or current microformats constructs such as the [[include-pattern]] need to be used to invisibly reference the original mention of ‘BBC 1’.

Repeating content is unacceptable, and the include-pattern is a messy, hacky mark-up pattern. Embracing the concept of the container would match the publishing pattern of the site, without repeating content or including invisible pointers.

'''ideally this markup proposal would be moved to the "markup proposals" section below, separate from the "Use Cases" section, so that multiple varying proposals could be grouped together to compare, rather than intermingling them with the list of use cases.'''

.e.g.

<source lang=html4strict>
<div class='vcalendar'>
<h1 class='location'>BBC 2</h1>

<ul>
<li class='vevent'>
<h2 class='summary'>Gardener's World</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T20:30:00+0100'> </span> 8:30pm</p>
</li>
<li class='vevent'>
<h2 class='summary'>Have I Got News For You</h2>
<p class='dtstart'><span class='value-title' title='2009-06-05T21:00:00+0100'> </span> 9:00pm</p>
</li>
</ul>
</div>
</source>

Here, the <code>location</code> is promoted to being a property of the <code>vcalendar</code>, and is the default location for all the contained events.

This could also apply to the <code>organizer</code>, <code>attendees</code>, and others. With further explanation and [[value-class-pattern|date-time separation]], you could event declare the day of the week the the <code>vcalendar</code> and the time-of-day in the <code>vevent</code>. The basic principal is illustrated, though.

Uses for this pattern:
* Broadcast listings for a single channel/station
* Concert listings at a single venue
* Concert listings for a single act (e.g. ‘Doves in Concert’ is the event <code>summary</code> for multiple events at different <code>locations</code>)

This of course, extends the use of an existing container.

==Shared Aspects of Containers==
If containers become a more strongly adopted concept in microformats, they should behave consistently across formats (hence documenting these two examples here, rather than just as separate issues for both hReview and hCalendar).

Things that should be consistent and predictable:

* Inheriting an property into a microformat item within the container
* Contained items ''overriding'' one or more inherited property

== markup proposals ==
=== hreview-set ===
One solution to the problem of multiple reviews of the same item could be to wrap each <code>hReview</code> in a container (hypothetically, <code>hreview-set</code>. The <code>item</code> is a child of the set, and is inherited by each <code>hreview</code> contained within.

=== hcard as a container ===
hcard can contain associated information like reviews and aggregates. hreviews inside an hcard to not need to specify item.
<source lang=html4strict>
<div class="hcard">
<h1 class="fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview"> ...</div>
</div>
</source>
=== hcontainer===
A container microformat. Inside a container, a microformat that requires another microformat as a child (such as hreview requiring an hcard), can resolve this association by sibling relationship (as opposed to parent child relationship).
<source lang=html4strict>
<div class="hcontainer">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview">...</div>
<div class="hreview"> ...</div>
</div>
</source>
=== item as a container ===
The <code>item</code> microformat is currently used inside <code>hreview</code>s. Use this existing micformat as a container as well. This makes the specification slightly more complicated, since <code>item</code> will be allowed as a parent of <code>hreview</code> as well as a child. This is basically the same proposal as above, but using the name <code>item</code> for the container, instead of a dedicated name.
<source lang=html4strict>
<div class="item">
<h1 class="item hcard fn">name</h1>
<div class="hreview-aggregate">
<div class="rating">
<span class="average">4.4</span>
</div>
<span class="count">1313</span> reviews
</div>
<div class="hreview"></div>
<div class="hreview"></div>
</div>
</source>
=== hreview rating and hreview-aggregate rating use different names ===
Since the microformat <code>rating</code> is used for both, an <code>hreview</code> that includes an <code>hcard</code> which contains aggregates, effectively imports a second rating. This can be solved by having different names for hreview rating and hreview-aggregate rating.
<source lang=html4strict>
<div class="hcard item" id="review_item">
<h1 class="fn">name</h1>
<span class="average-rating">5</span> stars
based on <span class="review-count">1313</span> reviews
<span class="type microformat_detail">business</span>
</div>
<div class="hreview">...

<a class="item microformat_detail" href="#review_item">Aziza</a>
</div>
</source>

== see also ==
* [[hReview]]
* [[hCalendar]]
* [[hListing]]

container-brainstorming

2009-06-11T04:16:49Z

Elli: /* hcontainer */

container-brainstorming

2009-06-11T04:12:40Z

Elli: /* hcard as a container */

container-brainstorming

2009-06-11T04:06:53Z

Elli: /* hreview-set */

container-brainstorming

2009-06-11T03:53:33Z

Elli: Added section about using reviews and review aggregate on a business reviews page

aggregate-review-brainstorming

2009-06-02T07:07:39Z

Elli: /* 4) Do not use hreview classes in hreview-aggregate */

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 <code><a class="item include" href="#my_business_hcard"></a></code>
** Without including links with duplicate redundant information that is part of the hcard, example <code><a class="item include make_me_invisible_to_user" href="#my_business_hcard">Business Name</a></code>
** Without adding listing information, such as the type of listing: <code><span class="type">business</span></code>.
** 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 (using include pattern).
* 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''' (using include pattern). 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: [[aggregate-review-examples|examples]] - [[aggregate-review-formats|formats]]
* [[hreview-aggregate]]
* [[hreview|hReview]]

aggregate-review-brainstorming

2009-06-02T06:36:27Z

Elli: /* Other proposals suggested */

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 <code><a class="item include" href="#my_business_hcard"></a></code>
** Without including links with duplicate redundant information that is part of the hcard, example <code><a class="item include make_me_invisible_to_user" href="#my_business_hcard">Business Name</a></code>
** Without adding listing information, such as the type of listing: <code><span class="type">business</span></code>.
** 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: [[aggregate-review-examples|examples]] - [[aggregate-review-formats|formats]]
* [[hreview-aggregate]]
* [[hreview|hReview]]

hatom-examples

2009-06-02T04:04:48Z

Elli: Fixed "changes" section as it did not reflect the actual HTML in the example

<h1>hAtom examples</h1>

Examples of [[hatom]] - '''Work in progress!'''

= Contributors =
* [[User:DavidJanes|David Janes]]
* [[User:RobertBachmann|Robert Bachmann]]
* [[User:Chris_Messina|Chris Messina]]

= Transformation 1 =

A well behaved weblog.

Original:

<pre><nowiki>
<body>
<div id="wrap">
<div id="content">
...
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant:

<body>
<div id="wrap">
<div <span class="added">class="hfeed"</span> id="content">
...
<div class="<span class="added">hentry</span> entry" <span class="change">id</span>="post-60">
<h3 class="<span class="added">entry-title</span>">
<a href="<nowiki>http://</nowiki>www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<span class="added"><div class="entry-content"></span>
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>
<span class="added"></div></span>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="<nowiki>http://</nowiki>technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="<nowiki>http://</nowiki>technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="<nowiki>http://</nowiki>technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="<nowiki>http://</nowiki>www.microformats.org/blog/..." rel="bookmark"
title="..."><span class="added"><abbr class="published" title="2005-10-10T14:07:00-07:00"></span>October 10th, 2005<span class="added"></abbr></span></a>
</li>
<li>
<address class="vcard <span class="added">author</span>"><a class="url fn" href="<nowiki>http://</nowiki>theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="<nowiki>http://</nowiki>www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="<span class="added">hentry</span> entry" <span class="change">id</span>="post-59">
....
</div>
...
</div>
</div>
</body>

Changes:
* Added <code>class="hfeed"</code> to Feed
* Added <code>class="hentry"</code> to Entry
* Added <code>class="entry-title"</code> to Entry Title
* Moved <code>id="###"</code> from <code><h3></code> to Entry
* Added <code><div class="entry-content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code>class="author"</code> to <address>

Also note:
* We did not need to add a <code><address></code> element
* We did not need to add a <code><h#></code> element
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks

= Transformation 2 =

A not-so well behaved weblog (an older blogspot weblog)

Original:

<pre><nowiki>
<body bgcolor="...">

<div class="posts">
<a name="112993192128302715"> </a><br>
<div style="clear:both;"></div><strong>Nelson's final prayer</strong>
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a>
</span>
</div>

<div class="posts">
<a name="112993022840118939"> </a>
<br>
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a>
</span>
</div>
...

</body>
</nowiki></pre>

Transformed to hAtom compliant:

<body bgcolor="...">

<<span class="added">div class="hfeed"></span>
<div class="<span class="added">hentry</span> posts" <span class="added">id="112993192128302715"</span>>
<strong <span class="added">class="entry-title entry-content"</span>>
Nelson's final prayer
</strong>
<<span class="added">span class="entry-content"></span>
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
<span class="added"></span></span>
<div>
<span class="byline">posted by <span class="added"><span class="author vcard"><span class="fn"></span>Natalie<span class="added"></span></span></span> at
<a <span class="added">rel="bookmark"</span> href="2005_10_16_nataliesolent_archive.html#112993192128302715">
<span class="added"><abbr class="published" title="2005-10-24t09:49:00-00:00"></span>9:49 PM<span class="added"></abbr></span></a>
</span>
</div>
</div>

<div class="<span class="added">hentry</span> posts" <span class="added">id="112993022840118939"</span>>
<strong <span class="added">class="heading content</span>>"I really, truly </strong>
<span class="added"><span class="entry-content"></span>
didn't go ... view.
</span>
<div>
<span class="byline">
posted by <span class="added"><span class="author vcard"><span class="fn"></span>Natalie<span class="added"></span></span></span> at
<a <span class="added">rel="bookmark"</span> href="2005_10_16_nataliesolent_archive.html#112993022840118939">
<span class="added"><abbr class="published" title="2005-10-24t09:49:00-00:00"></span>9:28 pm<span class="added"></abbr></span></a>
</span>
</div>
</div>
...
</div>

</body>

Changes:
* Added <code>class="hfeed"</code> to Feed
* Added <code>class="hentry"</code> to each Entry
* Added <code>class="entry-title"</code> to each Entry Title
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Added <code><span class="entry-content"></code>...<code></div></code> around the Entry Title (!)
* Added <code><span class="entry content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><span class="author vcard"></code> and <code><span class="fn"></code> to the poster's name

Also note:
* the ID/fragments are not XHTML -- this is a big problem.
* there are multiple content blocks, because Natalie Solent embeds the title in the content
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet
* this is one of the uglier transformations you're likely to see

= Transformation 3 =

A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).

Original:

<pre><nowiki>
<div class="news">
<div class="story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span>
<div class="text"><a href="/news/credit.html">CBC News</a></div>

<div class="text">
<p>
China has confirmed three new outbreaks of bird flu, ...
<p>
<ul>
<li><font size="1">INDEPTH: </font><font size="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p>State media says the new outbreaks are in...</p>
<p>The news comes a day after China announced the ...</p>
<p>In China's eastern Anhui province, authorities have ...</p>
<p>The province says the measure will prevent domestic ...</p>
<p>Vietnamese health officials have confirmed that a ...</p>
<p>Doctors from the health department in the northern ...</p>
<p>Bird flu has killed 42 people in Vietnam since December ...</p>
<p>The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p>
</div>
...
</div>
</nowiki></pre>

Transformed to hAtom compliant:

<div class="news">
<div class="<span class="added">hfeed hentry</span> story">
<h1 <span class="added">class="entry-title"></span>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated
<span class="added"><abbr class="published" title="2005-11-23T04:26:18Z"></span>Tue, 22 Nov 2005 23:26:18 EST<span class="added"></abbr></span>
</span>
<span class="added"><address class="vcard author"></span><span class="text"><a <span class="added">class="url"</span> href="/news/credit.html">CBC News</a></span><span class="added"></address></span>

<div class="text">
<p <span class="added">class="entry-content"</span>>
China has confirmed three new outbreaks of bird flu, ...
</p>
<p>
<ul>
<li><font size="1">INDEPTH: </font><font size="2">
<a href="<nowiki>http://</nowiki>www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="<nowiki>http://</nowiki>www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p <span class="added">class="entry-content"</span>>State media says the new outbreaks are in...</p>
<p <span class="added">class="entry-content"</span>>The news comes a day after China announced the ...</p>
<p <span class="added">class="entry-content"</span>>In China's eastern Anhui province, authorities have ...</p>
<p <span class="added">class="entry-content"</span>>The province says the measure will prevent domestic ...</p>
<p <span class="added">class="entry-content"</span>>Vietnamese health officials have confirmed that a ...</p>
<p <span class="added">class="entry-content"</span>>Doctors from the health department in the northern ...</p>
<p <span class="added">class="entry-content"</span>>Bird flu has killed 42 people in Vietnam since December ...</p>
<p <span class="added">class="entry-content"</span>>The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p>
</div>
...
</div>

Changes:
* Added <code><div class="hfeed hentry"></code> around the single entry on the page
* Added <code><div class="entry-title"></code> to the Entry Title
* Added the class <code>class="entry-content"</code> to every paragraph, eg <code><p class="entry-content"></code>...<code></p></code> -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "entry-content" div but note that we did this so the "INDEPTH" part would not be marked as content,
* Added <code><abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address class="author vcard"></code> and <code><span class="fn org"></code> to the CBC Newsroom

Also note:
* We made the document more XHTML compliant
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page

= Transformation 4 =

A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])

Original:

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<div id="p54390" class="blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="blockpost roweven">
<h2><span><span class="conr">#2 </span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant:

<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<span class="added"><div class="hfeed"></span>
<div id="p54390" class="<span class="added">hentry</span> blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a <span class="added">rel="bookmark"</span> href="viewtopic.php?pid=54390#p54390">
<span class="added"><abbr class="published" title="2005-10-16T10:36:24-0500"></span>2005-10-16 10:36:24<span class="added"></abbr></span>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><span class="added"><address class="author vcard"></span><a <span class="added">class="url fn"</span>href="profile.php?id=2">Rickard</a><span class="added"></address></span></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="<nowiki>http://</nowiki>www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3 class="entry-title">PunBB 1.2.9</h3>
<div class="<span class="added">entry-content</span> postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="<span class="added">hentry</span> blockpost roweven">
<h2>
<span><span class="conr">#2 </span>
<a <span class="added">rel="bookmark"</span> href="viewtopic.php?pid=54392#p54392">
<span class="added"><abbr class="published" title="2005-10-16T10:54:41-0500"></span>2005-10-16 10:54:41<span class="added"></abbr></span>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><span class="added"><address class="author vcard"></span><a <span class="added">class="url fn"</span> href="profile.php?id=5298">IdleFire</a><span class="added"></address></span></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3 class="entry-title"> Re: PunBB 1.2.9</h3>
<div class="<span class="added">entry-content</span> postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...
<span class="added"></div></span>

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>

Changes:
* Added <code><div class="hfeed"></code> around the entries (as opposed to an existing <code><div</code> that enclosed more than entries.
* Added <code>class="hentry"</code> to each Entry
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Added <code><span class="entry-title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="entry-content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address class="author vcard"></code> and <code>class="fn url"</code> to the poster's name

Also note:
* We did not need to add <code>id="###"</code> to the Entry

= Transformation 5 =

Transforming RSS to hatom using MagpieRSS. [http://factoryjoe.com/projects/sixwords/index.txt PHP source available]. Result:

<ol><li><html></li>
<li><body <span class="added">class="hfeed"</span> id="<span class="nu0">173333</span>"></li>
<li> </li>
<li><div id="content" <span class="added">class="hentry"</span>></li>
<li>        <h2 <span class="added">class="entry-title"</span>></li>
<li>                No. <a href="http://twitter.com/ssmith/statuses/<span class="nu0">173333</span>" <span class="added">rel="bookmark"</span>><span class="nu0">173333</span></a></li>
<li>        </h2></li>
<li>        <p <span class="added">class="entry-content"</span>></li>
<li>                  Sweet potato pie. Sugar coma. Die.</li>
<li>        </p></li>
<li>        <p></li>
<li>                <small>Penned by <span <span class="added">class="vcard author"</span>><a href="http://twitter.com/ssmith" <span class="added">class="url fn"</span>>Sean</a></span> at <span class="added"><abbr title="Fri, <span class="nu0">24</span> Nov <span class="nu0">2006</span> <span class="nu0">01</span>:<span class="nu0">03</span>:<span class="nu0">11</span> <span class="nu0">+0000</span>" class="updated"></span><span class="nu0">1</span>:03am</abbr></small>.</li>
<li>        </p></li>
<li> </li>
<li></div></li>
<li></body></li>
<li></html></li></ol>

= More Examples =

hAtom for search results, from [[http://randomchaos.com/microformats/base/ Microformats Base]]:

<li <span class="added">class="hentry"</span>><a <span class="added">rel="bookmark"</span> href="http://tantek.com/presentations/2006/03/what-are-microformats/" <span class="added">class="headline"</span>>http://tantek.com/presentations/2006/03/what-are-microformats/</a> <span class="added">updated <abbr class="published" title="2006-07-10T14:05:54-04:00">2006-07-10 14:05:54</abbr></span></li>

Changes:
* Added <code>class="hentry"</code> to each result
* Added <code>rel="bookmark"</code> to each result link
* Added <code><abbr class="updated" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> for date of index update

include-pattern-examples-in-wild

2009-05-30T02:03:37Z

Elli: /* Examples */

=Include Pattern Examples in the Wild=

Pages which use the [[include-pattern]]. Please add new examples to the '''top''' of this list, and specify whether '''<code>object</code>''' or '''<code>a</code>''' is used for the included content.

==Examples==
* [http://www.sustainlane.com/ SustainLane] uses the include pattern on pages that contain one green local business and many reviews for that business ([http://www.sustainlane.com/reviews/farmerbrown/USD2YZY1YDR98XCST8B8H47O2O3A example]). We use an anchor tag that is hidden using CSS, the anchor contains the business name (redundant information):
<code><span class="item '''invisible'''"><a class="include" href="#review_item">Hello World Business Name</a></span></code>
* [http://www.niallkennedy.com/blog/2009/01/facebook-vs-power-ventures.html Niall Kennedy's Weblog] uses empty anchor with include pattern to reference the parent company of an hcard org-unit when mentioned. Include hcards currently appear as invalid in Operator.
* [http://bergantinedesign.us/ Joseph Bergantine] uses <code>a</code> include syntax throughout the site to combine information in various places on the page, originally used <code>object</code> syntax but that caused significant issues in Safari
* [http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html INGV Bologna] uses include-pattern for organization-name and fax in hcards of staff-members. The hcards are marked up as table-rows, '''<code><a href="#anchorName"></a></code>''' sintax is used for the included data.
* [http://3amproductions.net 3AM Productions] uses include-pattern for filling in hcard pieces throughout the page. Originally used <code>object</code> but switched to <code>a</code> due to issues styling <code>object</code> in IE as well as accessibility validator issues ([http://www.contentquality.com/ Cynthia])
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club] in the English Midlands uses include-pattern, with <code>object</code>, to include the logo from the top of each page, in the page-footer's hCard (e.g on [http://www.westmidlandbirdclub.com/new.htm the What's New page]), and to include the location and page-URL of, for example, its [http://www.westmidlandbirdclub.com/birmingham/indoor.htm indoor meetings in Birmingham] in their hCalendar microforamts.
*...

==Related Pages==
{{include-pattern-related-pages}}

hreview-examples-in-wild

2009-05-30T01:46:12Z

Elli: /* New Examples */

<h1>hReview Examples in the wild </h1>
This page is an '''informative''' section of the [[hreview|hReview]] specification.

The following sites have published [[hreview|hReviews]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If you publish hReviews on your own site, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hreview|hReview]] markup. Examples added without a URL to a page with hReview markup may be removed.

Want to get started with writing an [[hreview|hReview]]? Use the [http://microformats.org/code/hreview/creator hReview creator] to write a review and publish it on your blog or site.

== New Examples ==
* [http://www.sustainlane.com/ SustainLane] uses hreview for user reviews of local green businesses and green products ([http://www.sustainlane.com/reviews/b-restaurant-bar/YSNIVHY298U2SBV7AWNUJ1VWYWOR example]). Also rel-tag, hcard, vcard, and many more coming.
* [http://www.momentville.com/ MomentVille] uses hReview markup for wedding vendor reviews. Example: [http://vendors.momentville.com/vendors/elizabeth_morgan_photography/reviews Reviews of Hawaii Wedding Photographer].
* [http://inkweaver-review.blogspot.com Inkweaver Review] uses a modified Blogger XML template to automatically generate hReview markup for its reviews of young adult books. Example: [http://inkweaver-review.blogspot.com/2009/05/toby-alone-by-timothee-de-fombelle.html Review of Toby Alone by Timothee de Fombelle].
* [http://www.eduhub.nl Eduhub] uses hReview for it's user reviews of trainings. Example: [http://www.eduhub.nl/tijdwinst/1-daagse-training-cursus-time-management#ervaringen Trainingreviews] .
* [http://aplawrence.com APLawrence.com] has started using hReview for its [http://aplawrence.com/cgi-bin/indexget.pl?Reviews reviews]
* [http://www.commonsensemedia.org Common Sense Media] now uses hReview for its parent-focused [http://www.commonsensemedia.org/movie-reviews movie reviews]. hReview for other media types (books, music, websites) is forthcoming.
* [https://www.brownbook.net Brownbook.net] The global free business directory that anyone can edit uses hReviews for customer submitted reviews on all its business listings. Example [http://www.brownbook.net/business/30991528/celebrity-lipstick Temecula Lipstick], or check out any of the reviews on the home page.
* [https://www.dutchbulbs.com/store/holidaygifts/16420 DutchBulbs.com] uses hReview for customer submitted reviews of its bulbs and perennials.
* [http://www.cleanertoday.com/Roof-Shingle-Cleaner-Reviews-s/116.htm CleanerToday] has implemented hReview linked to an hCard for reviews on product pages. (for example see [http://www.cleanertoday.com/Indian-Meal-Moth-Traps-p/trap-birdseed.htm Moth Trap Reviews].
* [http://www.MaxiMovieBlog.com] uses hReview, rel-nofollow and rel-tag microformats for reviews of movies and home-theater electronics
* [http://newyork.brokerbeagle.com BrokerBeagle] uses hReview linked to an hCard via the include-pattern to mark up reviews of New York apartment brokers, see [http://newyork.brokerbeagle.com/broker-302-harris_philip.html example].
* [http://anime.mikomi.org anime.mikomi.org] uses hReview to mark up all of its user reviews of anime series, see [http://anime.mikomi.org/series/292.html example].
* [http://www.ecovian.com Ecovian] uses hReview to mark up user reviews of environmentally friendly businesses, see [http://www.ecovian.com/l/san-francisco-ca/millennium-restaurant example]
* Russian site [http://hotelmate.ru/ Hotel Mate] uses hReview for user submitted hotel reviews.
* Swedish music site [http://dagensskiva.com/ dagensskiva.com] publishes all reviews in hReview format.
* [http://bergantinedesign.us Joseph Bergantine] periodically reviews things he [http://bergantinedesign.us/blog/my-name-is-rachel-corrie likes] or [http://bergantinedesign.us/blog/my-microwave-has-a-button-that-says-record dislikes] on his blog
* [http://microrevie.ws MicroReviews] - takes Twitter posts and marks them up with [[hReview]]. The markup is descibed on the [http://microrevie.ws/technical technical page].
* [http://www.scubafreebies.com ScubaFreebies.com] - reviews websites for SCUBA divers in hReview format. For example [http://www.scubafreebies.com/review/theaquaplanet review of video site theAquaPlanet]
* [http://www.hypercasinos.com Hypercasinos.com] - offers reviews of online casinos in hReview format. For example [http://www.hypercasinos.com/content/view/27/1/ a Bodog Casino review]
* [http://www.allogarage.fr/ Allogarage] - compare 13 000 motor mechanics in France- all reviews are in hReview format.
* [http://www.lopico.com Lopico - social business directory] - local business reviews in hReview
* [http://www.rolandinsh.lv/blog Rolands Umbrovskis - Blog] marked up with hReview all blog posts, using very basic requirements (hReview -> rating), for readers rating of any post/page.
* [http://www.concertbuzz.net ConcertBuzz- Concert Reviews] uses hReview for all user submitted concert reviews. See an [http://www.concertbuzz.net/genres/classic-rock/jethro-tull.html individual review page].
* All the [http://www.westmidlandbirdclub.com/review/ West Midland Bird Club's reviews], e.g. [http://www.westmidlandbirdclub.com/review/countrymans-bedside-book.htm Countryman's Bedside Book]
* [http://www.novedge.com/ Novedge], the largest online CAD/CAM/DCC store, uses hReview for all product reviews (currently about 2000 reviews). See [http://www.novedge.com/review/1978/ single review page] and [http://www.novedge.com/Robert-McNeel/Rhino-4-0/products/2217/tab/3 multiple reviews page]. Each hReview is also visually marked with the hReview button: http://rbach.priv.at/2006/buttons/hreview.png
* [http://club.coneco.net/ Coneco Club] (in Japanese) uses hReview for all product reviews. See [http://club.coneco.net/user/4/review/4178/index.htm example]
* [http://11870.com/pro/11870 11870.com] a social network (real life del.icio.us) which implements hReview for user's reviews about places, services and business
* [http://www.mises.org/periodical.aspx?Id=2 The Mises Review], an academic journal, uses hReview for their book reviews. See [http://www.mises.org/misesreview_detail.aspx?control=317 example]
* [http://www.golfdigest.com/ Golf Digest] uses hReview on its [http://www.golfdigest.com/courses/places Course Finder] detail pages to publish user comments, ratings and geo. [http://www.golfdigest.com/courses/places/2483 example]
* [http://www.ramkol.co.il/ Ramkol] (in Hebrew) Advanced social networking based local reviews in Israel
* [http://www.popsyndicate.com/ PopSyndicate] is a groups review site for comic books, movies, dvds, music, and book using hReview and hCard.
* [http://www.mitkbh.dk/ MitKBH] (in danish) uses hReview to publish reviews of shops, clubs, bars, cafées, take-aways and restaurants in Copenhagen, Denmark. Each reviewed place has also a geo incl.[http://www.mitkbh.dk/node.php?node=238 example]
* [http://www.readandtravel.info Read&Travel] includes meta-information using hReview for travel-book reviews.
* [http://www.mangospot.dk/ Mangospot] uses hReview to publish reviews of bars, cafées and restaurants [http://mangospot.dk/Steder/245/Klassisk65-BistroVinbar.aspx example]
* [http://www.sean-johnson.com/ Sean Johnson] has started using hReview for [http://www.sean-johnson.com/2007/05/04/everyman-by-philip-roth/ book] and [http://www.sean-johnson.com/2007/05/01/feist-the-reminder/ music] reviews.
* [http://www.loudervoice.com/ LouderVoice] publishes and aggregates hReviews to/from blogs. All [http://www.loudervoice.com/search?q=hotel+cork Search/Tag Results] are also marked up with hReview.
* [http://www.bayofislands.net/ Bay of Islands] uses hReview eg. for reviews of [http://www.bayofislands.net/accommodation/apartments/edgewater-palms-apartments/#reviews Edgewater Palms]
* [http://spotspotting.com/ SpotSpotting], a site where TV commercials are reviewed and marked up with hReview (in Spanish)
* [[User:AndrewKuchling]] has added hReview to his book diary and would like to know if the markup is correct; [http://www.amk.ca/books/h/Velocity_of_Honey example 1], [http://www.amk.ca/books/h/Star_Wars_On_Trial example 2])
* [http://www.revish.com/ Revish], a book review community, uses hReview for all reviews on the site.
* [[User:EdwardOConnor]] has published several hReviews on his blog ([http://edward.oconnor.cx/2006/08/cask-room 1], [http://edward.oconnor.cx/2006/10/lud-in-the-mist 2], [http://edward.oconnor.cx/2006/11/hoboken 3], [http://edward.oconnor.cx/2006/11/basic 4], [http://edward.oconnor.cx/2006/11/legitimacy 5], [http://edward.oconnor.cx/2006/11/pizza-port 6], [http://edward.oconnor.cx/2006/12/lady-dottie-and-the-diamonds 7]).
* [http://ficlets.com/stories/12 Ficlets] story page uses hReview for user comments.
* Birder's Library, e.g. [http://www.birderslibrary.com/reviews/dvd/audubon_video_guide.htm Audubon VideoGuide to 505 Birds of North America]
* [http://www.raveaboutit.com.au Rave About It] uses hReviews for all local business reviews. In addition it uses the hCard format for a business's contact details.
**No examples on cited page
*[[User:RobCrowther]] has a number of hReviews on his blog, for example [http://www.boogdesign.com/b2evo/index.php/a/2007/02/09/webdd07_unobtrusive_javascript_with_rail this is one of a sequence of reviews of talks at WebDD07], and a [http://www.boogdesign.com/b2evo/index.php/a/2007/02/28/wsg_london_accessibility_meetup single post with three reviews].
*[http://www.volume.co.uk/main/clients/clients.aspx Volume] publishes client reviews/quotes as hReviews.
* [http://revyu.com/ Revyu] allows people to review, rate, and tag anything. Individual reviews ([http://revyu.com/reviews/0b03069358e6c718167e09119f7709dc50fb3f6e/about/html example]) are marked up using hReview.
*[http://www.globaldm.co.uk/our-clients.html GlobalDM] publishes client reviews/quotes as hReviews.
* [http://www.dishola.com/dishes/index/Austin,%20TX Dishola] publishes user reviews and ratings of dishes at restaurants, as opposed to entire "restaurant" reviews.
* [http://musicknows.com/1998/10/22/the-science-lesson MusicKnows] publishes user reviews and memories of gigs using hReview.
** hReview does not have an item
* [http://thetenwordreview.com The Ten Word Review] simply contains ten word long reviews. All reviews are marked up as hReviews, and user information is marked up as hCards.
* [http://www.halogenguides.com Halogen Guides] is an independent network of websites for wealthy consumers. Member-created reviews for [http://realestate.halogenguides.com/company/exclusive-resorts/reviews destination clubs], private jets and fractional real estate are published with hReview.
* [http://www.board-crazy.co.uk Board Crazy Skateboarding] uses hReviews for all [http://www.board-crazy.co.uk/skate-reviews.php skateboarding product reviews].
** hReviews include the rating inside of the description - 12/11/2006
* [http://local.yahoo.com Yahoo Local] now supports hReviews for all the user feedback and ratings about places in their search results
*[http://corkd.com/ Cork'd] is a community site for reviewing and sharing wine. Member-created "Tasting Notes" are published using hReview.
*[[User:ChrisCasciano]] has started using hReview in his blog postings including these reviews of [http://chunkysoup.net/article/211/TechnoratisNewToys Pingerati and Technorati Microformat Search].
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
* [http://tech.yahoo.com/ Yahoo! Tech] has launched with hReview markup on all their reviews! Hat tips: [http://nerddawg.blogspot.com/2006/05/hreview-microformat-on-yahoo-tech.html Ashish Shetty] and [http://jeremy.zawodny.com/blog/archives/006729.html Jeremy Zawodny] both via [http://www.moskalyuk.com/blog/yahoo-tech-tip-of-the-day/1058 Alex Moskalyuk]. [http://jeremy.zawodny.com/blog/archives/006729.html#comment-27779 Alex says]: "when we launched, the press reported on 300,000 tech products in our database. Some popular items, like [http://tech.yahoo.com/pr/apple-ipod-video-30gb-black-mp3-player/1992981873 this Apple iPod], have over 200 reviews."
* [http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking] has an hReview of
[http://smarking.com/ Smarking.com] (a social bookmarking service) which marks up their tagged links with [[xfolk|xFolk]].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://www.pacificspirit.com Dave Orchard] provides hreview marked [http://www.pacificspirit.com/Restaurants-Vancouver.html Vancouver Restaurant reviews]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://3spots.blogspot.com/2006/04/what-is-wikio-definitely-web-20-but.html hReview of Wikio]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://jg.typepad.com/ciel/ Joan] has published [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html an hReview of Garçon]
** hReviews include the rating inside of the description - 12/11/2006
*[http://zipingo.typepad.com/ Zipingo Team Blog], a collaborative blog by the Zipingo Product Development Team at Intuit, used the hReview format to tag [http://zipingo.typepad.com/my_weblog/2005/12/finding_an_elec.html the backstory] of a review on a San Mateo electrician, written by one of the Zipingo team members ZipingoJim. Jim's post also links to his review on [http://www.zipingo.com Zipingo], a consumer opinion site.
** hReview does not have an item
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.debaser.it/ DeBaser.it] publishes music reviews (in Italian) supporting hReview.
* [http://blog.ftwr.co.uk/ Peter Westwood] posted an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.livejournal.com/users/danieljohn/ Daniel John] provides a [http://www.livejournal.com/users/danieljohn/58674.html scathing hReview of CIBC].
** hReview does not have an item
* [http://uk.movies.yahoo.com/movie-reviews/ Yahoo UK Movie Reviews] now supports hReview on all (>2000) reviews, e.g. [http://uk.movies.yahoo.com/h/Harry-Potter-and-the-Goblet-of-Fire/review-41195.html Harry Potter and the Goblet of Fire Review]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://adam.typepad.com/impossiblethings/ Adam Hertz] wrote hReviews of [http://adam.typepad.com/impossiblethings/2005/11/soluna.html Soluna] and [http://adam.typepad.com/impossiblethings/2006/05/cafe_gibraltar.html Cafe Gibraltar]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.mattmcalister.com/blog/ Matt McAllister] wrote an [http://www.mattmcalister.com/blog/_archives/2005/11/16/1408893.html hReview of the TV show: "The Office"]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.bmannconsulting.com/blog/bmann/ Boris Mann] wrote an [http://www.bmannconsulting.com/blog/bmann/doubletake-best-panorama-stitch-tool-for-mac-os-x hReview of DoubleTake, a panorama stitch tool for Mac OS X]
** hReview does not have an item
* [http://blog.ftwr.co.uk/ Peter Westwood] has written an [http://blog.ftwr.co.uk/archives/2005/10/03/blubeckers-hampton-court/ hReview of Blubeckers Hampton Court] and an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn Bucks Green, West Sussex]
** hReviews include the rating inside of the description - 12/11/2006
* [http://dougal.gunters.org/blog/ Dougal] has published an [http://dougal.gunters.org/blog/2005/08/03/french-vanilla-latte hReview of Wolfgang Puck’s Gourmet French Vanilla Latte].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.dinnerbuzz.com/ Dinnerbuzz] is a great site for posting tagged reviews of restaurants, and they publish and summarize all their reviews in hReview!
* [http://soldierant.net/ Bryce Glass (Soldier Ant)] posted an [http://soldierant.net/archives/2005/06/product_review.html hReview of the Uniden ELBT 595 Bluetooth Cordless Phone].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* dda posted an [http://sungnyemun.org/wordpress/?p=20 hReview of hReview] :)
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* An [http://tbp.xomerang.com/?p=3 hReview of Caffè Camardo coffee].
** No hreview on page even though the page claims to be an hreview
* [http://loadaveragezero.com/hnav/contact.php Douglas Clifton] posted [http://loadaveragezero.com/#May-12-2005 comments] regarding adapting his list of ~800 [http://loadaveragezero.com/app/drx Developer Resources] as a format for evaluating hReview.
* [http://www.oliverbrown.me.uk/ Oliver Brown] [http://www.oliverbrown.me.uk/2005/05/09/sitereviewsorg-supports-hreview-i-think/ has announced] that his [http://en-us.sitereviews.org/ SiteReviews.org] (which reviews websites) publishes its reviews using hReview, e.g. here is the [http://en-us.sitereviews.org/review-photomatt.net review on SiteReviews.org for photomatt.net].
* [http://www.myelin.co.nz/post/ Phillip Pearson] is publishing hReviews in the [http://coffee.gen.nz/rss/reviews RSS feed of cafe reviews] on his [http://coffee.gen.nz/ kiwi coffee review site], which of course has the reviews in HTML with embedded hReview markup as well.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://station11.net/ticker/ Kjell] is publishing his link blog as a [http://station11.net/ticker/ list of hReviews].
** hReviews have no fn specified on the item - 12/11/2006
* [http://epeus.blogspot.com/ Kevin Marks] has [http://epeus.blogspot.com/2005_04_01_epeus_archive.html#111484565269684374 published two hReviews] and used unicode "star" characters for his ratings!
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* JamesStewart is publishing hReviews in the location pages at his [http://grwifi.net Grand Rapids WiFi site].
* [http://www.happenchance.co.uk/ Paul Livingstone] uses hreview to voice his opinion on [http://happenchance.co.uk/reading/ books] and [http://happenchance.co.uk/listening/ music].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.stuffandnonsense.co.uk/ Andy Clarke] uses hReview for his [http://www.stuffandnonsense.co.uk/general/recommended-reading.html recommended reading list].
** hReviews have no fn specified on the item - 12/11/2006
* [http://nachlin.com/ Jim Nachlin] has added hReview publishing to the CMS he uses to publish [http://daysofleisure.com/writing his blog].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://whumpdotcom.livejournal.com/236856.html Bill Humphries] has reviewed the book "A Brother's Price" on his LiveJournal.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.thinkvitamin.com/ Vitamin] uses hReview on it's [http://www.thinkvitamin.com/reviews/ reviews] section (e.g. a [http://www.thinkvitamin.com/reviews/webapps/fluxiom/ review of Fluxiom]).
* [http://www.openguides.org/ OpenGuides] has support for the hReview microformat, and you can see it in action on [http://cotswolds.openguides.org/wiki/The_Plough,_Finstock this Cotswolds OpenGuide Review].
** hReview does not have an item
* [http://paulgoscicki.com Paul Goscicki] is publishing his [http://paulgoscicki.com/#wp_movie_ratings movie ratings] using hReview.
* [http://www.cellphones.ca/ Cell Phones etc.] is using hReviews for user-contributed [http://www.cellphones.ca/cell-phones/reviews/ cell phone reviews].
* [http://www.liptrot.org Adam Liptrot] publishes movie reviews using hReview and hCard. See article at [http://www.liptrot.org/journal/entries/movies_and_microformats/ Movies and Microformats].
* [http://www.webteacher.ws Web Teacher] is using hReview for book reviews in both the hReview creator format and a modified format. See a modified example at [http://www.webteacher.ws/2006/11/review-web-design-complete.html Web Design: A Complete Introduction].
** hReviews include the rating inside of the description - 12/11/2006
* [http://niftylist.co.uk/ The nifty list UK.] is using hReviews for user-contributed [http://niftylist.co.uk/mobiles/ mobile phone reviews].
** hReview does not have an item
* [http://sergiosantos.info/2007/3/books SergioSantos.info] uses hReviews for the reviewed book collection.
* [http://www.dcs-media.com/ DCS Media] converted all of their Firefox extension Reviews into hReview format. See the [http://www.dcs-media.com/fireday/default.aspx Fireday] page for extension listings.
* [http://bit.ly/iiag Is It Any Good . biz]has added hReview to all of their product reviews. See this example review of [http://bit.ly/2A3nVk Leapster2 Learning System ].

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hreview|hReview spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hreview-faq|hReview FAQ]], or raise any queries on [[hreview-issues|hReview issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.

* [http://apple.com/store Apple Store] customer reviews are marked up in hReview, as in [http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/wa/RSLID?mco=E1BD7358&fnode=home/shop_mac/mac_accessories/airport_wireless&nplm=MB053LL/A#review-RTD4T4KYJYYF9UC44 this review] of the Airport Extreme Base Station.
**'''sub-optimal''': Model numbers (?) marked up as URLs, e.g. <code><nowiki><SPAN class="url">MB053LL/A</SPAN></nowiki></code>
*loadaveragezero.com e.g. [http://loadaveragezero.com/app/drx/Data_Formats/Metadata/XMDP]
**'''invalid''': no fn (site owner informed)
* ...

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

==Related pages==
{{hreview-related-pages}}

hreview-examples-in-wild

2009-05-30T01:44:27Z

Elli: /* New Examples */

<h1>hReview Examples in the wild </h1>
This page is an '''informative''' section of the [[hreview|hReview]] specification.

The following sites have published [[hreview|hReviews]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc.

If you publish hReviews on your own site, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hreview|hReview]] markup. Examples added without a URL to a page with hReview markup may be removed.

Want to get started with writing an [[hreview|hReview]]? Use the [http://microformats.org/code/hreview/creator hReview creator] to write a review and publish it on your blog or site.

== New Examples ==
* [http://www.sustainlane.com/ SustainLane] uses hreview for user reviews of local green businesses and green products. [http://www.sustainlane.com/reviews/b-restaurant-bar/YSNIVHY298U2SBV7AWNUJ1VWYWOR example]
* [http://www.momentville.com/ MomentVille] uses hReview markup for wedding vendor reviews. Example: [http://vendors.momentville.com/vendors/elizabeth_morgan_photography/reviews Reviews of Hawaii Wedding Photographer].
* [http://inkweaver-review.blogspot.com Inkweaver Review] uses a modified Blogger XML template to automatically generate hReview markup for its reviews of young adult books. Example: [http://inkweaver-review.blogspot.com/2009/05/toby-alone-by-timothee-de-fombelle.html Review of Toby Alone by Timothee de Fombelle].
* [http://www.eduhub.nl Eduhub] uses hReview for it's user reviews of trainings. Example: [http://www.eduhub.nl/tijdwinst/1-daagse-training-cursus-time-management#ervaringen Trainingreviews] .
* [http://aplawrence.com APLawrence.com] has started using hReview for its [http://aplawrence.com/cgi-bin/indexget.pl?Reviews reviews]
* [http://www.commonsensemedia.org Common Sense Media] now uses hReview for its parent-focused [http://www.commonsensemedia.org/movie-reviews movie reviews]. hReview for other media types (books, music, websites) is forthcoming.
* [https://www.brownbook.net Brownbook.net] The global free business directory that anyone can edit uses hReviews for customer submitted reviews on all its business listings. Example [http://www.brownbook.net/business/30991528/celebrity-lipstick Temecula Lipstick], or check out any of the reviews on the home page.
* [https://www.dutchbulbs.com/store/holidaygifts/16420 DutchBulbs.com] uses hReview for customer submitted reviews of its bulbs and perennials.
* [http://www.cleanertoday.com/Roof-Shingle-Cleaner-Reviews-s/116.htm CleanerToday] has implemented hReview linked to an hCard for reviews on product pages. (for example see [http://www.cleanertoday.com/Indian-Meal-Moth-Traps-p/trap-birdseed.htm Moth Trap Reviews].
* [http://www.MaxiMovieBlog.com] uses hReview, rel-nofollow and rel-tag microformats for reviews of movies and home-theater electronics
* [http://newyork.brokerbeagle.com BrokerBeagle] uses hReview linked to an hCard via the include-pattern to mark up reviews of New York apartment brokers, see [http://newyork.brokerbeagle.com/broker-302-harris_philip.html example].
* [http://anime.mikomi.org anime.mikomi.org] uses hReview to mark up all of its user reviews of anime series, see [http://anime.mikomi.org/series/292.html example].
* [http://www.ecovian.com Ecovian] uses hReview to mark up user reviews of environmentally friendly businesses, see [http://www.ecovian.com/l/san-francisco-ca/millennium-restaurant example]
* Russian site [http://hotelmate.ru/ Hotel Mate] uses hReview for user submitted hotel reviews.
* Swedish music site [http://dagensskiva.com/ dagensskiva.com] publishes all reviews in hReview format.
* [http://bergantinedesign.us Joseph Bergantine] periodically reviews things he [http://bergantinedesign.us/blog/my-name-is-rachel-corrie likes] or [http://bergantinedesign.us/blog/my-microwave-has-a-button-that-says-record dislikes] on his blog
* [http://microrevie.ws MicroReviews] - takes Twitter posts and marks them up with [[hReview]]. The markup is descibed on the [http://microrevie.ws/technical technical page].
* [http://www.scubafreebies.com ScubaFreebies.com] - reviews websites for SCUBA divers in hReview format. For example [http://www.scubafreebies.com/review/theaquaplanet review of video site theAquaPlanet]
* [http://www.hypercasinos.com Hypercasinos.com] - offers reviews of online casinos in hReview format. For example [http://www.hypercasinos.com/content/view/27/1/ a Bodog Casino review]
* [http://www.allogarage.fr/ Allogarage] - compare 13 000 motor mechanics in France- all reviews are in hReview format.
* [http://www.lopico.com Lopico - social business directory] - local business reviews in hReview
* [http://www.rolandinsh.lv/blog Rolands Umbrovskis - Blog] marked up with hReview all blog posts, using very basic requirements (hReview -> rating), for readers rating of any post/page.
* [http://www.concertbuzz.net ConcertBuzz- Concert Reviews] uses hReview for all user submitted concert reviews. See an [http://www.concertbuzz.net/genres/classic-rock/jethro-tull.html individual review page].
* All the [http://www.westmidlandbirdclub.com/review/ West Midland Bird Club's reviews], e.g. [http://www.westmidlandbirdclub.com/review/countrymans-bedside-book.htm Countryman's Bedside Book]
* [http://www.novedge.com/ Novedge], the largest online CAD/CAM/DCC store, uses hReview for all product reviews (currently about 2000 reviews). See [http://www.novedge.com/review/1978/ single review page] and [http://www.novedge.com/Robert-McNeel/Rhino-4-0/products/2217/tab/3 multiple reviews page]. Each hReview is also visually marked with the hReview button: http://rbach.priv.at/2006/buttons/hreview.png
* [http://club.coneco.net/ Coneco Club] (in Japanese) uses hReview for all product reviews. See [http://club.coneco.net/user/4/review/4178/index.htm example]
* [http://11870.com/pro/11870 11870.com] a social network (real life del.icio.us) which implements hReview for user's reviews about places, services and business
* [http://www.mises.org/periodical.aspx?Id=2 The Mises Review], an academic journal, uses hReview for their book reviews. See [http://www.mises.org/misesreview_detail.aspx?control=317 example]
* [http://www.golfdigest.com/ Golf Digest] uses hReview on its [http://www.golfdigest.com/courses/places Course Finder] detail pages to publish user comments, ratings and geo. [http://www.golfdigest.com/courses/places/2483 example]
* [http://www.ramkol.co.il/ Ramkol] (in Hebrew) Advanced social networking based local reviews in Israel
* [http://www.popsyndicate.com/ PopSyndicate] is a groups review site for comic books, movies, dvds, music, and book using hReview and hCard.
* [http://www.mitkbh.dk/ MitKBH] (in danish) uses hReview to publish reviews of shops, clubs, bars, cafées, take-aways and restaurants in Copenhagen, Denmark. Each reviewed place has also a geo incl.[http://www.mitkbh.dk/node.php?node=238 example]
* [http://www.readandtravel.info Read&Travel] includes meta-information using hReview for travel-book reviews.
* [http://www.mangospot.dk/ Mangospot] uses hReview to publish reviews of bars, cafées and restaurants [http://mangospot.dk/Steder/245/Klassisk65-BistroVinbar.aspx example]
* [http://www.sean-johnson.com/ Sean Johnson] has started using hReview for [http://www.sean-johnson.com/2007/05/04/everyman-by-philip-roth/ book] and [http://www.sean-johnson.com/2007/05/01/feist-the-reminder/ music] reviews.
* [http://www.loudervoice.com/ LouderVoice] publishes and aggregates hReviews to/from blogs. All [http://www.loudervoice.com/search?q=hotel+cork Search/Tag Results] are also marked up with hReview.
* [http://www.bayofislands.net/ Bay of Islands] uses hReview eg. for reviews of [http://www.bayofislands.net/accommodation/apartments/edgewater-palms-apartments/#reviews Edgewater Palms]
* [http://spotspotting.com/ SpotSpotting], a site where TV commercials are reviewed and marked up with hReview (in Spanish)
* [[User:AndrewKuchling]] has added hReview to his book diary and would like to know if the markup is correct; [http://www.amk.ca/books/h/Velocity_of_Honey example 1], [http://www.amk.ca/books/h/Star_Wars_On_Trial example 2])
* [http://www.revish.com/ Revish], a book review community, uses hReview for all reviews on the site.
* [[User:EdwardOConnor]] has published several hReviews on his blog ([http://edward.oconnor.cx/2006/08/cask-room 1], [http://edward.oconnor.cx/2006/10/lud-in-the-mist 2], [http://edward.oconnor.cx/2006/11/hoboken 3], [http://edward.oconnor.cx/2006/11/basic 4], [http://edward.oconnor.cx/2006/11/legitimacy 5], [http://edward.oconnor.cx/2006/11/pizza-port 6], [http://edward.oconnor.cx/2006/12/lady-dottie-and-the-diamonds 7]).
* [http://ficlets.com/stories/12 Ficlets] story page uses hReview for user comments.
* Birder's Library, e.g. [http://www.birderslibrary.com/reviews/dvd/audubon_video_guide.htm Audubon VideoGuide to 505 Birds of North America]
* [http://www.raveaboutit.com.au Rave About It] uses hReviews for all local business reviews. In addition it uses the hCard format for a business's contact details.
**No examples on cited page
*[[User:RobCrowther]] has a number of hReviews on his blog, for example [http://www.boogdesign.com/b2evo/index.php/a/2007/02/09/webdd07_unobtrusive_javascript_with_rail this is one of a sequence of reviews of talks at WebDD07], and a [http://www.boogdesign.com/b2evo/index.php/a/2007/02/28/wsg_london_accessibility_meetup single post with three reviews].
*[http://www.volume.co.uk/main/clients/clients.aspx Volume] publishes client reviews/quotes as hReviews.
* [http://revyu.com/ Revyu] allows people to review, rate, and tag anything. Individual reviews ([http://revyu.com/reviews/0b03069358e6c718167e09119f7709dc50fb3f6e/about/html example]) are marked up using hReview.
*[http://www.globaldm.co.uk/our-clients.html GlobalDM] publishes client reviews/quotes as hReviews.
* [http://www.dishola.com/dishes/index/Austin,%20TX Dishola] publishes user reviews and ratings of dishes at restaurants, as opposed to entire "restaurant" reviews.
* [http://musicknows.com/1998/10/22/the-science-lesson MusicKnows] publishes user reviews and memories of gigs using hReview.
** hReview does not have an item
* [http://thetenwordreview.com The Ten Word Review] simply contains ten word long reviews. All reviews are marked up as hReviews, and user information is marked up as hCards.
* [http://www.halogenguides.com Halogen Guides] is an independent network of websites for wealthy consumers. Member-created reviews for [http://realestate.halogenguides.com/company/exclusive-resorts/reviews destination clubs], private jets and fractional real estate are published with hReview.
* [http://www.board-crazy.co.uk Board Crazy Skateboarding] uses hReviews for all [http://www.board-crazy.co.uk/skate-reviews.php skateboarding product reviews].
** hReviews include the rating inside of the description - 12/11/2006
* [http://local.yahoo.com Yahoo Local] now supports hReviews for all the user feedback and ratings about places in their search results
*[http://corkd.com/ Cork'd] is a community site for reviewing and sharing wine. Member-created "Tasting Notes" are published using hReview.
*[[User:ChrisCasciano]] has started using hReview in his blog postings including these reviews of [http://chunkysoup.net/article/211/TechnoratisNewToys Pingerati and Technorati Microformat Search].
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
*[http://www.judysbook.com/ Judy's Book] is a local reviews community. All reviews are published in hReview format, and all business listings and members (review authors) in the hCard format.
* [http://tech.yahoo.com/ Yahoo! Tech] has launched with hReview markup on all their reviews! Hat tips: [http://nerddawg.blogspot.com/2006/05/hreview-microformat-on-yahoo-tech.html Ashish Shetty] and [http://jeremy.zawodny.com/blog/archives/006729.html Jeremy Zawodny] both via [http://www.moskalyuk.com/blog/yahoo-tech-tip-of-the-day/1058 Alex Moskalyuk]. [http://jeremy.zawodny.com/blog/archives/006729.html#comment-27779 Alex says]: "when we launched, the press reported on 300,000 tech products in our database. Some popular items, like [http://tech.yahoo.com/pr/apple-ipod-video-30gb-black-mp3-player/1992981873 this Apple iPod], have over 200 reviews."
* [http://3spots.blogspot.com/2006/05/social-bookmarking-smarking.html 3spots: Social + bookMARKING = Smarking] has an hReview of
[http://smarking.com/ Smarking.com] (a social bookmarking service) which marks up their tagged links with [[xfolk|xFolk]].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://www.pacificspirit.com Dave Orchard] provides hreview marked [http://www.pacificspirit.com/Restaurants-Vancouver.html Vancouver Restaurant reviews]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://3spots.blogspot.com/2006/04/what-is-wikio-definitely-web-20-but.html hReview of Wikio]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
*[http://jg.typepad.com/ciel/ Joan] has published [http://jg.typepad.com/ciel/2006/02/daniel_bouluds_.html an hReview of Garçon]
** hReviews include the rating inside of the description - 12/11/2006
*[http://zipingo.typepad.com/ Zipingo Team Blog], a collaborative blog by the Zipingo Product Development Team at Intuit, used the hReview format to tag [http://zipingo.typepad.com/my_weblog/2005/12/finding_an_elec.html the backstory] of a review on a San Mateo electrician, written by one of the Zipingo team members ZipingoJim. Jim's post also links to his review on [http://www.zipingo.com Zipingo], a consumer opinion site.
** hReview does not have an item
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.debaser.it/ DeBaser.it] publishes music reviews (in Italian) supporting hReview.
* [http://blog.ftwr.co.uk/ Peter Westwood] posted an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.livejournal.com/users/danieljohn/ Daniel John] provides a [http://www.livejournal.com/users/danieljohn/58674.html scathing hReview of CIBC].
** hReview does not have an item
* [http://uk.movies.yahoo.com/movie-reviews/ Yahoo UK Movie Reviews] now supports hReview on all (>2000) reviews, e.g. [http://uk.movies.yahoo.com/h/Harry-Potter-and-the-Goblet-of-Fire/review-41195.html Harry Potter and the Goblet of Fire Review]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://adam.typepad.com/impossiblethings/ Adam Hertz] wrote hReviews of [http://adam.typepad.com/impossiblethings/2005/11/soluna.html Soluna] and [http://adam.typepad.com/impossiblethings/2006/05/cafe_gibraltar.html Cafe Gibraltar]
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.mattmcalister.com/blog/ Matt McAllister] wrote an [http://www.mattmcalister.com/blog/_archives/2005/11/16/1408893.html hReview of the TV show: "The Office"]
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.bmannconsulting.com/blog/bmann/ Boris Mann] wrote an [http://www.bmannconsulting.com/blog/bmann/doubletake-best-panorama-stitch-tool-for-mac-os-x hReview of DoubleTake, a panorama stitch tool for Mac OS X]
** hReview does not have an item
* [http://blog.ftwr.co.uk/ Peter Westwood] has written an [http://blog.ftwr.co.uk/archives/2005/10/03/blubeckers-hampton-court/ hReview of Blubeckers Hampton Court] and an [http://blog.ftwr.co.uk/archives/2006/01/05/the-fox-inn/ hReview of The Fox Inn Bucks Green, West Sussex]
** hReviews include the rating inside of the description - 12/11/2006
* [http://dougal.gunters.org/blog/ Dougal] has published an [http://dougal.gunters.org/blog/2005/08/03/french-vanilla-latte hReview of Wolfgang Puck’s Gourmet French Vanilla Latte].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* [http://www.dinnerbuzz.com/ Dinnerbuzz] is a great site for posting tagged reviews of restaurants, and they publish and summarize all their reviews in hReview!
* [http://soldierant.net/ Bryce Glass (Soldier Ant)] posted an [http://soldierant.net/archives/2005/06/product_review.html hReview of the Uniden ELBT 595 Bluetooth Cordless Phone].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
** hReviews include the rating inside of the description - 12/11/2006
* dda posted an [http://sungnyemun.org/wordpress/?p=20 hReview of hReview] :)
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* An [http://tbp.xomerang.com/?p=3 hReview of Caffè Camardo coffee].
** No hreview on page even though the page claims to be an hreview
* [http://loadaveragezero.com/hnav/contact.php Douglas Clifton] posted [http://loadaveragezero.com/#May-12-2005 comments] regarding adapting his list of ~800 [http://loadaveragezero.com/app/drx Developer Resources] as a format for evaluating hReview.
* [http://www.oliverbrown.me.uk/ Oliver Brown] [http://www.oliverbrown.me.uk/2005/05/09/sitereviewsorg-supports-hreview-i-think/ has announced] that his [http://en-us.sitereviews.org/ SiteReviews.org] (which reviews websites) publishes its reviews using hReview, e.g. here is the [http://en-us.sitereviews.org/review-photomatt.net review on SiteReviews.org for photomatt.net].
* [http://www.myelin.co.nz/post/ Phillip Pearson] is publishing hReviews in the [http://coffee.gen.nz/rss/reviews RSS feed of cafe reviews] on his [http://coffee.gen.nz/ kiwi coffee review site], which of course has the reviews in HTML with embedded hReview markup as well.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://station11.net/ticker/ Kjell] is publishing his link blog as a [http://station11.net/ticker/ list of hReviews].
** hReviews have no fn specified on the item - 12/11/2006
* [http://epeus.blogspot.com/ Kevin Marks] has [http://epeus.blogspot.com/2005_04_01_epeus_archive.html#111484565269684374 published two hReviews] and used unicode "star" characters for his ratings!
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* JamesStewart is publishing hReviews in the location pages at his [http://grwifi.net Grand Rapids WiFi site].
* [http://www.happenchance.co.uk/ Paul Livingstone] uses hreview to voice his opinion on [http://happenchance.co.uk/reading/ books] and [http://happenchance.co.uk/listening/ music].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.stuffandnonsense.co.uk/ Andy Clarke] uses hReview for his [http://www.stuffandnonsense.co.uk/general/recommended-reading.html recommended reading list].
** hReviews have no fn specified on the item - 12/11/2006
* [http://nachlin.com/ Jim Nachlin] has added hReview publishing to the CMS he uses to publish [http://daysofleisure.com/writing his blog].
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://whumpdotcom.livejournal.com/236856.html Bill Humphries] has reviewed the book "A Brother's Price" on his LiveJournal.
** hReviews have invalid item/fn markup (fn not a child of item) - 12/11/2006
* [http://www.thinkvitamin.com/ Vitamin] uses hReview on it's [http://www.thinkvitamin.com/reviews/ reviews] section (e.g. a [http://www.thinkvitamin.com/reviews/webapps/fluxiom/ review of Fluxiom]).
* [http://www.openguides.org/ OpenGuides] has support for the hReview microformat, and you can see it in action on [http://cotswolds.openguides.org/wiki/The_Plough,_Finstock this Cotswolds OpenGuide Review].
** hReview does not have an item
* [http://paulgoscicki.com Paul Goscicki] is publishing his [http://paulgoscicki.com/#wp_movie_ratings movie ratings] using hReview.
* [http://www.cellphones.ca/ Cell Phones etc.] is using hReviews for user-contributed [http://www.cellphones.ca/cell-phones/reviews/ cell phone reviews].
* [http://www.liptrot.org Adam Liptrot] publishes movie reviews using hReview and hCard. See article at [http://www.liptrot.org/journal/entries/movies_and_microformats/ Movies and Microformats].
* [http://www.webteacher.ws Web Teacher] is using hReview for book reviews in both the hReview creator format and a modified format. See a modified example at [http://www.webteacher.ws/2006/11/review-web-design-complete.html Web Design: A Complete Introduction].
** hReviews include the rating inside of the description - 12/11/2006
* [http://niftylist.co.uk/ The nifty list UK.] is using hReviews for user-contributed [http://niftylist.co.uk/mobiles/ mobile phone reviews].
** hReview does not have an item
* [http://sergiosantos.info/2007/3/books SergioSantos.info] uses hReviews for the reviewed book collection.
* [http://www.dcs-media.com/ DCS Media] converted all of their Firefox extension Reviews into hReview format. See the [http://www.dcs-media.com/fireday/default.aspx Fireday] page for extension listings.
* [http://bit.ly/iiag Is It Any Good . biz]has added hReview to all of their product reviews. See this example review of [http://bit.ly/2A3nVk Leapster2 Learning System ].

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hreview|hReview spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hreview-faq|hReview FAQ]], or raise any queries on [[hreview-issues|hReview issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.

* [http://apple.com/store Apple Store] customer reviews are marked up in hReview, as in [http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/wa/RSLID?mco=E1BD7358&fnode=home/shop_mac/mac_accessories/airport_wireless&nplm=MB053LL/A#review-RTD4T4KYJYYF9UC44 this review] of the Airport Extreme Base Station.
**'''sub-optimal''': Model numbers (?) marked up as URLs, e.g. <code><nowiki><SPAN class="url">MB053LL/A</SPAN></nowiki></code>
*loadaveragezero.com e.g. [http://loadaveragezero.com/app/drx/Data_Formats/Metadata/XMDP]
**'''invalid''': no fn (site owner informed)
* ...

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

==Related pages==
{{hreview-related-pages}}