=Paper=
{{Paper
|id=None
|storemode=property
|title=When to use what: Structuralization, Specialization, Instantiation, Metaization - Some Hints for Knowledge Engineers
|pdfUrl=https://ceur-ws.org/Vol-755/paper06.pdf
|volume=Vol-755
|dblpUrl=https://dblp.org/rec/conf/confws/HotzR11
}}
==When to use what: Structuralization, Specialization, Instantiation, Metaization - Some Hints for Knowledge Engineers==
https://ceur-ws.org/Vol-755/paper06.pdf
When to use what: Structuralization, Specialization, Instantiation, Metaization -
Some Hints for Knowledge Engineers
Lothar Hotz, Stephanie von Riegen
Hamburger Informatik Technology Center, Department Informatik, University of Hamburg, Germany
e-mail: {hotz, svriegen}@informatik.uni-hamburg.de.
Abstract has-parts relation can be modeled as well as other struc-
tural relationships. Instances are instantiations of concepts
In knowledge engineering, ontology creation, and represent concrete domain objects (instance-of).
and especially in knowledge-based configura- Additionally to concepts, instances, and their relations,
tion often used relations are: aggregate rela- constraints provide model facilities to express n-ary relation-
tions (has-parts, here called structural relations), ships between properties of concepts [John, 2002; Gelle and
specialization relation (is-a), and instantiation Faltings, 2003]. Constraints can represent restrictions be-
(instance-of). A combination of the later is tween properties like arithmetic relations or restrictions on
called metaization, which denotes the use of mul- structural relations (e.g. ensuring existence of certain in-
tiple instantiation layers. In this paper, we give ex- stances). Especially constraints on structural relations ex-
amples and use-hints for these relations especially tend typical constraint technology, which is based on prim-
from the configuration point of view. itive data types like numbers or strings [Hotz, 2009b].
In this paper, the use of structuralization, specialization,
and instantiation are discussed. Even those relations are
1 Introduction quite well-known they are sometimes confounded. Further-
For configuration-based inference tasks, like constructing a more, when used with more than the two mentioned do-
description of a specific car periphery system [Hotz et al., main and system layers (see [Asikainen and Männistö, 2010;
2006] or drive systems [Ranze et al., 2002], the knowledge Hotz, 2009a]) the instantiation relation is multiply applied,
of a certain domain is represented with a knowledge-modeling which leads to new modeling layers and thus, probably to
language (KML) which again is interpreted, because of a de- modeling difficulties. The creation of such multiple layers is
fined semantic, through a knowledge-based system or config- called metaization [Strahringer, 1998].
urator [Arlt et al., 1999; Günter and Hotz, 1999]. Examples In the following, we first consider all relations in more
for those KMLs are the Web-Ontology Language (OWL) and depth and give examples of their use (Section 2 and Section
the Component Description Language (CDL); further lan- 3). Afterward, we discuss metaization and its use for config-
guages are e.g. described in [van Harmelen et al., 2007]. uration (Section 4). We end with a short discussion on related
KMLs typically provide concepts or classes gathering all work and a conclusion.
properties, a certain set of domain objects has, under a unique
name. With concepts and instances a strict separation into 2 Structuralization
two layers is made: a domain model (or ontology) which cov- As already elaborated in [Hotz, 2009a] configuration can be
ers the knowledge of a certain domain (abbr. layerD ) and a considered as model construction, because a description of a
system model (or configuration) which covers the knowledge certain system (a configuration) is constructed by a configu-
of a concrete system or product of the domain (abbr. layerS ). rator. Furthermore, [Hotz, 2009a] emphasizes to consider the
Properties of a concept that map to primitive data types, has-parts relation as a has relation that may be used for
like intervals, values sets (enumerations), or constant values, diverse aspects like has-Realizations or has-Features
are called parameters. Properties that map to other concepts in software-intensive systems. For the typical use, a structural
or to instances are called relations. KMLs provide structural, relation represents a compositional relation. In this case, be-
specialization, and instantiation as typical relations. A spe- tween c and its relatives r, c denotes the aggregates and r
cialization relation relates a superconcept to a subconcept, denotes the parts. The underlying structural relation is used
where the later inherits the properties of the first. This relation by configurators to construct the description and thus are the
(also called is-a relation) forms a specialization hierarchy motor of configuration. Depending on what instances (of c
or lattice, if a concept has more than one superconcept. The or r) exist first, instances of the related concepts are created;
structural relation is given between a concept c and several e.g. this enables reasoning from the aggregate to the parts or
other concepts r, which are called relative concepts. With contrariwise, from the parts to the aggregate. This semantic
structural relations a compositional hierarchy based on the holds for every structural relation. Thus, introducing several
Feature Space Artefact Space
Thing
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
Context
-is Context of -has Context
Product
-has Hardware
engineer must not use a specialization but e.g. instantiation,
0..*
-is Feature of
1 1..* because c and s are probably on different layers.
-has Feature 1..* 1..* -has Software
Feature
0..* M D S
-realizes
1..* -has Realization
Artefact
1..* Compilable
Artefact
Concept Concept
Hardware Software
Motion
Software Detection
Generalization -is Software of 0..* Software
-is Hardware of 0..*
Compilable
Structural relation with number restriction Concept
Upper Model
Artefact
Domain-specific model
has
Motion
Domain-specific extension of the upper model instance-of
Software Detection
is-a
Software
Figure 1: Extract from an upper-model for modeling
software-intensive systems. Figure 2: Good and bad use of specialization and instantiation
in software-intensive systems.
structural relations enables the use of adequate domain names An example for this situation is shown in Figure 2; it
like has-Features or has-Realizations, and thus to fa- presents the confounded usage of specialization and in-
cilitate maintenance. stantiation relations in the aforesaid modeling of software-
Figure 1 pictures an upper-model for software-intensive intensive systems domain (SiS) (Section 2). The system
systems (UMSiS, [Hotz et al., 2006]). It defines four as- model layer (SiS S ) covers specific individuals, here the
set types (features, context, hardware and software artefacts) Motion Detection Software. This object is an in-
which are common to most application domains of software- stance of Software (SiS D ) but no instance of Compilable
intensive systems (SiS). A product, i.e. the result of the prod- Concept. Compilable Concept denotes a specific kind
uct derivation, contains software and hardware artefacts as of concept (thus a specific description of instances) that can
parts, these together realize particular features. Several struc- be compiled. Thus, in the “bad” use, Motion Detection
tural relations are depicted, like has-Realizations and Software is incorrectly considered as a concept, i.e. as a
has-Feature. When using the upper-model for a specific description of instances. Instead it is an instance (here of
domain, the UMSiS is extended with domain-specific knowl- Software), thus a specific domain object.
edge about hardware and software artefacts, the existing fea- When a concept s is specialized to c all properties of s
tures, relevant context aspects, etc. In the example above, the are inherited by c. Furthermore, the properties defined in c
concepts are organized in different spaces. Each space rep- that are also defined in s must have more special property
resents a specific aspect of the domain and thus each config- values than those in s. For checking this strict specialization,
ured product should have those aspects. Figure 1 provides the the subset semantic is defined for all primitive data types and
example of the feature and artefact aspects in the domain of the structural relation [Hotz, 2009b]. Thus, the specialization
software-intensive systems. Thus, spaces separate concepts relation is used for structuring the space of needed concepts
of one layer. Through this grouping of concepts of one layer for representing domain knowledge.
the configuration model is easier to manage for a knowledge By the time a concept is instantiated, properties of the cre-
engineer. Furthermore, concepts of different spaces are con- ated instance are initialized by values or value ranges speci-
nected by a structural relation. This ensures that a configured fied in the concept. Thus, the concept determines the structure
product finally contains all modeled aspects. In contrast to of the instance (i.e. the properties). In this sense, a concept
this, in Section 3 we will see, how the instantiation relation says something about its instances, i.e. a concept is on a dif-
separates concepts and instances on different layers. ferent layer than its instances. By reducing the value ranges
according to user decisions or constraint computations the
3 Specialization vs. Instantiation configurator subsequently creates a specific description con-
A concept describes a set of instances. The specialization sisting of instances.
relation (or subsumption or is-a relation) between two con-
cepts c and s describes a subset relation, i.e. the set of in- 4 Metaization
stances of concept c is a subset of the set of instances of its For structuralization and specialization, the involved concepts
superconcept s (see also [Brachman, 1983]). Or, as defined are on one layer. However, for instantiation and metaiza-
in ontogenesis.knowledgeblog.org/699: “c is-a tion they are on different layers. By instantiating a concept
s iff: given any i that instantiates c, i instantiates s”. An in- one instance is created, i.e. a step from a set of instances
stance of a class c is always an instance of each superclass s to an individual element of this set is performed. If this
of c. We consider this aspect as the hinting characteristic for step is cascadized, a concept c can be considered as an in-
knowledge engineers: During knowledge modeling one can stance of another concept cm , i.e. a step from a set of con-
try to make a specialization between two domain aspects and cepts to one specific concept is performed. The concept cm
is on a further layer. Figure 3 demonstrates this situation. M D S
The concept Feature is an instance of Abstract Concept
supercon-
concept-
cept-m
has
has-
m instance-of
which is a specialization of concept-m. All concepts on is-a
the metalayer CDLM represent the modeling facilities of
Realizable
CDL, describing the concepts and relations of CDL. Con- Concept
Product Car
Feature
cept Artefact is a typical CDL concept (it is an instance of
Hardware
Software
has-
has-
has-
concept-m) and the relation has-Realization is a struc- Abstract
Feature
Pre Crash
tural relation (represented by instantiating the CDLM con- Concept Detection
zation
Reali-
has-
cept relation-descriptor-m) ([Hotz, 2009a] for more
on modeling CDL with CDL). CDLM represents all what Artefact
is known about CDLD , i.e. concepts and relations.
Motion
Compilable
Software Detection
Concept
Software
MM M D S
Manufacturable Short Range
Hardware
parameter- Concept Radar Sensor
descriptor-m Pre Crash
Artefact
Detection
has-Para-
relation-
meters
descriptor-m
Realization
Figure 4: Modeling software-intensive systems.
has-Rela-
has-
tions
concept-m ping for CDL and [Tran et al., 2008] for mapping for OWL or
has [Bateman et al., 2009]). Metalayers allow for handling (meta)
Abstract
Feature
instance-of
is-a
tasks and services. For example, [Tran et al., 2008] proposes
Concept
to provide statistics about the model (e.g. retrieve all knowl-
edge elements about Pre Crash Detection). With a metalayer
Figure 3: Modeling the Component Description Language. like provided in Figure 4, during configuration of a software-
intensive system one can call different external mechanisms
Figure 4 presents the enhancement of Figure 1 by the ad- for each specific metaconcept. For example, if an instance of
ditional layer SiS M . SiS M describes the SiS D layer con- an instance of Compilable Concept (e.g. an instance of
Software) is configured, an external compiler mechanism
cepts Feature, Software, and Hardware as Abstract
Concept, Compilable Concept, and Manufacturable
can be called to realize the software. If an instance of an
Concept, respectively. Thus, it is a domain dependent ex-
instance of Manufacturable Concept is configured, the
tensions of CDLM . warehouse can be contacted to check if the needed parts for
By doing so, constraints on concepts of SiS D can be ex- the manufacturing are present. Thus, through the metalayer
pressed. For example a constraint represents that each feature the actual configuration of a product can be monitored and
should be realizable by an artefact. A constraint can check reasoning on the configuration process can be processed.
that each feature (a subconcept of Feature) should have
a structural relation has-Realization to a subconcept of 5 Related Work
Artefact. These kinds of constraints may be hard to define, The modeling approach, especially metaization [Strahringer,
because typically they are not related to one specific concept 1998], has similarities to the Model-Driven Architecture
but to several. Still, such constraints are usually part of some [Miller and Mukerji, 2003; Kühne, 2006; Atkinson and
modeling guidelines.1 Kühne, 2003; Hotz and von Riegen, 2010a], because of the
In [Hotz and von Riegen, 2010b; 2010a], we introduce the explicitation of several layers. However, the introduction of
Reasoning Driven Architecture (RDA) that allows the im- reasoning systems for each layer allows the direct usage of
plementation of metalayers by using a configuration system existing reasoners for inferring on metalayers.
on each layer. By doing so, each layer can be seen as a Metaization as such is less considered in knowledge-based
knowledge-based system that says something about the layer configuration. However, especially when learning methods,
below. In the case of RDA, SiS D contains the knowledge of i.e. automated knowledge engineering, has to be used in
domain objects, which again are represented on SiS S . By in- changing environments, the automated monitoring of KBs
troducing the metalayer SiS M , knowledge about knowledge becomes crucial and is conceivable with the presented tech-
is made explicit, i.e. knowledge about the knowledge of do- niques.
main objects. This enables the use of reasoning techniques
for each layer, not only for the domain and system layers as 6 Conclusion
it is typically the case in knowledge-based systems. The cen-
tral point of such an implementation is a mapping between In this paper, we state the differences of the main relations
instances on one layer to concepts on the next lower layer for modeling configuration knowledge, i.e. specialization, in-
(see Figure 5 and [Hotz and von Riegen, 2010a] for a map- stantiation, and structuralization. By introducing and clari-
fying the use of instantiation on several metalayers, we open
1
The SiS M M layer has been omitted because no modeling is up a further modeling facility and sketch first usage of this
required here. metaization technique for knowledge-based configuration. In
(individual :name AbstractEntity-1 [Hotz and von Riegen, 2010a] L. Hotz and S. von Riegen.
:has-superconcept-m AbstractEntity-2
:domain-name “Feature”) A Reasoning-Driven Architecture - a Pragmatic Note on
(individual
(i di id l :name Ab
AbstractEntity-2
t tE tit 2
Metareasoning. In J. Sauer, editor, Proc. of 24. Work-
:domain-name “PreCrashDetection” shop, Planen, Scheduling und Konfigurieren, Entwerfen
:is-subconcept-of-m AbstractEntity-1
:has-relations relation-descriptor-m-1)
(PuK2010) – KI 2010 Workshop, Göttingen, Germany,
2010.
(individual :name CompilableEntity-1
:has-superconcept-m CompilableEntity-2
:domain-name
d i “S ft
“Software”)
”)
[Hotz and von Riegen, 2010b] L. Hotz and S. von Riegen.
Knowledge-based Implementation of Metalayers - The
(individual :name CompilableEntity-2
:domain-name “MotionDetectionSoftware” Reasoning-Driven Architecture. In Alexander Felfernig
:is-subconcept-of-m CompilableEntity-1
:has-relations relation-descriptor-m-2)
and Franz Wotawa, editors, Proceedings of the ECAI
2010 Workshop on Intelligent Engineering Techniques for
(individual
(indi id al :name
name relation-descriptor-m-1
elation desc ipto m 1
:domain-name “has-Realization” Knowledge Bases (IKBET), 2010.
:relation-of-m AbstractEntity-2
:has-left-side structural-spec-1) [Hotz et al., 2006] L. Hotz, K. Wolter, T. Krebs, S. Deelstra,
(individual :name structural-spec-1
M. Sinnema, J. Nijhuis, and J. MacGregor. Configuration
:in-relation-left-m relation-descriptor-m-1 in Industrial Product Families - The ConIPF Methodol-
:some of CompilableEntity
:some-of CompilableEntity-2)
2)
ogy. IOS Press, Berlin, 2006.
(individual :name relation-descriptor-m-2
:domain-name “realizes” [Hotz, 2009a] L. Hotz. Construction of Configuration Mod-
:relation-of-m CompilableEntity-2
:has-left-side structural-spec-2)
els. In M. Stumptner and P. Albert, editors, Configuration
Workshop, 2009, Workshop Proceedings IJCAI, Pasadena,
(individual :name structural
structural-spec-2
spec 2
:in-relation-left-m relation-descriptor-m-2 2009.
:some-of AbstractEntity-2)
[Hotz, 2009b] L. Hotz. Frame-based Knowledge Represen-
tation for Configuration, Analysis, and Diagnoses of tech-
Figure 5: CDL Example with instances on CDLM represent- nical Systems (in German), volume 325 of DISKI. Infix,
ing concepts of CDLD . This representation enables to reason 2009.
on domain concepts with instance-related reasoning services. [John, 2002] U. John. Konfiguration and Rekonfiguration
mittels Constraint-basierter Modellierung. Infix, St. Au-
upcoming work, we will apply these techniques in learning gustin, 2002. In German.
environments in the field of robot vision. [Kühne, 2006] T. Kühne. Matters of (Meta-)Modeling. Jour-
nal on Software and Systems Modeling, 5(4):369–385,
References 2006.
[Arlt et al., 1999] V. Arlt, A. Günter, O. Hollmann, T. Wag- [Miller and Mukerji, 2003] Joaquin Miller and Jishnu Muk-
ner, and L. Hotz. EngCon - Engineering & Configuration. erji, editors. MDA Guide Version 1.0.1, omg/03-06-01.
In Proc. of AAAI-99 Workshop on Configuration, Orlando, Object Management Group, 2003.
Florida, July 19 1999.
[Ranze et al., 2002] K.C. Ranze, T. Scholz, T. Wagner,
[Asikainen and Männistö, 2010] T. Asikainen and A. Günter, O. Herzog, O. Hollmann, C. Schlieder, and
T. Männistö. A metamodelling approach to configu- V. Arlt. A Structure-Based Configuration Tool: Drive So-
ration knowledge representation. International journal of lution Designer DSD. 14. Conf. Innovative Applications
mass customisation, 3:333–350, 2010. of AI, 2002.
[Atkinson and Kühne, 2003] Colin Atkinson and Thomas [Strahringer, 1998] S. Strahringer. Ein sprachbasierter Meta-
Kühne. Model-Driven Development: A Metamodeling modellbegriff und seine Verallgemeinerung durch das
Foundation. IEEE Softw., 20(5):36–41, 2003. Konzept des Metaisierungsprinzips. In Proceedings of the
[Bateman et al., 2009] J. Bateman, A. Castro, I. Normann, Modellierung 1998. Astronomical Society of Australia,
O. Pera, L. Garcia, and J.M. Villaveces. OASIS common 1998.
hyper-ontological framework (COF), Deliverable D1.2.1. [Tran et al., 2008] Thanh Tran, Peter Haase, Boris Motik,
Technical report, University of Bremen, 2009. Bernardo Cuenca Grau, and Ian Horrocks. Metalevel In-
[Brachman, 1983] Ronald J. Brachman. What is-a is and formation in Ontology-Based Applications. In Dieter Fox
isn’t: An analysis of taxonomic links in semantic net- and Carla P. Gomes, editors, Proc. of the 23rd AAAI Conf.
works. IEEE Computer, 16(10):30–36, 1983. on Artificial Intelligence (AAAI 2008), pages 1237–1242,
[Gelle and Faltings, 2003] Esther Gelle and Boi Faltings. Chicago, IL, USA, July 13–17 2008. AAAI Press.
Solving mixed and conditional constraint satisfaction [van Harmelen et al., 2007] Frank van Harmelen, Vladimir
problems. Constraints, 8(2):107–141, 2003. Lifschitz, and Bruce Porter, editors. Handbook of Knowl-
[Günter and Hotz, 1999] A. Günter and L. Hotz. KON- edge Representation (Foundations of Artificial Intelli-
WERK - A Domain Independent Configuration Tool. Con- gence). Elsevier Science, 2007.
figuration Papers from the AAAI Workshop, pages 10–19,
July 19 1999.