Sign in





In the last section we introduced the CIDOC CRM. One of the objectives of the CRM is to allow for its extensibility and that is exactly what we are now going to talk about in the context of the English Heritage CRM extension and which is known as the CRMEH. This extension was created primarily by Ceri Binding and Keith May to allow for the modelling of archaeological excavation and post-excavation data that was being produced by EH teams. EH, as with most archaeological units in the UK, use the Single Context excavation and recording methodology that has been championed and codified by the Museum of London Archaeology group. The reason that I am going to explain the model now in some detail and why I decided to implement it in the first place is that the Single Context method was used in the excavation of Priniatikos Pyrgos, the archaeological site that provides the initial dataset for the site and following the principle that data that is modelled using an existing public ontology is more valuable than data that is modelled using a custom ontology, the CRMEH seemed like the obvious candidate.

As the CRMEH extends the CRM, it naturally mirrors the latter’s structure and aims. Therefore, it is constituted of entities and properties that link these entities and entities often take the form of events. For example, the ContextFind entity is linked to the ContextFindMeasurement entity via the ContextFindMeasurementEvent entity and the CRM’s P39_measured and P40_observed_dimension properties.

The CRMEH is complex

Here is a diagram showing the relationships that exist between the various entities in the CRMEH extension (with thanks to Ceri Binding for providing the diagram).

The CRMEH diagram As you can, the CRM and its extensions can be complex beasts. The event model espoused by the CRM undoubtedly increases this multi-level complexity. For instance, a flat Object Orientated model might contain a central class that defines an archaeological unit and that class could have properties for dimensions of the unit in which numeric data is stored. The CRMEH models that same semantic fact as a four-level chain starting with a Context entity, going through a ContextStuff and ContextStuffMeasurementEvent entity and ending up with a ContextStuffMeasurementUnit entity.

The Context and other entities

The Context entity is central to the CRMEH. This is unsurprising as the context forms the core of the Single Context system as well. As noted above, the CRMEH model is a multi-level hierarchy, with the numerous entities that make up the model gravitating out from the central semantic axis of the Context.

Other important entities are the ContextEvent, which groups information relating to the formation of the context, the ContextExcavationEvent, which groups data about the excavation of the context, the ContextStuff entity, which represents the physical material that the context is actually composed of, and the ContextRecord and ContextSheet, which are related to the recording of the context. Contexts are associated with larger spatial entities that might be trenches or sites in the form of SiteSubDivision and Group entities. Contexts in turn contain ContextFind entities that represent finds that are made within their limits. There are also entities that describe imagery relating to the context and a number of entities that deal with archaeological science, sampling and finds processing.

Dealing with the CRMEH’s complexity

When these entities and their real world correlates are all listed, it is perhaps unsurprising that the CRMEH is so multi-layered and complex. Archaeology is after all a complex and multi-facetted practice. The CRMEH attempts to take in most of these various sub-categories of activities and so its holistic approach has created a complex network of entities and interactions. Once understood it is a pliable and powerful tool in the modelling of Single Context archaeological data. However, one cannot but wonder whether some of its completeness might have been sacrificed in the name of readability and usability.

Next learn about custom ontologies and extensions to the CRM.