Extending Numishare for IIIF

The American Numismatic Society is in the process of migrating both its own production web applications and Nomisma.org to a central dedicated Rackspace server from the Rackspace cloud. The new server has a lot more resources, which will make our projects more stable and efficient. Furthermore, the extra storage, CPU, and RAM will now make it possible to publish high resolution images through IIIF. All of our high resolution images have been transferred to the new server (over 420GB), and when we flip the switch on the domain names over to the new server, Mantis will now feature high resolution zooming of the obverse and reverse images of about 150,000 objects in its collection. The RDF exports from Mantis for both Nomisma.org and Pelagios will include IIIF service metadata conforming to the Europeana Data Model extension (already detailed in older posts). This means that the high-res coverage of Roman Republican, Imperial, and coinage of Alexander the Great will be increased by 60,000 coins in CRRO, OCRE, and PELLA.

Updating NUDS and Numishare

The NUDS XSD schema has namespaced METS for capturing image links for thumbnails and reference images for both the obverse and reverse of the coin. A mets:file[@USE='iiif'] has been added into the mets:fileGrp for both the obverse and reverse. The mets:FLocat URL points to the IIIF service. This is a simple XML model modification that needed to be addressed in Numishare's code in several contexts:

IIIF images rendered in Mantis

• If there's a mets:file[@USE='iiif'] detected when rendering the HTML page for an object, the obverse and reverse IIIF services are rendered with Leaflet (above)
• As above, in the NUDS->RDF serialization, the EDM IIIF extension includes an edm:WebResource, svcs:Service to capture IIIF service metadata
• The Solr->Nomisma, Pelagios RDF for large data exports will now include IIIF service metadata since the service URI for each image is indexed into Solr

 

Manifests

I have authored an XSLT stylesheet that transforms the NUDS XML document for a physical object into a JSON manifest. This transformation process extracts metadata from the NUDS typological and physical descriptions and generates a sequence of two canvases: one for the obverse and the other for the reverse.

This XSLT compiles a variable of an XML metamodel by applying templates to NUDS and METS elements. This metamodel is then piped through templates in order to construct JSON. The metamodel includes XML elements such as _array, _object, __@id, __@type, which are then transformed into proper JSON on the output with Orbeon's XML Pipeline Language. The model is similar in concept to how XForms constructs an XML model from a JSON service according to the XForms 2.0 specification.

You can view an example of a manifest at http://app1.numismatics.org/search/manifest/1995.11.1648. Here it is rendered in Universal Viewer.

I plan to expand this functionality so that IIIF manifests can be derived from NUDS + SPARQL results for coin types so that it will be possible to see a listing of all available images for a coin type, which will lend itself to more efficient annotation of iconographic features, monograms, and other sorts of symbols. These monograms will link to URIs defined in type corpora. We will be creating the full array of Hellenistic monograms as part of the NEH-funded Hellenistic Royal Coinages project. Ultimately, I would like these monograms to be annotated on images, where available. This isn't a feature of the project that we outlined in our application, but will come as an added bonus.

More mapping features for Nomisma SPARQL responses

Edited 23 August 2017: changed getGeoJsonForQuery to query.json and getKmlForQuery to query.kml

The Nomisma.org SPARQL query HTML interface, for both SELECT and CONSTRUCT/DESCRIBE responses, has been extended generate a map when the query response includes latitude and longitude geographic coordinates (when using the geo:lat and geo:long RDF properties).

The introduction of this new feature necessitated the creation of a new API, query.json, which is essentially an XSLT transformation from either the SPARQL XML response schema or RDF into GeoJSON. The XSLT was extended from existing templates for the other GeoJSON responses for getting the geographic distribution of mints, hoards, or individual finds for a Nomisma concept ID or a coin type.

The query (get a list of hoards that contained tetradrachm coin types [based on PELLA])

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX nm: <http://nomisma.org/id/>
PREFIX nmo: <http://nomisma.org/ontology#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT DISTINCT ?hoard ?findspot ?lat ?long WHERE {
  ?type a nmo:TypeSeriesItem ;
          nmo:hasDenomination nm:tetradrachm .
  ?coin nmo:hasTypeSeriesItem ?type ;
        dcterms:isPartOf ?hoard .
  ?hoard a nmo:Hoard ;
           nmo:hasFindspot ?findspot .
  ?findspot geo:lat ?lat ;
            geo:long ?long
}

is therefore rendered as the image below:

Map response for SPARQL query, http://bit.ly/2v36y9t

The GeoJSON response is rendered in Leaflet with the MarkerCluster plugin. Similarly, by replacing SELECT DISTINCT with DESCRIBE, the map will also render when coordinates are available within the RDF output from the SPARQL endpoint. See here.

Furthermore, I introduced a query.kml API, which accepts the same SPARQL query parameter and outputs KML instead of GeoJSON.

The SPARQL results page now has links to download the result set in CSV for SELECT queries and RDF/XML, Turtle, and JSON-LD for CONSTRUCT/DESCRIBE, as well as links to the GeoJSON and KML responses when geographic distributions are available.