hreview-brainstorming: Difference between revisions
Jump to navigation
Jump to search
AndyMabbett (talk | contribs) (add related pages template) |
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
||
(8 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE: hReview brainstorming }} | |||
; Editor/Author: [http://tantek.com Tantek Çelik] | ; Editor/Author: [http://tantek.com Tantek Çelik] | ||
Line 5: | Line 5: | ||
This document is for capturing thoughts on improving/iterating upon [[hreview|hReview]]. | This document is for capturing thoughts on improving/iterating upon [[hreview|hReview]]. | ||
== hReview 0.4 thoughts == | |||
* items of <code>type</code> <code>place</code> SHOULD use a nested [[geo]] or [[adr]] or [[hcard|hCard]] as the item itself. | |||
* items of <code>type</code> <code>url</code> MUST specify a <code>url</code> property for the item (in hReview 0.3 having "url" property for the item is only a SHOULD) | |||
* note that in the future, items of <code>type</code> <code>product</code> SHOULD use a nested [[hProduct]]. | |||
* note and clarify that item <code>type</code> of "url" means the review applies to *only* the resource present at that URL, whether it is an HTML page, an image, an mp3, whatever. Whereas item type of "website" applies to everything at that URL and contained in any subdirectories thereof. | |||
* consider deprecating the <code>version</code> property. is the <code>version</code> property needed? currently it is optional and created invisibly by the [http://microformats.org/code/hreview/creator hReview creator]. It is not clear that it is necessary for parsing either, since all changes to hReview have been forward/backward compatible and it is our goal to continue to make compatible changes. | |||
* is the <code>type</code> property needed? It too is created invisibly by the [http://microformats.org/code/hreview/creator hReview creator]. | |||
* drop <code>self</code> from the <code>permalink</code>. Even [[hatom|hAtom]] just uses <code>bookmark</code>, so should hReview. | |||
* should allow multiple license - switch to using [[item-license]]. | |||
* item type fallback. If the expected encapsulated microformat for a given item type (e.g. business / hCard) is not present, then fall back to parsing for item sub properties and construct an implied encapsulated microformat from those subproperties. Alternative, just take the fn, url, photo subproperties that are present as is, and don't bother to imply an hCard. | |||
* implied "fn" inside item. if there is no "fn" then treat the entire "item" as an "fn". | |||
* if available the user shoul be able to specify a product id, such as an ISBN for books. (valid as long as no. 3 is open) | |||
* incorporate {{must}} implement [[value-class-pattern]]. | |||
* consider adopting (for "skill" elements) category+[[rel-tag]] pattern like [[hCard]] and [[hCalendar]], don't require rel-tag. | |||
** same issue for [[hResume]], [[hReview-aggregate]], [[hListing]], [[hProduct]] | |||
** perhaps make category+rel-tag into a pattern for re-use. | |||
== archive == | |||
=== hReview 0.3 thoughts === | |||
This iteration of hReview is directly in response to [[hreview-feedback]] and [[hreview-issues]]. See those documents for more details. | This iteration of hReview is directly in response to [[hreview-feedback]] and [[hreview-issues]]. See those documents for more details. | ||
Line 28: | Line 47: | ||
* Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. what does Food:18/30 mean? | * Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. what does Food:18/30 mean? | ||
==Related pages== | ==Related pages== | ||
{{hreview-related-pages}} | {{hreview-related-pages}} |
Latest revision as of 16:27, 18 July 2020
- Editor/Author
- Tantek Çelik
This document is for capturing thoughts on improving/iterating upon hReview.
hReview 0.4 thoughts
- items of
type
place
SHOULD use a nested geo or adr or hCard as the item itself. - items of
type
url
MUST specify aurl
property for the item (in hReview 0.3 having "url" property for the item is only a SHOULD) - note that in the future, items of
type
product
SHOULD use a nested hProduct. - note and clarify that item
type
of "url" means the review applies to *only* the resource present at that URL, whether it is an HTML page, an image, an mp3, whatever. Whereas item type of "website" applies to everything at that URL and contained in any subdirectories thereof. - consider deprecating the
version
property. is theversion
property needed? currently it is optional and created invisibly by the hReview creator. It is not clear that it is necessary for parsing either, since all changes to hReview have been forward/backward compatible and it is our goal to continue to make compatible changes. - is the
type
property needed? It too is created invisibly by the hReview creator. - drop
self
from thepermalink
. Even hAtom just usesbookmark
, so should hReview. - should allow multiple license - switch to using item-license.
- item type fallback. If the expected encapsulated microformat for a given item type (e.g. business / hCard) is not present, then fall back to parsing for item sub properties and construct an implied encapsulated microformat from those subproperties. Alternative, just take the fn, url, photo subproperties that are present as is, and don't bother to imply an hCard.
- implied "fn" inside item. if there is no "fn" then treat the entire "item" as an "fn".
- if available the user shoul be able to specify a product id, such as an ISBN for books. (valid as long as no. 3 is open)
- incorporate MUST implement value-class-pattern.
- consider adopting (for "skill" elements) category+rel-tag pattern like hCard and hCalendar, don't require rel-tag.
- same issue for hResume, hReview-aggregate, hListing, hProduct
- perhaps make category+rel-tag into a pattern for re-use.
archive
hReview 0.3 thoughts
This iteration of hReview is directly in response to hreview-feedback and hreview-issues. See those documents for more details.
Changes from hReview 0.2:
- MUST (instead of SHOULD) use hCard for the item description of a business
- reviewer changes
- make reviewer *optional* per feedback from Ryan King and Mark Nottingham
- If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer. If there is no "reviewer" outside either, then use the
<address>
for the page. - MUST (instead of SHOULD) use hCard to represent reviewer information
- SHOULD use hCalendar to represent an item of 'type' 'event'
- Accepted. We considered making this a MUST, and postponed it to the next version, based on publication experience with 0.3
- add one decimal digit of precision to ratings' numerical values.
- use the "value" construct from hCard (as it is used in "tel" properties for example) to more explicitly markup the rating value when also providing (marking up) the best/worst of a rating. need to also provide an example that does so.
- add rel-license to indicate the license of the hReview as a whole.
- add this to hatom as well!
- permit tags inside ratings to denote rated tags, the same as ratings inside tags per suggestion from Eran Globen.
- add include-pattern support to allow multiple reviews for the same item to not repeat the item info.
Informative improvements:
- Note that scalar/rated tags would ideally use a tag space that explain the ratings for that tag. E.g. what does Food:18/30 mean?
Related pages
- hreview
- hReview-aggregate - microformat for specifying summary information from a collection of reviews about a product or service
- hReview creator (feedback) - create your own hReview.
- hReview authoring - learn how to add hReview mark-up to your existing contact info.
- hReview brainstorming - thoughts for improving hReview.
- hReview cheatsheet - hCard properties.
- hReview examples in the wild - an on-going list of websites which use hReview.
- hReview FAQ - If you have any questions about hReview, check here, and if you don't find answers, add your questions!
- hReview feedback - Feedback is encouraged!
- hReview implementations - websites or tools which either generate or parse hReviews.
- hReview issues - Please add any issues with the specification to the issues page.
- hReview parsing - Normatively details of how to parse hReviews.
- hReview profile - The XMDP profile for hReview.
- hReview tests - a wiki page with actual embedded hReviews to try parsing.
- hReview advocacy - encourage others to use hReview.
- review-examples
- review-formats
- review-brainstorming - where we brainstormed about review formats before coming up with hReview.
- currency - proposal for marking up amounts of money (e.g. prices of reviewed items).
- Aggregate reviews - examples - formats - brainstorming