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.