This website uses cookies to ensure you get the best experience. By clicking or navigating the site you agree to allow our collection of information through cookies. More info

2 minutes to read Posted on Monday October 26, 2015

Updated on Thursday October 31, 2019

Who's Using What: Omeka

Omeka is perhaps the most well known and widely used open-source web-publishing platform for libraries, museums, archives, and storytelling enthusiasts.

Just take a look at their Wiki of past exhibitions that have made use of Omeka, it's extensive. Europeana used it for their digital Art Nouveau exhibition. Omeka started life in 2008 at the Roy Rosenzweig Center for History and New Media at George Mason University and has been only getting better since. Let's see what tools the Omeka team are using to ensure that the platform is easy for others to build-upon, adapt and modify while retaining its strong core, and what their future plans are.

This interview was submitted by Sharon Leon, Director of Public Projects at the Center for History and New Media and Director of Omeka. You can read more about Leon's work here.

What Open Source Tools Do You Use / Have You Used?

Omeka relies on a number of underlying technologies. Most fundamentally, Omeka is built on the Zend Framework. It provides a lot of functionality for us to use€” things like routing requests, a structure for building themes and plugins, and a codebase that lets us work within an existing set of patterns. To the extent that we do a good job of adhering to those patterns, that makes an easier onramp for others to extend Omeka and suggest fixes and improvements to the core of Omeka. Currently, we also incorporate the tinyMCE editor for our text/HTML inputs, and have moved toward using more of the established javascript and CSS libraries like jQuery and SaSS. As a big project, this lets us benefit from other FLOSS work focused on their own functionality, so we can concentrate on developing for the needs of our own user communitity.

What are you currently developing?

The next generation of Omeka, Omeka S, continues to use Zend Framework, but also incorporates newer tools like the Doctrine ORM. Besides modernizing the codebase, this similarly allows us to use the efficiencies of Doctrine to improve our site performance and manage data relationships. One of the main goals of Omeka S is to improve data sharing between Omeka and other GLAM tools. Openness and interconnectedness, generally understood, is built into the design of Omeka S. To that end, we are relying heavily on Linked Open Data serialized as JSON-LD, and basing our API on that. It is designed to be "€˜multisite"€™, meaning that one installation will support many distinct sites for different purposes, similar to a WordPress network installation. Different from a WordPress network, though, content is designed to be shared at a fundamental level to be shared between sites. Explicit RDF-based relationships between resources in Omeka S will be possible. To supplement the linked data implementation with Omeka S, we are also in the process of building modules to integrate a range of standardized vocabularies such as those offered by the Getty Research Institute and the Library of Congress. When it is available, we are also planning to offer a module that includes the recent DPLA/Europeana international rights statements standard.

What would you like to see built?

We would love to see an open source Agile project management tool built on top of GitHub's API. Some (paid) services and products based on GitHub exist (Waffle, HuBoard), and Jira can connect with GitHub. But the right, magical balance of what works well for developers and what works well for project managers remains elusive. Full Agile information like user stories, story points, epics, backlog tracking, and burndowns is a significant layer on top of the developer-focused GitHub information of commit history, code review, and issue tracking. User testing tracking, documentation writing, and more involves the entire project team:” coders, writers, and managers;€” and call for a tool in which everyone is equally comfortable working. Each product privileges either management needs or developer needs, and we have not yet found one that does not add pain-points for one group to remove them for another. We are fortunate at Omeka that the developer and project management groups are pretty fluid and conversant, and so we overcome those obstacles fairly easily. But we would still like a tool that removed the pain-points for everyone.