Scholars’ Lab and CHNM Partner on “Omeka + Neatline”

 Announcements, Awards, digital humanities, Digital Libraries, Geospatial and Temporal, GIS, Neatline, Omeka, plugins, Visualization and Data Mining, web development  No Responses »
Feb 162011
 

The Scholars’ Lab at the University of Virginia Library and the Center for History and New Media (CHNM) at George Mason University are pleased to announce a collaborative “Omeka + Neatline” initiative, supported by $665,248 in funding from the Library of Congress.

The Omeka + Neatline project’s goal is to enable scholars, students, and library and museum professionals to create geospatial and temporal visualizations of archival collections using a Neatline toolset within CHNM’s popular, open source Omeka exhibition platform. Neatline, a “contribution to interpretive humanities scholarship in the visual vernacular,” is a project of the UVa Library Scholars’ Lab, originally bolstered by a Start-Up Grant from the Office of Digital Humanities at the National Endowment for the Humanities. Omeka is an award-winning web-publishing platform for the display of cultural heritage and scholarly collections and exhibits, funded by the Institute of Museum and Library Services, Alfred P. Sloan Foundation, Andrew W. Mellon Foundation, and Samuel H. Kress Foundation.

This two-year initiative will allow CHNM and the Scholars’ Lab to expand and regularize a partnership that developed informally between the two centers over the course of the past year. Collaboration has already resulted in improvements to the core functionality of Omeka by CHNM and has led the Scholars’ Lab to produce a number of prototype plugins making Omeka a more attractive and viable option for scholarly partnerships with larger libraries and cultural heritage institutions. These include: improved data import (including EAD, a common archival standard); Solr-powered searching and browsing; and Fedora-based repository services. Further development will improve existing plugins, add preservation workflows, and refine the Neatline toolset for integration and sophisticated editing and scholarly annotation of historical maps, GIS layers, and timelines. Enhancements to Omeka’s core APIs, improved documentation, regular “point” releases, and a new Exhibit Builder will strengthen Omeka’s already large and robust user and developer communities.

Omeka + Neatline is one of six contract awards made by the Library of Congress in a program that aims both to improve the Library’s own content management and content delivery infrastructure and to contribute to collaborative knowledge sharing among broader communities concerned with the sustainability and accessibility of digital content. In July of 2010, the Library of Congress targeted approximately $3,000,000 toward Broad Agency Announcements covering three areas of research interest related to these goals. Technical proposals were openly solicited from expert, multi-disciplinary communities in both academic and commercial settings in three areas: Ingest for Digital Content, Data Modeling of Legislative Information, and Open Source Software for Digital Content Delivery.

In addition to guiding software development work at the Scholars’ Lab and CHNM, project directors Tom Scheinfeldt and Bethany Nowviskie will use the Omeka + Neatline project as an opportunity to document and disseminate a model for open source, developer-level collaborations among library labs and digital humanities centers.

 Posted by on February 16, 2011

Building Omeka Exhibits with Fedora Repository Content

 digital humanities, Digital Libraries, fedora, Omeka, plugins, SLab Code, solr, TEI  No Responses »
Dec 162010
 

Our NEH-funded Neatline project has inspired the Scholars’ Lab to develop or enhance several new Omeka plugins recently. (See our full list.)

One of these is FedoraConnector, which is designed to enable administrators to attach Fedora datastreams (a digital object — whether image, XML like TEI or EAD, or video) to Omeka items. This is fundamentally different from attaching files to an item–the datastream is not duplicated and stored within Omeka’s archive. Rather, a reference to the Fedora object (PID) is stored within a new table in the Omeka database that associates the item with the URL of the datastream that is accessed (and rendered) with Fedora’s REST API. The plugin also supports importing Dublin Core and MODS metadata into the DC Element Set in Omeka. The importers can be extended to map from any metadata standard into DC.

The benefit to this architecture is that it enables dynamic rendering of the most current version of the Fedora object, and thus there is no issue about storing duplicate files in the Omeka disk space that can be deprecated by updates to the original Fedora object. Additionally, FedoraConnector can take advantage of institutional-specific services that are developed for delivering content. For example, thumbnail and medium-sized page images are rendered in real time by querying the University of Virginia Library’s JPEG2000 server and requesting deliverables at a specific dimension. Disseminators, or handler functions for rendering Fedora content based on mime-type and/or datastream type, are extensible.

TEI document from Fedora

TEI document from Fedora

Earlier this year, we released a beta version of a plugin for rendering TEI files into HTML within Omeka. Called TeiDisplay, this plugin was enhanced by the insertion of several hooks that execute FedoraConnector functions (if FedoraConnector is installed) to render TEI XML datastreams on the fly directly from the repository. TeiDisplay supports, as the documentation for the plugin indicates, selection of customized XSLT stylesheets and two display types: entire document and segmental view (with table of contents and by-section rendering). Indeed, documents coming from Fedora can be rendered dynamically with the same set of options.

But what about indexing the document? This is why the Scholars’ Lab developed SolrSearch last summer to replace Omeka’s default mySQL search with the more advanced search options afforded by Solr, an open source search index. SolrSearch supports facets, sorting, hit highlighting, and a handful of other options. Originally designed to index the full text of Omeka files with a text/xml mime-type, SolrSearch was enhanced to index the full text of Fedora datastreams with a text/xml mime-type as well, enabling full text searching, faceted browsing, and hit highlighting of the aforementioned TEI files referenced from a repository.

solr

Solr search of TEI file in Omeka

So in essense, the range of plugins the Scholars’ Lab has created for Omeka can enable creation of attractive and cutting-edge public user interfaces for collections of Fedora objects. Coupled with our Neatline plugins, which are all about geospatial and temporal interpretation of archival collections, this work bridges a well-recognized gap between the volume of digital content housed in sophisticated repositories and the curators, scholars, and end users who seek access to it and wish to interpret it in online exhibits.

WMS vs. tilecaching

 Add new tag, Geospatial and Temporal, GIS, historic, map, plugins, Visualization and Data Mining  No Responses »
Jun 302010
 

In our work on Neatline, we have made a deliberate choice to start by constraining ourselves to map-sources that are quickly and easily provided through WMS. This leaves out (for now) two popular sources of map imagery; Google Maps and Open Street Map. I’m going to explain why we made that choice, and why, when we do come to make these sources usable with Neatline, we will do so with great care and with an eye to scholarly method.

All two-dimensional maps (as opposed to globes) are projected. That is, the curved three-dimensional surface of the Earth is transformed onto a flat two-dimensional surface. This can be done in an infinite variety of ways, many of which have been mathematically characterized and named by cartographers, for whom they are necessary tools. We must note, however, that no such transform can obtain a perfect representation of a section of the Earth. The mapmaker must choose which qualities to preserve and in what measures. Is it more important to provide an accurate depiction of relative areas or of relative lengths? Is the area around Greenland to be kept in the focus of accuracy, or that around New Zealand?

Each map therefore carries with it from its creation certain choices like these, part of the arguments the map makes about the world by its very construction. We chose WMS on which to start building our tools because, amongst other reasons, it allows for the transmission of projection information as part of its operation. This fact allows us to produce imagery from historical maps (themselves in any number of projections) and maintain the original choices the mapmaker made. Google Maps and Open Street Map are not WMS sources. They can be described as tile caches, huge reservoirs of rendered imagery. As such, they offer their own choices about how the world is to be projected. (Google’s choice has become so closely associated with Google that it is known widely as “the Google projection”.)

Now we come to an important technical distinction; WMS services are able (depending on the capabilities of the specific software in use) to reproject their contents. That is, in response to a specific request for imagery, they can produce the imagery in a projection different from the one in which it was stored. GeoServer, the software we are using for Neatline, has a library of thousands of projections to which users can add more as desired. This allows us to take imagery from a WMS source and lay it under a historical map layer while maintaining the original projection for that of the map as a whole. Tile caches, by and large, do not allow for this. (Google Maps offers its one projection, and Open Street Map offers two.) This means that in order to lay historical map imagery over a layer from one of these sources, we would have to reproject the foreground (historical imagery) overriding the choices of the mapmaker and introducing additional choices of our own about what facets of the geographies at stake are to be preserved and which abandoned.

(Neogeographers will remark that georectifying a digital image introduces similar issues. This is true, but unavoidable for our purposes. We would like to avoid compounding the matter in a way that is subtle and hard to detect.)

We are working out means by which we can provide the undeniable utility of popular tilecaching services in a way that is respectful of the historical context and story of map artifacts. Until we do, we will continue to concentrate on the more flexible and sophisticated apparatus provided by WMS.

Expanding the Capabilities of Omeka

 Digital Libraries, EAD, metadata, Omeka, plugins, SLab Code, VRA Core  No Responses »
Jun 182010
 

Because I have a keen interest in the description of cultural heritage artifacts and in doing interesting things with metadata, in recent months I have developed a handful of Omeka plugins to meet these interests. My first foray into plugin development for the application was with the EAD Importer. The EAD Importer, as the name suggests, extracts item-level metadata (along with a bit of collection-level metadata, like rights) from Encoded Archival Description finding aids and generates a CSV file which can be imported through the CSV Import plugin developed by the Omeka crew. The plugin would be useful to archivists who would like to use Omeka to build online exhibits of their collections. I took this framework a step further to create a plugin that is capable of importing any flat XML into Omeka by transforming that file into a CSV file.

Most recently, I have turned my attention to expanding the descriptive abilities of Omeka into the realm of collections of artwork. Omeka items are described with Dublin Core, which is capable of describing anything, though not particularly well. I developed VraCoreElementSet, which incorporates VRA Core fields into the Edit Item form. VRA Core is a much more semantically appropriate schema for describing art and artifacts. Since it was conceived as an XML standard (not strictly a flat list of fields), some elements have hierarchical sub-componenets. For example, a work may have several agents involved in its production, and each agent has a name as well as a role, culture, birth date, and, as the case may be, a death date. The VraCoreElementSet plugin creates a table for agents so that a user may enter this data separately. Then in the Edit Item form, the user may select VRA Core agents from a drop down menu restricted by the records in the agents table. Items may also be exported to schema-compliant VRA Core XML. There is still some work remaining on this plugin, but it is well on its way toward completion.

Now that the Scholars’ Lab has contributed EAD Importer and VRA Core Element Set plugins, Omeka may attract new institutional users from the library, archive, and museum fields, who may have otherwise settled for proprietary applications to disseminate their digital collections.

Preparing #multimedia content…

 day of digital humanities, DayofDH, dh, dhh10, digital humanities, English, plugins, UQAM  Comments Off
Mar 192010
 

Preparing #multimedia content for tonight’s class. Need to rent equipment + set it up myself; only a screen in my classroom #UQAM #DayofDH

Original post : http://identi.ca/notice/25199875
Posted from : http://stéphanethibault.com/2010/03/18/preparing-multimedia-content/ (using the Identi.ca Tools WordPress Plugin)