For this unit, we installed a new VM to use the DSpace digital repository software. It was a pretty similar process to the other Ubuntu Server VMs that I’ve created for this class and 672. The notable additions were Tomcat and PostgreSQL.
It was very easy to follow the installation instructions. The only thing that I fudged was instead of creating a file on my primary system and using Fugu to transfer it to the VM (I suppose I could have used scp, too, but I never remember the right way to do those filepaths — any constant blog readers wanna help me out?), I just used Nano on the VM. I suppose the reason the instructions didn’t say to do that is that there would be no way to copy and paste the text in the config file directly from the host machine to the VM. Luckily I was using ssh to make copy/pasting a bit easier, so that wasn’t an issue.
When I looked over the alternative installation instructions (https://wiki.duraspace.org/display/DSPACE/Installing+DSpace+1.7+on+Ubuntu and http://wiki.lib.sun.ac.za/index.php/SUNScholar/Dspace), they seemed pretty similar. There were some small differences. For example, the former used a different version of Java, and the latter used the command line to do all the user configuration. Overall, though, it seemed like a very similar process. Since those instructions are both easily found online, I’m pretty sure I would be able to do an installation of DSpace myself at a later time by following those instructions.
For this week’s assignments, we spent some more time installing and configuring Drupal modules. One of our assignments was to choose our own module to install. I chose Print (http://drupal.org/project/print), which allows someone visiting your Drupal site some convenient buttons for saving content on a page (print, save as PDF, or email options). I thought this would be well-suited to a collection that’s writing-focused. However, a snag is that since I chose to upload files to my Drupal database, the actual site doesn’t really display the files — you have to download them. I guess in the real world, people would really want their writing files to be visible on the site itself, and might be more likely to copy/paste the text itself into the post in the content type, rather than attaching a file.
Installing it was a breeze — I just used wget to download the module in tarball format from Drupal’s FTP server, and then used the “tar” command and then the “mv” command to unpack it and sent it to my site’s folder on my VM. (Just an aside — isn’t wget kind of like magic? I often use it instead of GUI to download files on my Mac when something gets stuck halfway through a download or whatever.) It wasn’t very hard to configure — I just went ahead and allowed all three options.
This week has been a bit gentler-paced, which I appreciated! I enjoyed using Drupal to enter my initial items in my digital collection. I found it to be pretty similar to what I did last week. Although one of my classmates found it too “bloggy” for her collection, I actually find my particular collection (my personal writing files) to be well-suited to a blog format. Since I had just been using a (different) WordPress blog for (some) of those files in the past, categorizing them and deciding where different items fit on the taxonomy wasn’t too hard of a task. I could see it being more difficult with multiple users, though. On the other hand, the nice thing about Drupal is that even if users disagreed on, say, where certain content should be located on the site, it is possible to just have the same information show up in multiple places at once, and there’s only one version that can get edited and updated as needed. That seems to be a big problem with large sites — too many things are in multiple places, and when something gets changed in one place, whoever’s updating that content in that place might not even know about the other place.
The only thing that was a bit tedious was, again, because there’s a lot of information that seems redundant to me since it’s just my stuff (like putting my name as author over and over again). But as we’ve been learning in the management readings, doing the bare minimum of metadata on a collection makes it less interoperable with other collections, so there is a fair amount of data entry work. Another thing I really like about Drupal is that someone without any web design background can do this work: it is very successful in divorcing the form from the content. It also has mechanisms to allow review by someone who’s in charge of content before new content goes live, gets deleted, etc., which again are a bit redundant when it’s just me working with my own stuff, but is definitely a useful feature in the real world.
This week’s assignments were an interesting mix of theory regarding managing digital content, and practical readings and assignments focused on JHOVE (JSTOR/Harvard Object Validation Environment: pronounced “jove”), which is a framework for format validation, and Drupal, an open source content management system (CMS). I’d gotten to play with Drupal a little bit in the past, so it’s been interesting learning more about it, and although I knew absolutely nothing about JHOVE, I imagine I’ve used it unawares when I’ve searched, say, the JSTOR database.
One of our reading assignments was to skim the 2006 Library Hi Tech issue (Issue 1) focusing on CMS issues in the library world. The article that I chose to read in-depth and discuss on this here blog post was “Beyond HTML: Developing and re-imagining library web guides in a content management system” by Doug Goans, Guy Leach, and Teri M. Vogel.
I found this article especially pertinent to my volunteer project last semester, helping with the CCP’s website redesign. Previous incarnations of that website had suffered similar problems to the ones described by the authors, of each author of a particular page (especially the online exhibits) simply creating their own page, with its own unique (and more- or less- usable) fonts, color schemes, and pathways, rather than making sure that everything cohered to a style for the site as a whole. The CCP was eventually redesigned using Drupal, but reading about GSU’s choice to use a custom CMS based on ASP and MYSQL was very interesting to me, since their concerns with integration with Microsoft products, like IIS, would definitely be shared by the team who develops the website for my library system, the Pima County Public Library. Just because the open source solution worked for the CCP does not necessarily mean it would play nicely if PCPL decided to migrate to Drupal. (Although, and perhaps this is something that will be covered in future classes, I believe that Drupal 7 does integrate better into non-open-source environments than previous verisons did.)
In any case, it was clear that GSU’s decision to use a CMS led to greater consistency and usability across their site, as well as making the content editable by a variety of people who would not have had the skills necessary to manage the form.