THOUGHTS ABOUT STRUCTURALIZATION, SPECIALIZATION,

INSTANTIATION, AND METAIZATION

Lothar Hotz and Stephanie von Riegen

Hamburger Informatik Technology Center, Department Informatik, University of Hamburg, Hamburg, Germany

Keywords:

Metamodeling, Knowledge representation.

Abstract:

In knowledge engineering, ontology creation, and especially in knowledge-based conﬁguration 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. Structural and specialization relations are mainly used for organizing the

knowledge represented on one layer. Instantiation layers model different kind of knowledge, i.e. knowledge

about sets, individuals, and knowledge about knowledge (metaknowledge). By applying reasoning techniques

on each layer, reasoning on metaknowledge is enabled.

1 INTRODUCTION

For conﬁguration-based inference tasks, like con-

structing a description of a speciﬁc car periphery sys-

tem (Hotz et al., 2006) or drive systems (Ranze et al.,

2002), the knowledge of a certain domain is repre-

sented with a knowledge-modeling language which

again is interpreted, because of a deﬁned semantic,

through a knowledge-based system or conﬁgurator.

Examples for knowledge-modeling languages are the

Web-Ontology Language (OWL) or the Component

Description Language (CDL) (Hotz, 2009). Further

languages are e.g. described in (Harmelen et al.,

2007). Such languages typically provide concepts or

classes that gather all properties, a certain set of do-

main objects has, under a unique name. With con-

cepts and instances a strict separation into two layers

is made: a domain model (or ontology) which cov-

ers the knowledge of a certain domain (abbr. layer

)

and a system model (or conﬁguration) which covers

the knowledge of a concrete system or product of the

domain (abbr. layer

Properties of a concept that map to primitive data

types, like intervals, values sets (enumerations), or

constant values, are called parameters or attributes.

Properties that map to other concepts or to instances

are called relations. Knowledge-modeling languages

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 ﬁrst. This relation (also called

is-a relation) forms a specialization hierarchy or lat-

tice, 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 rela-

tive concepts. With structural relations a composi-

tional 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 re-

lations, constraints provide model facilities to express

n-ary relationships between properties of concepts.

Constraints can represent restrictions between prop-

erties like arithmetic relations or restrictions on struc-

tural relations (e.g. ensuring existence of certain in-

stances).

In this paper, the use of structuralization, special-

ization, and instantiation is discussed. Even those re-

lations are quite well-known they are sometimes con-

founded. Furthermore, when used with more than

the two mentioned domain and system layers (see

(Asikainen and M

annist

o, 2009; Hotz, 2009)) the in-

stantiation relation is multiply applied, which leads to

new modeling layers and thus probably to modeling

difﬁculties. The creation of such multiple layers is

called metaization (Strahringer, 1998).

In the following, we ﬁrst consider all relations in

more depth and give example of their use (Section 2

and Section 3). Afterwards, we discuss metaization

and its use for conﬁguration (Section 4). We end with

a short discussion on related work and a conclusion.

457

Hotz L. and von Riegen S..

THOUGHTS ABOUT STRUCTURALIZATION, SPECIALIZATION, INSTANTIATION, AND METAIZATION.

DOI: 10.5220/0003666504570460

In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (KEOD-2011), pages 457-460

ISBN: 978-989-8425-80-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

Artefact

Software

Thing

ProductContext

Feature

Hardware

has-Realization

has-Context

has-Feature

has-Software

has-Hardware

instance-of

is-a

has

Figure 1: Extract from an upper-model for modeling

software-intensive systems.

2 STRUCTURALIZATION

As already elaborated in (Hotz, 2009) conﬁguration

can be considered as model construction, because a

description of a certain system (a conﬁguration) is

constructed by a conﬁgurator. Furthermore, (Hotz,

2009) 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 ag-

gregates and r denotes the parts. The underlying

structural relation is used by conﬁgurators to con-

struct the description and thus are the motor of con-

ﬁguration. Depending on what instances (of c or r)

exist ﬁrst, instances of the related concepts are cre-

ated; e.g. this enables reasoning from the aggregate to

the parts or contrariwise, from the parts to the aggre-

gate. This semantic holds for every structural relation.

Thus, introducing several structural relations enables

the use of adequate domain names like has-Features

or has-Realizations, and thus to facilitate mainte-

nance.

Figure 1 pictures an upper-model for software-

intensive systems (UMSiS, (Hotz et al., 2006)). It

deﬁnes four asset types (features, context, hardware

and software artefacts) which are common to most

application domains of software-intensive systems. A

product, i.e. the result of the product derivation, con-

tains software and hardware artefacts as parts, these

together realize particular features. Several struc-

tural relations are depicted, like has-Realizations

and has-Feature. When using the upper-model for a

speciﬁc domain, the UMSiS is extended with domain-

speciﬁc knowledge about hardware and software arte-

facts, the existing features, relevant context aspects,

etc. In the example above, the concepts are orga-

nized in different spaces. Each space represents a spe-

ciﬁc aspect of the domain and thus each conﬁgured

product should have those aspects. Figure 1 provides

the example of the feature and artefact aspects in the

domain of software-intensive systems. Thus, spaces

separate concepts of one layer. Through this group-

ing of concepts of one layer the conﬁguration model

is easier to manage for a knowledge engineer. Fur-

thermore, concepts of different spaces are connected

by a structural relation. This ensures that a conﬁg-

ured product ﬁnally contains all modeled aspects. In

contrast to this, in Section 3 we will see, how the in-

stantiation relation separates concepts and instances

on different layers.

3 SPECIALIZATION VS.

INSTANTIATION

A concept describes a set of instances. The special-

ization relation (or subsumption or is-a relation) be-

tween two concepts c and s describes a subset rela-

tion, i.e. the set of instances of concept c is a subset

of the set of instances of its superconcept s (see also

(Brachman, 1983)). Or, as deﬁned in ontogenesis.

knowledgeblog.org/699: “c is-a s if and only if:

given any i that instantiates c, i instantiates s”. An

instance of a class c is always an instance of each su-

perclass s of c. We consider this aspect as the hint-

ing characteristic for knowledge engineers: During

knowledge modeling one can try to make a special-

ization between two domain aspects and test this char-

acteristic. Thus, it is tested if an instance of c is also

reasonably an instance of s. If it is false the knowl-

edge engineer must not use a specialization but e.g.

instantiation, because c and s are probably on differ-

ent layers.

A Motion

Detection

Software.exe

instance-of

is-a

has

Compilable

Concept

Artefact

Software

Compilable

Concept

Motion

Detection

Software

A Motion

Detection

Software.exe

Software

Motion

Detection

Software

Artefact

Figure 2: Good and bad use of specialization and instantia-

tion in software-intensive systems.

An example for this situation is shown in Fig-

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

458

ure 2; it presents the confounded usage of specializa-

tion and instantiation relations in the aforesaid model-

ing of software-intensive systems domain (SiS). The

system model layer (SiS

) is covering speciﬁc in-

dividuals, here for instance the A Motion Detection

Software.exe. This object is an instance of the

Motion Detection Software (SiS

) but no instance of

Compilable Concept. Compilable Concept denotes a

speciﬁc kind of concept. A concept typically spec-

iﬁes the description of the property structure of its

instances. A Compilable Concept additionally can

take this description and compile it to an executable

ﬁle. Thus, in the “bad” use, A Motion Detection

Software.exe is incorrectly considered as a concept,

i.e. as a description of instances that can be com-

piled. Instead it is an instance of Motion Detection

Software, thus a speciﬁc domain object not a concept

and, of course, it is already compiled.

When a concept s is specialized to c all proper-

ties of s are inherited by c. By the time a concept is

instantiated, properties of the created instance are ini-

tialized by values or value ranges speciﬁed in the con-

cept. 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 conﬁgurator subsequently creates a

speciﬁc description consisting of instances, i.e. the

conﬁguration.

4 METAIZATION

For structuralization and specialization, the involved

concepts are on one layer. However, for instantiation

and metaization they are on different layers. By in-

stantiating 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 an-

other concept c

, i.e. a step from a set of concepts to

one speciﬁc concept is performed. The concept c

on a further layer. Figure 3 demonstrates this situa-

tion. The concept Feature is an instance of Abstract

Concept which is a specialization of concept-m. The

concepts on the metalayer CDL

represent the mod-

eling facilities of CDL, describing the concepts and

relations of CDL. Concept Artefact is a typical CDL

concept (it is an instance of concept-m). Beside con-

cepts, also relations have a concept on CDL

for rep-

resenting them (not depicted in the Figure, see (Hotz,

2009)). Thus, CDL

represents all what is known

about CDL

, i.e. concepts and relations.

Figure 3 presents the enhancement of Figure

1 by the additional layer SiS

. SiS

describes

the SiS

layer concepts Feature, Software, and

Hardware as Abstract Concept, Compilable Concept,

and Manufacturable Concept, respectively. Thus, it

is a domain dependent extensions of CDL

By doing so, constraints on concepts of SiS

can

be expressed. For example, a constraint represents

that each feature should be realizable by an artefact.

Such a constraint can check that each feature (a sub-

concept of Feature) should have a structural relation

has-Realization to a subconcept of Artefact. These

kinds of constraints may be hard to deﬁne, because

typically they are not related to one speciﬁc concept

but to several. Still, such constraints are usually part

of some knowledge modeling guidelines.

Motion

Detection

Software

Short Range

Radar Sensor

Pre Crash

Detection

A Motion Detection

Software.exe

A Short Range

Radar Sensor

A Car

A Pre Crash

Detection

instance-of

is-a

has

Manufacturable

Concept

Feature

Artefact

Software

Hardware

Compilable

Concept

Product

Abstract

Concept

has-

Reali-

zation

has-

Feature

has-

Hardware

has-

Software

concept-

has-

supercon-

cept-m

Realizable

Concept

Figure 3: Modeling software-intensive systems.

In (Hotz and von Riegen, 2010), we introduce

the Reasoning Driven Architecture (RDA) that al-

lows the implementation of metalayers by using a

conﬁguration system on each layer. By doing so,

each layer can be seen as a knowledge-based sys-

tem that says something about the layer below. In

the case of RDA, SiS

contains the knowledge of do-

main objects, which again are represented on SiS

By introducing the metalayer SiS

, 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 in-

stances on one layer to concepts on the next lower

layer (see (Hotz and von Riegen, 2010) for a map-

ping for CDL and (Tran et al., 2008) for a mapping

for OWL or (Bateman et al., 2009)). Metalayers al-

low for handling (meta) tasks and services. For ex-

ample, (Tran et al., 2008) proposes to provide statis-

tics about the model (e.g. retrieve all knowledge ele-

ments about Pre Crash Detection). With a metalayer

THOUGHTS ABOUT STRUCTURALIZATION, SPECIALIZATION, INSTANTIATION, AND METAIZATION

459

like provided in Figure 3, during conﬁguration of a

software-intensive system one can call different ex-

ternal mechanisms for each speciﬁc metaconcept. For

example, if an instance of an instance of Compilable

Concept (e.g. an instance of Software) is conﬁg-

ured, an external compiler mechanism can be called

to realize the software. If an instance of an instance

of Manufacturable Concept is conﬁgured, the ware-

house can be contacted to check if the needed parts

for the manufacturing are present. Thus, through the

metalayer the actual conﬁguration of a product can be

monitored and reasoning on the conﬁguration process

can be processed.

5 RELATED WORK

The modeling approach, especially metaization

(Strahringer, 1998), has similarities to the Model-

Driven Architecture (K

uhne, 2006; Atkinson and

uhne, 2003; Hotz and von Riegen, 2010), because

of the explicitation of several layers. However, the in-

troduction of reasoning systems for each layer allows

the direct usage of existing reasoners for inferring on

metalayers.

(Asikainen and M

annist

o, 2009) and (Haase et al.,

2009) present also approaches that include semantics

on the metalayer, similar to our approach. By do-

ing so, reasoning methods on each layer as well as

the capability to deﬁne domain-speciﬁc extensions on

the metalayer is in principle enabled. Metaization as

such is less considered in knowledge-based conﬁgu-

ration. However, especially when learning methods,

i.e. automated knowledge engineering, has to be used

in changing environments, the automated monitoring

of knowledge bases becomes crucial and is conceiv-

able with the presented techniques.

6 CONCLUSIONS

In this paper, we state the differences of the main

relations for modeling conﬁguration knowledge, i.e.

specialization, instantiation, and structuralization. By

introducing and clarifying the use of instantiation on

several metalayers, we open up a further modeling fa-

cility and sketch ﬁrst usage of this metaization tech-

nique for knowledge-based conﬁguration. In upcom-

ing work, we will apply these techniques in learning

environments in the ﬁeld of robot vision.

REFERENCES

Asikainen, T. and M

annist

o, T. (2009). Nivel: a metamod-

elling language with a formal semantics. Software and

Systems Modeling.

Atkinson, C. and K

uhne, T. (2003). Model-Driven Devel-

opment: A Metamodeling Foundation. IEEE Softw.,

20(5):36–41.

Bateman, J., Castro, A., Normann, I., Pera, O., Garcia, L.,

and Villaveces, J. (2009). OASIS common hyper-

ontological framework (COF), Deliverable D1.2.1.

Technical report, University of Bremen.

Brachman, R. J. (1983). What is-a is and isn’t: An anal-

ysis of taxonomic links in semantic networks. IEEE

Computer, 16(10):30–36.

Haase, P., Palma, R., and d’Aquin M. (2009). Up-

dated Version of the Networked Ontology Model.

Project Deliverable D1.1.5, Neon Project. www.neon-

project.org.

Harmelen, F. V., Lifschitz, V., and Porter, B., editors (2007).

Handbook of Knowledge Representation (Founda-

tions of Artiﬁcial Intelligence). Elsevier Science.

Hotz, L. (2009). Construction of Conﬁguration Models.

In Stumptner, M. and Albert, P., editors, Conﬁgura-

tion Workshop, 2009, Workshop Proceedings IJCAI,

Pasadena.

Hotz, L. and von Riegen, S. (2010). Knowledge-based Im-

plementation of Metalayers - The Reasoning-Driven

Architecture. In Felfernig, A. and Wotawa, F., editors,

Proceedings of the ECAI 2010 Workshop on Intel-

ligent Engineering Techniques for Knowledge Bases

(IKBET).

Hotz, L., Wolter, K., Krebs, T., Deelstra, S., Sinnema, M.,

Nijhuis, J., and MacGregor, J. (2006). Conﬁguration

in Industrial Product Families - The ConIPF Method-

ology. IOS Press, Berlin.

uhne, T. (2006). Matters of (Meta-)Modeling. Journal on

Software and Systems Modeling, 5(4):369–385.

Ranze, K., Scholz, T., Wagner, T., G

unter, A., Herzog, O.,

Hollmann, O., Schlieder, C., and Arlt, V. (2002). A

Structure-Based Conﬁguration Tool: Drive Solution

Designer DSD. 14. Conf. Innovative Applications of

AI.

Strahringer, S. (1998). Ein sprachbasierter Metamodellbe-

griff und seine Verallgemeinerung durch das Konzept

des Metaisierungsprinzips. In Proceedings of the

Modellierung 1998. Astronomical Society of Aus-

tralia.

Tran, T., Haase, P., Motik, B., Grau, B. C., and Horrocks,

I. (2008). Metalevel Information in Ontology-Based

Applications. In Fox, D. and Gomes, C. P., editors,

Proc. of the 23rd AAAI Conf. on Artiﬁcial Intelligence

(AAAI 2008), pages 1237–1242, Chicago, IL, USA.

AAAI Press.

KEOD 2011 - International Conference on Knowledge Engineering and Ontology Development

460