Category Archives: microformats

Fixing Facebook’s Microformats (at their request)

6 Replies

Twitter, and the wider ‘blogosphere’, have been alive tonight (UK time), with people commenting on, or mostly simply repeating, the news that Facebook have implemented the on all their events, making them parsable by machines and thus easy to add to desktop or on-line calendars. They’ve also included for venue details.

This is generally a good thing, but what most people — at least some of whom should have known better — failed to notice was that the implementation is broken.

Consider this event, a concert by my friends’ band, Treebeard:

which, as you can see, is on 18 February from 19:00–22:00 (7–10pm).

That’s encoded, in the Facebook page’s mark-up, as:

<span class=”dtstart”><span class=”value-title” title=”2011-02-18T19:00:00-08:00“> </span>19:00</span> – <span class=”dtend”><span class=”value-title” title=”2011-02-18T22:00:00-08:00“> </span>22:00</span>

The “-08:00” at the end of each date-time value represents a timezone 8 hours behind UTC (as we must now call Greenwich Mean Time) — that would be correct were the event in California, or elsewhere in the Pacific Time Zone; but for the UK, the mark-up translates to 3-6am.

Since the event is in the UK, the start time should be encoded as “2011-02-18T19:00:00+00:00“, which puts it in the correct UTC timezone (in British Summer Time, it would be “2011-02-18T19:00:00+01:00“). Ditto for the end time.

The same will apply for events in any other timezone on the planet, each with an appropriate adjustment.

I’ve already alerted Facebook developer Paul Tarjan to the problem, and this is my response to his requests for assistance in fixing it.

Sharing images openly is better than uploading to single sites

Leave a reply

Simon Whitehouse, blogging as part of his day-job with Digital Birmingham, suggests that to the History Pin website.

That’s a neat idea; it would be a collaborative move on behalf of the City (disclosure: they employ me, but these are my own thoughts), and would be of interest to the general public.

However, the time and effort spent doing do so would only be of use to that one site and its visitors.

A better solution, perhaps, would be for the City Council (and anyone making archives of images available in an open manner) to invest the equivalent effort in adding metadata (about the subject, location, date and licence, which should of course be open) to suitable images, and for third-party sites to then parse that metadata, and import the images. Of course, such an import could also be done by individuals, on an “as needed” (or more likely “as desired”) basis, as a crowd-sourcing activity.

Carved and painted stone coat of arms

My picture of the City of Birmingham's pre-1974 coat of arms, hosted on Flickr, where it has lots of lovely, rich metadata and an open licence

The question is — what is the best way to include such metadata — internal to the image, in a format like ? As scrapeabe text, on a page displaying the image, like Flickr’s metadata, such as tags? Or on such a page, but using a parsable , or as a separate resource, such as ? Or a combination of these?

And are any third-party sites already indexing or aggregating images and their metadata in this way? If not, why not? Do we have a chicken-and-egg problem?

Everything at your postcode – proposal for a new website

13 Replies

Over the last few weeks, I have been imagining a website for UK citizens and visitors; where they can enter their postcode and be served a page or pages of hyperlocal links about everything to do with where they live. This post is me continuing that thinking out loud; comments — including the constructively critical — are actively solicited.

Links could be almost anything, from local government services (via DirectGov and OpenlyLocal) to public transport information; from maps to fun things. They would either link to sites which use postcodes as as an argument; or would be built using the target site’s postcode-lookup API.

The site would avoid the need for each hyperlocal website to compile its own list of such links.

Here are a few such links, based on a randomly-selected postcode, B23 6UH (I simply opened a local newspaper and picked the first advert that used a Birmingham postcode). Note that the first link is computed; the rest use the postcode directly.

User would also be able to suggest additional links if they find a good web service which takes a postcode as a locator — for now, please feel free to do so in comments on this post, and I’ll add them to the above list. Purely commercial links, like individual chains’ store locators, would be excluded (a few paid for links, clearly identified as such, might generate enough revenue to cover hosting costs).

As can be seen from the above, the site wouldn’t actually store or generate content; just links. The links could be clustered under headings, or on sub-pages, like “maps”, “local services”, and “fun stuff”.

It might also be possible for the site to determine the user’s nearest postcode, using their browser or device’s GeoLocation feature, or by selection from a map. The site would also accept partial postcodes, such as “B”, “B23” or “B23 6”.

The service could perhaps be “widgetised” for inclusion on other sites. And of course, it would be possible to link to the site using postcode as an argument.

The site would, of course, make data available in RSS, OPML and open data formats; and use microformats.

Unfortunately, though be willing to collate and maintain the links and code some HTML, I lack the programming and graphic-design skills to make such a site, which means that I must rely on the good will of others. Can you help? Should I organise a hack event (a day, or an evening) at a Birmingham venue, to work on this collaboratively?

Or does such a service — curated, rather than spammy — already exist? Would it belong better as an adjunct to an existing service like OpenlyLocal or DirectGov?

Over to you…

Proposed citation microformat: better than COinS metadata

1 Reply

My is given as a reference in , on Wikipedia.

The reference is entered using Wikipedia’s {{Cite book}} template, which in turn emits the requisite HTML mark-up, including :

<span class="citation book">Mabbett, Andy (2010). <i>Pink Floyd - The Music and the Mystery</i>. London: Omnibus,. ISBN <a href="...">9781849383707</a>.</span>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pink+Floyd+-+The+Music+and+the+Mystery&rft.aulast=Mabbett&rft.aufirst=%26%2332%3B%26%2332%3BAndy&rft.au
=Mabbett%2C%26%2332%3B%26%2332%3B%26%2332%3BAndy&rft.date=2010&rft.place=London&rft.pub=
Omnibus%2C&rft.isbn=9781849383707&rfr_id=info:sid/en.wikipedia.org:Pink_Floyd_The_
Wall_(film)"><span style="display: none;"> </span></span>

And here it is again, with line breaks inserted for clarity:

<span class="citation book">Mabbett, Andy (2010). <i>Pink Floyd - The Music and the Mystery</i>. London: Omnibus,. ISBN <a href="...">9781849383707</a>.</span>
<span class="Z3988" title="ctx_ver=Z39.88-2004
&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook
&rft.genre=book
&rft.btitle=Pink+Floyd+-+The+Music+and+the+Mystery
&rft.aulast=Mabbett
&rft.aufirst=%26%2332%3B%26%2332%3BAndy
&rft.au=Mabbett%2C%26%2332%3B%26%2332%3B%26%2332%3BAndy
&rft.date=2010
&rft.place=London
&rft.pub=Omnibus%2C
&rft.isbn=9781849383707
&rfr_id=info:sid/en.wikipedia.org:Pink_Floyd_The_Wall_(film)">
<span style="display: none;"> </span>
</span>

Some people complain that the presence of COinS bloats pages which have many references: for instance, note that my name, the publisher (“Omnibus“), publishers’ location (“London“), ISBN etc., plus the article’s URL, are repeated in the title attribute of the span which has class=”Z3988″, used to denoted COinS metadata.

If we were to mark that up with the proposed citation microformat, hCite, it might look like this:

<span class="citation book hCite"><span class="author vcard"><span class="fn">Mabbett, Andy</span></span> (<span class="dtstart">2010</span>). <i class="work">Pink Floyd - The Music and the Mystery</i>. <span class="publisher vcard"><span class="label">London</span>: <span class="fn org">Omnibus</span>,. ISBN <a href="..." class="isbn">9781849383707</a>.</span>

Despite adding semantic class names (hcite, author, vcard, fn, dtstart, work, publisher, label, org, isbn), and span elements on which to hang some of them, this is markedly more compact (down from 614 to 363 characters, excluding the redacted URL), easier for humans to read, doesn’t require lots of escaped characters and doesn’t repeat any of the data. The processing burden on Wikipedia’s servers would also be lower.

The primary tool used for accessing COinS metadata is Zotero; whose authors have already indicated to me (in conversation) an interest in parsing such a microformat.

Discussions of what to include in the proposed citation microformat on the microformats mailing list stalled sometime ago, but that doesn’t stop an organisation like Wikipedia from developing a draft, implementing it, and presenting it to the wider web community for discussion, improvement and ratification. The draft could have 1–1 mapping with the properties in COinS, to facilitate ease of conversion by parsing tools.

An open letter to Facebook, about their broken microformats

Leave a reply

Dear Facebook,

Thank you for adding an hCard microformat to my profile on your site.

However, it’s broken, as you can see in this screenshot, made using the debugger in the superb ‘Operator’ add-on for Firefox:

Microformat contains bogus "org" and "title" properties and no ""URL" or "email" properties

My Facebook profile, with broken hCard microformat shown in Operator toolbar's debugger

You need to fix some things:

  • I am not an organisation, so please remove the org property (you may have some user accounts for organisations, contrary to your own polices. That’s their, and your, problem — individual users are by far the majority).
  • The names of six of my friends, chosen by you at random, are not my titles. My title is currently “Mr”. (I say currently; it might change to “The Right Honourable”, if ever gets to be PM and I threaten to publish the pictures).
  • Add class="url" and rel="me" to my web addresses, This is probably the single most useful thing you could do for me right now. Unless you like ironing.
  • Add class="email" to… oh, you guessed, To my e-mail address; that’s right. I’m sure that won’t be hard to do.
  • Add a machine readable date and mark up my birthday as such: I might get more cards if you do.
  • Mark up my address as such, or at least as a label.

If you do this for me, I promise not to refer to you as “Farcebook” again. Until the next time you screw up, that is.

All the best

Andy
— x —

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!