David Janes wrote: > I'm not sure if I'm that excited :-) but I definitely think there's a > gap that can be filled (i.e. that hReview/hListing identify people > directly but only things indirectly). It's possible, but this is very > speculative, that this could simplify the path for creating new > microformats like hWine.
I am just joining the discussion list, so forgive me if what I rehash older discussions. Craig Cook and I had been working on hProduct somewhat in isolation and thought we should post the information we've created to get our ideas and thoughts out there. I see some sililarities with what is up on hItem, though I agree hItem may be a little too broad (see the earlier 'what is an item?' comments). >> I'd definitely advocate for hItem including information about its >> creator, and optionally its producer and vendor. These of course could >> be hCard entries or links, and I think it would give us a flexible way >> to include much of the information that felt very "wine" specific such >> as Vintage (aka, producer and production date). It seems as though an >> hItem's production and creation could also be considered events, so >> reusing hEvent here seems to make a lot of sense. >> >> What do you think? Is this more complicated than it needs to be, or is >> the reuse of other microformats here a good thing? > > Let's go through the examples and see what's frequently used, somewhat > used and rarely or sporadically used. That will point the right > direction I think. And, as per usual, I encourage everyone to > contribute to the examples because that's one of the hardest and least > thanked parts. Hmm, I think we really need to boil this down to its essence. With products, unless you want to go the route niche microformats like hWine or hBook, it makes sense to stick to a few key, repeatable fields, for example: * name * description * image * msrp * uri * brand The rest could be handled by a generic property value construct which we've called 'p-v' (and may honestly have usefulness outside the hProduct/hItem concept). >> Also, is this ground already being covered by hListing (which seems to >> be looking to include some of this info), or would you simply have >> hListings of events (hEvent), people (hCard), and things (hItem)? > >The latter, but we're data mining hListing/hReview to maximize reuse. IMHO, there are a few places I think hListing (and hReview for that matter) are reaching a bit beyond what should be their scope. This is where I think hProduct/hItem fits in. In other words, you could essentially script the linking of a product for sale in an hListing with a review of that product in hReview. I'd be interested in feedback on what Craig and I have posted so far and perhaps we can find a way to merge hItem and hProduct and suggest some augmentations to hListing and hReview to make some space for hProduct/hItem. We will be posting some of our examples shortly. Cheers, Aaron ---- Aaron Gustafson Sr. Web Designer/Developer Easy! Designs, LLC 203-215-8829 O 203-230-0773 F [EMAIL PROTECTED] ---- Easy! Designs, LLC 83 Treadwell St Hamden, CT 06517 http://www.easy-designs.net http://www.easy-reader.net _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
