Off
Posted: 2012/04/27 Filed under: Uncategorized Leave a comment »There are days when I want to post, but I don’t know what to say.
Unit 13: End-of-Semester Reflection
Posted: 2011/11/20 Filed under: Uncategorized Leave a comment »After thirteen weeks of trials and travails, this class is winding down, and it is time for reflection.
For me, this class was not about new concepts. I did learn how to complete small tasks, but understanding the big things–metadata, repositories, management, and virtual machines–happened in my earlier DigIn courses. This course was where we finally took all those concepts and put them into practice. While not as rigorous as creating a production repository for a museum or university, actually carrying out tasks like selecting a metadata schema and controlled vocabulary for a repository instead of theorizing on how I might do such a thing required me to think, plan, and deal with details in a way that I never had before.
The other thing I learned in this class was that the quality of a repository cannot be determined from a single perspective–end user, depositor, or site administrator–nor can quality be determined by a single attribute–number of schemata supported, ability to organize along organizational structure, kinds of customization available. Every aspect of a repository, from how easy (or difficult) it is to install to how easy it is to migrate to a new repository. Easy installation was important for me, but I also needed comprehensive and easily understandable software documentation. My collection also needed a repository with easily modifiable input forms, an attractive display, and tools that would allow users to contribute metadata to the collection. As I attempted to make my collection “fit” with various repositories, I learned that finding a package of mostly desirable attributes with only a few undesirable attributes was quite difficult.
I am definitely not done learning about repositories; I doubt that I will ever be done. But looking back to where I was at the beginning of the semester, I am pleased to realize my knowledge of repositories has made a big leap from where it was before.
Unit 12: Benefits or Drawbacks of Pre-Installed Virtual Machines
Posted: 2011/11/13 Filed under: Uncategorized | Tags: institutional repositories, virtual machine Leave a comment »This week winds up our work building and configuring virtual repositories, and we were asked to consider the possibility of creating collections in a pre-installed virtual machine instead of building the machine and the repository. My own preference for learning is to do everything hands on. My persistence (or stubbornness) when it comes to troubleshooting and my desire to know _why_ came in handy when building repositories from scratch,
but sometimes my desire to understand was held back by my middling computer skills.
These preferences aside, there are several reasons that I would argue that using a pre-installed virtual machine in order to allow students to focus on building collections would be less beneficial, not more beneficial, when the end goal is to give students a strong understanding of repositories.
First, students lose out on a more holistic understanding of how a repository is built when they work only with pre-installed virtual machines. Assuming that most DigIn students come from a library background, a weaker understanding of the technical aspects of repositories would negatively impact the ability of the student to work with IT professionals in building repositories, which runs counter to the goals of the DigIn program.
Troubleshooting a VM that I had installed myself, and consequently had some rudimentary idea of where to look for issues, was difficult and time-consuming enough. If troubleshooting a virtual machine with the repository software pre-installed can be more difficult, then the time savings–the stated purpose of using a virtual machine with pre-installed software–is lost.
Third, by installing and configuring the repository softwares myself, I learned that the repository and the collections it holds cannot be considered separately. With each installation, I had to determine whether my custom metadata fields and controlled vocabularies could be added. If some of the repositories had been production repositories, I would’ve had to add even more metadata, because some repositories did not allow users to add metadata.
Finally, the more opportunity students have to interact with repositories, the better equipped they are to critique repositories and make well-informed decisions about what repository is “best” for any given collection.
Unit 11: Repository Home Sites
Posted: 2011/11/07 Filed under: Uncategorized | Tags: Drupal, DSpace, EPrints, JHOVE, OAI, Omeka, PKP Leave a comment »Here we are in week 11, on to another repository software. At this point, we were asked to review the homepages for the various repositories and other kinds of software we have used this semester. There is a lot of variability in the appearance, organization, and content of the websites, as with the softwares themselves. However, this correlation was not always exact: JHOVE was a relatively easy-to-use software, but its website made the software seem more daunting and difficult to use than it was.
Consequently, judging a repository software exclusively by its website is not an entirely accurate way to determine the quality and usability of the software. The software’s website is the portal to software help and documentation, however, and as such, it should be welcoming, usable, and contain the content that the software’s users will need to answer their questions, be they new to repository technology or old hands experimenting with advanced features.
Omeka
This website is well organized, with an appealing layout, and clearly explains the repository. The help documentation is also well-organized and covers the main topics new users will likely need to know.
OAI PKP Harvester
Website has a clean layout and well-organized information, but users must navigate several levels down in the website to actually get at any of the documentation
EPrints
The layout is decently clean, and content is reasonably well-organized. The repository help is stored in a wiki, which normally I appreciate. In this instance, however, the wiki’s appearance of helpfulness contrasts with the actual experience: the wiki is actually difficult to navigate and find information in.
DSpace
The layout of the DSpace homepage is clean and appealing, and content on the website is logically organized. Unfortunately, there is so much information on this website that it is very overwhelming to search, and there is a gap between the basic, high-level “getting started” material and the extremely technical content on the wiki.
Drupal
The Drupal website has a tidy, bright, and well-organized homepage. While the site contains tons of information, the basic information pages contain links to related advanced topics, facilitating navigation. User comments on the content of pages is useful as well.
Jhove
The homepage and entire website are clearly organized but text-heavy and aesthetically lacking. Worse, the website does not make the JHOVE validator easy to understand. Another turn-off for me was that the “Community” is a mailing list. I really dislike mailing lists.
Unit 10: OAI Service Providers
Posted: 2011/10/30 Filed under: Uncategorized | Tags: OAI, PKP Leave a comment »Week 10 is here, and we are careening into OAI harvesting. After turning our own virtual machines into little OAI service providers using the PKP application, we checked out other OAI service providers.
scirus for scientific information only (http://www.scirus.com/srsapp/)
I found this search site very well done. The interface isn’t pretty, but it has a lot of functionality. Users can go to the “About” page and see where the service gets its records from (the web, Medline, MIT OpenCourseWare, PubMed Central, among other sources). Before beginning a search, users can also set preferences, which include the ability to display partner links. I chose the American Museum of Natural History, and a link to their catalog displayed next to every journal article that the AMNH library owns. Users can also sort results by relevance or date, and limit searches to journal articles, websites, etc.
In the results list, the record’s source appears underneath the title and summary. I appreciated that I didn’t have to click away from the results list to find where a particular record was coming from.
Sheet Music Consortium (http://digital2.library.ucla.edu/sheetmusic/)
This service provider offers a beautiful interface and functionality too! From search box on the the homepage, users can limit their search to names, subjects, place, publisher, and digitized sheet music. The site also has an advanced search which, among other things, allows users to search for items from a specific collection. I was quite taken with the “virtual collections” feature, which allows users to drag and drop records from search results into a little floating menu, and from there, e-mail the records or (if one logs in) save the virtual collection. Virtual collections can be made public, so other users can visit the Consortium website and view the collections others have made. This would be a very useful feature for music teachers to use.
OAIster (http://oaister.worldcat.org/)
OAIster is basically WorldCat’s interface: clean, with lots of options to focus the search (format, author, language, year, etc). The results list does not show the institution that the record came from, but this information has its own section on the individual item records. For me, the roomy, ordered results list makes up for the slight inconvenience caused by not having the contributing institution listed on the results list.
Unit 09: Cataloging and Metadata Consistency
Posted: 2011/10/21 Filed under: Uncategorized | Tags: Dublin Core Leave a comment »My collection only addresses consistency in the controlled vocabularies. My sweater style terms are drawn from the Getty’s AAT, and the names I use to describe synthetic fibers come from “A Quick Guide to Manufactured Fibers,” produced by the American Fiber Manufacturer’s Association. However, the metadata fields I chose to use for my collection are not drawn directly from standard Dublin Core, and I am reminded of how much my collection’s metadata diverges from the “standard” every time I try to fit my collection to a new repository software.
Part of my intention in choosing the metadata fields that I did was to provide a core body of information that, in a production environment, would allow information professionals to track objects and identify them reliably without becoming cumbersome. A collection of sweaters could be relevant to museums with fashion collections, students of fashion design, and knitters. My hope would be that, in a production environment, users from these diverse backgrounds would contribute descriptive terms that would encompass the diverse terminology from each of these fields. From my experience as a crafter, there is a certain amount of variability in the terms that are used to describe garment styles, and the rapid pace of the fashion world ensures that new styles with new names are constantly appearing. With users contributing descriptive metadata, I think the metadata would better reflect the diversity of terminology used by the different fields that a collection of garments would be useful to.
Of course, tapping user knowledge does not mean that the librarians curating a collection like mine in a production environment would be able to step back from the collection after the core metadata was added: building a dedicated user group would require an investment of repository staff’s time and also funding for advertising.
Unit 08: EPrints and Branding
Posted: 2011/10/16 Filed under: Uncategorized | Tags: Drupal, DSpace, EPrints Leave a comment »We are officially at the halfway point of the semester. It’s hard to believe, but my classmates and I have a new demo repository to prove it: EPrints!
EPrints was, for me, a pretty simple install. However, throughout the class, the CMS/repository software has been less of an issue than what also happens to be happening as I attempt to install and configure my repository. During the Drupal configuration, I was on vacation, connecting to the Internet via a hotspot set up on a phone, and generally working far too late at night. DSpace was installed and configured during two weeks where homework time seemed to come in increments of 30 minutes or less. For my EPrints installation, I was simply trying not to repeat the same mistakes I had made during the previous two installations.
As a repository, EPrints is very similar to DSpace. Both repository softwares come out-of-the-box with a structure meant to mimic the structure of universities, and the deposit process is designed to ingest and describe text-based resources, especially preprints, sprints, theses, and dissertations. Drupal is a CMS, not strictly a repository software, hence it’s odd-one-out status.
After my time-consuming DSpace configuration fiasco, I was less gung-ho about configuring EPrints. To customize the repository branding, I changed the messages in the Welcome and About sections on the EPrints homepage. I also installed the Social Network Extensions for Eprints (SNEEP) app from the EPrints Bazaar. Thankfully, all these proved to be foolproof changes. Fingers crossed that uploading items goes so smoothly!
Unit 07: Outside the Box
Posted: 2011/10/11 Filed under: Uncategorized | Tags: institutional repositories, Ravelry Leave a comment »The unit on DSpace is winding up. I for one am glad: I had attempted to get fancy and do some configuration, which did not work well at all. If we were continuing on with DSpace, the daily reminders that that one form was not doing what I wanted it to would be too much for me, and I would have to keep fiddling with it, which would only lead for more frustration and repository angst.
There are plenty of sources of repository angst this semester: after working on our own demo repositories, we read about institutions’ production repositories. These are inevitably facing a Difficulty of Epic Proportions, be it short-lived funding or lack of institutional support or a guiding document with a fatal omisson.
Whenever I am feeling disheartened by any of this, I go to a repository that does not have any of these shadows hanging over it: Ravelry. On the homepage, Ravelry identifies itself unassumingly as “a free site for knitters and crocheters.” While Ravelry is a website, and its intended users are knitters and crocheters, it goes far beyond that.
Beyond the login page, users will find that the site is divided into several areas: Patterns (a pattern database and repository), Yarns (a yarn repository), People (a database of users), Forums, Groups (a directory of all groups created by users), and, last but definitely not least, My Notebook (all content you, the user, have created, be it a list of knitting patterns or yarn you own, projects you are working on, or friends you have on Ravelry).
Although no librarians helped plan Ravelry, it has many resemblances to the kind of environment librarians are trying to create with institutional repositories and VREs. All the separate parts of the site are integrated, so a user can begin on the forum, skip to a friend’s notebook to view a project she’s knitting, then link to the page for the pattern, and from there view everyone who has knit that pattern, read every comment, blog post, and forum post associated with this pattern, and even look at recommended yarns. Users, be they professional pattern designers, longtime knitters and crocheters, or newcomers to the hobby, contribute most of the content. Ravelry has barely half a dozen employees, and an army of volunteers assist ensuring the quality and accuracy of the content. Finally, in spite of the complexity that results from such rich, varied, and interconnected information, the interface is intuitive and seamless.
Getting bogged down by our immediate surroundings can happen easily; I’m glad that there are resources out there, like Ravelry, that have the same values as library repositories and VREs, but are different enough that they can offer inspiration for ways libraries can bring their ideas to fruition.
Unit 06: DSpace Install
Posted: 2011/10/03 Filed under: Uncategorized | Tags: DSpace, PostgreSQL, Tomcat Leave a comment »Moving along rapidly, the class has now switched from Drupal to DSpace. I am quite happy that the initial installation went pretty smoothly; there was a small mishap partway through the installation (user error, I expect), but I had been making snapshots of the virtual machine. Rolling back to an earlier installation and working from there got everything back on track!
Aside from this little hiccup, my initial installation was successful. I definitely would not have been able to do this installation without the detailed instructions provided in Course Content, but I was able to see what was happening at each stage of the instructions. Of particular interest were the steps in the installation devoted to setting up the server software; Drupal is built off the standard LAMP stack, which is installed along with Ubuntu, while DSpace uses Tomcat for its server and PostgreSQL instead of MySQL. Again, seeing it once certainly won’t make me expert enough to install and configure a LAMP alternative without help, but seeing yet another variation on the means to the end (a working repository) gives me a better sense of the scope of the world of CMS and institutional repository software.
Unit 05: Modules
Posted: 2011/09/26 | Author: Allison | Filed under: Uncategorized | Tags: Comment Notify, Drupal, Modules | Leave a comment »In unit 5, the class touched on advanced Drupal techniques, including Modules. I was thrilled with the modules, especially the Custom Control Kit, because these gave me the ability to do things with my collection that I wanted to but couldn’t with just a basic installation.
The assignment to choose and install a module that would make our collection more useful was tricky, however. I felt like I could have used at least two weeks to learn how to use the modules we had already installed to their fullest extent. Not knowing what sort of functionality I might already have without realizing it, searching for a module that would add more functionality was a challenge.
I settled eventually on the Comment Notify module. While a very small addition, I knew it was within my capacity to install. If my Drupal project were to go live, and have a group of users, the Comment Notify module would facilitate “conversations” among users via comments.
To install Comment Notify, I swapped out the information for that module in the class instructions for installing the CCK module. All went smoothly, but a pre-existing issue with e-mails (Drupal does not want to send them to my student account; I do not have the expertise or time to figure out why) prevented the notifications of actually being sent. This underscored my takeaway message for this unit: there will always be more to learn.