The Australasian Ontology Workshop series was initiated in 2005, and AOW 2012 is the eighth in the series. In 2012, AOW was held on the 4th of December 2012 in Sydney, Australia. Like most of the previous events AOW 2012 was held as a workshop of the Australasian Joint Conference on Artificial Intelligence celebrating its 25th anniversary as AI2012.
Out of papers submitted, we accepted 5 full papers and 4 short papers on the basis of three or four reviews submitted by our Program Committee of international standing. The submissions covered an interesting balance of topics with papers on fundamental research in ontologies, to ontology applications. We were pleased to note that we again attracted international authors. As in previous years, an award of $250 AUD was made available for the best paper, sponsored this year by CAIR 1 (the Centre for Artificial Intelligence Research in South Africa). In 2012 the best paper prize was awarded to Giovanni Casini and Alessandro Mosca for their paper "Defeasible reasoning in ORM2". AOW 2012 was the last AOW in its current form. From 2013 AOW will be replaced by the Australasian Semantic Web Conference (ASWC). The 12th International Semantic Web Conference (ISWC) and the 1st Australasian Semantic Web Conference (ASWC) will be held 21-25 October 2013 in Sydney, Australia and from 2014 onwards, ASWC will be a free-standing conference. Many individuals contributed to this workshop. We thank our contributing authors and dedicated international Program Committee for their careful reviews in a tight time frame. We also thank CAIR for sponsoring the memory keys containing the proceedings. We acknowledge the EasyChair conference management system, which was used in all stages of the paper submission and review process and also in the collection of the final camera-ready papers, as well as the Yola web authoring system for our website available at http://aow2012.yolasite.com. We hope that you found this eighth Australasian Ontology Workshop to be informative, thought provoking, and most of all, enjoyable! Kerry Taylor (CSIRO ICT Centre, Australia) (co-chair) Aurona J. Gerber (CAIR, South Africa) (co-chair) Tommie Meyer (CAIR, South Africa) (co-chair) Mehmet A. Orgun (Macquarie University, Australia) (co-chair)
1 http://www.cair.za.net/ Conference Organisation
AOW 2012 Accepted Papers
Defeasible reasoning in ORM2.
OntoMerge: A System for Merging DL-Lite Ontologies. Lexichographic Closure for Defeasible Description Logics. A normal form for hypergraph-based module extraction for SROIQ.
Two Case Studies of Ontology Validation.
Non-Taxonomic Concept Addition to Ontologies.
Deep Semantics in the Geosciences: semantic building blocks for a complete geoscience infrastructure.
Assessing Procedural Knowledge in Open-ended Questions through Semantic Web Ontologies.
Using Formal Ontologies in the Development of Countermeasures for Military Aircraft. p.4 p.16 p.28 p.40 p.52 p.64 p.74 p.86 p.98
Giovanni Casini1 and Alessandro Mosca2 1 Centre for Artificial Intelligence Research, CSIR Meraka Institute and UKZN, South Africa
Email: GCasini@csir.co.za 2 Free University of Bozen-Bolzano, Faculty of Computer Science, Italy
Email: mosca@inf.unibz.it
1 Introduction
ORM2 (‘Object Role Modelling 2’) is a graphical fact-oriented approach for modelling,
transforming, and querying business domain information, which allows for a
verbalisation in a language readily understandable by non-technical users [
On the other hand, in the more general field of formal ontologies in the last years a
lot of attention has been dedicated to the implementations of forms of defeasible
reasoning, and various proposals, such as [
In what follows we propose an extension of ORM2 with two new formal constraints,
with the main aim of integrating a form of defeasible reasoning in the ORM2 schemas;
we explain how to translate such enriched ORM2 schemas into ALCQI knowledge
bases and how to use them to check the schema consistency and draw conclusions.
In particular, the paper presents a procedure to implement a particular construction in
nonmonotonic reasoning, i.e. Lehmann and Magidor’s Rational Closure (RC)[
Fact-oriented modelling in ORM2
‘Fact-oriented modelling’ began in the early Seventies as a conceptual modelling
approach that views the world in terms of simple facts about individuals and the roles they
play [
According to the ORM2 design procedure, after the specification of the relevant object types (i.e. entity and value types) and predicates, the static constraints must be considered. The rest of this section is devoted to an informal introduction of the constraint graphical representation, together with their intended semantics. Fig. 1 shows an example of an ORM2 conceptual schema modelling the ‘academic domain’ (where the soft rectangles are entity types, the dashed soft rectangles are value types, and the sequences of one or more role-boxes are predicates). The example is not complete w.r.t. the set of all the ORM2 constraints but it aims at giving the feeling of the expressive power of the language. The following are among the constraints included in the schema (the syntax we devised for linearizing them is in square brackets): 1. Subtyping (depicted as thick solid and dashed arrows) representing ‘is-a’ relationships among types. A partition, made of a combination of an exclusive constraint (a circled ‘X’ saying that ‘Research&TeachingStaff, Admin, Student are mutually disjoint’), and a total constraint (a circled dot for ‘Research&TeachingStaff, Admin, Student completely cover their common supertype’). [O-SETTot(fResearch&TeachingStaff, Admin, Studentg,UNI-Personnel)] 2. An internal frequency occurrence saying that if an instance of Research&TeachingStaff plays the role of being lecturer in the relation isGivenBy, that instance can play the role at most 4 times [FREQ(isGivenBy.Research&TeachingStaff,(1,4))]. A frequency occurrence may span over more than one role, and suitable frequency ranges can be specified. At most one cardinalities (depicted as continuos bars) are special cases of frequency occurrence called internal uniqueness constraints [e.g. FREQ(hasWeight.Course,(1,1))]. 3. An external frequency occurrence applied to the roles played by Student and Course, meaning that ‘Students are allowed to enrol in the same course at most twice’. [FREQ(isIn.Course,isBy.Student,(1,2))] 4. An external uniqueness constraint between the role played by Course in isIn and the role played by Date in wasOn, saying that ‘For each combination of Course and Date, at most one Enrollment isIn that Course and wasOn that Date’. [FREQ(isIn.Course,wasOn.Date,(1,1))] 5. A mandatory participation constraints (graphically represented by a dot), among several other, saying that ‘Each Course isGivenBy at least one instance of the Research&TeachingStaff type’ (combinations of mandatory and uniqueness translate into exaclty one cardinality constraints). [MAND(isGivenBy.Research&TeachingStaff,Research&TeachingStaff)] 6. A disjunctive mandatory participation, called inclusive-or constraint (depicted as a circled dot), linking the two roles played by the instances of AreaManager meaning that ‘Each area manager either works in or heads (or both)’. [MAND(fworksIn.AreaManager,heads.AreaManagerg,AreaManager)] 7. An object cardinality constraint forcing the number of the Admin instances to be less or equal to 100 (role cardinality constraints, applied to role instances, are also part of ORM2). [O-CARD(Admin)=(0,100)] 8. An object type value constraint indicating which values are allowed in Credit (role value constraints can be also expressed to indicate which values are allowed to play a given role). [V-VAL(Credit)=f4,6,8,12g] 9. An exclusion constraint (depicted as circled ‘X’) between the two roles played by the instances of Student, expressing the fact that no student can play both these roles. Exclusion constraint can also span over arbitrary sequences of roles. The combination of exclusion and inclusive-or constraints gives rise to exclusive-or constraints meaning that each instance in the attached entity type plays exactly one of the attached roles. Exclusion constraints, together with subset and equality, are called set-comparison constraints. [R-SETExc(worksFor.Student,collaborates.Student)] 10. A ring constraint expressing that the relation reportsTo is asymmetric. [RINGAsym(reportTo.Admin,reportTo.AreaManager)]
A comprehensive list of all the ORM2 constraints, together with their graphical
representation, can be found in [
The ALCQI encoding of ORM2zero
With the main aim of relying on available tools to reason in an effective way on ORM2
schemas, an encoding in the description logic ALCQI for which tableaux-based
reasoning algorithms with a tractable computational complexity have been developed [
Now, the discrepancy between ORM2 and ALCQI poses two main obstacles that
need to be faced in order to provide the encoding. The first one, caused by the absence of
n-ary relations in ALCQI , is overcome by means of reification: for each relation R of
3
arity n 2, a new atomic concept AR and n functional roles (R:a1); : : : ; (R:an) are
introduced. The tree-model property of ALCQI guarantees the correctness encoding
w.r.t. the reasoning services over ORM2. Unfortunately, the second obstacle fixes,
once for all, the limits of the encoding: ALCQI does not admit neither arbitrary
set-comparison assertions on relations, nor external uniqueness or uniqueness involving
more than one role, or arbitrary frequency occurrence constraints. In other terms, it can
be proven that ALCQI is strictly contained in ORM2. The analysis of this inclusion
thus led to identification of the fragment called ORM2zero which is maximal with
respect to the expressiveness of ALCQI, and still expressive enough to capture the
most frequent usage patterns of the conceptual modelling community. Let ORM2zero =
fTYPE; FREQ ; MAND; R-SET ; O-SETIsa; O-SETTot; O-SETEx; OBJg be the
fragment of ORM2 where: (i) FREQ can only be applied to single roles, and (ii)
R-SET applies either to entire relations of the same arity or to two single roles. The
encoding of the semantics of ORM2zero shown in table 1 is based on the SALCQI
signature made of: (i) A set E1; E2; : : : ; En of concepts for entity types; (ii) a set
V1; V2; : : : ; Vm of concepts for value types; (iii) a set AR1 ; AR2 ; : : : ; ARk of concepts
for objectified n-ary relations; (iv) a set D1; D2; : : : ; Dl of concepts for domain
symbols; (v) 1; 2; : : : ; nmax + 1 roles. Additional background axioms are needed here
in order to: (i) force the interpretation of the ALCQI knowledge base to be correct
w.r.t. the corresponding ORM2 schema, and (ii) guarantee that that any model of the
resulting ALCQI can be ‘un-reified’ into a model of original ORM2zero schema.
The correctness of the introduced encoding is guaranteed by the following theorem
(whose complete proof is available at [
Let us conclude this section with some observation about the complexity of
reasoning on ORM2 conceptual schemas, and taking into account that all the reasoning tasks
for a conceptual schema can be reduced to object type consistency. Undecidability of the
ORM2 object type consistency problem can be proven by showing that arbitrary
combinations of subset constraints between n-ary relations and uniqueness constraints over
single roles are allowed [
Now we briefly present the procedure to define the analogous of RC for the DL
language ALCQI. A more extensive presentation of such a procedure can be found in [
: : : ; Rk:a1; : : : ; Rk:amg; O) (A) R-SETSub(A; B) (A) R-SETExc(A; B) (B) R-SETSub(A; B) (B) R-SETExc(A; B) O-SETIsa(fO1; : : : ; Ong; O) O-SETTot(fO1; : : : ; Ong; O) O-SETEx(fO1; : : : ; Ong; O) OBJ(R; O) logical characterization, it generally maintains the same complexity level of the underlying monotonic logic, and it does not give back counter-intuitive conclusions; its main drawback is in its inferential weakness, since there could be desirable conclusions that we won’t be able to draw (see example 2 below).
As seen above, each ORM2zeroschema can be translated into an ALCQI TBox. A TBox T for ALCQI consists of a finite set of general inclusion axioms (GCIs) of form C v D, with C and D concepts. Now we introduce also a new form of information, the defeaible inclusion axioms C < D, that are read as ‘Typically, an individual falling under the concept C falls also under the concept D’. We indicate with B the finite set of such inclusion axioms.
Example 1. Consider a modification of the classical ‘penguin example’, with the concepts P; B; F; I; F i; W respectively read as ‘penguin’, ‘bird’, ‘flying’, ‘insect’, ‘fish’, and ‘have wings’, and a role P rey, where a role instantiation (a; b):P rey read as ‘a preys for b’. We can define a defeasible KB K = hT ; Bi with T = fP v B; I v :F ig and B = fP < :F , B < F , P < 8P rey:F i; B < 8P rey:I; B < W g.
In order to define the rational closure of a knowledge base hT ; Bi, we must first of
all transform the knowledge base hT ; Bi into a new knowledge base h ; i, s.t. while
T and B are sets of inclusion axioms, and are simply sets of concepts. Then, we
shall use the sets h ; i to define a nonmonotonic consequence relation that models the
rational closure. Here we just present the procedure, referring to [
Transformation of hT ; Bi into h ; steps.
i. Starting with hT ; Bi, we apply the following Step 1. Define the set representing the strict form of the set B, i.e. the set Bv = fC v D j C < D 2 Bg, and define a set AB as the set of the antecedents of the conditionals in B, i.e. AB = fC j C < D 2 Bg.
Step 2. We determine an exceptionality ranking of the sequents in B using the set of the antecedents AB and the set Bv.
Step 2.1. A concept is considered exceptional in a knowledge base hT ; Bi only if it is classically negated (i.e. we are forced to consider it empty), that is, C is exceptional in hT ; Bi only if
T [ Bv j= > v :C where j= is the classical consequence relation associated to ALCQI. If a concept is considered exceptional in hT ; Bi, also all the defeasible inclusion axioms in B that have such a concept as antecedent are considered exceptional. So, given a knowledge base hT ; Bi we can check which of the concepts in AB are exceptional (we indicate the set containing them as E(AB)), and consequently which of the axioms in B are exceptional (the set E(B) = fC < D j C 2 E(AB)g).
So, given a knowledge base hT ; Bi we can construct iteratively a sequence E0; E1; : : : of subsets of B in the following way: – E0 = B – Ei+1 = E(Ei) Since B is a finite set, the construction will terminate with an empty set (En = ; for some n) or a fixed point of E.
Step 2.2 Using such a sequence, we can define a ranking function r that associates to every axiom in B a number, representing its level of exceptionality: r(C < D) = i if C < D 2 Ei and C < D 2= Ei+1
1 if C < D 2 Ei for every i : Here we shall assume that every concept has a finite ranking value, and we shall deal with the possible occurrence of some concept with 1 as ranking value in the following section. Step 3. Now we build a new formalization of the information contained in the knowledge base hT ; Bi, translating each of the two sets of axioms into two sets of concepts, and respectively. The set will simply correspond to the materialization of the inclusion axioms, i.e. the concepts translating the axioms.
= fC D j C v D 2 T g In order to define the set , given the rank value of the sequents in B, we construct a set of default concepts = f 0; : : : ; ng (with n the highest rank-value in B), with i = lfC
D j C < D 2 B and r(C < D) ig : Hence we substitute the conceptual system hT ; Bi with the pair h ; i, where and are sets of concepts, the former containing concepts to be considered valid for every individual of the domain, the latter containing concepts to be considered defeasibly valid, i.e. we apply such default concepts to an individual only if they are consistent with the information in our knowledge base. It is not difficult to see that the concepts in are linearly ordered by j=, that is, for every i, 0 i < n 1, j= i v i+1. Rational Closure. Consider now = fC1 D1; : : : ; Cm Dmg and = f 0; : : : ; ng. We define a nonmonotonic consequence relation between the concepts j h ; i that determines what presumably follows from a finite set of concepts . Simply, a concept D is a defeasible consequence of if it classically follows from , the strict information contained in the knowledge base (i.e. ), and the first default concept i that in the sequence h 0; : : : ; ni results classically consistent with the rest of the premises.
6
D, where i is the first ( )Definition 1. j h ; iD iff j= d u d u i v consistent formula 3 of the sequence h 0; : : : ; ni.
You can find in [
Proposition 1 ([
Moreover, as deciding entailment in ALCQI is EXPTIME-complete (see Theorem 2), and since the decidability problem for the rational closure is reducible to a finite number of decision w.r.t. the classical ALCQI consequence relation, we obtain immediately that Proposition 2. Deciding Cj hTe; eiD in ALCQI is an EXPTIME-complete problem. Example 2. Consider the KB of Example 1. Hence, we start with K = hT ; Bi. The strict form of B is Bv = fP v :F , B v F , P v 8P rey:F i; B v 8P rey:I; B v W g, with AB = fP; Bg. Following the procedure at Step 2, we obtain the exceptionality ranking of the sequents: E0 = fP v :F , B v F , P v 8P rey:F i; B v 8P rey:I; B v W g; E1 = fP v :F , P v 8P rey:F ig; E2 = ;. Automatically, we have the ranking values of every sequent in B: namely, r(B v F ) = r(B v 8P rey:I) = r(B v W ) = 0; r(P < :F ) = r(P < 8P rey:F i) = 1. From such a ranking, we obtain a set of default concepts = f 0; 1g, with 0 = (B 1 = (P
F ) u (B :F ) u (P 8P rey:I) u (P 8P rey:F i) : :F ) u (P 8P rey:F i) u (B
W ) Now, referring to definition 1, we can derive a series of desirable conclusions, as :F j :B, , B ^ greenj F , P ^ blackj :F , P j 8P rey::I. Instead, other counterintuitive connections are not valid, such as B ^ :F j P , B ^ :F j :P , or P j F . Here we can notice the main weakness of the Rational Closure: even if it would be intuitive to conclude that penguins have wings (P j W ), we cannot conclude that a class that results atypical (as penguins) cannot inherit any of the typical properties of its superclasses (as having wings), even if such properties are not logically connected to the ones that determine the exceptionality (not flying and eating fish). 5
Defeasible constraints for ORM2 As seen above, in order to introduce defeasible reasoning in DL we introduce the defeasible inclusion axiom C < D, indicating that the elements of the concept C typically, but not necessarily, are elements of the concept D. We want to introduce in the ORM2zeroschemas constraints playing an analogous role, i.e. representing defeasible constraints in the ontological organization of a particular domain. With this goal in mind, two constraints aimed at representing forms of defeasible constraints between classes, and classes and their properties, are introduced.
– A defeasible subclass relation: we introduce an arrow ‘;’, where ‘C ; D’ indicates that each element of the class C is also an element of the class D, if not informed of the contrary. 3 That is, 6j= d u d v : i. Example 3 (Defeasible subclass relation). Consider figure 2. The schema on the left represents in ORM2 the classic penguin example: penguins are birds and do not fly (the class Penguin is a subclass, respectively, of the classes Birds and Non-FlyingObj), while birds fly and have wings (the class Birds is a subclass, respectively, of the classes FlyingObj and WingyObj). The translation procedure into ALCQI gives back the TBox T in table 2. From T we can derive that the schema is inconsistent, since we have T j= :Penguin, i.e. the concept Penguin must be empty. We can modify the knowledge base introducing defeasible information, in particular stating that birds typically fly and typically have wings, and penguins typically do not fly. In this way we obtain the schema on the right, and in ALCQI we obtain a set B = fBird < WingyObject; Bird < FlyingObject; Penguin < NonFlyingObjectg, substituting the corresponding classical inclusion axioms in the TBox. – A defeasible mandatory participation: we introduce a new mandatory participation constraint ‘ ’, to use instead of the classically mandatory constraint ‘ ’. If the connection between a class C and a relation R is constrained by a constraint , we read it as ‘each element of the class C participates to the relation R, if we are not informed of the contrary’.
Example 4 (Defeasible mandatory participation). Consider figure 3. The schema represents the organization of a firm: the class Manager is a subclass of the class Employee, and every employee must work for a project. while every project must have at least an employee working on it. The class Manager is partitioned into AreaManager and TopManager. Each top manager mandatorily manages a project. The translation procedure into ALCQI of the left version of the schema gives back the TBox T in table 3. Since managing and working for a project are not compatible roles, T implies that the class TopManager is empty, since a top manager would manage and would work for a project at the same time. Instead, if we declare that typically an employee works for a project, we can consider the top managers as exceptional kind of employees; hence we substitute the mandatory constraint between Employee and WorkFor with a defeasible constraint (i.e. the schema on the right in figure 3); from such 8 WorksFor v 9f1 :Employee; WorksFor v 9f2 :Project Manages v 9f1 :TopManager; Manages v 9f2 :Project 9f1 :Manages v = 1 f1 :Manages Employee v 9f1 :WorksFor TopManager v 9f1 :Manages Project v 9f2 :WorksFor Project v 9f2 :Manages 9f1 :WorksFor v A>2 u :9f1:Manages Manager v Employee u (AreaManager t TopeManager)
AreaManager v :TopeManager a change we obtain a knowledge base as the one above, but with the defeasible inclusion axiom Employee < 9f1 :WorksFor instead of the axiom Employee v 9f1 :WorksFor.
Introducing such constraints, we introduce the forms of defeasible subsumptions appropriate for modeling nonmonotonic reasoning. In particular: – A subclass relation, as the ones in example 3, is translated into an inclusion axiom C v D, and correspondingly we translate the defeasible connection C ; D into a defeasible inclusion axiom C < D. – Analogously, consider the strict form of the example 4. The mandatory participation of the class B to the role AN is translated into the axiom B v 9f1 :AN. If we use the defeasible mandatory participation constraint, we simply translate the structure using the defeasible inclusion <, obtaining the axiom B < 9f1 :AN.
9
Hence, from a ORM graph with defeasible constraints we obtain an ALCQI knowledge base K = hT ; Bi, where T is a standard ALCQI Tbox containing concept inclusion axioms C v D, while the set B contains defeasible axioms of the form C < D. Once we have our knowledge base K, we apply to it the procedure presented in the previous section, in order to obtain the rational closure of the knowledge base.
Consistency. In ORM2, and in conceptual modeling languages in general, the notion of consistency is slightly different from the classical form of logical consistency. That is, generally from a logical point of view a knowledge base K is considered inconsistent only if we can classically derive a contradiction from it; in DLs that corresponds to saying that K j= > v ?, i.e. every concept in the knowledge base results empty. Instead, dealing with conceptual modeling schemas we generally desire that our model satisfies a stronger form of consistency constraint, that is, we want that none of the classes present in the schema are forced to be empty.
Definition 2 (Strong consistency). A TBox T is strongly consistent if none of the atomic concepts present in its axioms are forced to be empty, that is, if T 6j= > v :A for every atomic concept A appearing in the inclusion axioms in T .
As seen above, the introduction of defeasible constraints into ORM2zero allows to build schemas that in the standard notation would be considered inconsistent, but that, once introducing the defeasible constraints, allow for an instantiation such that all the classes result non-empty. Hence it is necessary to redefine the notion of consistency check in order to deal with such situations.
Such a consistency check is not problematic, since we can rely on the ranking procedure presented above. Consider a TBox T obtained by an ORM2zero schema, and indicate with C the set of all the atomic concepts used in T . It is sufficient to check the exceptionality ranking of all the concepts in C with respect to T : if a concept C has an exceptionality ranking r(C) = n, with 0 < n < 1, then it represents an atypical situation, an exception, but that is compatible with the information conveyed by the defeasible inclusion axioms. For example, in the above examples the penguins and the top managers would be empty classes in the classical formalization, but using the defeasible approach they result exceptional classes in our schemas, and we can consider them as non-empty classes while still considering the schema as consistent. The only case in which a class has to be considered necessarily empty, is when it has 1 as ranking value: that means that, despite eliminating all the defeasible connections we can, such a concept still results empty. Then, the notion of strong consistency for ORM2zero with defeasible constraints is the following: Definition 3 (Strong consistency with defeasible constraints). A knowledge base K = hT ; Bi is strongly consistent if none of the atomic concepts present in its axioms are forced to be empty, that is, if r(A) 6= 1 for every atomic concept A appearing in the inclusion axioms in K.
Given a defeasible ORM2zeroschema , eliminate from it all the defeasible constraints (call strict the resulting schema). From the procedures defined above, it is immediate to see that if strict is a strongly inconsistent ORM2zeroschema, in the ‘classical’ sense, then is a strongly inconsistent defeasible schema: simply, if the negation of a concept is forced by the strict part of a schema, it will be necessarily forced at each ranking level, resulting in a ranking value of 1.
10
On the other hand, there can be also strongly inconsistent defeasible schemas in which inconsistency depends not only on the strict part of the schema, but also on the defeasible part. For example, the schema in figure 4 is inconsistent, since the class A results to have a ranking value of 1 (the schema declares that the class A is directly connected to two incompatible concepts). Now, we can check the results of the defined procedure in the examples presented.
Example 5. Consider example 3. From the translation of the defeasible form of the schema we conclude that the axiom Penguin v NonFlyingObject has rank 1, while Bird v WingyObject and Bird v FlyingObject have rank 0, that means that we end up with two default concepts: – – 0 := dfPenguin 1 := Penguin
NonFlyingObject; Bird NonFlyingObject
WingyObject; Bird
FlyingObjectg;
We can derive the same kind of conclusions as in example 2, and again we can see the limits of the rational closure, since we cannot derive the desirable conclusion that Penguinj WingyObject. Example 6. Consider the knowledge base obtained in the example 4. We have only a defeasible inclusion axiom Employee < 9f1 :WorksFor, and, since Employee does not turn out to be an exceptional concept, we end up with a single default concept in B: – 0 := fEmployee
9f1 :WorksForg;
Since TopManager is not consistent with all the strict information contained in the schema plus 0, we cannot associate 0 to TopManager and, despite we have the information that for non-exceptional cases an employee works for a project, we are not forced to conclude that for the exceptional class of the top managers. 6
Conclusions and further work In this paper we have presented a way to implement a form of defeasible reasoning into the ORM2 formalism. Exploiting the possibility of encoding ORM2zero, that represents a big portion of the ORM2 language, into the description logic ALCQI on one hand, and a procedure appropriate for modeling one of the main forms of nonmonotonic reasoning, i.e. rational closure, into DLs on the other hand, we have defined two new constraints, a defeasible subclass relation and a defeasible mandatory participation, that are appropriate for modeling defeasible information into ORM2, and that, once translated into ALCQI , allow for the use of the procedures characterizing rational closure to reason about the information contained into an ORM2zero schema.
The present proposal deals only with reasoning on the information contained in the
TBox obtained from an ORM2 schema, but, once we have done the rational closure of
the TBox, we can think also of introducing an ABox, that is, the information about a
particular domain of individuals. A first proposal in such direction is in [
12 OntoMerge: A System for Merging DL-Lite
Ontologies Zhe Wang1, Kewen Wang2, Yifan Jin2, and Guilin Qi3;4 1 University of Oxford, United Kingdom 2 Gri th University, Australia 3 Southeast University, China 4 State Key Laboratory for Novel Software Technology
Nanjing University, Nanjing, China Abstract. Merging multi-sourced ontologies in a consistent manner is an important and challenging research topic. In this paper, we propose a novel approach for merging DL-LitebNool ontologies by adapting the classical model-based belief merging approach, where the minimality of changes is realised via a semantic notion, model distance. Instead of using classical DL models, which may be in nite structures in general, we de ne our merging operator based on a new semantic characterisation for DL-Lite. We show that subclass relation w.r.t. the result of merging can be checked e ciently via a QBF reduction. We present our system OntoMerge, which e ectively answers subclass queries on the resulting ontology of merging, without rst computing the merging results. Our system can be used for answering subclass queries on multiple ontologies. 1
Introduction
Ontologies are widely used for sharing and reasoning over domain knowledge,
and their underlying formalisms are often description logics (DLs). To e
ectively answer queries, ontologies from heterogeneous sources and contributed
by various authors are often needed. However, ontologies developed by multiple
authors under di erent settings may contain overlapping, con icting and
incoherent domain knowledge. The ultimate goal of ontology merging is to obtain
a single consistent ontology that preserves as much knowledge as possible from
two or more heterogeneous ontologies. This is in contrast to ontology matching
[
Existing merging systems often adopt formula-based approaches to deal with
logical inconsistencies [10; 9; 14]. Most of such approaches can be described as
follows: the system rst combine the ontologies by taking their union; then, if any
inconsistency is detected (through a standard reasoning), it pinpoints the axioms
which (may) cause inconsistency; and nally, remove certain axioms to retain
consistency. However, such an approach is sometimes unsatisfactory because it
is not ne-grained either in the way it measures the minimality of changes, and
thus it is often unclear how close the result of merging is to the source ontologies
semantically; or in the way it resolve inconsistency. In [
On the other hand, model-based merging operators have been intensively
studied in propositional logic, which are syntax-independent and usually satisfy
more rationality postulates than formula-based ones. However, a major
challenge in adapting model-based merging techniques to DLs is that DL models
are generally in nite structures and the number of models of a DL ontology is
in nite. Several notions of model distance are de ned on classical DL models
for ontology revision [
In this paper, we focus on merging ontologies expressed as DL-Lite TBoxes,
which can be also accompanied with the ontology-based data access (OBDA)
framework for data integration [
A New Semantic Characterisation
[
Formally, given a signature S, a DL-LitebNool language has the following syntax R
P j P
S
P j :P
B > j A j > n R C B j :C j C1 u C2 where n 2 SN , A 2 SC and P 2 SR. B is called a basic concept and C is called a general concept. BS denotes the set of basic concepts on S. We write ? for :>, 9R for 1 R, and C1 t C2 for :(:C1 u :C2). Let R+ = P , where P 2 SR, whenever R = P or R = P . A TBox T is a nite set of concept axioms of the form C1 v C2, where C1 and C2 are general concepts. An ABox A is a nite set of membership assertions of the form C(a) or S(a; b), where a; b are individual names. In this paper, an ontology is represented as a DL TBox.
The classical DL semantics are given by models. A TBox T is consistent with an ABox A if T [ A has at least one model. A concept or role is satis able in T if it has a non-empty interpretation in some model of T . A TBox T is coherent if all atomic concepts and atomic roles in T are satis able. Note that a coherent TBox must be consistent. TBox T entails an axiom C v D, written T j= C v D, if all models of T satisfy C v D. Two TBoxes T1; T2 are equivalent, written T1 T2, if they have the same models.
Now, we introduce a semantic characterisation for DL-Lite TBoxes in terms of types. A type BS is a set of basic concepts over S, such that > 2 , and > n R 2 implies > m R 2 for each pair m; n 2 SN with m < n and each (inverse) role R 2 SR [ f P j P 2 SR g. Type satis es basic concept B if B 2 , :C if does not satisfy C, and C1 u C2 if satis es both C1 and C2. Given a TBox T , type satis es T if satis es concept :C1 t C2 for each axiom C1 v C2 in T .
For a TBox T , de ne TM(T ) to be the maximal set of types satisfying the following conditions: (1) all the types in TM(T ) satisfy T ; (2) for each type 2 TM(T ) and each 9R in , there exists a type 0 2 TM(T ) (possibly 0 = ) containing 9R . A type is called a type model (T-model) of T if 2 TM(T ). Note that TM(T ) is uniquely de ned for each TBox T . Note that for a coherent TBox T , TM(T ) is exactly the set of all types satisfying T . Let TM( ) = TM(T1) TM(Tn) for = hT1; : : : ; Tni.
Proposition 1. Given a TBox T , we have the following results: { T is consistent i TM(T ) 6= ;. { For a general concept C, C is satis able wrt T i there exists a T-model in
TM(T ) satisfying C. { For two general concepts C; D, T j= C v D i either TM(T ) = ; or all
T-models in TM(T ) satisfy C v D. { T T 0 i TM(T ) = TM(T 0), for any TBox T 0.
Given a type , an individual a and an ABox A, we say is a type of a w.r.t. A if there is a model I of A such that = fB j aI 2 BI ; B 2 BS g. For example, given A = fA(a); :B(b); C(c)g, type = fA; Bg is a type of a, but not a type of either b or c in A. For convenience, we will say a type of a when the ABox A is clear from the context. Let TMa(A) be the set of all the types of a in A if a occurs in A; and otherwise, TMa(A) be the set of all the types. A set M of T-models satis es an ABox A if there is a type of a in M , i.e., M \ TMa(A) 6= ;, for each individual a in A.
Proposition 2. Given a TBox T and an ABox A, T [ A is consistent i TM(T ) \ TMa(A) 6= ; for each a in A. 3
Merging Operator In this section, we introduce an approach to merging DL-Lite ontologies to obtain a coherent uni ed ontology.
An ontology pro le is of the form = hT1; : : : ; Tni, where Ti is the ontology
from the source n.o. i (1 i n). There are two standard de nitions of integrity
constraints (ICs) in the classical belief change literature [
In classical model-based merging approaches, merging operators are often
de ned by certain notions of model distances [11; 6]. We use S4S0 to denote the
symmetric di erence between two sets S and S0, i.e., S4S0 = (S n S0) [ (S0 n S).
Given a set S and a tuple S = hS1; : : : ; Sni of sets, the distance between S and
S is de ned to be a tuple d(S; S) = hS4S1; : : : ; S4Sni: For two n-element
distances d and d0, d d0 if di d0i for each 1 i n, where di is the i-th element
in d. Given two sets S and S0, de ne (S; S0) = S if S0 is empty, and otherwise,
(S; S0) = f e0 2 S j 9e00 2 S0 s.t. 8e 2 S; 8e0 2 S0; d(e; e0) 6 d(e0; e00) g: In [
Inspired by classical model-based merging, we introduce a merging operator in terms of T-models. For an ontology pro le and an EC Te, we could de ne the T-models of the merging to be a subset of TM(Te) (so that Te is entailed) consisting of those T-models which have minimal distance to , i.e., (TM(Te); TM( )). However, this straightforward adoption does not take the CC into consideration, and the merging result obtained in this way may not be coherent. For example, let T1 = fA v :Bg, T2 = f> v Bg, Te = ;, and Ac = fA(a); B(a)g. Then, (TM(Te); TM(hT1; T2i)) consists of only one type fBg. Clearly, the corresponding TBox fA v ?; > v Bg does not satisfy the CC, and it is not coherent.
Note that in the above example, once the merging result satis es the CC, then it is also coherent, because both concepts A and B are satis able. In general, it is also the case that coherency can be achieved by applying certain CC to merging. We introduce an auxiliary ABox Ay in addition to the initial CC Ac, in which each concept and each role is explicitly asserted with a member. That is, Ay = fA(a) j A 2 SC ; a 2 SI is a fresh individual for Ag [ fP (b; c) j P 2 SR; b; c 2 SI are fresh individuals for P g: As assumed, SI is large enough for us to take these auxiliary individuals. From the de nition of CCs, the merged TBox T must be consistent with all the assertions in Ay, which assures all the concepts and roles in T to be satis able. Based on this observation, we have the following lemma.
Lemma 1. T is coherent i
T [ Ay is consistent for any TBox T .
To ensure the coherence of merging, we only need to include Ay into the CC. utes and values to their respective concept, and also identifies which concepts participate in a relation.
In OeLE, the texts are annotated semiautomatically, meaning that the teacher only needs to manually annotate the fragments unknown to the system or incorrectly tagged. In our system, the natural language processing is done manually for the moment, as GATE does not sufficiently support French (out-of-the-box) for our purposes. Performing automatic French annotation is planned as a future work.
As an example, we use an actual question from a computer algorithms course given
at our university: “Describe Depth-First Search (DFS)”. Table 1 shows the annotation
set (at the end of the NLP phase) of the partial student’s answer: “Depth-First Search
(DFS) is an exhaustive algorithm that explores a graph...” The ideal answer supplied
by the teacher is similarly annotated; however, for every annotated entity, a numerical
value ought to be supplied specifying the relative importance of that entity within the
question.
The grading stage consists of calculating the semantic distance between the
annotation sets (obtained in Section 3.1) of each student’s answer and that of the teacher’s
ideal answer, with respect to the course ontology. Because of space limitations, we
cannot give detailed calculations for the example. The reader is advised to see the full
explanation in the original publication [
The formulas used in [
The constants elements. Also, , , indicate the relative importance of the corresponding and . and (1)
The concept proximity (CP) is calculated using the taxonomy formed in the ontology by the class hierarchy defined in OWL. Note that the <is-a> relation is explicitly added to the course ontology (with the class as domain and the subclass as image) where rdfs:subClassOf is used: <owl:Class rdf:about="DepthFirstSearch">
<rdfs:subClassOf rdf:resource="Algorithm"/> </owl:Class>
If the concepts and have no taxonomic parent (other than the root), this value is zero, otherwise it is defined as such: ( ) | | ( | )| where | ( )| is the number of concepts separating and through the shortest common path through the taxonomic tree, and | | is the total number of concepts in the ontology. A shorter path thus indicates a stronger similarity between the two concepts.
The properties similarity (PS) calculates the similarity between the set of properties associated with and . The properties of a concept c are the union of the set of attributes that have c as domain, and the set of relations that have c as domain or image.
Lastly, ( ) uses the Levenshtein distance between the string representation of concepts and , written below, and is defined as follows: Attribute similarity. The attribute similarity between two attributes concepts is calculated by a similar function: and of two (2) (3) (4) (5) ( ( ( ( ) ) ) | | ) (
) (
) {| | |}| Here also, the non-negative constants , , must add up to 1. The function returns the (most specific) concept which is in the domain of a. The function ( ) is defined as such: that is, the similarity of their value sets. The function the attribute a. returns the image of Relation similarity. The relation similarity between two relations lated in a similar manner: and
is calcu(6) It is required that the sum of the non-negative constants , be 1. The function returns the most specific concept in the domain of r, while returns the most specific concept in the image of r. The concept similarity is calculated twice, to compare the domains of the relations and (obtained by ) and the images of the relations (obtained by ), respectively.
Global evaluation. In order to accomplish the evaluation of a question, each of the
concepts of the student’s answer is associated with the closest concept of the ideal
answer, given that each concept can only be used once. The similarity between each
pair of concepts is then calculated and is multiplied by the relative numerical value of
the concept in the ideal answer. The similarity is then added to the final grade. The
same process is repeated for relations and attributes.
3.3
Our system uses the same grading algorithm as OeLE [
However, this is not appropriate for assessing procedural knowledge in our system. If the above method is applied to evaluate text describing procedural knowledge such as algorithms-related answers, the grade calculation ought to take into account the relative order of a subset of concepts expressing procedural knowledge. Functional concepts. In order to address this issue, we propose to add functional concepts to the course ontology. A functional concept represents a global procedure, a sequence of sub-procedures or individual steps to accomplish a given task.
Let us consider the following example algorithm, DepthFirstSearch, given in pseudocode: procedure DepthFirstSearch
VisitRoot VisitFirstChildNode
VisitOtherSiblings end procedure VisitRoot [...] procedure VisitFirstChildNode [...] procedure VisitOtherSiblings [...]
For every procedure or sub-procedure, we create a corresponding functional concept: DepthFirstSearch, VisitRoot, VisitFirstChildNode, and VisitOtherSiblings. The last three sub-procedures could in turn be further decomposed.
The functional concepts allow for a high-level description of the algorithm and
mask implementation details, which would be difficult to express in the ontology
using relations or attributes. Further decomposition of VisitRoot into individual steps
could be stated in any of the following ways:
DepthFirstSearch <visits> Root [using relation <visits>]
VisitRoot <visits> Root [same relation with a more specific concept]
Root.visited=true [the value of the attribute <visited> becomes true]
Representing functional concepts in OWL. Relationships between functions are
defined as meta-functions in [
The same idea is found in [
In [
Similarly, the working draft: “Time Ontology in OWL” [
In our implementation, the functional concepts and the <is-preceded-by> relation are defined as such in OWL: <owl:Class rdf:about="FunctionalConcept"/> <owl:Class rdf:about="DepthFirstSearch">
<rdfs:subClassOf rdf:resource="FunctionalConcept"/> </owl:Class> <owl:Class rdf:about="VisitRoot">
<rdfs:subClassOf rdf:resource="DepthFirstSearch"/> </owl:Class> <owl:Class rdf:about="VisitFirstChildNode">
<rdfs:subClassOf rdf:resource="DepthFirstSearch"/> </owl:Class>
Note that the <is-achieved-by> relation is implied by the class hierarchy rooted at the concept FunctionalConcept, just as the <is-a> relation is implied by the class hierarchy in OeLE.
For every algorithm, a separate (meta) ontology lists the required orderings specific to that algorithm. Although there exists many algorithms for graph exploration, we only need to define the functional concepts once in the course ontology, and their ordering can then be declared in a separate ontology. For instance, the BreadthFirstSearch algorithm can be defined with the same functional concepts as above, only ordered differently.
For DepthFirstSearch, the meta-ontology is as follows: VisitFirstChildNode <is-preceded-by> VisitRoot VisitOtherSiblings <is-preceded-by> VisitFirstChildNode
Note that the following relation is also inferred by the transitive property: VisitOtherSiblings <is-preceded-by> VisitRoot Grading with functional concepts. In our approach, the question evaluation process remains mostly unchanged. No special treatment is given to the functional concept class hierarchy rooted at the concept FunctionalConcept, even though its implied relation is <is-achieved-by>, rather than the <is-a> relation implied for the other concepts. This takes into account function nesting and composition, while allowing calculating the proximity of the functional concepts.
However, the global evaluation of a student answer R takes into account the algorithm-specific orderings of the meta-ontology. The new evaluation function is given below: ( (7) (8)
The final grade (FG) for the student answer R is proportional to the global
evaluation of the answer, , obtained from Section 3.2. Here, is a constant in the
interval [
It should be noted that if functional concepts in the student’s answer are ordered with the opposite relation (that is, <is-followed-by>), the evaluation algorithm inverts the relation between the functional concepts.
Also, the individual student grades are affected by the number of defined orderings. If there are only a few orderings, as demonstrated below, students are strongly penalized for every mistake. This is also the case with the concept proximity defined in Formula 2, where the number of concepts in the ontology affects students' grades. However, we can assume that the course ontology is fixed during evaluation, and that the students' grades are therefore affected similarly (in a linear fashion). 4
Working Example and Results Using Depth-First Search as an example, we can quantify the effect of the new evaluation function on a student’s answer. To simplify, we omit the conceptual grading of the answer and concentrate on the functional grading. Since the same entities are present in both the student and teacher’s answers, the conceptual grade is 100%. The ideal functional answer could be as follows: “Depth-First Search first visits the root [of a graph], then [recursively] visits its first child node before visiting its other siblings.” Table 2 shows the produced functional concepts. Any permutation of this ideal answer taken as input by the original approach would yield a grade of 100%. Now, consider the following student’s answer: “Depth-First Search visits the root [of a graph], then [recursively] visits its first child node after visiting its other siblings.” Here, “after” inverts the ordering of the two last concepts (highlighted in bold below), yielding the following answer: The student gave here the incorrect ordering: VisitFirstChildNode <is-preceded-by> VisitOtherSiblings However, these two student orderings are correct: VisitFirstChildNode <is-preceded-by> VisitRoot [inferred] VisitOtherSiblings <is-preceded-by> VisitRoot
As stated above, the conceptual grading of this answer, as performed by OeLE, is 100%. By using the new evaluation function (Formula 7), the final grade (FG) becomes: ( ) (9) where the global evaluation (GE) is 100%, the ordering factor (DF) is 66.67%, and the constant is given a value of 1.0. Considering that the ideal answer to this algorithm contains only three orderings for pairs of functional concepts (one is inferred) and that a third is out of order, this low grade seems acceptable, or at least a reasonable improvement over the former grade of 100% that would have been attributed had we only used the conceptual grading system. 5
Conclusion and Future Work
The work presented in this paper adapts the OeLE system to include procedural
knowledge. The example was taken from an algorithms course given at Université de
Moncton. This approach could be used in other domains where procedural knowledge
is central to processing the text. For example, [
The approach put forth in this paper introduces functional concepts to represent procedural knowledge in ontologies. The class hierarchy of functional concepts is considered as a series of instances of the relation <is-achieved-by> instead of <is-a>. For every computer algorithm (or procedure, for other domains), a series of instances of the relation <is-preceded-by> specify an ordering for pairs of functional concepts.
In this paper, the texts were annotated manually. We are considering annotating the French texts semiautomatically as future work. The detection of the orderings (detecting keywords such as “first”, “before”, “after” in the example of Section 4) could also be performed automatically.
In the case where the student answer uses the opposite ordering relation (<isfollowed-by>), the relation between the functional concepts is inverted prior to evaluation. Some more complex answers could require more inversions, for example if the student wrote “X and Y should be done after Z”.
Future work could also consider flow control structures, such as loops or branches, although the textual representation of those structures without proper indentation or braces could be ambiguous. For example, the VisitOtherSiblings functional concept can be decomposed into the following loop: (for every other sibling, VisitNode).
Another idea that could be explored would be to add the notion of recursive procedures, such as Depth-First Search. VisitFirstChildNode and (every VisitNode of) VisitOtherSiblings should include recursive calls. As an ideal answer, the teacher could give either: DFS.isRecursive=true, or VisitFirstChildNode.isRecursive=true and VisitOtherSiblings.isRecursive=true. Depending on the ideal answer given and their own answer, students could be unjustly penalized. 16. Fernández-Breis, J.T., Valencia-García, R., Cañavate- Cañavate, D., Vivancos-Vicente, P.J., Castellanos-Nieves, D. OeLE: Applying ontologies to support the evaluation of open questions-based tests. In: Proceedings of the KCAP’05 WORKSHOP. SW-EL’05: Aplications of Semantic Web Technologies for E-Learning (in conjunction with 3rd International Conference on Knowledge Capture (KCAP’05)), Banff, Canada (2005) 17. Aroyo, L., Dicheva, D.: Courseware authoring tasks ontology. In: Proceedings of the
International Conference on Computers in Education, pp. 1319-1320. (2002) 18. Smith, B., Ceusters W., Klagges, B., Köhler, J., et al.: Relations in biomedical ontologies.
Genome Biology 6(R46) (2005) 19. Schulz, S., Markó, K., Suntisrivaraporn, B. Formal representation of complex SNOMED
CT expressions. BMC Medical Informatics and Decision Making 8(1) (2008) 20. World Wide Web Consortium (W3C), http://www.w3.org/TR/2006/WD-owl-time20060927/, last accessed 2012-11-21.
Short paper: Using Formal Ontologies in the Development of Countermeasures for Military
Aircraft Nelia Lombard1;2, Aurona Gerber2;3, and Alta van der Merwe3
1 DPSS, CSIR nlombard@csir.co.za http://www.csir.co.za 2 CAIR - Centre for AI Research Meraka CSIR and Univerity of Kwazulu-Natal http://www.cair.za.net/ 3 Department of Informatics University of Pretoria, Pretoria http://www.up.ac.za/
South-Africa Abstract. This paper describes the development of an ontology for use in a military simulation system. Within the military, aircraft represent a signi cant investment and these valuable assets need to be protected against various threats. An example of such a threat is shoulder-launched missiles. Such missiles are portable, easy to use and unfortunately, relatively easy to acquire. In order to counter missile attacks, countermeasures are deployed on the aircraft. Such countermeasures are developed, evaluated and deployed with the assistance of modelling and simulation systems. One such system is the Optronic Scene Simulator, an engineering tool that is able to model and evaluate countermeasures in such a way that the results could be used to make recommendations for successful deployment and use.
The use of formal ontologies is no longer a foreign concept in the support of information systems. To assist with the simulations performed in the Optronic Scene Simulator, an ontology, Simtology, was developed. Simtology supports the system in various ways such as providing a shared vocabulary, improving the understanding of the concepts in the environment and adding value by providing functionality that improves integration between system components.
Keywords: Ontology, Countermeasure, Simulation, Design Research
1
Military forces consider aircraft as important and expensive assets often
representing huge investments. The protection of these assets is considered to be a
priority by most countries. Protection is needed from various threats and one of
these threats are attacks through enemy missiles such as surface-to-air missiles,
which are relatively cheap and easy to operate, and in addition, widely
available in current and old war-zone areas [
Simulation systems model real-world objects and simulate them in an
articial world [
At present, various problems are experienced when constructing the input models for CmSim simulations. Because models are used as input into CmSim simulations, it is necessary to ensure that these models are adequate and accurate for useful simulations. The input model is adequate when it captures su cient input variables and context, and a model is accurate when it correctly captures the input variables and relations. It is for example possible to create input models that are syntactically correct, but the interaction between the models are not correctly set up in the simulation and therefore the results have no correlation with the real world. In addition, di erent users with various roles work with the system and it is necessary to acquire a common understanding and vocabulary for the constructs of the models and their characteristics. Furthermore, the creation of reference models for reuse across the user base would ensure better use of resources and time.
When investigating possible technologies that support modelling within
information systems, ontologies and ontology technologies feature extensively. One
of the original de nitions for the term ontology is that by Gruber who de ned an
ontology as a formalisation of a shared conceptualisation [
The remainder of this paper is structured as follow: Section 2 provides some background of the simulation environment and why it was necessary to build an ontology, as well as some background on ontologies. Section 3 discusses the development and nature of Simtology. Sections 4 and 5 discuss the contribution and conclude the paper in addition to discussing future work, as well as possible extensions to the ontology. 2
Background
One of the largest investments in the military of a country is aircraft. Aircraft
is the target of unfriendly forces in order to weaken the military forces of a
country. These attacks include attacks executed by shoulder-launched missiles,
which are portable, easy to use and relatively easy to acquire. In order to counter
these missile attacks, the military deploy various kinds of countermeasures on
aircraft, and these countermeasures are developed, evaluated and deployed with
the assistance of modelling and simulation systems such as the Optronic Scene
Simulator (OSSIM).
CmSim is a software application that is part of the broader Optronic System
Simulation (OSSIM) system [
CmSim is speci cally designed to do countermeasure evaluation for the
protection of military aircraft. Models of the aircraft, the missile, the
countermeasure and the environment are used to construct a scenario that simulates what
will happen in the real world [
In order to construct better input models, it is necessary to improve the understanding of the simulation and the meaning of concepts in the simulation environment. Users of models often does not know what models exist already, to what level the models were constructed, and the scenarios that might be possible in the simulation, and knowledge is not shared between di erent role-players. The simulation practitioner setting up the simulation scenario might not have specialist knowledge of how the models interact, and can set up scenarios that are syntactically correct but do not correlate with the real world scenario. There is therefore a need to capture the specialised knowledge in reference models that could be used before the scenario is fed to the simulation. Figure 2 depicts the di erent role-players that could be involved in the simulation environment.
Fig. 2. Di erent Role-players Involved in a Simulation Environment
In order to address the above mentioned needs, we initiated a project based
following the guidelines of design science research (DSR) [
Ontologies and Ontology Tools
The origins of the term ontology could be traced to the philosophers of the
ancient world who analysed objects in the world and study their existence [
From the characteristics listed above it is possible to argue that an ontology
may be a solution to the problems experienced in OSSIM simulations. Formal
ontologies are represented in a speci c formal knowledge representation language
[
Ontology Use in Modelling, Simulation and Military Systems
Within computing, modelling and simulation are used to build a representation
of the real world and simulate the behaviour of objects presented in the models
[
Military systems and the knowledge captured therein are complex and
often consist of layered information from di erent sources. To support this view,
Clausewitz, in his book, On War, wrote about military information as follow
[
Furthermore, Mandrick discussed the use of ontologies to model information
in the military environment. According to Mandrick, ontologies in the military
must adhere to the same requirements as ontologies in other domains, as
described in Section 2.2. Important aspects to highlight is the ability of the ontology
to provide a common vocabulary between planners, operators and commanders
in the di erent military communities [
At present the adoption of ontologies in the military domain is primarily for
support of command and control in the battle eld, as well as the management of
assets and the sharing of knowledge[
Simtology
The development of Simtology was in response to the identi ed needs when
using the Optronic Scene Simulator (OSSIM) [
The Design and Development Process
The research design adopted for the development of Simtology, was Design
Research (DSR). DSR is a research methodology for the design and construction
of computing artefacts through the use of rigour (the use of fundamental
knowledge) and relevance (basing the development of the artefact on real needs) [
Awareness and Suggestion The rst steps in the design research process is awareness of the problem and proposing possible suggestions for a solution. The following list summaries the issues and needs in the simulation system as discussed in Section 2.1 that created awareness of the problem: { Di erent role-players: There are developers, model builders and users involved in the system. Inconsistencies in the terminology used between different users often led to frustration and wrong use of concepts. There is lack of a common vocabulary that is shared by everyone involved in building and using the system. { Model complexity: One of the main characteristics is the ability of the system to execute models at di erent levels of detail. This poses a problem to users, when to know at which level of detail a model is implemented at. { Reference models: Speci c users that only interact with the system at a certain level, need more technical insight into model detail to know what is available in the system. This means that reference models are required that can de ne domain-speci c concepts to these users. { Model Interaction: A simulation consists of a scenario that is built up from interacting models. The models interact using a set of rules but there is currently no rules that verify model behaviour when a scenario are constructed.
Previous research e orts in the simulation environment attempted to address the the need for a standard notation for documentation of the simulation models. This proved to be problematic and one of the suggestions for further research was to investigate the use ontologies in the simulation environment. The suggestion according to the DSR process is therefore that a formal ontology is created to address the above mentioned needs for the simulation environment. Fig. 3. The Design Research Process on the left, and the Adaptive Methodology Process on the right 3.3
Development
The ontology was build using the approach followed by the researchers who
develop the Adaptive Methodology [
The prototype is a proof-of-concept and in this project it played an important role to demonstrate the feasibility of the suggested solution. The prototype ontology supported the role of an ontology in the simulation system environment, and supported an ontology as a solution to a shared, common vocabulary. The tools also provided graphical views of the concepts de ned in the ontology. { Development of the Working Ontology: During this phase the prototype ontology was expanded by adding concepts from the domain not previously included in the ontology, as well as developing new functionality. The working ontology contains a full set of domain concepts that describe the simulation models and model properties and is called Simtology. The next section describes Simtology in more detail, as well as how Simtology is used in CmSim. 3.4
Description of Simtology To do a simulation in CmSim, a scenario must be set up to act as input to the simulation. The scenario consists of various con guration les but the main le is the scenario le itself, which contains links to all other les necessary to describe a scenario and the components in it. Although the prototype already contained enough information to set up basic scenarios, Simtology contains all the concepts in the domain of CmSim.
The rst task was thus to expand the prototype to present not only the basic objects, but all the possible objects in the CmSim domain. The classes and properties were expanded. The following list describes the concepts and properties de ned in Simtology.
{ Concepts: In Simtology, an example of a concept representing all the individual aircrafts modelled in the simulation environment, is Aircraft. Figure 4 depicts an extract of the top-level concepts de ned in Simtology, where the concepts were selected to present those in a simulation scenario. The main concepts in Simtology are the Moving, Observer and Scenario concepts. The choice of concepts relied heavily on the structure of the simulation con guration les. Therefore objects of type Moving have speci c behaviour in the simulation and belong together in a concept. { Individuals: Individuals are asserted to be instances of speci c concepts.
Speci c scenarios can be build by choosing individuals from the ontology and thus creating an individual scenario.
ScenarioC130 is an individual of the Scenario concept that uses a speci c type of aircraft. { Object Properties: Object properties are used to link individuals to each other. In Simtology, a scenario must have a clock object, so having a clock object is an object property of the scenario concept. The name of the property is \hasClock\ and links an individual of class Clock to an individual from class Scenario.
In Simtology the main object properties belong to a scenario. The following properties are su cient to denote a valid scenario that can run in a simulation: ScenarioC130 hasClock Clock10ms ScenarioC130 hasTerrain TerrainBeachFynbos ScenarioC130 hasMoving C130Flying120knots ScenarioC130 hasObserver SAMTypeA ScenarioC130 hasAtmosphere MidLatitudeSummer { Data Properties: Data properties were added to Simtology to add data to individuals. Examples of data properties are geometric locations of moving objects, or data belonging to the class Clock, as depicted below: Clock10ms hasInterval 10ms and Clock10ms hasStopTime 10sec Functionality: A scenario can be complex and rules were built in to ensure that a valid scenario is constructed, for instance only certain types of ares can be used as a valid countermeasure on a speci c aircraft. After building the scenario in the ontology, the scenario can be processed by a reasoner. The reasoners are used to compute the inferred ontology class hierarchy and to do consistency checking after a scenario is created.
Additional functionalities were developed for use with Simtology such as the integration of the ontology with the graphical user interface (GUI) used to set up the simulation. The ontology is used to populate the elements in the interface, resulting in several advantages such as that only one source of simulation information has to be maintained, as well as that the ontology can be used to change the language displayed in the GUI .
Functionalities were also developed to write out scenarios created in the ontology to les that can act as input to the simulation. This made it possible that a scenario can rst be checked for logical correctness before it is run in the simulation. Modelling errors not handled by the simulation software are handled early in the simulation process by using the reasoning technology in the ontology. By having a scenario de ned in the ontology, it is possible to export a high-level description of a scenario and its components to be used for reporting and documentation of simulation studies.
Testing of Simtology Testing the ontology was an important step towards creating a useful Simtology. When an ontology is small with a few concepts, it is easier to identify modelling problems but when there are large numbers of concepts with complex relationships, it is important to test the ontology regularly in order to avoid inconsistencies immediately and eliminate rework. During ontology veri cation the focus was mainly to ensure that the ontology was built correctly and that the ontology concepts match the domain it represents. The test phase of the ontology is part of the adaptive methodology process and this phase complements the evaluation phase of the design research process. 4
Evaluation In Section 3.2, the simulation system environment was discussed. In order to evaluate the use of Simtology in the simulation system and the contribution it has for the improvement of the environment, the issues mentioned in Section 3.2 are used as evaluation criteria. The identi ed issues are 1) di erent users; 2) model complexity; 3) reference models; and 4) model interaction. When evaluated against the identi ed issues, Simtology provided the necessary solutions. { Di erent users: Simtology provided a common, shared 'language' to assist with eliminating ambiguities and the inconsistent use of terminology by the di erent users of the system. The feedback by all concerned users was positive. An example of how Simtology assisted with regards to a common understanding is in the use of ambiguous terms. Some terms in the simulation had di erent meanings depending on the user using it and the application it was used for. An example of such a term is countermeasure, which was vague and previously many di erent types of countermeasures existed. In Simtology the concept Countermeasure was de ned in such a way that it can be used as an explanatory tool to illustrate the di erent countermeasures available in the simulation as well as the use of each countermeasure. The Protege editor allows for several ways to communicate the ontology, for example a graphical display of the concepts and the relations in the ontology A visual display of the di erent components in the simulation leads to better communication between all the people involved. { Model complexity: Simtology formally de ned the concepts, properties and individuals necessary for the construction of input models. When a user uses Simtology to construct her input model, the appropriate level of detail and complexity of the input models are speci ed. { Reference models: Simtology provides a reference model for all the different users of the system to create their speci c input models from. After introducing Simtology, very few problems were experienced by users when constructing simulation models because Simtology acted as a reference model informed their speci c model design. { Model Interaction: A simulation consists of a scenario that is build up from interacting models. Simtology provides a common shared language to be used in the simulation environment for both users and when interacting with other applications. The de nitions of concepts in the system are kept in Simtology and made available to applications in the environment such as the Graphical User Interface.
As a nal evaluation, the guidelines proposed by Hevner et al. [
Conclusion and Future Work The outcome of the research project was Simtology, a domain ontology for the simulation environment that contains the model information for simulation scenarios. An added bene t was that the process to analyse the contents of the simulation environment to construct the ontology clari ed the knowledge in the domain.
During the construction of Simtology, the following observations were made: { With regards to modelling, it is important to distinguish part-of from subclassof. An aircraft body is part of an aircraft, not part of a speci c type of aircraft. { It is important to correctly model roles. Modelling a missile as an observer in the simulation means that it can never be used in the simulation as an object of type moving. In Simtology, a missile can therefore never be used in a di erent role. { Another important modelling decision has to do with the modelling of individuals vs. concepts. This decision has an impact on how the ontology could ultimately be used. The choice between concept and individual is often contextual and application-dependent but it needs to be evaluated in one of the development cycles. { The development and use of the ontology should be an iterative process. As new functionality is added, it must be tested, used and evaluated. Existing functionality is maintained by making changes where necessary. Proper version control is therefore also necessary when constructing ontologies.
Several advantages of having an ontology in the simulation environment emerged after the ontology was created. The ontology can, for instance, be used in training exercises to show aircraft personnel the technical detail of the countermeasures deployed on the aircraft. Furthermore, the simulation environment is always expanding and improving through the addition of new models, the addition of new properties to existing entities in the system or through the addition of new functionality to entities. Future versions of the ontology need to incorporate these changes and there should therefore always be future expansions to the Simtology ontology. Furthermore, Simtology should ideally be expanded to not only include concepts in CmSim, but also in the Optronic Scene Simulator. One of the planned functions to be developed is to reverse engineer previously run simulations and add the scenario descriptions of those simulations to the ontology.
References 1. Birchenall, R.P., Richardson, M.A., Butters, B., Walmsley, R.: Modelling an infrared man portable air defence system. Infrared Physics & Technology (July 2010) 2. Willers, C., Willers, M.: Ossim: Optronics scene simulator white paper. Technical report, Council for Scienti c and Industrial Research (2011) 3. Gruber, T.R.: A translation approach to portable ontology speci cations. Knowledge Acquisition 5(2) (1993) 199{220 4. Baader, F., Horrocks, I., Sattler, U.: Description logics as ontology languages for the semantic web. In Hutter, D., Stephan, W., eds.: Mechanizing Mathematical Reasoning: Essays in Honor of Jorg H. Siekmann on the Occasion of His 60th Birthday. Volume 2605 of Lecture Notes in Arti cial Intelligence. Springer-Verlag (2005) 228{248 5. Noy, N.F., McGuiness, D.L.: Ontology development 101: A guide to creating your rst ontology. Technical report, Stanford Knowledge Systems Laboratory (2001)