OpenArchaeo: A Semantic Web Portal Applied to Archaeological datasets

OpenArchaeo: A Semantic Web Portal 1 Applied to Archaeological datasets 2 3 Florian HIVERT1, Olivier MARLET2, Béatrice MARKHOFF2 4 5 1 UAR 3501 Maison des Sciences sociales et des Humanités Val de Loire – Université de Tours, France 6 2 UMR CNRS 7324 CITERES Laboratoire Archéologie et Territoires – Université de Tours, France 7 8 ABSTRACT 9 OpenArchaeo is a semantic-web platform dedicated to archaeology, developed by the 10 Huma-Num MASAplus consortium, to federate archaeological information scattered in 11 a large number of heterogeneous silos, thus building links between datasets. 12 When conceptualising the OpenArchaeo platform, a solution was devised by using a 13 semantic model based on the CIDOC CRM, representing the key entities in field 14 archaeology. Information relating to places, chronology, people or physical object 15 typology uses controlled vocabularies such as PACTOLS, GeoNames, PeriodO, 16 IdRef, VIAF or ORCID, ensuring that each dataset contains disambiguated information 17 and scientific terms that are shared and reusable by the community. Datasets in 18 OpenArchaeo are thus structured as knowledge graphs in RDF and managed in an 19 online triplestore providing a SPARQL endpoint, which is hosted by Huma-Num. 20 An intuitive visual querying interface was developed for OpenArchaeo, then made 21 generic under the name Sparnatural by the Sparna company. Sparnatural allows 22 users to interact with the triplestore without specific knowledge, neither of the ontology, 23 the underlying model, nor of SPARQL. Users query the triplestore using the 24 archaeological concepts they are used to manipulate. 25 OpenArchaeo is an innovative and powerful open-source application that enables data 26 published as knowledge graphs to be used not only by machines but also directly by 27 archaeologists, thanks to Sparnatural. This portal of open data increases the value of 28 research data by making it easy to find and access, in line with the first FAIR principles. 29 In addition, thanks to the use of semantic technologies and standard domain 30 ontologies, the datasets in OpenArchaeo are accessible via a single access point, 31 interoperable thanks to the CIDOC CRM ontology and controlled vocabularies, and 32 reusable by applications via the triplestore access point. 33 In this paper we present the ontological model OpenArchaeo relies on, how it guides 34 the workflow for generating knowledge graphs from legacy datasets, what offers 35 Sparnatural, and what are the other portal's features, in particular how it allows to 36 jointly query several knowledge graphs. 37 38 Keywords: Semantic Web, CIDOC-CRM, Ontology, Controlled Vocabulary, Archeology, 39 Cultural Heritage, Linked Open Data 40 Introduction 41 OpenArchaeo is a semantic-web platform dedicated to archaeology, developed by the Huma42 Num MASAplus consortium, to federate archaeological information scattered in a large number of 43 heterogeneous silos, thus building links between datasets. 44 When conceptualising the OpenArchaeo platform, a solution was provided by using a semantic 45 model based on the CIDOC CRM, representing the key entities in field archaeology. Information 46 relating to places, chronology, people or physical object typology uses controlled vocabularies 47 such as PACTOLS, GeoNames, PeriodO, IdRef, VIAF or ORCID, ensuring that each dataset 48 contains disambiguated information and scientific terms that are shared and reusable by the 49 community. The data is thus structured as a knowledge graph in RDF format and managed in an 50 online searchable triplestore, which is hosted by Huma-Num. 51 However, querying a triplestore can be complex, as it involves using the SPARQL language to 52 query the data graph. In addition, some choices in the semantic model, justified by the goal of 53 integration and interoperability (making links between datasets), make it complex to query. Some 54 information often seen as simple attributes of an entity may in fact be represented by a chain of 55 properties in the CIDOC CRM model. 56 An intuitive visual interrogation interface was developed for OpenArchaeo, then made generic 57 under the name Sparnatural by the Sparna company. This solution was initially inspired by the 58 interface proposed by ResearchSpace for the British Museum. It is an intuitive visual semantic 59 interrogation system. Sparnatural allows users to interact with the triplestore without any specific 60 knowledge of the ontology, the underlying model, or the SPARQL language. Users can query the 61 triplestore using the archaeological concepts they are used to manipulate, and the application 62 transforms these concepts into their ontological equivalents to generate the SPARQL query. 63 OpenArchaeo is an innovative and powerful open-source application that enables data 64 published as knowledge graphs to be used not only by machines but also directly by 65 archaeologists, thanks to Sparnatural. This portal of open data increases the value of research 66 data by making it easy to find and access, in line with the first FAIR principles. In addition, thanks 67 to the use of semantic technologies and standard domain ontologies, the data presented in 68 OpenArchaeo is accessible via a single access point, interoperable thanks to the CIDOC CRM 69 ontology and controlled vocabularies, and reusable by applications via the triplestore access point. 70 We present OpenArchaeo in this paper in order to get more feedback from the community, to 71 assess the relevance of Sparnatural's configuration, to improve the dataset integration process, 72 and to refine the query system, in order to improve the services offered by the platform, increase 73 the number of corpora available and the number of users of these corpora. The rest of this paper 74 is structured as follows: we first present the ontological model on which OpenArchaeo relies, and 75 how it guides the workflow for generating knowledge graphs from legacy data. Then we present 76 Sparnatural, after which we explain the portal's features, in particular how it allows to query several 77 federated knowledge graphs, before concluding. 78 A model for a common structure and a common expression 79 The initial work of MASAplus was to support archaeological researchers in publishing their data 80 on the Semantic Web, but this firstly meant starting by making the data accessible as resources 81 on the Web. When this data was put online, it was found to be very heterogeneous in terms of 82 systems, structures and vocabularies. Standardising the vocabularies was a priority for MASAplus, 83 because the concepts used in these corpora need to be aligned with reference systems for the 84 data to be interoperable (places, individuals, periods, subjects and themes). The use of 85 OpenRefine free software was invaluable in this task: in addition to data cleaning and 86 homogenisation processes, OpenRefine offers several solutions for enriching data with various 87 reference systems (GeoNames, Pactols, IDRef). 88 However, the heterogeneity of the vocabulary is not the only pitfall: although most of the 89 databases deal with the same archaeological concepts, there is a great variety of structures in 90 these datasets that makes creating interoperability bridges between each structure difficult. 91 Datasets come in the form of XML files, relational databases or tabular files, each with its own 92 structure defined by the researcher or project that produced it. Although the main subjects of these 93 datasets may be similar, the heterogeneity of their formats, structures, and models hinders the 94 ability to query them simultaneously. To facilitate the aggregation of heterogeneous datasets, a 95 common data structure had to be created. 96 When the OpenArchaeo platform was being designed, the chosen solution has been to 97 implement a generic model extracted from CIDOC CRM, the ontology ecosystem for cultural 98 heritage (Bekiari, Bruseker, Doerr et al. 2024). The relevance of the choice of CIDOC CRM no 99 longer needs to be demonstrated, since it is used by most European projects on heritage or by 100 major institutions such as the BnF or the British Museum (Niccolucci, Felicetti 2018). The model 101 implemented for OpenArchaeo is an extraction of the CIDOC CRMbase and a few extensions: 102 CRMsci for scientific observations, CRMarchaeo for field archaeology and CRMba for 103 archaeological buildings. It represents the key entities of the archaeological domain, such as 104 archaeological sites, archaeological finds/excavations, artefacts, stratigraphic units, buildings, 105 archaeological features (walls, graves, postholes, pits, etc.) and archaeological documentation 106 (e.g. record sheets, photographs, drawings). This model, presented in detail below, can be 107 downloaded (in OWL format) from the Catalogue page of the OpenArchaeo portal. 108 109 110 Figure 1 - OpenArchaeo CIDOC CRM generic model including only key entities. 111 Main classes and relationships in the OpenArchaeo model are the discovery (or excavation), 112 the site, the person responsible for the operation, the location, the structure, the archeological 113 feature, the stratigraphic unit, and the archaeological material (Figure 1). On this basis, each entity 114 can be identified, named, typed, and described, and can also be documented and dated, leading 115 to a complete generic model for describing most of archaeological data (Figure 2). 116 117 Figure 2 - Complete OpenArchaeo CIDOC CRM generic model. 118 Thanks to the methodology behind the CIDOC CRM ontology, the creation of relationships 119 between each identified key entity leads to an enrichment of the data structure. In this way, some 120 information, although only implicit in the source, is represented, formalized and used in the 121 modelling. An example is the representation of the dating of a piece of artefact, which would 122 correspond to a simple “date” attribute in a more conventional structure, but which becomes a set 123 of several entities in the CIDOC CRM model (Figure 3). 124 125 Figure 3 - CIDOC CRM modelling of dating for physical entities in the OpenArchaeo model. 126 These entities specify that an event linked to this piece of artefact is dated, most often 127 interpreted as its use, and that this event is linked to a time interval, which can finally be specified 128 as having one or more dates, depending on the dating method used in the source or the event to 129 be dated (production, use, discovery, etc.). For example, a coin does not in itself have a date. The 130 date it bears, sometimes engraved, is that of its production (entry into circulation), but the 131 archaeologist will only retain a post-quem date and will indicate in his database the dates of use 132 of the coin (from its production to its disappearance). However, in the database, the archaeologist 133 generally only indicates “date” for the field name, which is too ambiguous. With a CIDOC-CRM 134 based model, the date is necessarily linked to an event (a temporal entity), itself linked to the 135 artefact; the artefact cannot be directly associated with a date. This is an important contribution of 136 the CIDOC: forcing the implicit to be made explicit. 137 Over and above this apparent (but relevant) rigidity, the CIDOC also offers a degree of flexibility 138 that makes it possible to adapt to the various situations that can be encountered in archaeological 139 datasets, in particular because of the scales of representation that can vary. For example, in a 140 corpus of field recordings, we will specify that the artefacts were found in a stratigraphic unit, 141 possibly in a feature, itself in a structure and itself in a site. On a regional study scale, which 142 produces an inventory of the material found on archaeological sites, we will not necessarily specify 143 the stratigraphic units or the features in which the material was found. Semantically, it is simpler in 144 certain corpuses to define that the excavation of a site did indeed exist if a piece of artefact is 145 linked to the site, despite the absence of information about the excavation, than to infer in which 146 stratigraphic unit the artefact was found, if the information is not present. 147 In addition, in many databases the event of excavation or discovery is not explicitly indicated 148 and associated artefacts, archaeological features and structures are directly linked to the site. This 149 combines the two notions of site and operation in the same concept, which can sometimes be 150 justified for practical reasons when an archaeological site is only concerned by a single operation, 151 but this is not always the case. The model represents this event (excavation, discovery) with the 152 S19 Encounter Event class, which is either induced or represented in the archaeological data. 153 In addition, although the content of a dataset may be more specific than the entities in the 154 CIDOC CRM model, it can still be described using one of these entities. In this way, the CIDOC 155 CRM model can aggregate objects that are deeply differentiated in their original sources. For 156 example, in CIDOC, the notion of a trail left by humans (E25 Human-made Feature) is generic and 157 encompasses features (pits, postholes, ditches), but also burials or walls (including the foundation 158 trench). It is therefore necessary to distinguish between them, as most archaeological datasets 159 treat these elements as different concepts. In the CIDOC model, precision is then provided by 160 typing (E55 Type): a type is associated with each element (feature, wall, burial), based on a 161 vocabulary/thesaurus defining each of these terms. It should be noted that the notion of “feature” 162 is described by excluding other more specific features such as burials and walls (which are 163 themselves also features). 164 Similarly, the absence of specific entities to represent ceramics, lithic elements or coins is 165 compensated by the possibility of typing a generic entity to specify its original nature (see Figure 166 4). In the example in this figure, the object (named ‘Monnaie’ in French) is an E22 Human-made 167 Object whose type is ‘coin’ (as defined by nomisma.org) which is itself an E55 type in CIDOC. 168 169 Figure 4 - Representation of a coin in CIDOC-CRM. 170 The OpenArchaeo generic model uses this representation to preserve the specific details of 171 each object, or the type expressed in the source dataset, with controlled vocabularies such as 172 Pactols and the Getty AAT. This approach not only enriches the data with alignment work but also 173 ensures the interoperability of datasets within the Semantic Web, thanks to a common structure 174 provided by the CIDOC CRM generic model, and a common expression provided using controlled 175 vocabularies and other referentials. For entities such as places, periods, people or organisations 176 we use referential resources such as GeoNames, PeriodO, IdRef, VIAF or ORCID, which ensure 177 that each knowledge graph contains disambiguated information and common scientific 178 expressions in their domains. 179 Thanks to these two data modelling methods (the description of events and the characterization 180 of generic classes by external controlled vocabularies), each dataset can be cross-referenced 181 conceptually through the fundamental questions: Who, What, How, When, Where and Why. To 182 apply them, a workflow has been conceptualized, where the transformation of heterogeneous 183 datasets into a homogeneous knowledge graph is described in the form of steps. This workflow 184 has been published in the DARIAH SSH Open Marketplace (Figure 5). It enables field records 185 such as ArSol, excavation inventories such as Archaeology in Greece Online (École française 186 d'Athènes) and other French aggregators such as ArkeoGIS to be expressed in the same structure 187 and with the same expression, making OpenArchaeo a powerful portal for accessing 188 archaeological data (Marlet, Roulet, Hivert, Markhoff, Rodier et al. 2021). 189 190 Figure 5 - MASA+ Consortium workflow for publishing data on OpenArchaeo. 191 To ensure that this workflow runs smoothly, there are two important data cleansing and 192 enrichment stages, prior to the mapping stage with the CIDOC CRM model. These steps make it 193 possible to eliminate incorrect entries in the data, align it with the controlled repositories or 194 vocabulary, and, if necessary, specify in the data the entities represented in the CIDOC CRM 195 model. The OpenRefine free software perfectly fulfils all these functions. In addition to these 196 important steps, the data must be published online, so that the URLs of each entity can be used 197 as a resource, and the source of this information can be referenced on the Web. The matching 198 stage between the structure of the dataset and the OpenArchaeo generic model involves defining 199 correspondences between their respective schemas. These definitions are then used by RDF 200 graph generation scripts (knowledge graphs). In the case of an XML dataset, the Mapping Memory 201 Manager (3M) platform developed by the ICS-FORTH team (Heraklion, Greece) can be used. For 202 a relational database (mySQL, postgreSQL, etc.), an Ontop extension for Protégé can be used. 203 MASAplus has published tutorials for each of these cases. Once the knowledge graph has been 204 generated, checks are carried out using SHACL rules, which correspond to the ontological model 205 while specifying the constraints to be checked (the ontological model is intended for logical 206 reasoning, whereas the SHACL rules are for validating data). OpenArchaeo's SHACL rules can be 207 downloaded from the portal's Catalogue page. The validated knowledge graph can then be put 208 online using a triplestore. OpenArchaeo uses the GraphDB solution, and Huma-Num hosts this 209 knowledge graph manager and server. From here, a client application can send a SPARQL request 210 to the server and receive the elements queried in the knowledge graphs in response. For humans, 211 OpenArchaeo integrates Sparnatural. 212 Sparnatural: A solution for easing querying of the Semantic Web 213 Querying a triplestore can be a complex process, as it involves using the SPARQL language, 214 with which many researchers are unfamiliar. In addition, some ontologies, such as CIDOC CRM, 215 can enrich the data model to such an extent that it becomes difficult for researchers to find their 216 way around, due to the complexity of class and property names, or the subtleties of the model 217 itself. The model built is based on key entities in the field of archaeology, but the expression of 218 these entities differs greatly in their CIDOC CRM representation: a piece of an artefact becomes 219 an entity in the E22 Human-Made Object class, an archaeological features becomes an E25 220 Human-Made Feature entity and an excavation/discovery becomes an S19 Encounter Event 221 entity. Without mentioning the multilingual concerns (since CIDOC CRM presents its labels in 222 English only), translation between the common expressions of the domain and the CIDOC CRM 223 classes proves difficult without explanation of the model. In addition, simple information, often 224 accessible via a single property or attribute, may require two or three properties in the CIDOC 225 CRM model (see Figure 2), leading to confusion not of expression but of structural order. The user 226 must be familiar with the ontology, the model, and the interpretations chosen during the modelling 227 stage to understand how to query the knowledge graph. 228 In addition, the use of Semantic Web technology requires the knowledge graph produced to be 229 hosted, not in a traditional database management system or in an XML file index, but in a 230 triplestore. The RDF format in which the knowledge graph hosted on the triplestore is expressed 231 requires a query using the SPARQL query language. When known, this query language can be 232 used to trace the RDF triplets contained in the graph and obtain information according to the 233 desired result. Writing the SPARQL language is like expressing RDF triples in a computer file and 234 requires a certain technical knowledge of both the RDF format and the operation of a triplestore, 235 particularly its endpoint (the interface used to query the triplestore). After all, the endpoint is the 236 whole point of using a triplestore. This solution enables any system or user to request the contents 237 of a triplestore via an URL, generally provided by the triplestore itself. The content is then made 238 accessible and reusable on the Web, but also interoperable, provided that the ontology and 239 repositories used to describe the content are standard in the domain. 240 The use of these technologies creates a major accessibility problem, not in a machine context, 241 but in a user context. The knowledge, notions and concepts assembled to build a system using 242 Semantic Web technologies create an obstacle to the user taking advantage of the interoperability 243 induced by such a system. The Semantic Web's position as a technological niche adds to these 244 difficulties, through a lack of support solutions, some of which already exist, but which are often 245 obsolete or abandoned before completion. 246 An intuitive visual query interface was developed for OpenArchaeo and then made generic 247 under the name Sparnatural by the company Sparna. This solution was initially inspired by the 248 interface proposed by ResearchSpace for the British Museum and was developed as a semantic 249 data querying system for end users. Sparnatural allows users to interact with the triplestore without 250 needing specific knowledge of the ontology, the underlying ontological model, or the SPARQL 251 language (Figure 6). The Sparnatural application is developed in JavaScript and is open source. 252 It has since been reused, notably by the National Archives with the RIC-O ontology and cataloging 253 Huma-Num's Nakala resources. In OpenArchaeo, Sparnatural is integrated into an Explorer page, 254 which allows cross-referencing all datasets, and into specific pages for each dataset (search 255 limited to the graph produced for that dataset). 256 257 Figure 6 - Sparnatural query interface of the OpenArchaeo platform. 258 Sparnatural implements this method through a configuration file, written as an intermediate 259 ontology, which interprets each part of the knowledge graph contained in a triplestore according 260 to user needs. Writing this configuration still requires all the knowledge from the modelling process, 261 but it reduces the problem by bringing back the competency question. The key entities of 262 archaeology, defined during the modeling process of the OpenArchaeo generic model, are then 263 re-introduced into the configuration to appear clearly during user querying. Thus, each CIDOC 264 CRM class and their relationships can be interpreted according to the familiar terminology of the 265 domain. For example, an object associated with the Human-Made Object class in the generic 266 CIDOC CRM model is reinterpreted, as conceptualized in the modeling, as an artefact in the 267 OpenArchaeo portal. Sparnatural translates the artefact selected by the user into the 268 corresponding E22 Human-Made Object class and sends the SPARQL query directly to the 269 triplestore via its endpoint (see Figure 6). 270 The same approach is applied to relationships, allowing users to select connections such as 271 "artefact found in an excavation," which is then translated using the appropriate classes and 272 properties to recreate the path in the CIDOC CRM model. Thanks to this method, shortcuts can 273 be created, avoiding the complexity of the model expressed with an ontology like CIDOC CRM. 274 The representation of the dating presented earlier (Figure 2) adopts a form more commonly 275 accepted in computer systems, reducing the multiple RDF triples composing the CIDOC CRM 276 modeling into a single property in the configuration, simply named "is dated" (Figure 7). 277 References 405 Bekiari, Bruseker, Doerr et al. (2024). Definition of the CIDOC conceptual reference model, version 406 7.1.3, CIDOC CRM Special Interest Group. https://cidoc407 crm.org/sites/default/files/cidoc_crm_version_7.1.3.pdf 408 409 Christoki, Doerr, Felicetti, Hermon, Hiebel, Kritsotaki, Masur, May, Ore, Ronzino, Schmidle, 410 Theodoridou, Tsiafaki et al. (2024). Definition of the CRMarchaeo. An extension of CRMbase 411 to support the archaeological excavation process. Version 2.1.1, CIDOC CRM Special Interest 412 Group. https://cidoc-crm.org/sites/default/files/CRMarchaeo_v2.1.1%28site%29.pdf 413 414 Doerr, Kritsotaki, Rousakis, Hiebel, Thodoridou, Velios et al. (2023). Definition of the CRMsci. An 415 extension of CIDOC CRM to support scientific observation. Version 2.0, CIDOC CRM Special 416 Interest Group. https://cidoc-crm.org/sites/default/files/CRMsci-v.2.0%20%282%29.pdf 417 418 Marlet, Francart, Markhoff et Rodier (2019). OpenArchaeo for Usable Semantic Interoperability, in 419 : Poggi Antonella - Proceedings of First International Workshop on Open Data and Ontologies 420 for Cultural Heritage (ODOCH) co-located with the 31st International Conference on Advanced 421 Information Systems Engineering (CAiSE 2019), Rome, Italy, June 3, 2019, Sapienza 422 University of Rome, Rome. http://ceur-ws.org/Vol-2375/paper1.pdf 423 424 Marlet, Roulet, Hivert, Markhoff, Rodier et al.(2021). On using the CIDOC CRM to model 425 archaeological datasets. CAA2021 - Digital Crossroads, Juin 2021, Limasolle (virtual), Cyprus. 426 halshs-04199967 427 428 Niccolucci et Felicetti (2018). A CIDOC CRM-based Model for the Documentation of Heritage 429 Sciences. 2018 3rd Digital Heritage International Congress (DigitalHERITAGE) Held Jointly 430 with 2018 24th International Conference on Virtual Systems & Multimedia (VSMM 2018), 1-6. 431 https://doi.org/10.1109/DigitalHeritage.2018.8810109 432 433 Ronzino, Niccolucci, Delicetti, Doerr et al. (2016) Definition of the CRMba. An extension of CIDOC 434 CRM to support building archaeology documentation. Version 1. 4, CIDOC CRM Special 435 Interest Group. https://cidoc-crm.org/sites/default/files/2016-12-3%23CRMba_v1.4.1_UR.pdf 436 437 Wilkinson, Dummontier et al. (2016). The FAIR Guiding Principles for scientific data management 438 and stewardship, Scientific data 3.1: 1-9. https://doi.org/10.1038/sdata.2016.18 439