System Delivery

For this week's assignment, we worked with a pre-configured system with an Omeka instance. It was an interesting departure from the way we had been evaluating systems throughout the first part of the semester. Previously, we had been building LAMP servers on virtual machines and building the repositories from scratch on the server at the command-line. It's an incredibly useful pedagogical approach in that it allows students to experience, albeit in a controlled microcosm, what it's like on the IT side to install and configure a collection management system.

It's interesting that our instructor chose to use Omeka as the week to try the new pre-installed VM approach, because one of Omeka's strengths is its 5-minute setup. I've done test installs on a hosted server, and they were all extremely easy to do. It would have been interesting to compare our experiences installing Omeka and, say, DSpace. At the same time, I probably would have gotten a little more out of our work with DSpace had we not had so many problems installing and configuring the system. That was definitely part of the learning process, though, so I'm not suggesting we forsake that component.

I know that part of the object of the course is to help students understand and wrangle with the issues related to describing and representing these collections online, but I can't help but think that some of the comparisons of these systems might have been a little more focused if we could have worked from a body of resources. Spending the semester working with the same body of resources and even the related metadata would allow us to focus more on implementation and evaluation of each collection system. I know that I spent an inordinate amount of time thinking about the resources I used and rethinking about them. If we used this model, we could focus our final project on resources of our choosing on a platform that we think works best (after having spent the semester working with a variety of systems). I suppose this is a bit of a digression, but I was thinking about it in the context of receiving a pre-installed system and how we could have those resources and metadata also pre-installed on the desktop.

While we're evaluating these approaches, I'd like to mention something that has nagged at me all semester. I understand the value of adding resources to our collection management systems individually, but I feel like we could also stand to gain some valuable perspective learning how bulk processing might work in a production system. Maybe this would be "Extra Advanced Digital Collections," but I feel like I could use some guidance in this area. We could also work on migrating collections from one system to another and seeing what sort of problems we have in that process. This would also be work that would benefit from providing students with a pre-installed system (or systems) from which we could work.

Consistently Inconsistent

This week's conversation topic forces me to come to grips with the fact that I've been lax in maintaining any level of consistency in the collection I'm developing. I'm using the ERPAePrints Digital Preservation Subject Headings for the descriptive metadata. It's a useful classification schema, but I've admittedly not drilled down into the sub-classifications to describe my resources with more granularity. Without these distinctions, many of the resources I'm using end up looking very similar -- thus making them harder to retrieve with any usefulness. I would have liked to have brought this taxonomy into ePrints, but other technical problems left me in a bit of a time crunch and I didn't attempt that exercise. The use of LCSH proved to be less than useful as well.

Now, I admit. I'm not a cataloger. In fact, when I'm looking at the resources I'm adding to my collections, I get easily distracted and have a hard time remembering how I described similar resources -- reinforcing the need to have a controlled vocabulary from which to choose. I sort of look at my inexperience cataloging as an indication (however minute) of what might happen when you have a variety of different catalogers (or depositors for public repositories)

I'm dealing with a similar situation at work where we're creating a collection level directory of digital collections in our organization's membership. We're using the Omeka platform with the intention that, after the initial corpus of collections are added to the directory, librarians will be able to add other collections as they are created. One thing that I like about Omeka is that it provides data-entry guidance for users adding items to a collection. Not only does it give lay descriptions of the DC fields, but it also provides guidance for how the entry should be formatted (dates, names, etc...). It's essentially DC classification for dummies --

Modulation and Evaluation

I'd like to take a swing at both challenges for this week's blog post. First, I wanted to mention a module that I installed on my Drupal instance. A few weeks ago, I wanted to embed video into the body of a message -- particularly YouTube and similar types of videos. While my collection is currently mostly research (text), I can see that a collection of this type (digital preservation resources) might, in the near future, need to include video of conference proceedings or tutorials. I did a quick Google search for "YouTube embed Drupal" and came across this page with links to the module and some information about how to configure the module. This basically allows contributors to add a tag like this (without spaces) to embed the video:
[ video:http://www.youtube.com/watch?v=uN1qUeId ]

Second, I want to take a moment to reflect on Drupal as a CMS for digital collections. One of the areas that I think needs clarification for me is how we might differentiate a website from a digital collection. It's obvious how useful Drupal is for building a website that can scale according to an institution's needs. I'm also in the process of trying to migrate my professional portfolio to the Drupal platform for many of the same reasons that we've explored in these recent units. I'll report back here on my progress.

Balance. Reality.

I tend to not know when to say no. I've regularly bitten off more than I can chew, and as a result, been stuck with a mouthful of projects that I have to chew on before I can swallow before moving onto the next meal. It works for me most of the time, but sometimes I feel like some work doesn't get the amount of attention that it deserves and my work suffers. So it's a bit of a switch for me to be in this program with my colleagues and have most of them taking two classes while I'm just taking the one per semester. I mean, they're all working, just like me. They all have families and lives outside of school and work, just like me. In fact, I'm willing to guess that I have it pretty easy compared to most of my peers -- easy commute, no children in the house, you get the idea.

I've said from the beginning of this program that I don't know how my classmates are able to manage two classes and all the other things going on in their lives. And I still stand by that. There has to be a certain amount of "do-it-to-get-it-done" going on with some of the assignments. I know that because even I feel that way in my position of one-class-per-semester privilege. And I hate when I'm working like that. I hate when I put something together and rush it out the door knowing it's sub-par work.

I mention all of this to say that I feel like taking only one class per semester in the DigIn program allows me to minimize some of that rush and actually spend time with material and LEARN it. A useful point of comparison for me is the Intro to Applied Technology course -- which I took while I was enrolled in other SIRLS classes and working full-time in various capacities around Tucson (grad student, bartender, dog walker, etc...). I finished that course with a real concern for how much I was actually going to remember in 6 months, but the immersion program has actually worked out pretty well. I remember bits and pieces, and I know where to go for answers to things I've forgotten.

I started this post thinking that i was going to make a case for why one class per semester is how this program should be done, but I think I've actually convinced myself the opposite. In our careers, we make sacrifices and compromises based on our values and how we perceive those compromises may affect the people with whom we work and the work we're doing. In that sense, the program accurately reflects the real world.

This is an extremely long-winded way of saying that although I've managed to squeeze a number of projects in and around my work and personal lives, I feel like things are really well-balanced in this ADC class this semester. I feel like I'm able to spend my time carefully working through the tech assignments and giving the management classes their due as well. I was initially worried that it was going to be more like combining the digital preservation or intro to digital collections course with the intro to applied technology course. If that were the case, the workload would be more than I could handle in any productive way.

CMS as an Alternative to Inertia

I recently posed a question to some library colleagues asking them who was still using listservs and for what purposes. The question wasn't intended to disparage the listserv as a communication tool, but rather to get to the bottom of whether or not listservs are still a useful tool. With the advent of technologies like RSS, it would seem that the usefulness of listservs had run its course and we could now move on to more efficient means of communication. Still, a surprising number of respondents said that they and their colleagues were still using listservs -- primarily because of the inertia. So a clunky means of sharing information that clogs inboxes and demands active (and often quite involved) user management strategies remains heavily used despite a number of ways that can more efficiently manage exponentially larger amounts of information.

I see similarities in how we approach the construction and maintenance of library websites. Why do we still have web development teams that are responsible not only for the creation of a site and new pages, but also the editing of pre-existing pages that may number in the thousands for larger library systems? How can we expect our overworked web dev teams to keep up with the growing demands to make our library websites more accurately reflect the way our users seek, retrieve, and create information online? We can point to inertia as one of the main reasons some libraries are still building and maintaining their sites by hand -- despite, like our listserv example -- the fact that we have CMS tools to help us with the heavy lifting.

So I read "Untangling a Tangled Web" with great interest. The authors cite "the need to make maintenance quicker and easier, as well as a need to position the web site for future development and expansion" as two challenges driving a shift toward implementing a CMS -- worthwhile goals that would inevitably need to be measured against the challenges inherent in a major overhaul of Wheaton College Library's website.

The case study affords readers the chance to take a peek (albeit an edited and distilled peek) into the processes involved in the decision. What we see documented here is a fairly typical process -- review, testing, review, testing, implementation, testing, troubleshooting, the dreaded upgrade, and more troubleshooting. The authors identify speed bumps along what, in comparison to what might have gone wrong, seemed relatively manageable -- if tedious and frustrating. If that sounds flippant, it's because I think we need to allow for all kinds of obstacles and tedium in our planning. The authors affirm as much in suggesting that they should have "expected the unexpected" in the "What Could Have Been Done Differently" section. Most of the other comments refer to needing to tap into the user community, ensure clear communication, and (again) anticipating a steep learning curve.

While the narrative approach here is useful, it might also be interesting to see a graphical representation of the planning process that compares the initial timelines with the actual timelines. For example, I'm curious about how the review process got backed up and how far that backed Wheaton up to the launch of the new upgrade. It seems to me that if the time between the implementation and the rollout of the upgrade/overhaul, it might have made more sense to wait it out and work with the new version exclusively.

This running theme -- plan for a shitstorm -- might be the singlemost important reason for libraries to consider and choose open source options when exploring CMS options. There will inevitably be hiccups in any technology transition, but the ability to weather those storms (and prevent future ones for others) is exponentially better in the open source community. With the advent of so many smaller operations offering support for open source software and the right community of practice using a given system, old arguments based on the technical support for proprietary solutions hold less weight than they used to.

Revisiting DiPRR

I'm revisiting a project that I began thinking about in the Digital Preservation course last Spring. I posited the creation of a Digital Preservation Resource Repository (DiPRR) -- essentially an archive of published resources on digital preservation. By "published" I mean anything that was written/produced/recorded and made publicly accessible; which includes blogs, podcasts, white papers, journal articles, and the like. I've compiled a small corpus of resources that represent not only some of the key issues in digital preservation, but also range in formats from PowerPoint presentations, PDFs, mp3s, and web pages. Because web pages represent their own preservation challenges, I may end up dropping these from my collection, but we'll leave them in the mix for now.

The resources as a whole represent best practices, case studies, theory, and workflow management. My initial thought is that I'll be categorizing them with a flexible taxonomy much like what I'm using with for Delicious collection I've been building at my job. This allows at least an entry point for resources that may also be tagged with useful keywords or subject tags.

Now ... Where Were We?

There's not much to see here now, but just you wait.