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.