Ontology 101, Part 2: A Practical Application of an Ontology

pics-blog-dataarch-9Ontology 101, Part 2: A Practical Application of an Ontology

 posted by Mosaic Data Science

 

 

 

 

 

Part I in this three part series can be viewed by clicking here.

In Part 1 of the three part series, we discussed what an ontology is and what the key components are. If you have yet to read that article, please do so before continuing. In Part 2, we look at how an ontology can be applied to a domain, specifically our Traffic Management Initiative (TMI) ontology developed under the TMI Attribute Standardization (TAS) project. This article will first give a brief overview of why an ontology is needed for TMI data and then give a high-level overview of the ontology that we have created. For the purposes of clarity, all references to specific classes, properties, and individuals contained within an ontology will be written in italics, like this.

Motivation for a TMI

Ontology Traffic managers in the National Airspace System (NAS) today typically coordinate, disseminate, and record Traffic Management Initiatives (TMIs) via multiple automated and non-automated systems. These methods include, but are not limited to, the National Traffic Management Log (NTML), Information Display System (IDS), Traffic Flow Management System (TFMS), Flight Schedule Monitor (FSM), and oral or written communications. Historical TMI information is collected via a variety of sources, some automated and others manual, and includes free-text descriptions of TMIs. The lack of a comprehensive TMI ontology implemented through automated systems results in difficult collection, distribution and use of TMI information, both for real-time operations and historical analysis. In addition, current efforts toward the digitization of TMIs rely on imprecise algorithms to decipher free-text and non-standard input data.

This shortfall has created a need to define a system model in which TMIs can be organized into a TMI ontology according to their individual attributes and relationships. This ontology is able to facilitate automated storage and retrieval, real-time TMI coordination, implementation and dissemination, unified TMI modeling, post-event analysis, and continuous flight-day evaluation. The ontology is informed by, but not restricted to, the processes currently used for TMI implementation and coordination.

TMI Ontology Overview

The TMI ontology supports 16 different TMIs, including Airspace Flow Program (AFP), Altitude restriction, Blanket, Call for Release, Compression, Collaborative Trajectory Options Program (CTOP), Departure Sequencing Program (DSP), Ground Delay Program (GDP), Ground Stop (GS), Minutes-In-Trail (MINIT), Miles-In-Trail (MIT), Reroute, Shut Off, Speed restriction, Severe Weather Avoidance Plan (SWAP), and Time-Based Metering (TBM). The information for these TMIS have been organized into two main classes: DomainConcept and ValuePartition. The DomainConcept class contains all of the classes of individuals that represent features within the NAS (e.g. airports, routes, FCAs) or TMIs that are used to manage the NAS. The ValuePartition class contains specific classes of individuals that restrict the possible values for an object property (e.g. Probability of Extension, Causal Factor, or Meteorological Conditions). These two classes as well as their first-level subclasses are shown in the figure below.

ontology101b

Figure 1. The top level classes in the TMI Ontology.

Under DomainConcept, there are six major subclasses: Carrier, NASelement, NAScompound, NASevent, NASstatus, and TMI. The first five that are listed are NAS detail classes, which define features, physical locations, or events in the NAS. Additional information about each of these classes are listed below. Most of these classes are not defined in detail (i.e., include specific attributes in the ontology), but are placeholders for information that will be contained in another model. This information is included in the ontology as these NAS details may necessitate the issuance of a TMI, be used to define a TMI, and/or show the impact of a TMI.

  • Carrier – class that includes major and sub carriers and their connections.
  • NASelement – class that contains permanent locations or areas within the NAS (e.g., airport, airway, center, fix, NAVAID, runway, sector, taxiway, tower, and TRACON).
  • NAScompound – class that contains features that are comprised one or more NAS elements and are used to organize or manage the NAS (e.g., area, flight procedures, gate, metroplex, or route). Note that ad hoc routes (routes that are created dynamically to support a specific traffic situation) are defined in detail, including protected segments, flight filters, route types, etc.
  • NASevent – class that contains occurrences that take place in the NAS for a finite amount of time (e.g., deicing, equipment outages, flights, flow areas, and monitor alerts).
  • NASstatus – class that contains the state of an element within the NAS (e.g., Special Use Airspace (SUA) and airport configuration).

The TMI class is broken down into two major subclasses: TMI_Event and TMI_Program. The TMI Event class contains the individual initial and modified TMI instances that are issued. Every TMI event is part of an encompassing TMI Program, so each individual in the TMI_Event class links to one individual in the TMI_Program class. The subclasses of the TMI_Event class are the 16 TMIs that were listed above. Most of the TMI classes under the TMI_Event class have the same two subclasses: Initial and Modified. The Initial class contains individual instances of that TMI that is the first to be issued on a given day to address a demand/capacity imbalance and first create a TMI Program. Every issued TMI Program must have one event in the Initial class of that TMI. The Modified class contains individual instances of TMI events that modify an existing TMI event, and are part of the same TMI Program. Not all TMI events will have an instance in this class, but if more than one TMI event is issued for the same demand/ capacity imbalance, or program, those instances are captured in the Modified class of that TMI.

The TMI_Program class contains groups of individual TMI events, both initial and modified, that are issued to alleviate a specific demand/capacity imbalance. Similar to the TMI_Event class, the subclasses of the TMI_Program class are the 16 TMIs listed above. The members of the TMI_Program class link to at least one individual in the TMI_Event class. For example, if there are three contiguous TMI MIT events issued to control the flow of traffic into ORD, the information from those three events would be contained in a single individual in the TMI_Program class, specifically the TMI_Program_MIT class.

As mentioned in Part 1 of the series, a Value Partition is a special type of defined class that is used to refine the descriptions of a class by restricting the range of possible values to an exhaustive list. This type of class is added to an ontology when a there fixed number of values allowed for a particular property. For example, since there are only three possible values for the property hasProbabilityOfExtension, the correct way to model this in an ontology is to create a value partition containing the three choices: Low, Medium, and High. In this way, values assigned by the property are restricted to the range defined by the value partition. The TMI ontology contains a total of 31 value partitions, which are shown in Figure 1.

I hope you enjoyed the second part of the Ontology 101 series. Stay tuned for the final part of the series in which we will go through the steps on how to create an ontology from scratch. Please contact us with any questions or comments.

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

3 × one =