frameworks, and with the help of the Ford team analyzed the GSPAS ontology. Then the IITM team developed a document that presented ( 1) their understanding of the KR frameworks, ( 2) a potential
mapping between GSPAS and OWL, ( 3) their understanding of the design, organization, and use cases of
GSPAS ontology, and ( 4) a high-level approach to
GSPAS ontology reengineering.
The Ford team then reviewed the understanding
document and worked with the IITM team to validate their understanding of the ontology and to
address the questions and fill in the blanks where
An ontology describes terms in a domain and captures their association with other terms in that
domain. A structure-preserving transformation maps
each term and its associations and subsumptions
from a source ontology to a term with corresponding
associations and subsumptions in a target ontology,
and thereby preserves the semantics of these terms.
GSPAS implements a subset of KL-ONE that satisfies Ford’s AI needs. We worked with this subset
instead of the full KL-ONE. Accordingly, the goal of
framework mapping is to create a semantics-preserv-ing mapping between GSPAS (a subset of KL-ONE)
and OWL frameworks. This mapping is created for
each of vocabulary, representation, and reasoning
components of these frameworks.
GSPAS, KL-ONE, DL, and OWL frameworks, though
related, were developed by different groups across
space and time. This naturally led to the use of different names to refer to a given idea. Table 1 documents the various vocabularies and their correspondences. It also shows the GSPAS features (un)
supported in other frameworks.
To encode knowledge, the GSPAS ontology uses two
kinds of concepts (primitive and defined) and two
concept-forming operators (value-restriction and
conjunctions), further, it uses classifiable attributes
(roles) to define value restrictions, and two kinds of
nonclassifiable attributes (nondefinitional roles) to
store application data, where one is inherited by sub-
classes and the other is noninheritable. In KL-ONE
and so in GSPAS, a primitive-concept provides neces-
sary conditions for membership, whereas a defined-
concept provides both necessary and sufficient con-
ditions for membership. And a value restriction
restricts all fillers of a role to a given type or concept,
and allows us to describe concepts based on these
restrictions, like things whose tires are slick. Consider
the statement, Formula One car has slick tires. If this is
taken to provide a necessary condition about F1 cars
(a primitive concept) then it states that tires of F1 car
are slick tires. Instead, if it is taken to provide both
necessary and sufficient condition about F1 cars (a
defined concept) then it states that tires of F1 car are
slick tires, and things whose tires are slick are F1 cars. In
short, the GSPAS KR language permits the following:
A ⊑ C (primitive concepts); A ≡ C (defined concepts)
where A is any concept name, and C is a concept
forming expression which can be a concept-name or
a value-restriction or a conjunction, as shown below.
Here A1, A2 are concept names, R is role name, and
C1, C2 are concept forming expressions.
C → A1 C → (∀R.A2 ⊓ ∃R) C → C1 ⊓ C2
Using this notation, we can describe F1-Car as a primitive concept: F1-Car ⊑ Car ⊓ (∀ tire.Slick-Tire ⊓ ∃tire),
which states that F1-Car is a car and all its tires are
slick tires and has some tires. See how the textual
description resembles the expression.
For a lossless translation, we have to map the
GSPAS KR language to OWL constructs that will preserve the meaning of domain terms and their subsumptions. One such mapping (table 2) is discussed
First, the primitive concepts are mapped to partial
concepts in OWL and are encoded as subclass
axioms. And defined concepts are mapped to complete concepts in OWL and are encoded as class-equivalence axioms. Further, concept names and
concept conjunctions are mapped, respectively, to
class names and class intersections in OWL. These
four mappings are exact.
Next, GSPAS roles are mapped to object properties.
Figure 4. Ontology Reengineering.
The figure shows the current and end states of the ontology, the inputs to
reengineering (solid line), and the various phases and deliverables (dashed
END STATE CURREN T STATE