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.
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 hCalendar microformats 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?
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>
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.
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
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.]
It’s one year today since Bruce Lawson and James Craig published “hAccessibility“, about the misuse of the ‘abbr’ element in microformats (an issue I first raised on 20 September 2006 in Accessify Forums).
As recent events show, the microformats cabal still has its collective head up its own^W^W^W in the sand.
Despite suggestions for a workaround, a solution seems no nearer, thanks to their apparent indifference. Shame on them.
Twitter posts like this one:
have a place- name and corresponding coordinates (indicated by the prefix “l:”). This has allowed them to be plotted on a map.
It should be possible for the poster to send, say:
We’re still deep in the Sundarbans, near Tambulbunia, meeting experts on dolphins and tigers. #hcard: fn+locality:Tambulbunia: country-name:Bangladesh: geo:22.27722,89.71905
using colons as delimiters and have Twitter render that comment marked up as an hCard.
In the short term, this could be achieved by a third-party site, like #hashtags .
UPDATE: being more mindful of the 140 character limit than I have in the above example, perhaps class names might be abbreviated (“loc” for “locality”, “ctry” for “country-name”, and so on).
Dear Nokia, and Opera,
When using your browsers on my N95, please can I:
Surely that’s not a lot to ask for? Thank you.