hcomment

From Microformats Wiki
Jump to navigation Jump to search

This page is deprecated because it doesn't follow the process, but it is left here for historical purposes.

This page needs a major rewrite/edit. It appears to mostly be content copied from hReview without removing the hReview-specific content such as the draft spec note, date, authors, etc. This can be fixed by:

  • Analyze what aspects are "comment" specific (rather than just copied from hReview)
  • Extract comment-specific ideas/thoughts etc., and place them by themselves into a comment-brainstorming page.
  • Reference hAtom for possible additional comment brainstorming (i.e. how to markup blog comments (in addition to posts) with hAtom).
  • Leave a redirect from this page to comment-brainstorming

Tantek 15:18, 29 Jan 2008 (PST)

hComment 0.1

hComment is a simple, open, distributed comment format suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. hComment is one of several microformats open standards.

Draft Specification 2005-06-22

Editor

Authors

Introduction

In order to enable and encourage the sharing, distribution, syndication, and aggregation, of comments, the authors propose the hComment MicroFormat, an open standard for distributed comments.

A "comment" is a block of text which allows a user to express an opinion, thought, or other feedback about a particular content object (an article, blog entry, event, venue, product, etc.).

At present, every website has its own way of rendering comments into XHTML, making intra-site comment sharing, searching, and aggregation difficult. Trackbacks have shown the potential of intra-site discussion. Why not allow all comments to jump the chasm too?

Note: this standard is a reformulation of the hReview Microformat.

Relationship between hComment and hReview

A "review" is simply a comment with additional properties such as a rating or a specific object reference. Numerous web sites publish reviews using a broad variety of schema for all sorts of things from products (movies, music, books), to businesses (restaurants, hotels, stores), to events (concerts, theatre), to people (artists, leaders, celebrities), to places (landmarks, parks), to online resources (web pages, files), to reviews of reviews themselves.

Since reviews and comments overlap so substantially, they should share a common microformat standard. So, instead of two mutually exclusive standards which contain 98% of the same functionality, hReview will be expressed in terms of hComment.

Expressing hReview in terms of hComment

If hReview v0.3 is to be expressed in terms of hComment, here's what would need to be done:

  • Remove tags, permalink, description, summary, item type, item info, as they're now in hComment
  • Retain rating, as it's not in hComment
  • Remove reviewer and dtreviewed in favor of hcomment's poster and dtposted
    • transition can have dual-classing: class="dtposted dtreviewed" is fine
  • Deal with version being present in both somehow

Working Name

The name "hComment" is a working name for this microformat. The name was suggested as it shares much with the hCard and hCalendar microformats, despite not having an IETF RFC to reference for a normative schema.

Copyright

This specification is (C) 2005 by the authors. However, the authors intend to submit (or already have submitted, see details in the spec) this specification to a standards body with a liberal copyright/licensing policy such as the GMPG, IETF, and/or W3C. Anyone wishing to contribute should read their copyright principles, policies and licenses (e.g. the GMPG Principles) and agree to them, including licensing of all contributions under all required licenses (e.g. CC-by 1.0 and later), before contributing.

Patents

This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.

Inspiration and Acknowledgments

Thanks to everyone who responded to the open call for implementor participation for hReview. The authors in particular wish to thank the following individuals for their constructive input and feedback: Richard Ault, Danny Ayers, Jeffrey Barr,Adrian Cuthbert,Jason DeFillippo, Brian Del Vecchio, Scott Derringer, Bud Gibson, Joi Ito, Gen Kanai,Niall Kennedy, Rohit Khare, Ryan King, Jonas Luster, Kevin Marks, Derek Powazek, Jeff Rodenburg, David Sifry, James Stewart, Adriaan Tijsseling, Phillip Torrone, Thai Tran, Phillip Winn, YAMAMOTO Yohei.

Scope

Comments consistently share several common fields. Where possible hComment has been based on this minimal common subset.

Out of scope

Fields that are type-specific have been omitted from hComment. It is important that hComment be kept simple and minimal from the start. Additional features can be added as deemed necessary by practical implementation experience.

The concept of a "universal object identifier", that is, how to identify the same object/item/product across different shopping sites, though something very useful to have, is outside the scope of this format.

Semantic XHTML Design Principles

XHTML is built on XML, and thus XHTML-based formats can be used not only for convenient display presentation, but also for general-purpose data exchange. In many ways, XHTML-based formats exemplify the best of both HTML and XML worlds. However, when building XHTML-based formats, it helps to have a guiding set of principles.

  1. Reuse the schema (names, objects, properties, values, types, hierarchies, constraints) as much as possible from pre-existing, established, well-supported standards by reference. Avoid restating constraints expressed in the source standard. Informative mentions are ok.
    1. For types with multiple components, use nested elements with class names equivalent to the names of the components.
    2. Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.
  2. Use the most accurately precise semantic XHTML building block for each object etc.
  3. Otherwise use a generic structural element (e.g. <span> or <div>), or the appropriate contextual element (e.g. an <li> inside a <ul> or <ol>).
  4. Use class names based on names from the original schema, unless the semantic XHTML building block precisely represents that part of the original schema. If names in the source schema are case-insensitive, then use an all lowercase equivalent. Components names implicit in prose (rather than explicit in the defined schema) should also use lowercase equivalents for ease of use. Spaces in component names become dash '-' characters.
  5. Finally, if the format of the data according to the original schema is too long and/or not human-friendly, use <abbr> instead of a generic structural element, and place the literal data into the 'title' attribute (where abbr expansions go), and the more brief and human-readable equivalent into the element itself. Further informative explanation of this use of <abbr>: Human vs. ISO8601 dates problem solved

Format

In General

The hComment format is based on a set of comment fields common to numerous websites, blogs, and other content in use on the web today. Where possible field names have been chosen based on those defined by the related hCard, hCalendar, and hReview standards.

Schema

The hComment schema consists of the following:

  • hComment
    • version. optional. text.
    • summary. optional. text.
    • item type. optional. product | business | event | person | place | website | url.
    • item info. required. (fn || url || photo ) | hCard (for person or business).
    • poster. required. hCard | fn | email | url.
    • dtposted. required. ISO8601 absolute date time.
    • description. optional. text with optional valid XHTML markup.
    • tags. optional. keywords or phrases, using RelTag, each with optional rating.
    • permalink. optional.

Field details

The fields of the hComment schema represent the following:

version:: This optional field permits hComment publishers to specify a particular version of hComment that their content uses. By omitting this field, the publisher is stating that implementations may interpret the hComments according to any version of the hComment specification v0.1 or later. In practice the authors of this specification are comitted to maintaining backward compatibility with content produced using earlier versions of the specification. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.1".

summary:: This optional field serves as a title for the comment itself.

item type:: This optional field "type" provides the type of the item being commented upon, one of the following: product, business, event, person, place, website, url.

item info:: This optional field, when present, MUST have at a minimum the name ("fn" - the formatted text corresponding to the name) of the item, SHOULD provide at least one URI ("url") for the item, and MAY provide at least one URL to a photo or depiction ("photo") of the item. For items of type person or business, the item info (fn, url, photo) SHOULD be encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item. When an hComment lacks this field, the hComment is implicitly assumed to be a comment on the page on which it appears.

poster:: The person who authored the comment. An hCard representing the poster SHOULD be provided with full name and URL. Alternatively, just a name, email address, or URL to the person MAY be provided. To specify more than one of those, encapsulate them in an hCard. For anonymous comments, use "anonymous" (without quotes) for the full name of the poster.

dtposted:: This required field MUST provide an ISO8601 absolute date time of when the comment was written or otherwise authored. This field SHOULD use UTC, but MAY use the time zone offset syntax.

description:: This optional field contains the full text representing the written opinion of the poster. The field MAY include valid XHTML markup (e.g. paragraphs). User agents SHOULD preserve any markup. Multiple descriptions or section descriptions (e.g. pros and cons, plusses and minusses) SHOULD be included in the description field.

tags:: Tags are represented using a list of keywords or phrases (using the RelTag microformat for each individual keyword or phrase tag) that the poster associates with the item. Authors MAY enclose all tags for a comment inside an element with a specific classname, e.g. "categories" (from vCard RFC2426 and iCalendar RFC2445), but are not required to do so.

permalink:: This optional field is a URL for the hComment. In addition to using the <a href> tag for this field, the attribute rel="self bookmark" MUST be used to indicate that the hyperlink is a permalink for the comment itself. If the hyperlink already contains a rel attribute, then the values self and bookmark MUST be included among the space-separated set of values in the attribute. Indexers MAY treat the permalink of a comment as a unique ID in order to identify and collate the same comment from multiple sources (such as indexing a page multiple times). The permalink MAY also be used to indicate or imply the origin of the comment. Authors MAY use the classname of "permalink" on the element representing the permalink, but are not required to do so.

The following field names have been reused from the hCard and hCalendar microformats: version, summary, fn, url, email, photo, description, categories. In addition, items and posters described by hCards MAY contain any hCard field.

More Semantic Equivalents

For some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:

  • For any "url", use <a class="url" href="...">...</a> inside the element with class="hreview" in hComment.
  • Similarly, any "email", use <a class="email" href="mailto:...">...</a>
  • And for "photo", use <img class="photo" src="..." alt="Photo of ..." />

Language

  • To explicitly convey the natural language that an hComment is written in, use the standard (X)HTML 'lang' attribute on the element with class="hcomment", e.g.
    ...
    If portions of an hComment (e.g. the item name) are in a different language, use the 'lang' attribute on those portions.
  • hComment processors which need to handle the language of comments MUST process the standard (X)HTML 'lang' attribute as specified.

Human vs. Machine Readable

If an <abbr> element is used for a property, then its 'title' attribute is used for the value of the property, instead of the contents of the element, which can then be used to provide a user-friendly alternate presentation of the value.

Similarly, if an <img /> element is used for one or more properties, it MUST be treated as follows:

  1. For the "photo" property and any other property that takes a URL as its value, the src="..." attribute provides the property value.
  2. For other properties, the <img /> element's 'alt' attribute is the value of the property.

Notes

This section is informative.

  • By marking up a comment with the hComment microformat, the expectation is communicated that the comment MAY be indexed. This has no impact on the copyright of the comment itself.
  • The enumerated list of item types is under development and may be extended.
  • Each type may have custom hComment fields that follow the common set.
  • Additional details about a particular item should be specified with the rest of the item's info at the URL provided for the item.

Examples

Here are a few examples of comments from current web sites, and how they could be easily enhanced to support the hComment structured comment microformat.

Blog comments

Here is an example of a simple blog comment (based on a real blog comment from here): 

<div id="comment-9">
<cite><a href='http://http//9rules.com' rel='external nofollow'>Mike</a></cite>:
<br />
<p>Microformats sound cool, thanks for the great site guys!
</p>
<p class="com-meta"><a href="#comment-9" title="">June 22nd, 2005 at 9:28 am</a> </p>
</div>

Adding hComment to this comment is quite simple: 

<div class="hcomment" id="comment-9">
<cite class="poster vcard"><a class="url fn" href='http://http//9rules.com' rel='external nofollow'>Mike</a></cite>:
<p class="description">
Microformats sound cool, thanks for the great site guys!
</p>
<p class="com-meta"><a class="dtposted url" href="#comment-9" title="20050622T0928Z">June 22nd, 2005 at 9:28 am</a></p>
</div>

Examples in the wild

This section is informative.

The following sites have published hComments, 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 hComments on your own page, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

[Coming soon!]

Implementations

This section is informative.

The following implementations have been developed which either generate or parse hComments. If you have an hComment implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

References

Normative References

Informative References

Similar Work

Work in progress

This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

Changes from hReview v0.2

The following changes have been made in hComment v0.1:

  1. removed rating field
  2. changed reviewer to poster
  3. changed dtreviewed to dtposted
  4. removed many examples :(

Feedback

Retrieved from "http://microformats.org/wiki/index.php?title=hcomment&oldid=31344"