One of the outputs from the Pilot Study was an approach to working with geospatial data within the broader framework provided by the CIDOC CRM ontology and the CRMEH archaeological extension. Whilst there is ongoing work by myself and others to add archaeological and spatio-temporal components directly to the CIDOC CRM, for the purposes of the GSTAR project, a lightweight approach has been developed and deployed to suit the needs of the project; CRMEH already adds archaeological excavation capabilities and the spatial extension presented here gives a range of geospatial capabilities, as provided by a mapping to GeoSPARQL.
Parential Advisory by Michel Dumontier
Research Context
For the purposes of the GSTAR project, there is a need to be able to incorporate into semantic resources rich geospatial data representing depictions of archaeological features, sites and monuments, also boundaries of activities and events plus locations where objects were discovered. Whilst the CRMEH was developed with spatial information at its core, this has not, to date, been formally expressed. This is now possible using GeoSPARQL.
During the early stages of the GSTAR project, related work became apparent, notably two extensions to the CIDOC CRM (of which CRMEH is itself an extension) pertaining to spatio-temporal information (CRMgeo) and archaeological excavation information (CRMarchaeo). These will ultimately offer greater research potential but the mapping presented here can be seen as an example of a simple, lightweight solution targeting the ‘low hanging fruit’ so often talked about with respect to ontologies and Linked Data; a mapping which meets the needs of the GSTAR project, retains compatibility with the CIDOC CRM and GeoSPARQL standards and provides core geospatial functionality for CRMEH albeit without the reasoning power (and associated complexity) of the two aforementioned extensions.
Application within GSTAR
The semantic resource will be used through the Case Studies planned for the GSTAR project to investigate the use of geosemantic tools for archaeological research. Two of these are focussing on the integration aspect, looking at what I have defined as ‘horizontal’ and ‘vertical’ integration using the spatial components of source data. Horizontal integration refers to linkages between inventories, ie from site finds inventories to museum object inventories to sites and monuments inventories. Vertical integration refers to linkages between primary and derived data, from fieldwork databases containing records of features and finds up to inventories of higher order data objects containing records derived from these primary observations.
Related Work I – CRMgeo
Work is ongoing to produce a spatio-temporal model through integration of GeoSPARQL and CIDOC CRM: the CRMgeo extension, currently in draft form. This promised to be an incredibly powerful resource capable of advanced spatio-temporal description and reasoning.
The work is described as follows:
CRMgeo is an extension for the CIDOC CRM to provide an “articulation” (linkage) between the standards of the geospatial and the cultural heritage community in particular between GeoSPARQL and CIDOC CRM. The model was developed from the analysis of the epistemological processes of defining, using and determining places. This means that we analyzed how a question, such as “is this the place of the Varus Battle” or “is this the place where Lord Nelson died”, can be verified or falsified, including geometric specifications. Consequently, we reached at a detailed model which seems to give a complete account of all practical components necessary to verify such a question, in agreement with the laws of physics, the practice of geometric measurement and archaeological reasoning. This model indeed appears to have the capability to link both ontologies and shows the way how to correctly reconcile data at any scale and time – not by inventing precision or truth that cannot be acquired, but by quantifying or delimiting the inherent indeterminacies, as it is good practice in natural sciences. This model aims at being a comprehensive theory from which mutually compatible simplification can be derived for implementations in more constraint environment, such at those lacking moving frames.
Related Work II – CRMarchaeo
Similarly, work is ongoing to produce an archaeological excavation model: the CRMarchaeo extension, currently in draft form. This promises to support description of and reasoning about archaeological excavation information from a range of recording methodologies.
This project is described as follows:
CRMarchaeo is an ontology and RDF Schema to encode metadata about the archaeological excavation process.
The goal of this model is to provide the means to document excavations in such a way that the following functionality is supported:
- Maximize interpretation capability after excavation or to continue excavation Reason of excavation (goals). What is the archaeological question?
- Possibility of knowledge revision after excavation
- Comparing previous excavations on same site (space)
- All kinds of comprehensive statistical studies (“collective behavior”)
My contribution to CRMarchaeo is running in parallel to my work on the CRMEH. Whilst ultimately there will need to be some decisions as to which extension to use for new projects and resources, there is currently a fair amount of data out in the wild which uses CRMEH and at least until CRMarchaeo is finalised and probably longer, there will be some co-existence of these two complimentary models. After all, the two models are very much related and oversight has been maintained to ensure a good degree of compatibility between them.
A lightweight mapping
A decision was made to create a lightweight mapping of CRMEH to GeoSPARQL rather than implement a combination of CRMarchaeo and CRMgeo for three main reasons:
- Firstly, these extensions are centred on the core CIDOC CRM ontology rather than the CRMEH extension. As CRMEH is being used for the GSTAR project, their use would have required a mapping process anyway to ensure compliance.
- Secondly, both of these ‘emerging’ standards are currently in draft form, in the process of being finalised and formally adopted. As such, they are not fixed yet and subject to review, improvement and change; Some components in particular still require more work to completion.
- Finally, the degree to which the advanced features offered by these extensions could be made use of through the GSTAR project is uncertain. A lightweight mapping can be seen as an 80% or 90% solution, covering most eventualities and avoiding the overheads associated with the rather more complex extensions. But retaining overall compatibility.
Mapping rationale
The key spatial components needed are already present in CRMEH. There are two main components covering excavation data: the Context (aka Stratigraphic Unit; the atomic unit of archaeological recording) and the ContextDepiction (a depiction of the Stratigraphic Unit, typically a polygon shown in plan view). A Context is related to a ContextDepiction through the property Depicts / Is Depicted By with a Context being depicted by one or more depictions.
These extend from the core CIDOC CRM: the CRMEH class Context (EH0007) is a subclass of Place (E57) whilst ContextDepiction (EH0022) is a subclass of Place Appellation (E44). In GeoSPARQL, there are also two classes to describe spatial information with Features having some representation in the form of Geometry. There is a good alignment here between the CRMEH classes (or indeed the parent CIDOC CRM classes) and the GeoSPARQL classes, allowing the ontologies to be linked as described in the GeoSPARQL User Guide written by Dave Kolas and Robert Battle.
This is illustrated in the following diagram:
Alignment of CRMEH classes and properties with GeoSPARQL classes and properties
As shown in the diagram, the rdfs:subClassOf, rdfs:subPropertyOf and rdfs:isA relationships can be used to link the two ontologies. This maps the necessary classes and also allows instances of Context Depictions to behave as Simple Features as used within GeoSPARQL.
From mapping to RDF
This mapping allows Contexts to be depicted by one or more pieces of geometry, each instance of a ContextDepiction making use of an OGC Simple Features type (Point, Line, Polygon, etc) and represented using one of the standard formats, in this case WKT.
The mapping can also be applied at the broader CIDOC CRM level and inherited by the CRM EH (and other) classes and properties if this is advantageous.
With respect to data, resources can be created very simply by adding the class inheritance relationships once to a given resource then creating appropriate assertions relating to the ContextDepiction. This means in practice, GIS data can be converted very easily using a variety of tools (eg StringTemplate, Java(script), Python, VB or even Microsoft Excel) to produce suitable RDF of whatever flavour (ntriples, turtle, etc) ready for ingestion into a triple store.
An example of this for a single ContextDepiction is shown below:
@prefix crmeh: <http://purl.org/crmeh#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix gstar: <http://ld.gstar.archaeogeomancy.net/content/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sf: <http://www.opengis.net/ont/sf#> .
crmeh:EHE0007_Context rdfs:subclassOf geo:Feature .
crmeh:EHP4i_is_depicted_by rdfs:subPropertyOf geo:hasGeometry .
gstar:crmeh_EHE0022_123 a crmeh:EHE0022_ContextDepiction .
gstar:crmeh_EHE0022_123 a sf:Polygon .
gstar:crmeh_EHE0022_123 rdfs:label "Polygon Depiction of Context 123" .
gstar:crmeh_EHE0022_123 crmeh:EHP4_depicts ads:EHE0007_123 .
gstar:crmeh_EHE0022_123 geo:asWKT "<http://www.opengis.net/def/crs/EPSG/0/27700> POLYGON ((569170 169503,569170 169503,569170 169503,569170 169503,569170 169503,569170 169503,569170 169503,569170 169503,569171 169503,569170 169503,569170 169503,569170 169503,569170 169503,569170 169503,569170 169503))"^^sf:wktLiteral .
In the example (above), namespaces are shown in blue, subproperty/subclass relationships to be defined once in green and the block of RDF to be used for each ContextDepiction in red. NB The GSTAR namespace houses a WISSKI installation, currently not configured and acting as a placeholder only; the URIs do not resolve.
A working system
The system used for the Pilot Study took GIS data from the ADS archives, processed it as above and loaded it alongside the CRMEH RDF encoding and Erlangen CIDOC CRM RDF encoding. This was then successfully tested using a range of OGC spatial operators, SPARQL and GeoSPARQL queries.
Conclusions
For a fuller account of this, please see the Transfer Report when that is published more widely. Or wait a while longer for the thesis (due 2016).
In summary, whilst emerging standards building on the CIDOC CRM covering geospatial and archaeological excavation are forthcoming, a simple, lightweight approach can also be deployed for this use case to give a good range of functionality without the complexity, albeit sacrificing some semantic richness.
The mapping described here could also be applied directly to the parent CIDOC CRM classes/properties (rather than the child CRMEH classes/properties used here) to give a more generic linkage to GeoSPARQL suitable for use in a broader range of cases.
The post Extending CRMEH with GeoSPARQL appeared first on Archaeogeomancy: Digital Heritage Specialists.
