The SeaLiT Ontology – An Extension of CIDOC-CRM for the Modeling and Integration of Maritime History Information

The ontology has been developed in the context of the SeaLiT project,³ a European project in the field of maritime history (ERC Starting Grant, No 714437). The project studies the transition from sail to steam navigation and its effects on seafaring populations in the Mediterranean and the Black Sea between the 1850s and the 1920s. Historians in SeaLiT investigate the maritime labour market, the evolving relations among ship-owners, captain, crew, and local societies, and the development of new business strategies, trade routes, and navigation patterns, during the transitional period from sail to steam. The main concepts on which the scientific research focuses, are the ships (including various information such as type, usage, dimensions, technology), the people related to the ships (sailors, ship owners, students, relatives) and the historical events/activities related to these (such as voyages, recruitments, payments).

The archival sources considered and studied in SeaLiT range from hand written ship log books, crew lists, payrolls and employment records, to registers of different types such as civil, sailors, students, and naval ship registers. These archival sources have been gathered from different authorities in countries of the Mediterranean and the Black Sea, and are written in different languages, including Spanish, Italian, French, Russian, and Greek. The full archival corpus studied in SeaLiT is described in the project’s web site.⁴

The SeaLiT Ontology uses and extends the CIDOC-CRM (Conceptual Reference Model),⁵ in particular its stable version 7.1.1, which means that each class of the SeaLiT Ontology is a direct subclass or a descendant of a CIDOC-CRM class.

CIDOC-CRM is a high-level, event-centric ontology of human activity, things and events happening in spacetime, providing definitions and a formal structure for describing the implicit and explicit concepts and relationships used in cultural heritage documentation [3]. It is the international standard (ISO 21127:2014)⁶ for the controlled exchange of cultural heritage information, intended to be used as a common language for domain experts and implementers to formulate requirements for information systems, providing a way to integrate cultural heritage information of different sources.

The considered stable release of CIDOC-CRM (version 7.1.1) consists of 81 classes and 160 unique properties. The highest-level distinction in CIDOC-CRM is represented by the top-level concepts of E77 Persistent Item (equivalent to the philosophical notion of endurant), E2 Temporal Entity (equivalent to the philosophical notion of perdurant) and, further, the concept of E92 Spacetime Volume which describes the entities whose substance has or is an identifiable, confined geometrical extent in the material world that may vary over time. Figure 1 depicts how the high level classes of CIDOC-CRM are connected.

Over the last years, methods and technologies of the Semantic Web have started playing a significant and ever increasing role in historical research. The survey in [13] reviews the state of the art in the application of semantic technologies to historical research, in particular works related to (i) knowledge modeling (ontologies, data linking), (ii) text processing and mining, (iii) search and retrieval, and (iv) semantic interoperability (data integration, classification systems).

As regards ontologies for the modeling of maritime history information, the most relevant work is an ongoing project on the ontology management environment OntoME [1] that aims to provide a data model for the field of maritime/nautical history.⁷ The project is a cooperation between the Huygens Institute for the History of the Netherlands, LARHRA and the Data for History consortium. The current (draft) model consists of 13 classes and 12 properties, while it makes use of CIDOC-CRM as well as extensions of CIDOC-CRM. The ontology is unfinished and not for use yet (as of December 15, 2022).

Conflict ⁸ is an ontology developed in the context of the SAILS project (2010–2013)⁹ that models concepts useful for describing the First World War. The provided ontology version (0.1) is actually a taxonomy consisting of 175 classes, some of which allow modeling information related to maritime history, like the classes Ship, Ship_journey, Ship_type, and Ownership. Similarly, there are ontologies that could be used for modeling other parts of the model, such as GoodRelations [8], a lightweight ontology for exchanging e-commerce information, for the part that concerns payments for products.

We selected to use CIDOC-CRM because it is the standard ontology for cultural heritage documentation, extensively used in the fields of cultural heritage, history, and archaeology. It is directly related to the domain of discourse of history, as a discipline that studies the life of humans and societies in the past. This scope, studied from the point of view of maritime historical research, can be represented by the abstraction of reality offered by CIDOC-CRM. As an example, we can directly take advantage of the (direct or inherited) properties of the CIDOC-CRM class E7 Activity, such as ‘P14 carried out by’, ‘P4 has time-span’, ‘P7 took place at’, and the like, and use them for describing instances of classes of the SeaLiT Ontology that are subclasses of E7 Activity (e.g., Voyage, Arrival, Recruitment, etc.). Therefore, using CIDOC-CRM facilitates data integration with relevant (existing or future) datasets that also make use of CIDOC-CRM, but also it enables data sustainability because CIDOC-CRM is a living standard and has a very active community that constantly works on it and improves it.

Finally, there is a plethora of ontologies which have been developed as extensions of CIDOC-CRM, e.g., CRMas [14] for documenting archaeological science, CRMgeo [9] for geospatial information, CRMdig [18] for provenance of digital objects, IAM [4] for factual argumentation, and others.

The ontology has been created gradually, following a bottom-up strategy [6], working with real empirical data and information needs, in particular digitised historical records (transcripts) and corresponding data structures in various forms, as well as research questions provided by a large group of historians. The archival material together with the research questions define the modeling requirements.

The main characteristics of our strategy are summarised as follows:

In more detail, our approach focused on studying and analysing the historical sources from the historians’ perspective, following their respective research questions and practices of documentation. In order to achieve that, we had to consult all the data providers (coming from different research teams and countries) for a long period and to do extensive research on their research practices and the historical data for the development and the validation of the model. As a result, the model was designed from actual data values, from existing (and used) structured information sources (such as spreadsheets) and historical records (transcripts) that include the original information. The model’s concepts were refined several times during the span of the project for considering new information coming from new kinds of sources. Table 2 provides the considered archival sources as well as an overview of the recorded information and an example record (transcript) for each source.¹⁰

As regards the research questions and information needs provided by the historians, their majority concerns aggregated information, such as number of sailors per origin location that arrived at a specific port, average tonnage of ships, wage level per country, percentages of immigration in relation to the sailors’ profession, and so on. Other information needs concern the retrieval of a specific list of entities (e.g., ship construction places during a specific time period), comparative information (e.g., time of sailors’ service in relation to the time on land, number of women/men in ships, etc.), or the retrieval of a specific value (e.g., total number of officers employed by the company in a specific year or span of years).¹¹

For creating the ontology, we followed a custom engineering methodology [11] which, though, maintains most of the features supported by existing methodologies, such as HCOME [10] and DILIGENT [17]. In particular:

The basis for the model was CIDOC-CRM since it is a standard suitable for recording historical information relating who, when, where, and what. From an ontological point of view, we followed the below steps:

The ontology was built following these principles. Its design and development was an iterative process with several repetitions of the steps described above.

The ontology currently (version 1.1) contains 46 classes, 79 properties and four properties of properties, allowing the description of information about ships, ship voyages, seafaring people, employments and payments, teaching activities, as well as a plethora of other related activities and characteristics. Appendices A and B provide the full class and property hierarchy, respectively.

Figure 2 shows how information about a ship is modelled.¹² A Ship (subclass of E22 Human-Made Object) is the result of a Ship Construction activity (subclass of E12 Production) which gave the Ship Name (subclass of E41 Appellation) to the ship. A ship also has some characteristics, like Horsepower and Tonnage (subclasses of E54 Dimension; this allows providing, apart from the value, the corresponding measurement unit, a note, etc.), and is registered through a Ship Registration (subclass of E7 Activity) by a Port of Registry (subclass of E74 Group), with a ship flag of a particular Country (subclass of E53 Place) and with a particular Ship ID (subclass of E42 Identifier). Modeling the ship ID as a class allows including additional information about the identifier, such as which authority provided the identifier, when, and so on (by connecting it to the CIDOC-CRM class E15 Identifier Assignment). Finally, a ship has one or more Ship Ownership Phases (subclass of Legal Object Relationship), each one initialized by a Ship Registration and terminated by a De-flagging activity. Note here that, all classes related to activities (like Ship Construction, Ship Repair, De-flagging, etc.) can make use of the CIDOC-CRM property ‘P4 has time-span’ for providing temporal information.

Figure 3 shows how information about a ship voyage is modelled in the ontology. First, a Voyage (subclass of E7 Activity) concerns a particular Ship, navigated by one or more captains (E39 Actor), and has a starting from place, a destination place, and a finally arriving at place (E53 Place). Then, the main activities during a ship voyage include Loading things, Leaving from a place, Passing by or through a place, Arrival at a place, and Unloading things. All these activities are linked to a E52 Time-Span through the CIDOC-CRM property ‘P4 has time-span’.

Figure 4 shows how the ontology allows describing information about employments and payments. Money for Service (subclass of E7 Activity) is given to an E39 Actor for a particular Service (subclass of E7 Activity).¹³ The class Money for Service has two specialisations (subclasses): Money for Things and Money for Labour, while the class Employment is a specialisation of the class Service. A Crew Payment concerns a particular Voyage and is a specialisation of Money for Labour. In this context, a Labour Contract (subclass of E29 Design or Procedure) specifies the conditions of Money for Labour. An Employment starts with a Recruitment (subclass of E7 Activity) and ends with a Discharge (subclass of E7 Activity).

Figure 5 shows how information about persons (seagoing people, such as captains, crew members, students, etc.) is modelled in the ontology. A person (E21 Person) is registered through a Civil Registration activity and receives an identifier (E42 Identifier). A person has a first name and last name (E62 String), works at an organisation or company (E74 Group), has an age (E60 Number) at a specific time (the time of the information recording), as well as a set of other properties, in particular a Religion Status, a Literacy Status, a Sex Status, a Language Capacity, a Social Status, and a Profession (all subclasses of E55 Type). The use of E55 Type as superclass of these properties/qualities (instead of modeling them as temporal entities) is a good solution when the sources (such as a civil register or a census document) do not provide enough temporal information to infer/observe the corresponding event (this is exactly the case with the archival sources of the SeaLiT project). In addition, a Punishment (subclass of E7 Activity) or Promotion (subclass of E13 Attribute Assignment) can be given to a person. A Promotion is related either to a Social Status promotion or to a job/career (Profession) promotion.

Finally, Figure 6 shows how the ontology allows describing information about teaching activities related to seafaring. A Teaching Unit is an activity that can be specialised to Course or Section. It is connected to a Subject (subclass of E55 Type), the students (E39 Actor) who participated in the teaching unit, the number of participating students (E60 Number), as well as one or more other teaching units through the CIDOC-CRM property ‘P9 consists of’. The latter allows, in particular, describing the information that a course consists of sections.

The ontology development process lasted more than two years, including a large number of intermediate versions, before releasing the first stable version (1.0). In particular, the ontology elements (classes and properties) were revised several times based on (a) new evidence coming from newly-considered archival sources, and (b) new requirements (information needs) by the domain experts (maritime historians). Such new evidence and requirements required either the definition of new elements, such as the creation of a new class or property, or the revision of an existing set of elements that concern a part of the model.

Figure 7 shows how the part of the ontology that concerns ship ownership was revised several times during the ontology development process.

A first requirement provided by the historians was the ability to find all ships per owner. The analysed archival material (crew lists) only provided the name of the owner, where the value was either the name of a person or the name of a company. Based on this evidence, the property ‘has owner’ was created connecting an instance of Ship with the an instance of the CIDOC-CRM class E39 Actor (v1 in Figure 7).

Another source (naval ship register lists) provided information about ships’ previous owners, while a new requirement was the ability to find the number of first owners per ship during a period of time. Based on this, as well as on the fact that the binary relationship has owner implies/hides a temporal entity, we defined the class Ship Ownership Phase, the property ‘has phase’ for connecting a ship to a ship ownership phase, the property ‘in time’ for connecting the ownership phase to a E52 Time-Span, while the property ‘has owner’ was revised for connecting the ship ownership phase with an E39 Actor (v2 in Figure 7).

A ship can have many names during its lifespan, while an owner can own more than one ship with the same name (as shown in logbooks and crew and displacement lists). According to the historians, ownership usually assigns a name to a ship and a ship changes its name under a new ownership state at a specific time. Based on this historical knowledge, the property ‘ownership under name’ was created for enabling to link the ship ownership phase to a Ship Name (v3 in Figure 7).

Evidence shows that ownership of a ship is a type of information that can be inferred and not directly observed. An ownership phase can be traced by the ship registration activity that initiates it and by the de-flagging activity that terminates it. The documentation of a ship registration in Austrian Lloyd’s fleet lists, in particular, includes information about the ship’s construction place and date, which together with the name given to ship after construction constitute safe criteria to identify a ship. Based on this, the classes Ship Registration (subclass of E72 Activity), De-flagging (subclass of E72 Activity) and Ship Construction (subclass of E12 Production) were defined, together with the properties ‘registers’ (for linking a registration activity to a ship), ‘ownership is initialized by’ (for linking an ownership phase to a registration activity), ‘de-flagging of’ (for linking a de-flagging activity to a ship), ‘ownership is terminated by’ (for linking an ownership phase to a de-flagging activity), ‘constructed’ (for linking a construction activity to a ship), and ‘under name’ (for linking a construction activity to a ship name (v4 in Figure 7).

The ownership of a ship is actually a legal agreement in which an owner holds shares. For example, according to Italian sources (maritime registers), the ownership of a ship was structured in 24 parts (“carati”). Sometimes only one ship owner possessed all 24 parts. However, much more frequently the 24 parts were distributed among several ship owners. Based on this evidence, a new class Shareholding was created as a specialisation (subclass) of Ship Ownership Phase, together with the property ‘of share’ for assigning the number of shares to a shareholding phase (v5 in Figure 7).

In the last ontology version (see Figure 2), Ship Ownership Phase is defined as specialisation (subclass) of the class Legal Object Relationship, together with the class Legal Document with Temporal Validity which comprises official documents or legal agreements that are valid for a specific time-span. The more general class Legal Object Relationship represents kinds of relationships whose state and time-span are not documented and thus cannot be directly observed. We can only observe the relationship through the events that initialise or terminate the state (starting and terminating events).

The specification of the ontology and its RDFS implementation are available through the Zenodo repository (DOI: 10.5281/zenodo.6797750),¹⁴ under a Creative Commons Attribution 4.0 license. The (resolvable) namespace of the ontology pointing to the RDFS implementation is: http://www.sealitproject.eu/ontology/.

The specification document defines the ontology classes and properties. For each class, it provides: (i) its superclasses, (ii) its subclasses (if any), (iii) a scope note (a textual description of the class’s intension), (iv) one or more examples of instances of this class, and (v) its properties (if any), each one represented by its name and the range class that it links to. For each property, the specification provides: (i) its domain, (ii) its range, (iii) its superproperties (if any), (iv) its subproperties (if any), (v) a scope note, (vi) one or more examples of instances of this property, and (vii) its properties (if any). If a property has an inverse property, this is provided in parentheses next to the property name. Scope notes are not formal modelling constructs, but are provided to help explain the intended meaning and application of a class or property. They refer to a conceptualisation common to domain experts (maritime historians) and disambiguate between different possible interpretations.

The RDFS implementation provides the scope note of each class or property using ‘rdfs:comment’. For producing the class and property URIs, the space character in the name of a class or property is replaced by the underscore character. Inverse properties are provided using ‘owl:inverseOf’. The version of the ontology is provided through the property ‘owl:versionInfo’ and its license through the Dublin Core term ‘dc:license’. For the properties pointing to classes that are represented as literals in RDF (seven properties in total, pointing to the CIDOC-CRM classes E60 Number or E62 String), we define their range as rdfs:Literal.

We also provide an OWL implementation of the ontology, containing 71 object properties, seven datatype properties, and one symmetric property (the property ‘related to’).¹⁵

Since RDF does not provide a direct way to express properties of properties, we make use of property classes (as suggested and implemented by CIDOC-CRM), as a reification method for encoding the four properties of properties defined in the SeaLiT Ontology. Using this method, a class is created for each property having a property. This property class can then be instantiated and used together with the properties ‘P01 has domain’ and ‘P02 has range’ provided by the RDFS implementation of CIDOC-CRM.¹⁶ For example, Figure 8 depicts how the property ‘in the role of’ of the property ‘works at’ is implemented using the idea of property classes. First, the property class PC works at is provided for representing the property ‘works at’. During data generation/instantiation, an instance of this property class is created pointing to the domain (an instance of E21 Person) and the range (an instance of E74 Group) of the original property ‘works at’ using the properties ‘P01 has domain’ and ‘P01 has range’, respectively. Then, we can provide the property of property ‘in the role of’ by directly linking it to the property class instance.

The SeaLiT Ontology has been used in the context of the SeaLiT project (cf. Section 2.1) for transforming the data transcribed from a set of disparate, localised information sources of maritime history to a rich and coherent semantic network of integrated data (a knowledge graph). The objective of this transformation is the ability to run complex questions over the integrated data, like those provided by the historians that require combining information from more than one sources.

In particular, the original archival documents are collaboratively transcribed and documented by historians in tabular form (similar to spreadsheets) using the FAST CAT system [5]. In FAST CAT, data from different sources are transcribed as records belonging to specific templates. A record organises the data and metadata of an archival document in a set of tables, while a template represents the structure of a single data source, i.e., it defines the data entry tables. Currently, more than 600 records have been already created and filled in FAST CAT by historians of SeaLiT. An example of a record for each different type of source (template) is provided in Table 2.

For transforming the transcribed data to RDF based on the SeaLiT Ontology, schema mappings are created for each distinct FAST CAT template. These mappings define how the data elements of the FAST CAT records (e.g., the columns of a table) are mapped to ontology classes and properties. To create the schema mappings and run the transformations, we make use of the X3ML mapping definition language and framework [12]. The transformed data (RDF triples) are then ingested into a semantic repository (RDF triplestore) which can be accessed by external applications and services using the SPARQL language and protocol. The ResearchSpace application (described below) operates over such a repository for supporting historians in searching and analysing quantitatively the integrated data. The reader can refer to [5] for more information about the FAST CAT system and the data transcription, curation, and transformation processes.

The generated knowledge graphs are available through the Zenodo repository (DOI: 10.5281/zenodo.6460841),¹⁷ under a Creative Commons Attribution 4.0 license. This dataset currently consists of more than 18.5M triples, providing integrated information for about 3,170 ships, 92,240 persons, 935 legal bodies, and 5,530 locations. These numbers might change in a future version since data curation, including instance matching, is still undergoing and new archival documents are transcribed in FAST CAT.

For supporting historians in exploring the SeaLiT Knowledge Graphs (and thus the integrated data), we make use of ResearchSpace [15], an open source platform that offers a variety of functionalities, including a query building interface that supports users in gradually building complex queries through an intuitive (user friendly) interface. The results can then be browsed, filtered, or analysed quantitatively through different visualisations, such as bar charts. The application is accessible at: http://rs.sealitproject.eu/.

The query building interface of ResearchSpace has been configured for the case of the SeaLiT Knowledge Graphs. In particular, the following searching categories have been defined: Ship, Person, Legal Body, Crew Payment, Place, Voyage, Course, Record, Source. By selecting a category (e.g., Ship) the user is shown a list with its connected categories. By selecting a connected category (e.g., Place) the user can then select a property connecting them (e.g., arrived at) as well as an instance/value (e.g., Marseille; thus the user is searching for ships that arrived at Marseille). Such a property actually corresponds to a path in the knowledge graph that connects instances of the selected categories.

Figure 9 shows a screen dump of the system. In this example, the user has searched for persons that were crew members at ships that arrived at Marseille,¹⁸ and has selected to group the persons by their residence location and visualise the result in a bar chart. From the bar chart we see that the majority of persons had Camogli as their residence location. This query corresponds to a real information need provided by the historians of SeaLiT.

For retrieving the results and creating the chart, ResearchSpace internally translates the user interactions to SPARQL queries that are executed over the SeaLiT Knowledge Graphs. For instance, the below SPARQL query retrieves the persons that were crew members at ships that had Marseille as their final destination:

For grouping the persons by their residence location and showing a chart, the below SPARQL is executed for retrieving the relevant data:

Such queries can also utilise the RDFS inference rules, e.g., those based on the subClassOf and subPropertyOf relations. An example is the use of the CIDOC CRM property ‘P9 consists of’ for getting all voyage-related activities of a particular ship (leaving by a place, arrival at a place, passing by or through a place, loading things, unloading things), as shown in the below SPARQL query:

In this case, we exploit the fact that the property ‘P9 consists of’ is super-property of the properties ‘consists of leaving’, ‘consists of arrival’, ‘consists of passing’, ‘consists of loading’, and ‘consists of unloading’.

The type of historians’ research questions / information needs that can be answered (either directly or indirectly) using the ResearchSpace platform over the integrated data mainly depends on the actual archival material that is transcribed and transformed to RDF based on the SeaLiT Ontology, and less on the ontology itself. Specifically, the ontology was designed considering community requirements and material evidence, therefore if the data needed to answer an information need (or to find important information related to the information need) exists in the transcripts (and thus in the transformed data) then the question can be answered either fully, or partially through the retrieval of important relevant information. For example, in the case of SeaLiT, there are transcripts (FAST CAT records) containing tables that are not fully filled, either because some archival documents do not provide the corresponding information, or just because historians did not fill the columns during data transcription (planning to do it at a later stage). In this case, information needs that require this missing information cannot be satisfied. In the future, if new types of information (and corresponding information needs) appear that cannot be modelled by the ontology, the ontology will be extended/revised and a new version will be released.

With respect to incomplete information, missing entity attributes (e.g., unknown construction location for a particular ship) are in general very common in historical-archival research, but at the same time an important-to-know information for historians because they can affect the interpretation of quantitative analysis results. Our configuration of ResearchSpace considers missing information by representing it as an ‘unknown’ value, e.g., by showing an ‘unknown’ column in a bar chart.