[uf-discuss] Request for feedback: Using hReview with barcode-scanning mobile devices.

Erik Hermansen erikh at ethicalspender.org
Wed Oct 8 18:49:10 PDT 2008


My group is putting together a system specification, called "IPORR",
that works like this:

1. A webmaster (or other person editing HTML content) puts hReviews on
his website that have a few extra requirements for their formatting
beyond what hReview specifies.
2. The webmaster notifies us that he has these IPORR-friendly hReviews
on his site.
3. We crawl the website, generate an index to hReviews, and make that
index publicly accessible through a REST interface.
4. People come to our website where the available hReview sources are
categorized and choose the ones they like.
5. Those people's mobile devices are configured to listen to the
chosen hReview sources.
6. When the people are out shopping, they scan barcodes for products
in which they interested.
7. hReviews from chosen sources download from the internet and onto
their mobile devices, giving them immediate advice on spending

I've completed instructions for the webmaster to use in publishing an
IPORR-friendly hReview.  They can be found at this URL:


You might be wary of an "embrace and extend" tactic creating lots of
nasty, incompatible hReview mutants.  But keep in mind we are just
adding extra restrictions for what our system would accept, so any
"IPORR" hReview is 100% compatible with the hReview spec.  To
summarize what makes an hReview usable for IPORR:

* The "item info" field is limited to identifying a product or
organization.  A product is identified with a GTIN URN.  An
organization (business, nonprofit, governmental) is identified with a
website URL.  The idea is to narrow down the number of ways the target
of the rating can be identified so that it is practical to perform
lookups.  This is done so that we can match one or more hReviews to
the digits pulled from a product's barcode scan.
* The "type" field is either "product" or "url".
* The "rating" field is required, and some rough guidelines are given
for normalizing the numeric value.  This is required because the
intended applications will need to provide a single indicator of
whether a consumer should buy something or not--a number between 1 and
5 shown on a tiny screen.  Or maybe the consumer doesn't even look at
the screen and he just hears an audio cue.
* The "dtreviewed" field is required.  With hReviews affected people's
buying decisions so directly, it becomes more important to limit the
influence of obsolete information.
* The "summary" field is a brief justification for the value of the
numeric "rating" field.
* The "description" field is a more complete explanation of the
numeric "rating" field.

I would sincerely appreciate any feedback, particularly if I'm not
promoting good use of the hReview format.  It would be better to work
out the kinks in my publishing instructions now than to have a bunch
of people making hReviews in a way that needs to be corrected later.
I'm happy to discuss any aspect of what we're doing as well.  This is
not a promote-and-run post--I'll be checking back for responses and
reply on the list.

-Erik Hermansen
President, Ethical Spender
erikh at ethicalspender.org

More information about the microformats-discuss mailing list