# Representing and Validating Cultural Heritage Knowledge Graphs in CIDOC-CRM Ontology
## 4 Analysis and Validation  
For the purpose of validating and checking the generated knowledge graph, both SHACL and OWL-based techniques were selected. SHACL is a language for checking whether an RDF graph satisfies certain conditions given as \"shapes\" [23]. Using SHACL permits investigating string-matching patterns, value types, and other constraints. Moreover, the framework of SHACL supports high-level validation by expressing more complex conditions in the SPARQL query language. Validation of data and mapping were also performed based on OWL by running reasoner Pellet and SPARQL queries. This latter was performed via Protege and TopBraid Composer to verify the consistency and correctness of mapped data manually based on inferred properties. Protege, a free open-source ontology editor, was used to validate the mapped data using Pellet. Pellet is a Java-based open-source OWL-DL reasoner. For instance, by running reasoner Pellet, an error was raised because the \"P23 transferred title from\" property was used to link E8 Acquisition to E78 Collection rather than E39 Actor. After cleaning the generated RDF file from all syntax errors and bugs and running the reasoner Pellet, the inferred properties were displayed with a yellow background. In Figure 12, the inferred properties (p11i_participated_in, p12i_was_present_at...) of the person \"n16143\" are outputs of this reasoning based on the hierarchies. It was challenging to run SPARQL queries in Protege due to performance issues. For instance, in Figure 13, we ran a SPARQL query to retrieve all collectors who collected a collection between 1988/01/01 and 2003/01/01. Figure 12: An example of inferred properties for a person n16143. We chose TopBraid Composer over Protege due to the fact that it permits generating SHACL shapes using a user-friendly interface. In Figure 14, for example, we executed the SHACL shape, which was expressed with more complex conditions in a SPARQL query, to check whether there were duplicated places with different URIs. The error messages with detailed information (focus node, value) are displayed in the SHACL Validation tab. The overall validation can be classified into several categories:  
1. Ontology-based validation: here the constraints defined using OWL can be validated, for example: * Type validation: checking whether the source data is mapped to the appropriate data type, and only to that. The validation of restrictions and cardinality constraints (if any) falls into this category as well; * Property validation includes the checking of the domain and range types and the cardinality of functional properties. For example, a painting is denied the birthdate property;  
Figure 14: Validating same places with different URIs. Figure 13: SPARQL query about collectors between 1988 and 2003. Data validation: the format of data for data properties can be checked. For example, incorrect dates, incorrect language tags, or characters outside of UTF-8 may be detected. 2. Contextual validation is based on common sense and domain knowledge, and it includes constraints that are hard or impossible to represent in OWL or were simply forgotten during ontology implementation: * Temporal validation: the events should be in a logical order, e.g., birth, marriage, death. For example, events in a collection must follow its creation. Table 5 is an example of using SHACL to conduct temporal validation via TopBraid. The below shape inspects whether a person's birthdate occurred before the dates of all his/her activities; * Spatial validation: the locations must adhere to logical containment. For example, featured item I of collection C must be in the same location as C; * Uniqueness validation: there should be one URI and RDF representation for each entity. For example, we detected and merged multiple RDF individuals for cities and people; 3. Validation of mapping is used to check if properties and classes are translated in the right way.