Ontology design patterns and semantic abstractions in ontology integration

2.1. Hackathon

The following were the stated aims and activities for the Hackathon, as recorded on the hackathon wiki page for this hackathon (Bennett and Berg-Cross, 2014):

Explore and identify ontologies for the different types of content that relate to risk (events, situations, statistics, incidents, goals, etc.)

2.2. Future work/out of scope

Scope out and specify a possible application

2.3. Focus was on

Ontology design patterns versus high level abstractions

2.4. Tooling

Two ontology visualization tools were available for use in the hackathon. One was a Unified Modeling Language (n.d.) tool called Sparx Enterprise Architect (n.d.), adapted by the author for the visualization of constructs in the Web Ontology Language (OWL), described in McGuinness and Van Harmelen (2009) using an early draft of the Ontology Definition Metamodel (2009) from the Object Management Group (n.d.) that was modified to provide business-readable diagrams. It was not possible to generate OWL serialization files directly from this toolset, and so this was only used for presentation of visual representations of the common risk foundational ontology in the Financial Industry Business Ontology (2015) Foundations specification that was in preparation during this hackathon.

The main visualization tool used was the Visual Ontology Modeler (n.d.) from Thematix Partners LLC. This was used for visualizing ontologies after they were created. This tool uses the canonical version of the ODM (2009) specification. It also has the ability to ingest OWL in a number of syntactical flavors and to generate OWL representations of that material for further work and for validation in tools that provide reasoner support.

Additional tooling was used to create ontologies, principally Protégé (n.d.) from Stanford University.

3.1. Ontologies

The group defined the subject domain to be the risks involved in getting from Location A to Location B via various means of transport. Team members identified, built or adapted ontologies for the different dimensions of the problem (events, situations, probabilities and impacts). These were:

trajectory modeling

3.2. Detailed working

The proposed mobile application was intended to provide comparative risk figures for a range of transportation modes against a single specified goal. In the example, the goal was to get from the user’s home in Washington, D.C., to a conference venue in Austin, Texas, by 9am on a given day. A number of different options were given for completing this goal. Risks would then be calculated as a product of probability and impact on that goal, with probability being determined as a simple actuarial application of historical data to present probabilities.

The team combined concepts in the following areas:

Some ontologies were created from scratch from sample data sets, while others were adapted or re-used. The Trajectory ontology was provided by Mike Dean, who extended it with travel-related concepts for the purposes of this hackathon in the form of a new “Trip” ontology. The kinds of incident that could prevent or delay a traveler were sourced in the three sample sets of historical data from which Anett Hoppe created an ontology from scratch.

The Event Ontology was built around a published event ontology design pattern for open source development, developed for the Centre for Digital Music. Max Gillmore extended and adapted this to create an over-arching ontology of risk events.

Mike Bennett created diagrammatic visualizations of these ontologies and facilitated collaborative sessions in which the group endeavored to integrate these.

We imported most of the ontologies into our working set of integrated ontologies in the VOM tool, and used this to identify common concepts and differences between concepts in the different ontologies.

In this way the hackathon involved both top-down and bottom-up development of ontologies.

For the Trip, Common Risk and Risk Assessment areas, the participants created or adapted ontologies in Protégé. The resulting Common Risk and Risk Assessment ontologies were then ingested into the VOM tool in order to provide a visualization of the model content.

All ontologies were in OWL. We did not set out any specific requirements for these to be in particular dialects of OWL as described in McGuinness et al. (2009), such as OWL-DL or OWL-Full, since the requirement focused on business meaning rather than machine processing. However, inspection of the ontologies used suggests that many or all of them would also be OWL-DL compliant. We did not test for this.

Syntaxes used were N3 (2011), Turtle (2014) and RDF/XML (2014). OWL was chosen partly because it was familiar to a number of participants and could be created in tooling available to them, and partly because there were pre-existing ontologies in this format which we were able either to re-use or adapt.

Diagrams were created in the VOM tool for each ontology to better understand the content, and these were laid out along similar lines to the available conceptual diagrams in the reference sources for this work. The aim was to create an integrating ontology which would import these and define the overall application ontology.

The ‘Travel Adverse Events’ ontology was developed in bottom-up fashion directly from the available data. This ontology is very extensive and covers multiple modes of transport and multiple causes of delays, accidents, bridge strikes1

A second round of work involved layering the common risk concepts such as those for risk event consequences and impacts, and integrating the C4DM Events ODP with the FIBO ontology for Goals. This was then ingested into VOM and a set of diagrams created for the main concepts (Fig. 1).

OPEN IN VIEWER

Fig. 1.

The Ontology ‘Risk Core Concepts’.

We used the on-line sessions to compare thinking about what a model of the core concepts for risk would look like and converged on a common conceptual framework which was implemented in whole or in part in the travel events, common concepts and risk assessment ontologies, each of which contained refinements and extensions to that model. The common conceptual framework took the form of a set of high level semantic abstractions of which the concepts in the integrated ontologies could be framed as specialized kinds by way of subclass and subproperty relationships.

The extensions to the Trip ontology were segregated so that there were separate OWL files for instance data for the example application, and for common concepts for modes of transport. Most of those common concepts were already in the ‘Travel Adverse Events’ ontology, while some needed to be added. Those additional concepts were for types of rental car, types of aircraft body and other variables which were assumed to be related to the real-world risk of those travel modes. As a future exercise, once the ontology of these additional concepts is defined, it would form a checklist of sets of historical data to be mined. Thus, the top-down approach to risk factors met the bottom-up modeling of available risk statistics that was carried out during the hackathon.

Of particular interest in the integration, was the notion of “Event”. For the hackathon itself, we did not look at foundational ontologies that have high-level concepts for things that happen, but instead took as our starting point the simple C4DM event ontology design pattern and considered the semantics of events as they related to risk.

The hackathon ended up with two distinct notions of Event that could not be combined into one concept or represented as one class. One of these was the above ontology design pattern where an event has a time and a place (whether this is in the past, present or future), and the other was the kind of event that may or may not happen, and which (for the purposes of risk) is an event to be avoided. As can be seen in Fig. 1, these were related via two subclass relationships but this was not considered satisfactory. This was not addressed during the hackathon, and in particular the class shown as ‘RecurrentEvent’ in Fig. 1 would not be retained in any eventual solution.

OPEN IN VIEWER

Fig. 2.

Integrated Ontology Architecture.

It was also noted that in other contexts, such as finance, an event to be avoided by one party as a risk might represent an event to be welcomed by another as an opportunity. In either case, the event needed to be represented in the ontology even though it may not (or in the risk case, should not) actually happen. This provided some interesting insights into the way that different interpretations of a term like “event” might refer to different kinds of events in a domain of discourse.

4.1. Status of the ontologies

At the end of the hackathon there was sufficient information to specify an overall, integrated ontology and design for a simple travel risk mobile application. In this application, the user would enter a desired time and destination and either enter different travel modes or have these calculated by existing applications which already do this; the application would return comparative risk figures for the different travel options.

The integrated ontology consists of several modules in the form of individual OWL files (sometimes also referred to as ontologies), with OWL import relationships between them as appropriate. One over-arching OWL file imports the others to define the overall graph that is the integrated ontology for the application, as shown in Fig. 2. This over-arching file is identified in Fig. 2 as “Integrating Ontology” and would need to be given a more appropriate permanent name.

In Fig. 2 the rounded gray boxes are individual OWL ontology files while the white boxes represent sets of assertions which are included in those ontology files for now but which would ideally be segregated into separate ontology files when the design is completed.

4.2. Ontological analysis of ‘Event’

There needed to be representations that would account for the two distinct interpretations of the notion of ‘Event’: something that actually happens with a time and a place, and something that can be described and thought of as an event whether or not it will happen. The latter is always either avoided or is in some possible future; once a risk related event has happened, it is no longer a risk. Therefore, any event characterized as having a time and a place is an event which has happened (or will happen) and having done so no longer presents a risk.

This presents challenges to some notions of how an ontology is intended to relate to its subject matter (e.g. ‘what exists’). One common approach to these challenges has been to think in terms of the risk event occurring in some “possible world”. In the case of risk this does not seem satisfactory, since one always has to model the world in which the event is avoided – this being also a possible world but not the possible work in which the event occurred. In any case this kind of work-around would not directly address the presence of two risk classes in the ontology – how would you show the distinction between the two classes called Event? These would have different identifiers but the user would need to know the intended semantics of each.

Since the application needs to make reference to both of these event concepts, it was necessary to approach this problem by sub-dividing the event-related part of the foundational model, to distinguish events that represent some risk, from other kinds of event in the domain of discourse, including the occurrence of a journey (a set of events) in which the risk-related events do not happen.

Another way of looking at this is that an ontology can be understood to provide intensional representations of events real, imagined or avoided, and that in the case of adverse events this intensional understanding of the concept is germane to avoiding or dealing with the occurrence of such an event in the actual world.

4.3. Property domains and ranges

It was also noted that many of the re-used ontologies had overly generalized domains and ranges, relying on the restrictions within the application to convey the intended semantics. In our view, this might be appropriate for a stand-alone Semantic Web application and may make some ontologies easier to re-use, but can be a barrier to integration of ontologies from multiple sources, as the intended semantics of the individual properties are not well defined.

4.4. Tooling

Another conclusion was that the tooling that we were able to find was not ideal for integrating ontologies. For example, VOM was well suited to ontology visualization, but only supports editing of one ontology at a time. There is a need for tooling that can be used to actively edit content in multiple ontology files, to move things around and complete and optimize the overall, integrated ontology.

4.5. Travel risk and financial risk

An interesting by-product of this work is that there are conceptual similarities between the semantics of the risks in multi-stage journeys, and the semantics of financial credit risk and cashflow payment streams. The concepts seen here for journeys and trajectories provide a more accessible way of thinking about these concepts for the financial industry. The similarities between journey trajectories and complex cashflow commitments seems to be amenable to the creation of a common ontology design pattern for the flow of cash based on the trajectories ontology. This would be complementary to existing mathematical models such as the well-known Black–Scholes model (Black and Scholes, 1973).