Practices of Linked Open Data in Archaeology and Their Realisation in Wikidata

Abstract

In this paper, we introduce Linked Open Data (LOD) in the archaeological domain as a means to connect dispersed data sources and enable cross-querying. The technology behind the design principles and how LOD can be created and published is described to enable less-familiar researchers to understand the presented benefits and drawbacks of LOD. Wikidata is introduced as an open knowledge hub for the creation and dissemination of LOD. Different actors within archaeology have implemented LOD, and we present which challenges have been and are being addressed. A selection of projects showcases how Wikidata is being used by archaeologists to enrich and open their databases to the general public. With this paper, we aim to encourage the creation and re-use of LOD in archaeology, as we believe it offers an improvement on current data publishing practices.

1. Introduction

Legacy data is ubiquitous in Archaeology because excavations are not reproducible, and therefore their original records are always relevant. It exists in analogue and digital form. The latter can be born-digital or digitised and comes in a variety of formats [1]. Surveys show that after completion of a project, data is often saved on local networks or servers provided by the employer, and rarely in professional repositories [2,3,4], which is also due to national legislation not always requiring deposition of data with professional repositories [5]. Data and databases that have been published online are often hard to find and/or inaccessible ([6] pp. 133–136). They are not always managed by IT professionals, complicating their integration into follow-up research. As the special issue of Internet Archaeology (58, 2021) [7] shows, the state of development of digital repositories is diverse, with some regions of the world having a well established infrastructure, while others are just beginning a transformation. Richards et al. conclude:

“To be successful, archaeology needs not only better policies for data curation, but also the harmonising of the processes of data creation and its deposition for archiving.” [1]

Here, we propose one building block towards the solution to these problems: Linked Open Data (LOD). LOD is part of a vision for the World Wide Web [8,9] that aims at connecting openly available datasets and facilitating machine analysis by applying a standardised technology stack. LOD enables the combination and joint processing of existing data from various digital sources to address archaeological research questions. Since LOD by its definition (cf. Section 2) is interoperable, we believe that archaeology data and metadata adhering to LOD standards can effectively be combined and integrated into follow-up research and increase the findability and interoperability of published data on the Web.

With this paper, we would like to encourage the creation and use of LOD by offering an accessible entry point to the use of LOD and a bridge between Digital Humanities practitioners and less technically proficient researchers. To this end, the use and creation of LOD within recent projects that re-use and add data to Wikidata [10] is described. Wikidata acts as a linked data hub and readily provides extensive multidisciplinary LOD and respective user-friendly tools. The presented projects demonstrate the potential of LOD together with Wikidata and exemplify common challenges in turning legacy data into LOD. They cover a variety of sub-disciplines, dealing with Early Neolithic European ceramics, Roman terra sigillata, Irish Early Medieval inscribed stones, and bibliographic data about Aegean Bronze Age seals and sealings. We argue that the Wikidata ecosystem greatly simplifies the provision of highly connected LOD, regardless of its provenance and legacy status.

The remainder of this contribution is structured as follows: The next section provides an introduction to LOD and related concepts, general pointers to LOD creation and publication, and a more in detail description of Wikidata and the creation of LOD with Wikidata. The section concludes with an overview of the benefits and challenges of LOD. Next, we describe in brief the adoption of LOD in archaeology by building upon already published summaries [11,12] before presenting and discussing five Wikidata projects. The inline links given in the text have been accessed last 02 June 2022.

2. Understanding Linked Open Data (LOD)

The overall aim of LOD is to provide openly available online data sets that are interlinked and allow for cross-querying to, e.g., address archaeological research questions. To fully understand what LOD is, we will briefly present some of its core building blocks: Semantic Web, Linked Data (LD), and Open Data. A more in-depth coverage of the topic from a humanities perspective is given in, e.g., [13,14].

Before moving on, it has to be understood that LOD is not a data model, but a design principle for providing data with a standardised technology stack in its background. Data modelling (semantic and conceptual) ideally precedes exposing data as LOD. Comparable alternatives to LOD include publishing data in structured and standardised formats or allowing access via programming interfaces (Web APIs), which often lack comprehensibility of the data and their underlying schema, accessibility as well as share-ability, and hinder data integration [15]. Other alternative developments include Microformats and Dataspaces ([16] pp. 13–15). The former adds structured data directly in HTML but only has a restricted vocabulary and leaves integrated data without identifiers ([16] p. 13). The latter is a small-scale LOD approach for databases that might eventually contribute to LOD ([16] p. 15).

The Semantic Web is a term introduced by Tim Berners-Lee in 1998 ([8] p. 157) [17,18], that refers to a World Wide Web not only accessible to humans but also processable by machines, i.e., a web with machine-readable information. For information to become machine-readable, it needs to be annotated (also: marked up or tagged) with metadata. This metadata adds the semantic meaning to data and links, which makes them processable by computers without human intervention ([19] p. 89) [20]. For this purpose, the World Wide Web Consortium (W3C) provides standardised technologies [21], e.g. the Resource Description Framework (RDF) [22] as a data model for the representation of data and the SPARQL Protocol and RDF Query Language (SPARQL) [23] as a language to query data represented in RDF.

Let us take the Wikipedia article about the Phaistos Disc [24] as an example (Figure 1), which renders an informative text with various sections, tables, and images to the human user. While a human can easily read where the disc was found, a machine cannot do this because the underlying facts and information such as the statement ‘The Phaistos Disc was found at the site of Phaistos.’ are buried in sentences like “The disc was discovered in 1908 by the Italian archaeologist Luigi Pernier in the Minoan palace-site of Phaistos, [...]” [24]. In the Semantic Web, the underlying information contained within these sentences is represented in RDF.

In RDF [22], data is represented as a directed graph consisting of statements about resources. The statements are expressed as triples in the form subject—predicate—object, where the subject is the resource that is being characterised or described. The statement from our example above can be expressed in a simple triple consisting of a subject (‘The Phaistos Disc’), an object (‘the site of Phaistos’), and the predicate (‘was found at’) that specifies the relationship between subject and object:

Example 1.

$$\begin{array}{ccc}\hfill \left(\mathit{The}\mathit{Phaistos}\mathit{Disc}\right)\hfill & \hfill -\mathit{was}\mathit{found}\mathit{>at}->\hfill & \hfill \left(\mathit{the}\mathit{site}\mathit{of}\mathit{Phaistos}\right)\hfill \\ \hfill subject\hfill & \hfill predicate\hfill & \hfill object\hfill \end{array}$$

In Example 1 the predicate—or RDF property—is directed from the subject to the object and the respective triple can be visualised as a directed and labelled graph as shown in Figure 2.

The predicate from Example 1 already represents a link between two resources. In fact, Tim Berners-Lee foresaw the linking of data as a core principle of the Semantic Web:

“The Semantic Web is not designed just as a new data model—it is specifically appropriate to the linking of data of many different models. One of the great things it will allow is to add information relating different databases on the Web, to allow sophisticated operations to be performed across them”. [25]

According to Berners-Lee [9], LD is created by complying with four rules:

• Resources (or things) being described should be named with URIs, a universal form of URLs.
• The URIs used, should be HTTP URIs, to enable looking up the URI names.
• Useful information should be provided using standards, such as RDF* (i.e., the entire family of RDF standards [26]) and SPARQL.
• Links to other URIs should be included.

The last rule is what allows humans and machines alike to explore the ‘Giant Global Graph’ also called the ‘Linked Open Data Cloud’ [27] or ‘Web of Data’, which are other terms used for the Semantic Web (also known as ‘Web 3.0’) or ‘Linked Data’.

The application of the first two of the four LD rules to Example 1 leads to the graph in Figure 3. The individual parts of the statement are now represented with HTTP URIs coming from Wikidata. The subject (‘The Phaistos Disc’) is indicated with https://www.wikidata.org/entity/Q465338, the object (‘the site of Phaistos’) with https://www.wikidata.org/entity/Q249707, and the predicate (‘was found at’) with https://www.wikidata.org/entity/P189.

Before applying LD rules three and four, we introduce the concept of namespaces [28], which are used to shorten the URI notation in Figure 3 by replacing the URI part ‘https://www.wikidata.org/entity/’ with a short prefix like ‘wd:’. This allows for a simpler visualisation of Example 1 as shown in Figure 4.

LD rule number 3 requires the application of standards, such as RDF, and the provision of useful information [9]. While our example is already represented in RDF, the very little information given by the statement is not very useful yet. This can be improved by adding properties to further characterise our resources, that is the subject, the object and also the predicate from Example 1. We could, e.g., add a label and a type. Depending on the type, we could add a property indicating the material or the geographic coordinates. Which properties can be used for distinct types of resources and how they can be related is formalised with a set of rules called an ontology [29]. When needed, a list of allowed terms for the description of resources can be defined in a controlled vocabulary [30]. For both ontologies and controlled vocabularies, widely used standards exist, including dedicated ones for cultural heritage and archaeology mentioned in Section 3.

Adding further information to the statement of Example 1 results in the larger graph in Figure 5. The initial triple is now embedded in a network of triples and we can see that the resource representing our initial subject ‘wd:Q465338’ has the label ‘Phaistos Disc’ and is an instance of the class ‘wd:Q220659’. The latter represents another resource, which itself is further described with properties, such as the label ‘archaeological artifact’. This means our subject ‘Phaistos Disc’ is classified as an ‘archaeological artifact’. The object in an RDF triple can either be another resource or a plain literal. As can be seen for the case of ‘wd:P189’ (location of discovery) in Figure 4, properties are also resources that can be further described with, e.g., their labels used in Figure 5.

To complete our LD example, we shall now apply the fourth rule, which calls for links to other URIs. While links are already present, they all point to internal resources, i.e., all resources linked to are stored in the same namespace (wd), representing Wikidata. However, as Berners-Lee states, links to external sources are “necessary to connect the data we have into a web, a serious, unbounded web in which one can find al[l] kinds of things” [9].

A record for the Phaistos Disc can also be found in the object database iDAI.objects arachne (Arachne) [31]. The URI for the record is https://arachne.dainst.org/entity/2436227 and with the namespace ‘ar:’ replacing ‘https://arachne.dainst.org/entity/’ we get a link to the resource ‘ar:2436227’ in Figure 6. Similarly, we can proceed with an external link for the place Phaistos, which has the URI https://pleiades.stoa.org/places/589987 in Pleiades [32,33] and is now represented as ’pl:589987’ in Figure 6. With these additional external links, records from different data bases are now connected and can be analysed jointly.

Finally, we come to what constitutes Linked Open Data (LOD). The prerequisites include LD, as explained above, and the concept of Open Data. The Open Definition [34] defines ‘open’ as: “anyone is free to access, use, modify, and share” the data, limited only by measures to preserve provenance and openness. This definition implies that data as a whole is provided openly and with free access in an open format that can be processed with at least one free/libre/open-source software tool (e.g., CSV [35]). Furthermore, the definition stresses that data should be machine-readable, i.e., it “must be provided in a form readily processable by a computer and where the individual elements of the work can be easily accessed and modified”, and—if the data is not already in the public domain—it must be provided under an open license, such as the Creative Commons licenses [36] CC BY 4.0 or CC0.

In short, LD becomes LOD when it is free for anybody to access, use, modify, and share it. Differently put, LOD is LD released under an open license. LOD that complies with these requirements is also referred to as five star LOD [9].

2.1. Creating and Publishing LOD

This section provides general pointers on how to create and publish LOD before describing in more detail what Wikidata is and how LOD publication can be achieved with it. Dedicated practical guides from a humanities perspective with recommendations for specific tools include [13,37,38].

The W3C [39] has identified ten steps for the creation and provision of LOD, which can be summarised as having four activity areas: planning, choosing and curating the dataset, data modelling, and publishing and maintaining LOD. Planning for LOD includes defining the overall aim of the project, assessing the overall needs and required expertise, as well as identifying suitable tools and resources to be used ([38] p. 5). When choosing a dataset, licensing, re-use potential, and quality of data should be considered. The latter can be improved by curating, cleaning up, and refining the dataset ([38] pp. 6–7).

Data modelling is a process consisting of determining the external resources to link to, choosing and applying a model for knowledge representation, and converting the data to the chosen schema as well as to a suitable linked data format ([38] pp. 7–15). Modelling for LOD also involves defining how data represented in one model, such as a local spreadsheet or a relational database model, are going to be transformed into the chosen knowledge representation model ([39] Step #3). It is best practice to use a well-known and standard knowledge representation model (i.e., an ontology) ([38] p. 11) ([39] Step #6) for LOD instead of creating a new bespoke ontology, as the latter can lead to data silos and limit the re-usability of LOD [40].

Finally, the prepared dataset can be served to the public in various ways ([37] Thing 8) ([38] p. 15), e.g., as a simple downloadable file (a so-called ‘data dump’) or a full-fledged RDF database (a so-called ‘triplestore’, a database system for graph-data represented in RDF) with a dedicated SPARQL endpoint (e.g., a website for receiving and processing SPARQL queries) for querying the data. Offering an RDF triplestore means that the ‘self-hosted’ URLs used as identifiers in the triples have to be provided in a persistent way.

After publication maintenance is required, which not only includes maintenance of the used hard- and software framework but also of the data itself. Data maintenance includes tasks like taking care of broken links and applying corrections and updates to the dataset itself.

LOD with Wikidata

Providing LOD requires significant effort when done with a custom framework and database. Given the time and cost constraints many humanities and especially archaeology projects face, using ready-made solutions can immensely help in providing standardised LOD without much additional effort. One of these solutions is the use of Wikidata, which is already used for science and research [41].

The open knowledge base Wikidata [10] was established in 2012. It acts as a central storage for structured data of other Wikimedia projects including Wikipedia, Wikimedia Commons, or Wiktionary. Wikidata is a secondary database, which does not only record statements but also their sources, as well as connections to other databases. Data within Wikidata can be edited and added by anybody, is multilingual and available under the free licence CC0. The data is accessible to humans and machines alike and can be exported in standardised formats like e.g. JSON [42], RDF [22], or CSV [35]. Researchers can immensely benefit from using Wikidata because of the wide range of disciplines, topics, and research areas already represented there. This facilitates the combination of different knowledge domains and allows for interdisciplinary queries on the data.

While Wikidata’s data model represented in Figure 7 is not defined in terms of RDF [43], it is still close to Semantic Web triples. The main entities in Wikidata are items and properties [44]. Items can be uniquely identified by the Wikidata Q identifier (QID), which consists of a ‘Q’ followed by a number, e.g., ‘Q465338’ from Figure 7, which identifies the item representing the Phaistos Disc. Similarly, the properties are identified by a ‘P’ followed by a number, e.g., the property ‘location of discovery’ in Figure 7 is identified by P189. Items in Wikidata are further described with statements. Each statement consists of a property and a value which can be supplied with qualifiers and references to indicate where the statement comes from and narrow the scope of a statement, e.g., state when a population number was valid. Several properties in Wikidata are external identifiers that point to authority control files or external databases [45,46]. Examples include the properties P496 to add ORCID iDs for researchers [47], P356 to append a DOI to publications [48], or P1566 for adding GeoNames IDs [49] to places. The external identifiers help in integrating the data within Wikidata with other data sources, enabling Wikidata to act as a linking hub [50].

Wikidata is part of the LOD Cloud [51,52,53], meaning that all data included in Wikidata is already LOD and can be accessed as such [54]. Multiple options are available for accessing the data in an LOD format: querying via the Wikidata Query Service (further described in Section 4.2), downloading a full or partial data dump, or per item access via the item’s URI [54].

Contributing data to Wikidata is simply achieved by just editing existing items or adding new ones. This is possible even without an account, which is a must for batch editing (cf. Section 4.2). Due to Wikidata’s multidisciplinarity and flexibility, no specific data model is prescribed for items. Nonetheless, a project that aims at adding data to Wikidata, should take into account the used set of statements for existing items of a specific class and follow relevant recommendations to ensure that the newly added data is consistent with existing data.

2.2. Benefits and Drawbacks of LOD

LOD comes with a number of benefits, as well as some shortcomings which we will expand upon here.

Decentralised and distributed data storage is at the centre of LD and its core benefit lies in the linking of otherwise discrete data silos and the possibility to query across them, e.g., [15,38] ([55] p. 269) [56,57], regardless of the discipline [58]. This linking in particular enhances and accelerates research processes [59,60] ([61] p. 84) and aids in distributing and reducing costs, e.g., by enriching a database with little effort by referring to and re-using external data sources [15,38] ([59] p. 3). With LOD, links between free-text reports and associated data can be established, which facilitates the use of data-heavy publications such as site reports and increase their usefulness. This also enables tracking the process of interpretation and re-interpretation in different research stages [55] and to better represent complex relationships between different entities ([62] p. 5).

The required use of formal ontologies for LOD leads to self-describing and self-contained data because definitions for elements of an unknown ontology can be looked up via the provided dereferenceable URI ([16] pp. 3–4) [63] (see rules 2 and 3 in Berner-Lees 5 Star LOD, explained in Section 2.1). The use of ontologies also leads to disambiguation [63] and the formal logic of ontologies allows for computational reasoning and inferencing ([8] pp. 177–194), which enables information validation [64] or may even lead to drawing new conclusions [59,63].

LOD is represented in RDF format, which in turn represents a graph—something well suited for visualisation and exploration [57]. Graphs can easily be extended with new relations and nodes, which means that LOD is more open to further enrichment than other systems might be [15,38]. The distribution of LOD has the benefit of allowing for bespoke ontologies that fit specific needs [65]. The underlying technologies of LOD enable this by allowing a single ontology to contain links (‘mappings’) to other ontologies. Furthermore, one graph can contain elements from multiple differing ontologies.

It has been argued that digitisation without reflection and subsequent classification of data may lead to the digital resources being cemented as self-evident in later archaeological discourse and that this effect might be intensified by the use of LOD ([62] p. 5). We believe, though, that the distribution and flexibility of LOD are capable of capturing the academic discourse with varying scholarly opinions and attributions, as exemplified by the projects presented in Section 4.1.4 and Section 4.1.5.

Applying LOD is considered to enhance the discoverability of data and foster community engagement [59], but tracking actual re-use of LOD is difficult ([38] p. 3), which is why no reliable data on this topic within archaeology is available [5]. Nonetheless, as an archaeological example, the numismatic project Nomisma.org [66] has been mentioned as a success story in this regard ([61] p. 46) ([62] p. 8).

The features that make up the advantages of LOD are also behind some of the disadvantages. Due to data in Archaeology often being MEAN (Miscellaneous, Exceptional, Arbitrary, Nonconformist) [67] disadvantages are often exacerbated. Nonetheless, most drawbacks can be mitigated with adequate measures we present here.

The decentralised and distributed nature of LD leads to issues with data quality because external data is under the control of autonomous data providers with differing intentions. Thus, linked data and its metadata might be inconsistent, inaccurate, incomplete, or out of date ([61] pp. 78–79) [68]. Linking to trusted sources can lessen quality issues. For LD to be sustainable, persistent URIs are vital. Applications have failed, because a data provider changed their infrastructure, leading to thousands of dead links [69] and abandoned SPARQL endpoints ([61] p. 37) [70]. Sustainable LD infrastructures are required for the provision of stable LOD resources, which implies that short-term financed LD/LOD projects will need institutional partners with a stable infrastructure or should use well-established open alternatives, such as Wikidata (cf. Section 2.1).

Another challenge related to the distribution of LOD is that the same concept has several URIs originating from different sources, e.g., the place ‘Phaistos’ can be identified with the Wikidata URI https://www.wikidata.org/entity/Q249707, the GeoNames URI https://sws.geonames.org/262531/ or the Pleiades URI https://pleiades.stoa.org/places/589987. Data hubs, such as Wikidata, that collect multiple identifiers for their records, can help in pulling the resources together and ultimately bring LOD a step forward by connecting more sources. In addition, different sources often use different standards and ontologies to represent their resources, which makes it difficult to map resources to each other and leads to a lack of interoperability. These problems are further exacerbated when the provenance of the data has not been properly declared and vocabularies fail to adequately label and classify their containing concepts. In order to interconnect such sources and resources, a cross-disciplinary semantic alignment can be implemented, which is, e.g., an endeavour of TRAIL 4.2 of the NFDI4Objects research data infrastructure [71]. Wikidata enables the interlinking of dispersed resources with dedicated properties for external sources, thereby acting as a linking hub.

It can be challenging to find suitable ontologies or an adequate level of resolution for metadata to link differing concepts and understandings of terminology ([62] p. 6) without losing information. This holds especially true when adhering to the best practice recommendation of re-using existing ontologies (cf. Section 2.1). If a new ontology has to be created, additional effort is required to ensure interoperability by mapping it to standard ontologies.

LOD served via a triplestore can lead to performance issues when dealing with a large number of triples ([61] pp. 9–10) and this can only be mitigated with the development of other solutions or by removing a subset of the triples [72].

Creating and using LOD often requires technical skills, which not every archaeologist has or will have, as learning the technical concepts and needed programming languages is a high investment that does not yet lead to academic recognition. This is applicable to most Digital Humanities skills within the traditional humanities, see e.g., ([73] p. 358) and has to be addressed from two sides: on one side, easy-to-use tools should be provided, on another, scholars need to be trained in basic digital technologies.

When it comes to the creation and publication of LOD, the most significant investment is that of human labour ([38] p. 3), since individual steps require careful planning and might have to be re-iterated. Furthermore, the maintenance of published LOD is a continuous effort in order to adhere to the latest standards ([38] p. 4). Analysing the cost-benefit of creating LOD is difficult, as there are various factors to calculate for costs (development and mapping to ontologies, output of RDF, hosting of triplestores, etc.) as well as benefits (see above), which may be valued differently by individual stakeholders. The development of new tools, which facilitate and simplify the workflows can be expected to reduce the costs of providing LOD ([61] pp. 56-63) and we describe some of those in Section 4.2.

3. LOD in Archaeology

Drawing from different data sets, mixing and merging information from diverse sources, deriving own ideas and conclusions as well as forming new arguments based on already published material is a core practice of archaeological and historical research. Data was and often still is published in form of printed catalogues, figures, and tables. Instead of copying and publishing this kind of data anew, it is standard practice to reference the published table or figure. This practice can be expressed as an LD triple:

Example 2.

$$\begin{array}{ccc}\hfill \left(\mathit{The}\mathit{table}\right)\hfill & \hfill -\mathit{was}\mathit{published}\mathit{in}->\hfill & \hfill \left(\mathit{literature}\right)\hfill \\ \hfill subject& \hfill predicate\hfill & \hfill object\hfill \end{array}$$

It is, though, only a small part of what has always been linked. Citations of articles and monographs are links to the information given in them. Concordance lists, bibliographies, and index volumes of journals, where entries are sorted by keywords are other solutions to a problem researchers have always been faced with: finding information as the very first step in any scholarly undertaking.

With the growth of the Open Access movement, the awareness of the need for finding aids such as standardised and consistent tagging systems and indexes increases. In contrast, the ideas of Open Data and LOD are still little known in archaeology, though they can be seen as nothing but a further consequent development of good citation practices for a digital and interconnected research environment. LOD allows to entrust computers with the tedious task of information tracking and enables computational reasoning approaches ([8] pp. 177–194) [63].

LOD was first adopted by Cultural Heritage institutions, libraries, archives, and museums, before being integrated in archaeological research processes ([61] pp. 42–43). The uptake and use of LOD in archaeology have been extensively described by Leif Isaksen in 2011 [11]. He pointed out that contributions to Semantic Web technologies at the international Computer Applications and Quantitative Methods in Archaeology (CAA) conferences increased since the early 2000s ([11] p. 41 Table 2.5). An update on LOD in archaeology including a vision for its future has been provided by Guntram Geser in 2016 [12] and the Ariadne LOD SIG in 2017 [61]. This section builds on existing reviews and contributes towards completing the picture until the present day.

The first step towards LOD in archaeology was done by publishing data and metadata on online platforms, of which some have already been developed in the 1990s. Examples include the German Arachne [31], born in 1995 with a focus on providing object data, now part of the iDAI.world [74], or the Archaeology Data Service (ADS) [75] founded in 1996 in the UK for the long-term preservation of digital archaeological data [76].

In the early 2000s, a need for dedicated discipline-specific standards to combine different data collections was identified, e.g., ([11] pp. 39–40) ([12] p. 7) [77,78,79]. Dedicated ontologies, e.g., [80,81,82] as well as vocabularies, e.g., [78] were developed to close this gap.

Relevant ontologies include Lightweight Information Describing Objects (LIDO) [83], Cultural Heritage Abstract Reference Model (CHARM) and the CIDOC Conceptual Reference Model (CIDOC CRM) (ISO 21127:2014) [84]. The latter is widely used in archaeology ([12] pp. 78–79) [62]. Vocabularies relevant for archaeology include the Getty Art & Architecture Thesaurus (Getty AAT) [85] and the Forum on Information Standards in Heritage (FISH Vocabularies) [86] that include more general concepts, as well as the community-built gazetteer for ancient places Pleiades [32,33], and the public gazetteer for historical, art-historical, and archaeological periods PeriodO [87,88].

The now completed STAR (Semantic Technologies for Archaeological Resources, 2010) and STELLAR (Semantic Technologies Enhancing Links and Linked data for Archaeological Resources, 2010-2011) projects of the ADS are forerunners for the uptake of Linked Data in archaeology. Projects like these fuelled the emergence of interest groups, such as the Linked Ancient World Data Initiative (LAWDI) or the Special Interest Group for Semantics in Archaeology at CAA, which was active from 2010 until 2017. The group re-formed in 2020 as Semantics and LOUD in Archaeology (SIG Data-Dragon). Further groups aiming for increasing the visibility and usage of LOD in archaeology exist: the Pelagios Network established in 2011, has partnered with many initiatives and communities, such as Pleiades [32] or Nomisma.org [66,89], to develop linking between different resources based on the common references to places [90]. The Linked Pasts Network (and symposium) emerged from Pelagios in 2015 and contributes to the spread of LOD in the wider humanities.

In the last decade, the Semantic Web has still been a popular topic at international CAA conferences (

Table 1. Number of papers presented at CAA on semantic technologies or linked data (2012–2021). The table is a continuation of [11] (p. 41 Table 2.5) (years 2001–2011).

), with e.g., contributions in the domain of numismatics [91,92], ceramics [57,93,94], or periods [95]. Notably, the popularity of LD and LOD has significantly increased since 2018, which might be explained by the introduction of the FAIR Data Principles in 2016 [96]. The catchy acronym is used to describe a set of principles for making data and its metadata Findable, Accessible, Interoperable, and Re-usable. While not directly connected to LOD, the rules behind these principles partially overlap with LOD principles. In 2018, Linked Art introduced the concept of Linked Open Usable Data (LOUD) [97], to further include usability for human users—with an emphasis on human-readability—and thus lowering barriers to using LOD.

Important and reliable providers of LOD in archaeology are repositories dedicated to long-term preservation, such as the aforementioned ADS. A recent overview of such repositories on a national and regional level is provided in a special issue of Internet Archaeology (58, 2021) [7]. Only a few countries “have repositories with the required specialist knowledge” [1] and “most do not have persistently available data in interoperable formats” [1], which renders reliable linking impossible. The overview in [7] is skewed towards the ‘global West’ because it is an outcome of the European COST Action SEADDA (CA 18128), which is a European network (including Turkey and Israel) with international partners from Argentina, Canada, the United States, and Japan, leaving an obvious gap with missing or underrepresented partners from Africa, Asia, and South America. Steps towards data integration are being made by aggregation platforms functioning as a single entry point for searching across multiple data providers. Examples include the European Europeana (since 2008) [98] and ARIADNE Portal (since 2013) [99] as well as the US-American Digital Index of North American Archaeology (DINAA) (since 2012) [100], which links i. a. to the Paleoindian Database of the Americas (PIDBA) and the Digital Archaeological Record (tDAR) [101]. These aggregators combine different subject-specific data sources via standardised Metadata.

Since the Transatlantic Archaeology Gateway project, which created links between ADS and tDAR [102], there have been, to our knowledge, no significant attempts to connect data on a worldwide level. Therefore the national scope and the lack of interoperable data (including LOD) preclude a true worldwide cloud of archaeological knowledge. Data integration is further complicated by the employment of different workflows [103] and heterogeneity of data ([61] p. 45).

The vision developed by Geser for LOD in archaeology ([12] p. 7), in which archaeological data is interlinked with e.g. biological or geoscientific information, has not been realised yet. A survey among repository managers by ARIADNEplus and SEADDA about data management policies and practices of digital archaeological repositories shows that LD is considered an important technology: The answer “Use Linked Data to interlink own and other (meta)data” to the question “What would help the repository most for improving data access?” was selected by 43% of the respondents [5].

To conclude, we can observe a long-standing tradition of linking information in archaeology, that is being transferred into the digital space since the early 2000s. Since the 2010s there has been an EU-wide political effort towards enhancing LOD and several networks, including ARIADNE and Europeana, got funded by the European Union. Although a number of national repositories are not interlinked there are a number of successful LOD implementations. Geser’s assertion from 2016, that “To meet expectations such as automatic reasoning over a large web of archaeological data many more (consistent) conceptual mappings of databases to the CIDOC CRM would be necessary.” ([12] p. 16), still holds true today, although one might argue that any other agreed-upon standard would work as well.

4. Wikidata for Archaeology

A growing hub for researchers and volunteers interested in archaeology and LOD is Wikidata (cf. Section 2.1). Archaeological data has already been integrated and interlinked in Wikidata to a certain degree. Besides actual items, such as the period ‘Bronze Age’ (Q11761), the place ‘Olympia’ (Q38888), the object ‘Dipylon amphora’ (Q331805), the publication ‘Architecture and Consumption in the Terrace House 2 in Ephesos’ (Q102078120), or the person ‘Gertrude Bell’ (Q231360), more general items for classifying items exist. Examples include the discipline ‘archaeology’ (Q23498) or the Wikidata class ‘archaeological site’ (Q839954). Examples of Wikidata properties related to archaeology include the ‘Art & Architecture Thesaurus ID’ (P1014) to link concepts with the Getty AAT, the ‘Pleiades ID’ (P1584) to connect ancient places in Wikidata with Pleiades, or the ‘Nomisma ID’ (P2950), which is used to link coin-related items to Nomisma.org.

The driving force behind getting archaeology (and any other) data into Wikidata is the community. Teams can get organised via WikiProjects to bundle items, properties, tasks and activities concentrating on a specific topic. This section can only highlight a very small example set from the vast amount of archaeology-related data in Wikidata. A more complete overview is being collected in the WikiProject Archaeology, which includes, among others, archaeological datasets and relevant queries.

4.1. Practical Approaches to Realising LOD in Wikidata

This section presents six Wikidata-related projects pursued by the authors. They showcase how Wikidata can be used to enrich and provide digital archaeological data as LOD. First, the Linked Open Samian Ware project (Section 4.1.1) exemplifies a workflow for turning legacy data from printed collections into a relational database and into FAIR resources. Second, the Linked Open Ogham project (Section 4.1.2) showcases how to use Wikidata as an information hub to map and align different cataloguing systems of archaeological artefacts. Third, the establishment of an up-to-date bibliography on a certain topic within Wikidata is presented (Section 4.1.3). Fourth, how to reference a bibliographical entry as a source for a Wikidata statement is explained in Section 4.1.4. Fifth, the ARS3D project demonstrates how Wikidata can be used as a hub for scientific data—in this case iconographic items—referring to modelled concepts defined in external resources. At the end, a citizen science project exemplifies an easy workflow for collaborative data collection. All projects link to, contribute to, or use data from Wikidata in various ways and make use of several free Wikidata-related tools, which are presented in Section 4.2.

4.1.1. A Workflow from Legacy Data to Wikidata: Linked Open Samian Ware

The Department of Scientific IT (WissIT) at the Römisch-Germanisches Zentralmuseum (RGZM) currently focuses on the transformation of Roman ceramics data into LOD to provide FAIR data [96] and to connect distributed databases. The project is also part of the NFDI4Objects initiative [104] and describes digital resources, e.g., about ceramic objects, with authority files, gazetteers, and vocabularies, which are linked to each other via community-driven vocabulary hubs, such as Wikidata, DANTE (Eng. data hub for authority files and terminologies) [71,105,106], or domain-specific data hubs, such as archaeology.link. The RGZM WissIT works on the publication of expert data in Wikidata and on establishing bidirectional links between existing (re)sources. Geographic, iconografic and typologic items from expert databases can now be used by the research community and citizen scientists to create a common understanding of these entities. This way the dissemination of data can be maximised and new input integrated into the expert database.

The project Linked Open Samian Ware (LOSW) is based on the online database Samian Research [107]. It relies on the printed corpus ‘Names on Terra Sigillata’ [108], which documents over $200.000$ potters’ stamps and signatures. The Samian Research database was created as a statistical exploration tool for data interpretation and to provide up-to-date information including new material and revisions of existing information. The database comprises a quarter of a million potters’ stamps on terra sigillata from all over the Roman Empire. The data is actively curated by an international research community. A series of machine-readable interfaces and interoperable data formats such as a RESTful API and RDF were implemented by the RGZM WissIT [93,109,110]. The database contains (bidirectional) external links to, e.g., Pleiades, and Wikidata [111].

A reproducible workflow, presented in Figure 8, to transform Samian Ware data into LOUD [97] and FAIR data was developed to enable researchers to re-use the data [112]. The Samian Research Database grows through the input by the user community and several steps are necessary in order to normalise this source data and add it to the LOD Cloud. Entries like potters’ stamps are curated in a web application and transferred into a PostgreSQL database, from which database views are created via ColdFusion/SQL scripts. Next, these database views are exported as CSV files, which are transformed to RDF with the help of Python scripts according to the Samian Ontology. The Linked Open Samian Ware project then uses two separate sub-workflows, (i) one leading to a self hosted triplestore, (ii) the other one to the WikiProject in Wikidata. In the first sub-workflow (i) with the help of the Java Maven application, the RDF data [113] is imported into a RDF4J triplestore and links to the Linked Open Data Cloud, e.g., Pleiades and Wikidata are added. The second sub-workflow (ii) employs the QuickStatements [114] tool (see Section 4.2) to transform the CSV data to Wikidata entries.

Within Wikidata, custom classes were prepared beforehand, such as the geospatial classes ‘Samian Ware Discovery Sites’ (Q102202066, currently 3886 items included, c.f. Figure 9), production centres (kiln sites) as ‘Samian Ware Production Centres’ (Q102202026, currently 103 items included), and kiln regions as ‘Samian Ware Kilnregion’ (Q102201947, currently 11 items included). Each of the geospatial resources is also categorised as an ‘archaeological site’ (Q839954).

For inclusion of individual records, forms have been prepared with the Cradle tool [118] to ensure a consistent set of statements for the respective Wikidata items. Further properties used to describe individual resources are exemplified in

Table 2. Samian Ware in Wikidata; examples of discovery sites, production centres and kiln regions.

	Discovery Site	Production Centre	Kiln Region
QID	Rheinzabern (Q103191516)	La Graufesenque (Q102763431)	South Gaulish Samian Ware Kilnregion (Q102764958)
instance of (P31)	Samian Ware Discovery Site (Q102202066) & archaeological site (Q839954)	Samian Ware Production centre (Q102202026) & archaeological site (Q839954) & manufactory (Q380342)	Samian Ware Kilnregion (Q102201947) & archaeological site (Q839954) & Economic region of production (Q5333539)
part of (P361)	Samian Research (Q90412636)	Samian Research (Q90412636)	Samian Research (Q90412636)
located in (P706)	n/a	South Gaulish (Samian Ware Kilnregion) (Q102764958)	n/a
coordinate (P625)	49°7′5.016″ N, 8°16′41.016″ E	44°6′0.000″ N, 3°4′59.999″ E	44°4′44.666″ N, 2°36′8.561″ E
Geoshape (P3896)	n/a	n/a	SamianKilnregionSouthGaulish
exact match (P2888)	lado:samian/loc_ds_1004152	lado:samian/loc_pc_2000001	lado:samian/loc_kr_131462
Pleiades ID (P1587)	109362	n/a	n/a
Cradle form	samian ware discovery site	samian ware productioncentre	samian ware kilnregion
SPARQL query	https://w.wiki/52Tu	https://w.wiki/4pKz	https://w.wiki/4pL4

.

For further analyses easy-to-use Open Source tools have to be developed, an endeavour which, e.g., the Research Squirrel Engineers Network pursues [119,120]. One such tool is the ‘SPARQLing Unicorn QGIS Plugin’ [121] ([122] pp. 90–100) which helps to create SPARQL queries to populate QGIS vector layers. The Samian Ware data in Wikidata can be queried in QGIS using this plugin, e.g., Figure 10 shows Spanish production centres located in the ‘Spanish Samian Ware Kilnregion’ (Q103132368) loaded into QGIS.

This project shows a reproducible workflow of transforming expert databases into LOD resources for further dissemination and research opportunities.

4.1.2. Linked Open Ogham: Connecting Catalogues Using Wikidata

The Linked Open Ogham Data project [123] was started in 2019 by the Research Squirrel Engineers Network. It aims at providing and integrating legacy data from printed and digital catalogues about Ogham Stones in Wikidata, which is used as a community hub [65,122,123]. Furthermore, tools for exploring and enriching Ogham data are being created [124]. Here, we will showcase how the different concepts and descriptions pertaining to the same stone can be modelled and linked under a common denominator in Wikidata.

Ogham stones (e.g., Figure 11) are Early Medieval stones inscribed with the Ogham script created between the 6th and 9th centuries A.D. Linked Open Ogham Data primarily focuses on the digitisation and publication of the analogue Ogham stone catalogues ‘Corpus inscriptionum Insularum Celticarum’ (CIIC) by Macalister [125], ‘A Guide to Ogam’ by D. MacManus [126], and ‘An Archaeological Survey of South Kerry’ by O’Sullivan and Sheehan [127]. Information from existing online resources such as the Celtic Inscribed Stones Project (CISP) and the Ogham in 3D Project are being incorporated and interlinked as well.

The respective project page on Wikidata is the WikiProject Irish Ogham Stones. Dedicated Wikidata items created for this project include ‘Ogham Stone Concept’ (Q106602575), ‘Ogham Site’ (Q72617071), ‘Ogham Person Concept’ (Q110897921) and ‘Ogham Stones Cluster Region’ (Q110897622). As of June 2022, Wikidata contains 234 sites, 538 person concepts, 26 cluster regions, and 1238 stone concepts related to Ogham stones. Figure 12 depicts Ogham sites in Ireland.

Ogham Stones are modelled as ‘Ogham Stone Concepts’ (Q110897921) to distinguish the physical archeological artefacts from their descriptions in the analogue or digital sources. Currently, four stone concept types from four sources have a Wikidata item: ‘Ogham Stone Concept (RAS Macalister)’ (Q106602599), ‘Ogham Stone Concept (CISP Database)’ (Q106602627), ‘Ogham Stone Concept (Ogham in 3D Project)’ (Q106602633), and ‘Ogham Stone Concept (O’Sullivan & Sheehan)’ (Q111442203). The ‘Ogham Stone Concept (Research Squirrel Ogham Project)’ (Q106602643)—also known as ‘Squirrel Stone’—serves as an umbrella for Ogham stone concepts referenced in several sources. Another umbrella for Ogham stone concepts in regard to findspots is the geographical reference, the ‘Ogham Site’. A dedicated tool to view Ogham stones grouped by stone concepts and sites was developed: the Ogham Search Lookup Tool. How the different stone concepts from these sources are interlinked, can be best shown with an example like OSS 908, which is an Ogham Stone Concept by O’Sullivan & Sheehan [127]. In Wikidata, OSS 908 (Q111442223) is linked to the Ogham Stone Concept by the Research Squirrel Ogham Project 218 via the property ‘partially coincident with’ (P1382). The latter then links to related stone concepts from CIIC, CISP, and the Ogham in 3D project.

In this project, Wikidata has been used to link different resources about Ogham stones, facilitating future research on this topic. By differentiating between Ogham stone concepts as digitally described representations of the stones and the actual stones themselves, it is possible to create umbrella IDs in Wikidata that bring together differing descriptions.

4.1.3. Bibliography of Bronze Age Aegean Seals

In Section 3 we described that—although done in an analogue way—linking of information and sources in archaeology has always been part of the research process and output. An elementary tool in this regard are printed bibliographies with thematically and geographically indexed references. One problem inherent to printed bibliographies is that they cannot be easily updated in a timely manner.

The project ‘A Linked and Open Bibliography for Aegean Glyptic in the Bronze Age’ aims at closing this gap in research about Minoan and Mycenaean Bronze Age seals by including the reference information recorded in ‘A Bibliography for Aegean Glyptic in the Bronze Age’ [128] with all related keywords into Wikidata. The bibliography is part of the ‘Corpus der Minoischen und Mykenischen Siegel’ (CMS) established in 1958. Younger’s publication serves as a basis for an interactive and online bibliography that can be extended and corrected by anyone. Additional information will be included, such as links to the full text or to the digital representation of the mentioned seals in Arachne [31], as well as more recent references that are dispersed across the webpage of the CMS, the Open Library for Aegean Archaeology, and Nestor.

A dedicated web application is being developed to present all references in a user-friendly format and allow for export. Visualisations of bibliographic information from Wikidata are also provided with the tool Scholia, which include co-occurrence of topics, author networks, or citation networks for a given topic, such as ‘Aegean glyptic’ (Q58681669).

The dataset being imported consists of more than 1200 references indexed with about 500 keywords, places and periods. Automated parsing (done with AnyStyle) and extensive manual checking are required because the references are not available in a structured bibliographic format, such as bib or RIS. The dataset import is documented on a dedicated Dataset Imports page on Wikidata. Since every piece of information, such as keywords, authors, publishers or even journals, has to be represented with its own item on Wikidata, the import has to be done in several rounds. OpenRefine is used for the preparation of the data, which is then batch-processed into Wikidata with QuickStatements.

Future work in this endeavour will include adding information about the archaeological objects referred to and including cross citation information to allow for the investigation of citation networks. The former was already tested with the seal CMS XII 087 (Q61293075) which is now included as the main subject (P921) for the article ‘Seals and Script II’ (Q61292379). The latter will require significantly more work. A comparable undertaking has been done with the topic ‘archaeological excavations in Ephesos’ (Q93429379), which already provides visualisations for citation networks on Scholia.

This project exemplifies how Wikidata can be used as an open and collaborative bibliometric research tool.

4.1.4. Source Attribution of a Finds Database in Wikidata

References included in Wikidata, e.g., those described in Section 4.1.3, can be (re-)used within Wikidata as sources for statements. The project presented here represents a practical application of this mechanism.

The framework of this undertaking is a project that aims to reconstruct the development of the post-linear band cultures (post-LBK) of the 5th millennium BC in Brandenburg (North-East Germany) by analysing ceramic finds. The finds have been (in some cases varyingly) attributed to the Stroke-Band Pottery and Rössen Culture, Guhrauer Group, and Brześć-Kujawski Culture. It is intended to import the database records into Wikidata at the end of the project and to link to external vocabularies thereby adding the data to the LOD Cloud.

Sources for this project include survey results from professional and volunteer archaeologists, recent excavation documentation, archival information, and legacy information. The latter originates from finds made before 1926, where the original material was partially lost due to World War II. In order to adequately record the changes in cultural attributions of finds resulting from scholarly discourse, the database schema has to be able to properly reflect which scholar was responsible for which cultural attribution. The approach used in the database is similar to the use of references for Wikidata statements as described in Section 2.1 (Figure 13).

In the practical implementation, a relational database is developed with two schemas: One for input, which follows standards used for archaeological databases. The second schema, though, consists only of cross tables with three columns: subject, predicate, and object. These will be more easily transferred to a LOD format at the end of the project for publication in Wikidata. Upon import to Wikidata, the sources of the respective scholarly attributions will be included as references in the matching statements (Figure 14). For this to happen, the source (e.g., a journal article) first needs to be a Wikidata item, as described above in Section 4.1.3. External links are created by including Open Streetmap IDs and GeoNames for the nearest settlement of a findspot, and PeriodO [87] information for the dates given.

By creating this collection in Wikidata, it can act as an information source not just for researchers, but also for local historians and citizen scientists.

4.1.5. Iconography in Wikidata: Linked Open African Red Slip Ware

African Red Slip Ware (ARS) is a category of terra sigillata produced in the province of Africa Proconsularis, mostly in the region of modern Tunisia. ARS dates from the 3rd to the 7th century AD and is characterised by the use of relief decorations, called appliqués. These appliqués depict a large variety of topics, e.g., mythological and biblical scenes, or depictions of circus games [129]. The African Red Slip Ware digital project (ARS3D) digitised and linked information in a cooperation between the RGZM and the i3mainz [130]. A total of 336 objects in different preservation conditions were processed within the framework of ARS3D, including various vessel types as well as models and stamps for manufacturing the objects [131].

LOD provided as RDF was used to realise the FAIR principles for this dataset [112]. Wikidata serves as a secondary publication and community exchange platform for ARS and iconographic items (WikiProject African Red Slip Ware Digital). This approach enables the research community to work collaboratively on the referencing and interlinking of several iconographic typologies in combination with openly licensed images, hosted on Wikimedia Commons. Furthermore, the project profits from already present items on Wikidata, such as the iconographic items ‘Hercules’ (Q240679) and ‘Victoria’ (Q308902), which are described with several statements, including external links to, e.g., the Iconclass classification system [132].

Iconographic items, such as those of Hercules and Victoria described by Sophie zu Löwenstein ([133] pp. 457–489, 632–634) and depicted on the two bowls O.39446 and O.40718 are represented in Wikidata with the properties listed in

Table 3. African Red Slip Ware in Wikidata. Examples according to Sophie zu Löwenstein [133].

	B / FT VII	B / FT III	N / FT III (Victoria)	N / FT I (Victoria)
QID	Q110892406	Q110892402	Q110892417	Q110892415
instance of (P31)	iconographic item (Q109525730) & work of art (Q838948)	iconographic item (Q109525730) & work of art (Q838948)	iconographic item (Q109525730) & work of art (Q838948)	iconographic item (Q109525730) & work of art (Q838948)
part of (P361)	Löwenstein (2015) (Q109525632) & ARS3D project (Q105268778)	Löwenstein (2015) (Q109525632) & ARS3D project (Q105268778)	Löwenstein (2015) (Q109525632) & ARS3D project (Q105268778	Löwenstein (2015) (Q109525632) & ARS3D project (Q105268778)
has creator (P170)	Sophie z. Löwenstein (Q110454289)	Sophie z. Löwenstein (Q110454289)	Sophie z. Löwenstein (Q110454289)	Sophie z. Löwenstein (Q110454289)
collection (P195)	Mythologische Darstellungen auf Gebrauchsgegenständen der Spätantike. Die appliken- und reliefverzierte Sigillata C3/C4 (Q109525632) [133]	Mythologische Darstellungen auf Gebrauchsgegenständen der Spätantike. Die appliken- und reliefverzierte Sigillata C3/C4 (Q109525632) [133]	Mythologische Darstellungen auf Gebrauchsgegenständen der Spätantike. Die appliken- und reliefverzierte Sigillata C3/C4 (Q109525632) [133]	Mythologische Darstellungen auf Gebrauchsgegenständen der Spätantike. Die appliken- und reliefverzierte Sigillata C3/C4 (Q109525632) [133]
depicts (P180)	Hercules (Q240679)	Hercules (Q240679)	Victoria (Q308902)	Victoria (Q308902)
same as (P460)	Armstrong 8.108 [134] (Q110892542)	Armstrong 8.109 [134] (Q110892540), Atlante 135 [135] (Q110892520)	Armstrong 8.100 [134] (Q110892537)	Armstrong 8.101-103 [134] (Q110892533; Q110892534; Q110892535)
image (P18)	Löwenstein B FT VII.png	Löwenstein B FT III.png	Löwenstein N FT III Victoria.png	Löwenstein N FT I Victoria.png

. As the classification and description of a specific iconographic item depend on the scholar doing this work, multiple names for the same item might exist. This is, e.g., the case for Hercules ‘Löwenstein B / FT VII’ (Q110892406), which was also described by Meg. A. Armstrong [134] and is named ‘Armstrong 8.108’ (Q110892542). Although these two examples are included as individual items in Wikidata, they are related to each other with the property ‘said to be the same as’ (P460). Object O.40718 depicts ‘Löwenstein B / FT VII’ and ‘Löwenstein N / FT I (Victoria)’ ([133] pp. 460, 632–633), Object O.39446 ‘Löwenstein B / FT III’ and ‘Löwenstein N / FT III (Victoria)’ ([133] pp. 459, 634) shown in Figure 15.

The ARS3D project also added iconographic elements to Wikidata which are not explicitly mentioned in the literature [136]. This additional iconography catalogue is modelled in Wikidata as the collection ‘African Red Slip Ware—Additional Iconography Catalogue’ (Q111370392) and, e.g., includes ships/boats as physical items ‘G / FT I’ (Q111370381), ‘G / FT II’ (Q111372289), ‘G / FT III’ (Q111372294) and hybrids like the human-horse hybrid, ‘M / FT I’ (Q111372221). The data, especially the iconographic items, can be visualised with the Wikidata Query Service. The Service provides various display options, including an image grid as shown in Figure 16.

The data collected and published by this project can now be easily used by scholars to find and refine information on the modelled iconographic items, thereby facilitating further research.

4.1.6. Wikidata as an Open Reference Collection for Citizen Science

The projects described above, focus on Wikidata as a resource for scholars. By its open and accessible nature, the platform also lends itself well to citizen science projects. Together with a group of volunteer field walkers, a small project was designed that aimed at creating an online reference collection for the volunteers in Wikidata. The project Zerschlagenes Geschirr—Archäologische Quellen in Wikidata (‘Smashed dishes—archaeological sources in Wikidata’) is still ongoing. It employs the Cradle tool [118] to create a form to collect information about prehistoric ceramic which enables an intuitive and standardised entry of data in Wikidata (Figure 17).

As this is a citizen science project and to keep the entry barrier low, the use of scientific jargon is avoided. Instead, e.g., the description of the decoration can be made with simple terms like ‘incision’, ‘point’, or ‘wave’ (see

Table 4. List of properties included in the form prehistoric ceramics prepared with the Cradle tool.

Property	Data Entry Options	Example: Q111600125
instance of (P31)	mandatory: archaeological find (Q10855061) and pottery ware (Q17379525)	archaeological find (Q10855061) and pottery ware (Q17379525)
made from material (P186)	mandatory: ceramic (Q45621)	ceramic (Q45621)
instance of (P31)	drop-down-menu: rim sherd (Q106990428), wall sherd (Q106990472), base sherd (Q106990489), ...	wall sherd (Q106990472)
image (P18)	free field to link to Wikimedia file	SBK-Scherbe_Hohenbrück.jpg
has pattern (P5422)	drop-down-menu: incising (Q6014696), stamp (Q96093273), triangle (Q19821), line (Q1228250), quadrilateral (Q36810), ...	stamp (Q96093273) and quadrilateral (Q36810)
culture associated with item (P2596)	drop-down-menu: Linear Pottery Culture (Q806348), Stroke-ornamented Ware Culture (Q1932196), Rössen Culture (Q1886212), ...	Stroke-ornamented Ware Culture (Q1932196)
discoverer or inventor (P61)	free field to link to Wikidata item
location of item at discovery (P189)	free field to link to Wikidata item	Hohenbrück (Q1623655)
time of discovery (P575)	free field to enter date
part of WikiProject (P5008)	mandatory: Prehistoric Ceramics (Q107588426)	Prehistoric Ceramics (Q107588426)
stated in (P248)	drop-down-menu: volunteer (Q24716636), Heritage Management of Baden-Württemberg (Q1541782), Heritage Management of Bavaria (Q812412), ... all other German Heritage Management institutions	Heritage Management of Brandenburg (Q897952)
described by source (P1343)	free field to link to Wikidata item
described by URL (P973)	free field to enter URL	https://brandenburgikon.net/index.php/de/sachlexikon/stichbandkeramik

). Multiple terms can be added to the record of a sherd. Spatial information is given by providing the nearest settlement as a findspot, which will be interesting for field walkers in the region. Images of the finds are hosted by Wikimedia Commons. The information entered via the cradle tool can later be searched for by using the Wikidata Query Service [137].

A manual on how to contribute, as well as dedicated queries, will be provided for the users on Wikidata:WikiProject Prähistorische Keramik and distributed to the community. Queries could, e.g., yield all items where a certain decorative element such as ‘incision’ was used, or list all items from a specific region. This way inexperienced volunteer archaeologists can compare the sherd they found to a growing number of items in Wikidata and Wikimedia Commons. An example query is https://w.wiki/3BWg.

4.2. Tools for Wikidata

Wikidata has a vibrant community, which creates and maintains a diverse ecosystem of tools that aid in all possible aspects of working with Wikidata: input, editing, output, querying, and visualisation. At this point, we would like to give more information on the tools that were used in the projects described above in Section 4.1. For a selection of tools that aid in the LOD workflow in Wikidata, refer to [138].

Cradle [118,139] allows the creation of forms for data entry, which facilitate data input for beginners and help in standardising specific item types or classes. The tool aids in formalising a specific data model for individual item classes, which otherwise is not possible in Wikidata. With Cradle, mandatory and optional statements can be designed, as well as pre-defined value lists provided. The Cradle tool has already been used for archaeology related data, e.g., for ancient ceramicists and vase painters, coin types, or historic buildings in Germany. Dedicated Cradle forms were created for the projects presented in Section 4.1.6 and Section 4.1.1.

The Wikidata Query Service [137,140,141] provides a graphical user interface for human users to query data in Wikidata from a SPARQL endpoint. Because of several built-in features, including extensive examples and the Wikidata Query Builder [142], special knowledge of the query language SPARQL is not required. The service provides a plethora of visualisation formats for the queries, which are also used in such tools as Scholia (described below). All projects detailed in Section 4.1 use the service for querying and analysing data included in Wikidata.

The SPARQLing Unicorn QGIS Plugin [121], ([122] pp. 90–100) (Q74005133) is a plugin for the free and Open Source Geographic Information System QGIS. It offers users an easy way to query and import geospatial as well as associated data from Wikidata and other triplestores into QGIS, which can be used for further data processing and analysis beyond the capabilities of Wikidata or the Wikidata Query Service. The plugin is developed and maintained by the Research Squirrel Engineers Network [143]. The projects described in Section 4.1.1 and Section 4.1.2 make use of this plugin.

QuickStatements [114,144] is a tool for batch creating or editing Wikidata items, thus allowing for the import of large datasets to Wikidata without the time-consuming manual steps. It works by providing a simple set of text commands, which can also be created from within OpenRefine (see below). The projects described in Section 4.1.1 and Section 4.1.3 make use of QuickStatements.

OpenRefine [145,146] is a versatile programme for working with structured data, such as tabular data. Its functionality is especially aimed at cleaning messy data, transforming it into other formats, and enriching data from external sources. Local data can be matched and enriched with Wikidata items using the Wikidata reconciliation service. Data in OpenRefine can easily be transformed into Wikidata statements by creating a dedicated export schema that maps each column to respective items and properties. Data prepared in this way can directly be processed with QuickStatements, thus allowing for editing and creating of Wikidata items directly from within OpenRefine. The tool was extensively used for data preparation in the bibliographic project described in Section 4.1.3.

Scholia [147] (Q45340488) is a web service built on top of Wikidata to handle and visualise scientific bibliographic information contained within Wikidata for scientometrics without requiring any technical knowledge from the user. The data to be displayed is collected via pre-built SPARQL queries from the Wikidata Query Service and visualised with the output formats provided by the service. Visualisations include lists of publications, different charts to represent publications per year, graphs for co-author or citation networks, and images to augment a topic graph. Within Scholia, different kinds of information, called ‘aspects’ ([147] p. 5) can be examined, e.g., individual authors, works, organisations, or topics. It is also possible to, e.g., combine multiple topics for viewing, such as ‘archaeology’ (Q23498), ‘linked data’ (Q515701), and ‘linked open data’ (Q18692990), which renders a page that includes a list of works on any combination of these topics. Scholia is a central tool used in the bibliographic project described in Section 4.1.3.

4.3. Summarising the Role of Wikidata

The presented projects deal with turning (legacy) data into LOD by using Wikidata as an already established knowledge hub that is multilingual and interdisciplinary by design and aims at connecting different sources. While the projects seem completely different, there are commonalities in their workflows: developing a suitable schema or ontology for data representation both in dedicated databases and in Wikidata; cleaning up and enriching legacy data; reconciling data with Wikidata to avoid duplicates; preserving provenance information such as sources and references for cultural attributions or classifications; enriching the data with external links and further information. The added value lies in the (re-)useability of the enriched and interlinked datasets that are open for researchers and citizen scientists alike.

Though we agree in general with Franca et al., who state that “individual researchers and research groups should may [sic!] not be thought of as a primary focus of Linked Data initiatives. Managers of digital archives for the research community and institutional repositories are much more relevant target groups” ([61] p. 16), we show that by using Wikidata individual researchers are enabled to contribute to the LOD Cloud in archaeology.

Although using Wikidata to provide LOD is much easier than developing your own framework, it still poses a few challenges for less technically savvy users. Many tools, of which a selection is presented in Section 4.2, have been implemented for Wikidata to aid in dealing with various tasks.

In practice, two key features of Wikidata could pose obstacles. One is that Wikidata is by definition open to everyone, both for reading and editing. Secondly, all facts are available under the free licence CC0. The former might lead to (unintended) editing of items, meaning someone may enter false data, tamper with formerly correct information or delete a statement they consider irrelevant. This is not the experience of any of the authors—on the contrary: many Wikidata items have profited from enrichment with further information and external links. In some cases, sensitive information not suitable for open publication, e.g., exact in situ location, is either only entered with vague statements or not at all. In addition, not all kinds of information can be included in Wikidata due to the use of the CC0 licence. These especially include longer texts, such as abstracts, that might be under copyright.

5. Conclusions

Due to their heterogeneity, their scattered nature, and, in some cases, their incompleteness and lack of documentation, legacy data is usually more difficult to process and analyse than data collected by oneself. Nonetheless, these challenges have to be continuously addressed because of the core practice of archaeological research that builds on original documentation and former publications. We believe that if we do not use contemporary digital publishing media and structures for data nowadays, we continue to create discrete legacy data that will just increase these challenges for future generations of researchers. Digitisation of legacy data is being undertaken in several institutions and projects, e.g., [148,149,150]. Digitisation poses its own challenges; most notably, loss of information due to financial or curatorial issues or deliberate decisions, as well as faulty metadata that can only be identified as such and corrected when access to the original source is possible. While online publication of data and results increases its accessibility, as, e.g., travelling to archives and warehouses in person is not a must anymore, we argue that this is not sufficient to meet current research methodologies and needs.

As described in Section 3, LOD represents the consequent further development of scientific citation and referencing practice in the digital decentralised space. LOD is what enables linking of data with synthesis and argument [151], as well as ultimately connecting different sources, e.g., [56] and disciplines, e.g., [58]. When LOD is properly implemented, computer-aided processing and inference become possible ([8] pp. 177–194) [63]. Nonetheless, we recognise that an adequate implementation of LOD principles is not without challenges (cf. Section 2.2), with additional costs of human labour for creation and the need of a sustainable infrastructure being the most pressing ones.

We understand that providing and using LOD via dedicated APIs requires technical skills not every archaeologist has or will have. This problem has to be addressed from two sides. On one side, human-readable (and -friendly) interfaces help lower the barriers to using LOD from, e.g., Wikidata in daily work. Tools like those presented in Section 4.2, which might even be included in familiar working environments, such as the SPARQLing Unicorn QGIS Plugin, have the same effect. On the other side, another important step towards lowering barriers related to technical know-how is described by Kansa and Kansa:

“If one aim of preserving data is for others to be able to use it, we need to increase practitioners’ skills in accessing and using data. Broadening data literacy skills over the next decade will help us realize the full potential of archaeological data.” ([152] p. 82)

Increasing data literacy skills requires awareness of LOD and its potential as well as sustainable infrastructures. An important building block in the direction of these requirements is an active user community that includes researchers as well as citizen scientists. Only with an active user group, such frameworks as Wikidata, Pelagios, and other LOD providing systems can become sustainable. This also applies to research software [153]. Regarding the infrastructure side, a commitment by national and international funding bodies is necessary. Although the problem has been widely recognised and is being addressed, most recently, e.g., the funding of a German national research data infrastructure (NFDI) by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) with the NFDI4Objects consortium dedicated to material remains of human history, some core infrastructure components such as data repositories still require action [7].

Ultimately, just as LOD links data from different sources, it should also bring together researchers from a wide range of disciplines to work together on interdisciplinary research questions and collaborate towards sustainable (LOD) infrastructures.