Ontology 101, Part 3: How to Create an Ontology

pics-blog-dataarch-10Ontology 101, Part 3: How to Create an Ontology

posted by Mosaic Data Science

 

 

 

 

 

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

In Part 2 of the three part series, we discussed the motivation behind and a high-level overview of our TMI ontology. If you have yet to read either Part 1 or Part 2 of this series, please do so before continuing. In the final part of this series, we look at the steps that we took to create the TMI ontology. It is important to note that even though the examples for each step link back to the TMI ontology, the method that we utilized can be used for any domain. For the purposes of clarity, all references to specific classes, properties, and individuals contained within an ontology will be written in italics, like this.

To create the TMI ontology, a six step approach was taken. (1) This approach helped guide the process from the concept development phase to the creation of each part of the ontology. Each of the six steps are summarized below.

1. Determine the domain and scope of the ontology. This is done by first determining the domain that the ontology will cover, how the ontology will be used, and who will be using and maintaining the ontology. The scope of the ontology can be established by creating a list of questions that the information in the ontology should be able to answer. Known as competency questions, these questions help focus the ontology by making sure that it contains enough information at the appropriate level of detail to answer the questions. For example, a competency question for the TMI ontology would be “Does the ontology account for every possible combination of inputs from the primary TMI tools?”

2. Consider using existing ontologies. At this point, the TMI ontology does not contain any ontology that was previously developed. However, it has been built in such a way that would allow for the addition of another ontology. For example, it known that another effort is under way within the FAA to organize all of the information that is used to manage the NAS on daily basis into a single ontology. While it is more likely that the TMI ontology could be used as a piece of this NAS-wide ontology, some individual pieces that make up that ontology could be “plugged in” to the TMI ontology (e.g. flight information, airport specifications, etc.) to make it more robust.

3. Enumerate important terms in the ontology. This is done by creating a comprehensive list of all of the terms and their attributes that the ontology should cover. During this step, all of the TMIs in the NAS and the attributes that define them were identified from various data sources (e.g., entry tools, TMI databases, and FAA tutorials) and interviews with Subject Matter Experts (SMEs). The resulting information for each identified TMI was organized into a Microsoft Access database which guided us during the development phase of the TMI ontology.

4. Define the classes and the class hierarchy. This was done by using a top-down approach whereby the development process starts with the most general concepts in the domain and then becomes increasingly specific with each successive level of the hierarchy. Take for example the hierarchy of classes that describe the routes that are contained within the National Playbook. In the TMI ontology, the top level (the most general) is the class called NAScompound, which describes individuals that are comprised of one or more NAS elements (e.g. airports, fixes, etc.).

of complexity is the NAScompound_Route class which describes all of the routes that are defined in the NAS. The NAScompound_Route_Playbook class resides under the NAScompound_Route class, but the final level of specialization (the most specific) is added to the NAScompound_Route_Playbook class by including classes that describe the routes for airports, airway closures, east-to-west transcontinental, west-to-east transcontinental, and regional.

5. Define the properties of classes. While the classes alone do provide a detailed framework to the ontology, they do not provide enough information to answer the competency questions that were created in the first step. To do this, the attributes of the identified TMIs must be added to the ontology and assigned to the specific classes they describe. During this step it is important to remember that that all subclasses of a class inherit the properties of that class. For example, when the property hasStartTime is added to the superclass TMI, that property applies to all of the subclasses of TMI in the ontology.

6. Define the facets of the properties. The facets of a property describe the value type, allowed values, and the number of the values (cardinality) that are allowed across a property. Further information about each of these facets is described below.

a. Value Type: The facet describes what types of values can fill the property. Some of the more common value types include:

i. String – properties with a string value. For example the value for the hasTMIname property.

ii. Number – properties with a numeric value (e.g., integer, dateTime, or float). For example, the value for the hasStartTime property or the value for the hasNewMinDelay property.

iii. Boolean – properties with a simple true/false or yes/no flag. For example, the value for the isInternal or isActualTMI properties.

iv. Enumerated – properties with a list of allowed values specified by a value partition. For example, the hasAircraftEngineType property can only have one of four possible values: Prop, Turbo, or Jet. v. Instance – properties that define a relationship between individuals. For example, TMI events with the property hasTMIprogram have a value that is a member of the TMI_Program class.

b. Domain and Range: This facet defines the allowed class or classes for an Instance-type property (range). For example, the range for the property includeFlight is the individuals of the NASevent_Flight class. Conversely, the domain of a property specifies the class or classes that a property describes. For example, the domain of the property includeFlight is the TMI_Event class.

c. Cardinality: Defines how many values a property can have, ranging from single cardinality (at most one value) to multiple cardinality (any number of values). The minimum and maximum cardinality of a property can also be set which allows the number of values allowed for a property to be specified more precisely. For example, the property hasMilesValue for a MIT TMI event can only have 1 positive integer or the property includeAnyDepartureCenter for a GDP TMI event needs to have at least (minimum of) 1 individual from the NASelement_Center class.

It should be noted that the ontology itself was created using Protégé 4, which is a free, open-source ontology editor. (2) The ontologies created in Protégé are saved in the OWL 2 Web Ontology Language file format as specified by the World Wide Web Consortium (W3C). Since Protégé can produce the ontology in the standard OWL format, any other ontology tool can be used to view and edit the ontology in the future, as long as it supports the OWL format. I hope you enjoyed the last part of the Ontology 101 series and now have a better understanding on the world of ontologies. If you have any questions about anything present in this series, please do not hesitate to reach out to us.

 

<hr />

(1) Noy, N. and McGuinness, D.L. (2001). Ontology Development 101: A Guide to Creating Your First Ontology.

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>

*

1 × two =