τεχνοσοφια

This is a slightly modified (read: rough) transcription of the talk I gave at this year's NJLA conference, called "Library Revolution." Continue reading…

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.

I was stoked to see our Digital Initiatives Coordinator position posted earlier today. We have been without a full-time field officer for nearly eight months, though Kevin Clarke (lead programmer) has served with distinction — and with nary a complaint! (Well, okay, there may have been some complaints, but he always had a smile on his face.)

Here are some reasons you might consider this position:

• A chance to get in on the ground floor — our team is still undecided on many important issues, so you would have the opportunity to shape the organization.
• Work with a broad range of technologies, such as Java, Ruby, XQuery, XForms, native XML databases, Solr, and more.
• Assist in the ongoing effort to select repositories for various use cases — we're evaluating DSpace, several Fedora front-ends, and the X-Hive/DB native XML database
• Many rare and beautiful library collections.
• Great location — it hardly seems like New Jersey!
• Lead the digital collections team, currently consisting of four librarian programmers and five digitization gurus.
• Forge ties with one of the finest faculties in academia.
• Comprehensive benefits package — 24 days vacation, the whole insurance kit and kaboodle, and so on.
• Uncommon amount of support (financial and otherwise) for professional development.
• … and you get to work with me! But seriously, the great team we have assembled has been a big part of why I've thoroughly enjoyed my time at Princeton.

You can get a sense of the work we've been doing by browsing our Digital Collections, though that's only the tip of the iceberg, and the site will be overhauled in the coming months.

Have some digital initiatives experience? Ready for leadership responsibilities and an environment in which you will hone your vision? Then by all means, check it out. An MLS is not required.

First, I'm stoked to be getting copies of the following books over the course of the next few weeks:

• Information Architecture for the World Wide Web: Designing Large-Scale Web Sites
• Ambient Findability: What We Find Changes Who We Become
• A Semantic Web Primer (Cooperative Information Systems)
• RESTful Web Services

They reflect pretty clearly the sorts of things that have been on my mind of late.

Also, I saw a very interesting post on Peter Brantley's blog, Shimenawa, and I thought it was important enough to share verbatim:

There is considerable ferment these days in the library community about the shortcomings of the current generation of OPAC systems. A number of libraries are investigating replacement discovery systems divorced from their Integrated Library Systems (ILS), and a few have already implemented alternatives. Replacing an integrated OPAC with an external generalized discovery system raises some difficulties, however, as OPACs provide functions beyond simple bibliographic discovery. Among the areas of difficulty are:

* Handling/displaying complex non-bibliographic library data, such as detailed serial holdings;
* Providing access to highly volatile ILS transaction data, such as circulation status;
* Supporting ILS-specific patron functions, such as renewing charged-out books;
* Supporting institution-specific functions, such as requesting the delivery of books from a remote storage facility.

The inability to provide such popular functions will inhibit the freedom of libraries to use alternative (frequently more modern) discovery platforms for their catalogs.

From the standpoint of libraries it would be ideal to be able to mix-and-match ILS and discovery platforms to suit local needs. To create such a rich environment the library and vendor community will need agreement on the specific technical details of how discovery and ILS systems are to integrate.

DLF is planning to establish a Task Group to analyze the issues involved in integrating ILS and discovery systems, and to create a technical proposal for how such integration should be accomplished. We are now seeking nominations of knowledgeable people to serve on the Task Group. Candidates should have analytic skills, be familiar with ILS and discovery systems, and, ideally, have some experience in systems interoperation. We hope to create a group that has a balance of experience with a variety of specific ILS and discovery systems. We encourage both self-nomination and the nomination of people from the community you believe can contribute to this important effort.

Because we believe the need to regularize interoperation is immediate, we are hoping to name this Task Group within the next several weeks, and that its work can be completed by the end of the calendar year. We expect most of the work of the group to be carried out through telephone and electronic means, although one or two face-to-face meetings may be needed. I have also asked a few experienced people to serve as advisors for the Task Group, to offer help and advice if needed.

Note that although this call went out originally to DLF members, this effort will not be limited to DLFies.

Peter Binkley wrote a while back about the crop of neat digital librarian-y jobs that'd been popping up. There've been a bunch more lately:

• Head, Library Technology (Oregon State University)
• Coordinator for Digital Library and Metadata Services (University of Colorado)
• Digital Collections Coordinator (U. of Oregon)
• Digital Projects and Catalog Management Librarian (U. of Oregon)
• Digital Initiatives Coordinator (Clemson U.)
• Digital Library Initiatives Manager (Temple U.) [Direct link could not be obtained]
• Digital Library Program Manager (UC-San Diego)

It's great to see academic libraries diving head-first into digital collections / library initiatives, and doing so with dedicated staff.

Some of these positions look like great options for folks like myself who've been bouncing around the digital libraries world for a few years now and are starting to think about taking on greater responsibility within an organization. I know you're out there, folks. Consider applying!