As far as I'm concerned, the most exciting developments this year in repositories and digital curation have come out of the California Digital Library. It has been impossible not to notice their papers and presentations. Put simply, their idea is that digital curation is enabled by "micro-services" built upon well-known abstractions such as the filesystem. The benefits are obvious: filesystem tools are ubiquitous and cross-platform, and there are strong market forces to ensure the filesystem persists. The idea is radically simple and straightforward, though many questions remain about such a paradigm. I'll return to those later.

If you have not yet taken a look at CDL's curation micro-service specifications, most of which may be printed on as few as one or two sheets of paper, see the Digital Library Building Blocks.

My co-workers in the LC Repository Development Center have been chatting about these specs on and off throughout the year. After months of procrastinating, I finally read all of the specs on Thursday; it's wonderful that you can do so in the course of one reading session, I might add. Yesterday a bunch of us RDCers got together to chat (informally) about the specs: what they're for, how they work, and how they interact with one another. I learn by doing, by examples, so I combed through each of the specs in advance of our meeting and tried to construct a minimal repository[1] based on micro-services.

Here is a tree visualization of the final product, inevitable warts and all: The services I used were Namaste, Content Access Node (CAN), Pairtree, Dflat, Reverse Directory Deltas (ReDD), Class-based System for Managing Object Properties (CLOP), and BagIt (co-developed by LC and CDL).

As I mentioned in our Friday meeting, recounting my experience exploring the specs: the bad thing is that I spent an hour building a repository with rudimentary tools such as mkdir, touch, cp, ln, and emacs; but the good thing is that I built a repository in one hour using common, rudimentary tools. It's a very compelling paradigm. Ed's already built a tool implementing some of Dflat, further demonstrating how lightweight these micro-services are. (UPDATE: Ed notes that this code is a work in progress and is "barely functional.") (UPDATE 2: The dflat library has come a long way. Check it out if you're interested. Also, I just committed a pretty basic Namaste library: http://github.com/mjgiarlo/namaste. Only took about an hour, which is a testament to the power of lightweight specs.)

I am certain this will be a running thread at work as the specifications evolve and our understanding of them grows. Some questions and comments that occurred to me while exploring the micro-service specs and building the minimal repo:

• CAN was a bit puzzling. The spec is simple enough, but I found some of the conventions confusing, and I was left wondering what CAN provides other than a container. What I would like to see is a simple use case and perhaps more examples. Thus, the CAN stuff in my sample repo doesn't feel very useful only because I had a hard time working with the spec.
• CLOP feels like the least mature of the specifications. It seems generally useful to be able to put digital objects, however you define that, into classes and define properties on those classes. The spec did not clearly convey to me just how it accomplishes that aim. A few examples would go a very long way. I've got some CLOP stuff in the sample repo but I have no idea how close my implementation matches the spec.
• Is Dflat dependent on ReDD? One would assume not since there's an optional property in the dflat-info.txt file for specifying a delta scheme. But, say, could you stub out the v001 directory (reserved to hold the initial version of a digital object) and use a system such as git or bazaar?
  
  One might argue that these established delta schemes, if you want to call them that, have many more developers and users than a system such as ReDD and thus should persist longer and have more tools built around them. I imagine the micro-service viewpoint would acknowledge that point, but counter that the spirit of these specs is to avoid dependencies from outside the filesystem?
• Is the ReDD specification meaningful outside of a Dflat given that any one ReDD directory knows nothing of its successors and predecessors, or is it dependent upon Dflat?
• Could a BagIt bag live inside of the ReDD reserved "full" directory? That is, could the "full" directory be marked up appropriately to be a BagIt bag?
• How many tools exist for these specs? I notice there's code in CPAN for Pairtree and Namaste, which is a fabulous start. Tools are the difference between YAMF (Yet Another Messy Filesystem) and reliably managed curation services. Granted, tools such as cp and emacs already exist and are part of the appeal of these micro-services, but there's also tremendous room for error if operations are all done "by hand."
• To what extent has CDL transitioned to using these specs/tools?
• Are other institutions using these specs/tools? I have heard tell that digital library folks from the University of Michigan and the University of North Texas may be involved.

I hope I don't sound overly critical. I'm really glad our colleagues at the California Digital Library have written these specifications and applied their deep experience to what could be a transformative paradigm[2] in the digital curation world. Kudos to them!

Notes

1. Perhaps it's more in line with the specs to refer to this space as "a managed filesystem that drives repository and curation services," given the CDL philosophy that preservation is not a place/repository. But it's easier to say "repository," so there you go.
2. Please excuse the fanboyishness; this filesystem fetishism is exciting stuff!

While doing some reading for a little talk my colleague, Ed Summers, and I are giving at code4lib 2009, I came across a paragraph that sparked a crazy thought. So crazy that it's not crazy at all. So not crazy that I am sure other people have thought of it. But nonetheless, here I am writing about it just in case.

From Sarah Currier's paper on SWORD (emphasis mine):

One of the most frequently cited barriers to academics depositing their teaching materials into repositories is the keystroke-count involved in logging into a repository, uploading the resource, creating metadata, perhaps selecting a licence, and publishing the resource. It was a quick win, therefore, to create a drag-and-drop desktop tool to allow a single keystroke deposit of resources, including multiple resources in one action. For a repository that supports automatic metadata generation, administrative metadata can be created at the point of entry to the repository without the user needing to create any.

And I wondered how many repositories supported automatic metadata generation. I wondered how many repositories supported automatic generation of rich metadata. And lastly I wondered, might this be a more or less natural role for catalogers: augmenting stub metadata records or doing original cataloging for institutional repository deposits? Especially at a time when many of them are being reclassified as acquisitions specialists or digital projects managers?

Potential issues and questions:

• Author ignorance: Maybe catalogers are already doing this and I'm a moron?
• Scale: Is it realistic to expect to be able to "keep up" with repository deposits?
• Granularity: Does cataloging at the level of articles, and perhaps at even finer granularities, introduce challenges?
• Duplication: If pre-prints are cataloged in the IR, for instance, will they need to be cataloged again later?
• … there are others I thought of on my commute this morning but have since forgotten them. Feel free to add comments.

I will admit here that I've been somewhat out of the (academic) institutional repository space a while, and cataloging is something I don't share thoughts about very often because my exposure is limited to having taken one course a couple years ago.

I assume there's a body of research about this out there somewhere but I figured I'd post this anyway.

Karen Coombs responds to Ross Singer, re: requiring an MLS degree in library technology positions.

I'm torn on the issue, as an erstwhile systems analyst who went through library school primarily for letters after my name. I've seen both sides of the divide and have seen IT positions that might have benefited from the MLS — a particular non-MLS comes to mind who had no sense of which battles were winnable and ultimately wound up leaving — and also seen jobs with a totally unnecessary MLS requirement that accomplished little other than watering down the candidate pool.

If a position will need to interact with librarians or act in public services capacities, the MLS is very useful; folks from IT (or elsewhere in the extrabibliosphere) do not necessarily know our culture or our values — hell, they might not even speak our language. And there is something to be said for this sort of familiarity. Librarians hold the reins in libraries and if you can't speak to their values in a language they understand, you are likely to spend much of your career tilting against windmills (and getting nowhere fast).

On the other hand, we librarian folk think that libraries are a hell of a lot more special than we actually are. Our needs are sometimes esoteric, but many times they are not, and so an MLS requirement probably does more harm than good. And too often "web librarian" and "systems librarian" are euphemisms for "underpaid IT workers." Earning a master's degree should not reduce your earning potential, and yet that is precisely what happens.

In summary, I guess my views align with Karen's but I appreciate what Ross is adding to the dialogue (having experienced much of the same nonsense). We need more Rosses in library-land, and ought to treat them very well in order to keep them around. Library technologists are (read: "should be") first-class citizens in libraries and will play an active if not vital role in our future, whether they have the MLS or not. We'd do well to keep that in mind.

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.

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!

I followed a series of links[1] to find this article on the effect of Generation X values upon work culture. The article cites the impending wave of Baby Boomer retirements, pointing out that a number of executive and upper management positions will open up and likely be filled by Generation Xers. Will workplace culture change when GenXers take the reins? If so, to what extent? And how will it affect libraries which, unlike the corporate world, are saturnine[2]?

If organizational culture is in part derived from the values and culture of those who are at the helm, it is bound to change when Generation X takes over. Baby Boomers are described as follows:

"Leadership for them has been characterized by workaholic tendencies and materialism. Baby Boomers have had a minimum number of careers or a single career path, are impressed by authority, are optimistic and are driven to achieve."

GenXers, on the other hand,

"…question authority, seek bigger meaning in life and work, are technologically savvy, live in the present, are skeptical, see career as a key to happiness, are open to multi-careers, consider challenge and variety as being more important than job security and constantly aim to achieve work-life balance."

An obvious criticism of the differences between the generations is that they are only generalizations and that they apply only to those who fit the stereotypes. However, it does seem naïve to assume that none of the generalizations apply, that cultures and skill sets do not vary generationally; stereotypes are rooted in the truth.

The article links to a study showing that

"Baby Boomers received higher ratings from managers in 10 out of 18 competencies, particularly in their ability to coach and develop people and to manage execution. Generation X managers received higher ratings in self-development, work commitment and analyzing issues"

GenXers will need to work on their ability to mentor and on expanding upon their analysis skills with the ability to synthesize as well; it is important to see both the forest and the trees. Whereas Baby Boomers are more comfortable in standard hierarchies, GenXers take more of a team-building approach, valuing independence and creativity to get the job done, whatever it may be. GenXers are also reported to thrive on change which is a key attribute in dealing successfully with disruptive technologies and technological discontinuities, clearly an area where improvement is needed.

As a GenXer, I am cynical about the likelihood of my generation's general disdain for bureacratic structure having any noticeable effect upon the bureaucracy, so common in academia, that seems to cripple decision-making processes and any semblance of agility. I would love to see a new crop of administrators and managers come in and abolish the old ways of "analysis paralysis." Why not take a heuristic-based approach to management? Instead of discussing something ad nauseum in three months' worth of meetings, why not try it out as a pilot project?

Still, I am hopeful. If the coming wave of retirements brings in a batch of administrators that value agility, tear down process-tangling walls of bureaucracy, encourage and reward creativity, embrace innovation and skunk-works as being essential to our mission, and generally stir the pot in some productive fashion, the future holds great things.

Besides, I can't wait for flannel shirts and wool hats to become de rigueur for Academic Library Fashion 2.0. (Or will the meme have evolved to 3.0 by that time?)

–

1. I've been following Mark Leggott's Slow Library blog the past few months. Read the "Ahhh…the Beauty of Slow" post for an explanation of what the movement entails. The latest post contains a link to the Slow Leadership blog, which is where I found the Generation X article.

2. This is a base generalization; I admit that libraries might even be more agile than the corporate world in some areas, but do tend to believe that we are slow-moving, change-resistant beasts in general.