Sunday, October 31, 2010

8a - EPrints Install


I wish I could have recorded my description of my EPrints install that I told Bethany this week. I was lucky enough to cover a shift at a different library branch and so happened I was able to meet one of my classmates.

As usual, prof. Fulton's notes are very detailed and very precise about how to install step by step. My trouble this week did not come from the installation necessarily, but in the configuration phase. The user profile I created to admin the EPrints repository was without a password. This is documented in the install guide. We were to use sudo su eprints to begin configuration in the eprints directory. Whatever commands I attempted to run, the server kept demanding a password for eprints (which didn't exist). Other students had the same problem (or just confusion?) and documented it in the technical discussion forum. I thank them for that, but where those students had epiphanies, I was still lost. I could understand that eprints is not a sudo user, but that did not solve my trouble that the server insisted on the password. Again, as usual, I decided to start over from scratch the next day to better understand each step I took. Due to luck and persistence, I side stepped the problem and continued configuration per the documentation.

Comparing visual customization against DSpace and Drupal is difficult, since I hardly changed aesthetics on those installations. I can say that swapping the EPrints logo was easy and the documentation on altering html/css in EPrints looked quite straightforward.

Thursday, October 21, 2010

Unit 7 - DSpace Cont.


I can see the value that both Drupal and DSpace bring to digital collections. Each has its own drawbacks too. The purpose of a project would determine which one is better suited to that collection. Drupal, for lack of a better word, is more casual. Yes, the administrator can create strict permissions for which users are allowed to post, edit, and delete in each sub-collection. But monitoring posts comes after they have been published to the site whereas DSpace has the ability to configure a structured review of posts before they are made. It is akin to having an editor go over the work before it is posted. This is just one example of how the purposes for which each of these applications were developed differ from one another. Drupal's ability to add thumbnails makes the collections and communities more blog-like. DSpace's workflows, Google interoperability function, and Dublin Core metadata standards which all work "out of the box" remind me more of an online database such EBSCO where context is sacrificed for control.

Since my collection is more like a sample of course documents a French teacher might post for a class and expect students to use as a one-stop place for that course, I can sacrifice the bit-level checksums, file format conversions, workflows, metadata control, and Google scholar "push" cataloging that come with DSpace. Instead, I am gaining a more visually appealing, community tagging, user commenting, and modular application that may take more effort to configure, but ultimately suits my purpose better in this instance.

Wednesday, October 13, 2010

Unit 6 - DSpace Install


The DSpace install took some time. I was caught off guard by how long the Maven package took to install. I would definitely need to follow a tutorial a couple more times before I felt comfortable doing the install without step-by-step instructions.

I have to say, DSpace was much more functional "out of the box" than I remember Drupal. There was much more configuration to be done with the Drupal install, "go to site building, configure, save, go to site configuration, configure, save, go to site building, etc." DSpace was ready to go with Dublin Core metadata prompts by default. If someone were unable or unwilling to take the time to configure Drupal with all the modules needed to function as desired, then DSpace would be the obvious choice. A user can practically just install it and start adding communities, collections, and items. The new user training units are a great resource for getting started.

Now that I have a small collection of my French lesson recordings entered, I would benefit from going back over the new user training to fill in the gaps that were a little foreign the first time through. Like Drupal, I am afraid that this software takes little time to begin using as an amateur and promises to take lots of time and energy to master. The volume contained in the DSpace Manual is intimidating or it could just be the "wall of text" that is the table of contents.

Tuesday, October 5, 2010

Unit 4 - Drupal Cont.

This week, you might choose to comment on how suitable Drupal might be for your collection. Begin to develop some criteria you would use to judge how well an application such as Drupal meets the needs of your collection and its users. We will expand on this problem over the semester.

It seems that the advantage of Drupal is, in short, management. In order to benefit from the management features, there need to be contributors. Hopefully, if building a digital library of items, people would not be assigned such a project alone, so I see Drupal being very beneficial for any project involving several contributors and regular updates.

My collection is a small sample, so it is difficult to see the benefit in the case of fifteen items which will remain static so long as I am the only one working on it. Features in content management, user management, and site building do show a great deal of flexibility. I can regulate which authenticated users control precisely which actions (e.g. creation, editing, deletion) in precisely which areas of expertise (e.g. planes, trains, automobiles, you name it, etc). Modules create even more options to explore, but from those that I used (date & cck), they were options which I could already control from site building. Well, the modules do speak for an active community of developers and certainly contain useful tools (if you can find them).