Wednesday, September 13, 2017

SPARQL-derived IIIF Manifests for Coin Types

Building on Numishare's new IIIF manifest functionality, I have extended this feature to support the generation of a manifest for the IIIF resources for physical coins associated with coin types. The coin type manifest is generated in much of the same way as other queries for related coins: a SPARQL query, with the exception that the results are restricted only to physical specimens connected to IIIF services, according to the EDM extension.

The query is here: https://gist.github.com/ewg118/d4833fc0f61c17f84c723dcb3a7fe901

The metadata for the manifest are still derived from the typological information within the coin type NUDS document, but each canvas object is transformed from the SPARQL results for each coin.

The challenge here is that different organizations have different standards for packaging their obverse and reverse photographs. Most of our IIIF partners (including the ANS) have a separate image file for both the obverse and reverse, but several (like Harvard Art Museums) have combined the obverse and reverse photos into a single image file. In order to present the most cohesive and intuitive display of the manifest within a IIIF viewer, I opted to represent each coin rather than each image as a canvas (and incorporated collection, identifier, weight, diameter, and axis metadata within the canvas). Therefore, I experimented with generating a canvas as wide as the width of both the obverse and reverse images and placing both images on the same canvas, with the reverse image as a segment with its top left corner aligning with the top right corner of the obverse image. This is done by specifying placement and dimensions of the canvas:

"on": "http://gallica.bnf.fr/ark:/12148/btv1b10323768v#xywh=2646,0,2646,2646"

However, I have found that neither Universal Viewer nor Mirador support this functionality out of the box yet, even though it is valid according to the IIIF Presentation API. It does work in Masahide Kanzaki's IIIF viewer built on OpenSeadragon.



You can see an example of the Price 112 manifest rendered here: http://www.kanzaki.com/works/2016/pub/image-annotator?u=http://app1.numismatics.org/pella/manifest/price.112

IIIF coverage will be expanded significantly across PELLA, OCRE, and CRRO once the new version of Mantis goes live in the next one or two weeks. There is now a link at the top of each coin type page (when applicable) to the IIIF manifest.

Thursday, August 31, 2017

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.

Tuesday, August 22, 2017

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.

Tuesday, June 20, 2017

Experimenting with 3D integration in OCRE

The Wild West of 3D Capture in Cultural Heritage


The lowered technical barriers and costs of 3D capture (especially photogrammetry) within the museum and archaeology domains has seen an explosion of 3D data within the cultural heritage sector. The Smithsonian X 3D and British Museum (led by Nomisma scientific committee member, Dan Pett) endeavors are among the best recognized efforts in this area, but 3D cultural heritage models (from artifact scans to excavation trenches and entire sites) are being published to the web by many organizations through a wide variety of information systems. Many organizations have turned to Sketchfab as the primary mode of publication, but others are using home-grown systems. In truth, 3D publication is the wild west. There aren't even readily agreed-upon open standards for the models themselves, let alone metadata standards, publication frameworks or APIs for accessing models/metadata (in contrast to 2D images through IIIF standardization).

As such, integration of 3D data back into the scholarly research ecosystem has fallen very far behind 3D production capacity. We have seen that Sketchfab models can be embedded into web-based news articles or blogs (such as the Telegraph article above or Sarah Bond's recent post on Forbes), which have been an excellent medium for making these resources available to a general audience. However, we cannot overlook the fact that these are also valuable resources to a scholarly audience, and this audience isn't going to poke around various universities' institutional repositories or Sketchfab profiles for relevant 3D data. Numismatists studying Roman imperial coinage use Online Coins of the Roman Empire, and if there are 3D models of Roman coins, they should expect to access that material through OCRE and not Sketchfab directly. The same goes for Greek pottery experts and Kerameikos.org. Scholars more broadly interested in the ancient world may access 3D objects through Pelagios and more general audiences (both academic and public) may interact with these objects through Europeana or DPLA.

I have high hopes that the 3D GLAM community (including commercial entities such as Sketchfab) will move toward open standards for the dissemination of these data. Taking Greek pottery as an example, 3D models are much preferred over 2D photography for viewing inscriptions and iconography, and if 3D models can be annotated following the same standards we see in IIIF (Open Annotation RDF), scholars will be able to view all objects depicting Dionysus, regardless of the 2D/3D medium of capture.

Sketchfab models in OCRE, a Proof of Concept


The coin cabinet of Heinrich-Heine-Universität Düsseldorf, a Nomisma partner through the NUMiD network of German university coin cabinets, recently uploaded three models to Sketchfab: a Roman provincial coin showing the damnatio memoriae of Geta, an imperial coin of Severus Alexander (RIC IV 455), and an imperial coin of Constantine (RIC VII Constantinople 126). The latter two coins have already been integrated into OCRE, and so I set forth on the task of incorporating triples for the 3D models into the RDF for these two coins.


Fortunately, two librarians at the University of South Florida, Xiying Mi and Bonita Pollock, have put forth a useful proposal at ALA (see Linked Metadata for 3D-Models: From Dublin Core to Europeana Data Model) to capture some basic 3D model metadata and associate this information with the cultural heritage object.

Since we have already implemented the IIIF extension for the Europeana Data Model in Nomisma, it was fairly straightfoward to link to a 3D model in much the same manner by using the edm:isShownBy property to link to the Sketchfab URI, which is cast as an edm:WebResource class. This edm:WebResource carries some additional metadata about the model itself, including the capture process (photogrammetry as a dcterms:format linking to a Getty AAT URI, etc.).

A 3D model of a coin of Severus Alexander, shown in OCRE
These data model adaptations were followed by some updates to Numishare's underlying SPARQL query and UI scripts to render the 3D model, when available. There is a conditional within the Javascript to use an iframe to embed the Sketchfab model when the edm:WebResource is a Sketchfab URI. So far, there's only one condition for rendering. Ultimately, the scripts will read the mime-type from the RDF metadata and use an open source JS 3D library accordingly (such as Universal Viewer).

This of course is predicated on the cultural heritage community coming to an agreement on open standards for 3D models and APIs for accessing these models and associated metadata. In this endeavor, I see myself as a consumer of 3D--not for my own research purposes, but as a technical developer building middleware for scholars to access the models to achieve their needs. In my role as a consumer, I hope to be able to steer the content producers and architects of 3D information systems onto a path that results in the greatest potential for reuse and synthesis.

Thursday, June 8, 2017

Updates to symbol/monogram pages in OCRE

I have just pushed some changes to symbol and monogram pages in OCRE, which are more broadly applied to Numishare. Up to this point, we have published several dozen late Roman monograms from RIC 10 and a small handful of Siscia Officina marks from RIC 8. The data underlying these symbols are in RDF, conforming to the Nomisma ontology and data model. The web pages displayed little more than a list of metadata about the symbol, but no further context. Altogether, these pages weren't particularly useful as scholarly tools.

Map of Marcian monogram 1

Following updates to Nomisma, I have implemented two new features on symbol pages:

  1. A map showing the distribution of mints and findspots (a heatmap layer showing all findspots and individual layers for finds and hoards). The geoJSON APIs in Nomisma were extended to support SPARQL queries for geographic data by passing a 'symbol' request parameter. See http://nomisma.org/apis#getMints, for example.
  2. A list of coin types that bear these symbols, with available images, when available. The list of types is downloadable as CSV, and the user can click a button to view the underlying SPARQL query, which could be copied, modified, and submitted directly to Nomisma's endpoint (see below).

Coin types that show Marcian monogram 1

Below is the SPARQL query for getting a list of types associated with a monogram, with some basic metadata:

SELECT ?type ?label ?startDate ?endDate ?mint ?mintLabel ?den ?denLabel WHERE {
  {
    SELECT ?side WHERE {
     ?side nmo:hasMonogram <%URI%>
    }
  }
?type ?prop ?side
   MINUS {?type dcterms:isReplacedBy ?replaced}
   ?type a nmo:TypeSeriesItem ;
   skos:prefLabel ?label FILTER(langMatches(lang(?label), "en")) .
   OPTIONAL {?type nmo:hasStartDate ?startDate}
   OPTIONAL {?type nmo:hasEndDate ?endDate}
   OPTIONAL {?type nmo:hasMint ?mint . 
    ?mint skos:prefLabel ?mintLabel 
       FILTER(langMatches(lang(?mintLabel), "en"))}
   OPTIONAL {?type nmo:hasDenomination ?den . 
    ?den skos:prefLabel ?denLabel 
       FILTER(langMatches(lang(?denLabel), "en"))}
}

Since these features are now inherent to Numishare, they will be available for the enormous array of Greek monograms that will be published as part of the Hellenistic Royal Coinages project. I hope to have a prototype of a few monograms published in PELLA within the next few weeks.

As more and more Nomisma partners adopt IIIF, these monogram URIs will form a basis for image annotation, and eventually these symbol pages will use Open Annotation and IIIF APIs to display photographic examples of monograms, in addition to a print and web-ready idealized SVG renderings.

Friday, May 19, 2017

Nomisma measurement analysis interface ready for wider testing

I have been working on and off for the last month or two on a new quantitative analysis feature in Nomisma, which is available on pages for certain types of Concepts (that are associated with coin types that have been ingested into Nomisma) as well as on a new page, http://nomisma.org/research/metrical.

Much like the distribution analysis interface, the user can select multiple dataset groupings to compare for average weight or average diameter. Optionally, and like the existing features in OCRE, CRRO, and PELLA, the user can input a start date and end date and an interval of 5 or 10 years in order to visualize the change in average weights over time. The parameters established in the web form are used to query a web service, which interacts with Nomisma's SPARQL endpoint and serializes the response into JSON for visualization.

Average weight of denarius (red), aureus (yellow), and antoninianus (blue) from 100 BC to AD 300. See for yourself.

What separates this interface from the feature that is built into Numishare projects (like OCRE) is that the weights are drawn from all relevant coins, regardless of an explicit connection to a coin type defined by a URI published by OCRE or similar project. This means that coins from Antike Fundmuenzen Europa or other finds databases that do not have positively identifiable RIC numbers can be queried alongside those that do, as long as those relatively uncertain coins still have some certain attributes, such as authority or denomination. Moreover, these interfaces allow the querying across related, but separate datasets--e.g., to evaluate the change in average weight of denarii from 100 B.C. to A.D. 100, even though the denarius coin types are split between OCRE and CRRO starting about 27 B.C.

The raw data can be downloaded as CSV for further analysis, visualization, or publication, and the chart for the metrical analysis page can be reproduced easily by bookmarking the resulting URL.

Weight of Augustan denarii from Rome compared to Lugdunum


Known Limitations

The metrical analysis feature is still a working proof of concept that will be refined and enhanced over time.

First, we do encounter coins that are either cataloged with the wrong RIC number or the automated matching script erroneously interprets a reference into the wrong RIC number, so the weights of these coins may have an effect on the overall average for a query. I think, in most cases, the margin of error is quite small.

The charts are visualized with a d3.js plugin called d3plus. There's an error in the handling of BC dates (according to the ISO spec), and so (in interval queries), the dates are converted to an integer value. So -100 is 100 B.C. and 200 is A.D. 200. As a result, the d3plus line graph cannot be set as a timeline, and therefore date ranges that do not contain weight data are removed from the chart. It is important to be able to visualize gaps in weights, as these gaps may illustrate periods where coin types conforming to a query were not issued (for example, there is no weight data for aurei from 70-50 B.C.).

One last thing to note is that I have not been able to manually override the x-axis labels, so -100 actually means 100 B.C. to 96 B.C. when the interval is set to five years (not just 100 B.C.). The human readable date range is still available when hovering the mouse over a point in the chart and in the CSV download.

Next Items

Aside from minor alterations that should come when d3plus's B.C. date glitch is fixed, I plan to expand beyond average weight and diameter to showing weight+diameter as a cluster as well as standard deviation for measurements, which should be more illustrative of coins that do not conform with the norm, enabling them to be eliminated from further weight query, while also flagging them to collections as potentially erroneously attributed coins, counterfeits, partial specimens, or other such aberrations.

Friday, May 12, 2017

Extending Nomisma geoJSON for Temporal Data

The geoJSON output for queries for findspots and hoards associated with Nomisma.org concepts has been updated with the geoJSON-T extension, including closing or burial dates of hoards or individual finds, when known. Additionally, the properties following the geoJSON-T proposed model for gazetteer toponyms and URIs, e.g.:


{
      "type": "Feature",
      "label": "Meolo (Albaredo d'Adige) (Italy; ME2)",
      "id": "http://numismatics.org/chrr/id/ME2",
      "geometry": {
        "type": "Point",
        "coordinates": [
          11.27843,
          45.31859
        ]
      },
      "when": {
        "timespans": [
          {
            "start": "-0038",
            "end": "-0038"
          }
        ]
      },
      "properties": {
        "toponym": "Albaredo d'Adige (Italy)",
        "gazetteer_label": "Albaredo d'Adige (Italy)",
        "gazetteer_uri": "http://www.geonames.org/3183350/",
        "type": "hoard"
      }
    }


Furthermore, the getFindspots, getHoards, and heatmap APIs have been updated to accept a coinType request parameter instead of an id parameter in order to get relevant geographic data associated with coin type URIs, rather than associations with Nomisma-defined numismatic concepts. This is the first step in the eventual overhaul of the mapping features in Numishare coin type projects (like OCRE) to render geoJSON-T in Leaflet, finally retiring the TimeMap plugin that has not seen active development in at least four years.