item-brainstorming

Item Brainstorming

This page is to collect ideas about an "item" microformat and/or design pattern, for representing any "thing" that may exist or be referenced in another microformat. The goal is to create a small and concise vocabulary roughly mirroring hCard that represents the intersection of attributes across things, not the union.

Editors

• David Janes

Authors

• David Janes
• James Darling
• your name here...

Introduction

Goal

1. when someone creates a new microformat that uses, contains, or references an item, they can just pick up hItem and use it
2. when someone creates a new microformat that is a thing or item, they can build on hItem by composition (using it as a microformat) or by vocabulary (using it as a design pattern)
3. by using an explicit item microformat, today's parsers will explicitly recognize in future microformats that an item being used, even if the exact nature of that item is not available

Rationale

• items and things are frequently used or referenced in other microformats. For example:
  • hListing
  • hReview
  • citation
• people and places explicitly get a container element (hCard) which implicitly brings in a rich and descriptive set of attributes. In hListing and hReview, other non-person non-place things also get a container element marked class. However, the attributes of these items are explicitly specified in each microformat, even though they are common to both. hItem explicitly isolates and describes these attributes
• by isolating and documenting these attributes and their behaviors, not only do existing microformats become more consise but future microformats -- wine, houses, citations, automobiles -- become easier to write

Notes

• The hItem microformat already implicitly exists; see hreview and hlisting. We are just explicitly isolating it
• As a microformat, this is very much analogous to hCard and we shall reuse all applicable attributes:
  • 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

hItem-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 (real and proposed)

hListing

• identifier: item
• attributes:
  • hcard:fn
  • hcard:url
  • hcard:photo
  • geo:geo
  • adr:adr
• hlisting spec doesn't explicitly mark "item" as a class; this seems to be an oversight rather than a design decision
• all the attributes of the item are optional, including fn

hReview

• identifier: item
• attributes:
  • hcard:fn
  • hcard:url
  • hcard:photo
• hreview doesn't explicitly note that reviewed items (that aren't hCards) may have an address or a location; this is likely an oversite because obviously seems likely that some reviewed non-locations may have these attributes; for example, a review of an amusement park
• fn (the name of the thing being reviewed!) is required; this is different than hlisting and will require some thinking about

citation

• citation is not a microformat yet, but could benefit from hItem

Tier 4: specific to particular item-types

This is out of scope. Particular item types should be described by their own microformat that ideally would composite with hItem or use it as a design pattern.

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".

4. As a composite with hitem and item

Under this method, we would composite future microformats with a "hitem" top level node and "item" for scoping parts within the microformat.

<div class="hitem hmovie">
  <span class="fn">A.I.: Artificial Intelligence</span>
  <div class="item vcard">
    <span class="role">Directed</span> by...
  </div>
</div>

The "hMovie" parser, because we use "item" rather than "hItem" can look inside to get selected attributes, in this case a "role" of a person. More documentation and more realistic examples would be needed to see if this differentiation is worth pursuing.

hItem is basically then MFO with additional compositing properties. (More thoughts needed here)

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, based on information extracted from hListing/hReview in much the same was adr and geo were extracted from hCard
• The top level class name will be "item"
• There are probably a few more very common attributes that should be added; in particular:
  • a description field
  • a UID
• Think about composition of items using nest items; need to back this idea up with examples
• hItem should not describe the type of item; rather this comes from the context or composition
• 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")
• hItem should be simple and concise and not be a general purpose dumping ground for attributes
• Updated: 2006-12-08

Andy Mabbett

• Please see my proposal, on the mailing list Andy Mabbett 14:31, 18 Nov 2006 (PST)

See Also

• examples
• formats
• brainstorming
• initial discussion
• hproduct