Metadata and Omeka

Like the web, metadata is always evolving, and for me,  it’s always had an air of elusiveness around it. I really appreciated the way that metadata is defined here. Succinctly, (since the 1990s) “metadata” denotes machine-readable descriptions of things, most commonly in the context of the Web. The structured descriptions of metadata help find relevant resources in the undifferentiated masses of data available online. Anything of interest can be described with metadata, from book collections to football leagues and stuff you want to sell. Describing different types of resources requires different types of metadata and metadata standards.

In the article on Google’s use of metadata, Dan Clancy says that users should take responsibility for fixing metadata errors, kind of like an independent cataloging effort. I am in agreement with Clancy-if every person that encounters a mislabel or a metadata error on Google addresses it then and there, it might be corrected more efficiently. However, this is an idealistic approach- correcting these errors would be a huge undertaking. This situation also underscores the importance for us to use metadata in our digital exhibits. If we approach metadata correctly from the start of a digital project, we save ourselves and other historians and archivists tons of time.

It should be fairly easy for our group to approach metadata with our exhibit because we’re using Omeka. Omeka has made it part of its mission to standardize data about digital objects, so they’ve implemented the use of the Dublin Core Metadata Initiative. The following Dublin Core fields are available through Omeka:

  • Title- name given to the resource
  • Subject- topic of the resource
  • Description- an account of the resource
  • Creator- an entity primarily responsible for making the resource
  • Source- the resource from which the described resource is derived
  • Publisher – an entity responsible for making the resource available
  • Date-a point or period of time associated with an event in the lifecycle of the resource
  • Contributor- an entity responsible for making contributions to the resource
  • Rights- Information about rights held in and over the resource
  • Relation- a related resource
  • Format- the file format, physical medium, or dimensions of a resource
  • Language- language of the resource
  • Type –  The nature or genre of the resource
  • Identifier- An unambiguous reference to the resource within a given context
  • Coverage- The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant

Dublin Core has been around since 1995, and started with simple and generic description of online resources. Metadata has become much more complex since then, but I think that the “core metadata” that Dublin Core offers in conjunction with Omeka seems thorough enough for beginners like me. Only a few fields- date and location- are required, but filling all the fields that you can when adding items to your online exhibit seems like a no brainer. Filling these Dublin Core fields is a really simple way to greatly improve accessibility to your collection. While maybe it’s time consuming to incorporate metadata, it’s imperative that we do so in order to open up access to these collections for present and future researchers.

I took a look at Campaigns and Causes: Political Memorabilia in North Carolina, hosted by the University of North Carolina, and the digital collections at the University of Washington. Both use metadata in different ways. The Campaigns and Causes website is part of UNC, and a link to the UNC digital collections page is available on Omeka, so I assumed that all of their collections would use extremely detailed metadata. They do, but not all fields are filled. I did a search for an item that I knew was in the collection: a campaign button reading “AH LAHK IKE”. Upon searching “Ike” nothing comes up, but searching “eisenhower” leads the researcher straight to the item. I think they’d benefit from adding more metadata tags to their items. What if I had no idea that the button was a southern phonetic version of “I like Ike”, and the only word I remembered was “ike”?  How would I find the item then? I’d probably do a google search of the phrase, which would let me know it was a phonetic spelling, and then search I like Ike, which would presumably lead to information about Eisenhower, and then I’d be able to use the correct search terms. The search shouldn’t be that hard! As usual, adding more tags increases accessibility.

Along the same lines, the specs of each item up on the University of Washington’s digital collections includes an area for tags, but none of the items I browsed through had any tags listed! This was annoying, as there is clearly defined space for this data to be included, but it wasn’t. Again, I’m sure that resources and funding or a combination of both could have prevented tags from being utilized, but the researcher wouldn’t know the details of the institution’s constraints-they just know the frustration of not being able to locate what they need.






Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s