I chose the following OAI Services to review:
1) OAIster http://www.oaister.org/
I think that OAIster is one of the largest OAI Services with 1034 contributing members.
2) Sheet Music Consortium
http://digital.library.ucla.edu/sheetmusic/
The Sheet Music Consortium is a collaboration between UC Los Angeles, Indiana University, Johns Hopkins University and Duke University.
3) Australasian Digital Theses Program http://leven.comp.utas.edu.au/AuseAccess/pmwiki.php?n=Activity.ADTP
"The majority of Australian universities are signed up and deliver thesis metadata to the [[http://adt-beta.library.unsw.edu.au/|ADT Program gateway]] at the University of New South Wales, while in late 2005 New Zealand also agreed inter-nationally to feed theses to the Program, making it the ''Australasian'' Digital Theses Program.The gateway (holding e-thesis metadata) is harvested by Google, Google Scholar, etc."
The primary criteria for a "good" federated collection is a clear scope and useful purpose. I feel these are important qualities for both the back-end institutions so that they can maintain a manageable and practical project as well as for end-users who desire quality over quantity. I am definitely a novice in the world of harvesting, but "quality over quantity" strikes me as a adage with near universal applicability. On the other hand, OAIster is a mega-service registry. I suppose that it serves a useful function in the harvesting world as the biggest, broadest federated collection. However, I think that for every one OAIster, there should be many more digital theses and specialized format or topic collections that feed into a meta-harvester; otherwise, the balance of expertise, quality control and project management might be tipped toward a circular, 6 degrees of seperation-type phenomenon with much redundancy and little value added.
Tuesday, October 28, 2008
Tuesday, October 21, 2008
Cataloging with EPrints
Well first of all, I must say that I enjoyed entering items into a digital repository using EPrints. The process was pretty straightforward and user-friendly. I especially enjoyed the automatic-fill feature that remembered previous field entries. I also liked the built-in LCSH feature for the subject headings. Overall, as I discussed in more detail in my discussion post for this week, EPrints mapped well to my application profile for my digital collection.
Regarding the question of consistency in my approach to cataloging using EPrints, I feel that the tight match between my application profile and the EPrints default categories and features was sufficient to ensure a reasonable degree of consistency among items in my repository The auto-fill feature ensures that I do not have redundant variations of the same name on the creator and publisher fields. I wish the auto-fill functionality could be extended to the keyword field as well, because this is the most vulnerable area of my cataloging approach in terms of consistency. The main problem I encountered in tagging the keywords for my items was the potential for alternate versions of the same word due to hyphenation. For example, I use the prefix "post" for several keyword entries such as "postmodern" and "post-custodial". In the word content of the items I think there is variation between the "post-modern" and "postmodern" spellings of the word. I tried to overcome this problem by entering both version of hyphenated words so that end-users will get the same result regardless of how they search. Another slight problem I encountered was the lack of precision in the built-in LCSH categories. The default EPrints LCSH are very broad--I suspect there might be a way to update EPrints with a module that would expand the LCSH so that I could label my items with more accuracy.
Regarding the question of consistency in my approach to cataloging using EPrints, I feel that the tight match between my application profile and the EPrints default categories and features was sufficient to ensure a reasonable degree of consistency among items in my repository The auto-fill feature ensures that I do not have redundant variations of the same name on the creator and publisher fields. I wish the auto-fill functionality could be extended to the keyword field as well, because this is the most vulnerable area of my cataloging approach in terms of consistency. The main problem I encountered in tagging the keywords for my items was the potential for alternate versions of the same word due to hyphenation. For example, I use the prefix "post" for several keyword entries such as "postmodern" and "post-custodial". In the word content of the items I think there is variation between the "post-modern" and "postmodern" spellings of the word. I tried to overcome this problem by entering both version of hyphenated words so that end-users will get the same result regardless of how they search. Another slight problem I encountered was the lack of precision in the built-in LCSH categories. The default EPrints LCSH are very broad--I suspect there might be a way to update EPrints with a module that would expand the LCSH so that I could label my items with more accuracy.
Tuesday, October 7, 2008
Unit5Assignment5--Drupal module install
After reviewing available modules from Drupal, my experimental content management system, I decided to download the "Avatar Selection" module. I chose this module because, at first glance, it seemed relatively straightforward. It did not have any dependencies with other prerequisite modules. After I installed the module, I discovered otherwise during configuration in the Drupal interface.
I downloaded the module using the VMWare CLI to 1) download the tar file, 2) unpack the tar file, and 3) move the unpacked file to the /var/www/drupal/modules directory. This went well. Afterwards I went to the Drupal GUI and activated the module under Administer >> Site Building >> Modules and checked the "Avatar Selection" box under "Other". After enabling the module, I got a message in green text at the top notifying me that I had to enable the "Picture Support" setting at Administer >> User Management >> User Settings. So after I did that, I needed to create a directory in Ubuntu using VMWare to hold the pictures that users select for their avatars.
I had to look back at the instructions for the Image module installation to create a storage directory. The commands were as follows:
$ sudo mkdir /var/www/drupal/sites/default/files/avatar
$ sudo chmod o+w /var/www/drupal/sites/default/files/avatar
After creating the directory, I tested the avatar selection module by selecting the URL pathway to a default image for users. The image I chose was a JPEG of my Italian Greyhound, Coco. I copied and pasted the URL from the JPEG had posted earlier using the Image module into the "Default picture" box. I also increased the maximum file size and picture dimension settings, just in case. The module seems to have worked because when I click on "My Account" my user profile now has my dog Coco as the avatar image.
The Avatar Selection module does not necessarily enhance the search or retrieval capabilities of my digital collection, but it does add some style and user interaction to the interface. I consider this part of personalizing the collection building process and user interface, which is fitting because my digital collection is inherently personal as it is self-archiving of my own portfolio of graduate work.
I downloaded the module using the VMWare CLI to 1) download the tar file, 2) unpack the tar file, and 3) move the unpacked file to the /var/www/drupal/modules directory. This went well. Afterwards I went to the Drupal GUI and activated the module under Administer >> Site Building >> Modules and checked the "Avatar Selection" box under "Other". After enabling the module, I got a message in green text at the top notifying me that I had to enable the "Picture Support" setting at Administer >> User Management >> User Settings. So after I did that, I needed to create a directory in Ubuntu using VMWare to hold the pictures that users select for their avatars.
I had to look back at the instructions for the Image module installation to create a storage directory. The commands were as follows:
$ sudo mkdir /var/www/drupal/sites/default/files/avatar
$ sudo chmod o+w /var/www/drupal/sites/default/files/avatar
After creating the directory, I tested the avatar selection module by selecting the URL pathway to a default image for users. The image I chose was a JPEG of my Italian Greyhound, Coco. I copied and pasted the URL from the JPEG had posted earlier using the Image module into the "Default picture" box. I also increased the maximum file size and picture dimension settings, just in case. The module seems to have worked because when I click on "My Account" my user profile now has my dog Coco as the avatar image.
The Avatar Selection module does not necessarily enhance the search or retrieval capabilities of my digital collection, but it does add some style and user interaction to the interface. I consider this part of personalizing the collection building process and user interface, which is fitting because my digital collection is inherently personal as it is self-archiving of my own portfolio of graduate work.
Subscribe to:
Posts (Atom)
