In knowledge engineering, ontology creation, and especially in knowledge-based configuration often used relations are: aggregate relations (has-parts, here called structural relations), specialization relation (is-a), and instantiation (instance-of). A combination of the later is called metaization, which denotes the use of multiple instantiation layers. In this paper, we give examples and use-hints for these relations especially from the configuration point of view.
For configuration-based inference tasks, like constructing a description of a specific car periphery system [Hotz et al., 2006] or drive systems [Ranze et al., 2002], the knowledge of a certain domain is represented with a knowledge-modeling language (KML) which again is interpreted, because of a defined semantic, through a knowledge-based system or configurator [Arlt et al., 1999; Gu¨nter and Hotz, 1999]. Examples for those KMLs are the Web-Ontology Language (OWL) and the Component Description Language (CDL); further languages are e.g. described in [van Harmelen et al., 2007]. KMLs typically provide concepts or classes gathering all properties, a certain set of domain objects has, under a unique name. With concepts and instances a strict separation into two layers is made: a domain model (or ontology) which covers the knowledge of a certain domain (abbr. layerD) and a system model (or configuration) which covers the knowledge of a concrete system or product of the domain (abbr. layerS ).
Properties of a concept that map to primitive data types, like intervals, values sets (enumerations), or constant values, are called parameters. Properties that map to other concepts or to instances are called relations. KMLs provide structural, specialization, and instantiation as typical relations. A specialization relation relates a superconcept to a subconcept, where the later inherits the properties of the first. This relation (also called is-a relation) forms a specialization hierarchy or lattice, if a concept has more than one superconcept. The structural relation is given between a concept c and several other concepts r, which are called relative concepts. With structural relations a compositional hierarchy based on the has-parts relation can be modeled as well as other structural relationships. Instances are instantiations of concepts and represent concrete domain objects (instance-of).
Additionally to concepts, instances, and their relations, constraints provide model facilities to express n-ary relationships between properties of concepts [John, 2002; Gelle and Faltings, 2003]. Constraints can represent restrictions between properties like arithmetic relations or restrictions on structural relations (e.g. ensuring existence of certain instances). Especially constraints on structural relations extend typical constraint technology, which is based on primitive data types like numbers or strings [Hotz, 2009b].
In this paper, the use of structuralization, specialization,
and instantiation are discussed. Even those relations are
quite well-known they are sometimes confounded.
Furthermore, when used with more than the two mentioned
domain and system layers
In the following, we first consider all relations in more depth and give examples of their use (Section 2 and Section 3). Afterward, we discuss metaization and its use for configuration (Section 4). We end with a short discussion on related work and a conclusion. 2
As already elaborated in [Hotz, 2009a] configuration can be considered as model construction, because a description of a certain system (a configuration) is constructed by a configurator. Furthermore, [Hotz, 2009a] emphasizes to consider the has-parts relation as a has relation that may be used for diverse aspects like has-Realizations or has-Features in software-intensive systems. For the typical use, a structural relation represents a compositional relation. In this case, between c and its relatives r, c denotes the aggregates and r denotes the parts. The underlying structural relation is used by configurators to construct the description and thus are the motor of configuration. Depending on what instances (of c or r) exist first, instances of the related concepts are created; e.g. this enables reasoning from the aggregate to the parts or contrariwise, from the parts to the aggregate. This semantic holds for every structural relation. Thus, introducing several -is Context of -has Context test this characteristic. Thus, it is tested if an instance of c is also reasonably an instance of s. If it is false the knowledge -has Hardware engineer must not use a specialization but e.g. instantiation, because c and s are probably on different layers. structural relations enables the use of adequate domain names like has-Features or has-Realizations, and thus to facilitate maintenance.
Figure 1 pictures an upper-model for software-intensive
systems
A concept describes a set of instances. The specialization
relation (or subsumption or is-a relation) between two
concepts c and s describes a subset relation, i.e. the set of
instances of concept c is a subset of the set of instances of its
superconcept s
An example for this situation is shown in Figure 2; it presents the confounded usage of specialization and instantiation relations in the aforesaid modeling of softwareintensive systems domain (SiS) (Section 2). The system model layer (SiSS ) covers specific individuals, here the Motion Detection Software. This object is an instance of Software (SiSD) but no instance of Compilable Concept. Compilable Concept denotes a specific kind of concept (thus a specific description of instances) that can be compiled. Thus, in the “bad” use, Motion Detection Software is incorrectly considered as a concept, i.e. as a description of instances. Instead it is an instance (here of Software), thus a specific domain object.
When a concept s is specialized to c all properties of s are inherited by c. Furthermore, the properties defined in c that are also defined in s must have more special property values than those in s. For checking this strict specialization, the subset semantic is defined for all primitive data types and the structural relation [Hotz, 2009b]. Thus, the specialization relation is used for structuring the space of needed concepts for representing domain knowledge.
By the time a concept is instantiated, properties of the created instance are initialized by values or value ranges specified in the concept. Thus, the concept determines the structure of the instance (i.e. the properties). In this sense, a concept says something about its instances, i.e. a concept is on a different layer than its instances. By reducing the value ranges according to user decisions or constraint computations the configurator subsequently creates a specific description consisting of instances. 4
For structuralization and specialization, the involved concepts
are on one layer. However, for instantiation and
metaization they are on different layers. By instantiating a concept
one instance is created, i.e. a step from a set of instances
to an individual element of this set is performed. If this
step is cascadized, a concept c can be considered as an
instance of another concept cm, i.e. a step from a set of
concepts to one specific concept is performed. The concept cm
is on a further layer. Figure 3 demonstrates this situation.
The concept Feature is an instance of Abstract Concept
which is a specialization of concept-m. All concepts on
the metalayer CDLM represent the modeling facilities of
CDL, describing the concepts and relations of CDL.
Concept Artefact is a typical CDL concept (it is an instance of
concept-m) and the relation has-Realization is a
structural relation (represented by instantiating the CDLM
concept relation-descriptor-m)
MM
Figure 4 presents the enhancement of Figure 1 by the additional layer SiSM . SiSM describes the SiSD layer concepts Feature, Software, and Hardware as Abstract Concept, Compilable Concept, and Manufacturable Concept, respectively. Thus, it is a domain dependent extensions of CDLM .
By doing so, constraints on concepts of SiSD can be expressed. For example a constraint represents that each feature should be realizable by an artefact. A constraint can check that each feature (a subconcept of Feature) should have a structural relation has-Realization to a subconcept of Artefact. These kinds of constraints may be hard to define, because typically they are not related to one specific concept but to several. Still, such constraints are usually part of some modeling guidelines.1
In [Hotz and von Riegen, 2010b; 2010a], we introduce the Reasoning Driven Architecture (RDA) that allows the implementation of metalayers by using a configuration system on each layer. By doing so, each layer can be seen as a knowledge-based system that says something about the layer below. In the case of RDA, SiSD contains the knowledge of domain objects, which again are represented on SiSS . By introducing the metalayer SiSM , knowledge about knowledge is made explicit, i.e. knowledge about the knowledge of domain objects. This enables the use of reasoning techniques for each layer, not only for the domain and system layers as it is typically the case in knowledge-based systems. The central point of such an implementation is a mapping between instances on one layer to concepts on the next lower layer (see Figure 5 and [Hotz and von Riegen, 2010a] for a map1The SiSMM layer has been omitted because no modeling is required here. s conmcept- t-cepm rcupeon -sha
Realizable
Concept Compilable Concept Software
Car Pre Crash Detection ping for CDL and [Tran et al., 2008] for mapping for OWL or [Bateman et al., 2009]). Metalayers allow for handling (meta) tasks and services. For example, [Tran et al., 2008] proposes to provide statistics about the model (e.g. retrieve all knowledge elements about Pre Crash Detection). With a metalayer like provided in Figure 4, during configuration of a softwareintensive system one can call different external mechanisms for each specific metaconcept. For example, if an instance of an instance of Compilable Concept (e.g. an instance of Software) is configured, an external compiler mechanism can be called to realize the software. If an instance of an instance of Manufacturable Concept is configured, the warehouse can be contacted to check if the needed parts for the manufacturing are present. Thus, through the metalayer the actual configuration of a product can be monitored and reasoning on the configuration process can be processed. 5
The modeling approach, especially metaization [Strahringer, 1998], has similarities to the Model-Driven Architecture [Miller and Mukerji, 2003; Ku¨hne, 2006; Atkinson and Ku¨hne, 2003; Hotz and von Riegen, 2010a], because of the explicitation of several layers. However, the introduction of reasoning systems for each layer allows the direct usage of existing reasoners for inferring on metalayers.
Metaization as such is less considered in knowledge-based configuration. However, especially when learning methods, i.e. automated knowledge engineering, has to be used in changing environments, the automated monitoring of KBs becomes crucial and is conceivable with the presented techniques. 6
In this paper, we state the differences of the main relations for modeling configuration knowledge, i.e. specialization, instantiation, and structuralization. By introducing and clarifying the use of instantiation on several metalayers, we open up a further modeling facility and sketch first usage of this metaization technique for knowledge-based configuration. In (individual :name CompilableEntity-1 :has-superconcept-m CompilableEntity-2 :domain-name “Software”) (individual :name CompilableEntity-2 :domain-name “MotionDetectionSoftware” :is-subconcept-of-m CompilableEntity-1 :has-relations relation-descriptor-m-2) (individual :name relation-descriptor-m-1 :domain-name “has-Realization” :relation-of-m AbstractEntity-2 :has-left-side structural-spec-1) upcoming work, we will apply these techniques in learning environments in the field of robot vision.