I know precious little about rights management.  And what I do know I have gleaned from the occasional Slashdot post or Wired article.  Former colleague Grace Agnew, Associate University Librarian for Digital Library Systems at Rutgers University, has put the wraps on a book about digital rights management targeted at librarians, Digital Rights Management: A Librarian’s Guide to Technology and Practice (also available in paperback):

This book provides an overview of the current landscape in digital rights management (DRM), including: an overview of terminology and issues facing libraries, plus an overview of the technology (including standards and off-the-shelf products). It discusses the role and implications of DRM for existing library services, such as integrated library management systems, electronic reserves, commercial database licenses, digital asset management systems and digital library repositories. It also discusses the impact that DRM ‘trusted system’ technologies, already in use in complementary areas, such as course management systems and web-based digital media distribution, may have on libraries. It also discusses strategies for implementing DRM in libraries and archives for safeguarding intellectual property in the web environment.

If you’re a librarian or information professional looking for an introduction to DRM, an underpinning for rights management strategy, or a refresher on rights management technologies, you might consider checking it out.

For full disclosure, I was one of several reviewers of this book.

I’ve been using my time at RepoCamp today to get the OAI-ORE plugin for WordPress validating again.  I’m having some trouble using the validator so I say that with some diffidence.  But the latest code which is now checked in to the WordPress plugins svn repo ought to be close, if not fully conformant, to the 0.9 version of the ORE spec.

I’m not sure the plugin is really useful; it’s just an Atom feed of all posts and pages in a WP instance.  I can think of some ways to make this more useful, by allowing blog authors to create their own aggregations, pulling in content outside of the particular instance.  I am certain that others can come up with even better uses.  I’m open to suggestions.

Thanks to Jay Datema for prodding me a bit, if indirectly.

About a month ago, I read on my colleague’s blog that the Emory University Digital Library published a new book on sustaining digital libraries.  I’ve finally started reading it and figured I would post a note here.

The articles of this monograph provide resources for digital library stakeholders who seek to better understand how to effectively evolve such efforts from short-term projects to long-term sustainable programs. The monograph includes contributions from leaders in major digital libraries that have made such transitions or which are systematically considering the question of programmatic sustainability, including representatives from the National Digital Infrastructure and Information Preservation Program (NDIIPP) and the National Science Digital Library (NSDL).

I might also note that the book is available for free as a PDF.

So far I’ve read the introduction by the editors and the abstract from Leslie’s paper, and the book looks like a high-quality read from cover to cover, with articles based on actual digital library experience.  It’s a pragmatic approach for how to sustain digital library initiatives, looking beyond technical concerns towards the more challenging social and economic ones.  To some extent, we are getting pretty good at preserving bits and relationships between collections of bits — it is yet to be seen how good we will be at preserving the preservation systems themselves.

It’s hard to believe but I’ve been at the new job for six months already, a full half-year come the 29th. Some days it seems like I’ve been here forever; others like I’m still a rank newb. I haven’t written terribly much about what I’ve been up to (but I assure you I’ve been busy). Let me rectify that.

The Transfer Problem

Two of the projects I’ve been working on relate to a fairly general problem that we like to call “transfer,” which revolves around, well, transferring files to and fro. Sounds simple. Is simple. That is, until you start thinking about preservation and accounting for a highly heterogeneous network with idiosyncratic nodes, esoteric storage software, and differential firewall rules. And that’s where it gets interesting (and problematic). The transferring itself, or copying of files from one location to another which we call “transport,” is the easiest part. We like to use common tools in our environment. It makes life easy. And so good ol’ scp seems like an obvious choice to handle the job.

Since preservation is a core aspect of our “repository,” a term which I use loosely, we must build certain other functionalities into the transfer process: validation, verification, inventory, backup, ingest, and so forth. Every time a file is copied to a non-transient location, we verify the file against a (SHA1) checksum and record an event for auditing purposes.

Repository Workflows

Some steps in the transfer process are routine and best handled by machines. Thus we automate them with scripts and code. Others require human intervention. This introduces another key aspect of our repository needs: workflows. No two projects will have the same workflow and yet all will have some steps in common. We’re using JBoss’s jBPM library for workflow management and it is more than capable of handling our workflow needs. It allows us to model complex and varied flows in a robust and not ad hoc way; it does seem preferable to me to model our workflows via jBPM’s graphical editor (serialized to JPDL XML) rather than copying around blocks of code and otherwise modeling the workflow procedurally in business logic.

One of my coworkers (the author of this) designed a complete workflow system in jBPM last summer and I’ve taken on implementing, tweaking, and testing this system, which has required bootstrapping my sorry-arse Java skills and learning jBPM. Though I find it difficult to think in Java patterns and generally find it a burdensome environment, I’m quite impressed by jBPM. I’ve been working on various updates of and unit test coverage for the workflow system, which has been a crash course in a number of Java technologies and a perfect first task at LC, as it gets me into the guts of things. The Java stack we use for our workflow is highly abstracted and componentized, which is conveniently modular… but it’s also Java: fairly heavy and arguably not as agile as dynamic languages such as Python.

Two Great Tastes?

So recently we’ve begun to think about implementing some transfer and workflow components in Jython (Python written in Java). Why? The value of Jython is as follows:

1. Ease of deployment - Deploying jar files to existing JVMs in production environments (which we do not control) is a simple task, or at least simpler than some other options.
2. Interoperability - Our stack is primarily Java-based and so interoperating with existing Java components means not having to rewrite functionality in other languages. Jython allows Python to talk to Java and vice versa.
3. Familiarity - It’s Python, and we like Python. It’s the closest my team has to a lingua franca and so it increases the chances of sharing code, maintaining code, and so forth.

It does not come without its drawbacks:

1. Currency - The Jython project went moribund for a few years or so and the latest stable version is now 2.2.1. Compare that to the latest version of Python: 2.5.2. I don’t begrudge the Jython developers, though. I’m glad some folks picked the project up, dusted it off, and breathed new life into it. I am also glad that they’re skipping 2.3 and 2.4 releases and plowing right into a 2.5 release. Because of this currency issue, some Python libraries won’t work with the latest Jython and that means you’re stuck looking for outdated, potentially vulnerable Python libraries, or hooking into Java libraries for the same functionality (which inevitably means more lines of code). I’m no lines of code fetishist but it does militate against the goal of agility somewhat.One does have the option of living on the edge and trying out the 2.5 branch, but that seems out of step with an infrastructure that is supposed to preserve terabytes upon terabytes of our nation’s, and the world’s, intellectual property. It’s a responsibility I do not take lightly, as much as I’d like to be on the bleeding edge.
2. Interoperability difficulties - Talking to Java from Jython is a snap: just import java at the top of your script, and, assuming your classpath is copacetic, voila: you have access to Java libraries in your Python code! Talking to your Jython modules from Java code is, well, a little more complicated. Read on.

Despite the caveats it does seem a sane, reasonable, and potentially productive path to go down. Right? I am specifically looking to implement two workflow components in Jython: one for transport (wrapping Ant’s JSch library, which provides a slick scp API) and the other for automation of ZFS filesystem/volume creation on the staging server. Nothing arcane, nothing tricky, nothing fancy. So it must be easy! Right? …

Lessons Learned?

I’m beginning to wonder about the feasibility of using Jython to make bits of our Java stack more agile. Specifically, there are three ways to get at Jython code from Java:

1. Compile to bytecode/jar via the Jython compiler (jythonc) and reference your Jython objects and methods as though they were POJOs
2. Embed a Jython interpreter
3. Instantiate a (JSR-223) script engine

Option 1 is nice because you get object- and method-level interop. However, jythonc is unsupported and will disappear. This does not seem sustainable though I might be able to limp along a while. And there are signs of hope:

Though jythonc is going away, all of the capabilities it provides will be present in 2.5 in other forms. We’re adding functionality to expose Python classes as Java classes using decorators to replace the docstring class creation that jythonc provided, and we’re adding static compilation of proxy classes so regular jython can run in applets and other environments with restrictive classloaders. We’re definitely doing something about jythonc.

That doesn’t help much now, of course, but just because jythonc goes away does not mean my jars will stop working.

The suggested methods for option 2 [1, 2] seem to be more trouble than they’re worth. If the goal is more agile development for certain components, the reliance upon multiple, separate Java classes — an interface class and an object factory, in the examples listed — to get a ten-line Jython script working, this seems suboptimal, both inefficient and not straightforwardly maintainable; it seems, to me and my Java-dumb ways, rather baroque.

Option 3 [1, 2] is more appealing than option 2 as it does not rely upon these other classes specifically for Jython code. But the number of lines of Java code that must be wrapped around the Jython to get it working looks like overkill for the drop-dead simple scripts I’m writing — it might be easier, for instance, to just write the darn things in Java and be done with it. (Did I just say that?)

Conclusions

Options 2 and 3 are similar as both involve embedding Jython code, or referencing files with Jython code, and interpreting the code within Java. Generally, I worry that either option would obviate the benefit of agile Jython scripting because you wind up wrapping the code in so much Java. I offer two disclaimers to counter my objections:

1. Cleverer Java coders than myself could, I am almost certain, find ways to build abstractions (or abstractions of abstractions) to eliminate the “lines of code” and “many separate classes per Jython script” issues
2. The value of Jython in our Java environment increases proportionately with the complexity of the component — given the overhead, a short Java class seems easier and more straightforward to implement than a short embedded Jython script. On the other hand, there’s value in embedding a Jython script that’d be an order of magnitude simpler than its Java analog.

At least, that’s the state of my head right now re: getting Jython and Java to play nice. If I make any breakthroughs or give up entirely, I’ll post follow-ups.

I am but a Java philistine and a Jython neophyte, so I remain humbly open-minded. I would greatly appreciate comments, questions, corrections, smackdowns, sagacious advice, and so on.

This is very rough, but here’s a WordPress plugin that provides a resource map for the aggregation of all posts within an installation of WordPress. I’ll be working on this some more, but for now, it does appear to work and validate (as Atom). Useful? If so, I’ll zip it up and commit it to the wp-plugins svn.

Note:Ed reminds me that xsltproc can be used to transform the Atom-based resource map into RDF via GRDDL:

xsltproc http://www.openarchives.org/ore/atom-grddl.xsl http://lackoftalent.org/michael/blog/wp-content/plugins/oai-ore/rem.php

Update: The plugin has its own page.

Reading Adam Smith’s D-Lib article has got me thinking about identifiers again. I don’t agree with some of the assertions in the section titled “A Persistent Identifier Primer” — URIs are in fact persistent; we just break them through poor management — and so I’m led to a fundamental question: what are the good use cases for Handle (or ARK, or PURL) identifiers?

I get the need for persistent and globally unique identifiers; I’m just wondering why one needs special software with a separate URI namespace to gain persistence.

One potential use case might be resources that are outside of the organization’s control — i.e., licensed content from vendors — but surely folks are using Handles for many resources that are created and managed within the organization. And I’m curious why they have decided that Handles are more durable than native URIs (the URIs to which Handles redirect), and how they deal with the problem of downstream (post-redirection) citation and bookmarking. How useful is this sort of identifier scheme if your users never even see the supposedly more persistent URI for a resource?

As a former proponent of Handles and ARKs, this may seem like a hypocritical question to pose. If I had to answer my own question, I would say that Handles seem like a good option because they save you some work and headaches in the short-term; you don’t need to get together with your web team and come up with a scalable and sustainable URI policy; just assign native URIs in the usual haphazard way and generate Handles to compensate for a lack of identifier policies.

But if you’re already making an organizational commitment to identifier persistence — and if you’re rolling out Handles, I’d wager that’s likely — why not do so by minting carefully-considered cool URIs? Less management and technology overhead and less confusion for your users are two good reasons to consider it.

I seem to be having issues successfully submitting comments to certain WordPress blogs lately — or perhaps Akismet has finally decided to (rightly) classify my comments are spam? Anyone know of any Firefox / WordPress comment bugs? My comments seem to be submitted — there are no errors — and Firefox winds up on a link like “http://example.org/blog/foo-bar-whatever/#comment-12309″. Any ideas? At any rate, I’m left to comment via trackback for now.

Thanks for the nod, Winona. Hopefully you folks will get some good use out of the XQuery-based OAI-PMH data provider I’ve been working on.

I just want to clarify that only one small bit of the code is specific to X-Hive, and that’s a call to an extension that gets last-modified dates from the X-Hive service. We do not reliably store this information in the metadata itself, and so I needed to go this route. Some folks do store this in MODS or elsewhere in descriptive or administrative metadata. It should be a two-line change to short-circuit this behavior (xhive-exts:last-update() is only invoked in two places, I believe).

I’m currently working on adding EAD support, modularizing things a bit more, and streamlining configuration. resumptionTokens will come after that, I hope.

I’ll be interested to hear more of UVM’s implementation and how I can make this thing more useful to others.

At long last, the paper that Ron Jantz and I wrote for the Journal of Archival Organization has been published in a special double issue. It’s titled “Digital Archiving and Preservation: Technologies and Processes for a Trusted Repository” and is intended to be a fairly nitty-gritty piece on digital preservation (in the context of trusted repositories) for archivists. The abstract:

This article examines what is implied by the term “trusted” in the phrase “trusted digital repositories.” Digital repositories should be able to preserve electronic materials for periods at least comparable to existing preservation methods. Our collective lack of experience with preserving digital objects and consensus about the reliability of our technological infrastructure raises questions about how we should proceed with digital-based preservation practices, an emerging role for academic libraries and archival institutions. This article reviews issues relating to building a trusted digital repository, highlighting some of the issues raised and possible solutions proposed by the authors in their work of implementing and acculturating a digital repository at Rutgers University Libraries.

This special double-issue of JAO will also be released in the manuscript, “Archives and the Digital Library.”

Thanks to editors Bill Landis, Robin Chandler, Tom Frusciano, and Caryn Radick for seeing this through. And of course to Ron Jantz for getting me interested in this crazy stuff at a time when I had no direction or interest in my career.

This is a slightly modified (read: rough) transcription of the talk I gave at this year’s NJLA conference, called “Library Revolution.”

The abstract described an idealistic scenario:

Imagine, if you will, a world where library services are automatically discovered; Library users retrieve information objects and metadata with a single click, never having to navigate the dark alleys of dead-ends that are full-text resolvers; Information sources and services are connected and remixed according to user preferences and needs, where and when they wish. What if we could leverage existing library and industry standards, applications, and protocols to make this a reality? And soon?

In this scenario, a potential library revolution could be fomented — in which the goal would be to return the means of production to users, to hand over the reins, to re-envision ourselves as tool- and service-building artisans, as Karen G. Schneider described in her keynote at the Code4Lib 2007 conference, rather than gatekeepers and information proxies — and I’m going to suggest some ways this might be achieved. For now I’ll assume it’s self-evident why it is desirable to, generally speaking, get “our stuff” “out there” and meet users at their points of need.

Rather than get into nitty-gritty details, I’d like to describe a higher-level vision which has been put forward by a host of library technologists that have come before me (especially Daniel Chudnov). Some aspects of my vision may indeed be pie-in-the-sky, but consider this:

1. Isn’t pie delicious?
2. Shouldn’t we reach for it?

So, what’s the problem? Why a revolution? Here are some (arguably trite) observations:

1. Full-text resolvers do not work well. You should not have to click through two, three, or four windows to get at full-text — assuming it’s actually there and not a complete dead end! Don’t get me wrong — it’s better to have access to full-text through a resolver than not to. I’d like to see more resolver systems that implement look-ahead resolution like Oregon State University’s new, and freely available, metasearch tool, LibraryFind. LF uses what Jeremy Frumkin, the Chair of Innovative Library Services at OSU, likes to call “two-click workflow”: one click to find, one click to get.
2. Information splatter. We’ve accumulated too many silos and need to figure out better ways to access all of that information via a single interface, whether the method is federation, aggregation, or something else. Users should not have to go to multiple sites to search our collections for resources of interest.
3. Sandboxing. Our content and services are, generally speaking, tightly coupled to our websites, so we are generally unable to meet users at their points of need.
4. Service usage — reference desk visits, OPAC searches — appears to be dwindling.
5. Growing popularity of Google, Amazon, and “web 2.0″ or social networking sites — del.icio.us, flickr, twitter, myspace, facebook, ning, librarything. These sites are great — especially MySpace, where I get all sorts of offers for new prescription drugs and live adult webcams. But these sites really -are- great. They empower users to connect with one another, to describe their own resources, to share with others, to remix information. And most of all? They’re incredibly easy to use. Are our tools as easy to use? Are we similarly empowering users?

An aside on “2.0″: Although I cringe at the viral “2.0″ meme — web 2.0, library 2.0, business 2.0, identity 2.0, enterprise 2.0, learning 2.0, travel 2.0… — it is interesting to note that there is something to “2.0″. Something revolutionary. And it’s not folksonomies, it’s not tagging, it’s not tag clouds, it’s not sharing, it’s not any particular site or idea. It is the very fabric of “2.0″, and that is a re-envisioning of the web from connecting people with data to connecting people with people. The web has evolved from a network of interlinked documents to an extension of the social fabric connecting us all.

As you can see, a revolution of sorts has already begun. Time magazine selected “You” as their 2006 person of the year. When MSNBC covered the story, the headline read “From blogs to YouTube, user-generated content transforms the Internet”. I’m personally not that interested in the social networking aspect, and it already receives a lot of coverage from the library 2.0 gang. Library 2.0 is a popular topic now, and much has been said of wikis, blogs, and RSS. These are important topics but others are already covering them quite well. The point to take away from 2.0, in my view, is that it’s empowering and inspiring users to do things with information they previously were not able or willing to do. Ask tens of millions of people to help us catalog MARC records? Right. But ask them to tag videos on YouTube, bands on Last.FM, images on Flickr, links on del.icio.us, and so forth? There you go. My areas of interest with regard to library revolution are unifying our content and services, getting them outside the library sandbox, and returning the means of production in this very “2.0″ way.

Let’s step through some technologies and technological concepts that may play a role in reaching this outcome.

• Systems integration: We have accumulated a wealth of resources over the years and have purchased, or built, or licensed, numerous systems to access these resources that have traditionally been disparate. This is a great accomplishment; the more information we can get into the hands of our users, the better. The process doesn’t scale, though, and has resulted in a proliferation of information silos. Because of thorny issues of interoperability, not to mention licensing issues, technological incompatibilities, and lack of resources, we have thus far struggled to bridge the gaps between these silos. The result? A number of different search interfaces, with different result sets, in different formats, supporting different depths of coverage.
   
   How can we reconcile in our users’ minds this information environment with the “simple, single search box” mentality of the Google age? What if we built bridges between our systems? Pull together metasearch with the link resolver, the link resolver with the catalog, the catalog with institutional repositories. Easy, right? Well, no. But at the very least, if you can get XML out of these systems — whether through OAI-PMH, or SRU, or a database export — you can bring it together. Index it with a tool like Solr, and you’ve got your Google-ish library search tool.
• Auto-discovery: Auto-discovery is used by a number of technologies, though perhaps its usage to announce syndication (RSS) feeds is the most well-known. The mechanism for syndication auto-discovery is actually quite simple. Got a feed for your site? Add a single line of HTML code to any page you’d like to announce it on, and modern web browsers will pick it up and clue you in.
   
   In HTML, there is a LINK tag, not to be confused with the A tag (which stands for anchor) commonly used for hyperlinks. The anchor and link tags differ in the following ways:
  • Anchor tags may have text content and show up as labels for links. For instance, you might link to FoxNews.com and label it “Fair and balanced? Yeah right.” LINK tags do not have text content.
  • Actionability: Anchor tags are clickable. They take you someplace. LINK tags are not clickable.
  • Context: Anchor tags appear in the body of a document. LINK tags appear in the HEAD.
  • Semantics: Anchor tags may represent any number of things. It might be a link to content further down in the current page, it might link to another page entirely, or it might even be used to activate some javascript or launch a popup window. LINK tags are used solely to describe document relationships, more semantic information. For instance, a LINK tag might describe a link to the next and previous chapters in an e-book, a LINK tag might be used to link to alternative representations of a document, such as versions in other languages, or versions formatted in RSS or the Atom syndication format. The LINK tag is a great way to leverage the existing web architecture to handle the problem of “one resource, many representations”, and I wouldn’t be surprised if the OAI-Object Reuse and Exchange initiative took a hard look at it.

  The LINK tag sort of auto-discovery, such as for syndication feeds, is common, but is not the only implementation of auto-discovery. There are more sophisticated ways, such as Zero Configuration Networking.

• Syndication: You’ve probably heard a lot about RSS, or Really Simple Syndication, and I wouldn’t be surprised if most of you are already using it. It’s a great technology, simple to use and implement, and I know it saves me a great deal of time on a daily basis. Instead of having to click through and browse the 50 or so websites I track regularly, I read updated content from each site in my feed aggregator in a unified interface. A lot of attention is already paid to RSS, especially in library 2.0 circles, so I won’t say much more about it. Syndication allows content to be syndicated into feeds that folks can subscribe to and unsubscribe from willy-nilly.
   
   But I thought it was important to include an explicit mention of syndication since a couple of the other topics relate to it, and since it is a great example of getting stuff out there. Rather than requiring your audience to come to your website, syndication enables them to read your content in an environment of their choosing. It’s worth noting that my wife is not a fan of syndication. She likes the experience of going to different websites, enjoying their different takes on web design, and compartmentalizing her web surfing. And that’s great; no one, to the best of my knowledge, has advocated an “RSS-only” interface. Content available in the RSS format is also available otherwise, so it is a convenient option for people like myself.
   
   One more point about RSS, despite saying I wouldn’t talk much about it. It’s kind of an academic point, but I feel it warrants some clarification. The term RSS has quickly become the Band-Aid, or the Kleenex, of syndication feeds. RSS is one of a number of formats used for marking up syndication feeds. Another is the Atom Syndication Format. Most browser and feed aggregators are fully aware of both feed types — for instance, Bloglines has supported both formats since June of 2006 — and they generally should render the same, and that’s why you don’t hear about Atom much; it’s a detail that is, for the most part, behind the scenes.
• OpenSearch: Does anyone here have a website or a catalog? Do they have search interfaces? Perfect, you’re about a third of the way there. OpenSearch is a specification for some simple formats that allow you to share search results. Just as syndication allows you to decouple your content from your website, OpenSearch allows you to decouple your search engines from your websites. Here’s how it works:
  1. Go to your search page and look at the URL after you run a search
  2. Write an OpenSearch description document
  3. Embed a LINK tag linking to the OpenSearch description document, for auto-discovery
  4. Return search results in RSS or Atom

  You might ask “why bother?” Firstly, the newest browsers — FF2 and IE7, among others — support auto-discovery of OpenSearch targets. So folks can search Google, Wikipedia, Amazon, eBay … and your websites or catalogs directly from their browser. Secondly, it allows for fairly simple federation of searches across OpenSearch targets. Since each target contains a description document that is machine-readable, I can point my OpenSearch client at a number of targets, find their descriptions, and learn how to search them. Results are, by convention, returned in RSS or Atom, which are easily crosswalkable, so aggregating result sets is fairly trivial (though how to sort or rank them is tricky). Thirdly, since results are returned as RSS or Atom, one can in effect subscribe to search results. For example, you could subscribe to a search on Wikipedia for “Anarcho-Syndicalism”, and your feed aggregator will be alerted whenever that search returns new results. Or, a Linguistics professor could subscribe to your catalog’s OpenSearch target, hoping to be alerted when new materials about Germanic syntax are cataloged — and it’s worth noting, this is as easy as just two or three clicks in a web browser.

• unAPI: Numerous tools and protocols exist for integrating library resources into other information systems, library or otherwise. OAI-PMH and OpenURL are two great examples of successful and widely deployed technologies. Unfortunately, few developers outside the relatively small world of library technology know anything about library standards, and this is seen as a significant integration barrier. Dan Chudnov, a librarian programmer at LC, reflected on this: ‘we librarians and those of us librarians who write standards tend, in writing our standards, to “make complex things possible, and make simple things complex.”‘
   
   To address this issue, a number of librarians and technologists came together to develop a new standard called unAPI. unAPI is a tiny web-based specification designed to solve the problem of identifying, copying, and pasting discrete content objects to and from web applications (including catalogs, bibliographic databases, repositories, link resolvers, and so forth), making it simpler for developers outside the library world to get at our vast intellectual resources. The objective of unAPI, then, is to enable web sites with HTML interfaces to information-rich objects to simultaneously publish richly structured metadata for those objects, or those objects themselves, in a predictable and consistent way for machine processing.
   
   unAPI consists of three parts: A microformat for embedding object identifiers in HTML, an HTML LINK tag for unAPI service auto-discovery (as used for RSS, Atom, and OpenSearch), and a web service consisting of three functions–get formats , get formats for x identifier , get format y of identifier x — two of which have a standardized response format, returning XML.
• ZeroConf: I want to acknowledge Dan Chudnov again, for suggesting that Zero Configuration Networking might have a place in library services. The general question here is “why can’t library tools be as cool as iTunes is?” Just waltz into Starbucks, connect to the wi-fi, and you can see everyone else’s playlist. You can listen to their music, even. What sort of magic made this sort of auto-discovery “just work?”
   
   The technology is called Zero Configuration Networking, or ZeroConf, though you may see older mentions under the names Rendezvous and Bonjour. Without getting into the hairy details, ZeroConf is a small stack of fairly low-level technologies that piggy-back on the ubiquitous domain name system (or DNS), which enables us to type identifiers like “google.com” and “nytimes.com” into a web browser and rest assured that our computers will take care of the rest for us — looking up the domain name, finding the network address of the server, connecting to the server on an appropriate port, and so forth. ZeroConf allows machines to connect to networks without any knowledge of what’s already on the network, without regard for the type of network topology or infrastructure, and both register the services it provides and query the services already provided by other nodes on the network. It sounds complicated, but everytime you walk into Starbucks and start up iTunes, it seems pretty trivial. It “just works.”
   
   Wouldn’t it be great if users could discover our services and resources that easily? What if we went through with systems integration and announced that unified service via ZeroConf? A visiting scholar could enter our library, connect her machine to the network — and let’s forget about authentication and authorization for now — and immediately find our new service, from which she could run a simple search against all of our bibliographic databases, all of our catalog records, all of our full-text holdings, and all of our repository objects. What if library services “just worked”?Significant work needs to be done in this area before it becomes viable as I’ve just described, but I find it to be a compelling vision.

The technology as is widely acknowledged is the easy part. So how do we get there? How do we re-envision ourselves as library artisans? How do we craft services that “just work?” How can we investigate all these technologies that let us unleash our considerable assets?

1. Commitment to innovation. If you can afford to have skunkworks in your organization, even if it’s only one employee, or allowing a couple of creative individuals to devote 10% of their time to innovative pursuits, it’s worth it.
2. Bold direction.
3. Think outside the orgchart — leverage collaborative development, forge communities, make the most of your consortial ties.
4. … You tell me.

We can yield revolutionary results via small steps and a bold, forward-thinking direction. Pie in the sky? Maybe, but isn’t pie delicious? (Yes, that was a glib and abrupt ending, but I’m tired of editing.)

A friend and former colleague asked if I would comment on a chapter in her upcoming book on digital rights management and I agreed. The chapter is about identification and authenticity of web resources. Throughout my review of the chapter, I kept coming back to a couple of very basic notions that underlie any effort to provide persistent identifiers for web resources. These notions are, to my mind, central to identifier persistence, and any other concerns rely upon this foundation:

1. Identifier persistence requires an organizational commitment. Persistence cannot be ensured by a few renegades in the skunk-works, nor can it be mandated from on high without the support of those who manage the identifiers or produce web resources. All individuals involved in the life-cycle of web resources must be committed to persistence in perpetuity if true persistence of identifiers is to be achieved.
2. No technology, no standard, no identifier scheme, no information architecture will get you persistence. Whether you choose native URIs, Handles, DOIs, PURLs, ARKs, UUIDs, or XRIs, you will never achieve identifier persistence without active management of your identifiers and web resources. This requires the aforementioned organizational commitment since such management cannot occur without sufficient resources. Management of web resources and identifiers requires time and due diligence and those don’t come for free.

And, at the risk of being reductive, that’s about it. Once you’ve got an organizational commitment and a person or team to manage your identifiers and web resources, the rest of the decisions are secondary. If you like semantically meaningful URLs that redirect, choose Handles; if you prefer opaque identifiers, go with ARKs; if you don’t want to run your own software, consider PURLs. At that point, it really doesn’t matter which scheme you choose, as long as its characteristics match your organization’s values. You’ve already done the heavy lifting; rest easy.