Difference between revisions of "machine-data"

From Microformats Wiki
Jump to navigation Jump to search
(→‎As supplementary data using the value-excerption-pattern: Remove old section on value-excerption-pattern, link to value-class-pattern.)
(→‎Proposed Methods: Remove 'proposed methods' section, now covered by value-class-pattern.)
Line 93: Line 93:
See [[value-class-pattern]].
See [[value-class-pattern]].
== Proposed Methods ==
===As Invisible Supplementary Data===
''The main content of this section — focussing just on using the [[value-excerption-pattern]] in a mark-up level hidden manner — has been moved into [[value-excerption-pattern-issues]] for easier tracking.''
'''''These are proposals''' and therefore should be noted that they are not endorsed or supported. You should not use any of these patterns when publishing a page, but may like to [http://microformats.org/discuss get involved] to help develop these ideas.''
===Proposals for more publisher-friendly mark-up for machine-data===
* Extend the [[value-excerption-pattern]] to parse title attributes from empty elements with class value. Empty elements are ignored by browsers in the DOM, so won't render a tool-tip or be exposed to screen readers. Of course, it means putting an empty element into mark-up. Please post responses to this on the [[value-excerption-pattern-issues]] page.
* Embed the data into the <code>class</code> attribute, where it will not be rendered or exposed.
* Use a ‘<code>ufusetitle</code>’ class name to particular elements, as a processing instruction to parsers to read the <code>title</code> attribute rather than inner text. However, this adds a new concept of putting ‘parsing instructions’ into the <code>class</code> attribute, which is currently only used to extend the <em>semantics</em> of elements.
* Break with requirements for valid HTML and adopt the RDFa <code>content</code> attribute as a means of embedding data (or another custom attribute). This results in invalid HTML.
** Depends on what DTD you use. It would not be much work to create a DTD that added a "content" attribute to a few elements. Or simply validate against the RDFa DTD.
* Use the title attribute on <em>any</em> HTML element for data embedding, and prefix the machine data with the string ‘<code>data:</code>’. Users exposed to the data string are given some context. This reduces the impact of the problem at the user side, and assistive technology is less likely to expose the title attribute of generic elements such as <code>span</code> as they are for <code>abbr</code>. This avoids adding empty elements to a page, but continues to expose the machine data to human users through tool-tips.
* Repurpose the <code>input</code> element with a <code>type=hidden</code> attribute. Browsers hide this element from users completely. However, this would stretch the semantics of <code>input</code>; using an <em>input</em>, forms device for <em>output</em>.
A final suggestion is that on a case-by-case basis, all the above documented machine-data patterns could be reworked in a human accessible, publisher compatible, internationalizable  and machine-parsable manner. Previously, such solutions have not been forthcoming.

Revision as of 03:55, 14 May 2009

Machine Data in Microformats

Microformats are designed to mark-up human consumable information, as commonly found in the wild. But, in a number of exceptional cases it has been necessary to specify precise data formats for particular properties. Formats for dates, times and locations are standardised in a way that doesn't always match the way information is visibly published. This is necessary to make the data understandable to parsers. Similarly, there are keywords in hCard that must be written in English (telephone ‘type’ in hCard, for example).

It is necessary for these data formats to be fixed to make the data parsable by machines; the cost for a parser to support every commonly published date-time format in the world (include approximations like ‘five minutes ago’) is too high, as is handling international translation (such as mobile telephones; US-English ‘cell’ published as British English ‘mobile’).

In some cases, the human version of the data can be semantically described as an abbreviated form of the machine data, and the machine data may also be human consumable. For example, the Date Design Pattern uses HTML's abbr element to expand one human date representation into the ISO 8601 form date: ‘January 1st’ is an abbreviated form of ‘2008-01-01’. The latter is also legible to humans (and can be exposed to them through tool-tips and assistive screen readers).

In other cases, this machine data is not legible to humans. In hAudio, the duration property uses ISO 8601, resulting in machine data of PT3M23S; not understandable to humans, and therefore not a valid expansion of ‘three minutes and twenty-three seconds’.

Cases of Fixed Data Formats in Microformats

The following are all current uses of fixed format machine data required by the various microformats.



  • Telephone type keywords: voice, home, msg, work, pref, fax, cell, video, pager, bbs, modem, car, isdn, pcs.
  • Address type keywords: INTL, POSTAL, PARCEL, WORK, dom, home, pref.
  • Email type keywords: INTERNET, x400, pref.
  • Uses ISO 8601 date for bday
  • ISO 8601 time zone for tz
  • Telephone numbers requires a numerical form, whilst phone numbers can be presented in alpha-numeric form: e.g. +1-555-FORMATS


  • Uses an ISO 8601 date-time for dtreviewed


  • Uses ISO 8601 date-time for updated
  • Uses ISO 8601 date-time for published


  • Uses ISO 8601 date for individual experience items.
  • Uses ISO 8601 date for individual education items.


  • Requires latitude and longitude in decimal form (1.23232;-2.343535), but may be published in degrees: N 37° 24.491, W 122° 08.313
  • Locations are most often published just as place names (not abbreviated co-ordinates)


  • Uses ISO 8601 for track duration, e.g. PT3M23S

Misconceptions of Fixed Data Formats in Microformats

There are also cases (at least one) of apparent fixed data formats in microformats which should not require the providing of a separate value. It is useful to document these as a way to clear up apparent misconceptions.


  • Uses fixed-point integer values from 0-5 for rating (publishers may, for example, display a percentage rating)

There are several misconceptions here.

  1. The default rating values in hReview 0.4 (in progress) are from 1.0-5.0 (not 0-5)
  2. hReview permits the author to state their own 'worst' to 'best' range for any given 'rating'.

Thus a publisher that wants to display a percentage rating can do so by simply specifying a 'worst' value for a rating of 0, and a 'best' value for a rating of 100. Then the actual percentage rating can simply be marked up inline and no separate machine value is necessary.

Embedding Fixed Data Formats in Microformats

There are currently three supported methods of including these fixed data formats in a microformatted document.

As Visible Page Content

You may use the standard class-design-pattern to mark-up the data visibly in the page.

Ben was born on <span class="bday">1984-02-09</span>.

We're meeting up on Northumberland Avenue (<span class="geo">51.507033,-0.126343</span>).

As An Abbreviation

In some cases, the data formats specified make valid expansions of common human forms, such as dates in in an hCard birthday field:

Ben was born on <abbr class="bday" title="1984-02-09">9th February</abbr>

Note, however, that not all data formats are valid expansions. In HTML, the abbr element is working semantically at a text level, not a data level. Both the abbreviated form (the inner text) and the expanded form (the title) need to be consumable by humans.

This means that in hAudio, using an abbreviation for duration is incorrect:

<abbr class="duration" title="PT3M23S">3 minutes, 23 seconds</abbr>

Whilst the data ‘PT3M23S’ is an expanded form of ‘3 minutes, 23 seconds’, the text is not; ‘PT3M23S’ is nonsense to most human beings. abbr is an element that describes the text, not the data. HTML4 has no way to mark up arbitrary data.

Using the value-class-pattern

See Value Class Pattern.


  • James Craig and Bruce Lawson for the suggestion using an empty span as a means of embedding data without it being exposed in assistive technology
  • Jeremy Keith for assistance refining the invisible data extension to value-excerpting

Related Pages