Microformats Wiki - User contributions [en]

hproduct-issues

2009-02-18T23:01:08Z

PaulLee: responses to issues

__TOC__

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

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-17</span> raised by <span class="fn">NicolasLeroy</span></span>
<div class="description">
*# In the "[[hproduct#Out_of_Scope|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"_
*# 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 <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: 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? ([[User:PaulLee|Paul Lee]]: If there's no objection here, may I suggest updating the price reference and keeping quantity and shipping as is?])
</div>
</div>

<div class="vevent">

== <span class="summary">HP2 - FN should be used instead of N for product title</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Why is <b>n</b> used instead of <b>fn</b> for the title of the product? hCard and hAudio both use fn for the formatted name of the product. <b>n</b> is usually an optimization.
</div>
</div>

<div class="vevent">
== <span class="summary">HP3 - BUY duplicates functionality of PAYMENT from hAudio</span> ==
* {{OpenIssue}} <span class="vcard">BUY duplicates functionality of PAYMENT from hAudio<span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>buy</b> is duplicating the functionality of <b>payment</b> from hAudio.
** Response <span class="vcard">by <span class="fn">[[User:PaulLee|Paul Lee]]</span>, 2008-02-18</span>: 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.
</div>
</div>

<div class="vevent">
== <span class="summary">HP4 - Are all of the formats for PRICE in hProduct allowed</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* The way that <b>price</b> is used is iffy - do we allow anything but currency/amount in the compound statement?
</div>
</div>

<div class="vevent">
== <span class="summary">HP5 - The format for the contents of SHIPPING are vague</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Seems like <b>shipping</b> could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
</div>
</div>

<div class="vevent">
== <span class="summary">HP6 - P-V seems like a catch-all for hProduct</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>p-v</b> seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
** Response <span class="vcard">by <span class="fn">[[User:PaulLee|Paul Lee]]</span>, 2008-02-18</span>: 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.
</div>
</div>

<div class="vevent">

== <span class="summary">HP7 - Lots of vocabulary terms, does the data really back this up?</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* 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 <span class="vcard">by <span class="fn">[[User:PaulLee|Paul Lee]]</span>, 2008-02-18</span>: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.

</div>
</div>

== Template ==
{{issues-format}}

2008-08-21T04:05:57Z

PaulLee: /* Adam Craven */

<h1> product microformat brainstorming </h1>
This is brainstorming for a [[product]] microformat per the [[process]]. See also [[product-examples]], and [[product-formats]].

{{TOC-right}}

== Contributors ==
* Aaron Gustafson, [http://easy-designs.net/ Easy! Designs]
* Craig Cook, [http://focalcurve.com/ Focal Curve]
* [[User:JayMyers|Jay Myers]]

== The Problem ==

There are numerous ways to publish product information on the web, but nothing is standardized. It would be useful to have standardized product information on the web for creating mash-up applications which could

* allow aggregated product details to be linked to from hListings or hReviews
* match hListings to hReviews
* aggregate product-specific information from across the web
* aggregate and compare like products based on features

Additionally, it should be recognized that more mature formats like hListing are not granular or specific enough to cover the many possible attributes of a product. Without these specifics, hListings describing products lose much of their value and don't accurately represent product data.

== To be incorporated ==
The following pages should be incorporated into this page:
* [[rel-product-brainstorming]]
* [[hproduct-feedback]]
And then those pages should simply redirect to this one via: <nowiki>#redirect [[product-brainstorming]]</nowiki>

== Elements that come up often in practice ==

Examples of elements that might be included because they seem to come up often in user- and CMS-generated product publishing, include the following:

=== Base Schema Elements ===

* hproduct
** version. optional. text.
** name. required.
** image. optional. IMG element or rel='image'. could be further refined as image type ( thumb || full, photo || illo).
** description. optional. could be denoted as 'summary' or 'extended'.
** brand. text | [[hcard|hCard]]
** uri. optional. URI to product page, href could contain rel='product'.
** price. optional. could be further refined as specific type (sale || regular || msrp || clearance). should follow [[currency]] format.
** savings. optional. should follow [[currency]] format.
** p-v. optional. opens up possibilities for custom property-value pairs in more complex examples.
*** property. required. property types could include:
**** artist
**** author
**** released - [[hcalendar]] event for date of release
**** upc
**** isbn
**** sku
**** sn
**** vin
**** batch
**** size
**** color
**** uid - unique id, item number
**** offer
**** others. possibly around product specs, features.
*** value. required. (label may be implied)
** availability. optional. text containing availablity message.
** shipping. optional. shipping messaging.
** reviews. text | [[hreview|hReview]]
** buy. optional. text purchase messaging and/or rel="purchase" indicating target URI for purchasing item

=== Extensibility ===
Being that so many products in the world have specific charachteristics or properties, we thought it might be wise to create a means of standardizing the listing of that information, setting the stage for possible subformats of a product microformat. This could be done by setting up property value pairs or groups using a <code>CLASS</code> of "p-v". It would be possible to offer a few means of doing this.

==== Natural language property-value association ====

<pre><nowiki><p class="p-v">The <span class="property">dimensions</span> of this book are
<span class="value">6½"(<abbr title="width">W</abbr>) ×
12"(<abbr title="height">H</abbr>) ×
1¾"(<abbr title="depth">D</abbr>)</span></p></nowiki></pre>

==== List property-value association (pairs) ====

<pre><nowiki><ul>
<li class="p-v">
<span class="property">Mileage</span>:
<em class="value">34,787</em>
</li>
<li class="p-v">
<span class="property">Year</span>:
<em class="value">2006</em>
</li>
<li class="p-v">
<span class="property">Exterior Color</span>:
<em class="value">Burgundy</em>
</li>
<li class="p-v">
<span class="property">Body Style</span>:
<em class="value">Hatchback</em>
</li>
</ul></nowiki></pre>

==== List property-value association (groups) ====

Note: as a <code>DL</code> contains semantic property-value pairs/groups, setting a <code>CLASS</code> of "p-v" should be enough (reducing extra markup).

<pre><nowiki><dl class="p-v">
<dt>Mileage</dt>
<dd>34,787</dd>
<dt>Color</dt>
<dd>Burgundy (Exterior)</dd>
<dd>Tan (Interior)</dd>
</dl></nowiki></pre>

==== Non-visible property names ====

We have considered the possibility of allowing property names to be invisible to users by allowing the addition of the property name as a class immediately following the "propery" <code>CLASS</code> keyword:

<pre><nowiki><ul class="p-v">
<li class="property mileage">34,787</li>
<li class="property year">2006</li>
<li class="property color-exterior">Burgundy</li>
<li class="property body-style>Hatchback</li>
</ul></nowiki></pre>

Parsing would be a bit trickier, but from the perspective of someone marking up the document, it is pretty simple and straightforward.

=== Suggested Additions ===

* image sub-categorization (could make use of [[media-info|Media microformat]]?):
** thumb (for thumbnail)
** full (for full size image)
** photo (for a photograph)
** illo (for an illustration).
* description sub-categorization:
** summary
** extended
* uri (or url) - URI for the product at its brand website; not to be confused with the hListing 'permalink'.

== Isn't this duplicating hListing and hReview? ==

No, a product microformat would not seek to compete with [[hlisting|hListing]] or [[hreview|hReview]], it simply aims to enhance them. In either of these microformats, the <em>item</em> could easily contain the product. Also, a product microformat is the more appropriate place for Manufacturer's Suggested Retail Price (MSRP), which is not likely to be the final price of the product being listed. The actual price/sale price/final price should be solely in the domain of hListing.

== Random Thoughts ==

Please add your thoughts & feelings below. If you are interested in getting involved in the development of this microformat. Please contact aaron [at] easy-designs [dot] net and/or join the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats mailing list].

===Ronnos===

Wouldn't the release date of the product be a good addition? I'm writing product re- and previews. I use hReviews to give my opinion about the product, but there's now way to indicate that the product is or is not in stores yet. As far as i can see, the release date is a usefull product attribute, not only usefull in combination with other Microformats, but also for indicating the "age" of a product.

* Release date is a good idea but how to specify it? Is it the date on which the product first becomes available in shops? Would you have a per-region release date (certainly applicable to DVDs, CDs and at least some electronic devices such as gaming consoles) --[[User:SMulcahy|SMulcahy]] 13:38, 15 Feb 2007 (PST)
** Seems like this depends on whether this is intended for use by retailers and/or manufacturers. Retailers might have access to the manufacturer release date, but their date may differ from other retailers; so they would probably want to use when they have it available, similar to saying that this is a valid_from_date. Manufacturers, on the other hand, would probably be able to offer a limited or wide release availability date. These do not need to be mutually exclusive. --[[User:PaulLee|Paul Lee]] 21:01, 20 Aug 2008 (PST)

===Aaron Gustafson===

Actual price, savings, discounts, etc. should be part of hListing instead of a product microformat. MSRP (suggested retail price) should be part of the product microformat, however.
*Not all products have a MSRP. [[User:AndyMabbett|Andy Mabbett]] 09:08, 19 Nov 2006 (PST)
**I agree, they don't which is why it should not be required. [[User:AaronGustafson|Aaron Gustafson]] 16:60, 20 Nov 2006 (MST)

===Andy Mabbett===
Please see my [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007281.html proposal, on the mailing list] -- [[User:AndyMabbett|Andy Mabbett]] 09:08, 19 Nov 2006 (PST)
* I agree with the idea of enabling sub-product formats, but am not sure I like the idea of a "wrapper" for hReview or hListing, I think the item should exist ''within'' an instance of one of those microformats. [[User:AaronGustafson|Aaron Gustafson]] 16:60, 20 Nov 2006 (MST)
**There may be more than one review of a product, on one page e.g. [http://www.amazon.co.uk/o/ASIN/B000I0SGSA/ref=pd_rvi_gw_1/026-5782158-8338825] [[User:AndyMabbett|Andy Mabbett]] 00:54, 21 Nov 2006 (PST)

===Adam Craven===

A product microformat will definitely be one of the largest microformats.

What about specifications of products, which is important for data aggregation. To categories every type and variation of a product would be mad. So how should the hurdle be crossed, if at all?

The nearest related uF is the citation format, although it isn't overly suited.

* To this and the point below, it is also important to keep in mind that product categories evolve over time, and may take awhile to mature. Think about the specs on cameras over the past 15 years. --[[User:PaulLee|Paul Lee]] 21:05 20 Aug 2008

===Stephen Mulcahy===

As with microformats in general maybe the approach to take to specifications of products is to let people who need/want them start specifying the ones they are interested in - we don't need an exhaustive universe of potential things categorised. See my posting for some other comments here - http://microformats.org/discuss/mail/microformats-discuss/2007-January/008379.html , in particular note that I think the hard part of this is defining the specifications of individual products. I'm happy to start on the laptop one ... it would be good to have some laptop vendor on board but maybe its too soon for anyone to be interested.

* Some potential subformats (what kind of naming scheme do we want to use here)
** hNotebook (or hProductNotebook ?) - for products like laptops, notebooks, tablets
*** os
*** bundledSoftware
*** size (height, width, depth)
*** weight (units?)
*** processor
*** display
**** size
**** resolution
*** video (for video card)
*** embeddedVideo (boolean)
*** hard drive (maybe manufacturer,model,size? .. eeek is hard drive a hProduct subformat itself?)
*** memory (type and size?)
*** optical drive (types?)
*** battery
*** warranty
*** videoOut (types supported - is it acceptable have a bunch of boolean options for laptop features that may or may not exist on a particular model?)
** hDesktop - for desktop PCs and similar
** hConsole - for gaming consoles such as the Wii, PS3 and XBox360
** hMobilePhone (or hMobileDevice .. not sure we generally want generic subcategory since the whole point of subformats is to give a concrete set of characteristics, or do we want to have nesting of subformats to capture general characteristics at higher levels?).
** hPda (maybe a hMobileDevice .. it starts getting a bit fuzzy here)

Maybe we should talk to some projects like the Linux on Laptops [http://www.linux-laptop.net/] project and get them to encourage contributors to mark-up their laptop reviews in hProductNotebook? --[[User:SMulcahy|SMulcahy]] 07:51, 20 Feb 2007 (PST)

Attempting to create a taxonomy of product subformats is a really bad idea. There are too many different kinds of products. Large e-commerce sites keep many employees busy with product taxonomy work, not something a standard should attempt to do. [[User:Tantek|Tantek]] 23:04, 21 Aug 2007 (PDT)

===Robbie van der Blom===
What about unique identifiers for products like ISBN nr. and the UPC codes for a product? My gut feeling is that they should be part of a product microformat.

With respect to the above, do we really need to talk about hProductNotebook etc. this seems odd.

===Adam Craven===

In relation to the p-v and general property values. The [[abbr-design-pattern]] could be used over the hidden class variable. So
<pre><nowiki>
<h1 class="name">Breitling SuperOcean Chrono</h1>
Water resistant up to <span class="p-v"><abbr class="property value" title="water-resistance">1500m</abbr></span></nowiki></pre>

In this second example, the color is embedded within the name of the shirt itself.
<pre><nowiki><h1 class="name"><span class="p-v"><abbr class="property value" title="color">White</abbr> Coxmoor shirt</h1>
<img src="white-coxmoor-shirt.jpg" rel="image thumb" /></nowiki></pre>

For items such as books, whereby authors sometimes aren't explicitly denoted visibly (http://www.thebookpeople.co.uk/webapp/wcs/stores/servlet/product_10001_10051_47517_100_10014_10013_category_10013), rather inferred by convention. Could arguably still use the abbr pattern:

<pre><nowiki><h1><span class="name">Great Tales From English History</span> - 3 Books</h1>
by <span class="p-v"><abbr class="property value" title="author">Robert Lacey</abbr></span></nowiki></pre>

Or even
<pre><nowiki><h1><span class="name">Great Tales From English History</span> - 3 Books</h1>
<span class="p-v"><abbr class="property" title="author">by</abbr> <span class="value">Robert Lacey</span></span></nowiki></pre>

A final thought to throw in. If the property and values are within the same HTML tag, it might be possible to remove the property & value class, as the p-v indicates a property value relationship itself.

<pre><nowiki><abbr class="p-v" title="author">Robert Lacey</abbr></nowiki></pre>
What do you think?

===LanceW===

A product microformat would I think be useful for corporate sites.
For example, my employers site lists the products and services we work with, I am able to (and have) used microformats to contact details, but would like to microformat products and services. At present I have as a start added rel="product" to links to our individual product pages, but to be able to do it in a better manner would be good, also so I could microformat the product page itself so that one could find say all the products from a specific manufacturer.

== naming ==
Here are candidate names for a product microformat:
* hProduct

== proposal ==
The above brainstorming, based on [[product-examples]] and [[product-formats]] (TO BE DONE) research, should go into a proposal:
* [[hproduct-proposal|hProduct proposal]]
Currently this is premature, as the [[product-formats]] page has not yet even been created, much less researched. Per the [[process]], research on formats must be done before brainstorming or drafting a separate proposal.

== related ==
* [[product]]
* [[product-examples]]
* [[product-formats]]
* [[product-brainstorming]]

== see also ==
* [[hReview]]
* [[hListing]]

product-brainstorming

2008-08-21T04:02:03Z

PaulLee: /* Random Thoughts */

<h1> product microformat brainstorming </h1>
This is brainstorming for a [[product]] microformat per the [[process]]. See also [[product-examples]], and [[product-formats]].

{{TOC-right}}

== Contributors ==
* Aaron Gustafson, [http://easy-designs.net/ Easy! Designs]
* Craig Cook, [http://focalcurve.com/ Focal Curve]
* [[User:JayMyers|Jay Myers]]

== The Problem ==

There are numerous ways to publish product information on the web, but nothing is standardized. It would be useful to have standardized product information on the web for creating mash-up applications which could

* allow aggregated product details to be linked to from hListings or hReviews
* match hListings to hReviews
* aggregate product-specific information from across the web
* aggregate and compare like products based on features

Additionally, it should be recognized that more mature formats like hListing are not granular or specific enough to cover the many possible attributes of a product. Without these specifics, hListings describing products lose much of their value and don't accurately represent product data.

== To be incorporated ==
The following pages should be incorporated into this page:
* [[rel-product-brainstorming]]
* [[hproduct-feedback]]
And then those pages should simply redirect to this one via: <nowiki>#redirect [[product-brainstorming]]</nowiki>

== Elements that come up often in practice ==

Examples of elements that might be included because they seem to come up often in user- and CMS-generated product publishing, include the following:

=== Base Schema Elements ===

* hproduct
** version. optional. text.
** name. required.
** image. optional. IMG element or rel='image'. could be further refined as image type ( thumb || full, photo || illo).
** description. optional. could be denoted as 'summary' or 'extended'.
** brand. text | [[hcard|hCard]]
** uri. optional. URI to product page, href could contain rel='product'.
** price. optional. could be further refined as specific type (sale || regular || msrp || clearance). should follow [[currency]] format.
** savings. optional. should follow [[currency]] format.
** p-v. optional. opens up possibilities for custom property-value pairs in more complex examples.
*** property. required. property types could include:
**** artist
**** author
**** released - [[hcalendar]] event for date of release
**** upc
**** isbn
**** sku
**** sn
**** vin
**** batch
**** size
**** color
**** uid - unique id, item number
**** offer
**** others. possibly around product specs, features.
*** value. required. (label may be implied)
** availability. optional. text containing availablity message.
** shipping. optional. shipping messaging.
** reviews. text | [[hreview|hReview]]
** buy. optional. text purchase messaging and/or rel="purchase" indicating target URI for purchasing item

=== Extensibility ===
Being that so many products in the world have specific charachteristics or properties, we thought it might be wise to create a means of standardizing the listing of that information, setting the stage for possible subformats of a product microformat. This could be done by setting up property value pairs or groups using a <code>CLASS</code> of "p-v". It would be possible to offer a few means of doing this.

==== Natural language property-value association ====

<pre><nowiki><p class="p-v">The <span class="property">dimensions</span> of this book are
<span class="value">6½"(<abbr title="width">W</abbr>) ×
12"(<abbr title="height">H</abbr>) ×
1¾"(<abbr title="depth">D</abbr>)</span></p></nowiki></pre>

==== List property-value association (pairs) ====

<pre><nowiki><ul>
<li class="p-v">
<span class="property">Mileage</span>:
<em class="value">34,787</em>
</li>
<li class="p-v">
<span class="property">Year</span>:
<em class="value">2006</em>
</li>
<li class="p-v">
<span class="property">Exterior Color</span>:
<em class="value">Burgundy</em>
</li>
<li class="p-v">
<span class="property">Body Style</span>:
<em class="value">Hatchback</em>
</li>
</ul></nowiki></pre>

==== List property-value association (groups) ====

Note: as a <code>DL</code> contains semantic property-value pairs/groups, setting a <code>CLASS</code> of "p-v" should be enough (reducing extra markup).

<pre><nowiki><dl class="p-v">
<dt>Mileage</dt>
<dd>34,787</dd>
<dt>Color</dt>
<dd>Burgundy (Exterior)</dd>
<dd>Tan (Interior)</dd>
</dl></nowiki></pre>

==== Non-visible property names ====

We have considered the possibility of allowing property names to be invisible to users by allowing the addition of the property name as a class immediately following the "propery" <code>CLASS</code> keyword:

<pre><nowiki><ul class="p-v">
<li class="property mileage">34,787</li>
<li class="property year">2006</li>
<li class="property color-exterior">Burgundy</li>
<li class="property body-style>Hatchback</li>
</ul></nowiki></pre>

Parsing would be a bit trickier, but from the perspective of someone marking up the document, it is pretty simple and straightforward.

=== Suggested Additions ===

* image sub-categorization (could make use of [[media-info|Media microformat]]?):
** thumb (for thumbnail)
** full (for full size image)
** photo (for a photograph)
** illo (for an illustration).
* description sub-categorization:
** summary
** extended
* uri (or url) - URI for the product at its brand website; not to be confused with the hListing 'permalink'.

== Isn't this duplicating hListing and hReview? ==

No, a product microformat would not seek to compete with [[hlisting|hListing]] or [[hreview|hReview]], it simply aims to enhance them. In either of these microformats, the <em>item</em> could easily contain the product. Also, a product microformat is the more appropriate place for Manufacturer's Suggested Retail Price (MSRP), which is not likely to be the final price of the product being listed. The actual price/sale price/final price should be solely in the domain of hListing.

== Random Thoughts ==

Please add your thoughts & feelings below. If you are interested in getting involved in the development of this microformat. Please contact aaron [at] easy-designs [dot] net and/or join the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats mailing list].

===Ronnos===

Wouldn't the release date of the product be a good addition? I'm writing product re- and previews. I use hReviews to give my opinion about the product, but there's now way to indicate that the product is or is not in stores yet. As far as i can see, the release date is a usefull product attribute, not only usefull in combination with other Microformats, but also for indicating the "age" of a product.

* Release date is a good idea but how to specify it? Is it the date on which the product first becomes available in shops? Would you have a per-region release date (certainly applicable to DVDs, CDs and at least some electronic devices such as gaming consoles) --[[User:SMulcahy|SMulcahy]] 13:38, 15 Feb 2007 (PST)
** Seems like this depends on whether this is intended for use by retailers and/or manufacturers. Retailers might have access to the manufacturer release date, but their date may differ from other retailers; so they would probably want to use when they have it available, similar to saying that this is a valid_from_date. Manufacturers, on the other hand, would probably be able to offer a limited or wide release availability date. These do not need to be mutually exclusive. --[[User:PaulLee|Paul Lee]] 21:01, 20 Aug 2008 (PST)

===Aaron Gustafson===

Actual price, savings, discounts, etc. should be part of hListing instead of a product microformat. MSRP (suggested retail price) should be part of the product microformat, however.
*Not all products have a MSRP. [[User:AndyMabbett|Andy Mabbett]] 09:08, 19 Nov 2006 (PST)
**I agree, they don't which is why it should not be required. [[User:AaronGustafson|Aaron Gustafson]] 16:60, 20 Nov 2006 (MST)

===Andy Mabbett===
Please see my [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007281.html proposal, on the mailing list] -- [[User:AndyMabbett|Andy Mabbett]] 09:08, 19 Nov 2006 (PST)
* I agree with the idea of enabling sub-product formats, but am not sure I like the idea of a "wrapper" for hReview or hListing, I think the item should exist ''within'' an instance of one of those microformats. [[User:AaronGustafson|Aaron Gustafson]] 16:60, 20 Nov 2006 (MST)
**There may be more than one review of a product, on one page e.g. [http://www.amazon.co.uk/o/ASIN/B000I0SGSA/ref=pd_rvi_gw_1/026-5782158-8338825] [[User:AndyMabbett|Andy Mabbett]] 00:54, 21 Nov 2006 (PST)

===Adam Craven===

A product microformat will definitely be one of the largest microformats.

What about specifications of products, which is important for data aggregation. To categories every type and variation of a product would be mad. So how should the hurdle be crossed, if at all?

The nearest related uF is the citation format, although it isn't overly suited.

===Stephen Mulcahy===

As with microformats in general maybe the approach to take to specifications of products is to let people who need/want them start specifying the ones they are interested in - we don't need an exhaustive universe of potential things categorised. See my posting for some other comments here - http://microformats.org/discuss/mail/microformats-discuss/2007-January/008379.html , in particular note that I think the hard part of this is defining the specifications of individual products. I'm happy to start on the laptop one ... it would be good to have some laptop vendor on board but maybe its too soon for anyone to be interested.

* Some potential subformats (what kind of naming scheme do we want to use here)
** hNotebook (or hProductNotebook ?) - for products like laptops, notebooks, tablets
*** os
*** bundledSoftware
*** size (height, width, depth)
*** weight (units?)
*** processor
*** display
**** size
**** resolution
*** video (for video card)
*** embeddedVideo (boolean)
*** hard drive (maybe manufacturer,model,size? .. eeek is hard drive a hProduct subformat itself?)
*** memory (type and size?)
*** optical drive (types?)
*** battery
*** warranty
*** videoOut (types supported - is it acceptable have a bunch of boolean options for laptop features that may or may not exist on a particular model?)
** hDesktop - for desktop PCs and similar
** hConsole - for gaming consoles such as the Wii, PS3 and XBox360
** hMobilePhone (or hMobileDevice .. not sure we generally want generic subcategory since the whole point of subformats is to give a concrete set of characteristics, or do we want to have nesting of subformats to capture general characteristics at higher levels?).
** hPda (maybe a hMobileDevice .. it starts getting a bit fuzzy here)

Maybe we should talk to some projects like the Linux on Laptops [http://www.linux-laptop.net/] project and get them to encourage contributors to mark-up their laptop reviews in hProductNotebook? --[[User:SMulcahy|SMulcahy]] 07:51, 20 Feb 2007 (PST)

Attempting to create a taxonomy of product subformats is a really bad idea. There are too many different kinds of products. Large e-commerce sites keep many employees busy with product taxonomy work, not something a standard should attempt to do. [[User:Tantek|Tantek]] 23:04, 21 Aug 2007 (PDT)

===Robbie van der Blom===
What about unique identifiers for products like ISBN nr. and the UPC codes for a product? My gut feeling is that they should be part of a product microformat.

With respect to the above, do we really need to talk about hProductNotebook etc. this seems odd.

===Adam Craven===

In relation to the p-v and general property values. The [[abbr-design-pattern]] could be used over the hidden class variable. So
<pre><nowiki>
<h1 class="name">Breitling SuperOcean Chrono</h1>
Water resistant up to <span class="p-v"><abbr class="property value" title="water-resistance">1500m</abbr></span></nowiki></pre>

In this second example, the color is embedded within the name of the shirt itself.
<pre><nowiki><h1 class="name"><span class="p-v"><abbr class="property value" title="color">White</abbr> Coxmoor shirt</h1>
<img src="white-coxmoor-shirt.jpg" rel="image thumb" /></nowiki></pre>

For items such as books, whereby authors sometimes aren't explicitly denoted visibly (http://www.thebookpeople.co.uk/webapp/wcs/stores/servlet/product_10001_10051_47517_100_10014_10013_category_10013), rather inferred by convention. Could arguably still use the abbr pattern:

<pre><nowiki><h1><span class="name">Great Tales From English History</span> - 3 Books</h1>
by <span class="p-v"><abbr class="property value" title="author">Robert Lacey</abbr></span></nowiki></pre>

Or even
<pre><nowiki><h1><span class="name">Great Tales From English History</span> - 3 Books</h1>
<span class="p-v"><abbr class="property" title="author">by</abbr> <span class="value">Robert Lacey</span></span></nowiki></pre>

A final thought to throw in. If the property and values are within the same HTML tag, it might be possible to remove the property & value class, as the p-v indicates a property value relationship itself.

<pre><nowiki><abbr class="p-v" title="author">Robert Lacey</abbr></nowiki></pre>
What do you think?

===LanceW===

A product microformat would I think be useful for corporate sites.
For example, my employers site lists the products and services we work with, I am able to (and have) used microformats to contact details, but would like to microformat products and services. At present I have as a start added rel="product" to links to our individual product pages, but to be able to do it in a better manner would be good, also so I could microformat the product page itself so that one could find say all the products from a specific manufacturer.

== naming ==
Here are candidate names for a product microformat:
* hProduct

== proposal ==
The above brainstorming, based on [[product-examples]] and [[product-formats]] (TO BE DONE) research, should go into a proposal:
* [[hproduct-proposal|hProduct proposal]]
Currently this is premature, as the [[product-formats]] page has not yet even been created, much less researched. Per the [[process]], research on formats must be done before brainstorming or drafting a separate proposal.

== related ==
* [[product]]
* [[product-examples]]
* [[product-formats]]
* [[product-brainstorming]]

== see also ==
* [[hReview]]
* [[hListing]]