Labov's Haskins Prize Lecture
« previous post | next post »
Bill Labov's 2009 Charles Homer Haskins Prize Lecture, “A Life of Learning: Six People I Have Learned From", is now available in a new form, as a text with embedded audio highlights.
The Haskins Prize Lecture is named for the first chairman of the American Council of Learned Societies. Each year's winner is asked "to reflect on a lifetime of work as a scholar and an institution builder, on the motives, the chance determinations, the satisfactions (and dissatisfactions) of the life of learning, to explore through one’s own life the larger, institutional life of scholarship".
[A meta-comment: in order to embed the audio clips conveniently in the html, the ACLS folks had to use a commercial product. Their choice offers decent value for money — it's only $19.95 for a single-server version — but the simple function of being able to play an audio clip, in a consistent way across browsers, is long overdue as a standard feature of html. Given that images were available from the beginning — and a wide range of image formats are now straightforwardly transcluded in a consistent way across browsers — it's shocking that (as I understand it) the addition of an audio tag to html5 is still contested.
And yes, I know that there are free alternatives with similar functionality, using flash and the like — I use them all the time. I'm just commenting on what seems to me to be an extraordinary collective failure on the part of the W3C.]
greg said,
January 15, 2010 @ 10:31 am
With regard to the meta-comment, it is only very recently that users' internet connections were capable of quality streaming of audio, let alone video. And then there has also been the problem with reducing the actual audio/video file size via compression while still maintaining the quality of the sound/video. (see: Ars Technica's article on the history of video compression.) The current HTML standard was developed well-before that sort of functionality and capability was common with anything other than MIDI files.
[(myl) I'm not buying this as an excuse. Short mp3 audio clips are not necessarily any bigger than moderate-quality photographic images (which continued to be a problem for some low-bandwidth connection for a decade after html provided for them); and hundreds of millions of users, worldwide, have had internet connections adequate even for video streaming, much less audio streaming, for several years. That's why YouTube was an instant success in 2005-2006. And the W3C's role in other areas has been to (try to) provide standards that the web can grow into, not be to provide mechanisms for providing web content five or ten years after everybody has learned to make do with a bewildering variety of inconsistent and inadequate alternative solutions.
No, I don't think there's any question about it: the W3C has embarrassed itself and failed the public it's supposed to serve. You can argue about whose fault it is, but I don't think that there can be any argument about the fact of failure.]
Nick Lamb said,
January 15, 2010 @ 12:12 pm
I don't think you understand the history of the situation Mark
The web had a perfectly good way to embed any arbitrary thing into a web page for many years, OBJECT. OBJECT is a W3C standard. You can see demonstrations (but they probably won't work in your web browser) of this from perhaps a decade or more ago. It can do audio, or video, or 3D or whatever. Simple, declarative, and doomed.
For OBJECT to be really useful browser vendors have to needed to agree to implement the same formats inside OBJECT.
The biggest vendor, Microsoft, wanted nothing to do with a standard cross-platform solution to play music, let alone video, in a web browser. For them, their existing proprietary solution was a stick with which to beat a commercial rival, Apple. For Apple, it was vital to refuse to work with Microsoft's proprietary solution, and for every small third party, more or less impossible to work with either because of patents licensed under ridiculous "reasonable" terms that are only reasonable to other huge international corporations.
The W3C like the UN is a talking shop. If you go there to tell lies and renege on everything you promise (as Microsoft did for almost five whole years) there is no way to punish you. The W3C can't fine Microsoft for lying, or arrest its senior executives, its other members can only sigh at the waste of everybody's time. It makes no more sense to blame the W3C for the failings of its huge corporate members like Microsoft than to blame the UN for not preventing the US war in Iraq.
[(myl) I do know something about the history, though doubtless not as much as you. There's plenty of blame to go around — we could also talk about Apple's role, for example, which has also been far from positive — but the W3C is a "consortium" which has collectively failed to solve this basically simple problem, for complex legal, political and technical reasons. The analogy to the U.N. is a pretty good one, I think. We could discuss why the U.N. failed so miserably to prevent genocide in Rwanda, or prevent the Srebenica massacre, etc. — how much of the blame should be put on the U.N. bureaucracy, how much on its overall structure, how much on the perfidy or incompetence or divergent interests of particular member states, how much on various individuals — but no sane and honest person would claim that the U.N. succeeded in those cases. Similarly, I don't think it's possible to question the fact that the W3C has failed in this case. Maybe it's the structure of the organization, maybe it's perfidy or incompetence or divergent interests of individual companies, maybe it's some of the individuals involved. But up to now, they've collectively failed, and if there's any evidence that there's a credible path to success in the immediate future — where for current purposes let's define "success" as a tag that plays audio clips and works across operating systems, browsers, and configurations, without using Flash or other external plugins — I'd like to see it.]
Nick Lamb said,
January 15, 2010 @ 12:22 pm
Oh, also images weren't "available from the beginning". Initially the web could handle images only by linking to them, at which point in most cases an external program would run on your computer, load the image and display it*. The IMG element used today was originally a proprietary extension invented to insert small inline "icon like" images, and not envisioned for e.g. having a dozen high resolution photographs on a web page, which explains a lot about its odd default behaviour.
[(myl) I don't know much about the history before 1995, but in 1995 I began using the <img> tag in pretty much the same way that I use it today. In the linguistics department at Penn, we've been preserving our course pages unaltered since 1997, so here's the front page of Linguistics 001 from September 1997, and here's the 1997 front page of Linguistics 520, both of which used the img tag in a way that still works today. I've been waiting since 1995 — that's almost 15 years now, which is nearly a century in Internet Years — for a similarly simple and reliable way to embed audio clips in educational pages.
* This same trick works with audio today – though it's just as frustrating to have an external application, but with the extra complication that a lot more audio file formats won't load on various sorts of computers by default and so there's a good chance large segments of your audience will just see an error.
[(myl) This is exactly true, but there's no credible technical excuse for it. Exactly the same approach that allows the IMG tag to display files in jpg, gif, png, etc. etc. etc. formats could allow audio clips in mp3, aac, wav, etc. etc. formats to be played.]
Nick Lamb said,
January 15, 2010 @ 12:54 pm
Perhaps I'm taking this too personally, but the company I work for is a W3C member, as was the University where I worked previously, and I just don't see how I (or they collectively) could have fixed this. Delivering what users wanted (audio and video that just work on the web) was contrary to the apparent business interests of very large corporations that completely controlled how a majority of those users used the web.
Shouting "you idiots, these corporations are working against your best interests" directly at the users was tried, and it was exactly as ineffective as anyone but the most optimistic and naive student organiser would expect.
Perhaps people like Sir Tim could have remonstrated personally with the senior executives at those companies but I doubt it would have done any good. And frankly Tim is very easily distracted by shiny new toys, he's not the right person to play tough negotiator, the UN at least has the advantage that those represented send trained ambassadors rather than nerdy engineers.
And no, I don't think it makes sense to call this a collective failure. This is not a case of Joint Enterprise. The W3C as an entity did everything it could here, and one or two of its members (which are not the same as the W3C itself, in the same way that an employee is not the same as the company) in particular let you down. Like any standards organisations, from ISO to the IETF it isn't perfect, but it's not to blame for the problem you're talking about.
Nick Lamb said,
January 15, 2010 @ 12:54 pm
“I don't know much about the history before 1995”
Ah, yes, the novelty of IMG is a bit before your time. See for example
http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html
“Exactly the same approach that allows the IMG tag to display files in jpg, gif, png, etc. etc. etc. formats could allow audio clips in mp3, aac, wav, etc. etc. formats to be played.”
That exists, in OBJECT. There's no argument about whether you can tell a web browser to play an audio file, you could do that last century. The question is – will Person A's browser refuse to play file X, whereas Person B's browser will play X but not Y. Without that, you lose the interoperability.
You're content with IMG because of two bits of luck. The patent on the compression used in GIF was hardly enforced on the web, and expired before people got too anxious about it, and the patented "arithmetic" compression in JPEG is optional, and thus nobody uses it. So it happens that all browsers were able to view GIF and JPEG (and today PNG) and therefore you achieved interoperability. But add a "JPEG 2000" or TIFF image to a web page and you get a vision of the world as it might have been – in some browsers it works and in others it does not.
J.W. Brewer said,
January 15, 2010 @ 12:55 pm
To stay away from the metacomment, I thought Labov's presentation was excellent and the occasion for it was also a nice exception from the general marginality and low visibility of linguistics scholarship within the broader academy. (Since this seems to be an everything-but-actual-scientists group, it is perhaps ironic that Labov was unusual in his generation of linguistics scholars for the extent to which he took a more science-like approach to data collection and analysis.) I am idly curious as to whether the Haskins for whom the lecture series is named was some kinsman to the Haskins for whom Haskins Labs is named. It's not a particularly common surname, although to be fair there are more individuals surnamed Haskins with their own wikipedia articles than I would have supposed.
[(myl) The Haskins Prize Lecture is named for Charles Homer Haskins (1870-1937), a historian who was the first chair of the American Council of Learned Societies. Haskins Laboratories was named for Caryl Parker Haskins (1908-2001), an entomologist (and many other things). They were definitely different people — what I don't know is how they were related, if at all.
According to this work,
According to the wikipedia page for Charles Homer Haskins, he was born in Meadville, PA, in the same generation as Caryl Haskins' father. So I'd say that preliminary indications are that their kinship was distant at best. ]
Nick Lamb said,
January 15, 2010 @ 1:12 pm
Here's an example page from 2006 using OBJECT
http://joliclic.free.fr/html/object-tag/en/object-audio.html
According to that page (which may be out of date) all the popular browsers can play WAV. That's great, except WAV is uncompressed, so choosing this route could cost you rather more than $19.95 in bandwidth overage fees if your page is popular.
[(myl) Almost, but not quite yet. When I try that test page across the three computers (Mac OS10.4, Windows Vista, Ubuntu Linux) and four browsers (Safari, Firefox, Chrome, IE, all more or less the latest versions) that happen to be available in the room where I am at the moment, it sort of works, except that
* in some cases, the content plays before any clicking is done, despite the autoplay="false" instructions;
* on the Linux machine, each item will play once, but then the item becomes dead and won't repeat;
* in each case, the appearance of the controller depends on the plug-in (and is therefore variable in size and functionality);
* there seems to be no general way to do some really simple things, like linking the "play" control to an arbitrary graphical or textual element.
And this page suggests that if I really wanted even this much to work in general, I'd have to do quite a bit of extra fussing.
This is a higher general level of functionality than I've seen in the past, but it's really not what any rational content-creator would want for this capability. I'm not saying that anyone in particular is at fault, just that the system as a whole deserves a grade of Bozo Minus on this one.]
Stephen Jones said,
January 15, 2010 @ 3:34 pm
I've always used the 'embed' tag. The problem surely lies in the plugins that will play the file which vary from browser to browser and computer to computer. But what browsers can't play .mp3 files?
I've had problems with .mpeg4 files which seem to require the Quick Time plugin and won't play on our Blackboard system because apparently the file at 125MB chokes the browser, but the problem with mp3s has always been the player wanting to update itself or something equally silly.
Stephen Jones said,
January 15, 2010 @ 3:37 pm
All popular browsers also play mp3s. Are do you think Lynx is still a popular browser?
rpsms said,
January 15, 2010 @ 5:35 pm
I think the real answer to this is patents. GIF was already on the web before the compression patent was enforced/discovered (which led to png development).
There are/were no audio nor video codecs that were not encumbered by such legal issues, and many freeware mp3 codecs are not strictly legal afaik
scott said,
January 15, 2010 @ 6:29 pm
You might be interested in some history of the img tag:
http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element
(google cache)
http://74.125.95.132/search?q=cache:QABCqaDt-4kJ:diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element+dive+into+mark+image+tag&cd=1&hl=en&ct=clnk&client=firefox-a
The short version is, the reason you were able to use an img tag in 1995 because a browser writer wrote it. Not to belittle your pain, but I think some of the frustration comes from the misplaced belief that the WC3 is in charge of anything.
A notable quote from the linked article:
"HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction."
peter said,
January 16, 2010 @ 1:06 am
It's not only in the direct commercial interests of some IT companies to have no agreed standards for the technologies appropriate to their products and services, it is also often in their direct commercial interest for there to be perceptions of chaos and confusion by potential customers about whether and when agreed standards may emerge. It should not surprise us when commercial enterprises act in their own self-interest.
moo said,
January 16, 2010 @ 3:36 am
The audio element has been part of HTML5 for a long time, its syntax is pretty much stable and nobody at W3C disputes it. Even Microsoft plans to support it. It's completely scriptable and much more useful than "object". The only point of contention was, as the Wikipedia article explains, whether the HTML5 spec should require browser vendors to support a specific audio format, and there was no consensus. Still, the audio element can and should be used in HTML5 browsers today. Just offer both an MP3 and an OGG <source> to be cross-browser compatible. For older browsers, Flash player/Java player/download link can be included as a fallback. See this demo page.
audio said,
January 16, 2010 @ 12:54 pm
The inclusion of audio in the HTML standard is uncontested.
It is the choice of audio formats that is.
Patrick Hall said,
January 18, 2010 @ 2:37 am
A worthwhile intro to audio (and video) in HTML5:
http://diveintohtml5.org/video.html#audio-codecs
The details of implementing audio and video are not exactly pretty right because of all the codec spats folks have been describing here, but the contrapation can be made to work, and in just about all the browsers.
Personally, I'm expecting this stuff to (i) become simpler and (ii) become standard. (And when the device tag hits future versions of HTML, it will become possible to record from the browser too. Linguists will be able to do fieldwork with audio and video without installing anything.)
Stephen Jones said,
January 18, 2010 @ 4:44 pm
I am puzzled by Mark's objection. Everything in HTML requires a program on the computer to render it. We can see text because there is a program called a browser that makes that text viewable on screen. We can see certain image formats (but not others) because the browser is a program that makes them viewable within the web page.
However we need a separate program to listen to audio files because the browser does not play audio files out of the box. It requires another program as a plug in. Having an 'audio' tag will only work differently from current 'object' or 'embed' tags if there are browsers that play the appropriate file formats natively. Firefox 3.5 now plays .ogg files natively, but we have to wait until other browsers catch up, and of course other formats still require plugins.