A strategy for archives metadata representation on CIDOC-CRM and knowledge discovery

3.1.CIDOC-CRM recomendations

The translation of the Archival metadata into the CIDOC-CRM representation follows the main principles of the CIDOC-CRM model44 [5,31].

3.2.Information useful for natural language interpretation of text or queries

With the focus on the development of an interface to query the knowledge base in Natural Language and, in the near future, the automatic information extraction from text, it is important that the information representation in the ontology facilitates the interpretation process of Natural Language expressions. The interpretation of a Natural Language expression requires the inference of instances, classes or/and properties in the ontology.

Consider, for instance, the concept ‘Country’ that could be represented in the ontology as a class. If the ontology does not have a class with that concept, a general concept should be considered, such as ‘Place’, and then define ‘Country’ as a subclass of ‘Place’. However, by the first main principle of CIDOC-CRM recommendation, a new subclass should not be created. Therefore, there are two alternatives, first one is to create an instance of the class ‘Place’, losing the subconcept ‘Country’, and the second one is to create an instance of the class ‘Place’ connected with an instance of ‘E55 Type’ with value ‘Country’, using the property ‘P2 has type’.

The second alternative is more informative than the first one, since it is possible to model the subconcept ‘Country’, allowing to retrieve easily all instances that have type ‘Country’. Therefore, the following rule is taken into account when defining the mapping between ISAD(G) and CIDOC-CRM:

Fig. 2.

Representation of an instance V of the class C1, which is a subclass of the class C2.

This rule is always used whenever the concept C1 can be represented by Natural Language expressions in an ontology query. For instance, consider the query “Which are the countries that produced baptism materials?”. The result should be a list of instances of ‘Place’ that has type ‘Country’ and produced baptism materials. To interpret the meaning of an expression, such as ‘Country’, a noun, it is necessary to search for:

The similarity calculus will be higher for the second interpretation, since the expression ‘Country’ is closer to the second expression than to the expression ‘Place’. The second interpretation is enabled by representing the concept ‘Country’ with the rule 1 above and this representation captures the meaning of the expression ‘Country’ in the query.

Another rule that is taken into account in the mapping process is that:

Fig. 3.

Representation of the type of an appellation.

This rule is always used whenever the name can be represented by Natural Language expressions in an ontology query. For instance, consider the query “Which are the institution’s abbreviations?”. The result should be a list of instances of the class ‘E41 Appellation’ (or ‘E42 Identifier’) that are classified as ‘institution abbreviation’.

The matching between the sentences terms (nouns, adjectives, prepositions, verbs, named entities) and classes, properties and instances of an ontology is a common step in natural language interpretation for querying an ontology or mining text to populate an ontology [6,15,21,22].

3.3.Mapping description rules

As mentioned before, each unit, at some level of description, has a well-known structure of information defined by the ISAD(G) elements. In order to define the representation of each unit, the elements can be grouped, according to their content and what they refer to, and associated with three concepts, namely the object itself that belongs to the physical archive; the digital registration that describes the object; and the language properties associated to the object (when they exist). These three concepts are mapped into the following CIDOC-CRM classes, respectively ‘E22 Human-Made Object’; ‘E31 Document’; and ‘E33 Linguistic Object’. Whereby, each unit is itself mapped into an instance of ‘E31 Document’, that documents (property ‘P70 documents’) a physical object (an instance of ‘E22 Human-Made Object) and refers to (property ‘P67 refers to’) a conceptual object (an instance of ‘E33 Linguistic Object’).

The hierarchical structure of the archives is represented using the relation ‘P106 is composed of’ between the ‘E31 Document’ and their sub-documents (also represented as individuals of the class ‘E31 Document’).

These representations follow the CIDOC-CRM recommendations, and similar approaches for representing archives and collections, presented in [3,14,32]. The representation of the archival description units in the CIDOC-CRM Ontology is done through rules that express the metadata mapping into the ontology entities. These rules define the set of Mapping Description Rules that establishes the basis for the automatic migration process. Table 5, in the Appendix, presents some of the Mapping Description Rules defined.

Therefore, the representation of the unit explained before is translated into the rule No. 1, showed in Fig. 4, and the hierarchy of the archive is captured in rule No. 17, and showed in Fig. 5.

Fig. 4.

Rule No. 1 – Unit of description.

Fig. 5.

Rule No. 17 – Hierarchy.

Consider, for instance, the ISAD(G) element ‘Reference code’, with value ‘PT/TT/…’. Each unit is uniquely identified by this code. The ‘Reference code’ can be represented as an instance of the class ‘E42 Identifier’, and to represent that the value of the reference code is the identification of the unit, it is possible to use the property ‘P1 is identified by’, resulting the statement ‘E31 Document’ ‘P1 is identified by’ ‘E42 Identifier {= PT/TT/…}’, see Fig. 6.

Fig. 6.

Reference code representation as the unique identifier of a document.

However, in this representation, the information that the ‘Reference code’ is the identifier of the document is implicit. If this information needs to be explicit, then it is possible to apply a type to the identifier with the rule ‘E42 Identifier {= PT/TT/…}’ ‘P2 has type’ ‘E55 Type {= Reference code}’, as illustrated in Fig. 7.

Fig. 7.

Reference code representation as the unique identifier of a document and a type.

If the same ‘reference code value’ expression is intended to be used to identify other entities, then the identifier could have other types depending on the entity that it identifies. So, the type of the identifier on the document should be placed on the relation ‘P1 is identified by’, as shown in Fig. 8.

Fig. 8.

Reference code representation with the type on the P1 relation.

But OWL2 only allows the use of binary properties, so this representation should be done as presented in Fig. 9 and follows the recommendation of CIDOC-CRM [31,33]: a subclass of ‘PC0 CRM Property’ is created with the name of the property that has a type, PC1, ‘PC1 is identified by’ with a new data property ‘P1.1 has type’. The properties P01 and P02 are already defined in CIDOC-CRM, where class ‘PC0 CRM Property’ is the domain and ‘E1 CRM Entity’ is the range.

Fig. 9.

Reference code representation with the type on the P1 relation as binary relation.

Fig. 10.

Rule No. 2 description level.

However and as explained before, the expression of ‘reference code value’ is a unique value and with the intention of allowing to search and retrieve information using the term ‘reference code’, the mapping description rule used for this element needs only to establish the type over the identifier, as illustrated in Fig. 7, and captured by the rule No. 3, shown in Table 5 (the Appendix). The representation illustrated in Fig. 9 is used when the identifier instance of ‘E42 Identifier’ can identify more then one instance and can have more then one type. For instance, ‘PT’ can be an instance of ‘E41 Appellation’ with type ‘Country abbreviation’ when it identifies a Place, or it can be an ‘E41 Appellation’ with type ‘Person name abbreviation’ when it identifies a Person. Whenever the same instance of the class ‘E41 Appellation’ identifies different entities, the type classification must be on the relation as it happens in rules No. 6, No. 7, No. 8, No. 13, No. 14 and No. 15, of Table 5 (the Appendix).

Consider now the element ‘Description level’ of an unit. Its value establishes the type of the unit, according to ISAD(G) model of the constituents description units of an archive (Fig. 1), such as Fonds, Sub-Fonds, Series, Sub-Series, File, Item, etc. As a result, it is considered that the ‘Description level’ is the only type property of the ‘E31 Document’ that represents the unit. So an instance of ‘E55 Type’ is created with the value of the unit type and this instance will have the type ‘Description level’, if those instances do not exist already. Additionally, the property ‘P2 has type’ is added to link the ‘E31 Document’ to its type ‘E55 Type’ (see Fig. 10). This representation is adequate for the interpretation of natural language queries, since it makes explicit that the value is a ‘Description level’. Note that if an unit could have more then one type, then the type of the type should be the property ‘P2.1 has type’ (similar to the one explained before and showed in Fig. 9). The Mapping Description Rule No. 2 (Table 5, the Appendix) captures the translation of the ‘Reference code’ element into CIDOC-CRM representation.

According to the proposed representation of the unit of description, the ISAD(G) elements are linked to the classes that represent the unit in CIDOC-CRM, as follows:

The Mapping Description Rules are presented in Table 5, in the Appendix, including the formalism interpretation used, and they are also displayed in a diagram format for better understanding.

4.1.DigitArq metadata extraction

The DigitArq database contains a large and diverse amount of records, currently over 2 millions. As mentioned before, this database is structured, using a well-established standard archival description, with a hierarchical structure adapted to the nature of archival assets.

Along with the development of the DigitArq database, a web-based search engine (web service) was developed to allow local and remote users to find and browse the Archive’s collections. The result is a well-structured and normalised web service66 that for each unit shows the whole information needed to be considered in the migration process.

For this purpose, the jsoup library77 is used to extract web page content from specific fields. jsoup is a Java HTML Parser that provides a very reliable, user-friendly, and easy configuration and parameter adjustments capabilities, for connecting to URLs and extracting and manipulating data.

The use of jsoup library to extract information from web pages to be analyzed and interpreted is not new, and can be found in [4,9]. The first one presents a solution for querying Greek governmental site, and the second one presents a solution to extract semi-structured information from web pages in the context of the innovation environments of the state of São Paulo, Brazil.

Each record’s web page has a standardized scheme following the ISAD(G) and ISAAR(CPF) definitions, with the information organized according to a set of known fields and their values. Among this set of fields, there are some that present atomic values, such as “Reference code”, “Title”, or “Recipient”, and others, that do not need further interpretation and the migration process is directly performed by applying the already introduced Mapping Description Rules (summarized in Table 5, the Appendix).

As an illustration, consider the fonds record, named “PARÓQUIA DE ALDOAR”,88 which describes the set of archival documents that composes it, regardless of its form or support, and concerning to baptisms, weddings, deaths, usages and customs, legacies and obligations of religious masses and indices registered by the Parish of Aldoar, from Oporto district, Portugal.

Using a set of jsoup functions, it is possible to extract information like the title, and other ISAD(G) elements (fields), as well as their values, presented in the web page record. For instance, the function title() allows to extract the title of the record; the function getElementsByClass() allows to extract the information per elements, as well as to get the set of its child records; the function f.select(“span”).first().html() allows to extract the name of each field and their values could be obtained using the function text(). jsoup also provides functions to connect and parse directly the web page source, such as connect() followed by get(), and parse(), respectively. The fragment of Java code Listing 1 illustrates how this is performed. Using such strategy to extract information, it is possible to consider other public webpage platforms as database that can offer the same or additional information, such as the “Archives Portal Europe”.99

Listing 1.

Metadata extraction Java code for the fonds record “PARÓQUIA DE ALDOAR”.

Some of the fields and the corresponding values extracted from “PARÓQUIA DE ALDOAR”’s fonds record are presented in Table 1.

The information extracted is adequately analysed, where each fields’ name and their values are identified, the adequate ontology representation is established, and the corresponding ontology entities, such as individuals and properties, are then generated. This process is made by applying the set of Mapping Description Rules, some of them presented in Table 5(the Appendix) and introduced in the previous Section 3. Its implementation is explained with more detail in the following subsections.

4.2.Migration process from DigitArq into CIDOC-CRM

The migration process consists of generating CIDOC-CRM ontology instances (classes and properties instances) by applying the Mapping Description Rules (see Section 3.3) to the DigitArq information.

At this step, the OWL API1010 [11] and the SPARQL-DL1111 [13,30] libraries are used to upload and model the CIDOC-CRM1212 [5,31] archival representation into a well-structured model for Java environment, to implement the mapping description rules, to update the mapping knowledge base, and also to reasoning over the knowledge base. The OWL API is a high level Application Programming Interface (API) for working with OWL ontologies, and is closely aligned with the OWL 2 structural specification.1313 It supports parsing and rendering in the syntaxes defined in the W3C specification, manipulation of ontological structures, and the use of reasoning engines. The SPARQL-DL is a Java query engine, settled on top of the OWL API, and it is fully aligned with the OWL2 standard and adds a SPARQL-DL interface to every OWL API 3 reasoner.

Using the mentioned tools, the set of commands representing each mapping description rule is directly translated to Java instructions, which allows for automatically generate the CIDOC-CRM representation for each DigitArq record, and save it in OWL2 format.

As mentioned in the previous Section 4.1, each DigitArq database record, interpreted as a unit of description, has a well-known structure represented by a set of fields and their values, as well as their hierarchical relationship with other units, according to archival standards. As presented before, the migration process defines for each unit the application of:

For better understanding, let us go back to the fonds unit “PARÓQUIA DE ALDOAR” and consider the elements ‘Description level’, ‘Reference code’, ‘Language of the material’, and ‘Date range’. Figure 12 shows the solution obtained in the mapping process by applying respectively the rules No. 2, No. 3, No. 4 and No. 11 for the corresponding elements and their values. The mapping representation of the unit is obtained by applying the rule No. 1, and the mapping representation of the hierarchical relationship with other units is obtained by applying the rule No. 17. The fonds unit is composed by 8 other units (Fig. 12 just presents 2 of them), each one with the classification of ‘Series’ as ‘Description level’ (and each one is composed by other units [23]). The size of the hierarchy depends on the type and composition of the fonds and on what is described in DigitArq database. The complete representation of the fonds unit “PARÓQUIA DE ALDOAR” in CIDOC-CRM representation is obtained by applying the mapping process for each unit, belonging to the hierarchical tree of the fonds. Table 2 shows the mapping process metrics of the CIDOC-CRM representation of the fonds unit “PARÓQUIA DE ALDOAR”, as well as its complete hierarchical composed units.

Fig. 12.

The fonds unit “PARÓQUIA DE ALDOAR” partial mapping.

4.3.Ontology knowledge discovery

The Ontology Knowledge Discovery step consists of, by applying Natural Languages Processing (NLP) techniques, finding the proper interpretation of some text fields, from instances of CIDOC-CRM class, such as ‘E62 String’, that contain strings with description information as their value, and therefore extract additional information. The ‘Scope and content’ is one of the ISAD(G) elements that is characterized by having additional information describing its unit, and it is in text format.

These texts, usually, have a structure that can be recognized, by using NLP tools, and giving as output a feature value list that will be the input of the migration sub-process. Enumeration is a structured pattern that is frequent in these text fields.

Consider as an illustration the fonds unit entitled “JUÍZO DA ÍNDIA E MINA”,1414 which describes the set of archival documents that compose it, regardless of its form or support, and concerning civil and criminal processes registered under Portuguese discoveries root “Índia” and “Mina”. Most of those processes are related to shipping damage, payment of soldiers, collection of freight, freight and unloading, qualification of heirs, processes of individuals who wanted to prove to be Portuguese and that their ships had made in Portuguese shipyards, with no foreigners interested in their cargo, and also about Corsair and piracy lawsuits. This fonds unit has the following piece of text withdrawn from its ‘Scope and content’ element.

From this text using some NLP tools (e.g., tagger and lemmatization) and some grammar rules, it is obtained a list of Type-Value (vessel, name) elements. The representation of this information in CIDOC-CRM is given by rule No. 19, Table 6, the Appendix.

Each pair vessel-value gives rise to a new instance of ‘E22 Human-Made Object’ connected to the ‘E31 Document’ of the fonds unit by the Object property ‘P129 is about’, the instance ‘E22 Human-Made Object’ has type value that has type ‘vessel’. Therefore, rules No. 19 to No. 21, from Table 6 (the Appendix), can be automatically generated from the text structure in ISAD(G) properties to obtain the CIDOC-CRM representation of the corresponding information.

For this example, Table 3 presents the total of axioms generated to represent the information interpreted, which increases substantially the amount of entities in the knowledge base compared to the entities generated in the migration process of the fonds unit itself. More important, it is possible to retrieve such information and infer about it, both automatically.

Another structure pattern that is often found in ‘Scope and content’ element is the identification of people and their relationship role with the ‘Recipient’ when referring to activities [20]. These activities can be baptisms, weddings or deaths, and the information is organized in a list of names and tagged by the role of the relationship that connects to the ‘Recipient’ of the unit. For instance, to illustrate this pattern, consider the Item unit entitled “REGISTO DE BAPTISMO”,1515 which refers to the baptism happening of the person named “Ana”, ‘Recipient’ of the unit, and its ‘Scope and content’ element has the following text value:

Applying to this text some NLP tools (e.g. tagger and lemmatization) and some grammar rules, it is possible to extract the names of each person and the corresponding role of the relationship that links each person to “Ana” through the baptism activity. In particular, this means that it is possible to identify “Ana”’s parents, grandparents from both sides and also her birthdate.

Unlike what happens with the birth event for which the CIDOC-CRM has the entity ‘E67 Birth’ to represent this concept, CIDOC-CRM model does not have a specific entity to represent the baptism activity. In this case, any baptism activity is established as an instance of the entity ‘E7 Activity’ and to mark the activity as a baptism, it is applied a type to the activity, i.e., ‘E7 Activity’ ‘P5 has type’ ‘E55 Type’.

To establish parenting relationship through the birth event, CIDOC-CRM model has proper properties, like ‘P96 by mother’, ‘P97 by father’ and ‘P98 brought into life’, that allow to perfectly represent the roles of being a father or a mother of someone else. To set a name to a person, the CIDOC-CRM has the class ‘E41 Appellation’ whose instances values represent names and the object property ‘P1 is identified by’ to link the name to the person. For instance, to set ‘Manuel de Oliveira’ as the name of a person, the representation expression is ‘E21 Person’ ‘P1 is identified by’ ‘E41{Manuel de Oliveira}’. The rule No. 22, in Table 6 (the Appendix), expresses the complete mapping description for a birth event, described in a baptism record unit.

The role of being a godparent is established through the baptism activity and the CIDOC-CRM model does not have a proper set of entities and properties that explicitly represent those concepts. The solution is to establish a ternary relation where the role of the relationship is expressed as the type of a property. The entity ‘PC14 Carried Out By’ represents the relationship, which has type (‘P14.1 has type’) the role of the relationship (‘E55 Type’), with domain the baptism ‘E7 Activity’ and range the godparent ‘E21 Person’. Rule 23, in Table 6 (the Appendix), captures the complete mapping description for the godparents relationship.

Figure 13 shows the complete solution for the baptism example, obtained after the application of the Mapping Description Rules identified and expresses the axioms that are added to the knowledge base.

Fig. 13.

The baptism activity of the person “Ana” partial mapping.

In the Appendix, the Mapping Description Rules, presented in Table 6, are also displayed in a diagram format for better understanding.

4.4.Evaluation of migration process

The Migration Process is composed of 3 modules (Fig. 11), as presented in previous subsections. The development state of each module is the following:

The first module refers to the information extraction from DigitArq webpages, using jsoup tool. This task is complete, which means that each ISAD(G) element presented in a webpage is extracted in the form as presented in Table 5 (the Appendix), second column. Therefore, the information extracted matches the original one.

The evaluation of this process was made at the same time as the development, where the tests were made manually by comparing the input webpage with the corresponding output. The evaluation results grants that the process has a 100% accuracy, which means that the information extraction from DigitArq is correct.

The second module consists of the migration process of the previous output information to the CIDOC-CRM representation, according to the rules presented in Table 5 (the Appendix). This task is complete, which means that all the rules are implemented and it is possible to represent all the units of description in CIDOC-CRM.

The evaluation of this process is made automatically. For each unit of description represented in DigitArq, it is possible to compare the output obtained at first module with the information recovered in CIDOC-CRM Knowledge Base. This process is made by using SPARQL-DL queries to search in the OWL Knowledge Base. For instance, to check that the unit with reference code “PT/ADPRT/PRQ/PPRT01/001/0004/00001” has as description level value ‘Item’, it is only necessary to question the knowledge base with the DL query:

The answer to this DL query, ‘Item’, is compared to the ‘Description level’ value obtained in the first module for the same unit of description, which is [‘Description level’, ‘Item’].

The evaluation process was made for all the elements of ISAD(G) presented in DigitArq web interface for a sample of fonds, and their hierarchical composition, for instance, the “Paróquia de Aldoar” with a total of 1426 units of description. The evaluation results grants that the process has a 100% accuracy, which means that the implementation is correct.

The third module consists of representing the information contained in textual elements of ISAD(G), such as ‘Scope and content’. This task has as input the instances of the Knowledge Base that are Strings, representing texts written in Portuguese, from where some information must be extracted, such as baptisms, births, incorporations of material into Fonds, transfers of materials, lists of entities, father, mother, godparents, etc.

This process is defined in 3 sub-process: text classification, extraction, and representation. All these sub-processes are ongoing and no formal evaluation has been made yet.

Regarding the representation sub-process, some of the information to extract has already been identified. For this information, a set of rules (Table 6, in the Appendix) is already defined and evaluated with a sample. This evaluation was made automatically, by using SPARQL-DL queries to search in the OWL Knowledge Base, and explained in the next Section 5. This task is not complete, since it is necessary to identify more information to be extracted and to define the rules to represent it in CIDOC-CRM.

In the text classification sub-process, it is defined a classifier for each type of information to identify the texts where that kind of information could be extracted. These classifiers are built using machine learning and natural languages processing tools. For instance, to identify the texts that contain baptism information, it was built a manually annotated sample of 200 Portuguese texts and a classifier using a N-Gram TF-IDF model for the sample data and a decision tree, allowing to obtain a high precision in the identification of the texts containing information about baptisms.

In general, the results, obtained with the classifiers, were not so good because the recall had lower values, but the precision had high values. However, these results are considered at this moment good enough to classify the text. As future work, it is intended to use other language models to improve the recall of the classifier.

About the extraction sub-process, in the classified text, the information is extracted into an established format (column 2, Table 6, in the Appendix). A pipeline of natural language processing tools was integrated in the Gate framework.1616 A set of Jape rules was also used to extract the entities and relations. This work is ongoing but some experiences were already performed, enabling the automatic extraction of some information, and can be confirmed in the dataset example [24].

4.5.Migration to other ontologies

In this subsection, a set of rules to map ISAD(G) into RIC-O, following the proposed strategy representation, is presented to show that the migration process can be easily adapted to the use of other ontologies.

Fig. 14.

Rule No. 1: Unit of description representation in RIC-O.

Fig. 15.

Rule No. 2: Description level in RIC-O.

Fig. 16.

Rule No. 3: Reference code in RIC-O.

Fig. 17.

Rule No. 4: Language of the material in RIC-O.

The migration of DigitArq into RIC-O could be achieved by writing the new mapping description rules that model the Portuguese National Archives in RIC-O. As an example, it is presented in Figs 14, 15, 16, and 17, and Table 7 in the Appendix, the corresponding rules in RIC-O for the elements ‘Unit of Description’, ‘Description level’, ‘Reference code’, ‘Language of the material’ and ‘Hierarchy’. For instance and as can be seen in Rule No. 2 (Fig. 10 in Section 3.3), the ‘Description level’ representation in CIDOC-CRM is more expressive than the one in RIC-O. CIDOC-CRM uses general concepts to describe the elements and it is possible to assign specific types to those elements. In RIC-O model, classes and properties are more specific and related to the ISAD(G) elements, such as ‘rico:RecordSetType’ or ‘rico:hasRecordSetType’, and there is no property that allows to apply a type (category) to a ‘rico:RecordSetType’.

The representation of the unit of description in RIC-O (see Fig. 14) is set with an instance of the class ‘rico:RecordSet’ and linked with a new instance of the class ‘rico:Instantiation’ through the property ‘rico:hasInstantiation’.

Similar to Rule No. 2 in Fig. 15, to represent ‘Reference code’, RIC-O model uses specific classes and properties to represent identifiers of a unit of description, such as ‘rico:Identifier’ and ‘rico:hasOrHadIdentifier’, and there is no property that allows to apply a type (category) to a ‘rico:Identifier’, see Fig. 16.

For the case of the element ‘Language of the material’, the representation in RIC-O has the same expressiveness as CIDOC-CRM, see Fig. 17 and Fig. 22(a) in the Appendix.

To conclude, the hierarchical structure of the unit of description collection is modeled the same way as in CIDOC-CRM, see Fig. 18. Table 7, in the Appendix, shows CIDOC-CRM and RIC-O Mapping Description Rules, based on the figures previous mentioned, that are used for the automatic migration.

Fig. 18.

Rule No. 17: Hierarchy in RIC-O.

5.1.Querying the knowledge base

The process of retrieving the information about the archival units uses the Mapping Description rules, presented in Table 5 and Table 6, in the Appendix, to define the Description Logic (DL) queries on the subject of a question.

The examples, presented in Table 4, illustrate queries to obtain some of the elements of an unit,1717 such as Reference code, Description level, Title, Title Type, Creator (Producer), Date Range.

To help the evaluation of the CIDOC-CRM representation of the migrated data, a web interface was developed, see Section 5.2 for further information. The queries Q8 and Q9, presented in Table 4, are examples of smart queries enabled by the interface application and that allow to explore the advantages of the archives OWL representation. For instance, with question Q9, the following examples of answers are obtained when questioning the knowledge base about the type of a given name:

Note that Protegé does not allow to query for a property of an instance, but it is possible to do it with SPARQL-DL as in Listing 4. This query retrieves all the instances of ‘E31 Document’ where its ‘Description level’ is ‘Fonds’ (Mapping Description Rule No. 2, Table 5, in the Appendix).

Listing 4.

“Units with ‘Description level’ ‘Fonds’”.

These ‘smart’ queries are useful in the interface application, not only for helping the users to explore the knowledge base, but also to use in the interpretation of natural language text and assign ontology terms to sentences tokens.

Another kind of query that is important for the natural language interpretation process is to obtain object properties that link instances from a class domain and instances from a class range. The query presented in Listing 5 is an example of an SPARQL-DL query to obtain the object properties that link instances of ‘E31 Document’ to a ‘Reference code’. This query can not be done in Protegé.

Listing 5.

“Properties that link an ‘E31 Document’ to a ‘Reference code’”.

5.2.Query ontology interface

The knowledge base querying process is supported by an application program interface (API), entitled Query Ontology Interface, that facilitates the interaction between project team developers and the knowledge base. The main goals for the development of such API are to allow retrieving information from knowledge base without technically know how the information is represented in the ontology, as well as to express queries as near as possible to natural language text. The interface main target users, the EPISA project members that work in DGLAB, are in general not able to make queries using SPARQL language, or even using description logic languages.

The Query Ontology Interface has an important role in the process of manual evaluation during the development of the migration process, enabling the visualization of the extracted information, and helps in identifying the correctness of the information extracted and how it is related with the other ontology information.

The Query Ontology Interface was developed using Spring Boot,1919 a Java-based framework that allows to create a Graphical User Interface (GUI) and export the final API in a stand-alone application (originally a web-application). The SPARQL-DL Java query engine is used to search the knowledge base, and serves as a middle layer application between the GUI and the knowledge base. The question made by the user at the GUI level is translated to the corresponding CIDOC-CRM representation and the answer is retrieved using the SPARQL-DL engine and then presented at the GUI application level. The approach used to query the knowledge base is as much user-friendly as possible, besides the use of a GUI, it also uses Natural Language understanding mechanisms to help the users in the querying process. Other existing interfaces over CIDOC-CRM Ontology use similar approach, such as OpenArcheo [17].

The Query Ontology Interface is able to retrieve information about single individuals and about the structure of the whole knowledge base. For instance, it is possible to retrieve information based on the value of some key-entities, like ‘E41 Appellation’ or ‘E42 Identifier’, that are expressed in Natural Language and stored as xsd:string.

A user expression can be interpreted as a class or as a class constrained by a property. As an example, consider a search using the expression “Ana”, the result is a DL-query where a person is constrained to be identified by an appellation with value “Ana”. This NL interpretation tool is still in development.

It is also possible to define a constraint (or a joint of constraints) to retrieve the desired individuals. The result of such query is an individual (or a joint of individuals) with all the properties and other individuals linked to it. In addition, it was defined a set of predefined queries that work like filters, such as displaying all the class entities or all the individuals belonging to a class entity. An example on how it works is shown in Fig. 19, where the search is made using the ‘Reference code’ value, see Fig. 19(a), and the result is the information of the corresponding unit elements, see Fig. 19(b).

Fig. 19.

Query ontology interface example.