1. their architecture (physical)
2. their librarians (departments)
3. their collections (special -> digital)

The most flexible and adaptable of these differentiating factors, then, will most likely be our websites and digitized items (eventually, perhaps, our “linked data”). Certainly the physical architecture of the libraries will change most slowly, but with an average website “face-lift” occurring — let’s say — every three years, presently it may actually be the case that the average time frame of personnel shift amongst libraries/departments is approximately equal to any major attention lavished on the website and/or the addition/migration of major digitized collections. But soon, surely, it will be indisputable that it’s our digital collections alone that will be our most adaptable differentiating factor.

As such, it will equally be the most powerful method to level the variances between our libraries (think “open source software”) and, paradoxically, also the most powerful method to differentiate our libraries (think local developments on top of “open source software”). Furthermore, though our digitized surrogates will certainly retain the provenance of their real-world counterparts by means of metadata, my contention is that in the eventual wake of the mass digitization of special collections, major research libraries will only be distinguishable by — not three — but just two things:

1. their architecture
2. their librarians

And so, as our most unique resources become de-referenceable, these acts will slowly but eventually erase all differences in our collections (barring, of course, or perhaps only being slowed by, forced authentication and registration of online “researchers”) and return libraries to a pre-website state.

Rather than being feared, however, this should be our ultimate goal. Though universities will certainly retain their differences and specialties, the special collections of the libraries (those available online) will become the collections of all (of course, libraries will still need to maintain these collections, but it’s likely that they’ll perform this as a shared and proportionally balanced duty).

I should clarify, though: being returned to a “pre-website state” will not mean that a library will suddenly cease to exist online. Rather, the library’s online existence will no longer be controlled and contained, at least not in the same manner (and the site, as we know it now, might simply not need to exist).   And this, finally, brings me back to Flickr, a small but timely example of the changes ahead.

But first, I should say, I had little to no experience with Flickr when setting out to include a sample of ECU’s digital collections  (http://www.flickr.com/photos/ecu_digital_collections). I mention this at the onset to highlight Flickr’s ease of use and, also, the potential reasoning behind my false steps along the way, especially since I ended up working through the necessary steps in, literally, a backward fashion.

What follows is a bullet-list summary of my experience in the process so far (and please feel free to ask me about any particulars).

Basic steps:

• Requested a free, non-commericial API from Flickr (http://www.flickr.com/services/api/)
• Selected public domain/copyright free items to share
• Batched and resized images to save space (wanted to be under the free account’s 100 MB/month cap)
• Wrote an XSLT stylsheet to remove just a few pieces of data from our METS record
  1. Title
  2. Description
  3. Date
  4. Persistent URL
• Added just one or two tags to each image based on “format” and “virtual collection” (opted not to add our subjects as tags or to display them at all)
• Used a text editor to take the output and put into a Python file, generally making sure that I wrapped strings in triple quotes
• Finally, I used “Beej’s Python Flickr API kit” for the mass upload and user authentication

Next steps:

• Update my old images with “machine tags“, as I neglected this in my first round
• Add a new set (the free account lets you have up to three)
• Get the Pro account
• Use the API to funnel the comments and tags from Flickr to our site, thereby linking user-supplied data from this Flickr image to that same image in our digital repository, which doesn’t yet have that comment or tag.
• Join The Commons on Flickr if approved

And things to consider if you set up a Flickr account:

• Don’t select a birthday that would make you under 18, or else you’ll need to use a credit card to verify parental consent (as if that alone won’t make everyone underage grow up quite quickly)
• If you’re using a free account, remember that though you’re able to upload 100MB a month, only your 200 most recent images will be displayed

Some interesting Library/Flickr articles to read:

• Historical Photos in Web Archives Gain Vivid New Lives by Noam Cohen
• Developing an Academic Image Collection with Flickr by Jeremy McWilliams

And finally:

As our collections continue to disperse in the digital age, and as our collections begin to arrive in a predominately digital format, it’s my hope that we’ll be able to receive donations that can be shared online without restrictions.

At the same time, SAA and archivists in general will need to vigilantly campaign against the potential misappropriation of our collections. Though commercial partners and vendors might not offer to digitize our special collections for free, they will certainly come knocking on the doors soon enough, explaining that they can host our vast collections; but in this respect I hope that we do not yield. If we do, we’ll surely trap not only our libraries, but also our users; and, being a trap, the situation won’t come equipped with something as user-friendly as the Flicrk API to permit the free passport of our collections and users. Certainly, then, there’s no reason that we shouldn’t already be imagining the equivalent of the Hathi Trust for our special collection materials.

I now realize that nearly everything you do like this is going to take a long time, if: a) you want to do it right and b) your institution won’t quit asking you to do other projects!

All joking aside, we are enormously proud of our repository. The guiding principles were:

• one common database and infrastructure that could be utilized for multiple “collections”
• Collections are nice and we do like them, but we will always have “uncollected” items in there and we need to design it so that you can still discover these
• This repository will gather everything digitized for a patron request, for an exhibit, for a book, for preservation, or because it would be cool to digitize it

Based on the above principles we used a back-end XML database (TextML) and a METS/MODS record for every object. In addition, we included Dublin Core records in the METS (scripted from the MODS) for the purposes of OAI harvesting, appropriate admin metatadata (MIX in most cases since we have a lot of images), and even the full text of TEI records when those were available. To date we only have one audio object, but should be ingesting another 20 or so by March.

We had the details of the backend database worked out in the first third of 2008, and then set ourselves to the task of figuring out how to present this stuff to people who would have no idea what the site was, and in many cases, who ECU and Joyner Library were. We took the approach that the site had to invite people into the content — we had to have lots of ways that they could come to page, click on one thing and get to content.

So we created “subject clouds” and created collections post-hoc (i.e. we picked some relevant themes, then looked at what we had and organized them together). Both of these things were created on the premise that the organization of physical items in the library isn’t necessarily the best organization for things on the web. The web can do both more and less than that.

We also provided more tools for navigating through materials once you found some by including hyperlinks in the records, and a faceted drill-down of the subject headings. These, as well as the subject cloud and the organization of the post-hoc collections, were all based on LCSH subject headings. A simple look at size of the facet list or the subject cloud gives you a good indication of both the benefits and drawbacks of this approach. But we figured we would use what we had and I think in some sense it is successful.

What is most interesting to me, is that many of these design elements were things that I’ve been thinking about since my days at UM. Being able to realize them here with a fresh new project was really exciting. Certainly, it isn’t perfect, but I think it’s all too rare in our jobs that we get to come up with an idea, implement it, and then evaluate how it worked out. We are often saddled with maintaining past projects and living within the bounds of past decisions. Of course, admitting that means that I must acknowledge that one day the decisions we’ve made on this project will limit us somewhere else. But I think we’ve created enough leeway and enough to think about, that we should be busy for quite some time.