Weibel Lines

Chrome Plaited

Even as a child, I didn't like comics much... I'm a fan of the well-crafted paragraph -- perhaps part of this is that writing is within my reach, whereas drawing is another thing entirely. 

But its a visual age we live in, and I'm certainly not a fan of a text-only web, and there's that picture-worth-a-thousand-words thing, too.  But do we really need dialog balloons to convey textual information?  Art Spiegelman may have let the camel into the tent with Maus, but I mostly find the idiom of 'graphic novels' boring and tedious... even (especially!) if its in the New Yorker, which has been doing comic-idiom pieces for many years now.

So, along comes Chrome, Google's latest foray in the Web-as-OS campaign, and curiously, the comic is one of the main launch communication channels.  I nearly winced.  Then I read it.   It is a convincing and clear explication of why the Web needs a Web browser built from the ground up, and I'll certainly try the browser at the earliest opportunity (later today, apparently, but given that even the comic server is overwhelmed as it seems to be at the moment, how long before it will be possible to slurp down the Chrome code?).

The 38 page comic is remarkable in its clarity on topics such as multi-threaded processes versus multiple-process architecture, garbage collection, testing regimes (and why Google is likely to do this better than most), the virtues of Webkit and virtual machines, intricacies of user Interface choices, privacy, security, and more.  I couldn't have been more surprised.

One of the charming aspects of the comic is that it features some of the engineers behind the browser, so there is yet another benefit for working there... you have a chance at becoming a comic book super-hero.  They missed an important one, though... the communications wizard who is responsible for this terrific archetype of a new age of documentation.

-----

An early morning thunderstorm from my balcony -- a rare thing in Seattle, and one of the things I miss about Midwestern weather.

Social Contracts and Graceful Failure

Sean McGrath blogged several interesting issues having to do with naming and identifiers this past week. The title of his post goes straight to the heart of this important issue: A URL producer/consumer contract. It is this social contract between information providers and consumers that is at the heart of the success of the Web. We use the Web not with an expectation of perfection, but with the realistic hope that when we click, we ‘go’ somewhere useful. Mostly this works, and when it fails, it fails gracefully (back up… go somewhere else… low cost failure).

Our tolerance for the failures is a product of their frequency and impact.  In general, links to resources that are expected to be persistent are managed more carefully, and so fail less frequently. The history of efforts to reduce such failures through technology is tortuous and beyond the scope of this post, but what success as has been achieved falls largely in the category of tools that make easier the job of fulfilling the social contract that Sean’s note alludes to.

Sustaining links to important resources has everything to do with the commitment of organizations, and only to a small extent with a particular technology. Tim Berners-lee suggests that ‘cool URLs don’t break,’ but what could be cooler than his early web-presence having to do with the design and deployment of the Web? You won’t find them at CERN anymore.  While Web historians may relish the challenge of reconstructing these early and delicate threads, they just aren’t accessible to most of us in their original context, and this is in part due to the fact that Tim and his cohorts had other important things to occupy their attention.  CERN, which as an organization might have been expected to be interested in their curation, wasn’t. There’s all that physics to do afterall!

The single important predictor of persistence of identifiers and their resources has to do with the organizational commitment of the managers of content. It’s a social contract. The best we can hope for from technology is for it to make it easier for us to meet those commitments: tools that make management of URI collections easier and cheaper. PURLs are a step in that direction, but not a wholistic solution. More on this directly….

For your "info"

Giddiness is  uncommon in a professional capacity, but that is a little bit how the authors feel at the end of a laborious and frustrating struggle to achieve formal recognition by the IETF of the "info" URI scheme.

The effort stretched nearly two and a half years and many episodes of frustration, angst, and ideological argumentation on both sides.

The "info" URI scheme is predicated on the notion that the current Web identifier architecture is incomplete, and will benefit from a commonly recognized mechanism that:

• acknowledges that sometimes it is useful to decouple identity and resolution,
• supports a mechanism for bringing legacy identifiers into Web-space without directly maintaining Web server infrastructure, and
• provides for simple registration of identifier namespaces that will benefit from a common registration and declaration mechanism.

There are well-known and respectable advocates on both sides of this issue, but their opinions and ideologies will have almost no impact on the success or failure of this informational standard.  Certainly approval by the IETF in itself, while important, will not assure success.  The only thing that really counts is uptake.  Will "info" URIs attract the uptake necessary to generate network effect benefits? Will it add enough value to become a useful and persistent part of Web infrastructure?

The answer is uncertain at this time, but there are reasons to be cautiously optimistic:

• "info" URIs are the basis for the OpenURL naming architecture
• The MPEG community is exploring the use of "info" for the identification of a wide variety of media assets that currently have non-URI identifiers
• A number of communities are experimenting with "info" for identifying 'conceptual' resources -- terms from metadata sets, controlled vocabularies, and classification systems
• SRW uses both HTTP: and "info" URIs to identify objects
• "info" is a candidate for identifying digital assets stored in repositories such as PRONOM.
  

There are sound reasons not to stray from the dominant linking idiom of the Web: HTTP URIs.  Andy Powell's arguments to this effect illustrate why using HTTP URIs should be the starting assumption in the design of every Web identifier system.  But there are also circumstances where the expectation of resolution (the implied promise of HTTP links) is specifically undesirable.  Distinguishing between these cases, and building sustainable services that address these needs, motivated the development of the "info" URI standard.  Wrapping that standard with policies and value-added business models is the next, and more difficult, challenge.

More information about the "info" URI scheme and the registry of "info" namespaces can be found at http://info-uri.info.