IRLS 675 Unit 11 part 2

Personally, I think that all of the installation and configuration done in 672 and 675 is very valuable. It may be from my desire to know how things work. However, if one would end up at a small library, you may need to do this yourself to get a small digital archive project up and going. Also, this information would at least give you some idea if IT people are trying to snow you with over estimates of time and cost to set something up. And you would also get an understanding of any problems they might be having.
I think even though it is brief(I barely remember some of the experiences with some of the software and have to go back and refresh my memory of them), I think we get enough experience with the various repository software. After entering a certain number of items, one gets the idea of how it is going to work. It would be helpful if all or most of them could be running side by side. That would be the easiest way to compare their function.

IRLS 675 Unit 11

I think they are all very useful for digital archiving, especially for those organizations on a tight budget or smaller organization. They can also be used by big organizations too. I think dspace would be the best for ingesting large quantities of data and linking remote organizations together. For more focus on meta data, omeka and drupal would be best. As I've said before, since drupal is more a general library product, it has more features than are really needed for most digital archives. I liked dspace and eprints for having the configurable approval process for someone to look over the submissions and give the okay before a submission is put online.

Usability and searchability are very important also. You need to people that are going to want to use them. I don't recall any of them as being difficult to browse or search with. omeka was one of the more inviting ones from my point of view as far as the layout and the thumbnails being shown. dspace was the one that has the least appealing appearance if I remember correctly.


Standards are important, and to have a standardized way to harvest meta data is a very good thing to have to be able to make more archives visible to the maximum number of people. jhove is also important to make sure that your archive records are in a standard form that can be used by the most people and will likely be standard for years into the future.

IRLS 675 Unit 10

Looking at University of Arizona's Institutional Repository, I did a search on “Auto” and the first entry was “The Low Rider Ritual: Social Mobility On Wheels”. It was easy to see it came from the “Arizona Anthropologist” collection. It can be useful to search this collection, but it is so diverse that there may not be many collections that overlap in their subjects. So having them all together may be convenient, but it may not yield any results from multiple collections. Another one I looked at, the Perseus collections. It was easy again to find which collection a particular item was from. This collection is more homogeneous, being texts and other artifacts from antiquity. So I was able to find things from multiple collections using a single search term. The third one I looked at, Norwegian Open Research Archives, is similar to Perseus in that the type of information is similar and I am able to search for a term and get information from multiple repositories. The archive is listed next to the item.

Regarding oaister.org, this is good if you want a site that you can search on a large number of repositories. It would allow you to find a large number of items if that is what you are looking for. The negative can be the large amount of information that can be returned and the amount of time it may take to search. Looking through the large amount of information and trying to make sense of all of it may be a problem also. It is like what you have to deal with when using google’s large amount of information.

IRLS 675 Unit 9

My collection of images is pretty straightforward. The topic is images of music collectibles. The image is either a photograph or an image of some kind of music collectible. So it is easy, I think to be consistent in my cataloging. Keywords are usually the artist, year, type (program, ticket, CD, etc.), Title of Album if it has something to do with an album or its tour, and whether it includes an autograph. So the information can be entered straightforwardly and consistently, I believe. I have not worked in a library yet so I have no real world experience on cataloging or anything like that. So I have to go on what I know so far.

I used all those as keywords in DSpace, which I believe was a time saver while still being complete. So DSpace would be the cheapest solution for me because of the straightforwardness of its operation with my collection and also the completeness, without too much extra that I do not use.

IRLS 675 Unit 7

A concern I have is the amount of different software packages there are out there and the fact that institutions, like Stanford are still creating their own digital repository software. To me, this leads to a lot of inefficiency and waste. I know that the technology has not matured yet and at some point I would think there will be market consolidation. But right now, especially with budgets being tight, institutions need to really think about using something that is off the shelf, rather than developing their own. Stanford is doing that now with their second generation plan. I think more institutions, if they haven't already, will leverage their plans off of one of the existing software packages. This will hopefully improve the existing software and bring total costs down, while still allowing for innovation.

IRLS 675 Unit 6

The install went pretty well. It was another long one. I missed the sentence about the password should be dspace or I would need to change it in that configuration file. So I had to go back and start from an earlier snapshot and start from there, first changing the dspace password, then starting maven over. So that took some time. The instructions were good as usual. I am usually able to follow them easily unless I am in a hurry and miss something. Even with my background in software engineering, I did next to nothing with installing and configuring any applications on any of the flavors of unix I used. So I would probably not be able to do this myself without learning more and asking for help.

IRLS 675 Unit 5

I added the "site map" drupal module. I first wanted the Google Analytics but I needed to create some kind of tracking id for google and I was having trouble logging into my google account so I abandoned that one. There wouldn't be that much usage to track anyways. Normally I think tracking would give good feedback of what people like and don't like.

I like what the site map does, mapping out everything on my site in various subject headings and lists all of my object meta data fields and their members. It also has RSS feeds. Pretty simple module as far as enabling and configuring. I just followed the installation instructions exactly and made it available to everyone and it worked. It gives me a better visual picture of what is contained in my site and helps me understand drupal more.

IRLS 675 Unit 4

I see my collection as much like the Arizona memory project. Both contain a lot of images of various things. I like the way the AMP was set up and since they use Drupal, my collection of images of music items can be set up much in the same way. However, the way my stuff is displayed by drupal right now is not that great. you have to click on something, then click on its image to get to see it. On AMP, the images have little preview icon images you can see that is more aesthetically pleasing. Mine does not. I looked around a little to see how that could be done but couldn't find anything. Maybe a little bit of PHP is involved.

IRLS 675 Unit 2

I read "Luwak: a content management solution" by Matt Benzing. It discusses a content management system called Luwak, that uses XML, a database, and XSLT, a style sheet language. That is what we are doing in the technology side of the class with Drupal. It was done at the Dressler Research Libraries for their online content. The idea was to separate the content from the formatting so that it is flexible to work on multiple devices. Handheld devices were the original catalyst for doing this. Traditional HTML webpages are slow and unwieldy on handhelds. Converting the HTML pages to XML had a few hiccups, including in determining syntax errors and spelling errors but overall the transition over to it went smoothly, according to the paper.

They also mentioned it was easier to maintain and support. They didn't even need style sheets for different browsers after trying the site out.

I've heard that story of Luwak coffee beans before. It still seems disgusting.

675 Unit 1

The collection I thought of is my collection of music related stuff. It is reasonably diverse, consisting of ticket stubs, autographed memorabilia, programs, T-shirts, special editions of vinyl records like picture disks and such. I have some of it up on my Facebook account: http://www.facebook.com/album.php?aid=6717&id=1726221208 http://www.facebook.com/album.php?aid=19703&id=1726221208 http://www.facebook.com/album.php?aid=12278&id=1726221208 plus, I'll see if I can get my concert programs from my ex-to-be and digitize a few of those. One could search by artist, type of item, year, whether autographed or not, scanned or photographed, if picture disk, and anything else I can think of in the meantime. People that are interested in that type of music, especially stuff from the 80's mostly are the people that would access it.