BBC Balloon Release Complaint

Here’s a complaint I lodged with the BBC, on Saturday, 30 January 2010, with added links and image:

Prof. Jim Al-Khalili, on the BBC’s ‘Chemistry: A Volatile History’, (ep. 2) released a big, red, helium-filled balloon, with a string attached.

On its return to earth, the balloon will become litter. Balloons are harmful to wildlife, as documented by the Marine Conservation Society.

The Environmental Protection Act 1990 unequivocally makes it is an offence to drop ‘or otherwise deposit’ litter in a public place.

The Marine Conservation Society are campaigning to stop balloon releases, both by persuasion in the short term and, eventually, through prohibitive legislation. They are supported in that campaign by a large number of reputable organisations, including the RSPB, the RSPCA, the National Farmers’ Union, the Tidy Britain Group, Keep Scotland Beautiful, county bird clubs, various Wildlife Trusts and other organisations.

Please make it BBC policy to forbid the release of balloons, as many other organisations have done.

I’ve e-mailed a courtesy copy of the complaint to Prof. Al-Khalili. I’ll let you know what responses I get.

Manu Sporny recommends me on LinkedIn

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

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!

Bacchus Bar, Birmingham. Awful.

I spent yesterday evening, from 7-11, in Bacchus Bar, Burlington Arcade, Birmingham, one of Mitchells & Butlers‘ supposedly “Classic Pubs”. Had I not been there as a guest of others, for whom I have great respect, I would have left.

The only guest ale was off.

The dirty plates left by the departing people whose table we occupied, and their and our empty glasses and bottles, were not collected once. The plates included uneaten food, which sat festering for four hours.

The men’s toilets were an utter disgrace: stinking, awash with urine – footsteps caused audible splashes; I’m going to have to have my trousers laundered – and clearly not attended to all evening. Everyone who entered, each time I was in there, commented. I was told the women’s toilets were little better.

A pile of vomit on the carpet outside the toilets was marked with a “wet floor” A-frame, but otherwise left for over an hour, remaining until after closing.

I have never seen such bad practice, even in run down inner-city pubs; let alone a supposedly prestige, and pricey, city-centre venue.

Update: I have contacted Mitchells & Butlers, and asked them to respond here. Their contact form includes several unnecessary yet mandatory questions, such as wanting my postal address (which I declined to give, using bogus data instead) and the number in the party, which must be a number, making it impossible for me to say “over 15″.

Machine Tagging Flickr

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

I am not a Twitcher!

Three times this week, people have referred to me, in good faith, as a “twitcher”. I’m not, and I blame lazy tabloid hacks for creating this misconception, which I will now try to lay to rest.

I am a birdwatcher or, if you will, a birder. I like to be outdoors, with my binoculars and sometimes a telescope, to watch birds. I like to travel to different places, such as hills or the coast, to see different kinds of birds, but I also like to watch common birds, like Starlings, in my garden, or as I move around my home city.

[Picture: Common Starling, Sternus vulgaris, from Creative Commons, by Paul Stein; licenced under Attribution-Share Alike 2.0 Generic.]

I like to know their life histories, and to read about and study their behaviour, their conservation and their contribution to human folklore.

All together, this brings me a great deal of enjoyment, and helps me to de-stress after spending long hours at a desk in front of a computer, or in stuffy meetings, in my day job. I try to pay some of it back, by sharing my interest with non-birders, and beginners, and by doing voluntary work for the RSPB and the West Midland Bird Club, of which I’m a trustee.

Occasionally, I am pleased to chance upon a rare bird, or to travel a short distance to a local reserve, knowing one is present. The interest in seeing a new species this way is sometimes tempered by the fact that, if it’s a rare vagrant from Siberia or the Americas, it is likely to be exhausted and near death. At the very least, it will never get home or find a mate.

Twitchers, on the other hand, enjoy an extreme, compulsive type of birding, whereby they will hunt out such rarities, competitively, often travelling great distance, at great cost, and enduring considerable discomfort, to do so. They will often prefer to see one bird of a new species, involving a day or more travelling, over the opportunity to spend time looking at a whole range of other, more common birds (which some of them refer to as “trash birds”). There have been cases of twitchers paying hundreds of pounds to charter a boat or plane to get them to The Scillies or The Shetlands, and one once famously left his own wedding reception and missed the start of his honeymoon, to chase after a rarity.

Unlike some birders, who disdain them, I make no judgements about twitchers, and I know that some are very knowledgeable, and are just as likely as other birders to be involved in voluntary and conservation work.

But I’m not one of them. I trust that that’s now clear.

Triple-tag references to Twitter posts

Further to my post about a protocol for Twitter posts, you can also triple-tag blog posts, Flickr images and similar web utterances, which refer to a specific twitter post (or status) like this: twitter:status=1975532392 – and this post is tagged with that!

[Update: See also my Flickr screenshot of a Twitter post, triple tagged with #twitter:status=1828036334 to reference the same post.]

Poorly lawnmower

One thing that really irks me is when an otherwise working product fails because of one component which is not easily fixed or replaced – “built in obsolescence”, as its called. It may be good for the maker’s bottom line, but it’s bad for mine; and really bad for the environment.

I have a Black & Decker GR280C rotary lawn mower, which still works, but the blade keeps spinning loose once it’s switched off – as it decelerates, the bolt which holds the blade in place unscrews.

Can anyone suggest how this can be repaired, or a part replaced, before I have to junk the whole mower?

Twitter: canonical URLs and Protocols

On Twitter, I’m twitter.com/pigsonthewing, but in my preferred twitter client, Dabr, I’m dabr.co.uk/user/pigsonthewing. We might refer to the former as the “canonical” URL.

There are a number of other web-based Twitter clients, too, and people using them can find my twitter stream, variously, at:

• m.twitter.com/pigsonthewing
• accessibletwitter.com/app/user.php?uid=pigsonthewing
• m.slandr.net/user?id=pigsonthewing
• tweetree.com/pigsonthewing
• m.tweete.net/pigsonthewing
• hahlo.com/user_timeline.php?user=pigsonthewing
• www.twitstat.com/m/index.php?userid=pigsonthewing

Likewise each of my Twitter posts, or “tweets”, has a URL on each of some of those domains (though not on all, it seems). For example:

• twitter.com/pigsonthewing/status/1828036334
• dabr.co.uk/status/1828036334
• accessibletwitter.com/app/status.php?1828036334
• m.slandr.net/single.php?id=1828036334

are all the same tweet. We can again regard the first of them, on twitter.com, as canonical.

Anyone using one of those services, and who wants to link to my profile or one of my tweets will either post the URL as it appears in their service, which isn’t much use to people not using that service, or expend time and effort translating the URL into the generic, canonical, Twitter format — which even then may not be of much use to someone using something else.

In the short term, we could do with some recognition of this fact from the above services, which might provide a link to the “standard” or canonical URL for that tweet; and when doing so on an individual page, should link to it using rel="alternate" and/ or rel="canonical".

Better still, there could be browser tools (such as FireFox plug-in or Greasemonkey script) to do that task, automagically.

Ultimately, though, as Twitter becomes ever more widespread, perhaps we need a pair of protocols for linking to Twitter profiles and posts. Using this, authors would be able to mark up links to me and my comments on Twitter as, say:

<a href="twitter:pigsonthewing">Andy Mabbett</a> said <a href="twitterpost:1827840116">something witty</a>.

Then, each reader could set their computer to open those links their choice of browser-based or desk-top/ mobile phone client. The setting to do could even be changed in the installation package for such tools, to aid non-technical users.

Footnote: if you know of another URL for my Twitter stream, please let me know!

Dates and coordinates in HTML5

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 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?

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>