|linkedarc.net core ontology||la-ontology.ttl|
|linkedarc.net survey ontology||la-ontology-survey.ttl|
|The Priniatikos Pyrgos project ontology||la-ontology-la_pp.ttl|
linkedarc.net is designed to be ontologically neutral as any good Linked Data provider should be. All the projects that host data on the site can use different data models, the chose of which is up to the project administrator. For example, the Priniatikos Pyrgos project employs the English Heritage CRM extension as its model. The following document looks at how this interplay of models works in practice.
The first set of data that needs to be modelled is the site administration data and this is done by la-ontology.ttl. This data is in fact rather small and non complex for linkedarc.net. It simply describes the projects that are hosted on the service. The following diagram describes the hierarchy of system classes and their properties.
Each class, which is linked to a class on its left, is the sub-class of that class. For example, the Record class is a sub-class of the Thing class. Notice how the linkedarc.net system ontology does not exist in isolation of external public ontologies, as the Thing class is itself a subclass of the schema.org Thing class.
The ontology that models the Priniatikos Pyrgos data is an extension of the CRMEH ontology, which itself is an extension of the CRM. It contains many more classes and properties than the linkedarc.net system ontology, as the data that it models is far more complex.
You can see that most of the new properties have been applied to the CRMEH’s Context class. There are also a number of new classes defined, which inherit from either CRM or CRMEH classes. The inclusion of the LA_E10_RecordingMethod class and its two sub-classes, LA_E11_AmericanRecording and LA_E14_MoLASRecording reflect the fact that the Priniatikos Pyrgos project was excavated and recorded using two separate systems. The rest of the extension classes should be relatively self-explanatory.
It is to be entirely expected that models such as the CRM and CRMEH would need to be extended when applied to a specific data scenario. All situations are unique and extensions reflect this fact. As is noted in the CRM discussion, the model’s generic quality demands that it be implemented through extension.