Tag Archives: microformats

Google Maps’ microformats: unhappy anniversary – still broken after three years

Leave a reply

Three years ago today — on 31 July 2007 — Google proudly announced that they had added hCard microformats to Google Maps, so that, as they put it:

your browser can easily recognize the address and contact information in the page, and help you transfer it to an addressbook or phone more easily

Less than four hours after seeing a mailing-list repost of that announcement, by Google‘s Kevin Marks (one of the two signatories of the initial announcement), I replied, pointing out that the implementation was badly broken, and that none of the microformats in a search for a single entity, in this case a school, were valid. (As is usual on Google’s own blogs, there was no facility for comments on the original announcements.)

Google‘s Gregor J. Rothfuss, the announcement’s other signatory, replied that he would look into the matter.

Almost a month later, I asked Gregor if there had been any progress, and he said (I quote him in full):

i will work on it when i have some time.

so I took him at his terse word, and left him to it, with no further reminders. That’s the last I heard from anyone at Google on the issue.

Three years on, though the specific faults have changed, not one of the microformats in the Google Maps search linked above is valid (the mandatory “fn”, or “formatted name” property is missing; address components lack the mandatory child-properties) and I have been unable to find one that is, in other results. They are as useless to someone wanting to add the subject’s address to their address book today as they were on day one.

Update, 31 July 2011: Another year has passed, the microformats are still broken.

Overdue measurement microformat: useful for radio station frequencies

4 Replies

Three or four years ago, I and a few others did a lot of work preparing a draft for a , hMeasure, for marking up length, mass (weight), temperature and so on. Sadly, it has yet to be taken up by the unelected and unaccountable clique who oversee the microformats “process” — but that’s a story for another time.

Recently Corey Mwamba asked how he could semantically mark up the frequencies of radio stations, for example:

Heart FM (Sussex) 102.4 MHz (Eastbourne)

My friend Toby Inkster rightly proposed the use of the “note” property, but I think that authors could also usefully use a non-microformat class name of “frequency”, for added semantic richness (and to aid screen-scrapers), and better still, the proposed hMeasure:

         <div class="vcard">
                 <b class="fn org">Heart FM
                    (<span class="adr">
                        <span class="locality">Sussex</span>
                     </span>)
                 </b>
                 <i class="note frequency">
                         <span class="hmeasure">
                          <span class="num">102.4</span>
                          <span class="unit">MHz</span>
                        </span>
                         (<abbr title="50.9761;0.2293" class="geo">
                              Eastbourne
                          </abbr>)
                 </i>
         </div>

If enough people use this pattern (and write up their experiences of doing so), then a de facto microformat will emerge.

Update: There’s a copy of that code at pastebin.com/CXCYT5nF which has syntax highlighting, and which you can replicate and edit if you wish to make a counter suggestion.

Update 2: I have now implemented this in the Wikipedia Frequency template, as seen, for example, on the article about BRMB.

Lists in Microformats: Suggested Optimisation

4 Replies

Based on my extensive experience of applying microformats to templates in Wikipedia (and other MediaWiki installations) I’ve come to the following conclusion…

For attributes which can occur more than once (such as nickname or category in hCard), lists having, or in container having, that property should be parsed as lists of individual instances of that property.

For example:

<div class="category">
<ul>
<li>ornithologist</li>
<li>driver</li>
<li>gardener</li>
</ul>
</div>

and:

<ul class="category">
<li>ornithologist</li>
<li>driver</li>
<li>gardener</li>
</ul>

should be treated as equivalent to:

<ul>
<li class="category">ornithologist</li>
<li class="category">driver</li>
<li class="category">gardener</li>
</ul>

Manu Sporny recommends me on LinkedIn

1 Reply

I hope you will forgive me for immodesty repeating Manu Sporny’s kind and fulsome recommendation of me, from my LinkedIn profile, for the benefit of those of you who don’t have accounts there:

I had worked with Andy in the Microformats community, developing international standards for the Web. During this time Andy not only excelled at providing technical feedback and review, but led several bold initiatives to standardize the classification of planetary-geo-location and living species on the web. While a logically consistent and wise technical contributor, his influence on the direction of the community was also vital. Andy’s role in questioning and influencing the core philosophy and community process was and continues to be deeply appreciated.

I’m genuinely touched by that. Thank you, Manu!

Manu Sporny is CEO of Digital Bazaar.

Twitter: A microformat in lieu of a protocol

8 Replies

In May of this year I wrote about the problems of URLs for a given Twitter user’s profile, or for an individual post or “status” being different, depending the Twitter client in use. I suggested a new protocol for Twitter links. [You might want to read that, before the rest of this post]. I can’t believe I didn’t think of this simpler solution sooner!

The answer (in the short term) is to use a microformat (or a microformat-like “poshsformat”, if you prefer to call it that) for each case. Let’s say we use the classes twitter-user & twitter-status.

User-agents (that’s jargon for browsers) could then employ a script (such as those used by GreaseMonkey, or a Firefox extension) to ignore the encoded URL and substitute the equivalent for the user’s preferred Twitter client instead.

For links to user profiles:

<a
href="http://twitter.com/pigsonthewing">
Andy Mabbett
</a>

would become:

<a
class="twitter-user"
href= "http://twitter.com/pigsonthewing">
Andy Mabbett
</a>

and:

<a
href="http://accessibletwitter.com/app/user.php?uid=pigsonthewing">
Andy Mabbett</a>

would become:

<a
class="twitter-user"
href=" http://accessibletwitter.com/app/user.php?uid=pigsonthewing">
Andy Mabbett</a>

Likewise, for individual statuses:

<a
href="twitter.com/pigsonthewing/status/1828036334">
something witty</a>

would become:

<a
class="twitter-status"
href="twitter.com/pigsonthewing/status/1828036334">
something wittyg<a>

and:

<a
href="accessibletwitter.com/app/status.php?1828036334">
something witty<a>

would become:

<a
class="twitter-status"
href="accessibletwitter.com/app/status.php?1828036334">
something witty<a>

and:

<a
href="m.slandr.net/single.php?id=1828036334"
something witty</a>

would become:

<a
class="twitter-status"
href="m.slandr.net/single.php?id=1828036334">
something witty</a>

To simplify matters, the rules for extracting the user ID or the status update could be the same in both cases:

  1. Parse the value of the href attribute of the element to which the class applies.
  2. If there is a question mark, use everything after that.
  3. Otherwise, if there is an equals sign, use everything after that.
  4. Otherwise, use everything after the last slash.

That would deal with all the examples in my earlier post.

So, if you’re using a user-agent which is aware of this microformat, and find on a page:

<a
class="twitter-user"
href="http://twitter.com/pigsonthewing">
Andy Mabbett<a>
said
<a
class="twitter-status"
href="m.slandr.net/single.php?id=1828036334">
something witty<a>

but your preferred Twitter client is Dabr (one I recommend, BTW!) then your browser would treat (and possibly render) that as:

<a
href="dabr.co.uk/user/pigsonthewing">
Andy Mabbett<a>
said
<a
class="twitter-status"
href="dabr.co.uk/status/1828036334">
something witty<a>

Simples!

Machine Tagging Flickr

Leave a reply

I’ve posted some more thoughts on machine- (or triple-) tags and microformats on Flickr, in their Flickr Ideas group.

Update: There is now a tool to automatically generate tags for Flickr images of living things; iNaturalist tagger.

Dates and coordinates in HTML5

7 Replies

I’m grateful to Bruce Lawson of Opera for alerting me to discussion of the <time> element on the HTML5 mailing list (where I’ve posted a copy of this blog post) and encouraging me participate; and indebted to him for the engaging discussions which have led me to the ideas expressed below. So please blame him if you don’t like what I have to say 😉

I’ve read up on what prior discussion I can find on that mailing list; but may have missed some. I’ll be happy to have anything I’ve overlooked pointed out to me.

I have considerable experience of marking up dates in microformats, both for forthcoming events on the West Midland Bird Club’s diary pages; and for historic events, on Wikipedia and Wikimedia Commons.

I’ve been a staunch and early critic of the accessibility problems caused by abusing the <abbr> element for things like machine-readable dates (as has Bruce). The HTML5 time element has the potential to resolve that problem, but only if it caters for all the cases in which microformats are — or could potentially be — used.

It seems to me that there are several outstanding, and overlapping, issues for <time> in HTML5, which include use-cases, imprecise dates, Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates. First, though, I should like to make the observation that, while are most commonly used to allow event details to be added to calendar apps, and that that use case drove their development, they should not be seen simply as a tool to that end. I see them, and hope that others do, as a way of adding semantic meaning to mark-up; and that’s how I view the “time” element, too. Once we indicate that the semantic meaning of a string of text is date, it’s up to other people to decide what they use that for — ”let a thousand flowers bloom”, as the adage goes.

Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (“find me all the pages about events in 1923″ — recent developments in Yahoo’s YQL searching API (which now supports searching for microformats) have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a “SIMILE” or similar time-line. They can be translated into other languages more effectively than raw prose; they can be disambiguated (does “5/6/09” mean “5th June 2009” or “6th May 2009”?); and they can be presented in the user’s preferred format (I might want to see “5th June 2009”; you might see “June 5, 2009″ — such presentational preferences have generated arguments of little-endian proportions on Wikipedia).

hCalendar microformats are already used to mark up imprecise dates (“June 1977”; “2009”). ISO8601 already supports them. Why not HTML5? Though care needs to be taken, it’s even possible to mark up words like “today” with a precise date, if that’s generated real-time, server-side.

The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like:

<time schema="[schema-name]" datetime="[value]">[date in plain text]</time>

where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply:

[date in plain text]

if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.

As for BCE dates, they’re already allowed in ISO 8601 (since there was no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see no reason why they should be disallowed in <time> elements in HTML5. We wouldn’t, to take an extreme example, say that “<P>” can be used for paragraphs in English but not French; or paragraphs about literature but not music, so why make an effectively arbitrary limit on the dates which can be marked up semantically? Surely the use case for marking-up a sortable table of Roman emperors, should allow all such emperors, and not just those who ruled from 0001AD, to be included?

Coordinates

Another abuse of ABBR in microformats for coordinates:

<abbr class="geo" title="52.548;-1.932">Great Barr</abbr>

Bruce and I agree that this could be resolved, and HTML5 usefully extended, by a “location” element:

<location latitude="52.548" longitude="-1.932">Great Barr</location>

Using the “schema” attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies):

<location schema="moon" latitude="52.548" longitude="23.47297">Sea of Tranquility</location>

and for nonWGS84 coordinates, in a manner similar to that I described in my proposals to extend the related Geo microformat.

Now all we need to do is to work-around the abuse of ABBR for durations, in the draft hAudio microformat:

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

How microformat developments are blocked

1 Reply

The hCard microformat can distinguish between a person and an organisation, by the use of the org property:


<div class="vcard">
<span class="fn">Andy Mabbett</span>
</div>


<div class="vcard">
<span class="fn org">The Red Cross</span>
</div>

but it cannot distinguish between an organisation and a place:


<div class="vcard">
<span class="fn org">The Wembley Stadium fan club</span>
</div>


<div class="vcard">
<span class="fn org">Wembley Stadium</span>
</div>

treating them both as organisations.

On 31 December 2007, I described a way in which hCard microformat could be used to differentiate between hCards for places and organisations.

On 9 January 2008, having received favourable comment, I made a formal proposal to update the hCard specification.

Despite this ten-day gap, Brian Suda, one of the microformats “admins”, the cabal who control microformats, complained that he’d only had two days to consider the matter, and that “More time is needed to fully look over the implications of this change.”

No objections to the method, nor issues with it, have been raised.

Toby Inkster’s superb microformats parser Swignition (formerly called “Cognition”) has supported the method since version 0.1-alpha8, released in May 2008.

One year on from my formal proposal, what changes have been made to the hCard specification, in this regard? None.

Update: Three years on from my formal proposal, what changes have been made to the hCard specification, in this regard? None.

hAccessibility: BBC drop hCalendar microformat

5 Replies

Almost two years after I first raised the issue (to a reaction from the cabal that runs the microformats “community” which began with denial and moved to hostility) the BBC have stopped using the hCalendar microformat due to accessibility concerns.

Maybe now something can be done to incorporate one of the several, more accessible proposed work-arounds, into the relevant standards?

Thanks to Bruce Lawson and Patrick Lauke for breaking the news.

Update: Patrick now has a post on the subject, at webstandards.org

Spotted Mimics

1 Reply

As a child, I was often taken to our local shopping centre in Perry Barr, north Birmingham (since replaced by a tin shed with pretensions of being a mall) to see a Mynah bird (Acridotheres tristis). It resided in what I now realise was a ridiculously small cage, on the counter of a petshop, and would delight all and sundry by asking repeatedly, “Where’s George?”, wolf whistling, or performing another of its many acts of mimicry.

Now my ears are more attuned to such things I realise that the journey was unnecessary. Still living in Birmingham, I can hear the avian equivalent of Rory Bremner any time I wish, simply by opening a window and listening to the Mynah’s relatives, my local Starlings (Sturnus vulgaris). With the onset of autumn, they flock in ever increasing numbers, resplendent in new, strikingly sleek and spotty plumage, and very vocal. As well as having an uncanny ability to sound like any number of other birds, they have been known to imitate car alarms and mobile phones, and even children’s playground screaming.

The quiet suburban road where I live is rarely without Starlings, at any time of day, but the city-centre skies are no longer darkened by the flocks which came in to roost there in my childhood. A backfiring car would see thousands take off at once, and have pedestrians reaching for tissues to remove their supposedly “lucky” deposits from clothing or — worse — hair.

The birds in my garden are far better behaved, except when treated to their favourite delicacy: leftover, raw, shortcrust pastry. They descend from my and my neighbours’ rooftops the second I step back from the bird table, and the food disappears in moments, in a cloud of flying feathers and squawking and pecking bills, the birds mingling too rapidly to count accurately.

One particularly convincing, if annoying, individual has perfected the art of reproducing a Buzzard‘s (Buteo buteo) mewing call, no doubt heard in more open country. Ever gullible, I rush into the garden each time it performs this trick, in the hope of adding the real thing to my “garden list”. So far, without success.

[The above was written some time ago, with the intention of emulating the Guardian’s Country Diary column. As such, it has exactly 200 words, not counting the subsequent addition of scientific names. These are marked up with the draft Species Microformat, which I developed, and which is already being used on Wikipedia.]