Thursday, February 12, 2015

New Nomisma.org framework has been released

After much work, the new Nomisma.org framework has been launched into production. Not only is this a major architecture migration (moving the public UI from Apache Cocoon into Orbeon), but a data migration. We have implemented a new data model for IDs that conforms to the Nomisma ontology that Karsten Tolle has been working on for at least two years. IDs have a more stable system of classes that will improve the predictability of queries. There are presently 16 classes by which IDs are defined--most of them in the nmo: (http://nomisma.org/ontology#) namespace, but we are using the W3C Organziation ontology for expressing roles of people and organizations (under foaf:). The ontology is still evolving, but has a carefully curated set of properties and classes that pertain to numismatics. Certain URIs (like nm:mint), will never again be used simultaneously as classes and properties. In fact, all of the URIs that were used as classes and properties have been made instances of nmo:NumismaticTerm. Instances of mints (like Rome or Athens) are an nmo:Mint, and nmo:hasMint is the property to use for linking a coin or coin type to a mint URI. The ontology and data conform to standards established by the semantic web and computer science communities.

Data dumps from museum collections (like the ANS and Berlin) have been migrated into the Nomisma ontology, as have RDF exports from online type corpora, like OCRE and CRRO. This involved updating Numishare's code to export in the new ontology (see http://nomisma.org/documentation/contribute for example), as well as update SPARQL queries and the XSLT for reading latitude and longitude in the new model for mints. Mints are now reckoned as concepts (carrying the skos:Concept class, as well as nmo:Mint) that may or may not have a spatial feature, linked with geo:location. The object links by the geo:location is a geo:SpatialThing which may either have a latitude and longitude or have geoJSON encapsulated in the osgeo:asGeoJson property. Complex shapes, represented as geoJSON, can be drawn in Nomisma's XForms-based editing interface (powered by Orbeon). geoJSON objects created in OpenLayers in the editing interface are extracted by Javascript and incorporated into the XForms engine.

The new features of this framework are almost two numerous to mention, but here is a synopsis:

  • IDs are available in their native RDF/XML, but also serialized into Turtle and JSON-LD. IDs for regions that may contain complex geoJSON polygons are exported in geoJSON-LD. These serializations are linked from the ID page. Data dumps of all IDs are available in these three serializations as well.
  • Spatial queries are supported by extending Fuseki to interact with a Solr index.
  • Much improved browse interface allows for additional filtering by roles of people/organizations and sorting. These filters can be applied to the Atom feed as well.
  • Content negotiation is supported for IDs, the SPARQL endpoint, and the browse page. See http://nomisma.org/apis#access for more information about interacting with IDs and Solr. The SPARQL endpoint supports text/html, text/csv, text/plain, application/sparql-results+json, and application/sparql-results+xml.
  • RIC and RRC ids have been deprecated by Nomisma, as OCRE and CRRO maintain up-to-date and better quality versions. HTTP 303 See Other redirects are established for any ID that contains a dcterms:isReplacedBy property that links to something else. See http://nomisma.org/id/rrc-44.5
  • We have begun documenting the model and example SPARQL queries. The documentation will evolve to become more comprehensive in the coming months.
  • The system in general is far more stable and efficient now that RDF/XML has replaced XHTML documents. It reduces the need for additional transformation when delivering web services. More than 90% of HTTP requests for Nomisma content comes from machines (about 30,000 per day).

3 comments:

  1. Looks great! Forgive me if this is covered somewhere, but is there an ability to return a map with results (i.e. list all the hoards / findspots for a mint), or is this something can only be done after downloading the relevant results? If so, do you have an example query for this functionality?

    ReplyDelete
  2. I thought I typed a reply, but it disappeared.

    We used to offer this functionality in the old nomisma, but on account of IGCH Greek hoard content data purged from the nm: namespace, it has been temporarily disabled. We will deploy IGCH into its own framework soon (by the end of this week), so I'll restore these more detailed maps. We may also extend the functionality to offer maps for other types of ids, like the distribution of Augustus coins or denominations like denarii.

    At the moment, the only way to get findspots for a mint is to construct a query. However, this is only useful for a small handful of Roman mints active during the Republic (since most findspot data we have are for Republican coin hoards). Although, if you do include lat and long in your query and download as CSV, you can drop it right into Google Fusion Tables to render a map.

    I'm hoping that we can organize some workshops to allow people to get hands on experience crafting these sorts of queries and using Fusion Tables for basic visualization.

    ReplyDelete
  3. Thanks for the info - I am certainly looking forward to the IGCH drop

    ReplyDelete

Note: Only a member of this blog may post a comment.