To access my Omeka site, click here.
For this week’s practicum on public history we were tasked with creating a collection of objects on Omeka. I had been looking forward to learning about and using Omeka, and luckily for the first year fellows, our practicum coincided with our first week of our rotation in Public Projects. In the past three days we have gotten a handle on the front end of Omeka by looking at the showcased sites; played in the back end by installing Omeka on our dev sites through the shell rather than FTP; installed themes and more on our dev sites using git commands; and user tested themes and the poster plugin.
Step One: Gathering Primary Sources
In order to begin the practicum, I had to find primary sources. Since I didn’t come into the PhD program with a master’s in history, I don’t have a lot of data on hand to play with. I had been toying with the idea of women’s history as legal history for the final Clio project, in which I either text mine or map Supreme Court cases and newspaper articles. I quickly found the full text of the final decision on Muller v. Oregon from the Legal Information Institute at Cornell University. I edited the text, removing any hyperlinks or additional data, in order to not violate copyright. I then went to Chronicling America and found three newspaper articles, and from the Library of Congress site I found a cartoon. I also went on Flickr Commons and found a photograph of the nine justices sitting on the Court when the Muller decision was made.
Step Two: Uploading Items & Dublin Core
After collecting my primary sources I uploaded them onto Omeka. Omeka uses Dublin Core metadata, and inputting data into the fields was a time-consuming process since I wanted to ensure that I used a controlled vocabulary. In library school I did not ever get to use Dublin Core – this cataloging code is mostly used in archives and museums, and since I didn’t specialize in archives I wasn’t too familiar with Dublin Core. I found this page to be particularly helpful in figuring out what information to put into which fields (whether or not I did it correctly is yet to be determined). Often, the fields would overlap. For example, I used the same information in the type and identifier fields, and usually the creator and publisher would be the same.
Step Three: Creating a Collection
Once the documents had been put onto the site, I created a collection. For the collection I omitted certain metadata fields. I did not think it appropriate to use creator, publisher, contributor, or relation. Obviously if I use this collection as part of the final project, then I will need to include more information in the description field, as well as an argument. I was able to add all items into the collection in one click.
Step Four: Finishing Touches
I then moved on to editing the site in general. I played around with the themes, and chose seasons because I liked having the primary source at the top of the page with the metadata following. I named the site and filled out the site description field in settings. I had thought this would populate the about tab, but it didn’t. After looking around a bit I figured out that I needed to use the simple pages plugin to edit that tab. I removed the exhibit tab at the top of the page and configured the appearance so the featured exhibit box would not appear on the homepage. I edited the wording of the browse collections and browse items tabs.
I was incredibly pleased with Omeka. The interface is easy to use and is aesthetically pleasing. The codex is incredibly detailed, and I found myself referencing it a few times and always finding what I needed. I’m glad I was finally able to use Dublin Core, even though I’m not entirely sure I populated the fields with the correct information. I can certainly understand why so many institutions use Omeka for their online exhibits, and I’m looking forward to using Omeka more in the future.