I wrote this when I was the Digital Library Applications Lead at the University of Notre Dame. It was archived from http://www3.nd.edu/~dbrubak1/ which no longer exists.
- Digitized rare books (Architecture & RBSC)
- Digital images (Architecture)
- Digital exhibits with mixed media (RBSC)
- Digital exhibits released at the same time as the physical exhibits
- There is a symposium in February 2014 that needs an exhibit
- Past exhibits have unpublished digitized materials
- Production of digital content is rapidly increasing. We need to accommodate this.
- Presentation of completely digitized monographs
- Requirements have been gathered; they can be updated rather easily
- Digital exhibits
We need a path to sustainability creating digital exhibits. Julie and Sara have been looking at tools for exhibit building and think Omeka looks attractive.
The primary benefit of Omeka is that it is a mature open-source platform for exhibit building. It has the same pitfalls as any other content management system: if used as intended everything should be fine; if your needs exceed the capabilities of the tool it can cause a lot of headache.
In order to evaluate Omeka we should also consider these prominent plugins:
It appears that using the FedoraConnector is not tenable with CurateND because it requires that the content be accessible without access controls:
Currently, FedoraConnector can only interact with Fedora servers that do not place authorization checks on remote requests to access object datastreams.
If we implement Omeka as an exhibit system it would have to exist entirely outside our preservation system. This isn’t necessarily a non-starter. It would reduce the amount of programmer time needed to implement an exhibit system in exchange for duplicating some work for collection managers e.g. depositing digitized content into CurateND as well as separately managing access derivatives in Omeka.
Alternatives to Omeka
I have three design objectives for a digital exhibit system:
- Be able to retrieve content and metadata from CurateND or Fedora directly
- Allow staff who are not programmers to create exhibits and to manage the content of their exhibits.
- Present content in a mobile-first responsive design (further reading).
|Exhibitz||Yes||Yes (planned)||Maybe||2014 (planned)|
Of these options Omeka has been around along the longest and appears to have reasonable adoption. While this doesn’t guarantee that is is the best solution, I’ve seen quite a few underwhelming Omeka-driven sites, it exists in the wild and people actually use it.
Special collections already has about 50 digitized volumes that are not published. The Architecture Library has several digitized volumes as well but would like to move beyond just making PDFs available for download.
What do we actually need in a page turner?
RBSC likes e-codices. It would be good to know why as it doesn’t strike me as being particularly impressive. Because it limits zoom to only the single-page view it also wouldn’t be too difficult to implement using one of the standard image zooming libraries.
Another example is the Northwestern books site. It is a robust solution but both the technical infrastructure and metadata that powers it are very complicated. Their infrastructure is not in a state where it could be easily packaged up and adopted by another institution.
There are also use cases for juxtaposing related content from multiple volumes. Adam has created a Filemaker Database to do this in Architecture but it is not publicly accessible. They would love to make that kind of discovery experience available to their patrons at large.
- A IIIF compatible image server
- An image pipeline
- An image-centric search interface either in CurateND proper or as a separate tool.
- Before Christmas we need a plan for delivering digital exhibits
- Immediately folioing the launch of CurateND we should schedule stakeholder meetings with Adam and Jennifer in Architecture and Sara in RBSC
- Content modeling needs
- Batch ingest process requirements