Generic Ontologies and Generic Ontology Design Patterns Bernd Krieg-Brückner and Till Mossakowski German Research Center for Artificial Intelligence (DFKI), CPS, BAALL, and Universität Bremen, FB3 Mathematik und Informatik, Bremen, Germany Bernd.Krieg-Brueckner@dfki.de Institute for Intelligent Cooperating Systems, Faculty of Computer Science, Otto-von-Guericke-Universität Magdeburg, Germany till@iks.cs.ovgu.de Abstract. Generic Ontologies are introduced in GDOL, an extension of DOL, the Distributed Ontology, Modeling and Specification Language, and implemented using Hets, the Heterogeneous Tool Set framework. Parameters such as classes, properties, individuals, or whole ontologies may be instantiated with arguments in a host ontology. A Generic On- tology Design Pattern, GODP, defined in GDOL, embodies an ontology development operation and serves as a methodological tool for ontology development. Some non-trivial GODPs are presented for illustration, e.g. for qualitatively graded relations. 1 Introduction Structuring Ontologies In-The-Large is absolutely indispensable to retain an overview and allow separate developments (“divide and conquer”), when we consider large ontologies. For example, the “hyper-ontology” [6, 13] in [12] with more than 25.000 definitions is a network of ontologies, which built on top of each other: foundational so-called “Upper Ontologies”, ontologies in a variety of general domains, and finally ontologies in application domains. Standard OWL [2] allows such a breakdown into separate ontologies with import, although transitive import is not always properly supported by tools. Sometimes, however, we would like to import classes, relations etc. with renam- ing. We will look at support for this by DOL (Sect. 2.1) and Hets (Sect. 2.2). We extend ontologies to Generic Ontologies, and DOL to Generic DOL (Sect. 3), to allow easy reuse of ontologies without cumbersome renaming. Structuring Ontologies In-The-Small is required for sustained confidence in (or better: correctness of) intricate local, reusable development tasks. We take generic ontologies as the basis for Generic Ontology Design Patterns (Sect. 4) embodying development operations. We show how a complex pattern can be structured into sub-patterns, and how iteration can be achieved. This is demonstrated by several non-trivial examples. 2 Bernd Krieg-Brückner and Till Mossakowski 1 ontology VSet2 = 1 ontology VSet3Exp = Class: Val Class: Val 3 Class: Val0 SubClassOf: Val 3 Class: Val0 SubClassOf: Val EquivalentTo: {VAL_Val0} EquivalentTo: {VAL_Val0} 5 Class: Val1 SubClassOf: Val 5 Class: Val1 SubClassOf: Val EquivalentTo: {VAL_Val1} EquivalentTo: {VAL_Val1} 7 ObjectProperty: greater_Val 7 Class: Val2 SubClassOf: Val Characteristics: Transitive EquivalentTo: {VAL_Val2} 9 Domain: Val Range: Val 9 ObjectProperty: greater_Val Individual: VAL_Val0 Types: Val0 Characteristics: Transitive 11 Individual: VAL_Val1 Types: Val1 11 Domain: Val Range: Val Facts: greater_Val VAL_Val0 Individual: VAL_Val0 Types: Val0 13 end 13 Individual: VAL_Val1 Types: Val1 Facts: greater_Val VAL_Val0 ontology VSet3 = VSet2 and 15 Individual: VAL_Val2 Types: Val2 2 VSet2 with Val0 |-> Val1, Facts: greater_Val VAL_Val1 Val1 |-> Val2, 17 end 4 VAL_Val0 |-> VAL_Val1, VAL_Val1 |-> VAL_Val2 6 end Fig. 1. VSet2, VSet3 as renaming of VSet2, and VSet3Exp 2 Structured Semantic Modelling 2.1 Structuring with DOL A repository of general and specific domain ontologies may be utilized very well indeed for a variety of applications. In a special application, these ontologies are often only needed selectively, in specific “views”. The Distributed Ontology, Modeling and Specification Language, DOL, an OMG standard [19, 16, 14], allows, in particular, the definition of a selective view to an ontology upon import, and renaming of entities. Such a “fine” structuring is a form of structured reuse. It avoids multiple devel- opments and error-prone copies: later changes to an original are often mistakenly omitted in copies, or erroneous when replaying a slight adaptation. The “Same Name—Same Thing” Principle is fundamental in DOL, as it is in OWL. Thus a definition may be repeated for a class, say, when adding an additional axiom. Note, however, the use of separate name spaces, see Sect. 3.2. The Value Sets VSet2, VSet3, see Fig. 1, are examples of small ontologies that can be re-used as building blocks in other ontologies. VSet2 contains a class Val with two subclasses Val0 and Val1, with one indi- vidual each. A transitive order relation greater_Val is defined on the individuals. Now VSet3 is formulated in DOL as VSet2 “and” (i.e. united with) a copy of VSet2 “with” renamings; thus it contains 3 classes and 3 values. Generic Ontologies and Generic Ontology Design Patterns 3 Renamings take the form of a sequence of “mapping items” (using the symbol “|->”) from old to new names, e.g. Val0 is renamed as Val1, Val1 as Val2, in the copy. Note that mere textual substitution would be error-prone: the replacements in Fig. 1 would only work in reverse order in this particular case. The expanded result is shown as VSet3Exp. While being more concise, even with this DOL notation, the example will become cumbersome when constructing a value set of 4 or more values, because each time we have to use renaming for yet another copy with distinct names. So we are looking for a means to make a general construction reusable, and to structure it in such a way that iteration becomes easy and obvious to do, i.e. a generic solution (see Sect. 3.2, Fig. 3). 2.2 Heterogeneous Ontologies DOL has been devised for the heterogeneous combination of theories in a variety of logics, dealing with logic morphisms, i.e. functions mapping a theory from one logic into another, and theory morphisms, i.e. functions mapping a specification (e.g. an ontology) into another in the same logic. Actually, the axioms for a total order cannot be defined in OWL-DL, but could be defined in another logic, say FOL or the Common Algebraic Specification Language, CASL [4, 18, 7]. Such a logically complete formulation for a total (or any other desired) order would then accompany the DOL definition (see section 3.2.5 in [14]), to be used for verification purposes with Hets. The Heterogeneous Tool Set, Hets [17], is the implementation basis for DOL and provides and implementation of its semantics. It takes care of proper re- placements; e.g. it generates VSet3Exp. 3 Generic Ontologies in GDOL We propose the language Generic DOL, GDOL, which extends DOL by a param- eterization mechanism for ontologies. Generics in GDOL borrow their semantics from CASL’s generic specification mechanism. The syntax for OWL in GDOL is presently Manchester Syntax, extended by Parameterized Names (cf. Sect. 3.2). 3.1 Generic Ontologies Generics (first introduced in ADA [10]) are not just macros. Their most impor- tant aspect is that all parameters are fully typed items, and argument types are checked against parameter types. Moreover, generics are closed: all free names in the body come from imports, or are bound as parameters. When parameter to argument substitutions are interpreted in the context of the instantiation, frustrating name clashes in the context of the instantiation are thus avoided. Parameters in CASL or GDOL may be any items in the signature of a theory, or whole theories. Thus the parameter of a generic ontology may not only be a class, relation, or individual, it may be a whole ontology with specific abstract 4 Bernd Krieg-Brückner and Till Mossakowski 1 ontology List [Class: Item] = ontology List_NumExp = Class: EmptyList[Item] 2 Class: Num 3 SubClassOf: List[Item] Class: EmptyList_Num Class: NEList[Item] 4 SubClassOf: List_Num 5 SubClassOf: List[Item] Class: NEList_Num Class: List[Item] 6 SubClassOf: List_Num 7 DisjointUnionOf: Class: List_Num EmptyList[Item], NEList[Item] 8 DisjointUnionOf: 9 ObjectProperty: first[Item] EmptyList_Num, NEList_Num Characteristics: Functional 10 ObjectProperty: first_Num 11 Domain: NEList[Item] Range: Item Characteristics: Functional ObjectProperty: restList[Item] 12 Domain: NEList_Num Range: Num 13 Characteristics: Functional ObjectProperty: restList_Num Domain: NEList[Item] 14 Characteristics: Functional 15 Range: List[Item] Domain: NEList_Num end 16 Range: List_Num end ontology: List_Num = List[Class: Num] end Fig. 2. Generic List, Instantiation List_Num, and Expansion List_NumExp properties expressed by axioms. An argument ontology must conform to such a parameter ontology, i.e. the required properties must be satisfied. This concept makes structuring of ontologies in-the-large and in-the-small extremely powerful to capture separate semantic concepts independently, beyond mere modularization and “object-oriented” inheritance. Generic Lists. Lists, sequences, or sets are classic examples of parameterized data structures. Such “containers” are also quite useful in ontologies, likely to be instantiated many times. A list is cast into a generic OWL ontology List in Fig. 2: the class Item is a parameter. In the ontology List_Num, List is then instantiated, where an argument class Num is provided for the parameter Item; cf. also the expansion List_NumExp. This way, different instantiations, say List_Num and List_Person, may coexist, since classes and relations such as first_Num and first_Person are differentiated. 3.2 Pragmatic Naming in GDOL Inherited Name Spaces. DOL/GDOL supports declaration of prefixes that can be used for the abbreviation of URLs in much the same way as OWL does. Each ontology, and hence each argument of an instantiation of a generic ontology, carries its own set of prefixes, possibly distinct. The default prefix of the body of a GODP is set by the instantiation. Some- times an item in the body is closely related to a parameter and should in fact inherit the name space of the argument in an instantiation. Generic Ontologies and Generic Ontology Design Patterns 5 For example in TaxonomicExtension (Fig. 5), X is interpreted with the default prefix of the instantiation, whereas Y might be intended to reside in a different name space; this decision is made when the argument for Y is provided in the instantiation. Thus X gets the default prefix, and Y its own prefix, denoted Y:Y. For better readability, we drop the definition of the default prefix, or other prefixes (given in Fig. 5), in the presentation of the other examples in this paper. Parameterized Names and Stratified Names. Names of new items are often related to (“dependent on”) names of parameters. To avoid renaming and extra parameters, we use the construct of compound names in CASL to introduce Parameterized Names for use in ontologies. As in the CASL notation, Parameterized Names use brackets “[” and “]” around constituent names, and comma “,” as separator. When parameters are substituted by arguments in the expansion of an instan- tiation, the constituent names are substituted by the corresponding argument names, and “[” and “,” are replaced by “_” (the trailing “]” is dropped). The resulting Stratified Names are thus expressed in legal OWL notation, and all OWL-related tools can be used on instantiated generics. Parameterized Names in List allow a compact notation (Fig. 2): just the parameter class Item needs to be instantiated with an argument. The new classes, relations etc. are expressed as parameterized names such as List[Item], first[Item], and corresponding stratified names such as List_Num, first_Num are generated by Hets, supplying a fresh name for each expanded instantiation. Thus the required parameter definitions and instantiations are reduced con- siderably; if parameterized names were not available, all these names would have to be supplied as extra parameters (and arguments!), and generic instantiation would be quite cumbersome and not very different from renaming. Generic Value Sets. While VSet2 (see Sect. 2.1) is not per se generic, it is made to be so as ValSet4, see Fig. 3, to provide new names for parameters Val, Val0, Val1, etc., such that a new instance with different names is created for each instantiation. Note that we use multiple parameters, each consisting of a single class. The advantage is that we can write instantiations similarly, with one argument each, avoiding the need to rename, i.e. explicitly give a fitting morphism from param- eter to argument. ValSet4 is structured: ValSetInitial is the base for a generic extension, ValSet- Step, which adds another value class and individual to the set, and the order. This extension may be iterated: in ValSet4, ValSetStep is instantiated 3 times, providing a total of 4 values Val0 to Val3. In a final phase, a disjointness axiom completes ValSet4. Note that the “Same Name—Same Thing” principle ensures that repeated instantiations may speak about the same class (e.g. Val2). In the extension of the instantiation for Significance, duplicates of class definitions, e.g. for 2-Essential, are removed by Hets, cf. Fig. 3. 6 Bernd Krieg-Brückner and Till Mossakowski ontology ValSet4 1 ontology ValSetInitial 2 [Class: Val] [Class: Val] [Class: Val0] [Class: Val0][Class: Val1] 3 = Class: Val 4 [Class: Val2][Class: Val3] Class: Val0 SubClassOf: Val = ValSetInitial 5 EquivalentTo: {VAL[Val0]} 6 [Class: Val][Class: Val0] Individual: VAL[Val0] and ValSetStep[Class: Val] 7 Types: Val0 8 [Class: Val0][Class: Val1] ObjectProperty: greater[Val] and ValSetStep[Class: Val] 9 Characteristics: Transitive 10 [Class: Val1][Class: Val2] Domain: Val Range: Val and ValSetStep[Class: Val] 11 end 12 [Class: Val2][Class: Val3] and Class: Val 1 ontology ValSetStep 14 DisjointUnionOf: [Class: Val] Val0, Val1, Val2, Val3 3 [Class: PrevVal] 16 end [Class: NextVal] 5 = ValSetInitial ontology Significance [ Class: Val][ Class: PrevVal] 2 = ValSet4 7 and [Class: Significance] Class: NextVal SubClassOf: Val 4 [Class: 0-Insignificant] 9 EquivalentTo: {VAL[NextVal]} [Class: 1-Subordinate] Individual: VAL[NextVal] 6 [Class: 2-Essential] 11 Types: NextVal [Class: 3-Dominant] Facts: greater[Val] VAL[PrevVal] 8 end 13 end 1 ontology GradedRelations4Exp = Class: 0-Insignificant SubClassOf: Significance 3 EquivalentTo: {VAL_0-Insignificant} Class: 1-Subordinate SubClassOf: Significance 5 EquivalentTo: {VAL_1-Subordinate} Class: 2-Essential SubClassOf: Significance 7 EquivalentTo: {VAL_2-Essential} Class: 3-Dominant SubClassOf: Significance 9 EquivalentTo: {VAL_3-Dominant} Class: Significance 11 DisjointUnionOf: 0-Insignificant, 1-Subordinate, 2-Essential, 3-Dominant ObjectProperty: greater_Significance Range: Significance 13 Characteristics: Transitive Domain: Significance Individual: VAL_0-Insignificant Types: 0-Insignificant 15 Individual: VAL_1-Subordinate Types: 1-Subordinate Facts: greater_Significance VAL_0-Insignificant 17 Individual: VAL_2-Essential Types: 2-Essential Facts: greater_Significance VAL_1-Subordinate 19 Individual: VAL_3-Dominant Types: 3-Dominant Facts: greater_Significance VAL_2-Essential 21 end Fig. 3. ValSet4, ValSetInitial, ValSetStep, instantiation as Significance and expansion Generic Ontologies and Generic Ontology Design Patterns 7 1 ontology OrderRelationExtension 1 ontology OrderRelation = [ OrderRelation] = Class: Val 3 ObjectProperty: greater_Val 3 ObjectProperty: greater_Val InverseOf: less_Val Characteristics: Transitive 5 SubPropertyOf: greaterOrEqual_Val 5 Domain: Val Range: Val ObjectProperty: less_Val end 7 InverseOf: greater_Val SubPropertyOf: lessOrEqual_Val 1 ontology ValSet4WithOrderRelations 9 Characteristics: Transitive [ Class: Val] Domain: Val Range: Val 3 [ Class: Val0][ Class: Val1] 11 ObjectProperty: greaterOrEqual_Val [ Class: Val2][ Class: Val3] InverseOf: lessOrEqual_Val 5 = OrderRelationExtension 13 Characteristics: [ ValSet4 [ Class: Val] Transitive, Reflexive 7 [ Class: Val0][ Class: Val1] 15 Domain: Val Range: Val [ Class: Val2][ Class: Val3]] ObjectProperty: lessOrEqual_Val 9 end 17 InverseOf: greaterOrEqual_Val Characteristics: 19 Transitive, Reflexive Domain: Val Range: Val 21 end Fig. 4. OrderRelationExtension; composition with ValSet4 to ValSet4WithOrderRelations 3.3 Pre-conditions in Ontology Parameters Pre-conditions to an instantiation may be stated by axioms in parameters ex- pressed as whole ontologies, a powerful way to ensure semantic consistency. OrderRelationExtension in Fig. 4 is the extension of greater_Val, an order re- lation, to its inverse less_Val, the reflexive version greaterOrEqual_Val, and its inverse lessOrEqual_Val. The parameters Val and greater_Val are formulated to- gether as an ontology parameter OrderRelation. This way, the precondition that greater_Val should be transitive, is formulated in it, and will be checked for the argument (for a complete definition of an order relation in DOL cf. Sect. 2.2). In ValSet4WithOrderRelations, the instantiation of OrderRelationExtension re- ceives both the value set Val to be extended, and the order relation greater_Val, i.e. a proper OrderRelation, from nested instantiation of ValSet4. The resulting ontology is, as always, a union of the argument(s) and the (translated) body, thus contains the instantiated ValSet4 plus the extensions. 4 Generic Ontology Design Patterns Most of the existing patterns in the repository for ontology patterns [1] treat Upper Ontologies, or design issues and structuring in specific application do- mains (cf. Content Design Patterns in [9, 20]). Generic Ontology Design Patterns, 8 Bernd Krieg-Brückner and Till Mossakowski … … 1 ontology IndividualExtension [Class: X] 3 = Individual: VAL[X] Types: X is-a is-a is-a is-a end … … ontology DisjointUnionExtension 2 [Class: X Taxonomic Extension Collateral Class: Z1 Extension SubClassOf: X 4 Class: Zn SubClassOf: X] %prefix( : [Class: Y] 2 Y: )% Y SubClassOf: X 6 = Class: ontology TaxonomicExtension Class: X DisjointUnionOf: Y,Z1,Zn 4 [Class: X] [Class: Y:Y] 8 reject DisjointUnionOf: Z1,Zn = Class: Y:Y SubClassOf: X end 6 end Intermediate Abstraction Fig. 5. IndividualExtension, TaxonomicExtension and DisjointUnionExtension GODPs (cf. [12] for a first sketch), are mostly domain independent, universal On- tology Design Patterns according to the classification of [8]. They abstract away from application domains to a generic methodological level, and are then instan- tiated to particular domains as part of an ontology engineering process. A GODP may be a large ontology to be reused, but also a tiny ontology fragment to be composed with others, thus structuring ontologies in-the-large or in-the-small. … … GODPs now receive their semantic foundation from generic ontologies (cf. Sect. 3) and implementation basis from Hets. a is-a is-a is-a is-a is-a is-a is-a is-a is-a Examples for GODPs were introduced informally by diagrams in [12]. We formalize some of them here as examples for GODPs in GDOL/Hets. > … … … Taxonomic Taxonomic Extension. Extension The diagram for a TaxonomicExtension Supplementary Abstraction pattern in Fig. 5 illustrates the introduction of a new class as a subclass of . Like the generation of a standard individual in IndividualExtension, this ap- pears to be an extremely simple pattern, whose effect might just as well be achieved by free editing. However, it stands for a set of GODPs correspond- ing to development operations that rope in free editing and capture it under semantic control in an application context (cf. Sect. 5). Disjoint Union Extension. Moreover, if previously the subclasses , of were stated to be disjoint, we would expect the disjoint union axiom to be extended as well. When adding another that should be in- cluded in the union, we have to “repair” the disjoint union axiom to include by rejecting the old axiom and introducing the extended one (cf. [15]). The need for an extension of a previous disjoint union (with associated dele- tion) is circumvented in the example ValSet4 (Fig. 3) by introducing an explicit completion with a disjoint union of all constituent value classes as a final phase. Generic Ontologies and Generic Ontology Design Patterns 9 …. …. …. Qualitative Abstraction, Grading Simplified Symmetric Configuration ontology GradedRelations4 1 _Significance ontology GradedRels4 2 [Class: S][Class: T][Class: Val] = GradedRelations4 [Class: Val0][Class: Val1] 3 [Class: Ingredient] …. …. …. …. 4 [Class: Val2][Class: Val3] = [Class: Ingredient] ObjectProperty: has[T,Val,Val0] … [Class: Significance] … 5 6 Domain: S Range: T [Class: 0-Insignificant] Up-/Downgrading ObjectProperty: Configuration has[T,Val,Val1] 7 Adaptive [Class: Configuration 1-Subordinate] 8 Domain: S Range: T [Class: 2-Essential] ObjectProperty: has[T,Val,Val2] 9 [Class: 3-Dominant] 10 Domain: S Range: T end ObjectProperty: has[T,Val,Val3] 12 Domain: S Range: T ObjectProperty: has[Val] 14 Domain: T Range: Val end Fig. 6. Qualitative Grading and Configuration patterns, and GradedRelations4 Qualitative Abstraction. To achieve a graded valuation according to some qualitative abstraction of a semantic concept, we might introduce extra valuation domains, e.g. Significance (see Fig. 3), with values such as Insignificant, Subordi- nate, Essential, Dominant, or some other (arbitrarily fine) qualitative metrics; the number of levels depends on the application. To combine a class, say C, with its valuations, resp., we could construct extra combined domains, say C-Insignificant, ... , C-Dominant, one for each domain, or standard individuals for valuation combinations. The general approach in this vein is reification to realize a ternary relation by binary relations. These approaches involve a considerable overhead of introducing extra classes and relations, and are clumsy, barely readable, and ultimately error-prone. Qualitatively Graded Relations have been proposed instead in [12] to encode such valuations. Formally, we use an ordered set (Sect. 3.2) as grading domain. A ternary relation hasTarget with grade value Val1 as third argument is represented by a qualitatively graded relation hasTargetWithGrade_Val1 such that hasTarget(?s,?t,VAL_Val1) ≡ hasTargetWithGrade_Val1(?s,?t) This axiom cannot be expressed in OWL, but defines the proper semantic rela- tionships that may be used for verification in Hets. 10 Bernd Krieg-Brückner and Till Mossakowski 1 ontology GESubsumption4 1 ontology GESubStep [Class: S][Class: T][Class: Val] [Class: S][Class: T][Class: Val] 3 [Class: Val0][Class: Val1] 3 [Class: Vali][Class: Valj] [Class: Val2][Class: Val3] [ObjectProperty: has-T-Val-Vali] 5 = GradedRelations4 [Class: S] 5 = ObjectProperty: hasGE[T,Val,Vali] [Class: T][Class: Val] Domain: S Range: T 7 [Class: Val0][Class: Val1] 7 ObjectProperty: has-T-Val-Vali [Class: Val2][Class: Val3] SubPropertyOf: hasGE[T,Val,Vali] 9 and 9 ObjectProperty: hasGE[T,Val,Valj] GESubStep SubPropertyOf: hasGE[T,Val,Vali] 11 [Class: S][Class: T][Class: Val] 11 Domain: S Range: T [Class: Val0][Class: Val1] end 13 [ObjectProperty: has[T,Val,Val0]] and ontology GESubFinal 15 GESubStep 2 [Class: S][Class: T][Class: Val] [Class: S][Class: T][Class: Val] [Class: Vali][Class: Valj] 17 [Class: Val1][Class: Val2] 4 [ObjectProperty: has-T-Val-Vali] [ObjectProperty: has[T,Val,Val1]] [ObjectProperty: has-T-Val-Valj] 19 and 6 = ObjectProperty: hasGE[T,Val,Vali] GESubFinal Domain: S Range: T 21 [Class: S][Class: T][Class: Val] 8 ObjectProperty: has-T-Val-Vali [Class: Val2][Class: Val3] SubPropertyOf: hasGE[T,Val,Vali] 23 [ObjectProperty: has[T,Val,Val2]] 10 ObjectProperty: has-T-Val-Valj [ObjectProperty: has[T,Val,Val3]] SubPropertyOf: hasGE[T,Val,Vali] 25 end 12 end ontology GESubsumption4_SigExp = 2 Class: Ingredient Class: Significance ObjectProperty: hasGE_Ingredient_Significance_0-Insignificant 4 Domain: Ingredient Range: Ingredient ObjectProperty: hasGE_Ingredient_Significance_1-Subordinate 6 SubPropertyOf: hasGE_Ingredient_Significance_0-Insignificant Domain: Ingredient Range: Ingredient 8 ObjectProperty: hasGE_Ingredient_Significance_2-Essential SubPropertyOf: hasGE_Ingredient_Significance_1-Subordinate 10 Domain: Ingredient Range: Ingredient ObjectProperty: has_Ingredient_Significance_0-Insignificant 12 SubPropertyOf: hasGE_Ingredient_Significance_0-Insignificant Domain: Ingredient Range: Ingredient 14 ObjectProperty: has_Ingredient_Significance_1-Subordinate SubPropertyOf: hasGE_Ingredient_Significance_1-Subordinate 16 Domain: Ingredient Range: Ingredient ObjectProperty: has_Ingredient_Significance_2-Essential 18 SubPropertyOf: hasGE_Ingredient_Significance_2-Essential Domain: Ingredient Range: Ingredient 20 ObjectProperty: has_Ingredient_Significance_3-Dominant SubPropertyOf: hasGE_Ingredient_Significance_2-Essential 22 Domain: Ingredient Range: Ingredient ObjectProperty: has_Val Domain: Ingredient Range: Significance Fig. 7. GESubsumption4, GESubStep, GESubFinal and expansion of instantiation Generic Ontologies and Generic Ontology Design Patterns 11 Generic GradedRelations. With this encoding we obtain a sheaf of relations , one for each qualitative grade i, cf. Fig. 4. Note that GradedRelations4 is appropriate for a grade domain with 4 values; we have to provide an analogous GODP for each number by adding further relations. Graded Configuration can be defined in a similar way (cf. [12]), taking two sheafs of graded relations as parameters. Graded Subsumption. A grading level often corresponds to an appropri- ate interval of quantitative properties. When the levels are ordered (the in- tervals are consecutive), it makes sense to also introduce associated relations corresponding to a greater[Val] ordering (actually a greaterOrEqual[Val] ordering; ValSet4WithOrderRelations could be added if verification is intended). In GESubsumption4, see Fig. 7, this is expressed by subsumption of relations, where a given sheaf of graded relations is a parameter. Whereas an instantiation of GradedRelations4 (Fig. 6) only generates relations such as has_Ingredient_Sig- nificance_1-Subordinate, has_Ingredient_Significance_2-Essential, etc., an instan- tiation of GESubsumption4 additionally yields e.g. a relation hasGE_Ingredient_- Significance_1-Subordinate, which subsumes grades 1-Subordinate, 2-Essential, and 3-Dominant. We obtain the following relation subsumption hierarchy: hasGE_Ingredient_Significance_0-Insignificant has_Ingredient_Significance_0-Insignificant hasGE_Ingredient_Significance_1-Subordinate has_Ingredient_Significance_1-Subordinate hasGE_Ingredient_Significance_2-Essential has_Ingredient_Significance_2-Essential has_Ingredient_Significance_3-Dominant To create this hierarchy in GESubStep, a new GE-relation hasGE[T,Val,Valj] is defined as a subrelation of the previous GE-relation hasGE[T,Val,Vali], and has- T-Val-Vali, passed as a parameter, is also made a subrelation of the previous GE-relation hasGE[T,Val,Vali] (the instantiations are chosen in such a way that j denotes i+1). 5 Conclusion Development Operations with Constrained Focus. A GODP abstracts away from a particular development fragment. As such it embodies an ontology development operation, to be re-used repeatedly in a variety of contexts. While a free development, e.g. in Protégé, allows changes everywhere and cannot guard against erroneous changes in a different part of the hyper-ontology, a GODP pro- vides a constrained focus, a kind of “straightjacket” to allow only this particular development operation. Changes are confined to the effects of an instantiation, no other part of the host ontology is accidentally affected, it is “frozen”. The developers attention is focused on providing appropriate arguments, which are checked for violation of semantic constraints. 12 Bernd Krieg-Brückner and Till Mossakowski Composition of Development Operations is a powerful way to create new GODPs from the repository of generally applicable building blocks, viz. GODPs. We have seen in Fig. 4 that OrderRelationExtension may be instantiated on ValSet4, yielding a new GODP ValSet4WithOrderRelations. Similarly, a combination of initial, iteration step and final sub-GODPs as in ValSet4 (Fig. 3), or GESubsumption4 (Fig. 7) seems to be quite typical for the compilation of larger GODPs from small building blocks. Consistency. A GODP is separately defined from its applications; it can be tested to comply with the intentions of the developer once and for all (i.e. for all instantiations). The semantics of its body is defined w.r.t. its parameters; semantic pre-conditions may be stated by axioms in parameter ontologies. Structural consistency is then ensured in each instantiation by checking struc- tural conformance of arguments, e.g. that an argument of appropriate kind with the resp. name exists (subject to renaming). Semantic consistency is ensured by proving each ontology argument to comply with its parameter, if it contains axioms. Such a proof obligation is generated and managed by Hets. It may be discharged automatically, if it can be reduced to Description Logic, DL, or some other logic for which automatic reasoning is provided by an appropriate reasoner. In fact, every (generic) ontology pattern, e.g. for Order (cf. Sect. 2.2), should be accompanied by a formal definition in CASL, say, if DL is not sufficient, to properly define its semantics and to support a potential verification process. Towards Safer Ontology Development. It cannot be expected that ontolo- gies are ever “complete”; thus the development process and the correctness of changes on the resulting ontologies are a major concern. A GODP, separately defined and verified, is safe insofar as changes are con- fined to the effects of pattern instantiation, checking arguments for violation of semantic constraints; no other part of the host ontology is accidentally affected. The constrained development focus of “straightjacket” GODPs seems to have potential for supporting a safe development process. 6 Ongoing and Future Work Development Support Tools. We are working on an environment for just such “straightjacket” GODPs focussing on one GODP as a development opera- tion at a time while other changes are blocked. A planned user interface, as a Protégé [3] plugin, will take care of smooth interaction with Hets, tracks changes with change management, and provides development control (see below).The vi- sion for the future is that all development will be done this way and free editing is banned. This user interface will be for the semantic modelling expert, who will develop new general GODPs, and the domain expert selecting ready-made interfaces on top of GODPs for specific development tasks in an application domain. Generic Ontologies and Generic Ontology Design Patterns 13 The above experts are allowed to change the modelling level of an ontology; an application interface for an end-user will only be able to browse (with a frozen model), and add or change application-oriented data (i.e. individuals and relating facts), such as person profiles, new recipes, or shopping lists. Compilation of Application-Oriented Patterns. We expect the semantic modelling expert to be able to easily compile specialized domain-oriented GODPs from the repository of GODPs. An extra user-interface might then be added for the domain expert, compiled from a repository of appropriate components, but it is mere “syntactic sugar” (“interface topping”) with its semantics firmly and safely rooted in the GODP framework. Generation of Ontology Components is usually quite cumbersome and error-prone, since code using the OWL-API has to be written and debugged. With GODPs, this process is raised to an appropriate abstraction level (in- cluding potential verification). Only the triggering of the application of a GOPD has to be programmed (to be included in our support tools). The iteration of a GODP application is then easily achieved, possibly by development control (see below). As a simple example consider the generation of a standard individual IndividualExtension (Fig. 5), to be repeated for all classes in a particular context. Development Control for complex development tasks, guiding through sub- tasks, will require further research. Examples are collateral or intermediate ab- straction (cf. [12]), where an ongoing development is temporarily suspended, while another auxiliary development is pursued, and subsequently resumed; in fact, control is alternating between subtasks. We envisage development terms with GODP instantiations as development atoms and operations such as subordinate or collateral composition, where sub- developments are initiated while the parent development stays suspended. Simi- larly, iteration of developments is intended (cf. development functionals in [11]). Development Ontology. Development operations, their parameter profiles and other details will be formalized in a Development Ontology, which is im- ported into an actual development, but does not affect its semantics; links into it act like formal annotations. Of particular interest is the interlinking of the application of a development operation, viz. instantiation of a GODP, to the GODP and the arguments in the instantiation. Change Management. The definition of such a Development Ontology, which is the basis for change management, is fairly well advanced. On the basis of se- mantic change impact analysis [5], development operations will be treated as first class citizens; this will open the possibility for transformations of development terms such as reordering according to algebraic properties. Not only GODPs but whole developments will be re-usable by replay, poten- tially with adaptation transformations. 14 Bernd Krieg-Brückner and Till Mossakowski GDOL extensions. GODPs are presently supported as generic CASL speci- fications in Hets. Generic ontologies are defined as a Generic extension of DOL to GDOL, to be proposed as an extension of the DOL standard (cf. Sect. 2.1). GDOL examples in this paper (available at https://ontohub.org/godp) are confined to extensions of an ontology (actually the vast majority). Deletions of items in GDOL receive their semantics in [15]. In contrast to CASL, where generics are “first order”, we are considering an extension, where separate parameters, which often occur in the examples above, are taken to augment the context one by one; in fact, new generics could be defined from existing ones by partial parameterization (whether one should go all the way to introduce higher-order generics is a different question). This seems to be natural and would simplify some of the examples: e.g., with GESubStepVal = GESubStep[Class: S][Class: T][Class: Val] as a local definition in GESubStep, these parameters are fixed, and the previous instantiations of GESubStep are then reduced to just the remaining arguments, e.g. GESubStepVal[Class: Val0][Class: Val1][ObjectProperty: has[T,Val,Val0]]. We are also contemplating an extension of the syntax for GODPs in GDOL that corresponds to iterations in patterns, denoted e.g. by some elliptical nota- tion. Compare the initial, iteration step and final phases represented by extra component GODPs in Fig. 3 (Sect. 3.2), which suggest an ellipsis in the body of ValSet4 for instantiations of ValSetStep, accompanied by some ellipsis for extra parameters (similarly in Fig. 6 and Fig. 7). Moreover, it would be nice, if Hets would take the type of an argument (as required by the parameter) into account in instantiations; this would eliminate the need for stating such information in the argument and render instantiations considerably more compact: “Class:” could e.g. be deleted everywhere in the body of ValSet4 (Fig. 3), GradedRelations4 (Fig. 6), or GESubsumption4 (Fig. 7), and similarly in the associated instantiations. Acknowledgements. We are very grateful to the reviewers and Serge Autexier, Jens Pelzetter, and Martin Rink for their suggestions and contributions. References 1. Ontology Design Pattern Types, ontologydesignpatterns.org/wiki/OPTypes 2. OWL Web Ontology Language - Use Cases and Requirements - W3C Recommen- dation 10 February 2004, www.w3.org/TR/2004/REC-webont-req-20040210/ 3. Protégé Desktop User Documentation, August 2016, protegewiki.stanford. edu/wiki/ProtegeDesktopUserDocs 4. Astesiano, E., Bidoit, M., Krieg-Brückner, B., Kirchner, H., Mosses, P.D., San- nella, D., Tarlecki, A.: CASL - the Common Algebraic Specification Language. Theoretical Computer Science 286, 153–196 (2002), http://www.cofi.info 5. Autexier, S., Hutter, D., Mossakowski, T.: Change management for heterogeneous development graphs. In: Siegler, S., Wasser, N. (eds.) Verification, Induction, Ter- mination Analysis, Festschrift in honor of Christoph Walther. LNCS, Springer (November 2010) Generic Ontologies and Generic Ontology Design Patterns 15 6. Bateman, J.A., Castro, A., Normann, I., Pera, O., Garcia, L., Villaveces, J.M.: OASIS Common hyper-ontological framework (COF). EU FP7 Project OASIS – Open architecture for Accessible Services Integration and Standardization Deliv- erable D1.2.1, Bremen University, Bremen, Germany (January 2010) 7. Bidoit, M., Mosses, P.D. (eds.): CASL User Manual, LNCS, vol. 2900. Springer, Berlin, Heidelberg (2004) 8. Blomqvist, E., Sandkuhl, K.: Patterns in ontology engineering: Classification of on- tology patterns. In: Chen, C., Filipe, J., Seruca, I., Cordeiro, J. (eds.) ICEIS 2005, Proceedings of the Seventh International Conference on Enterprise Information Systems, Miami, USA, May 25-28, 2005. pp. 413–416 (2005) 9. Gangemi, A.: Ontology design patterns for semantic web content. In: Gil, Y., Motta, E., Benjamins, V.R., Musen, M.A. (eds.) The Semantic Web - ISWC 2005, 4th International Semantic Web Conference, Proceedings. LNCS, vol. 3729, pp. 262–276. Springer (2005) 10. Ichbiah, J., Krieg-Brückner, B., Wichmann, A., Ledgard, H., Heliard, J.C., Abrial, J., Barnes, J., Roubine, O.: Preliminary Ada Reference Manual. ACM SIGPLAN Notices (14:6 Part A) (1979) 11. Krieg-Brückner, B.: Transformational meta program development. In: Broy, M., Wirsing, M. (eds.) Methods of Programming. LNCS, vol. 544, pp. 19–33. Springer, Berlin, Heidelberg (1991) 12. Krieg-Brückner, B.: Generic Ontology Design Patterns: Qualitatively Graded Con- figuration. In: Lehner, F., Fteimi, N. (eds.) KSEM 2016, The 9th International Conference on Knowledge Science, Engineering and Management. Lecture Notes in Artificial Intelligence, vol. 9983, pp. 580–595. Springer International Publishing (2016) 13. Kutz, O., Mossakowski, T., Lücke, D.: Carnap, Goguen, and the Hyperontologies: Logical Pluralism and Heterogeneous Structuring in Ontology Design. Logica Uni- versalis 4(2), 255–333 (2010), special Issue on ‘Is Logic Universal?’ 14. Mossakowski, T., Codescu, M., Neuhaus, F., Kutz, O.: The Distributed Ontology, Modeling and Specification Language – DOL. In: Koslow, A., Buchsbaum, A. (eds.) The Road to Universal Logic, vol. I, pp. 489–520. Birkhäuser (2015) 15. Mossakowski, T., Krieg-Brückner, B.: Partial Pushout Semantics of Generics in GDOL (submitted) 16. Mossakowski, T., Kutz, O., Codescu, M., Lange, C.: The distributed ontology, modeling and specification language. In: Vescovo, C.D., Hahmann, T., Pearce, D., Walther, D. (eds.) WoMo 2013. CEUR-WS online proceedings, vol. 1081 (2013) 17. Mossakowski, T., Maeder, C., Lüttich, K.: The heterogeneous tool set, Hets. In: Grumberg, O., Huth, M. (eds.) Tools and Algorithms for the Construction and Analysis of Systems, 13th International Conference, TACAS 2007, Proceedings. LNCS, vol. 4424, pp. 519–522. Springer (2007) 18. Mosses, P.D. (ed.): CASL Reference Manual, LNCS, vol. 2960. Springer, Berlin, Heidelberg (2004) 19. Object Management Group: The distributed ontology, modeling, and specification language (DOL) (2016), OMG standard available at omg.org/spec/DOL. See also dol-omg.org 20. Presutti, V., Gangemi, A.: Content ontology design patterns as practical building blocks for web ontologies. In: Li, Q., Spaccapietra, S., Yu, E.S.K., Olivé, A. (eds.) Conceptual Modeling - ER 2008, 27th International Conference on Conceptual Modeling, Barcelona, Spain, October 20-24, 2008. Proceedings. LNCS, vol. 5231, pp. 128–141. Springer (2008)