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 Ontology 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.
an overview and allow separate developments (“divide and conquer”), when we
consider large ontologies. For example, the “hyper-ontology” [
Standard OWL [
We extend ontologies to Generic Ontologies, and DOL to Generic DOL (Sect. 3), to allow easy reuse of ontologies without cumbersome renaming.
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. 1 ontology VSet2 =
Class: Val 3 Class: Val0 SubClassOf: Val
EquivalentTo: {VAL_Val0} 5 Class: Val1 SubClassOf: Val
EquivalentTo: {VAL_Val1} 7 ObjectProperty: greater_Val
Characteristics: Transitive 9 Domain: Val Range: Val
Individual: VAL_Val0 Types: Val0 11 Individual: VAL_Val1 Types: Val1 11
Facts: greater_Val VAL_Val0 13 end 2 4 ontology VSet3 = VSet2 and
VSet2 with Val0 |-> Val1,
Val1 |-> Val2, VAL_Val0 |-> VAL_Val1,
VAL_Val1 |-> VAL_Val2 6 end 1 ontology VSet3Exp =
Class: Val 3 Class: Val0 SubClassOf: Val
EquivalentTo: {VAL_Val0} 5 Class: Val1 SubClassOf: Val
EquivalentTo: {VAL_Val1} 7 Class: Val2 SubClassOf: Val
EquivalentTo: {VAL_Val2} 9 ObjectProperty: greater_Val
Characteristics: Transitive Domain: Val Range: Val
Individual: VAL_Val0 Types: Val0 13 Individual: VAL_Val1 Types: Val1
Facts: greater_Val VAL_Val0 15 Individual: VAL_Val2 Types: Val2
Facts: greater_Val VAL_Val1 17 end
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 [
Such a “fine” structuring is a form of structured reuse. It avoids multiple developments and error-prone copies: later changes to an original are often mistakenly omitted in copies, or erroneous when replaying a slight adaptation.
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 individual 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.
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
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 [
The Heterogeneous Tool Set, Hets [
We propose the language Generic DOL, GDOL, which extends DOL by a parameterization 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
Generics (first introduced in ADA [
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 11 13 15 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
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. Sometimes 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.
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.
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 instantiation, 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 considerably; 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 parameter to argument.
ValSet4 is structured: ValSetInitial is the base for a generic extension, ValSetStep, 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. 10 12
ontology ValSet4 2 [Class: Val]
[Class: Val0][Class: Val1] 4 [Class: Val2][Class: Val3]
= ValSetInitial 6 [Class: Val][Class: Val0]
and ValSetStep[Class: Val] 8 [Class: Val0][Class: Val1] and ValSetStep[Class: Val]
[Class: Val1][Class: Val2] and ValSetStep[Class: Val]
[Class: Val2][Class: Val3] and Class: Val
DisjointUnionOf:
Val0, Val1, Val2, Val3 14 16 end
ontology Significance 2 = ValSet4
[Class: Significance] 4 [Class: 0-Insignificant]
[Class: 1-Subordinate] 6 [Class: 2-Essential]
[Class: 3-Dominant] 8 end 1 ontology ValSetInitial
[Class: Val] [Class: Val0] 3 = Class: Val
Class: Val0 SubClassOf: Val 5 EquivalentTo: {VAL[Val0]}
Individual: VAL[Val0] 7 Types: Val0
ObjectProperty: greater[Val] 9 Characteristics: Transitive
Domain: Val Range: Val 11 end 1 ontology ValSetStep
[Class: Val] 3 [Class: PrevVal]
[Class: NextVal] 5 = ValSetInitial
[ Class: Val][ Class: PrevVal] 7 and
Class: NextVal SubClassOf: Val 9 EquivalentTo: {VAL[NextVal]}
Individual: VAL[NextVal] 11 Types: NextVal
Facts: greater[Val] VAL[PrevVal] 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 1 ontology OrderRelationExtension
[ OrderRelation] = 3 ObjectProperty: greater_Val
InverseOf: less_Val 5 SubPropertyOf: greaterOrEqual_Val 5
ObjectProperty: less_Val 7 InverseOf: greater_Val
SubPropertyOf: lessOrEqual_Val 9 Characteristics: Transitive
Domain: Val Range: Val 11 ObjectProperty: greaterOrEqual_Val
InverseOf: lessOrEqual_Val 13 Characteristics:
Transitive, Reflexive 15 Domain: Val Range: Val
ObjectProperty: lessOrEqual_Val 17 InverseOf: greaterOrEqual_Val
Characteristics: 19 Transitive, Reflexive
Domain: Val Range: Val 21 end 1 ontology OrderRelation =
Class: Val 3 ObjectProperty: greater_Val
Characteristics: Transitive
Domain: Val Range: Val end 1 ontology ValSet4WithOrderRelations
[ Class: Val] 3 [ Class: Val0][ Class: Val1]
[ Class: Val2][ Class: Val3] 5 = OrderRelationExtension
[ ValSet4 [ Class: Val] 7 [ Class: Val0][ Class: Val1]
[ Class: Val2][ Class: Val3]] 9 end Pre-conditions to an instantiation may be stated by axioms in parameters expressed as whole ontologies, a powerful way to ensure semantic consistency. OrderRelationExtension in Fig. 4 is the extension of greater_Val, an order relation, to its inverse less_Val, the reflexive version greaterOrEqual_Val, and its inverse lessOrEqual_Val. The parameters Val and greater_Val are formulated together 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 receives 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
Most of the existing patterns in the repository for ontology patterns [
ontology TaxonomicExtension 4 [Class: X] [Class: Y:Y] 8
= Class: Y:Y SubClassOf: X <comp> end 6 end
Intermediate Abstraction … <Zn> is-a is-a
is-a <Z1> … <Zn>
<Y> Taxonomic Extension 1 ontology IndividualExtension
[Class: X] 3 = Individual: VAL[X] Types: X
end <X> <Y>
ontology D<irsejl>ointUnionExtension 2 [Class: X
ClCaoslsla:teZra1l ESxutbeCnlsaiosnsOf: X 4 Class: Zn SubClassOf: X]
[Class: Y] <Z> 6 = C<lraigshst:> Y SubClassOf: X
Class: X DisjointUnionOf: Y,Z1,Zn reject DisjointUnionOf: Z1,Zn <X> … <Y>
…
is-a
… <Zn>
GODPs (cf. [
GODPs now receive their semantic foundation from generic ontologies (cf. Sect. 3) and implementation basis from Hets. is-a isi-sa-a is-a is-a
Exampliess-afor GODPs were introducedis-ianforism-aally by diagrams in [
Like the generation of a standard individual in IndividualExtension, this appears 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 corresponding 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 <Z1>,
<Zn> of <X> were stated to be disjoint, we would expect the disjoint union
axiom to be extended as well. When adding another <Y > that should be
included in the union, we have to “repair” the disjoint union axiom to include <Y >
by rejecting the old axiom and introducing the extended one (cf. [
The need for an extension of a previous disjoint union (with associated deletion) 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.
Qualitative Abstraction, Grading <pm> …. <pn>
<rm> …. <rn> <Y>
<q> Simplified Symmetric Configuration <Z> 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, Subordinate, 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 [
[Class: S][Class: T][Class: Val] 3 [Class: Val0][Class: Val1]
[Class: Val2][Class: Val3] 5 = GradedRelations4 [Class: S]
[Class: T][Class: Val] 7 [Class: Val0][Class: Val1]
[Class: Val2][Class: Val3] 9 and
GESubStep 11 [Class: S][Class: T][Class: Val] 11
[Class: Val0][Class: Val1] 13 [ObjectProperty: has[T,Val,Val0]]
and 15 GESubStep
[Class: S][Class: T][Class: Val] 17 [Class: Val1][Class: Val2]
[ObjectProperty: has[T,Val,Val1]] 19 and
GESubFinal 21 [Class: S][Class: T][Class: Val] 8
[Class: Val2][Class: Val3] 23 [ObjectProperty: has[T,Val,Val2]] 10
[ObjectProperty: has[T,Val,Val3]] 25 end 1 ontology GESubStep
[Class: S][Class: T][Class: Val] 3 [Class: Vali][Class: Valj]
[ObjectProperty: has-T-Val-Vali] 5 = ObjectProperty: hasGE[T,Val,Vali]
Domain: S Range: T 7 ObjectProperty: has-T-Val-Vali
SubPropertyOf: hasGE[T,Val,Vali] 9 ObjectProperty: hasGE[T,Val,Valj]
SubPropertyOf: hasGE[T,Val,Vali]
Domain: S Range: T end ontology GESubFinal 2 [Class: S][Class: T][Class: Val]
[Class: Vali][Class: Valj] 4 [ObjectProperty: has-T-Val-Vali]
[ObjectProperty: has-T-Val-Valj] 6 = ObjectProperty: hasGE[T,Val,Vali]
Domain: S Range: T ObjectProperty: has-T-Val-Vali SubPropertyOf: hasGE[T,Val,Vali] ObjectProperty: has-T-Val-Valj
SubPropertyOf: hasGE[T,Val,Vali] 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 GradedRelations. With this encoding we obtain a sheaf of relations <pi>, 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. [
Graded Subsumption. A grading level often corresponds to an appropriate interval of quantitative properties. When the levels are ordered (the intervals 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_Significance_1-Subordinate, has_Ingredient_Significance_2-Essential, etc., an instantiation 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 hasT-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
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 provides 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.
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 structural 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.
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 confined 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
Development Support Tools. We are working on an environment for just
such “straightjacket” GODPs focussing on one GODP as a development
operation at a time while other changes are blocked. A planned user interface, as a
Protégé [
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.
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.
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.
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
(including 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
subtasks, will require further research. Examples are collateral or intermediate
abstraction (cf. [
We envisage development terms with GODP instantiations as development
atoms and operations such as subordinate or collateral composition, where
subdevelopments are initiated while the parent development stays suspended.
Similarly, iteration of developments is intended (cf. development functionals in [
Change Management. The definition of such a Development Ontology, which
is the basis for change management, is fairly well advanced. On the basis of
semantic change impact analysis [
Not only GODPs but whole developments will be re-usable by replay, potentially with adaptation transformations. GDOL extensions. GODPs are presently supported as generic CASL specifications 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 [
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 notation. 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.