Title: Using Omeka S To Create and Share Cultural Heritage Linked Open Data
Day/Time: Saturday, 1:30-5:30
Room: Arlington/Fairfax (3rd Floor)

Abstract:

In 2012, the Roy Rosenzweig Center for History and New Media (RRCHNM) at George Mason University (GMU) started developing a new version of our popular open-source web-publishing platform, «Omeka» (Classic) , that was designed specifically with the principles of Linked Open Data (LOD) in mind. Developed for medium and larger GLAMs, Omeka S uses JavaScript Object Notation-Linked Data (JSON-LD) as its native data format, which makes it possible to enmesh Omeka S in the LOD world. Every Omeka S Resource (item, item set, media) has a URI, and the core software includes the following Resource Description Framework (RDF) vocabularies, which maximizes its data interoperability with other data publishers: Dublin Core Metadata Initiative «(DCMI) Terms», «DCMI Type», «The Bibliographic Ontology» (BIBO), and The Friend of A Friend Vocabulary» (FOAF). In our progress toward ensuring and maintaining interrelationships between humanities data, connectors between Omeka S and other systems will ensure that LOD is maintained. For example, the connector to Fedora fosters import of both Fedora's own vocabulary, and the W3C Recommendation Linked Open Data Vocabulary that it rests on. Together, these features prepare data in Omeka S to be fully embedded in the semantic web.

Both Omeka Classic and Omeka S have straddled the line between encouraging interoperable metadata and easy web publishing. Often those two things come into conflict. For example, to take advantage of visual rhetoric for web pages, Omeka Classic users frequently want to include HTML and even embed codes in the metadata they display. Omeka Classic thus allows HTML (with optional filters for security) in all metadata fields, even though such choices might be questionable under strict metadata standards. Omeka S addresses this dilemma by treating visual display needs as a type of “media” attached to the record, similar to files attached to the record.

Omeka S also introduces a distinction in types of metadata values between string literals, internal references, and external URIs. Thus, for example, Dublin Core terms such a “creator” can easily be used to refer to both internal and external assets by a link between one Omeka S Resource and another (i.e. using a Person type Resource for Thomas Jefferson as the value for the creator field in description of the “Declaration of Independence” text Resource). Alternatively, a user could input a URI for an external resource (e.g. Thomas Jefferson’s DBpedia page).

In developing Omeka S, we quickly realized that the number of metadata properties from the available vocabularies could quickly become unmanagable to users, and so to ease metadata creation we created the feature of “resource templates”. These allow administrators to create a template for item and metadata creation specific to the design of each site. For example, an Omeka S site with an emphasis on linking creators to their works should create a template that emphasizes a record of type Agent using FOAF properties, and another template that emphasizes a record of type Text using Dublin Core properties. The creator property would then be used to link them together. The basic resource template that ships with Omeka S is aligned to the metadata that DPLA calls for.

In this tutorial we will walk through these and other aspects of Omeka S Item creation, with emphasis on LOD principles. We will also look at the features of Omeka S that ease metadata input and facilitate project-defined usage and workflows. In accordance with our commitment to interoperability, we will describe how the API for Omeka S can be deployed for data exchange and sharing between many systems. Finally, we will describe how add-on modules can expand on these metadata features, including use of Library of Congress and Getty authority data, «Rights Statements», and data expansion from Linked Open Data endpoints.

The first half of the tutorial will begin with the lessons we have learned from Omeka Classic and the balance between the needs of metadata standards and the needs of appealing online publication. Then, turning to Omeka S, we will demonstrate the processes for 1) creating Dublin Core and other metadata, 2) creating resource templates to guide metadata creation, 3) importing and integrating other RDF vocabularies, and most importantly 4) the principles we have adopted to foster valuable public display, reliable and useful metadata, and interoperability.

The second half of the tutorial will be a hands-on workshop, encouraging participants to bring their own sample data and records to explore workflows that fit with their own records and projects. We will use our publicly available sandbox Omeka S installation, which includes several authentication credentials that we will distribute during the tutorial. Only a browser will be required. However, bringing sample records that you would like to use to explore Omeka S will be very helpful. Media such as YouTube references, IIIF manifests, text descriptions or analysis, files to upload, or anything else will give you material to use for the hands-on portion of the tutorial. Importantly, since Omeka S is a young project, any kind of record you work with will create a way for you to tutor us in how well we fit your needs.

Learning Outcomes:

1. What differentiates Omeka S from Omeka Classic

2. Design choices in Omeka S that facilitate good metadata creation

3. How to create items and sites within Omeka S

4. The Omeka S metadata model, and how it is part of LOD

5. How Omeka S implements LOD

6. How Omeka S connects with other systems

Tutorial Leads:

Patrick Murray-John

Patrick Murray-John is a Research Assistant Professor and Director of Omeka Developer Outreach at the Roy Rosenzweig Center for History and New Media, George Mason University

[ TBA ]