hreview-feedback

From Microformats Wiki
Revision as of 16:33, 7 December 2005 by Tantek (talk | contribs)
Jump to navigation Jump to search

hReview Feedback

This document is for keeping track of feedback about hReview, one of several MicroFormats.

Feedback

General Questions

See the hReview FAQ.

General Comments

April 30, 2005:

Nice work :-) Some questions:

For the most part, the concept of the format's "fields" translates, in any particular case, to the field name appearing in the class attribute of an element, and the field value appearing in the text of the element. Right?

Can it be generally stated that it doesn't matter which elements these class/fields are attached to? If not, what are the specific constraints?

It'd be useful to outline any cases where:

  • fields or values appear in other attributes (e.g., class="type" title="business")
  • an element indicated as a field can contain more than text, or a mix of text and other elements (e.g., some of the 1 of 5 type rating span examples)

Also, what is the constraint about class attributes containing multiple values where one is a field name (i.e., I assume you're not supposed to put two field names in the same class--but, what is the extent of the constraint? Can multiple class values be used as long as they don't look like two field names?)

See hcard-parsing which answers these questions. -Tantek


Also (rel-tag question), does rel-tag support this kind of eleaborate label (where the tag indicated element has more than just a text value that exactly matches the last part of the uri?): 

<li><a href="http://flickr.com/photos/tags/Price" rel="tag">
Price: <abbr class="rating" title="2">$$</abbr>...</a></li>

Doesn't RelTag significantly constrain what appears enclosed within the A element? i.e., (from Technorati's tag description:) 

 <a href="http://technorati.com/tag/[tagname]" rel="tag">[tagname]</a>

-Jay Fienberg

</nowiki>

See the rel-tag spec. The last segment of the URL is the tagname, not the contents of the element. The Technorati help page is only providing suggested markup. See the spec for normative details. -Tantek


I don't know how widespread it is to have summaries of a review in one place and then point to them in another, but that's something I do on one of my sites, where reviews are accepted by trackback (eg. | this page). I've blogged a possible markup for that | here

- JamesStewart


Thus the "description" is optional, and you can provide a URL permalink back to the original. -Tantek

I've added some items to the FAQ page (hReview FAQ) Please take a look at them and feel free to clarify or modify.

-RyanKing

I've been following the evolution of microformats on Technorati with great interest and hReview seems to really break new ground. Reviews represent something big enough that they have their own identity, they can be 'referenced'. In contrast hCard and hCalendar seem to be more of a 'pass-by-value' proposition (I've ammended my SmartTag + AutoLink = SmartLink experiment to support hCalendar). To that end I was surprised at the specification. I've explained things more fully here

-Adrian Cuthbert

Has anyone considered list context? I have adapted my Developer's Resource Index, which is in essence a list of reviews, to use the hReview spec. However, is it appropriate to set the entire list as &lt:dl class="hreview">, or each individual item by wrapping the <dt>/<dd> pairs in a <div> (which is the approach I took)?

Follow-up: scratch that last comment: Since I'm using XHTML 1.1,

is not allowed in this context. Which of course brings me back to the original question. Hmm...

Have a look at an example of the code if you'd like: Markup Languages. I will post this URI to del.icio.us tagged as hreview as well.

Douglas Clifton

Shouldn't it be mentioned somewhere in which language the review is written in? Is it just a slip of the mind, or a very US-centric attitude, dude? I don’t think adding language info would be out of scope, as it would help filter out unwanted languages from search queries; plus, Ce n’est pas parce que mon blog est en anglais, 꼭 英語만 쓰는 것이 아니다… What if I wanted to post the same review in different languages, or quote something in another language..?

dda

Thanks for your input. This was made explicit and resolved by hReview 0.2, specifically: hReviews and language -Tantek

A sample xhtml fragment of "Multidimensional Restaurant Review" is not valid XML format.

original: 

 This 
 <a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</a>

correct: 

 This 
 <a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</a>

YAMAMOTO Yohei

Thanks for the feedback Yamamoto, that was my typo and the example has been corrected. - Tantek

Should the 'type' field be expanded? What is the proper type for reviewing a movie seen in a cinema? Of the existing values, 'event' would seem to apply best, but it's not completely intuitively obvious, especially since 'product' could also apply.

Compare to reviewing a movie on DVD. One might be tempted to use the 'product' type. But what is really the product here -- the film being viewed, or its packaging? Again, 'product' doesn't seem intuitively obvious, as it would seem to apply to more utilitarian objects, rather than to ephemera like movies or music.

I suggest the following:

'event' should specifically be defined to mean an occurence in a particular time/location frame, experienced in person (live concerts, trade shows, sporting events, etc).

'product' should similarly be narrowed down in some fashion. In some cases, it might be difficult to decide whether one is reviewing a 'business', or their 'product'. And where does the concept of a 'service' fall? These ideas are sometimes closely related, and other times quite separate.

'media' should be added to cover reviews of artistic creations (music, films, literature, art) which may appear in non-unique formats (viewed in person, DVD, CD, TV, radio, magazines, art galleries, etc).


Dougal Campbell 10:28, 26 Jul 2005 (PDT)

Dougal, this was already answered in the FAQ a while ago as the first question! -Tantek


The rating field, at the moment, is mandated to be an integer. Is there a particular reason for this (which seems like an unnecessary restriction)?

- Alf Eaton.

First, the rating field is based on current actual review/rating data published on the web, which for the most part is integer. There have been several requests for allowing one decimal digit of precision, since that broader definition would include many more (90%+ at least) reviews on the web, it is being considered for hReview 0.3.

Second, "unnecessary restriction" is looking at it from the complete wrong perspective. "unnecessary axis of freedom or extensibility" is the thing to avoid, because that is the antithesis of simplicity, and causes more work for everyone involved, testing, developing etc. Premature generality is a common mistake made by engineers, and microformats explicitly seeks to avoid it.

- Tantek

Consider for hReview 0.3:

  • make it explicit that a review of an event (see item types list) SHOULD use hCalendar to represent the item, just as a review of a company or person SHOULD use hCard. - Tantek
  • now that hCard, hcard-parsing, and hcard-profile are solid, change SHOULD to MUST for
    • item description of a business MUST use an hCard
    • reviewer information MUST be represented by an hCard

2005-10-06 Tantek Çelik and Ian McAllister discussed the above changes for hReview 0.3 and agreed that they should be in hReview 0.3.

  • add one decimal digit of precision to ratings per discussion above. Matt Mullenweg has also asked for this based on his experience at CNET and their reviews.

2005-11-29 Tantek Çelik and John Panzer discussed the above changes for hReview 0.3 and agreed that they should be in hReview 0.3.

2005-12-07 As pointed out by David Janes, there needs to be a more explicit way to markup the best/worst of a rating, and an example provided that does so, e.g.:

I think to convey the scale of an overall rating, we may need to borrow the "value" construct from hCard (as it is used in "tel" properties for example). E.g. 

<p class="rating">
On Fred's <span class="best">4</a> ICBM scale, I give this a <span 
class="value">2</a>.
</p>

- Tantek Çelik

Some comments:

  • There is no mention of any sort of credibility attached to a review in this specification. Most review sites today indicate how many users found the review helpful, etc, which I consider critical information to attach any credibility to the review. This can also be considered a review of a review, and allow for embedded hReviews.
    • Response: The URL from which the hReview is obtained can be used to lookup a credibility of that URL/domain/blog as a source in general. It's not clear this should be in the review itself.
  • I don't understand why the 'item type' field is restricted. What if I want to write reviews for job desriptions? Is my only option the URL type?
    • Please see the hReview FAQ about using tags for more specific items.
  • Shouldn't we have the 'origin' field as mandatory? If not specified, this may lead to duplicate reviews on a site that crawls multiple sites which in turn crawl eachother.
    • The permalink field solves this problem.
  • -Sapna
    • - Tantek Çelik

2005-10-20 David Sifry suggested adding a license feature so that companies could explicitly state the license/copyright of the review (e.g. CC license, or All Rights Reserved etc.).

  • The question is, is such a license feature something that all microformats need? And thus perhaps we need to figure out how to extend / update rel-license to apply to any microformatted chunk of data - Tantek Çelik

2005-11-30 RyanKing wonders whether requiring reviewer might be too much in some cases. For example, he wrote a review, on his own blog, but had to include his name in the post text.

Retrieved from "http://microformats.org/wiki/index.php?title=hreview-feedback&oldid=3047"