Pattern-based design applied to cultural heritage knowledge graphs

2.1. The General Catalogue of Italian Cultural Heritage

ICCD coordinates these cataloguing activities by maintaining the General Catalogue of Italian Cultural Heritage (footnote 11) (GC), which is the official institutional database of Italian cultural heritage, promoting integrated management of data coming from all over Italy and from diverse institutions and local contexts.

The General Catalogue is built upon a collaborative platform, named SIGECweb (footnote 13), to which national or regional, public or private, institutional organisations that administer cultural properties can submit their catalogue records, i.e. files containing data on cultural properties and compliant with predetermined standards and guidelines (see Section 2.2). Only users from institutions that are formally authorised by ICCD can access and contribute to SIGECweb, with specific profiles (e.g. administrator, cataloguer). The highly reliable provenance of the database is guaranteed by (i) an accreditation process that allows only authorised entities to contribute to the platform, (ii) a data validation phase performed by heritage protection agencies that assess the scientific quality of catalogue records, and (iii) an automatic data validation phase based on compliance with specific cataloguing standards (see Fig. 1). Based on its authoritativeness, it is assumed as a high-quality database, in terms of accuracy and completeness.

OPEN IN VIEWER

Fig. 1.

Accreditation and validation process for contributing to SIGECweb.

SIGECweb currently contains 2,735,343 catalogue records, 831,114 of which are publicly accessible through the General Catalogue. The privacy level associated with the remaining records prevents them to be openly published, since they refer to properties either private, or being at stake (e.g. items in unguarded buildings), or still requiring a scientific assessment by accounted institutions.

In order to guarantee high quality, consistency and interoperability between data accessible through the General Catalogue, ICCD defines a set of standards (normative) (footnote 9) for encoding catalogue records (schede di catalogo), which provides a template for collecting and organising data on different types of cultural properties and a methodological base for cataloguing. Thus, these standards are part of ArCo KG input, along with data contained in the GC catalogue records.

OPEN IN VIEWER

Fig. 2.

An example of the structure of an ICCD cataloguing standard.

Each cataloguing standard consists of a PDF document15

2.2.2. One cataloguing standard, different versions over time

ICCD has been sharing cataloguing standards since 1990: they have undergone changes and updates, regarding both their structure and rules for compilation.17

¹⁷

Previous and current versions include: 1.00 and 2.00 (1990–2000), 3.00 (2002–2004), 3.01 (2005–2010), 4.00 (since 2015).

As a result, the GC contains heterogeneous catalogue records, following different versions, thus requiring expensive and time-consuming mapping activities: indeed, in moving from a version to the next one, ICCD did not systematically keep track of changes. While in some cases this mapping is straightforward, in other cases differences over data due to different versions can be significant. Let us consider an example, depicted in Fig. 3, of the standard F (for cataloguing photographs). In version 3.00 there are three separate fields to indicate place, site and date of a photograph (MSTL, MSTD, MSTS, respectively), while in version 4.00, they are all encoded in a single field (MSTL).

OPEN IN VIEWER

Fig. 3.

The ICCD cataloguing standard F for photographs: difference and mapping between version 3.00 and version 4.00.

Although catalogue records submitted to SIGECweb are subject to a validation process, being collaborative in nature means that catalogue records are not error-free. There are cases of: mandatory fields that are not properly filled, thus producing an error code; catalogue records containing values alternative to those provided by controlled lists, hence undermining data homogeneity; use of non-standard formats (e.g. for dates); minor bugs and typing errors. ICCD is continuously working for improving the collecting process, in order to minimise these situations.

Moreover, catalogue standards themselves could be improved in their structure, in order to maximise data mining from catalogue records: there are still many fields allowing for long descriptive texts, from which structured high-quality information could be derived and extracted.

XD is an ontology design methodology that puts the reuse of ODPs at its core both as a principle and as an explicit activity. It provides guidelines for such an activity. Experiments have demonstrated its positive impact on ontology engineering and ontology quality [6,59].

XD is inspired by eXtreme Programming (XP) [60], an agile software development methodology that aims at minimising the impact of changes at any stage of the development, and producing incremental releases based on customer requirements and their prioritisation. Although the two approaches share the same principles and general guidelines, they in practice diverge towards different focuses, mainly due to the core differences between software systems and ontologies. XD is test-driven, and applies the divide-and-conquer approach as well as XP does. Also, XD adopts pair design (as opposed to pair programming). The intensive use of ODPs, modular design, and collaborative approach are the main characterising principles of the method. Further details on the relation between XP and XD, and a thorough description of XD, are given in [52].

OPEN IN VIEWER

Fig. 4.

The XD methodology as implemented for the ArCo knowledge graph.

As depicted in Fig. 4, after the project initiation, XD is executed by iterating a set of steps, each involving one or more teams:

a customer team, which elicits the requirements that guide the design and testing process;

Figure 5 depicts a simple example that will be used to illustrate the main steps of the methodology.

OPEN IN VIEWER

Fig. 5.

An example of a user story translated into CQs, and of the matching between a CQ and an ODP.

Requirements engineering A fundamental step is to collect requirements and to engineer them. Requirements are collected in the form of user stories, which are provided by the customer team. A user story is a set of sentences, which describe by example the kind of facts that the resulting knowledge graph is required to encode. The length of a user story is limited to favour keeping them focused; its maximum length is decided by the design team. The customer team is instructed to break possible complex stories into smaller and simpler ones. An example of a simple user story is (cf. Fig. 5): “Leonardo da Vinci was an artist, a philosopher and an engineer”. User stories may be associated with a priority level, a title, and an ID.20

Competency Questions One or more competency questions (CQs) [34] are derived from a generalisation of the user stories. CQs are the natural language counterpart of structured queries that we want to enable against the resulting knowledge graph. Generalising a user story means to identify the main concepts that it exemplifies. This generalisation is carried out by the design team, in collaboration with the customer team. For example, considering the previous user story, two CQs may be derived from it: “Which are the roles played by an artist?” and “Which artists played a certain role?” (cf. Fig. 5). The design and customer teams have identified that “Leonardo da Vinci” is an example of Artist, which is a relevant concept in the domain, and that “artist”, “philosopher”, and “engineer” are examples of Roles that an artist can play, another relevant concept to include in the ontology.

In addition to deriving CQs, the design team interacts with the customer team in order to identify possible general constraints that may accompany them. General constraints express possible inferences or other rules that apply to the concepts that the story involves. In the example of Fig. 5, the following general constraints can be drawn: “An artist is a person” and “A person cannot be a role”. General constraints are the natural language counterpart of axioms that will be formalised in the ontology. The CQs and the general constraints define the ontology requirements, hence contributing to assess the ontological commitment, as far as the ontology domain tasks and scope are concerned. From the XD perspective, the ontological commitment includes both meta-level aspects such as adopting a 3d or 4d view, as well as functional/application aspects which draw the boundaries of the scope of the ontology. ArCo ontological foundations are discussed in Section 4.

Matching CQs to ODPs CQs guide the selection of ODPs: a key process in XD, and in general in pattern-based design, is to match CQs to ODPs. At each iteration, a coherent set of CQs is selected, i.e. CQs dealing with the same modelling issues (e.g. roles played by agents). Possible existing solutions (ODPs) are analysed in order to find the most suitable one to be implemented in the ontology. This is a complex cognitive task that, currently, lacks proper tool support. Hence, it is better performed by whom has previous knowledge about existing ODPs. Nevertheless, if one is not familiar with ODPs, they can be found on catalogues, such as the catalogue maintained by the University of Manchester21

Testing and integration XD is test-driven and follows a unit testing approach as described in [7,52]. The CQs and general constraints defined by the design team are shared with the testing team. While the design team uses them for producing a piece of the ontology, the testing team uses them for designing unit tests: CQs are translated into possible SPARQL queries, while general constraints are used to create sample triples, based on the user stories, that are expected to provoke either consistency/coherence errors or inferences. The testing team will use a draft terminology based on the CQs. In other words, unit tests are sample OWL/RDF files (encoding the user story) and SPARQL queries, annotated with their corresponding expected results. When the testing team receives an ontology piece from the design team, it firstly attempts to replace the corresponding unit test (draft) terminology with the provided ontology vocabulary. At this stage possible missing concepts can be spotted, which would make the test positive25

Challenges of XD methodology So far, we have described eXtreme Design (XD) according to [4,6,52]. In the context of the ArCo’s project we faced a number of challenges that are not explicitly tackled by XD, hence we contributed to extend it. Specifically, one challenge concerns how to design the architecture of an ontology network. As we deal with a wide and complex domain such as Cultural Heritage, we would have benefit from clear guidelines. There is some preliminary work described in [30] about architectural patterns for ontologies, defined as patterns that

[...] affect the overall shape of the ontology, and dictate ‘how the ontology should look like’. [...] An ontology that has a simple modular architecture is composed of a set of ontologies, called modules, plus one ontology that imports all the modules.

Another challenge concerns the collection of requirements. Cultural heritage data are relevant for potentially many diverse consumers and applications. Our primary source of data is a catalogue, however our ultimate goal is to conceptualise the Cultural Heritage domain at large, going far beyond the cataloguing perspective. This means that ArCo needs to draw its requirements by a plethora of diverse potential consumers, which can enter the process at any time, posing new requirements. XD is adequate to support evolving requirements, but how to gather requirements from an evolving community is unclear.

A third challenge concerns testing. In this case, given the dimension and complexity of ArCo ontologies we soon realised that systematic testing, as recommended by XD, needed proper tool support, which was unavailable to the best of our knowledge. We have developed TESTaLOD to serve this purpose, which is presented in Section 6.1.

When the project started, its main customer was ICCD, i.e. the institute in charge of collecting and preserving the data of the General Catalogue, and of releasing updated cataloguing standards. ICCD domain experts formed the customer team and provided indications to the design team for the selection and prioritisation of requirements. They also supported the design team in gaining a good comprehension of the cataloguing standards. ArCo ontologies reflect (hence are compatible to) ICCD standards. However, they are not committed exclusively to their interpretation of the Cultural Heritage domain, which is limited to the point of view of cataloguing practices. The situation we faced is that ICCD wanted to address the need of diverse communities of potential consumers of CH data, while keeping an institutional management of the development process. We opted for a twofold approach: (i) we handled the requirements collection as an open process by involving external actors, and (ii) we have launched an “Early Adoption Program” aimed at engaging a number of representatives of potential consumers, who would provide both requirements and validation. This approach has favoured a relatively quick creation of an open community as well as widening the scope of the collected requirements. Early Adopters (EAs) are given assistance and support, and the fulfillment of their issues and requirements are put high in priority. In order to guarantee a lively interaction within the project community, regular meetings (e.g. webinars or meetups) are held and issues are discussed in an open mailing list. Furthermore, proposals for improvement and bugs can be submitted as GitHub issues.27

With this approach, the customer team became an evolving creature, which over time will extend by involving all representatives of potential producers and consumers of CH data. At the moment, ArCo is collecting requirements from private companies, public administrations, researchers and creative developers. These requirements are collected in the form of small stories (according to XD). A story is a non-structured text, exemplifying some scenario or reporting real use cases. They are submitted by the customer team to a Google Form, with a maximum of 250 characters.28

Requirements coming from user stories, as well those extracted from ICCD standards, are translated into Competency Questions. All CQs, and related SPARQL queries, that so far guided ArCo KG design and testing are available online.29

As an example, we report one of the stories collected through the Google form:

Type: Linking my data to ArCo data

Title: Cultural heritage and residential property

Story: I am looking for a residential property to buy, and I want to filter the results based on the type of cultural heritage nearby.

This story requires to address the following CQs: “What are the types of cultural properties located in a certain area?”, “Which is the current location of a cultural property?”, “Which are the geographic coordinates of the current location of a cultural property?”, “Which is the type of a cultural property?”. Other examples of stories concerned: linking cultural properties to multimedia resources, such as photographic documentation; describing specific attributes of drawings or music heritage; tracking over time the availability of cultural properties that have been confiscated from organised crime; relating catalogue records to heritage protection agencies.

Handling large ontologies is a non-trivial challenge for ontology engineers, reasoners and users. A modular approach, as opposed to a monolithic design, i.e. one ontology module addressing all CQs, favours readability, reusability and maintainability of an ontology [50,61]. Ontology modules are meant to identify conceptually coherent subparts of the domain. In this respect, XD lacks explicit guidelines on how to approach a modular design of potentially large, networked ontologies. Based on our experience in designing the architecture of the ArCo ontology network, we provide a set of guidelines as well as an architectural pattern that can be applied in other contexts with similar characteristics as the ArCo’s project.

The root-thematic-foundations architectural pattern 

OPEN IN VIEWER

Fig. 6.

ArCo ontology network, currently including seven modules: arco is the root node of the network, while core is reused by all other modules, where concepts related to cultural properties and catalogue records are represented.

We name the architectural pattern implemented by the ArCo ontology network root-thematic-foundations (Fig. 6). It can be described as follows:

The implementation of the root-thematic-foundations pattern requires a conceptual organisation of the domain into separate coherent subdomains. This can be achieved by clustering the requirements, based on thematic areas. The criteria for identifying thematic areas, and their granularity, can vary depending on the project’s commitment, design choices and the size of the domain. As ontologies are evolving objects, new (main) thematic modules may be added over time in case future requirements identify new subdomains.

In the context of ArCo, at a very early stage of development, we could leverage and analyse the ICCD catalogue, its data and standards, as well as the user stories provided by the customer team. In agreement with ICCD domain experts, we first focused on the cross cataloguing standard and related user stories, which address concepts that are relevant for all types of cultural properties. Our hypothesis is that the cross standard can give us a plausible overview of the CH domain. In all cataloguing standards, metadata are grouped into paragraphs, each containing different fields. We performed a manual clustering of these fields. This activity allowed us to identify five topics that could characterise the main thematic modules of the ArCo ontology network.

A first observation is that catalogue records contain: (i) data directly describing a cultural property and its contexts (e.g. techniques and materials, related exhibitions, surveys); (ii) data about catalogue records themselves (e.g. when they were created, by whom, their version, etc.); (iii) data about other entities referring to cultural properties (e.g. inventories, documentation, bibliography). Based on this observation, a main thematic module (catalogue30

Cultural properties, which are the main subjects of study of the CH domain, are described by means of measurable, intrinsic aspects such as length, weight, materials, conservation status, as well as properties deriving from an interpretation process, such as authorship attribution, dating. This conceptual distinction suggested us to define two additional thematic modules of the network: denotative description31

Finally, it results fairly evident that the locations associated with a cultural property and the cultural events in which it participates in, are two major components of its lifecycle. As a consequence, the ArCo ontology network includes the two thematic modules location33

The foundational concepts captured by the core35

Finally, the arco36

Competency Questions Each module of the ontology network addresses a subset of the Competency Questions elicited by the customer team. Table 1 lists some representative CQs for each module, except the core module, which is specialised by the other modules.

4.1. Foundational commitment in ArCo: DOLCE-Zero

The ODPs implemented in ArCo ontologies are mostly taken from a set of interrelated foundational ODPs, inspired by DOLCE UltraLite+DnS (DUL)37

DUL is a commonly used foundational ontology that commits to (i) DOLCE [28] distinctions: objects vs. events vs. qualities (specific attributes of objects and events) vs. qualia (dimensional representations of qualities), and to (ii) D&S (Descriptions and Situations) [23,47] distinctions for entities including situations vs. descriptions vs. concepts (see Section 4.2 for details), e.g. types, topics, roles, tasks, quality types, parameters, reified relations and classes, etc.

DOLCE-Zero contains a small set of classes on top of DUL, relaxing ambiguity resolution when needed. In particular, it introduces four “union classes”: d0:Characteristic, d0:Eventuality, d0:Activity, and d0:Location39

However, DOLCE (and its OWL implementation in DUL) has disjoint classes for physical vs. social objects vs. spatial regions, since the authors wanted to pursue a multiplicative approach, i.e. ideally we would need to introduce an entity in the universe of discourse for each distinct entity, e.g. Uffizi-as-building, Uffizi-as-museum, Uffizi-as-organisation. However, refactoring existing datasets in order to enforce multiplicativism is not simple in practice, since we do not always know the context allowing for establishing the distinction. In addition, the co-predicative nature of certain entities is built in the cognitive intentionality of speakers or data modellers, and it would be very difficult to change the data. The result of those pragmatic issues is that it would be dangerous to choose one particular meaning (e.g. Uffizi-as-building), because that choice might induce an inconsistency if data refer e.g. to the director of Uffizi (i.e. Uffizi-as-museum).

As a matter of fact, those distinctions are seldom represented in lightweight ontologies and natural language lexicons: trying to push multiplicativism would lead to debatable inconsistencies, as argued in [51], which reports a large-scale experiment that uses DOLCE-Zero to detect millions of inconsistencies in the DBpedia knowledge graph. In that experiment DOLCE-Zero union classes have avoided a much larger amount of inconsistencies, which cannot be fixed. Of course, for integrity checking, we could resort at anytime to data analytics that test multiplicativism for e.g. a fragment of the DBpedia or ArCo knowledge graphs.

ArCo foundational distinctions have a similar foundational commitment as DOLCE-Zero, so using more specific DUL’s distinctions only when necessary. This commitment is implemented in Level 0,40

A cluster of foundational requirements in ArCo is about events, states, actions, and their expressions, types and interpretations. Literature on these notions is heterogeneous [12], applying pragmatical, logical, and philosophical criteria, often mingled, to draw distinctions. As an example of the underlying problems, we can distinguish (i) a restoration event e on a cultural property c, (ii) the restored state s of c, (iii) their types or categorizations (e.g. procedures, phases, tasks, roles) t 1... m of e or s, (iv) the propositions p 1... n that report e or s, (v) the relationship r holding between c, the participants in e and s, and the propositions p 1... n , as well as (vi) the interpretation relation i functioning as the intensional counterpart to r. In ArCo, we have requirements for most of those distinctions: sometimes we need to talk about events, states, their types, their reports, the relationships between the participants, and interpretations of those relationships.

A related problem is that ArCo requirements (as most ontology design projects for the Semantic Web) need to represent n-ary relations (with n > 2 ) in a logical language (OWL) that only can express unary or binary predicates.42

While this is a representation problem, rather than an ontological one, there is ample evidence (see e.g. [15,24,31,33]) that similar cognitive constructions (intensions, logically speaking) apply to events, states, actions, event types, action schemas, frames (in the sense of [21]), and relations as first-order objects.

Based on this assumption, a useful generalisation can be applied, treating those entities as either (i) reified (extensional) relationships, e.g. the situation of Canova’s Venus Victrix being located at Galleria Borghese in Rome since 1838, or (ii) reified (intensional) relations, e.g. the Attribution frame representing the authorship attribution to cultural properties, as made by an interpreter based on some criteria.

That generalisation is applied quite often in ontology design. ODPs such as situation, description, descriptionsituation, planexecution, etc. (cf. [53]), inspired by the theory of Constructive Descriptions and Situations (cDnS) [23], provide a framework to systematically relate frames (a.k.a. intensional relations, schemas, descriptions), and frame occurrences (a.k.a. extensional relations, situations, states of affairs).

The generalisation implements the cognitive assumption of extensional relations in the world being “framed” or “schematised” through observation, interpretation, diagnosis, norm, expectation, etc. In other words, framing applies a conceptual construction to a set of sensory perceptions, given data, reported facts, etc. The correspondence between frames and their occurrences leads to assigning contextual roles to participants (e.g. being a restored object in a Restoration frame occurrence), tasks/types to actions (e.g. being a completion phase in a Restoration frame occurrence), parameters to data values (e.g. being a reliable dating in an occurrence of a frame for evaluating the reliability of Carbon-14 dating of an archaeological object). Application of those ODPs can be found in multiple domains [23,25,26,32,48,57].

ArCo adopts the framing patterns to the representation of cultural properties, using the class core:Situation for frame occurrences. See Sections 5.1, 5.2 and 5.3 for the situation types modelled in ArCo.

While situations allow to generalise over any relational concept, regardless of their arity, semantic web practices sometimes prefer binary predicates (called object or datatype properties) whenever useful. In order to accommodate the constructive stance of ArCo, which requires graphs including multiple triples for each relation, with the practical benefit of having simpler graphs with one triple representing each relationship, the same relational concepts are represented as both ⩾ 2 -ary (situation classes) and projected binary relations (OWL properties). This redundancy supports both high-level modelling needs (time indexing, evolution, changes), and lightweight modelling. Where possible, an OWL property chain abridges a situational graph representing a ⩾ 2 -ary relation to its binary projection(s).

For instance, agencies related to a cultural property (e.g. a cataloguing agency) can be represented in ArCo as either (i) a situation class (core:AgentRole) that includes the cultural property, the agency, and the role it played with respect to that cultural property, or (ii) an OWL object property (:hasRelatedAgency), which directly links the cultural property to the agency, and is subsumed by the property chain [core:hasAgentRole O core:hasAgent].

4.4. Other foundational event-like notions

Other event-like notions in foundational and cultural ontologies can be aligned as subclasses of core:Situation. Two examples are provided here.

CIDOC CRM E5 Event, subclass of E4 Period, is defined as ... changes of states in cultural, social or physical systems, regardless of scale, brought about by a series or group of coherent physical, cultural, technological or legal phenomena ... The distinction between an E5 Event and an E4 Period is partly a question of the scale of observation. Viewed at a coarse level of detail, an E5 Event is an ‘instantaneous’ change of state. CIDOC events are then considered as a granularity (or “aspectual”) distinction within the larger class of periods, which seem to encompass also other spatio-temporal phenomena, except E3 Condition State, which is defined as a particular state of an entity. Both E4 Period and E3 Condition State are subclasses of E2 Temporal Entity, which “encompasses all phenomena”. Orthogonally, ArCo situations focus on the role structure of event-, state-, and relation-like entities. All CIDOC temporal entities can be considered situations in ArCo, while their aspectual distinctions are not directly addressed in ArCo, since they could be defined as subclasses of core:Situation if needed in a cultural requirement. We remark that in CIDOC CRM participation (and therefore the possible roles of participants) is only defined for E5 Event, while all ArCo situations can have participants with a role.

As a second example, DOLCE [28] notion of Event (a.k.a. Perdurant or Occurrent) is defined axiomatically as the class of entities that “happen in time”, i.e. some of their proper parts/phases may not be present at each time they are present (extreme cases include instantaneous and stationary states). Participation is defined in DOLCE for all events. An extension of DOLCE [47] axiomatises also intensional relations (called descriptions) as schemas, with proper roles, for events or other entities. The notion of frame/description/intensional relation used in ArCo is compatible with that of description in [47], while ArCo situations do not commit to the distinction between objects and events as applied in DOLCE (and CIDOC CRM), since a situation is defined as the occurrence of a description as observed, diagnosed, aggregated, invented, etc. In this sense, the constructive approach inherited from cDnS [23] departs from other foundational ontologies, which focus on the 3D/4D distinction as primary to declare their commitments. That constructive stance prioritises the dependence of an event-like entity on its framing, so that a requirement for ontology design can be directly matched by a frame. For example, an iconological interpretation for an iconographical element can be represented as a framing: an art historian like Erwin Panofsky with a requirement to find iconographical elements that match marriage iconology would interpret several iconographical elements in the Arnolfini Portrait by van Eyck as the occurrence of a marriage contract.

This stance, besides cognitive results, is also inspired by Davidson [15], which provides a solid ground to events as first-order entities, corresponding to (reified) relationships.

Finally, as discussed in Section 4.5, a constructive stance is immediately applicable to the interpreted nature of cultural entities: historical, anthropological or archaeological events are always dependent on some interpretation for their cultural identity to be established, and cultural properties may change their meaning when interpretation conditions change.

4.5. Epistemological stance in ArCo

Related to the previous section, ArCo applies a distinction between three epistemological levels: factual, interpretation, and reporting situations, which constitute the core of cultural data dynamics.

For example, having physical size, constitution, unique qualities, or authorship are factual situations for a cultural property c, while establishing constitution via Carbon-14 or attributing authorship for c are interpretation situations. This distinction allows the modeller to distinguish factual data from interpretation data, when they exist (e.g. only rarely we have data describing the criteria used to establish the material of a statue). Finally, providing data and content about c is a reporting situation. The cultural heritage scientist typically establishes factual situations based both on direct or sensor-based observation data, and on documented evidence, mediated by interpretation activities. Data provided by cultural agencies, researchers or citizens do not necessarily contain the full story of how facts have been exactly established/reported, extended causal chains. In ArCo, we need to live with incomplete epistemological foundations, trying to associate situations with their epistemological level.

The epistemological stance in ArCo involves the distinction between: (i) catalogue versions, e.g. when someone adds data in a catalog record, (ii) interpretations, e.g. when a catalogue record reports an attribution, and (iii) current factual data, e.g. the authoritative data for a cultural property at the current state of the art. When the catalogue record is the only source for a knowledge graph, we depend on its versions to reconstruct the epistemological trajectory of c, with its interpretations, updates, and the current state of its factual data. Section 5.1 describes the predicates used for relating cultural property situations and where they are reported e.g. catalogue records.

However, the vision of ArCo goes well beyond reengineering traditional catalogues, and its epistemological stance accommodates for a more complex knowledge graph hosting interpretations with different provenance and reliability, different reporting sources, and potentially conflicting factual data, so enabling cultural knowledge graphs as investigation tools for researchers.

4.6. ArCo top level hierarchy and distinctions

The most general Cultural Heritage concept modelled in ArCo is :CulturalProperty. This class includes all tangible and intangible entities that have been recognised to be part of our cultural heritage. Once an entity is recognised as being part of cultural heritage, it never stops being a :CulturalProperty. For example, a commissioned artwork is not an instance of ArCo’s :CulturalProperty, unless or until it is officially recognised as such. Hence, according to the definition by [35], being a cultural property is an essential characteristic of all instances of :CulturalProperty, i.e. it is a rigid property in all possible worlds for ArCo’s universe of discourse: the Cultural Heritage domain.

The root of ArCo’s hierarchy (depicted in Fig. 7) is the class :CulturalProperty. According to the main distinctions in Cultural Heritage identified by UNESCO,43

OPEN IN VIEWER

Fig. 7.

The taxonomy of cultural properties.

:TangibleCulturalProperty is further specialized in :MovableCulturalProperty, i.e. objects that can be handled and moved by nature (e.g. a painting, a musical instrument), and :ImmovableCulturalProperty, i.e. objects fixed or incorporated into the ground, which generally occupy a large area (e.g. an archaeological site, a palace and its gardens).

Dynamic concepts, such as situations that change over time, are present in almost every domain. There are different patterns that model dynamic situations: in this subsection, we exemplify ArCo approach to dynamicity with catalogue records and cultural property locations, which may both evolve over time.

A catalogue record as a fluent information object A catalogue record is an entity that contains metadata about a cultural property. As it describes a real-world object, it can be defined as an information object, i.e. a piece of information, independent from how it is concretely realised, describing something in the real world. This concept is defined in several ODPs, including Information Realization46

A catalogue record is then a fluent entity, an information object that changes as the description of its denoted cultural property changes.47

Every change of a catalogue record produces an information object, which is a new version of the catalogue record, including the reporting of a new situation involving a same persistent entity. Nevertheless, the catalogue record finds its persistence in describing the same real-world object, i.e. the same cultural property, independently from different versions of the content and the reported entity changes over time. Thus, the catalogue record is represented as a persistent information object, and is related to its versions, which are information objects reflecting changes of its content over time.

OPEN IN VIEWER

Fig. 9.

Information Realization and Sequence ODPs reused for modeling catalogue records.

The Time Interval ODP is used to represent the temporal validity of each version, and the pattern Sequence48

Figure 9a depicts catalogue record modeling with the reused ODPs. A catalogue record is represented by the class a-cat:CatalogueRecord, which is aligned to dul:InformationEntity with an rdfs:subClassOf axiom, and is related to the cultural property it describes. Catalogue records have different a-cat:CatalogueRecordVersions, which are linked to (new) data included (a-cat:addsDataAbout), supported by a situation, or to deprecated data that were included in previous version(s) (a-cat:removesDataAbout). Each version is associated with a time interval, a-cat:editedAtTime, and with agents involved in its creation (e.g. a-cat:hasCataloguingAgent with its subproperties). The agents involved in changing the catalogue record play some role, which has its own temporal validity, hence we reuse another pattern. roapit:TimeIndexedRole49

In Fig. 9b we can see an instance of this model. The data:CatalogueRecordPST/030197167650

Multiple time-indexed and typed locations for one cultural property A tangible cultural property, i.e. a physical object, is located in a physical place, which can be defined by a set of components: country, region, city, address, etc. For an immovable cultural property (e.g. a monumental park), this place overlaps with the area occupied by the cultural property, and to which it is fixed. Instead, for a movable cultural property (e.g. a photograph), data about the address and the coordinates is referred to the building in which it is situated and preserved, and the related cultural institute. While an immovable cultural property, precisely because of its nature, will be related to a unique geographical place during its whole life cycle, a movable cultural property can be moved from a place to another. Different locations of a cultural property will hold in different time intervals. As a consequence, the temporal indexing of the locations associated with a cultural property is represented, also promoting the reconstruction of the spatial trajectory of the cultural property over time. During its life cycle, a movable cultural property is involved at least in as many situations as the places in which it has been located, and each situation is associated with a time interval. The Time Indexed Situation52

OPEN IN VIEWER

Fig. 10.

Time indexed situation ODP implemented for modelling different types of locations of a cultural property.

Figure 10a shows the class a-loc:TimeIndexedTypedLocation as the core class of the implementation of this pattern: it is a situation of a cultural property that is located in some place, at a certain point in time, and with the location playing a specific role in such a situation, so providing a type to that situation. A time indexed typed location is therefore associated with a a-loc:LocationType (e.g. a-loc:FindingLocation, a-loc:ExhibitionLocation, etc.). tiapit:atTime relates the situation to its temporal validity, a-loc:atLocation expresses the geographical entity involved in the situation, while its subproperty a-loc:atSite is used when this entity is a physical building that hosts cultural properties, and is related to at least one cultural institute. For instance, the Pitti Palace is the cis:Site of the cultural institutes “Palatine Galleries”, “Museum of Custom and Fashion” and others, and hosts many cultural properties.

Figure 10b depicts one of the time-indexed typed locations of a balsarium glass from the Imperial Roman age:53

A cultural property can be involved in many different situations during its life: it can be commissioned, bought or obtained, used (e.g. a garment wore by one person), it can be part of a collection, photographic or numismatic series, can change its availability as a result of theft, destruction or rescue, etc. Each situation defines a contextual relation between the cultural property and the other entities involved. The Situation54

For example, when a coin is issued, many entities play a role in such context: the cultural property itself, the issuer, the issuing State, the mint and the minter. The “coin issuance” is a situation representing the relation that keeps together all these entities for that purpose. Figure 11 shows how we model the coin issuance (a-cd:CoinIssuance) by implementing this ODP.

OPEN IN VIEWER

Fig. 11.

Situation ODP reused for representing the coin issuance.

OPEN IN VIEWER

Fig. 12.

Situation ODP reused for the authorship attribution.

A central situation in which a cultural property can be involved is the authorship attribution, a specific type of a-cd:Interpretation, i.e. a situation in which pieces of information about a cultural property are processed by an agent (a-cd:isInterpretationprovidedBy), and produce explicit knowledge, based on a specific source or criterion (cf. Section 4.5 for the distinction between factual, interpretive, and reporting situations). As in Fig. 12, an a-cd:AuthorshipAttribution is a situation in which one author is attributed to a cultural property, and this attribution is motivated by an a-cd:InterpretationCriterion, e.g. inscription, bibliography, documentation. Each cultural property has at least one preferred authorship attribution and/or a cultural scope attribution (e.g. Swedish workshop), and can have one or more alternative (i.e. previous and obsolete) authorship attributions.

Let us take as an example a coin55

OPEN IN VIEWER

Fig. 13.

An instance of the model in Figs 11 and 12: a numismatic property involved in a coin issuance and a preferred authorship attribution.

The technical status of a cultural property Another example of situation involving a cultural property is its technical status. In this case, a cultural property is related to a set of technical characteristics, intended as its technical aspects, attributes or qualities. For instance, “the archaeological cultural property realised with pottery material and cylindrical in shape”. Technical status refers to physical features, since it involves characteristics of entities that are either physical objects or physical realisations of information objects. These characteristics can change over time, thus modifying the technical status of the cultural property: for example, a new survey on an archaeological monument may discover new materials used for its foundations. The temporal validity of a technical status refers to the moment when the characteristics were observed (and recorded in the catalogue record), until when a new condition occurs.

Different technical characteristics of a cultural property can be specified, in order to describe its technical status: the constituting materials (e.g. wood, clay), the employed techniques (e.g. oil-painting, melting), the shape (e.g. square, octagon), the file format for a digital photograph (e.g. “.gif”, “.jpeg”), the prevalent colour of a garment, etc. All these concepts (i.e. material, technique, shape) classify the corresponding technical characteristics (i.e. wood, oil-painting, square). The Classification56

A specific set of technical concepts classifying the technical characteristics of a cultural property type (e.g. an artwork) represents a way to conceptualise the technical status of a cultural property, hence they constitute a technical description (cf. Section 4.2 for the foundational description pattern reused here). For example, an artwork technical description may be defined as the relation between constituting material, employed technique, and shape. We say that such technical description uses these concepts. The technical status of artwork A1 could be wood, oil-painting, and square, while the technical status of artwork A2 could be clay, melting, and octagon. Both technical statuses are expressed according to the artwork technical description: we say that they satisfy it. The Description and Situation57

OPEN IN VIEWER

Fig. 14.

The D&S pattern reused and specialised for modelling technical descriptions and status of a cultural entity.

Figure 14a shows how we model the a-dd:CulturalEntityTechnicalStatus, which includes the a-dd:TechnicalCharacteristics observed on a cultural property, as a subclass of core:Situation. The technical characteristic is modelled as a subclass of l0:Characteristic, which is aligned to d0:Characteristic, i.e. a union of dul:Parameter, dul:Quality, dul:Region. Each characteristic is classified by a a-dd:TechnicalConcept, e.g. the a-dd:Shape. For the most common values of technical concepts we provide a controlled vocabulary. These concepts are used in the a-dd:CulturalEntityTechnicalDescription, defined as a subclass of l0:Description.

Let us take a compass by an Italian workshop of the 19th century58

The involvement of a cultural property in an exhibition during its life cycle would be referred to, in everyday language, as a cultural event. When we informally refer to the repetition of a cultural event (e.g. different editions of an annual painting award), we use the term recurrent event as we are talking about an event that occurs more than once. Actually, we are implicitly referring to a series of conceptually unified situations: for example, the Art Biennale59

As these particular series of situations unfold, we can recognise a pattern in their iteration: an exhibition that has different editions over years usually follows a pattern in planning consecutive editions at regular time intervals (e.g. one edition per year). Moreover, it is possible to identify attributes that give all occurrences a unity: a general topic that does not change i.e. contemporary art, a place that hosts the situation i.e. Venice, etc.

OPEN IN VIEWER

Fig. 15.

The new pattern Recurrent Situation Series as implemented in ArCo.

Recurrent situations are usually modelled as a special type of events (cf. Wikidata60

We represent, as depicted in Fig. 15a, recurrent situation series (a-ce:RecurrentSituationSeries) as collections of situations, their members (a-ce:hasMemberSituation). Member situations share at least one common property (e.g. the topic) and are conceptually unified by unifying factors (a-ce:hasUnifyingFactor) that characterise the series. At the same time, a recurrent situation series is a situation, since it provides a relational context to all the member situations. Each member situation has its own time interval and is put in a sequence that relates it to the other member events of the same series (e.g. a-ce:hasNextSituation). The time period that elapses between member situations is (approximately) regular and is an attribute of the series (a-ce:hasRecurrentTimePeriod).

In Fig. 15b we can see an instance of this pattern. The ex:ArtBiennale (Biennale d’arte di Venezia) is a contemporary visual art exhibition, whose member situations are conceptually unified by: the Biennale Foundation as organiser, Venice as place, the promotion of new contemporary art trends as mission. The time period between two consecutive situations of the Art Biennale series is of about ex:2Years. The first three situations member of the series are in a temporal sequence: for example, the ex:ArtBiennale1895 has as immediate next situation the ex:ArtBiennale1897, while the object property a-cd:hasImmediatePreviousSituation relates the 1899 edition to the one held in 1897.

Reusing ontologies and ODPs can be done by following two main different approaches, depending on the conditions and requirements of a project: direct and indirect reuse [54].

Direct reuse This approach consists in directly embedding individual entities or importing implementations of ODPs or other ontologies in the local ontology, thus making it highly dependent on them. This may jeopardise the stability of the ontology if the evolution of the imported ontologies is outside the control or monitoring of the team/organisation that is reusing them: even small changes in the reused ontologies could introduce inconsistencies in the local one, contrary to its original requirements. For this reason, ArCo directly reuses only two ontologies that are considered reference standards by the Italian Government and the evolving process of which is relatively slow and systematised, and involves ArCo’s team. These ontologies are Cultural-ON,63

Indirect reuse In this approach, relevant entities and patterns from external ontologies are used as templates, by reproducing them in the local ontology and providing possible extensions. Alignment axioms (such as rdfs:subClassOf and owl:equivalentClass) are introduced to support interoperability with other ontologies and make it evident what parts have been reused. This practice decreases the dependency on external ontologies, and is widely adopted in ArCo.

Annotating reused patterns supports the identification of ontology alignments, which is a tedious, non-trivial task. In fact, ODP annotations may ease the process to understand and explore an ontology. These assumptions have driven the development of the simple Ontology Pattern Language annotation (OPLa)66

OPEN IN VIEWER

Fig. 16.

An example of a reused ODP annotated with OPLa ontology.

CQ verification, inference verification and error provocation The logical dimension is addressed by running a reasoner on ArCo KG. This is a necessary step, but not sufficient. We regularly run a reasoner, but we perform additional tests at each iteration of the design methodology, i.e. every time new requirements are selected to be addressed. In doing so, we adopt the testing methodology described in [7]. This methodology focuses on evaluating the appropriateness of an ontology against its requirements intended as the ontological commitment expressed by means of CQs and domain constraints, i.e. functional dimension. User stories are translated into one or more CQs and general constraints during the design phase. To each CQ and to each constraint corresponds a unit test, which contributes, when run, to validate the ontology. Thus, the core element of each unit test is either a CQ or a general constraint (e.g. disjointness axiom). Accordingly, three different approaches are followed in the testing activity: CQ verification, inference verification, error provocation.

CQ verification This approach consists in testing whether the ontology vocabulary allows to convert a CQ, reflecting an ontology requirement, to a SPARQL query. Let us consider the CQ “When was a cultural property created, and which is the interpretation criterion which the dating is based on?”, which ArCo ontologies should answer, based on the collected requirements. The testing team starts verifying the completeness of the ontologies by translating this question from natural language to SPARQL, using classes and properties defined in ArCo ontologies (e.g. the entities defined for representing the date of creation of a cultural property). This step allows to detect any missing concept or gap in the vocabulary, e.g. whether the concept of interpretation criterion has been modeled. If the CQ can be successfully converted, the testers run the resulting SPARQL query over the actual RDF data or, when missing, over artificial data generated for testing purposes using Fuseki,70

Inference verification This step focuses on checking the inferences over the ontologies, by comparing the expected inferences to the actual ones. Let us consider a complex cultural property, which is a cultural property with one or more components, as proper parts. If a :ComplexCulturalProperty is defined as a :CulturalProperty that has one or more :CulturalPropertyComponents, an axiom stating that a :CulturalProperty has a :CulturalPropertyComponent would suffice to infer that the property is complex, even if it is not explicitly asserted. For comparing this expected inference with the actual one, the testing team injects the necessary data in the knowledge graph – e.g. an instance of the class :CulturalProperty related to an instance of the class :CulturalPropertyComponent through the object property :hasCulturalPropertyComponent – and runs the reasoner. If the reasoner does not infer that the first instance is rdf:type:ComplexCulturalProperty, this means that the appropriate axiom is missing from the ontology, i.e. an equivalent axiom between :ComplexCulturalProperty and (:hasCulturalPropertyComponent some :CulturalPropertyComponent).

Error provocation This third testing activity is intended to stress the knowledge graph by injecting inconsistent data that violate our requirements.

For instance, the entities representing the concepts of dating and attributing an author to a cultural property should be disjoint, since there can be no individuals that are dating and authorship attributions at the same time. For validating the ontology regarding this requirement, the testers inject in the KG an individual belonging to both a-cd:AuthorshipAttribution and a-cd:Dating classes, and run the reasoner. The expected result is an inconsistency: if this is not detected by the reasoner, it means that the appropriate (disjointness) axiom is missing.

Refactoring and integration Problems spotted during the testing phase are passed back to the design team as issues. The design team refactors the modules and updates the ontology after performing a consistency checking. The result of this step is validated again by the testing team before including the model in the next release.

Evaluation tool We rely on TESTaLOD [11] for dealing with testing activities associated with CQ verification, inference verification, error provocation. TESTaLOD is a tool designed and implemented in the context of ArCo’s project for supporting not only the testing team of ArCo KG, but in general any testing team of projects adopting XD methodology or other test-driven methodologies. TESTaLOD is developed as a Web application71

OPEN IN VIEWER

Fig. 17.

Workflow implemented by TESTaLOD based on the user interface.

Let us consider as an example the competency question “Which archival set (fonds, series, subseries) a cultural property is member of?”, and that we want to verify if our ontology models information on membership of cultural properties to archival record sets. The test case for running this test will be an OWL file, annotated with the following properties:72

In order to allow TESTaLOD to automatically run this test, two new annotation properties73

Terminological coverage Additionally, we further analyse the functional dimension by setting up an experiment aimed at assessing ArCo ontologies with regards to their ability in capturing and conveying domain-specific terminology. Inasmuch as only measuring the terminological coverage for ArCo ontologies might not be informative, we set up this experiment as a comparative analysis. For the comparison we select EDM74

Experiments execution and results The results recorded are the following.

Inference and CQ verification, and error provocation We define 18 test cases for inference verification, 29 test cases for error provocation, and 55 test cases for competency question verification. Each test case is publicly available on GitHub77

Terminological coverage The ontology alignment is computed with Silk [65] by using the substring metric with 0.5 as threshold. The alignment with the vocabulary is executed three times, i.e. once for each ontology involved in the comparison. The configuration files provided as input to Silk are available on FigShare.79

OPEN IN VIEWER

Fig. 18.

The terminological coverage as recorded for ArCo, EDM, and CIDOC CRM.

For assessing the structural dimension of ArCo KG we use different metrics that have been defined and used in literature [13,27,44,49,58,63,66]. First, we compute base metrics that record quantitative aspects of ArCo knowledge graph: classes and their instances, properties, axioms, etc. Then, we compute schema and graph metrics aimed at assessing (i) the richness, width, depth, and inheritance at the schema level and (ii) the cohesion, coupling, multihierarchical degree, and extensional coverage of the ontologies. Those parameters are used for understanding the quality of ArCo expressed in terms of (i) flexibility, (ii) transparency, (iii) cognitive ergonomics, and (iv) compliance to expertise. These quality properties have been defined in [27]: (i) flexibility is the property of an ontology to be easily adapted to multiple views; (ii) transparency is the property of an ontology to be analysed in detail, with a rich formalisation of conceptual choices and motivation; (iii) cognitive ergonomics is the property of an ontology to be easily understood, manipulated, and exploited by its consumers; and (iv) compliance to expertise is the property of an ontology to be compliant with the knowledge it is supposed to model.

Table 280

We focus on ArCo KG v1.0, which counts 20,030,941 individuals, for analysing the distribution of those individuals across classes. Such an analysis allows us to understand how individuals are organised in the knowledge graph with respect to concepts. This suggests possible compliance to expertise. In fact, it provides an indication about the recall of classes over the entities of the domain (i.e. the individuals). In this case the recall is meant as extensional coverage computed as the average number of entities captured by ontology classes. It is worth saying that compliance to expertise has a strong functional characterisation that we investigate further by analysing the functional dimension. Notwithstanding, the distribution of the instances across classes is a fair structural metric as it provides us a tool for empirically validating if dense areas (most populated parts of the ontology) correspond to ontology design patterns. The use of patterns is among the indicators suggested by [27] for measuring the quality properties of transparency and cognitive ergonomics. Figure 19 shows the top-50 ranked classes based on the number of individuals they have in the knowledge graph. The ranking including all the classes can be retrieved by querying the knowledge graph.86

OPEN IN VIEWER

Fig. 19.

Top-50 ranked classes according to the number of individuals they have in the knowledge graph.

A high degree of modularity in an ontology is an indicator of transparency and flexibility. ArCo ontology network is highly modularised, however addressing transparency and flexibility meaningfully requires appropriate design of ontology modules. We compute the following metrics to assess the quality of ArCo modules.

Table 4 reports the values recorded for the aforementioned module metrics computed for each ontology module of ArCo. Module metrics are obtained by using the Tool for Ontology Module Metrics87

In the context of ArCo’s project, performing the testing activities initially resulted in a significant manual effort, for both annotating and running the unit tests. For this reason, TESTaLOD has been designed and implemented. The successful execution of inference verification, error provocation, and competency question verification is an indicator of (i) computational integrity and efficiency, and (ii) compliance to expertise. The former suggests that the ontology can be successfully processed by a reasoner. The latter suggests that ArCo KG is compliant with its collected requirements. Finally, the terminological coverage measured for ArCo (i.e. 0.72) shows very good results. In fact, the comparison with the results obtained for the Europeana Data Model (EDM) (i.e. 0.07) and for CIDOC CRM (i.e. 0.2) supports the claim that the expressiveness provided by such existing reference ontologies is not completely suitable for addressing ArCo’s requirements.

The analysis of the structural dimension shows that ArCo KG provides a larger terminological component than CIDOC CRM and EDM with 3,416 logical axioms, 340 classes, etc. ArCo is a massive knowledge graph counting of 172,580,211 triples describing 20,030,941 individuals. Nevertheless, ArCo is smaller than Europeana, which in turns counts of 2,836,270,332 triples describing 415,410,190 individuals. This finding is fair, first because ArCo is much younger than Europeana. Additionally, we remark that ArCo organises knowledge about Italian cultural properties only; on the contrary, Europeana contains structured knowledge about digital artifacts provided by 28 EU countries. Then, if we analyse the indicators obtained, we record that they suggest good transparency. In fact, we record:

Low coupling (i.e. NoC) and high cohesion (NoR, NoL, and ADIT-LN) also suggest flexibility, i.e. the property of adapting or changing the ontology with limited side-effects. The property of cognitive ergonomics (i.e. property of a knowledge graph to be easily understood, manipulated, and exploited by final users) is suggested by:

With respect to the evolution of ArCo KG during the design process, we record a significant growth of the knowledge graph from v0.1 to v0.5. For example the number of axioms, classes, and object properties changes from 715, 54, and 38 to 9,564, 329, and 332, for v0.1 and v0.5, respectively. This observation is confirmed by the fact the knowledge graph counts ∼ 133 M more triples in v0.5 than in v0.1. On the contrary, we observe a smoothening of the growth curve from v0.5 to v1.0. As a matter of fact, the number of classes varies from 329 to 340 and the knowledge graph increases of ∼ 3 K triples from v0.5 to v1.0. This means that: (i) from v0.1 to v0.5 the design process is more focused on the building of the knowledge graph from scratch by means of iterative development cycles; (ii) instead, from v0.5 to v1.0 we observe the change of the design approach towards iterative refinements of the knowledge graph. The refinement activities are fairly evident if we take into account the number of individuals. In fact, such a number, between v0.5 and v1.0, goes down from ∼ 22.5 M to ∼ 20 M . This is due to data cleansing operations aimed, for instance, at collapsing duplicate entries (e.g. a same author associated with multiples IRIs). If we focus on the metrics reported in Table 3, we observe comparable values among ArCo v0.1, v0.5, and v1.0. This is an indicator of the fact that the design process has followed a homogeneous strategy imposed by the pattern-based approach. As an example, we record similar among the three versions for relationship richness, inheritance richness, class/property ratio, average breadth, and ADIT-LN.

Module metrics suggest that all modules are modelled by following a similar design principle: identifying small and highly cohesive partitions as basic building blocks for ontology design. This result is fully compliant with the pattern-based approach adopted for modelling ArCo. As a matter of fact, the atomic size values we record are low and they differ only slightly from one module to another, i.e. ranging from 4.85 (core module) to 6.63 (context description module). The appropriateness values recorded are optimal ( = 1 for all modules). In fact, the appropriateness value for a module ranges from 0 (i.e. no appropriateness) to 1 (i.e. complete appropriateness) [44]. We record excellent values for encapsulation ( ∼ 1 for all modules). We remark that encapsulation values range from 0 (i.e. no encapsulation) to 1 (complete encapsulation). According to [13] a high encapsulation value is a good indication of the quality of a module. In fact, it suggests that such a module can be easily exchanged for another, or internally modified, without side-effects. The extremely low value for coupling ( = 0 for all modules) is excellent. Again, coupling values range from 0 (i.e. low coupling) to 1 (i.e. high coupling). Low coupling for an ontology module means that its entities do not have strong relations to entities in other modules. Accordingly, it is easy to modify and update such modules independently. Furthermore, the high encapsulation values along with the low coupling values suggest a high degree of independence of a module. This indicates that ArCo modules are self-contained and can be updated and reused separately. Thus, ArCo modules address the flexibility property identified by [27], which prospects an ontology/module that can be easily adapted to multiple views.

7.1. Reusing existing ontologies and patterns

eXtreme Design is a methodology that encourages the reuse of Ontology Design Patterns (ODPs), as common modelling solutions to classes of problems recurring in ontology design. Patterns to be reused can be both selected from dedicated catalogues (such as the ODP Portal (footnote 67)) and extracted from state-of-the-art ontologies. In Section 5.4 we briefly explained the two main practices for ontology reuse: direct and indirect [54].

Even if ODP catalogues represent a relevant support for pattern-based ontology design, there is a lack of well-documented and well-maintained high-quality ontology design patterns, as well as of tools for supporting ODP-driven ontology-engineering [5], which could guide the user in the selection of ODPs, e.g. by recommending possible ODPs to be reused for a certain modelling requirement. Additionally, using available ontologies as input to generate new ontologies is a difficult process, far from being automated [8,42,64], and can be hampered by scarcely documented ontologies, ontologies big in size and with a high number of classes, properties and axioms. Moreover, there is a need to carefully (thus time-consuming) consider the context, intended usage and semantic meaning of the ontology entities. Issues in reusing existing ontologies seem to be confirmed by [1], which observes a lack of explicit alignments between ontological entities in Linked Open Data, while the high number of top level classes may suggest a high number of conceptual duplicates.

Ontology reuse would benefit from annotations about the ODPs implemented by ontologies: [37] proposes a simple representation language for ontology design patterns (OPLa ontology), which makes use of OWL annotation properties for documenting ODPs. OPLa certainly contributes to fill a gap but its expressiveness requires an improvement. ArCo ontologies have been annotated with OPLa, but we soon realised that we were missing many relevant attributes of, and relations between, patterns that could be annotated and therefore possibly later detected from other parties.

As described in Section 5, during ArCo KG development we incrementally selected CQs from the available list and then match them with one or more existing ODPs. In this process, we also inspected state-of-the-art ontologies, such as CIDOC CRM (footnote 75), EDM (footnote 74), BIBFRAME,88

Testing an ontology network, which is periodically released in unstable and incremental versions, can be a time-consuming and repetitive activity, and, if performed manually, error-prone. Tests need to be run in order to validate our ontology, by translating competency questions into SPARQL queries, verifying expected inferences and provoking expected errors. Each time there are changes over the ontologies (e.g. a new version which models new information), new tests are created, and all previous tests must be executed again and, if needed, updated, in order to identify new possible bugs.

While performing testing in the context of ArCo KG, we realised that tools automatising it would have been of great support for the testing team. Building TESTaLOD (described in Section 6.1) helped us executing tests over new versions of the ontology network, allowing for automatic regression tests. At the moment TESTaLOD only addresses CQs-based testing and their corresponding SPARQL queries. Tests for inference verification and error provocation are executed externally. Moreover, the creation and annotation of test cases is not automatised. We believe that developing tools supporting (semi-) automatic creation of unit tests is of paramount importance to push the overall quality of released knowledge graphs. TESTaLOD is just a scratch on the surface of a possible tool suite for automatising many activities of ODP-based and test-driven methodologies such as XD.

7.3. Extended customer team for Cultural Heritage LOD projects

In ontology engineering methodologies, domain experts are the main actor and input source of requirements and validation tests: they give a crucial contribution, especially in defining domain and task requirements that guide the ontology design and testing phases [46]. User stories (then translated into Competency Questions) were used as a lingua franca for making communication effective between ontology designers and ICCD domain experts, during the development of ArCo KG.

Whilst not denying the key role played by ICCD domain experts in eliciting requirements, by means of both cataloguing standards, catalogue records and discussions on specific topics and issues, we believe that the Cultural Heritage (CH) domain has a specificity in its users: the community interested in CH data for different purposes is wide and diverse, involving domain experts, researchers, art critics, students, simple citizens, institutions and companies owning and managing CH data or data on related domains (e.g. tourism), public administrations and private companies offering services related to the CH domain, etc.

Cultural Heritage is usually managed with a top-down approach, where professionals and data owners (Galleries, Libraries, Archives, Museums, etc.) are in charge of defining standards and means for describing, representing and making available data on cultural heritage. More rarely, end-users are involved in this process. Instead, institutions aiming at enhancing cultural heritage would benefit from a bottom-up approach, alongside a top-down one, for collecting requirements from the community that consumes their data.

Linked Open Data projects can help in getting domain experts closer to their potential wide and diverse audience, and in promoting interactions between them. In carrying out the ArCo’s project, considering the characteristics of the CH domain and CH users, we involved a wider community in the requirements and feedback collection phase. Launching an Early Adoption Program, and involving the community in the unstable and incremental phases of the project, allowed us to capture a wider range of perspectives and requirements. For example, Synapta,90

With ArCo’s EAP, we experimented the involvement of private and public organisations, and extended XD to this purpose by identifying a set of tools (web forms, mailing lists, GitHub issue tracker), and practices that could support collecting requirements from such a diverse community (webinars, meetups). We believe that collecting requirements from a very diverse community is relevant for the CH domain but can apply also to other contexts, hence methodologies and possible supporting tools shall consider this aspect, so far neglected to the best of our knowledge, among their key requirements.

8.1. LOD and ontologies for Cultural Heritage

Projects such as LODLAM92

Publishing and interconnecting data is leading to the creation of international CH portals [39], such as Europeana,99

Along with the publication of LOD collections, ontologies representing the CH domain are being developed, and some of them are becoming widely adopted standards, e.g. the Europeana Data Model (footnote 74) (EDM) [41] and CIDOC Conceptual Reference Model (CRM) (footnote 75) [19]. In addition to them, many other ontologies model specific domains that can be relevant to CH (e.g. the PRO ontology101

ArCo substantially contributes to the existing LOD CH cloud with a huge amount of invaluable data of Italian cultural properties, and an ontology network tackling overlooked modelling issues.

There is quite a variety of knowledge associated with works of art and their dynamics, including their dating, authorship attribution, history, maintenance, symbolic and cultural interpretation, catalog reporting, etc. The design of CH knowledge dynamics requires then sufficient flexibility, which ArCo gathers from its constructive stance, described in Sections 4.2 and 4.5.

We provide here some cases, where ArCo supplies modelling solutions that are not easily obtained in other widely adopted CH ontologies (see also some related foundational differences in Section 4.4).

As an example, the painting “Woman Portrait” by Caspar Netscher (17th century) is associated with several types of locations: it is now located at the Uffizi in Florence, it was stored in 1942 at Poppi Castle, it was involved (hence temporarily moved) in an exhibition at Pitti Palace in Florence in 1773 (cf. Fig. 20).

OPEN IN VIEWER

Fig. 20.

The painting “Woman Portrait” by Caspar Netscher (17th century) and the different (types of) locations it is associated with.

CIDOC CRM allows us to encode the data about all these locations by means of a “move” event that is both temporally and geographically indexed. This representation lacks the means to express (i) the knowledge about the type or motivation of a specific location, e.g. production, exhibition, storage, etc.; (ii) the temporal validity of that location, which is different from the time at which a moving event occurs; (iii) in addition, location types can be further characterised by other data or entities specific to them. In ArCo it is possible to represent the moving event with its temporal and spatial indexing, as well as the (functional) type of its locations with their own temporal validity, and their specificities. We also remark that CIDOC CRM events are defined as state changes, hence they should not be applicable to generalised situations or eventualities. However, CIDOC CRM condition states, which should cover the rest of phenomena (cf. Section 4.4), are not supposed to have participants. While in principle one could possibly extend CIDOC CRM to supply missing modelling solutions, in ArCo we stress the importance of having an explicit constructive stance (Section 4.2) providing patterns for joint modelling of events, situations, interpretations, etc.

Other examples of ArCo design patterns motivated by its constructive stance include: the modelling of catalogue records as entities of the CH domain representing interpretative perspectives on cultural properties, the recurrence of cultural events such as periodic festivals, as well as other situations in which cultural properties are involved (observations, issuances, etc).

Denotation, cataloguing, interpretation When modelling the CH domain, there are at least three levels of representation that might need to be investigated and modelled: (i) the cultural property as such, with its inherent attributes, (ii) the process of systematically gathering and recording pieces of information related to the cultural property, (iii) the process of interpreting these pieces of information in order to extract knowledge about the cultural property. These levels are separate, but interrelated. Cataloguing is a preliminary step for being able to get the attributes of a cultural property into the universe of discourse: for example, a tangible cultural property is made of a certain material, but without observing it, and collecting and recording data about the material of that specific cultural property, this information may be lost: this activity is essential for preserving cultural heritage. Moreover, cataloguing supports interpretations over cultural properties and their history, and interpretations can be in turn recorded by cataloguers.

We will call the first of these levels denotation, as the set of attributes of a cultural property that refer specifically and “literally” to that cultural property, without considering its context and the associated meanings that these attributes can have. The second level, cataloguing, is based on the observation and recording of the directly observable attributes of the cultural property, while the interpretation level discovers new knowledge on the cultural property by interpreting the meaning of one or more attributes within the context, e.g. the observable style of an artwork, or a bibliographic resource about it, can reveal its author.

ArCo distinguishes these three levels (cf. Section 4.5), by providing models for: the denotative representation of a cultural property (materials, conservation status, inscriptions, measurements, etc.); the process of cataloguing (catalogue records as documents describing cultural properties, cataloguing agents, etc.); the interpretation process, with agents involved and criteria guiding it (a-cd:Interpretation).

Both EDM and CIDOC CRM distinguish between the cultural object and possible information resources related to it: crm:E89_Propositional_Object,102

High-level vs. specific ArCo’s requirements are primarily based on the ICCD cataloguing standards: as explained in Section 2, catalogue records can describe 30 different types of cultural properties, each one with distinguishing features, not shared with other types. Specificity is therefore a key characteristic of ArCo ontologies, which provide cultural property-specific models to be reused, extending by specialisation the taxonomy offered by EDM and CIDOC CRM. As explained in [17], EDM has been developed for integrating and making interoperable various metadata standards from a multitude of Galleries, Libraries, Archives and Museums (GLAM) across Europe, as a “common denominator” model to use for the Europeana portal. Therefore, it is by design that EDM does not invest into a fine level of granularity or rich axiomatisation. It provides a basic set of classes and properties, which also includes many Dublin Core104

For example, a musical instrument would be of type edm:PhysicalThing, edm:ProvidedCHO and crm:E22_Man_Made_Object by using without extensions EDM and CIDOC CRM, and of type :MusicHeritage by using ArCo. The same need to specialise concepts can be found in other projects reusing and extending CIDOC, e.g. Zeri&Lode, where FEntry ontology105

Specific types of cultural properties share some features (e.g. location, dating, author), but ArCo also needs to satisfy more modelling issues, overlooked by other ontologies so far, related to specific cultural properties, such as the diagnosis of a paleopathology and the interpretation of sex and age of death in anthropological material, other types of surveys on archaeological objects (e.g. laboratory tests), the coin issuance, the Hornbostel-Sachs classification of musical instruments, musicians and musical ensemble, recurrent art exhibitions, etc.

For example, let us take a modelling problem that a cultural institution publishing data on anthropological materials may need to address: it has been estimated that discovered anthropological materials (teeth, mandible and radius) are from a female individual dead at young age. The assignments of the attributes “female” and “young age” would be modelled in CIDOC as crm:E13_Attribute_Assignment, where the crm:E1_CRM_Entity “female” can be typed (crm:P2_has_type) as sex and “young age” as age of death. There is no means to represent that the sex is attributed based on the size and thickness of radius, and the age of death on the basis of the light dental wear. In ArCo, specific classes and properties, with an explicit semantics, have been created for solving this modelling issue: a-cd:SexInterpretation and a-cd:AgeOfDeathInterpretation, that can be related to the criterion that motivated that interpretation a-cd:InterpretationCriterion. Axioms on the class :ArchaeologicalProperty allow to specify that this type of cultural property can have sex and age of death interpretations.

Even in the case of features shared by most cultural properties, in many cases CIDOC lacks the expressiveness needed for modelling ArCo data without missing information. For example, according to CIDOC, changes of the physical location of a cultural property are represented by move events, and we can only know from and to where the cultural property was moved, and when the move happened, while there is no means to express e.g. the role that a specific location played during a time interval, with respect to a specific cultural property. EDM specialises dct:spatial107

Alignments ArCo is aligned to both EDM and CIDOC CRM.108

Other alignments include: BIBFRAME (footnote 88), FRBR (footnote 89), FaBiO109

As discussed in [17], when building a knowledge graph (KG) for publishing its data, a cultural institution makes a first relevant choice: it can publish Linked Open Data by building and using its own infrastructure, give its data to a cultural heritage data aggregator such as Europeana, or invest in infrastructure for publishing its data as well as in the whole process for producing them, by using the ontology model of an aggregator. In making this choice, a cultural heritage administrator is influenced by different aspects both political, economical and technical.

An aggregator provides a single point of access to different collections from many cultural institutions, giving visibility and guaranteeing respective enrichment and interoperability. Nevertheless, the adopted ontologies only capture a subset and a simplified encoding of the available information about a cultural property because they prefer a lightweight modelling i.e. based on binary relations, as opposed to more complex predicates, e.g. n-ary relations. Many existing CH institutions provide data to Europeana and/or use Europeana Data Model, along with Dublin Core, for representing their collections, such as the Rijksmuseum dataset [18], possibly extending it, as in the case of the VVV ontology [20]. In each of these projects, the institution intentionally chooses to publish only a subset of all the features characterising cultural properties, which are instead present in the original dataset, in order to reuse EDM and avoid a more significant effort in mapping between the input data and the ontology model.

In our opinion, when possible, it is preferable for an institution to carry out the whole process of data production and publication and to release as much rich data as possible, while guaranteeing the interoperability with and the publication (of simplified or subsets of its data) through aggregators: this is the approach followed by ArCo. This choice allows a cultural institution to clearly define its requirements regardless of which data is possible to publish through an aggregator, and by using which ontology. Moreover, such an approach better supports an open requirements collection, not limiting the commitment of the developed ontologies to the institutional guidelines. Having full control on the ontological commitment minimises loss of information contained in input data, for reaching a wide audience of diverse users.