hproduct-issues

open issue!

2011-11-15 
raised by Arthur

• HP9 - using hProduct vs. hListing to markup Real Estate properties. If use the hProduct (which is fully supported by Google) instead of hListing to markup Real Estate properties, what hProduct related properties should we use to replace these 3 properties of hListing: "item-type", "listing-type" and "listing-action"? (e.g. housing offer-sale).

Should we use "category"?

For a better understanding and for practical purposes, I provide 2 working examples for usability:

• 1. hListing original marked up example: hListing example
  2. and then, modified into hProduct: hProduct example

Feel free to copy and modify it along and attach it in your comments and the result should be placed in the right section as implementation example.

HP1 - hProduct product identifier

• open issue! 2010-04-29 raised by Harald Oehlmann

• 1. The product identifier has a relatively loose list of partly contradictory examples.

I would recomment to use a product identification in ISO15418 format following data identifier "25P" of ASC MH10.8.2. The proposal is to use the data of 25P as identifier. This superceedes the examples ean, jan, isbn, issn (which may be all represented as GTINs which is also a part of 25P). In addition, all unique product codes of other branches like automotive, steel, military, aviation, chemical, healthcare and many pharma codes are covered.

• 1. Within the examples, there is "sn" for serial number. This is another class of identifier, because an object, and not a product is identified. A serial number should be used as the data of "25S" which covers again all branch serial numbers and the GS1 GIAI code.
  2. Those are only some thoughts, you may delete this contribution if it is out of scope for you.

HP1 - hProduct vs hListing regarding "price" / "quantity" / "shipping" fields

• open issue! 2008-12-17 raised by NicolasLeroy

• 1. In the "out of scope" section, it is explained: _"This microformat does not intend to replicate any of the content proposed within hListing and would defer all money/transactional matters to that microformat"_
  2. However, in the hProduct schema, we have the following fields:
     • "price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance)" => if the price is the retailer price, then it should be delegated to hListing. We could imagine it represents the "manufacturer" price (which could be different from the retailer price) ; in this case, it should clearly be explained in the schema definition.
     • I would say there is also ambiguity between the responsibilities of hProduct vs hListing for the following fields: quantity / shipping
       • Response by Jay Myers, 2008-02-16: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
       • Response by Jay Myers, 2008-02-16: I don't follow the quantity/ shipping issue. I don't see either of these on hListing, unless the concepts are somehow embedded in other attributes. Can you elaborate on what the ambiguity is? (Paul Lee: If there's no objection here, may I suggest updating the price reference and keeping quantity and shipping as is?])
     • +1 I agree with NicholasLeroy, anything price or transaction related should be left out of hProduct 0.1, and instead develop recipes / mark-up examples showing use of hListing with hProduct. We need to strongly resist and fight the tendency to include "just one more field" to individual formats and instead push to use formats as building blocks. Tantek 23:41, 18 February 2009 (UTC)
       • Response by Jay Myers, 2009-03-03: If price should be left to hListing, should hAudio be modified not to include "price"?
     • I am going to add price back into the hProduct spec. Price is an attribute of a product. We should be able to use microformats either standalone or as building blocks in combination with other formats. On price I'm thinking specifically of product manufacturer sites who may not be commerce enabled and are listing their products for informational purposes. In this case, they would not be using hListing, as there would be no transaction taking place. Leaving the price attribute out would ignore a major product attribute (in 99% of product sites, per hproduct examples analysis).

HP2 - FN should be used instead of N for product title

• open issue! 2009-02-17 raised by ManuSporny

• Why is n used instead of fn for the title of the product? hCard and hAudio both use fn for the formatted name of the product. n is usually an optimization.
• +1 hProduct should use "fn" for the name of the product. Tantek 23:41, 18 February 2009 (UTC)
  • Response by Jay Myers, 2008-03-03: "n" will be changed to "fn" in the next version of the schema
• "fn" is hardly semantic, even though commonly deployed - surely "formatted-name" is truer to the principles of "humans-first, machines second" --Wowitim 12:59, 28 March 2009 (UTC)

HP3 - BUY duplicates functionality of PAYMENT from hAudio

• open issue! BUY duplicates functionality of PAYMENT from hAudio2009-02-17 raised by ManuSporny

• buy is duplicating the functionality of payment from hAudio.
  • Response by Paul Lee, 2008-02-18: From the payment page: "RelPayment is a microformat for making exchanges of support (be it financial or otherwise) possible. By adding rel="payment" to a hyperlink a page indicates that the destination of that hyperlink provides a way to show or give support for the current page. For example to give financial support to the owner of the current page. One of the goals with this microformat is to give content aggregators such as RSS readers a way to extract these support links and give them special attention (such as displaying a standard button along with the content)." First, this seems like a simple exercise for blogs, etc.; but the transaction process for shopping sites is typically considerably more complex. Usually, the actual payment URI is toward the end of the cart checkout process, the entry to which "buy" is intended to direct to the beginning of. Second, there is the potential for confusion when using payment, since "payment" in the shopping space often refers to payment methods, e.g., credit card, check, etc.
• +1 but in a different way. BUY/PAYMENT should both be out of scope for hProduct, and only be in hListing per issue HP1 above. Tantek 23:41, 18 February 2009 (UTC)
  1. • Response by Jay Myers, 2009-03-03: Should these be in scope for hAudio then?

HP4 - Are all of the formats for PRICE in hProduct allowed

• open issue! 2009-02-17 raised by ManuSporny

• The way that price is used is iffy - do we allow anything but currency/amount in the compound statement?
• +1 PRICE should not be in hProduct per issue HP1. Tantek 23:41, 18 February 2009 (UTC)
  1. • Response by Jay Myers, 2009-03-03: Should other microformats (thinking hAudio) be modified not to include "price"?

HP5 - The format for the contents of SHIPPING are vague

• open issue! 2009-02-17 raised by ManuSporny

• Seems like shipping could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
• +1 agreed and I think SHIPPING belongs in hListing (not in hProduct) as it applies to a particular transaction/offering, and is not intrinsic to the product itself. Tantek 23:41, 18 February 2009 (UTC)

HP6 - P-V seems like a catch-all for hProduct

• open issue! 2009-02-17 raised by ManuSporny

• p-v seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
  • Response by Paul Lee, 2008-02-18: IIUC, part of the reason why hproduct has been under discussion for quite awhile is b/c of the debate between p-v vs. more defined attributes. p-v is quite helpful b/c the attributes users care about change over time. Take cameras, for instance. Did anyone care about megapixels 10 years ago? etc.
• +1 I strongly oppose p-v as it is nothing more than a circumvention of the microformats process and 80/20 principle of formalizing only common properties. microformats are NOT designed to be infinitely extensible. p-v is simply another source of Tower of Babel problems. When attributes change over time, then the microformat can be iterated/extended to include them, *when* publishing behavior on the web for the *data* of such attributes exceeds the required 80/20 usage per microformats process. That being said, if you really must include arbitrary property-value data, there is already a microformat for that: xoxo. Modularly include a xoxo child and that way the extension is contained in a specific structure that can be ignored by implementations. Tantek 23:41, 18 February 2009 (UTC)

HP7 - Lots of vocabulary terms, does the data really back this up?

• open issue! 2009-02-17 raised by ManuSporny

• There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined... are they all justified? Is there a file that we can analyze (like via microformalyze)?
  • Response by Paul Lee, 2008-02-18:The examples aren't necessarily an accurate reflection of how frequently attributes/data is used by retailers. In practice, model/mpn is used much more frequently than dimensions, both for retailer websites as well as retailer submissions to search and shopping engines. Defer to those with more experience/other data on version.
• +1. If you cannot justify a property, or are unsure about including it, or don't think it is necessarily an accurate reflection of how frequently the data is used, then leave it out per microformats principles. A "version" property was added to hReview for largely theoretical concerns, but has never been needed/used. So in practice (per experience), leave out "version". Tantek 23:41, 18 February 2009 (UTC)
  • Response by Jay Myers, 2008-03-03: I agree on both fronts here, I was surprised that model wasn't more prevalent in the research data, as it seems like an attribute that appears on nearly every product. Since "model" is often used as a type of identifier, it should be moved under the identifier attribute. "Version" will be taken out.

HP8 - No clear way of including a valid hReview that refers back to the hProduct as its item

• open issue! 2010-03-05 raised by GeorgeBrock

• An hProduct can include one or more hReviews. Each hReview requires an item, which should be the hProduct. The include-pattern prohibits references to an ancestor. Therefore it is not clear how to include a valid hReview in an hProduct.
  • Suggested by Tantek on IRC: The item-url property from item-license could be used to refer to the review's item without including it.
    • This suggestion "seems to introduce extra markup that's likely to be extraneous from an end-user point-of-view, and thus set to display:none by authors." — Toby Inkster on the mailing list
  • The review property could be removed altogether, and instead multiple product reviews could be marked up using a more generic container mechanism (see container-brainstorming). This would give a us consistent method of marking up multiple hReviews that apply to the same item, instead of a special case that only applied to hProduct. — GeorgeBrock 13:35, 17 April 2010 (UTC)

Resolved Issues

HP1 - hProduct vs hListing regarding "price" / "quantity" / "shipping" fields

• resolved issue 2009-04-24 raised by JayMyers

• "quantity" and "shipping" have been removed from hproduct and transitioned to a new hlisting proposal. "price" has been retained, with the caveat that if hproduct is being used alone (eg., a non-commerce site who provides product information), without combining it with a microformat like hlisting, it is assumed that the price attribute represents the suggested manufacturers retail price. All transactional details (including transactional price) would be deferred to hlisting.

HP2 - FN should be used instead of N for product titles

• resolved issue 2009-04-24 raised by JayMyers

• changed in draft spec 0.2

HP3 - BUY duplicates functionality of PAYMENT from hAudio

• resolved issue 2009-04-24 raised by JayMyers

• buy removed in draft spec 0.2

HP5 - The format for the contents of SHIPPING are vague

• resolved issue 2009-04-24 raised by JayMyers

• shipping removed in draft spec 0.2

HP6 - P-V seems like a catch-all for hProduct

• resolved issue 2009-04-24 raised by JayMyers

• p-v has been removed in draft spec 0.3 in favor of xoxo

HP7 - Lots of vocabulary terms, does the data really back this up?

• resolved issue 2009-04-24 raised by JayMyers

• many attributes have been removed in draft specs 0.2 and 0.3. We believe the current number of attributes accurately represents a product object while providing adequate opportunity to be combined with other microformats for better overall semantic solutions.

Closed Issues

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>