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.
Monday, December 1, 2008
Friday, October 31, 2008
Harvest
This week we are exploring harvesting metadata across collections with the goal of forming useful strong federated searches. I won't go into the difficulties of my own data harvesting experiences except to say; thank goodness it wasn't the corn crop or we'd all starve. That isn't said to diminish the usefulness of harvesting metadata and the concept of federated searches but only to state that I had trouble with the PKP harvester software itself. A lot of trouble.
Thank goodness for service providers, sites harvesting and storing metadata from various collections. I looked at four of these sites.
1. Sheet Music Consortium – The consortium is a partnership between John Hopkins University, UCLA, University of Indiana and Duke University Library.
2. Perseus- http://www.perseus.tufts.edu/ A digital library of resources for the study of the humanities
3. Geo-Leo http://www.geo-leo.de/geoleo/www-docs/?language=en collects records in the subject areas Geology, Mineralogy, Petrology, Soil Science, Mining, Geophysics, Geography and Thematic Maps.
4. Citebase http://www.citebase.org/search "Citebase contains articles from physics, math, information science, and (published only) biomedical papers>"
A useful federated collection is based on records where there exists a commonality in the metadata and that enhances your research in some way. Each of these services fulfilled that need for the most part. Perseus returned over 1,000 hits on the search "railroad stations United States." This can be attributed to the Library of Congress being one of the sites searched. Also, Perseus returned irrelevant records including a sheep shearing station in Australia. The other sites returned data as I expected. Oh yes, one other reason why harvesting is good, there is the fact that you are only doing one search instead of searching individual sites.
The University of Michigan's mega repository Oaister http://www.oaister.org/ indexes about 15M records from nearly 1000 contributors. This is one of those cases where size matters and helps the cause. The advantage is you have the potential of more sources returning more useful records making for a stronger federated search Should this be your only source for information? Probably not, your research plan should include a look in more then one repository.
Thank goodness for service providers, sites harvesting and storing metadata from various collections. I looked at four of these sites.
1. Sheet Music Consortium – The consortium is a partnership between John Hopkins University, UCLA, University of Indiana and Duke University Library.
2. Perseus- http://www.perseus.tufts.edu/ A digital library of resources for the study of the humanities
3. Geo-Leo http://www.geo-leo.de/geoleo/www-docs/?language=en collects records in the subject areas Geology, Mineralogy, Petrology, Soil Science, Mining, Geophysics, Geography and Thematic Maps.
4. Citebase http://www.citebase.org/search "Citebase contains articles from physics, math, information science, and (published only) biomedical papers>"
A useful federated collection is based on records where there exists a commonality in the metadata and that enhances your research in some way. Each of these services fulfilled that need for the most part. Perseus returned over 1,000 hits on the search "railroad stations United States." This can be attributed to the Library of Congress being one of the sites searched. Also, Perseus returned irrelevant records including a sheep shearing station in Australia. The other sites returned data as I expected. Oh yes, one other reason why harvesting is good, there is the fact that you are only doing one search instead of searching individual sites.
The University of Michigan's mega repository Oaister http://www.oaister.org/ indexes about 15M records from nearly 1000 contributors. This is one of those cases where size matters and helps the cause. The advantage is you have the potential of more sources returning more useful records making for a stronger federated search Should this be your only source for information? Probably not, your research plan should include a look in more then one repository.
Wednesday, October 22, 2008
The Subjects
A question peered over the top of the laptop as I was entering my photo collection into Eprints. Which came first, the subject taxonomy or the collection? Do you fit the collection to the taxonomy or taxonomy to the collection? It depends on the type of collection, I think. In the case of my collection of photos from a recent trip to Alaska. I shaped the taxonomy to fit the collection by developing a series of parent child relationships. For example:
This hierarchy proved useful in cataloguing this collection, developing relationships between the photos and increases the searchability of the collection.
The challenges were where to draw the line between parent and child and develop terms that might be consistent with similar collections. Juneau is both a child and a parent.
I wasn't sure how to classify some terms. Should Mt. Roberts be a child of a different parent such as mountains? Consistency across repositories at my level of cataloguing is an ideal that I attempt to attain by drilling down from the general to the specific. In that way queries of my collection will return a useful result. That’s what it's all about, isn't it?
A: National Parks
a1: Glacier Bay National Park
B: States
b1: Alaska
b2Washington
This hierarchy proved useful in cataloguing this collection, developing relationships between the photos and increases the searchability of the collection.
The challenges were where to draw the line between parent and child and develop terms that might be consistent with similar collections. Juneau is both a child and a parent.
C: Cities
c1: Sitka
c2: Juneau
c2a:Mt. Roberts
c2b: Gastineau Channel
I wasn't sure how to classify some terms. Should Mt. Roberts be a child of a different parent such as mountains? Consistency across repositories at my level of cataloguing is an ideal that I attempt to attain by drilling down from the general to the specific. In that way queries of my collection will return a useful result. That’s what it's all about, isn't it?
Tuesday, October 7, 2008
Pour into Drupal
I have a friend who has an old Oldsmobile 88, from the mid 50s. He'd be out there every evening, in the garage, tuning it, polishing it, just fooling with it. It never worked totally right. Drupal is like that for me. I'm tweaking it and looking for fixes to correct those messages with the pinkish background. It works but has its problems. OK, I've only been at it for six days or so and have been able to enter content and metadata. It is searchable. It works. My friend was able to drive around in his Olds but it was soon back in the garage for more tweaking and tuning.
Drupal is open source and there are many people contributing various modules (code) to add to the functionality. There are modules a plenty, for almost anything you might want to add. As a class (see previous entries) we added a number of modules to the Drupal core) including an image module and a WYSIWYG editor, both working well and a category browser which for me never worked, evidently, there is a reported bug. With the image module, I was surprised to find it only supports jpeg, gif and png files in the "attach image module". If you want to add a tiff or a bmp then you need to do it in using the more conventional file attachment.
I added three modules on my own. The first is Lightbox2, a java script which overlay images on a page. It was a method to view photos in my collection. I still haven't gotten it to work to my satisfaction. The second module is Flash Video, a very powerful solution for playing video clips. One of its more interesting features is that it converts the original format to flv so it will be able to be played in a flash player. I've been able to upload an mpg file and have it playback but in QuickTime. Needs some tweaking! The third module, Node Map, is a tool that relates a node to a location on a map using either Yahoo or Google maps. It offers many uses to visitors to my collection, primarily attaching photo to a location. It also has its bugs. When I enter a location into the map I receive a location does not exist message.
I won't be in the garage, instead I'll be at the computer looking for solutions and tweaking.
Drupal is open source and there are many people contributing various modules (code) to add to the functionality. There are modules a plenty, for almost anything you might want to add. As a class (see previous entries) we added a number of modules to the Drupal core) including an image module and a WYSIWYG editor, both working well and a category browser which for me never worked, evidently, there is a reported bug. With the image module, I was surprised to find it only supports jpeg, gif and png files in the "attach image module". If you want to add a tiff or a bmp then you need to do it in using the more conventional file attachment.
I added three modules on my own. The first is Lightbox2, a java script which overlay images on a page. It was a method to view photos in my collection. I still haven't gotten it to work to my satisfaction. The second module is Flash Video, a very powerful solution for playing video clips. One of its more interesting features is that it converts the original format to flv so it will be able to be played in a flash player. I've been able to upload an mpg file and have it playback but in QuickTime. Needs some tweaking! The third module, Node Map, is a tool that relates a node to a location on a map using either Yahoo or Google maps. It offers many uses to visitors to my collection, primarily attaching photo to a location. It also has its bugs. When I enter a location into the map I receive a location does not exist message.
I won't be in the garage, instead I'll be at the computer looking for solutions and tweaking.
Wednesday, September 24, 2008
A Lot To Do
The question was asked about the pace of the tech assignments compared to the "intensive Intro course"? At 12:30 am Wednesday morning in Nashville, 10:30 pm in Tucson about 30 minutes to deadline, I'm still slogging through Drupal assignment for this week. Until this week I would say that they were at the right pace. It is similar to the summer's pace minus the quiz and some drop box items but there is the additional management component. I'm not sure if I really see the difference. Grumble Grumble!
On a more positive note, I found the readings for this week interesting. I can finally make sense of the various forms of the classification of objects.
On a more positive note, I found the readings for this week interesting. I can finally make sense of the various forms of the classification of objects.
Wednesday, September 17, 2008
Content Management Solutions
Matt Benzing in his article, "Luwak: a content management solution" appearing in Library Hi Tech (2006 Volume 24 Issue 1, pgs 8-13) discusses how the Library at Renssealer Polytechnic Institute solved its problems caused by users accessing its "website with a multitude of browser types". The Library needed to adapt their web pages to accommodate these browser types. Also there was a need for librarians of "various skill levels" to create and update web pages. For a time Macromedia Dreamweaver was use as a site management and design tool. Benzing reported that this was not a satisfactory solution. It did not solve the need for transforming pages for different delivery methods. It was also susceptible to the erasure or alteration of pages.
The answer to this was a content management system An XML based system was developed by the Communication & Collaborative Technologies division of Renssealer Polytechnic Institute. This home grown solution was too the name Luwak after, as Benzing describes it, the ferret-like Asian mammal and the coffee that bears its name and benefits from the animals biological functions. There is a Java Java thing going n here. This system offered answered many of the Library's needs. In publishing web pages roles can be assigned to various players. Various style sheets could be created for different devices that would be applied on the fly such as hand held devices. One of the more interesting changes was that it became much easier for librarians, who are not, for the most part web designers or content publishers to go in and make a quick fix to a page in either XML or plain text. Benzing concludes that "the Library's website is more flexible, efficient and consistent than it has ever been.
The library at RPI is fortunate that its school has a division that served as the CMS developer. This helped keep costs down. This really depends on how the bookkeeping is done. Luwak is based on open source software. Though the cost savings gained from having the CMS developed on campus is questionable, there is a saving from using open source software.
This is only one solution to content management systems. Others are buying an answer in a box and others are developing systems based on open source software solutions. Later this week I will be starting to work with Drupal, a content management system based on open source software.
The answer to this was a content management system An XML based system was developed by the Communication & Collaborative Technologies division of Renssealer Polytechnic Institute. This home grown solution was too the name Luwak after, as Benzing describes it, the ferret-like Asian mammal and the coffee that bears its name and benefits from the animals biological functions. There is a Java Java thing going n here. This system offered answered many of the Library's needs. In publishing web pages roles can be assigned to various players. Various style sheets could be created for different devices that would be applied on the fly such as hand held devices. One of the more interesting changes was that it became much easier for librarians, who are not, for the most part web designers or content publishers to go in and make a quick fix to a page in either XML or plain text. Benzing concludes that "the Library's website is more flexible, efficient and consistent than it has ever been.
The library at RPI is fortunate that its school has a division that served as the CMS developer. This helped keep costs down. This really depends on how the bookkeeping is done. Luwak is based on open source software. Though the cost savings gained from having the CMS developed on campus is questionable, there is a saving from using open source software.
This is only one solution to content management systems. Others are buying an answer in a box and others are developing systems based on open source software solutions. Later this week I will be starting to work with Drupal, a content management system based on open source software.
Tuesday, September 9, 2008
Collections
It’s the fall semester in my course of study at the University of Arizona, two courses both dealing with digital collections. Some interesting readings this week in both 675 and 671. On in particular pqued my interest was Clay Shirky’s essay, Ontology is Overrated ,. In it he raised the question, of how strict must should we be with the way we categorize, should we let the caategories fall as each person calls them. I think that it wont lead to chaos but instead might make it easier to find items.
This current assignment is to put together a collection to enter into Drupal in a few weeks. I'm going to continue dealing with the family photos, particularly those from the past 5 years. For the purpose of this exercise, I want to keep them generic tied to place as opposed to person. The audience would be friends and family. Some terms would include Alaska, ships, ocean, mountains, party, New York
This current assignment is to put together a collection to enter into Drupal in a few weeks. I'm going to continue dealing with the family photos, particularly those from the past 5 years. For the purpose of this exercise, I want to keep them generic tied to place as opposed to person. The audience would be friends and family. Some terms would include Alaska, ships, ocean, mountains, party, New York
Subscribe to:
Posts (Atom)