item-brainstorming

From Microformats Wiki
Revision as of 22:31, 18 November 2006 by AndyMabbett (talk | contribs) (Andy Mabbett's proposal)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Thing Brainstorming

This page is to collect ideas about an "thing" microformat or design pattern, for representing things that physically exist. At this point, my thinking is to aim for understanding the intersection not the union of attribute of things!

Editors

Authors

Introduction to the idea

Rationale

  • items/things are used in other micrformats
  • unlike people and places, items do not currently get a "container"; thus, attributes being associated with a (say) Review actually should be attached the thing itself
  • to cut down on the work required to create new microformats about things (wine, houses, cars, ...)

Notes

This is very much analogous to hCard and there is no reason that this shouldn't reuse as much as possible of this. In particular:

  • fn - the name of an item
  • url - the web address of an item
  • photo - a photo of an item
  • adr - the address of an item (for example, a house)
  • geo - likewise

More of this will be discovered in the examples discovery.

hThing-based microformats

Representation

This may just be a design pattern -- that is, a template for create new microformats in the future. If it is a microformat, how we identify the type of thing is an open question -- we could do it like phone number types in hCard or it could be a new class element (or both). I.e. do we create a top-level class "hWine" or do we do <span class="type">wine</a>

New Attributes

One can see that there are many common properties that can be shared about different types of things. Manufactor, brand name, generic name, color.... The base item microformat may avoid trying to define this and instead allow new/future microformats to do the discovery.

  • Quantity - can be assumed to be 1 unless specified.

hItem and hCard

Immediately the idea of a hItem demands the idea of the option for a contained hCard for the owner, but what about a large qauntity of items owned by a single owner. Would a hCard be required in each hItem, or would it be possible to wrap all the hItems in a hCard?

Analysis of Examples

Tier 1: in use in microformats today

Tier 2: common to 80%+ of examples

Tier 3: less frequently used items

Tier 4: specific to particular thing-types

How this could be used

This section is meant to explore the ways that a item/thing microformat would be used in practice.

1. As a design pattern

That is, we following exactly the pattern that hListing/hReview does. A number of attributes, taken mainly/entirely available from hCard, can be used to describe items/things. These are grouped together by whatever class name is most useful, typically "item":

<div class="item">
  <span class="fn">Some Thing</span>
  <img class="photo" src="..." />
</div>

2. As an ever expanding uF

Under this this method, we would explicitly identify a "item" class, a "type" field of some sort would identify the type of the thing and other attributes would be defined ... some way.

<div class="item">
  <span class="fn">Some Thing</span>
  (<span class="type">wine</a>)
  <img class="photo" src="..." />  
</div>

I don't particularly care for this method.

3. As a composite

Under this method, we would composite future microformats with a "item" top level node:

<div class="item hwine">
  <span class="fn">Some Thing</span>
  <img class="photo" src="..." />  
  <span class="nose">smelly</a>
</div>

Where "fn" and "photo" come from "hitem", "nose" always comes from "hwine" (which insists on being composited with hitem?), and "item" is the class that gives the thing a relationship with it's parent (hListing/hReview/whatever).

Note the precident set by hListing/hReview in compositing "item" with "vcard".

Current Summary

This section is designed to track the current summary thinking on a per-contributor basis. If you want to add your own section here, feel free. Eventually all opinions will converge and we'll be finished.

DavidJanes

  • We should have an "item" microformat
  • This is extracted from hListing/hReview in much the same was adr and geo were extracted from hCard
  • The top level class name should be "item"
  • There are probably a few more very common attributes that should be added; in particular, a description field
  • Future microformats describing specific types of items (hWine) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")
  • It probably should apply to non-physical things also since this is very general
  • The initial version of this spec should not be too complicated (avoid deep analysis and leave that for new microformats, possibly backmerging)
  • Updated: 2006-11-18

Andy Mabbett

See Also