The Tears of Toil

Our class continues to explore repositories for our collections. Since I last reported in I've worked with DSpace and Omeka. Once installed, the differences between them were few though. (There are still unresolved issues with thumbnails in DSpace but I believe that it is a programming issue that can be resolved.) Omeka seems easier to populate than DSpace. The distinction between the two is in the installation. In the past, the programs we have been working, such as DSpace with have been built "from scratch" onto virtual machines running Ubuntu server, hosted, in my case, in an XP environment. Though Omeka can be installed in what for this class has become the convention, we were asked to download a pre-configured virtual machine running Ubuntu desktop, containing Omeka, to open up in VM workstation. Once open on the Ubuntu desktop in Firefox I was ready to enter my collection. This made the sometimes onerous network configurations and command line entries that caused me problems in DSpace, unnecessary. Like other programs, Omeka is configurable through the terminal application on the desktop as is DSpace.

Is the preconfigured solution better, is there more time to concentrate on collection building instead of what amounts to programming? Are opportunities lost in understanding how a repository is structured? As far as missed opportunities go, in a preconfigured solution, there can be an assignment to look at the repository structure by looking at various files that make the program operate the way it does. The lesson is still there on what the underpinnings of the repository are without the time and frustration of getting the program installed and up and running. It is the time factor that makes the preconfigured solution more desirable. I spent almost two weeks trying to get DSpace running only to find out that my vision isn't what I thought it was; I swore that the 5 was an S. There was also a lot of time spent getting Drupal and Eprints working in a usable way. There is a sense of satisfaction once it was operating but it put me behind in this course and in 671. Given the amount of time we have I think that a preconfigured solutions is more desirable.

Does the preconfigured solution affect what we learn? Of course, and it also shapes the material being taught. As it stands now, directly installing three different repository programs, we are learning essentially about programming and configuring programs. This makes us a bit more marketable that we have some knowledge to troubleshoot and configure these popular repository programs. The only repository software, I think, that has wide spread use we didn't look at is OCLC's CONTENTdm. The reason is, I would guess, is that it is proprietary, and would have to pay a fee for its use. The course objectives would be different if we moved to preconfigured gnomes for each repository I believe that more time could be spent on the prototype collection, its accompanying metadata and general theory. This approach might mean fewer hands on experiences and call for a different skillset in the choice of faculty.

It seems that I'm in support of having the repositories preconfigured in virtual machines. That isn't totally true. Being able to create a new machine and install software is more my style. I usually don't shy away from new technologies. There is something very satisfying when the installation works as expected. I had a few of those moments, sometimes weeks after the due date but had them none the less. Though I got the repositories up and running, there were unresolved problems, the search in Eprints, the thumbnail problem and missing metadata fields in DSpace and modules not working in Drupal (see Oct. 7, 2008 post). Omeka, preconfigured, had fewest problems. I wonder if I built Omeka from scratch would I have any difficulties past the command line typos. I'd like to believe I wouldn't.