Numishare's Improved Data Model, Applied to Findspots

As I mentioned in the previous blog post, we are re-envisioning Numishare's underlying data model. The three sites that currently use Numishare in one form or another (University of Virginia Art Museum, Kittredge Collection, ANS's Mantis) are built on an adaptation of Encoded Archival Description, an XML standard common to archival collections, to numismatics. The new model is a numismatic-specific ontology that includes some museum collection types of fields, and is greatly influenced by existing XML standards. In fact, digital images are described in METS.

This new data model, let's call it NUDS-XML, also draws inspiration from linked open data initiatives, best illustrated by two types of records that can be described in Numishare.

The previous version of Numishare assumed that all records represented physical objects. Certainly the new NUDS-XML allows this type of record as well. The other type of record to be introduced is a conceptual object. This is, to say, an XML document that describes a coin-type. It contains, almost exclusively, typological metadata. This includes fields such as types and legends, authority and issuer, mint, material, and denomination. Unlike a record which describes a physical object, it does not contain die axis, weight or other dimsensions, nor does it contain information about provenience, owner, or repository. These fields are distinct to physical objects, not coin-types.

Among planned projects at the American Numismatic Society is an open access catalog of Roman imperial coins. There are tens of thousands of coin-types over several centuries, beginning with Augustus. The ANS does not own a physical representation of each conceptual object, but may own duplicates for other coin-types. The goal is to create a NUDS-XML record for every Roman imperial coin-type, and enable those records to point to URIs of associated physical objects in Mantis (or other digital numismatic collections).

In order to avoid duplication of typological metadata, physical record types in Numishare contain a URI reference to the source conceptual record rather than chunks of XML. Upon rendering and indexing into Solr the physical object record, the URI will be parsed by the XML/XSLT processor (in this case, Apache Cocoon) and the data scraped directly from the source typological record.

Examples below:

Above, a record for a Roman imperial coin-type

Above, a physical object record linked to the coin-type.

We can leverage the LODness of this new data model to render findspots for a coin-type. The encoding of findspots in NUDS-XML is pretty rudimentary thus far. A simple block of GML is embedded into an element called findspot. Ultimately, findspots can also refer to resources available at URIs, and geographical metadata may be scraped from external sources (like nomisma.org).

In any case, when a conceptual record is indexed into Solr, the indexing script scrapes the record's associated physical objects' NUDS-XML for GML coordinates and indexes them for rendering in an OpenLayers map layer. [The layer is derived from a Solr-to-KML transformation that has been detailed in an earlier blog post.] In Numishare, when a physical object's findspot is added or updated, and that object's typology is derived from a coin-type record, that coin-type record is reindexed in Solr so that changes to the map are apparent immediately.


These maps are especially valuable to economic historians for analyzing the distribution of a particular coin-type over space (and eventually time, when we introduce temporal mapping). One can visualize trade networks by the distribution of currency.

Visual Themes in Numishare

I've been busy over the last few weeks on seriously revamping Numishare's code trunk. We're moving toward a numismatics-specific XML ontology based on the NUDS fields list, which draws much inspiration from existing standards like VRA Core, EAD, and TEI, but also incorporates tenets of linked open data. I'll discuss NUDS-XML in greater detail in a future blog post.

As part of this major revision to Numishare (which I hope to officially release as Numishare 1.0 later this fall) is a simplified theming interface. One of the drawbacks to the application when it was first released about two years ago is that it required XSLT and general web development knowledge in order to customize the front-end user interface. While direct customization of code can still be done by a savvy developer in the current version, much of the theming is being moved into the administrative interface, with an XForms application that enables the user to control the visual design of the public site with an intuitive web interface that will function much like Blogger's own interface for customizing this or other blogs. This feature is vital in the encouragement of institutions and collectors to adopt Numishare as their publishing platform. After the initial deployment of Numishare's required applications onto a server (which takes a sys admin about 15 minutes), no other serious technical investment is required of the Numishare administrator to begin publishing coins since it requires no programming expertise to visually distinguish Numishare-based sites from one another.

jQuery UI theme

Object display page layout

The interface will enable the user to specify which jQuery UI theme to use (all pre-packaged themes are available to choose from), as well as other colors, fonts, background images, banner images, etc. There will be several page layouts to choose. These visual configurations are stored in an XML file that is edited with an XForms web form. So far, the jQuery UI theme and object display page layouts have been implemented, and I plan to implement the remainder of the theme-adjusting interface will be completed in the coming weeks.