Weibel Lines

Failure Points and Manifestations

Ed Summers made several points worth amplifying in his comment to my previous post.

I do think there's enough space here for multiple players including the
Library of Congress. Indeed one could argue that designing a
bibliographic identification system with one central point of failure
is a bad idea.

The single point of failure argument is a serious issue, but not insurmountable.  We don't worry much about the Amazoogles being accessible through a single URL.  Partly this is because we know we can use other search engines, but perhaps more importantly, the economic stakes for reliability, combined with their technical wherewithal, mitigate against service failures.  It is fair to challenge whether OCLC can provide a similar level of service.  Perhaps the better question is what is an acceptable interval of service denial, and an acceptable mean time between failure?

The other part of this question is whether there is harm in multiple authoritative links?  I argue that there is harm, and in fact that this harm is partly the reason why library materials often fail to show up in the first few links on a given search.   I've written about this in a previous post, and I think it is critical that the community agree on a canonical URL for a given piece of library content.  To do otherwise... to promulgate many identifiers for a given resource, is to dilute the link currency of that resource, and render the resource less findable and less actionable:

• Machine comparisons of identifiers will fail to recognize two referents as the same resource
• Diluted identity leaves resources lower in linking algorithms and hence less findable on the open web
• Aggregation of given identifiers in social software systems will be similarly diluted

It is naive to imagine that we can obliterate all but a given canonical URL from use, or even that we should. It is useful to be able to, for example, hack a WorldCat identifier together from an ISBN in hand.  Still, when citing (on paper or on the Web) a given identifier, it should be the canonical URL, not a transactional URL or even an ISBN URL.  OCLC can go a long way towards promoting this goal by making the canonical URL -- the permalink -- a prominent part of the record in the user interface, as well as to redirect all other comparable URLs to that canonical URL so that it appears in the browser address window.

Ed goes on to say:

OCLC's vast holdings database is certainly important for resolving an identifier to the actual item. But for practical purposes of citation (identification) it's rarely necessary to talk about the item itself...normally referencing the manifestation will do fine.

I agree with this point entirely... in fact, the canonical WorldCat URL is the OCLC record number, which for practical purposes, rounds to a manifestation identifier.  It is the holding data, not the manifestation identifier, that gets you that last mile.

-----

What I believe to be Frigate birds, taken on the beach at Manzanillo, Mexico, at DC 2006

Libraries and the Soul of the Web

Tim Spalding, perhaps the most innovative of Internet library entrepreneurs, made a number of interesting points in the LibraryThing blog, Thingology, recently.  However one may feel about the details of his argument, he is partially correct that:

the failure of the LC and other libraries to get their data "out there" on the open web has hurt them... It has made them seem irrelevant, standing silent and apart from the great conversation....

I believe Tim's charge that we're responsible for our own irrelevance is true, at least in part. He is way too hard on LC, though, dumping the sins of the community all in one place. And it isn't as though nobody on the Web knows about anything going on in libraries.  But still... as a community we have been slow to get the data out there.  There are lots of reasons for this, having to do with business models, capitalization, culture, public mission, and more.  It is far too complicated to unpack in a blog post.

What Tim has achieved almost singlehandedly is to demonstrate both the power and appeal of remixing bibliographic data and people in system that is engaging, accessible, and useful.  If you're a librarian and haven't explored LibraryThing, then do so, and you'll get a glimpse of what Web 2.0 means for our community, and more importantly, to our patrons.  Keep in mind that this system became, by some measure, the 100th largest library in the US on less than a single person-year of development effort (and an enormous amount of Web 2.0 patron-contributed effort). I hope my admiration is evident. 

Tim goes on in this same post to say:

The first culprits are the online catalogs, ugly, backward things lamed with session-based URLs. If you want to link to the LC, you can't. The URL you get will only work for you, for ten minutes. Linking--the very soul of the Web--is impossible.

It may be that it is impossible to link to LC's catalog, but it just isn't an issue.  It is not the place anyone should link to.  Web blaspheme?  No.  LC is not (for most of the Web's clientèle), a lending library.  It is the source of most (and arguably the best) of the cataloging that libraries depend on.  Why not link to these records?  Several reasons, foremost of which is that while such links are suitable as citation links, they are not connected to the content itself -- that last mile problem again -- and arguably the problem at the center of the "very soul of the Web".

So, are libraries thus marooned forever in Real Life?  No.  If you want to link to library materials there is exactly one best way to do it: WorldCat.org.  By using a WorldCat identifier, you provide a persistent identifier that links not only to an authoritative citation record, but to the items themselves.  The Worldcat database is supported by the holdings data of the OCLC Cooperative, thus allowing patrons to find the library closest to them that holds the item.  There are also links to electronic content, directly accessible, even though it isn't 'held' by a library: an example. There are even links to buy items if one would prefer to own rather than borrow (and libraries get a cut!).  Check it out... buy a couple of my wife's books just to prove that it works.

If it sounds like I'm flogging my employer's product (and Marguerite's books!), I suppose I am.  But the fact of the matter is that when WorldCat.org came online last summer, the world's library content became web-addressable for the first time in a soul-of-the-Web way with persistent, globally-scoped identifiers that will work anywhere in the world that members of the collective provide services.  Even if OCLC went belly-up next year, can anyone seriously imagine that the community could afford to not sustain the WorldCat database?

Now, if only we could get the WorldCat team to stamp that permalink prominently at the top of every record.  Stay tuned.
-----
Disclaimer: The opinions in this, and all of my posts, are mine.  The are not reviewed by anyone at OCLC prior to publication.  I'm trying my best to make them the opinions of my employer.
-----
image: Winter lights in my front yard, when I was still enjoying the snow.

Steal this blog post... please... but with attribution

Thanks to Dorothea Salo for noting that blog designs may be subject to copyright and hence impedimential to the harvesting and preserving of blogs.  In my initial scan of her comment I thought she was invoking copyright issues having to do with the content itself, but on reading more carefully, the issue she raises surprised me.  I confess It never occurred to me that TypePad might lay such a claim... duh! How ironic if these templates themselves stood in the way of proper archiving.

Simon Spero's followup comment would, I should think, answer this problem, though I've never cared much for reformating of content.   As things stand now, many blogs are syndicated into so-called Planet Blogs, aggregations of the feeds of various blogs on a given topic or area, and reformatted in just this way.   This entry, for example, appears in the Planet Code4Lib aggregator.  Irony once again rearing its winsome head, I learned this by accident  through perusing my referrer stats some time ago.  No one ever asked if I wanted my content aggregated in this way (I do, I do!), and it does make it more difficult to know who is reading (readers leave evidence in my stats only if they click on the entry in Planet Code4Lib and actually get to my site itself... probably not the most likely thing).   

Putting aside this anomaly, the content copyright issue is important, as otherwise only blogs whose authors will have specifically requested archival service would be captured unencumbered.  A huge part of the blogosphere will remain in an ambiguous state -- without explicit permission having been granted for preservation and redistribution. 

-----

If you look carefully at this image you will see a yoda-like visage in the left part of this picture of a recent attempt to ward off the Ohio midwinter blues.  Or maybe Elmer Fudd.  We ain't talking the blessed virgin here, but hey... a vision is a vision.

Library standards in the mainstream

Jon Udell's weekly podcast from February 16 features Dan Chudnov in a lengthy conversation about OpenURLs, COINS, xISBNs, FRBR, digital archiving, and other library geekery.  This is a long, but rewarding conversation that surfaces many issues of technical librarianship into one of the technical world's A-list blogs.  If you've been putting off raising your understanding of OpenURLs and related technolgies, this podcast will help contextualize contextual linking, and give you a roadmap for exploring a host of related technologies.

One of Udell's pet peeves is the difficulty of assuring the archival preservation of blogs, a medium that he, more than most, has invested in as a serious record of thought.  Conventional thinking has it that blogs are ephemeral, and who really cares if they are preserved?  I'm with Udell -- Blogs will become (are?) an important cultural and historical record -- even if they are ephemeral.  Remember the days when libraries were wringing their collective hands about preserving slow-burning acid-paper collections?  It was the so-called ephemera of earlier eras that caused the greatest concern, as these were precisely the materials that would disappear most quickly, and leave holes in the cultural record of their time.  So, today -- blogs.

Udell and Chudnov pod-pine for a business model for the preservation of blogs today.  Why not an inexpensive LOCKSS-like blog preservation service run by... who else... libraries?  Perhaps in Dan's new role in the Library of Congress he will be able to promote such a service.

-----

The canopy over the main platform of the Berlin Haupt Bahnhoff reprises the open elegance of major 2oth century European train stations in a modern facility in the heart of the city.

Metadata, Images, and Microformats

Jon Udell, who I know 
to be an avid 
photographer 
(well… he’s pretty much 
avid about everything he 
deals with, which is one 
of the main reasons  
we read him) suggests 
in a recent post 
a new addition to his
list of attributable truthisms:

Scott Dart, program manager for the Vista Photo Gallery: “The truth is in the file.”

The post references Microsoft’s new photo gallery facility in Vista, and the main point is an important one: the (metadata) truth needs to be in the file. The further away it gets from the file, the more likely it is to be lost or corrupted through bit-rot, incompatible applications, dispersion of related files… what have you. Having recently lost a good deal of work I had done within Adobe’s Lightroom beta, I salute this truthism enthusiastically.

Jon goes on to say:

And when I look at this it strikes me that here, finally, is a microformat that has a shot at reaching critical mass.

Before deconstructing this optimism, it might be useful to invoke the microformats home page to remind 
ourselves what a microformat is supposed to be:

Designed for humans first and machines second, microformats are a set of simple, 
open data formats built upon existing and widely adopted standards.

Jon invokes the following embedded fragment from a Vista-truthy file:

<xmp:xmpmeta xmlns:xmp="adobe:ns:meta/">

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b"

 xmlns:dc="http://purl.org/dc/elements/1.1/">

<dc:subject>

<rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

 <rdf:li>horse</rdf:li></rdf:Bag>

</dc:subject>

</rdf:Description>

<rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b"

 xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">

 <MicrosoftPhoto:LastKeywordXMP>

 <rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

 <rdf:li>flower</rdf:li>

 </rdf:Bag>

 </MicrosoftPhoto:LastKeywordXMP>

</rdf:Description>

<rdf:Description xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">

 <MicrosoftPhoto:Rating>1</MicrosoftPhoto:Rating>

 </rdf:Description>

<rdf:Description xmlns:xmp="http://ns.adobe.com/xap/1.0/">

 <xmp:Rating>1</xmp:Rating>

</rdf:Description>

</rdf:RDF>

</xmp:xmpmeta>

This is a lot of code to unpack in order to conclude that the photo is a flower.  Especially for a human. 
But Microsoft deserves kudos for adopting standards established by others 
(W3C, DCMI, Adobe), though it adds some of its own (non-interoperable) terms as well.

Examining the namespace declarations is interesting. In order of appearance:

• http://www.w3.org/1999/02/22-rdf-syntax-ns# Resolves to the RDF schema declaration of RDF
• http://purl.org/dc/elements/1.1/   Resolves to an RDF schema declaration of Dublin Core metadata
• http://ns.microsoft.com/photo/1.0 Does not resolve: server not found
• http://ns.adobe.com/xap/1.0/ Does not resolve: page not found

So, while I agree with the design philosophy that Jon commends in the Vista application, and Microsoft deserves kudos for adopting and declaring existing standards, this particular fragment leads to several  unsettling concerns:

• The code fragment isn’t really all that simple. In fairness, the overhead looks a lot more reasonable in the case of a richer set of descriptors, and image metadata is rich. Still, it’s a bit of a stretch to rule this within scope of a microformat. Not to say it is unuseful, but simple and human readable?  Probably too much to expect from metadata.
• While the code does indeed refer to existing open standards, some of their declarations are not Web accessible and it is not evident at a distance whether they were intended to be or not. This is one of the arguments for separating identifiers from resolution addresses.  When I see a URL, I expect it to point to a web-accessible location.  If it doesn't, it seems a fair conclusion that something is broken.  Note that elsewhere in this fragment there are identifiers that do not promise resolution, and hence do not disappoint expectations:
  • xmlns:xmp="adobe:ns:meta/"
  • uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b
• There are a lot of dependencies here, requiring confidence that a somewhat complicated and fragile technical scaffolding is going to be maintained equally well by all parties. One may argue that these namespace declarations are simply identifiers, and needn’t be resolved by most applications, but this assumption leads to unfortunate and unnecessary uncertainties.  This is certainly not a Vista flaw... it is a consideration in all our distributed applications. 
• Finally, I am skeptical that we really want multiple sources of potentially redundant metadata written into our image files. For example,
  • MicrosoftPhoto:Rating>1</MicrosoftPhoto:Rating

presumably stands for a user-assigned quality rating… stars, probably.  Again, good that it is in the file (this is the sort of data I lost in my unhappy experience with the Lightroom beta). But is iPhoto going to interpret Microsoft’s ratings, and vice versa? I doubt it.  Back to the standards room, folks?

As a photographer of some avidity myself, I would be thrilled to imagine that image metadata might be the domain of the first microformat killer ap.  As someone who lives in two OS domains, and expects to for the foreseeable future, I have a particularly strong desire to see this stuff work in a cross-platform way.  I think we’re still a long way away.

-----

Image: Ceiling detail in the ruins of Kaiser Wilhelm Church in Berlin, which stands as a memorial of remembrance of WWII in the center of the city.

Search and Rescue 2.0

If you've been following the unhappy drama of the disappearance of Jim Gray last week from a fair sea near San Francisco, hope for his return diminished each day, but not the outpouring of effort dedicated to finding him, even after the Coast Guard terminated their own intensive efforts last friday.  The stories one reads about his influence make clear that this exceptional person was both greatly admired and loved.  Brier Dudley's remembrance in the Seattle Times is exemplary of the many measures of his loss.

The widespread affection and respect that Jim attracted in our community helped mobilize an unprecedented ad hoc, high-tech volunteer effort on the part of some of the biggest companies and brightest minds in the information industry, including a blog that serves as a clearinghouse for ideas and information that might be useful in solving this perplexing mystery. Perhaps these efforts may seed ideas about how to bring Web 2.0 technology to bear on future search and rescue efforts.