Ramblings on Librarianship, Technology, and Academia

I've mostly been blogging on children's literature issues lately, not archives and library issues. I think this is because in archives, I'm much more concerned with the pragmatic macro/micro day-to-day realities of the nigtmare that is digital preservation, rather than with any attempt to drive the field forward. It's one of the reasons I haven't said anything about the DuraSpace announcement, not wanting to harsh on anyone's squee, because while in the long-term I can see real benefits to having a joint foundation, not tied to a single software solution, in the short run I just wish the Fedora Commons team would think more about the daily pragmatic realities of running a production preservation and access tool using their software.

But I am going to break my library silence because I haven't seen the Elsevier scandal get much play outside of the science and library blogospheres, and it should. In a nutshell, one of the ongoing Vioxx lawsuits revealed that Elsevier produced a fake peer reviewed journal as a marketing tool for Merck. The Australasian Journal of Bone and Joint Medicine was apparently high enough quality to fool doctors who weren't looking for shenanigans. Jacqueline at Laika's MedLibLog points out that this practice seems either more or less outrageous when you realize it's hardly unique. Good thing Elsevier assures us that it was an isolated practice and those responsible for sacking those responsible have been sacked!

Keep in mind that Elsevier has spent a substantial amount of time and money lobbying at least the United States and United Kingdom governments explaining that open access research will be devastating because it will be impossible for anyone to tell what is high-quality research and what is solid, peer-reviewed, and published by a reputable gatekeeper.

Library Garden posted on The New IT Librarian Application.
Librarian in Black responded with How to Test Applicants' Tech Skills.
Caveat Lector responded with Testing Your Techies.

Full disclosure: Before I went to library school, I spent ten years as a systems administrator in large corporate environments, and I was damn good at it. I still run my own small ISP. So I'm speaking here as a librarian/archivist but also as a sysadmin.

Library Garden's post is misguided: "If the person's resume and cover letter meet your standards, TEXT their cell phone to set up an interview. Unorthodox? Perhaps, but part of the IT personality is embracing modern technology. Texting is one of the most popular means of communication with our younger population and, if we want to stay current with our patrons, then we need make sure our IT people are familiar with it as well."

This is maybe good advice if you are trying to hire a Library 2.0 guru, but is it good advice to hire IT personnel? No, no, and no. Your IT people need to be able to make sure your servers are backed up. They need to make sure you have fast reliable networks. The need to make sure you have all of the rights you need to administer your data, and all the right tools at your fingertips. They need to make sure that your data are secure. They need to be on top of improvements in file systems, aware of security alerts, knowledgeable about server-class hardware. They probably need to be capable database administrators in a pinch. And if the library staff believes the best way to communicate with users includes setting up text notifications, then your IT people need to be able to set up a good infrastructure for sending text notifications.

Does that mean they need to take in text messages themselves? Maybe you think so. Maybe you think that nobody can set up a good infrastructure of a tool they don't themselves use. But I will tell you, there are plenty of fantastic sysadmins who are complete Luddites about personal technology. Are you really going to hire a sysadmin because she uses twitter? Or are you going to hire her because she writes Debian Linux kernel patches in her spare time? I will give you a hint: there is only one right answer to this question.

Librarian in Black hits it: "And testing an IT person's skills is a lot tricker, but it can be done...assuming you have someone on the other end who can verify the accuracy of the responses. I advocate for essay questions and actual problem-solving questions that present a real problem and ask for code,or a project plan, or a network diagram."

There are two hugely important points here: testing and having someone in-house who can verify the accuracy.

I have no idea how people do real interviews without doing skills tests. My favorite sysadmin test is to hand people this snippet:

crw-rw-rw- 1 root tty 3, 175 2008-06-07 23:43 ttyzf
prw-r----- 1 root adm 0 2008-06-10 10:04 xconsole
brw-rw---- 1 root disk 202, 2 2008-06-07 23:43 xvda2
drwxrwxrwt 7 root root 5120 2008-06-10 15:56 tmp
lrwxrwxrwx 1 root root 4 2008-04-24 15:48 lib64 -> /lib
-rwxr-sr-x 1 root mail 395107 2008-06-09 10:07 elm
-rwx--x--x 1 root staff 15340 2008-06-09 10:07 mmencode

I ask them to talk about it. It's a great piece, because if you have any UNIX admin experience at all, you should be able to at least give a four-word description of that whole class of text. And there are lines in there of some fairly intense levels of complexity, which in many cases only an experienced administrator would be able to describe. It's not a Pass/Fail test, it's a Show Me What You Know test, which is a far better kind. Alternately, I would ask problem-solving questions: "User calls up yelling about [situation]. Fix it." This gives you the opportunity to watch both problem-solving skills and at least the job applicant's stated user-communication skills.

But the vitally important issue here is what Librarian in Black says: assuming you have someone on the other end. It's very, very difficult -- almost impossible -- for an entirely non-technical hiring committee to select a good technical applicant. You can select someone nice, and you can select someone who will fit in with your corporate culture, and you can select somebody who talks a good game. But without finding somebody else with a similar set of job skills to sit on your hiring committee? It's all luck. Trust me, no matter how smoothly the person comes off, no matter how competent he or she seems, you can't do an accurate assessment of technical skills without having the knowledge yourself. Technical people often sound extremely confident in their skill, oftentimes with no good reason. If it is at all possible for you to get an IT person from somewhere else in your organization to sit in on the hiring committee? Do so.

I've been getting increasingly concerned about what I see as a too-shallow view of sustainability in digital preservation. There's been a lot of lip service paid over the last few years to preservation, and I have certainly heard talks by grant-funding agencies in which they explained that they are now only funding grants which have sustainability written into the grant structure. Yet time and time again, I see soft money being awarded to projects for which the project administrators clearly have only the vaguest idea of what sustainability really means in a software environment.

I don't see this as anyone's fault, mind you. Software developers and IT folks aren't used to thinking of software projects in terms of Permanence. In the traditional software world, the only way something is going to be around forever is if it's going to be used all that time -- for example, a financial application which is in constant use needs to be constantly up. But archival digital preservation has a very different sense of permanence. For us, permanence might mean that you build a digital archival collection once, don't touch its content again for 10 years, but can still discover all of its preserved content at the end of those 10 years.

Meanwhile, in Internet time, a project which has been around for two years is clearly well past its prime and ready to be retired.

Repository managers are putting all of this great work into the repository layer^* of preservation: handles and DOIs, PRESERV and PRONOM, JHOVE and audit trails and the RLG checklist. But meanwhile, all of these collections of digital objects -- many of them funded by limited-duration soft money -- are running on operating systems which will need to be upgraded and patched as time passes, on hardware which will need to be upgraded and repaired as time passes, on networks which require maintenance. Software requires sustenance and maintenance, and no project which doesn't take into account that such maintenance requires skilled technical people in perpetuity can succeed as perpetual preservation. Real sustainability means commitment from and communication with the programmers and sysadmins. It requires the techies understand an archivist's notion of "permanence", and the librarians and archivists (and grant agencies) understand how that a computer needs more than electricity to keep running -- it needs regular care and feeding.

(This, by the way, is one of the reasons I'm so excited by the OTW Archive of One's Own and the Transformative Works and Cultures journal. The individuals responsible for the archive and the journal *do* have a real understanding of and commitment to permanence down to the hardware and network provider level. Admittedly, it's a volunteer-run, donation supported organization, so its sustainability is an open question. But it's a question the OTW Board is wholeheartedly investigating, because they understand its importance.)

*I'm somewhat tempted to make an archival model of preservation that follows the layered structue of the OSI model of network communication. Collection policy layer, Accession layer, Content layer, Descriptive Metadata layer, Preservation Metadata layer, Application Layer, Operating System layer, Hardware layer. Then you could make sure any new preservation project has all of those checkboxes ticked. Sort of an uber-simplification of the RLG Checklist, in a nice, nerd-friendly format.

At the end of June, I will be leaving Brandeis to accept a position as Digital Resources Archivist at Tufts, and I'm experiencing major seller's remorse. Not buyer's remorse -- I am extremely excited about joining the team over at Tufts Digital Collections and Archives -- but seller's remorse. I don't want to leave my baby, my digital collections, with so much exciting work going on here.

The fact is that in only a year we've built the digital collections here from the glint in the milkman's eye to a robust and scalable program which will be ready to launch in a few weeks. What I'm most proud of is that I think we've built something which can live just fine without me while they hunt for a replacement, and what I am most upset about is leaving for somebody else all the great ideas for projects we've been forming as we've approached the finish line: Institutional Repository; ETDs; special faculty projects; integration with the University photography department. So all of you out there who read this humble blog and might have the skills to foster my baby? Apply for this job. The Brandeis Digital Collections deserve the best.

So, Tufts. Why am I so pleased about a position which looks like a step down? I'll be going from driving the entire digital collections initiative at one university to being responsible for a small component (management, ingest, and maintenance of digital objects) of the digital collections at a roughly equivalent university. (Not to mention that I will be moving from DSpace to Fedora, and so far, I very much prefer DSpace.)

Over the years that I've been working, I've learned something startling about myself: I'd rather be a small fish in a big pond than a big fish in a small pond. Which is not to say that I would rather be a peon or cog in the machine -- anything but. Everyone who knows me knows that I am chock full of opinions. But I want learning opportunities, mentors, people to teach me things. At the best working environment I ever had -- The Company Formerly Known As, as we like to call it -- I was smack in the middle of a large group of people which included both some of the best mentors I've ever had and some really terrific entry level people who were eager to learn. There was the opportunity to teach and learn from my peers.

I've had a great time over the last year at Brandeis learning by doing, learning by screwing up, learning by attending classes, learning by attending conferences, learning by reading blogs and mailing lists and conference proceedings. I've had my trial by fire, and now it's time for me to get some solid mentoring. The conferences I've attended over the last year have been chock full of presentations by people in the group I'm about to join. Now is my chance to really learn from people who've been doing this for a long time.

Also, I would be lying if I didn't admit that proximity to my home and a walking commute played a large part in my decision to change. One of the advantages of working in a university is gaining the University community. As a car-free person, I'm so distant from Brandeis geographically that I can't take advantage of that community. At Tufts, I can.

Okay, folks, I need your help. I am currently getting soaked in a brainstorm, and I'd like to get this idea down before I lose the details. But since this is a brainstorm, it might make no sense at all. Tell me if what I'm talking about is an incredibly stupid idea that will never work. Alternately, tell me if what I'm suggesting is ridiculously common, and everybody does it this way already, and how could I not have noticed?

The two-part problem:

1. As we investigate products for digital asset management in the library, it's extremely likely that no one product will solve all of our needs. We will perforce find ourselves with digital resources in a number of different products, and will need to design either a single front end, or we'll have to accept a certain amount of user confusion at not knowing which tool holds the resources they need.

2. It's entirely possible that a single asset might be simultaneously part of our institutional repository and yet necessary for our learning management software, or similarly dual-purposed. How do these assets get filed? In what product?

My idea: carefully design an institution-specific set of metadata fields for each purpose. One indicating institutional repository, for example, and another indicating learning management. Assign as many of these metadata fields as necessary to each asset, no matter what product the asset is stored in. Store the asset in a product which is best suited for that asset-type. Then, using some kind of harvesting (e.g. Z39.50, OAI), harvest the contents of the various products and repositories. Write an institution-specific search mechanism that knows how to search the harvested data for all, say, institutional repository items. Or for all items in the special collections.

This idea of course ellides several major problems: designing the metadata; building what is effectively a small-scale federated search tool; deciding the appropriate product for the appropriate kind of asset; submitting assets into a multitude of products, possibly by non-librarian users such as faculty members and students. But is there any meat to this idea?ed

Recently, I had an extended interview for a job for which I was ultimately rejected. I don't know who did get the job, but I'm sure I'll know soon enough. You see, this interview was to become Somebody in the library world. The person in this position will be a Mover and Shaker in the world of librarianship and technology. She'll have the opportunity to see potential improvements in librarianship and make them happen, to change the rules, to be part of the paradigm shift. I'm sure in the coming years I'll see her name at conferences, in books, on papers. And I'll be a little jealous every time.

As luck would have it, my next interview -- before I'd even been rejected from the Somebody position -- was to be a Nobody. A cog in a library system, about 6 steps removed from any reference or research or information. My job would be to make life a little more efficient for those who make life more efficient for those who enable the people who do actual library work. And what I discovered, when I interviewed for the Nobody position, was that I'd been corrupted by the interview for the Somebody position. While I'd not gone into librarianship in the hopes of fame and fortune, suddenly I found all other library positions paling before the reflected glory of my unrealised Somebodyness. All my unrealised hopes and dreams (the novelist I'll never be, despite my mother's constant pressure; the open-source revolution I never made; the PhD I never got; even the BNF I'm not) brought to light in all their unattractive, spotted, warty nakedness. Suddenly the simple library jobs for which I'd dropped my career, gone thousands of dollars into debt, and changed my life seemed petty.

It's hard getting my perspective back. I remind myself that it's easy in this day and age for a smart person to become Somebody if she so chooses. I have this blog: if I think of clever and world-shattering ideas I can post them. I'm a programmer: if I don't like existing library software I can write my own, better software. I'm literate and intelligent: I can write articles, attend conferences, and generally make a Somebody of myself. But only if I want to. It's not going to happen because an employer tells me so, but only if it's so important to me to become Somebody that I do the work.

Is it that important to me? I don't know. I'm happy enough in my life, and don't generally think I need to be on the forefront of changing the world. I don't want to be a name everybody knows, though I'd certainly not mind the private satisfaction of knowing that the Somebodys out there owe some small measure of their success to me. (I always did crew in high school plays. Does it show?) It wouldn't have occured to me until I interviewed for the Mover and Shaker position and realised the idea thrilled me. (And terrified me, in equal measure.)

I have to remember that being a librarian is, by definition, being Somebody. Remind myself of all my old lessons in social justice and community activism. Think globally, act locally, and all that. And I do remember, usually. Except late at night, when I'm trying to sleep, and I'm drowning in might-have-beens.

Note to self: Self, remember how parenth_blog and mirith convinced you to become a librarian? It was because they showed you how much you'd love reference, and they were right.

Self answers: Doh! I forgot. And Self gets back to the busy game of looking forward to reference and instruction at a conventional librarian position.

For the past two days, I've been a mad wikipedian. I got email from a classmate who knew I'm a wikipedia advocate asking me to talk about wikipedia to a colleague who'd called it "fun, but not scholarly" (I glowed appropriately, and with the necessary caveats and pro/con links); I watched Jon Udell's fabulous Heavy Metal Umlaut: the Movie (go watch! long, contains sound); and I updated several pages.

I found rather sad that the library and information science page, of all things, was in a year-old state of semi-stasis because of the early creation of an anti-academic article. After the neutral point of view was disputed, the page languished, unedited, for a year. I've been editing non-controversial Wikipedia pages for a while, but this was the first page I've ever made changes to with a non-neutral point of view warning. It was intriguing reading through all of the style and etiquette guides to make sure I was going about it the right way.

I certainly hope I don't cause any flaming. There are some interestingly contradictory points of Wikipedia etiquette. The first is that you don't unnecessarily delete controversial points of view, you just cite them so that they are statements of fact ("Bill O'Reilly called Jeremy Glick a coward", rather than "Jeremy Glick's cowardice...") and include opposing viewpoints where appropriate. But the second is that you can't use weasel words: "some people say Jeremy Glick was a coward". The trick with the "library and information science" page is that the controversial content contained some unverifiable statements, namely that practicing librarians and LIS professors are frequently at loggerheads.

I suspect that there's truth in that statement, though certainly not as much as the original article implied. The problem is that once practicing librarians start publishing their disagreements with the academy, they are well, publishing. And therefore somewhat in the academy, or at least in the semi-academic world of self-reflection, publishing, and dissemination. Honestly, do most practicing librarians who aren't interested in LIS even care what happens of library schools once they get out, as long as graduating students are competent to do the work? Library students, now they care, and frequently wish there were more practicing librarians among their professors. I could probably find some evidence of controversy between practicing and scholarly librarians if I spent enough time searching the peer-reviewed literature, but I certainly couldn't find much of the open web (amusingly, several of my Google searches for the great missing controversy led me straight to yarinareth2). Anyway, basic Wikipedia etiquette said that I needed to retain the original author's controversial statements as best I could, but Wikipedia style demanded more evidence than I could find. I did what I could, and weaseled out of it into discussion page for the article.

Sadly, now I've created a complex framework for the page, but it's midnight, and I have to wake up for work in 6 1/2 hours. I'll work on fleshing out the information, but hopefully other people will contribute as well (hint, hint).