hreview-feedback: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
Line 374: Line 374:
</div>
</div>


<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2010-04-08</span> raised by <span class="fn">Andy Root</span></span>
<div class="entry-content discussion issues">
My concern is about the way dtreviewed is handled. It is suggested that the date be wrapped in the abbr tag which is probably the most semantic. Since an ISO8601 absolute date time is NOT a friendly way to represent a date we use the abbr to represent it in a friendly manner, that makes sense. The problem is the tag is being used in the opposite manner it was intended. The friendly text should be placed in the title attribute and the abbr value should be the unfriendly (usually short) version. When a user mouses over they get the friendly version that helps the user understand the abbreviation. You see the hReview experience is opposite, the user sees an already understandable piece of information being a friendly way to represent a date but when they mouse over it they get a bunch of characters that don't make sense to them.
</div>
</div>


==Related pages==
==Related pages==
{{hreview-related-pages}}
{{hreview-related-pages}}

Revision as of 20:47, 8 April 2010

hReview Feedback

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

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter. 

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

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

  • 2005-06-21 raised by Hixie
    1. Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hReviews must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?

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 occurrence 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)?

- AlfEaton.

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

2005-12-07 I've made the following assumption from 0.2, which works pretty good and you may consider making more formal: "best"/"worst"/"rating" apply to the entire hReview object, unless they appear inside a rel-tag object, in which case they only appy to that. Since hReview seems designed to apply to one "item" at a time, this seems sufficient. -- David Janes

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.

  • Tantek reminds Ryan about the hResume discussion where we figured out how multiple hCards on a page could share a common "fn" at the top of the page by reference. Note: Tantek needs to add "write hResume draft" to his section on the to-do page.

2006-01-26

Eran Globen noted in July of 2005 that it may be good to allow for rated tags to be specified with the tag inside the rating. Combined with the "value" technique in hCard, this is quite doable. The example that Eran gave, modified just a bit to use the "value" technique: 

<ul>
  <li>
    <a href="http://en.wikipedia.org/wiki/Food" rel="tag">Food: 
     <span class="rating">18</span>/<span class="best">30</span></a>;
  </li>
  ...
</ul>

Changes to: 

<ul>
  <li class="rating">
    <a href="http://en.wikipedia.org/wiki/Food" rel="tag">Food</a>:
    <span class="value">18</span>/<span class="best">30</span>;
  </li>
  ...
</ul>

2006-01-27

In some contexts, it'd be somewhat useful for the author information to be able to be "inherited" from the review's context, e.g. perhaps a series of many, perhaps dozens, of reviews all by the same reviewer, provided together on a list, perhaps on a blog. This might be good for 0.3.

We thought of something similar for hResume, to enable hCards for each job to share a common "fn" value, derived from the individual's name at the top of the resume.

We could also use such a "sharing of data" concept for hAtom, so that the authors for entries are by default the authors for the blog, unless otherwise specified. - Tantek

  • We have now done this for hReview 0.3 via the object include-pattern Thanks. Tantek

2006-02-07

In the extended Crepes on Cole example, the reviewer name is anonymous, but is not so indicated by adding fn to the list of classes on the enclosing element. Is this correct? I don't think so. - Rohit

  • This has been corrected in hReview 0.3. Thanks. Tantek

2006-02-23

What's the rationale for making dtreviewed required? I think (as pointed out earlier) there are valid cases where it's omitted from the page markup (either because it's inferred from the HTTP Last-Modified date, or because a review date isn't relevant or available).

  • This was an unintentional omission from hReview 0.3, and has been corrected. Please take another look. Thanks. Tantek

2006-03-06

At postgenomic.com (an aggregator/analysis engine for life science weblogs), an attempt to get people to add markup to their posts to identify reviews of papers currently recommends using either a) rev="review" on the outgoing link, or b) to enclose the review in <div class="hreview"> and add class="url" to the outgoing link.

Because of the way the reviews can be structured (generally just free text, without extra citation metadata), the separation between 'item' and 'description' doesn't really fit. Could it be acceptable to just use class="url" on the outgoing link to imply that as the subject of the review, without using either 'item' or 'description'? -- AlfEaton

2006-09-20 What about marking up prices, using the currency proposal? - Andy Mabbett

2007-07-26

What are the optional and what are the required fields? - Mahesh

2007-11-30

Created three 3D Markup Maps for hReview microformats examples used in the Wiki to better understand the relationship of HTML elements and apply CSS rules:

  1. hReview Microformat 3D Markup Map for Products
  2. hReview Microformat 3D Markup Map for Movies
  3. hReview Microformat 3D Markup Map for Restaurants

-- Christopher Schmitt

2008-01-20

Item type considered harmful.

Unlike the other parts of the hreview spec, the type item requires that its contents be particular English language words that are meant for display to the reader of the page (as per the microformats principles of presentable and parsable). Clearly, this is inappropriate for any page that is not written in English. Defining synonyms for every specified type in every language is not realistic, either. So, we have a problem.

I suggest that the type item be dropped altogether. In reality it is redundant, as the reader of the page should be able to tell what sort of item is being reviewed from the review text itself, grouping of like reviews is possible through the URL item reference or any embedded tags, and it is not clear what computer processing purpose is being served by the level of granularity in the spec. For example, an hReview search for "product" is probably too coarse, potentially grouping together reviews of movies, books, songs, soft drinks, shoes or other products with the same name.

As this part of the spec would appear to have few (if any?) benefits, and a couple of clear problems (i.e. breaks for non English language, need to display redundant information to reader), it does not sit comfortably within the spirit of simplicity or extensibility that microformats promote, and should be removed from future versions of the spec.

- Andrew

  • This is another case where titles on spans, with a "data" flag, could be applied:
<span class="type" title="data: book">livre</span>
Andy Mabbett 08:43, 20 Jan 2008 (PST)
    • I don't think this is a good application. In this case, the value used by the microformat parser is different to the value that a human viewer of the page sees. Doesn't this violate one of the principles of microformats? Also, what if search engines are optimised for certain types of data - wouldn't this create an incentive for authors to misreport the type? Can anyone come up with a compelling reason to even have the type item? There seem to be plenty of reasons to drop it. - Andrew
      • "wouldn't this create an incentive for authors to misreport the type" - no more so than the current "abbr-pattern". Andy Mabbett 12:17, 10 Feb 2008 (PST)
        • The abbr tag displays both the abbreviated and full text to the user (with all modern browsers that I've come across anyway), so there is no hiding of the values. It's not the same as what you're proposing with a title on a span, which is typically not displayed to the user. Note that if it was displayed to the user, it would display something in potentially the wrong language, e.g. hover over "livre" and see "book". - Andrew 18:28, 21 Mar 2008 (UTC+11)
          • The ABBR element is not special in displaying its title as a tooltip. A, IMG, SPAN, DIV, EM, STRONG, TABLE, UL... they all do. The two practical differences between ABBR and SPAN are that some browsers include a dotted bottom border on ABBR by default; and that screen-readers will usually read the title instead of the contents (i.e. the content is invisible to them) of ABBR. In the case of the example above, I would say that neither of those features of ABBR is desirable here - the dashed bottom border would be puzzling to most readers; and the reading of an English word in the midst of a French review, disorienting. The third difference between ABBR and SPAN is the semantic difference - the difference in meaning. SPAN doesn't have much meaning, or rather the author can use SPAN to mean anything they want; ABBR means "this is an abbreviation". "Livre" is certainly not an abbreviation for "book", so ABBR is once again the wrong element for the job. TobyInk 00:44, 21 Mar 2008 (PDT)
        • Yes, there are either two ways this could go. Either it is displayed (like the ABBR tag) which would be inappropriate. Or it is not displayed, which would be against the principles of microformats. I think this issue is intractable, and the simplest solution would be to remove the "type" item from the spec. Andrew 18:28, 24 Mar 2008 (UTC+11)

2008-02-25

I have a question regarding the product hReview, but applicable to any type: On a product review page with user generated ratings (many ratings, aggregated in a single page), is there any way to have all the ratings on the hReview Microformat ? (maybe make a <li> for the rating and reviewer fields...)
I think a valid workaround is to set an average rating and not specifying the reviewer (anonymous reviewer). But somewhat this limits the value of the user generated ratings.

Jaume Suñol 17:02, 25 Feb 2008 (PST)
  • Think outside the box. Instead of: 
    <div class="hreview">
  <p class="item">...</p>
  <p class="description">...</p>
  <ul>
    <li class="rating">Thomas' rating</li>
    <li class="rating">Richard's rating</li>
    <li class="rating">Harold's rating</li>
  </ul>
</div>

    use: 

    <div id="thingy">
  <p class="item">...</p>
  <p class="description">...</p>
</div>
<ul>
  <li class="hreview">
    <a href="#thingy" class="include">Thingy</a>
    <span class="rating">Thomas' rating</span>
  </li>
  <li class="hreview">
    <a href="#thingy" class="include">Thingy</a>
    <span class="rating">Richard's rating</span>
  </li>
  <li class="hreview">
    <a href="#thingy" class="include">Thingy</a>
    <span class="rating">Harold's rating</span>
  </li>
</ul>

    Using include-pattern but turning it on its head, to pull the review into the ratings rather than pulling the ratings into the reviews. TobyInk 08:43, 25 Feb 2008 (PST)

open issue! 2009-08-31 raised by http://life-user.blogspot.com

  • Artists, albums and songs. I write music reviews on my blog, and I'd like to be able when I review an album to indicate the artist, when I review a song to indicate the artist and album(s). I'd also prefer it if I could nest individual song reviews inside the description element of an album review; for instance, in http://life-user.blogspot.com/2009/08/blunder-in-sky.html, I have several paragraphs that each talk about a song.

open issue! 2009-08-31 raised by http://life-user.blogspot.com

  • Best and worst X lists. My article http://life-user.blogspot.com/2009/08/best-manowar-songs.html contains fourteen reviews, all of which have two things in common: they're all unequivocally favourable, and they're all of Manowar songs. It would be useful to be able to make each <li> an hReview without having to use redundant elements to indicate these things.


open issue! 2009-12-25 raised by Ol'ga

Hello all! We are creating service that takes structured data from numerous partners. We’d like them to use some wide-spread format not to create something for us exclusively. That why microformats were chosen. But standard hReview fields are not enough for all our tasks. We need some extra classes, but would like to keep the integraty of the format so that any valid parser could process markup correctly. So would you be kind enough to suggest something on the following issues.

1. Our services need more precise classification of types than hReview allows. Recommendation to use rel-tag seems not applicable to our case as is. The product category may be not a visible text on the page. Is should be placed only for parser to understand some peculiarities of future processing. What can you suggest in this case?

2. We need to distinguish reviews of ordinary users and of professionals. At the same time there may not be any other data about reviewer, so it is not clear how to use hCard for this.

Thank you very much for any help in advance! And excuses if answers for such questions already exist here.

open issue! 2010-04-08 raised by Andy Root

My concern is about the way dtreviewed is handled. It is suggested that the date be wrapped in the abbr tag which is probably the most semantic. Since an ISO8601 absolute date time is NOT a friendly way to represent a date we use the abbr to represent it in a friendly manner, that makes sense. The problem is the tag is being used in the opposite manner it was intended. The friendly text should be placed in the title attribute and the abbr value should be the unfriendly (usually short) version. When a user mouses over they get the friendly version that helps the user understand the abbreviation. You see the hReview experience is opposite, the user sees an already understandable piece of information being a friendly way to represent a date but when they mouse over it they get a bunch of characters that don't make sense to them.

Related pages

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