I have recently worked on extending the geographic query functionality in the new Nomisma prototype. It took a few days of fiddling around and testing, but it was altogether a painless operation. First it required reading the (excellent) spatial query documentation for Apache Fuseki, which is the SPARQL endpoint that we have been using in Nomisma for nearly two years. I actually had not upgraded Fuseki since launching it into production in the early months of 2013, and so I had to update from 0.2 to 1.1 across the board in order to enable spatial queries--on the Nomisma production server, on the American Numismatic Society production server (Fuseki powers the interlinking of the Society's archival records in Archer), and on my two development machines at home.
Fuseki's configuration can be extended to use Lucene or Solr as the spatial index. The latter made a lot of sense because Solr is already an integral part of the architecture of most of our digital projects. The Solr index in Nomisma powers the basic facet-based search/browse interface and the Atom feed. I found an older email on the Jena list with an example configuration TTL file that I was able to modify.
After successfully configuring the spatial index, I initially learned that I was not able to use my current index for extending Fuseki. That is because only main Nomisma concepts are indexed, and not the geo:SpatialThing objects associated with mints and regions. The browse interface would be confusing if you received results for both nm:rome and nm:rome#this, the geographic feature associated with the concept of the mint of Rome. As a result, I spun up a new index for storing the URIs and coordinates for the geo:SpatialThings only, and this facilitated spatial queries that delivered results that I expected.
This is a dramatic leap forward in the types of geographic queries we can do in Nomisma, as we can get query results within a bounding box or within a certain distance of a point. Once we begin connecting larger numbers of coins with findspots into the system, we'll be able to do heatmaps showing geographic distribution and a variety of other visualizations. If we ingest other forms of GIS data, such as roads, springs, shrines, etc., we can query for hoards and finds within X meters of the geographic feature.
The example below is a query that will get mints within 50 km of Athens (by giving the lat and long of the city).
You can test it yourself in the Nomisma prototype.
Fuseki's configuration can be extended to use Lucene or Solr as the spatial index. The latter made a lot of sense because Solr is already an integral part of the architecture of most of our digital projects. The Solr index in Nomisma powers the basic facet-based search/browse interface and the Atom feed. I found an older email on the Jena list with an example configuration TTL file that I was able to modify.
After successfully configuring the spatial index, I initially learned that I was not able to use my current index for extending Fuseki. That is because only main Nomisma concepts are indexed, and not the geo:SpatialThing objects associated with mints and regions. The browse interface would be confusing if you received results for both nm:rome and nm:rome#this, the geographic feature associated with the concept of the mint of Rome. As a result, I spun up a new index for storing the URIs and coordinates for the geo:SpatialThings only, and this facilitated spatial queries that delivered results that I expected.
This is a dramatic leap forward in the types of geographic queries we can do in Nomisma, as we can get query results within a bounding box or within a certain distance of a point. Once we begin connecting larger numbers of coins with findspots into the system, we'll be able to do heatmaps showing geographic distribution and a variety of other visualizations. If we ingest other forms of GIS data, such as roads, springs, shrines, etc., we can query for hoards and finds within X meters of the geographic feature.
The example below is a query that will get mints within 50 km of Athens (by giving the lat and long of the city).
SELECT * WHERE {
?loc spatial:nearby (37.974722 23.7225 50 'km') .
?mint geo:location ?loc ;
skos:prefLabel ?label .
FILTER langMatches (lang(?label), 'en')
}
You can test it yourself in the Nomisma prototype.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.