EUCISE-OWL: An ontology-based representation of the Common Information Sharing Environment (CISE) for the maritime domain

1. Introduction

During maritime crises, human lives are constantly at stake, while the time to react to unforeseen events is extremely limited. Therefore, cooperation across sectors, and often across borders, is valuable in order to ensure the safety and efficiency of operations. Relevant studies indicate that authorities are indeed starting to realize the importance of cross-sector and cross-border information sharing [29].

Nevertheless, on a practical level, this cooperation is compromised by the vast diversity of systems that operate simultaneously but are not yet adequately interconnected. On top of that, one should also add the vast volumes of heterogeneous data generated during maritime operations, including sensor measurements, intelligence, and reporting, amongst others.

In order to address the above challenges, the EU launched in 2005 several initiatives for improving the interoperability between national authorities’ systems. These efforts included published communications, roadmaps, and green and blue papers, and eventually resulted in EU’s Integrated Maritime Policy (IMP) [6]. In parallel, there have been several EU-funded projects aimed at fostering information exchange across sectors and borders [28], with the participation of many EU maritime monitoring authorities.

A key outcome from these EU-wide efforts is the Common Information Sharing Environment (CISE), representing an open, collaborative process within the EU for promoting automatic information sharing between authorities involved in maritime monitoring, across sectors and borders [7]. In order to support the authorities’ continuously increasing needs, in conjunction with the constant decrease of operational personnel (operators), CISE aims to (a) increase the efficiency, quality, and responsiveness of surveillance and operations at sea, and, (b) ensure a safer, more secure, and environmentally protected EU maritime domain. The benefits of deploying a uniform model like CISE for maritime monitoring include: (a) minimizing the risk of human errors; (b) establishing a standard detection threshold, which can be dynamically adapted each time according to the needs and the occurring incidents; (c) expanding the human cognitive area; (d) reducing the need for highly experienced and specialized personnel; (e) reducing the adaptation and familiarization time for the users (operational personnel) with a minimal impact in their performance.

An important milestone in the roadmap for implementing CISE is represented by the EUCISE2020 project [5], which ran from 2014 to 2018 and promised to deliver an operational solution built on a common service-based architecture and open information exchange. In order to facilitate the adoption of CISE by third parties, EUCISE2020 openly published its CISE-based data model as an XML Schema specification accompanied by UML diagrams [4].

However, the adoption of CISE is compromised by the very serialization of the data model as an XML Schema. The latter does promote information sharing and exchange to an extent, but largely fails to deliver the fundamental additional benefits provided by ontologies, most prominently including a syntactically and semantically richer representation, enhanced semantic interoperability and semantic reasoning capabilities [14]. In order to capitalize on the critical benefits provided by ontologies, this paper presents a serialization of the EUCISE2020 data model as an ontology that will substantially encourage the extensive adoption of CISE. The proposed ontology is called EUCISE-OWL and aims to serve as a common representation framework for putting CISE in practical use. To the best of our knowledge, EUCISE-OWL is the first ontology attempting to fully implement the EU-wide approach represented by CISE. EUCISE-OWL is an outcome from the ROBORDER EU-funded project [21], after close collaboration with our end users who have extensive experience in deploying CISE in practice [15].

The paper is structured as follows. Section 2 presents the EUCISE2020 data model, while Section 3 describes our adopted process for converting the EUCISE2020 UML diagrams into an ontology. In Section 4, we present our EUCISE-OWL ontology, followed by an example in Section 5 for handling information exchange during a maritime crisis to demonstrate the use of the proposed ontology in practice. Section 6 assesses the EUCISE-OWL ontology, while Section 7 presents relevant approaches and models with similar scope. Finally, Section 8 concludes the paper with a discussion and key directions for future work.

2. The EUCISE2020 data model

The EUCISE2020 data model is based on the CISE Data Model v1.0 [1], which was defined in FP7 project CoopP (Cooperation Project Maritime Surveillance). CISE’s key ambition is to serve as a common European format for sharing information across countries and sectors. Towards this direction, and in order to facilitate the adaptation of existing maritime monitoring systems in Europe, the CISE data model considers the corresponding data standards and identifies the most useful aspects for maritime monitoring authorities, as they were identified and validated by experts who participated in the CoopP project and represented all relevant sectors at EU and national level. CISE’s main design principles included sector neutrality, flexibility, extensibility, simplicity and understandability.

In a nutshell, the CISE data model identifies seven core data entities (Agent, Object, Location, Document, Event, Risk and Period) and eleven auxiliary ones (Vessel, Cargo, Operational Asset, Person, Organization, Movement, Incident, Anomaly, Action, Unique Identifier and Metadata). Figure 1 illustrates the core concepts of the CISE v1.0 data model.

Without extending the scope of the CISE data model, EUCISE2020 maintains the original concepts, but also defines some additional attributes, in order to consider additional data sources and to ensure that EUCISE2020 services can be implemented in practice. As already mentioned in the introduction, the EUCISE2020 data model is available as an XML Schema specification and as a set of UML diagrams.

OPEN IN VIEWER

Fig. 1.

CISE v1.0 core concepts [1].

The Unified Modelling Language (UML) [22] and the Web Ontology Language (OWL 2) [32] are both established conceptual modelling languages that present significant similarities, despite being created on the basis of different contexts. A comparative overview of UML and OWL is presented in [11,35]. Both language definitions are referred to comparable meta-models that follow the object-property modelling pattern. However, in contrast to UML, OWL 2 is fully built upon formal logic, which enables the application of logical reasoning in ontologies, a characteristic that can be used to discover inconsistencies in conceptual models and new knowledge that lies behind the asserted concepts and relations.

Many approaches already address the problem of reusing knowledge from existing UML class diagrams to develop ontologies, in automated or semi-automated procedures [11,18,34]. Regardless the degree of automation or the adopted technologies (XML, XSLT, translation algorithms, etc.), a precise conceptual correspondence between UML and OWL elements is defined, through a semantics-preserving schema translation [18,34]. The model-conversion from UML to OWL follows simple conversion rules, the most common of which are presented in Table 1.

These mappings formed the groundwork in creating EUCISE-OWL, an ontology-based model of the domain of discourse that is fully compliant to the available well-established UML definitions presented in the EUCISE2020 data model [4]. The rules applied to convert the EUCISE2020 notions to OWL triples are presented in Turtle format [33] below, accompanied by indicative examples based on the eucise:Agent core class (see UML excerpt in Fig. 2).

OPEN IN VIEWER

Fig. 2.

A UML excerpt representing the core class Agent in the EUCISE data model.

Classes Any core entity or class described in the EUCISE2020 data model is defined in EUCISE-OWL as an owl:Class, which is a subclass of eucise:Entity (subclass of owl:Thing). Below is the definition of class eucise:Agent.

Attributes In the EUCISE2020 data model, classes are related to other data types (either classes or literal values) through the declaration of relevant attributes. In EUCISE-OWL, object and data properties are naturally responsible for this representation. Two respective examples are illustrated below.

Association classes and association roles In the EUCISE2020 data model, an association class is a specific type of class that defines the connection between the core entities of the model, using specific attributes called “association roles”. Association classes also have additional properties and datatypes of their own. Thus, we represent association classes in EUCISE-OWL as notions of type owl:Class (and not simply as object properties), whereas association roles define their related object properties. All association classes of the EUCISE2020 data model are grouped together under a top-level class named eucise:AssociationClass (subclass of owl:Thing). Below is an example of eucise:AgentRisk, as illustrated in Fig. 2.

Enumerations and enumeration types Enumerations in the EUCISE2020 data model define the possible types of specific entities. In EUCISE-OWL, enumerations are represented as classes (rdf:type owl:Class) that additionally have a predefined list of asserted instances. All enumerations of the EUCISE2020 data model are grouped together under a top-level class named eucise:EnumerationType (subclass of owl:Thing). Below is the definition of eucise:AgentRoleInRiskType, which represents the role of an agent in relation to a risk; allowed values are: cause, involved, reports, other, non-specified.

Metadata The EUCISE2020 data model contains metadata descriptions in each defined component, in order to enrich their comprehensibility and facilitate their reuse. Those data were completely integrated into the ontological model through the adoption of well-known object, datatype and annotation properties (e.g. rdfs:comment, skos:example, rdfs:seeAlso and rdfs:label). Indicative initialisations are presented in triples below.

The EUCISE-OWL ontology has been implemented in OWL 2, in accordance to the NeOn methodology Scenario 2: ”Reusing and re-engineering non-ontological resources” [26], where the EUCISE2020 data model and UML diagrams played the role of the resources for the ontology we developed. The main purpose of EUCISE-OWL is to specify a common information sharing environment, based on a widely accepted format, in order to enhance the usability and adaptability of the EUCISE2020 data model. Such an ontology-based representation can easily be integrated in an information or decision support system for supporting knowledge representation, event triggering, action inference, and information dissemination to the authorities. In a nutshell, the proposed ontology enumerates a total number of 153 classes, 127 object properties and 135 data properties. The key ontology metrics are summarised in Table 2.

In compliance with the original model, there are 8 core elements defined in the ontology under class Entity: classes Agent, Document, Event, Location, MeteoOceanographicCondition, Object, OperationalAsset and Risk. Additional concepts are represented as subclasses of owl:Thing, as seen in Fig. 3. Moreover, we introduced two additional concepts: (i) the AssociationClass for representing classes that interconnect core classes, and (ii) the EnumerationType for representing sets of enumerated values that define different types of entities in specific concepts. In the EUCISE-OWL ontology, there are 10 association classes and 869 enumerated values (see individual count in Table 2).

OPEN IN VIEWER

Fig. 3.

Hierarchy of the EUCISE-OWL ontology’s main notions.

In order to facilitate the semantic interoperability between EUCISE-OWL and existing data models, we performed an ontology alignment, which is the process of defining a set of correspondences between two or more ontologies. In general, the relation that holds between the matching entities may simply follow specific ontology language definitions (equivalence, disjointness, hierarchy) or even assert SPARQL queries, fuzzy relations and similarity measures [8]. An extensive survey of matching techniques is presented in [19]. Here, we focus only on hierarchy definitions via rdfs:subClassOf and rdfs:subPropertyOf; by linking concepts this way, we inherit all involved semantics declared in the adopted ontologies and we extend their definitions with respect to the context of our domain. Details of the aligned EUCISE-OWL entities with those from third-party ontologies are summarized in Table 3.

To illustrate the efficiency and completeness of the implemented ontology, we present an operational scenario, inspired from [9] (Use Case 25b: Investigation of antipollution situation (law enforcement)). More specifically, the example presented here concerns a sea pollution incident reported when an oil spill was detected by a drone in its monitoring area. The main instances populated in the ontology as well as their interrelations are visualised in Fig. 4, using the Graffoo ontology visualization framework [10]. The circles indicate instances (real data), while their captions are written in the form of “instance_XYZ::Class_ABC”, declaring the name and the type (class) of each instance correspondingly. All classes and relations mentioned in the diagram or the text below, belong to the EUCISE-OWL ontology, otherwise they are explicitly defined with their relevant prefixes.

As seen in Fig. 4, a drone (drone_1) is represented in the ontology as an OperationalAsset (rdfs:subClassOf Object), which is associated with an instance of detection event (detection_1 rdf:type Action and Action rdfs:subClassOf Event) via the ObjectEvent association class. Details of the detection event are included in document_1 (rdf:type Attached Document and AttachedDocument rdfs:subClassOf Document). The event concerns an oil spill (oilspill_1), spotted in an area (location_1) under observation. The oil spill is represented in the ontology as an instance of class PollutionIncident (rdfs:subClassOf Event). Both events (detection_1 and oilspill_1) are associated with each other through an instance of the association class EventEvent. Details of the pollution incident (e.g. the analysis dataset) may be potentially described through asserted values in document_2 (rdf:type EventDocument and EventDocument rdfs:subClassOf Document). The occurred pollution incident may imply direct risks to the ecosystem and human health, the degree or details of which can be encoded through the assertions of relevant properties/values in an instance of Risk type (risk_1). On the basis of the observed pollution incident, of its severity and its implied risks, the interested authorities could be informed, the details of which can be represented as an instance of Organization type (organization_1).

OPEN IN VIEWER

Fig. 4.

Main instances in EUCISE-OWL for representing a sea pollution incident where an oil spill was detected.

OPEN IN VIEWER

Fig. 5.

Asserted instances to the detection_1 instance of Action type.

Instances detection_1 and oilspill_1 represent events of different types (Action and PollutionIncident, respectively), and are associated with different properties and values. As seen in Fig. 5, an instance of Action type may be described through the assertion of relevant enumeration values that define the mission type, as well as the type, the status and the priority of the action. On the other hand, an instance of PollutionIncident may be described through the assertion of relevant enumeration values that define the pollution type, the nature, the type, the severity and certainty of the incident, as well as the urgency and response type of the event (Fig. 6). In the specific example, the severity of the incident was defined as moderate, i.e. possible threat to life or property (severity_type_03); considering this, responsive actions should be taken soon (urgency_type_02), according to the defined protocol (response_type_04).

OPEN IN VIEWER

Fig. 6.

Asserted instances to the oilspill_1 instance of PollutionIncident type.

OPEN IN VIEWER

Fig. 7.

Asserted instances to the eventlocation_1 instance of EventLocation type.

Details about the actual geographical location (latitude and longitude) of the pollution incident can be presented through the assertion of properties and values in an instance of type Location. Additional metadata can be represented through relevant instantiations attached to instance eventlocation_1 of the association class EventLocation. For example, as seen in Fig. 7, the date and time at which the oil spill was detected is represented through an instance of type Period; the location where the oil spill was detected is where the event started (enumeration value location_role_in_event_type_01); and, the area where the event takes place is now considered as dangerous (enumeration value event_area_type_DGR).

In order to assess the EUCISE-OWL ontology, we followed the guidelines in [23]. Initially, we focused on evaluating its modelling quality by submitting it to OOPS! (OntOlogy Pitfall Scanner!), an online system for testing an ontology against the most common modelling pitfalls [20]. OOPS! also provides an indicator (critical, important, minor) for each pitfall, according to the respective possible negative consequences. In the case of EUCISE-OWL, OOPS! did not detect any pitfall.

Moreover, although the development of the proposed ontology was heavily based on a UML-to-OWL conversion from an existing data model (see Section 3), which was in turn designed with substantial contributions by domain experts (see Section 2), it would be interesting to get some insight into the assessment of the ontology’s domain coverage. Thus, we submitted EUCISE-OWL to OntoMetrics [16], an online platform for calculating more advanced ontology metrics. Table 4 includes a subset of the metrics calculated by OntoMetrics that present the most interesting aspects of the ontology with regards to its domain coverage.

As indicated in [13], the first three metrics refer to the ontology’s accuracy, while the other two refer to its conciseness:

Furthermore, we wanted to assess the ontology’s performance and efficiency with real data. Thus, we generated four (4) different serializations of the EUCISE-OWL ontology, with a different total number of populated incident instances per case (i.e., 100, 1K, 10K, 100K). These serializations were generated via a custom service we developed for populating the ontology with synthetic data, namely, individuals of specific subclasses of type Event; every such instance is asserted with:

The experiments described below were executed with the use of rdf4j1

We then proceeded to evaluating the semantic reasoning performance, by creating three inference tasks (SPARQL queries Q1–Q3) with increasing complexity:

For brevity, Fig. 8 presents only the last SPARQL query. Results are summarized in Table 6.

On the basis of the aforementioned results, it can be stated that the ontology’s responses are given almost real time, regardless the number of triples, when queries do not involve complicated relations (like for example Q1). High response times are recorded in complex SPARQL queries, when the populated instances of Event type reach up to 100K; such a delay can be justified due to the additional effort that is required in Q3, for calling the GeoSPARQL function (geof:distance) in each repetition.

OPEN IN VIEWER

Fig. 8.

Indicative SPARQL query applied for performance evaluation purposes.

There is currently a great interest in automated, on-time maritime surveillance, with an increasing attention towards efficient data handling. Besides EUCISE2020, an indicative list of ongoing relevant maritime EU-funded projects includes MARISA,5

There are additional semantic approaches that model concepts relevant to the maritime domain, but usually they have a narrower scope than EUCISE-OWL. More specifically, in [3] an ontological representation of the different types of ships and relevant parameters is implemented, according to the AIS (Automatic Identification System), for maritime traffic analysis. Moreover, the detection or prediction of abnormal ship behaviour is investigated, by analysing semantic trajectories and geographical localizations of the maritime objects [2,31]. In [12], an ontology-based representation of maritime regulations is proposed, for formulating maritime decision support rules in a machine-readable way.

To the best of our knowledge, CISE is the most concrete and complete model for implementing a common information sharing environment across countries and involved authorities, where all maritime surveillance operations can cooperate with one another and share data, following a common set of rules. Thus, its availability in an interoperable and easily adoptable form, as our proposed EUCISE-OWL representation, is of vital importance for operational use. As also stated before, to the best of our knowledge, EUCISE-OWL is the first attempt to fully capitalize on the EU-wide CISE framework, in order to develop an ontology model for facilitating information exchange in the maritime domain.

This paper presented EUCISE-OWL, an ontology representation of the CISE data model that constitutes an EU-wide collaborative initiative for facilitating information sharing between maritime monitoring authorities. EUCISE-OWL is an outcome from the ROBORDER EU-funded project, and we are currently deploying it as a common platform for semantically integrating analysed data from heterogeneous sensors and for performing semantic reasoning on top of this data, in order to facilitate decision support for authorities. Within ROBORDER, EUCISE-OWL is addressing the project’s pilot use cases, which include addressing pollution incidents at sea (see Section 5), tracking suspicious vessels, countering illegal activities etc. Therefore, the ontology has only been evaluated in experimental settings (e.g. see Section 6), but the upcoming pilot demonstrations will provide an excellent opportunity for actually evaluating the utility of the ontology in practice.

As for our future goals, ROBORDER serves as a good testbed for the wider adoption of our proposed ontology and its potential extensions in a wider variety of scenarios, like e.g. border trespassing in the sea or on the land, or in applying robotics for enhanced security [27]. Within ROBORDER, we have the substantial advantage of collaborating with maritime authorities who have been deploying CISE in practice and could greatly contribute in encouraging the wider use of our EUCISE-OWL model through disseminating the outcomes of this work within their respective networks. On our part, we will be able to support the required technical implementations, in order to facilitate the wider and easier adoption of the model. Finally, a more long-term goal is to work towards including EUCISE-OWL in the EU’s SEMIC action11

The work within the ROBORDER project that involves the EUCISE-OWL ontology is characterised as “classified”. Thus, the ontology is not (yet) publicly available. Access can be granted after submitting to the corresponding author a request that will be evaluated on a per case basis.