Lettertray

A contributor on Code4Lib recently posted a request for folks to fill out his survey about the future of libraries.  Without directly addressing the question about how libraries approach technologies going forward, Code4Lib-ers started an interesting,  somewhat barbed discussion about MLS/MLIS degrees being required for library technologist positions.  I realized after hitting the send button that my comments sounded a little like a dig at librarians.  I didn’t intend it that way.  I think that librarians have tough jobs and a lot of competeing demands, and the generally poor quality of many MLS programs don’t prepare students for the issues that they can and should be tackling in their libraries.

My initial email:

The discussion of the value MLIS/MLS is interesting, and familiar. It is a discussion that always seems to go in one direction: namely, why do library technologists need MLS degrees? There are some pretty compelling arguments that they don’t, but I’m curious what that means for librarians going forward.

I went to library school during what I consider to be the Great Delusion of the Late Nineties. There was a palpable sense among MLS students and librarians that we were about to find our groove in the proto-Google web world. My intro MLS courses were chock full of readings about librarians being hired away by Fortune 500 companies to help them make sense of Information, and about these mystical skills that librarians possessed that allowed us some insight into Information that others could not possess without an MLS.

What happened, of course, was that things changed quicker than MLS programs could adapt, and whether we liked it or not, our culture had moved beyond the need for librarians as gatekeepers. In the meantime, these amazing things are happening with open repositories, web services, and resource-oriented systems - things that should be front-and-center for emerging librarians, but often are skimmed because of the technical knowledge required. The result is that a lot of smaller academic libraries need to choose between enacting a really ambitious and forward-looking technology strategy, and protecting their MLS faculty lines. It seems like a doomed strategy in the long-run, but for a library director, I don’t think there is an easy answer. So a lot of places try to have it both ways and fish for skilled technologists with MLS degrees.

In my case, I went the other direction, currently working in a non-Library (but closely affiliated) technology group that is under the IT umbrella, despite having an MLS. So go figure…

I’m finally getting a chance to comment on last week’s DLF Fall Forum.  Since I’m not technically a librarian any more, I probably wouldn’t have gone.  But seeing as it was in Providence, it was a great excuse.

The most compelling new thing that I saw there was the Djatoka (not Djakota, as Birkin Diana pointed out) JPEG 2000 Image server.  Since I’m not really an image person, my simplistic impression of JPEG 2000 is that it is full of potential as a high-quality and scalable image format, but that it has lacked accessible and affordable software support.  The folks at Los Alamos have now released Djatoka, which seems to be … pardon me here … a game changer.

In practice, Djatoka shares some features with Google Maps - images can be delivered as AJAXy tilesets, which can be dynamically loaded in the browser as requested by the user.  But the really cool feature is URI addressibility of any region of an image.  So, you want to study Mona Lisa’s nosehairs? Here is a URL.  Not only that, but the API lets you pass a URI for any image, which the Djatoka server compresses on-the-fly, and then delivers in JPEG2000 format.

One of the controversial (in a nerdy way) features of Djatoka is its heavy use of OpenURL to reference & deliver parts of the image.  There has been some discussion on Code4Lib about whether there is a better way to do it.  I’d say there probably are better ways, but OpenURL is a way to get the server out there quickly and get people using it quickly.  Pretty much any transfer format would get somebody’s hackles up, so you might as well build some momentum early by using a nearly-universal format (nearly universal for academic institutions that is, the rest of you are on your own).  And hey, it is open source, so if you don’t like OpenURL, hack away.

This past week, a bunch of smart folks came out with a preliminary specification for integrating diverse scholarly digital objects across repositories. Check out the announcement here.

The Object Reuse and Exchange (ORE) spec is, in my opinion, an enormous development. Scholarly technologists, librarians, and researchers have been circling around this idea of a truly semantic, services-based environment for a long time. It is great to see an architectural model that people can begin to discuss, rather than seeing more ad hoc development and tepid experiments by technology vendors.

The ORE working group describes their results like this:

“ORE will develop specifications that allow distributed repositories to exchange information about their constituent digital objects. These specifications will include approaches for representing digital objects and repository services that facilitate access and ingest of these representations. The specifications will enable a new generation of cross-repository services that leverage the intrinsic value of digital objects beyond the borders of hosting repositories. “

The also recommend an Atom-based model for packaging and delivering these representations of digital objects via syndication:

“These specifications describe a data model to identify and describe aggregations of web resources, and the encoding of the data model in the XML-based Atom syndication format. ”

Incidentally, my forthcoming article, “Syndicating Rich Bibliographic Metadata Using MODS and RSS”, Journal of Web Librarianship, Vol. 2 Issue 1, 2008, explores some very similar ideas, but as a proof-of-concept exercise applied to objects in library collections. Either way, it is really exciting to see the same vein of investigation happening at a much more prominent level.

It is pretty clear to most everyone that the old model of digital repositories - silos of data waiting for serendipitous discovery - is played out. Dan Cohen says it much more eloquently than I can, but suffice it to say that technology is just beginning to allow digital scholarship to more closely model the actual process of scholarship, in all of its complexity, nuance, and imprecision. It is pretty awesome.

Dealing with ILS (Integrated Library Systems) is probably the most drab and tedious part of my job, and, unfortunately fairly integral (ha ha). I find discussions about ILS issues to be generally uninteresting, hence a lengthy blog post about them.

Marshall Breeding, of http://www.librarytechnology.org, just posted the results of a survey he conducted about the level of satisfaction among ILS customers in regard to their respective systems. The report is available at http://www.librarytechnology.org/perceptions2007.pl. The most sad/interesting thing from my perspective is that Voyager, which is the system I work with, is waaaaaaaay down at the bottom of the list - as is its sister product, ALEPH. It’s no surprise to me - Voyager is poorly designed, poorly supported, and generally crappy product. What is interesting too is that the most enthusiastic supporters of open-source ILS projects are those from libraries running these crappy systems.

Part of the problem, in my humble, is that librarians still have a very consumerist attitude when it comes to their technology. The catalog and the technologies that support it, are products that you buy and then you make an effort to live with them. Ten years later, you repeat the process. In my mind, this mentality is akin to our culture’s adherence to the gas-combustion engine and coal-derived electric prower for most of our infrastructure needs. In the days of nanotechnology, ultra-efficient electronics, and ubiquitous computing, it is absurd that we cling to century-old technologies for our most fundamental needs. But we do. It’s also absurd that libraries - institutions that should be much more agile - still cling to this notion that their core technologies should take the form of large, unwieldy, local databases provided at enormous expense by private companies who really have no financial interest in improving their ILS products for more than half of their life-cycle. Once a product is 5 years old, the number of new customers dwindles and cash flow becomes scarce until the next generation comes out 5 years later. I would be very nice if libraries, collectively, put an end to this industry for good, and embraced systems that could be developed continuously, for the common good.

I’m a bit of a hypocrite, because I don’t know if I’d be able to sell that idea to our administration when the time comes to ditch Voyager, but it’s something to shoot for I guess…

Continuing the theme of divergent vocabularies in libraries, I was in a meeting last week with some other library folks from all over the spectrum, and we were brainstorming what we’d like to see in a next-generation library system. It was one of these management-nouveau exercises in which we put our ideas on little scraps of paper and pasted them to the wall. Occasionally there would be some discussion to clarify a point or develop the conversation a little further.

Somebody wrote “Good Metadata” on a piece of paper and it sparked a bit of a discussion. I don’t remember exactly how the conversation unfolded, but it became clear that I and some others in the room assumed “Good” metadata meant that it was non-MARC, XML-based, and highly customizable. I was quickly corrected by someone who told me that “Good” metadata meant complete, rich records using a controlled-vocabulary. The conversation moved on pretty quickly from there and we didn’t belabor the debate, but it once again highlighted for me just how fractured the library world has become in figuring out what our job is. The fact is, “Good” metadata is probably both of the things mentioned above. Nevertheless, we have a lot of work to do to reconcile the new work to-be-done with the work we’ve traditionally done, and, well that’s a lot of work.

I’m pretty sure that last sentence was stolen from one of Dubya’s State of the Union addresses.

What a lovely, grey December day.

I started experimenting with using Ruby to mash up some of the WorldCat.org data with Google Maps. It’s a fun project - it has probably been done 50 times in better and more useful ways, but as an exercise in web services for libraries it seems worthwhile. The aim is to develop some rudimentary sample applications that can be used to demonstrate the potential & power of Web Services to non-techno librarians. But more on that later when I have something worth posting.

What I really want to say is that since I have only recently really started using Ruby, I have found it surprisingly difficult to reverse-engineer my learning to fit into the Rails framework. Rails is so completely out-of-the-box and turnkey, and I tend to like to start with the ‘Hello World’ exercises when learning new technologies. So, instead of saying, “Hey I’m going to create a web application that does X, Y, and Z and I’ll use Rails to do it,” I said, “Hey I want to write a Ruby program that does X, Y, and Z.” Once I had the program working, I realized that fitting it nicely into the Rails framework was less intuitive than I thought it would be. What I’m doing at this point is just using a controller that calls my Ruby program, like this:

class SandboxController < ActionController::Base

require File.dirname(__FILE__) + '/myProgram.rb'

  def input
  end

  def get_addr
    @city = params[:city]
    @state = params[:state]
    @location = Array.new(search_worldcat_registry(@city,@state))
    [do_some_stuff, etc...]
  end
end

I have no idea if this sort of thing is best practice with Rails. My impression (possibly wrong) is that most developers approach a project with Rails in mind and then design in that context. Maybe next time around I’ll try it that way, but I suspect that this approach will, after a long slog, end with my having a much greater appreciation for how the Rails framework really works. I guess we’ll see…

I spent alot of time today in meetings to discuss the future of our l0cal Union Catalogs. It has really highlighted the way in which the library world has split into two camps (at least), neither of which seem to be well aware of the other.

On one hand, we have the technology folks - people like Roy Tennant, the Code4Lib bunch, and the countless number of library-employed developers who are applying a fairly non-traditional ideas to next-generation systems. These are the folks who see collections metadata as one part of a contiguous whole - an academic infrastructure made up of diverse yet coherent data sets. The idea of the ‘catalog,’ much less the Union Catalog, in this model seems pretty irrelevant, though in my experience everyone in this world is very keenly interested in presenting users with a coherent and useful public-service interface.

On the other hand, we have the approach common to MLS-educated mainstream librarians. At the risk of lumping this extremely diverse group into an artificially homogenized whole, please bear with me. Librarians are, mostly, still thinking of catalogs. They may be feature-rich and easy on the eyes (though probably not), but they are still catalogs. Locally managed, meticulously manicured, completist documents that are, by definition, tied to the physical buildings in which their collection resides. This isn’t to cast librarians as stodgy Luddites, nor to declare library technologists as revolutionary geniuses - in fact, I think the differences in philosophy are pretty easy to work around if we all get to using the same vocabulary. But what strikes me is that these conversations are largely occurring in parallel, rather than across organizations.

At last year’s Code4Lib 2007 conference , I was surprised at how few ‘official’ librarians were in attendance. But what I experienced was unbridled enthusiasm for the academic mission of the library, coupled with incredible talent and tons of promising new initiatives & projects. I think it made a pretty good (and pretty well-trodden) case that the MLS is superfluous to innovative library work. But I was dismayed that so much of the work emerging from this community, or many others like it, is almost completely unknown to the typical working librarian. Just because it is on a computer doesn’t make it somebody else’s domain anymore, and I think if we’re going to get this next-gen thing right, we’re going to need to accept it.

Incidentally, I don’t think I’ll be attending Code4Lib 2008 for personal reasons, which makes me sad. I hope to get involved more in years to come…

I moved this blog to my own domain (lettertray.org, in case you hadn’t noticed).  It took about 3 seconds, literally, to dump the old Wordpress.com blog and import it here.  Now granted, these are two flavors of the same product, but it seems that Wordpress has made it just as easy to do the same with a whole bunch of other blog software stuff.

Why can’t all data be this easy to move around?  It can, but then a lot of people would stop getting paid.

I’ve been working lately on some pilot projects using library data in Web Services (big “W” and big “S”, mind you) repositories. I’ve been trying to wrap my head around REST, or rather what it means for the real-library world. I like it. A lot. The crazy thing is that libraries really haven’t even caught on to the Web Services bandwagon, much less gone through the whole RPC/SOAP/REST soul-searching to discover what we want our next generation technologies to look like. Instead we still get into debates about MARC fields and unfixed bugs in our dying ILSs and such. Sigh.

Thankfully there are a bunch of community-based projects that are exploring some of these issues. I’m think of Evergreen, which is building in some really nice features for supporting web-services calls against catalog data; OpenSearch, which is attempting to standardize some ways to share search process data; and more broad protocol-type projects like unAPI. My problem with this is not that these projects exist - they’re terrific. The problem is that the issues, & technologies that make these projects terrific have failed to become a part of librarians’ vocabularies. Many of the folks who are developing these systems do work in the library world, but many of them are programmers/techies first and library people second. For a profession that has always clung desperately to it’s own sense of relevance, why are librarians merely becoming consumers of information-management technologies and not designers, researchers, and zealots?

It isn’t that librarians should all become programmers - we shouldn’t (at least not all of us). Nor should librarians’ central concern be about bleeding-edge technologies. But the fact is that we already spend massive amounts of time, energy, and resources dealing with and learning about library-centric technologies that are either dead or might as well be. What is the catalyst that brings us, as a profession, back to a place where we’re not merely digesting interfaces & services that are served to us by vendors, but actually dictating the terms of how our collections should be made accessible long-term and across the web?

None of this discussion is new, and folks like Roy Tennant have been talking openly about these issues for years and years. I think that is what is so frustrating. Librarians, as a profession, are aware of these issues, but we have such poor leadership and we’re such a highly-stratified profession that we haven’t been able to gain a consensus about how our technological existence can evolve.