can infer additional properties on behalf of the user.
These rules manage bookkeeping during operations—
e.g., moving a container changes the location of all the
items in the container—and for domain physics, such
as the loss of fluid flow when a pump loses power. The
rules are given in the form of SWRL rules (Horrocks
et al., 2004), which can be used to form rules whose
left hand sides (the if portion or context) and right
hand sides (the then portion or implication) are OWL
relations. An example of a rule in our ontology is
given below:
<DLSafeRule>
<Body>
<ClassAtom>
<Class abbreviatedIRI="base:PhysicalEntity"/>
<Variable IRI="urn:swrl#a"/>
</ClassAtom>
<ClassAtom>
<Class abbreviatedIRI="base:PhysicalEntity"/>
<Variable IRI="urn:swrl#b"/>
</ClassAtom>
<ClassAtom>
<Class IRI="#ISSlocation"/>
<Variable IRI="urn:swrl#l"/>
</ClassAtom>
<ObjectPropertyAtom>
<ObjectProperty IRI="#isAttachedTo"/>
<Variable IRI="urn:swrl#a"/>
<Variable IRI="urn:swrl#b"/>
</ObjectPropertyAtom>
<ObjectPropertyAtom>
<ObjectProperty IRI="#hasISSlocation"/>
<Variable IRI="urn:swrl#b"/>
<Variable IRI="urn:swrl#l"/>
</ObjectPropertyAtom>
</Body>
<Head>
<ObjectPropertyAtom>
<ObjectProperty IRI="#hasISSlocation"/>
<Variable IRI="urn:swrl#a"/>
<Variable IRI="urn:swrl#l"/>
</ObjectPropertyAtom>
</Head>
</DLSafeRule>
This rule says if a object is attached to another
object, and that object has an ISS location, then the first
object also has that location. Thus if a user asserts that
a piece of equipment is attached to a mount and that
mount has a location, a reasoner will infer the location
of the equipment. Figure 1 shows a piece of equipment
on the ISS called a DC to DC Converter Unit (DDCU-
E 3) with a few relations defined, the important one
being the isAttachedTo linking DDCU-E 3 to the cold
plate called DDCU-CP 1. This in turn is attached to
a mount (S0 DDCUmount1), and finally ends with a
specific ISS location (S0B01F01MS). After running
the reasoner and applying the SWRL rules as shown
in Figure 2, the reasoner can infer that DDCU-E 3 is
located at S0B01F01MS.
2 REASONER PERFORMANCE
ISSUES
As the PRONTOE project progressed, we noticed a
significant performance degradation in two OWL rea-
soners: Pellet (Sirin et al., 2007) and HermiT (Shearer
et al., 2008)—especially when we added telemetry
data to the OWL ontology. Before we added the
telemetry the reasoner would run over PRONTOE in
15–30 seconds; with the telemetry added it took from
15 to 20 minutes. Our ontology without the telemetry
had 442 classes and 1386 individuals; with the teleme-
try these increased to 502 and 1539 respectively. It
seemed strange that this slight increase in data would
cause such severe degradation in performance. The
telemetry data used all four of the OWL features men-
tioned above. We originally focused on the SWRL
rules, but this was quickly dismissed since removing
the SWRL rules had no significant effect on perfor-
mance. After some experimentation, we discovered
that removing all individuals of subclasses of Enu-
meration made the reasoner faster. Adding members
for a single subclass back (e.g. CDRSDayNightEnu-
meration members day and night) made the reasoner
slow again. CDRSDayNightEnumeration and other
subclasses of Enumeration are so-called closed enu-
merated classes. They are specified with the following
axioms (function-style syntax):
EquivalentClasses(:CDRSDayNightEnumeration
ObjectOneOf(:night :day))
We change this to an open class as follows:
ClassAssertion(:OpenOrClosedClass :a)
ClassAssertion(:OpenOrClosedClass :b)
The reasoner got much faster. There was initially
concern about switching the closed classes to open
classes. The intention of the closed classes was to
restrict the operator to choosing among the specified
individuals in a given class. However, OWL does not
make any assumptions about the uniqueness of indi-
viduals. Thus, closed classes can lead to unexpected
inference. For example, if you have a closed class
with members (A, B, C) and you assert that D is also a
member of the class, you will not get an inconsistency.
You will instead infer that D is equivalent to A, B or
C. We could get along with open classes by having
PRONTOE do its own checking for closedness, but we
decided to more thoroughly characterize the sources
of the slow reasoner speeds.
2.1 Characterization
We created a scalable synthetic ontology to investigate
the performance issue in more depth. A Python pro-
ReasonerPerformanceonOntologiesforOperations
305