Multiple and Dynamic Representation of frames with ... - CiteSeerX

Publication of the Conference RPO “Représentations par Objets” La Grande Motte, France, 22-23 June 1992

Multiple and Dynamic Representation of frames with Points of View in FROME Lenneke Dekker1, Bernard Carré Laboratoire d’Informatique Fondamentale de Lille, URA C.N.R.S. 369 Université des Sciences et Technologies de Lille Cité Scientifique - Bâtiment M3 59655 Villeneuve d’Ascq Cedex, FRANCE Tel: (33) 20 43 45 13 Email: {dekker carre}@lifl.fr Abstract:

We describe some contributions of the knowledge representation system FROME to the exploitation of class hierarchies. In order to cope with incomplete, subjective and changing knowledge, FROME proposes multiple and evolutive representation of frames. Multiple representation in FROME allows to describe and manipulate entities from different points of view. Point of view selection on frames contributes to the exploitation of multi-point of view hierarchies, which are an important subject of current research in object oriented knowledge representation (ROME, TROPES, SHOOD).

Keywords:

Frames, Knowledge Representation, Taxonomy, Multiple Representation, Dynamic Representation, Evolution, Point of View, Multi-Expert Systems, Object-Oriented Frame System.

Résumé:

Nous présentons quelques contributions du système de représentation des connaissances FROME aux problèmes liés à l’élaboration et l’exploitation d’hiérarchies de classes. Face au besoin de représenter des connaissances incomplètes, subjectives et sujettes à des changements continuels, FROME propose la représentation multiple et évolutive de frames. La représentation multiple de FROME offre un moyen de décrire et manipuler des entités sous des points de vues différents. La sélection de points de vue sur les frames permet une meilleure exploitation des hiérarchies multi-points de vue, qui représentent un centre d’intérêt dans la recherche actuelle sur la représentation par objets (ROME, TROPES, SHOOD).

Mots clés:

Frames, Représentation des Connaissances, Taxonomie, Représentation Multiple, Représentation Dynamique, Evolution, Point de Vue, Systèmes Multi-Expert.

1. Research supported by Région Nord-Pas de Calais under contract number 90030047.

1.Introduction Our models of the world are neither complete, nor absolute or definitive. Real world objects as well as our knowledge about them continuously change. The way we represent real world objects depends on what we know about them and what aspects we judge important, that is how we view them. Different people have in general different views of objects depending on their knowledge and their interests. In addition, the way we view an object can change when we learn more about it. Tools for knowledge representation should therefore be able to cope with incomplete, subjective and changing knowledge about objects that are themselves changing. In this paper we describe some contributions of FROME [Car91a] to the problem of multiple and dynamic representation of frames with points of view, [Bob77] [Bob81] [Car88] [Dug88] [Rec90] [Mar90] [Ngu91], related with this issue. FROME is an object-oriented frame language, endowed with some powerful notions for a flexible representation of evolving knowledge. Based on the class/instance/ inheritance model, FROME describes its frames by classes, organized in a hierarchy. The original features we describe here are multiple representation of frames within this hierarchy reflecting several points of view on them and the evolution of this representation, which allows a frame to migrate over the hierarchy. The hierarchy itself can be easily extended on the acquisition of new domain knowledge by the addition of new points of view or the specialization of existing ones. These features are promising with regard to multi-expert descriptions of evolving entities.

2.Hierarchical Modelling of Concepts The taxonomic power of class hierarchies is an important property of class based knowledge representation systems [Fik85] [Weg86a] [Weg86b] [Len91] [Hat91] [Mas89]. Hierarchical networks turn out to fit well for structuring our knowledge about the world and representing entities. General descriptions of entities are defined in classes and can be specialized in subclasses. An individual entity is represented by a frame instance belonging to a class in the hierarchy. Subclasses inherit characteristics (attributes or “slots”) defined by superclasses so that an entity belonging to a class has all characteristics defined by its class and by the superclasses of its class. 2.1. Specialization through subclassing Refinement of a frame description in a class corresponds to the addition of new slots or the specialization of inherited ones. Slot descriptions are specialized in turn by the addition of new facets or the restriction of those defined by a superclass. A classification of well-known facets (as available in FROME, and also in most other frame systems) is given fig. 1. We distinguish between active and passive facets (procedures and data), and between constraining and non constraining facets. Constraining facets express constraints on the slot value. Refining a slot means adding constraints, restricting possible values etc., respecting the conventional refinement rules such as: - the $type of a refined slot must be a subtype of the original type - new $domain and $interval values must be included in the original ones

Facets active passive constraining non constraining ✗ ✗ $type ✗ ✗ $domain $interval ✗ ✗ $default ✗ ✗ ✗ ✗ $comment ✗ ✗ $value ✗ ✗ $verify ✗ ✗ $if-needed ✗ $before-get ✗ ✗ $before-put ✗ ✗ ✗ $after-get ✗ ✗ $after-put ✗ $before-rem ✗ ✗ ✗ $after-rem

Flat

FlatWithGarden

MiddleFloorFlat

fig. 2: Subclassing

fig. 1

or adding reflexes (attached procedures before or after slot access, or for dynamic computation of slot values). An example of subclassing of two frame classes is given fig. 2. Consider a housing office which administers a group of flats. A general description of flat could be given by the frame class “Flat” below. Some of the associated slots could be “floor”, an integer, “totalRent”, which is the rent plus service charge. To compute the “totalRent” and the “serviceCharge” of a flat, these slots have a procedure defined in the “$if-needed” facet. [Metaframe new Flat supers (Frame) slots ( floor ( $type integer $interval (1 20)) garden ( $type boolean) rent ( $type real $interval (500 1000)) serviceCharge ( $type real $if-needed (lambda() (+ %maintenance (* 0.05 %rent)))) maintenance ( $type real $default 50) totalRent ( $type real $if-needed (lambda() (+ %rent %serviceCharge))))]

Special flats are those with a garden, or those situated on an intermediate floor, provided with a lift. They are described by the subclasses “FlatWithGarden” and “MiddleFloorFlat”: [Metaframe new FlatWithGarden supers (Flat) slots ( floor ( $domain (1)) garden ( $domain (true)) rent ( $interval (700 1000)))] [Metaframe new MiddleFloorFlat supers (Flat) slots ( floor ( $interval (2 5)) garden ( $domain (false)) liftCharge ( $type real $if-needed (lambda() (* %floor 12.50))) serviceCharge ( $if-needed (lambda() (+ (super) %liftCharge))))]

A flat with a garden sees the domain of its “floor” slot restricted to 1, through the

additional facet “$domain”. The “$domain” facet of “garden” has been restricted in both subclasses. The rent for an apartment with a garden is at least 700 as we find in the “$interval” restriction. A middle floor flat has supplementary service charge, due to the lift-charge. The way to compute the “serviceCharge” is specified by the refined “$if-needed” facet. Note that “(super)” in this refinement invokes the “$if-needed” facet of the same slot as defined originally in “Flat”. 2.2. Modelling incomplete and evolving knowledge Most concepts can not be described completely by a finite set of operations and attributes. But we can approach the definition through multiple partial views, each describing a particular aspect of the concept. Knowledge representation is never independent of what we want to do with it. Since it is inevitably incomplete, we only represent aspects which are important to us. Multiple utilizations of objects induce multiple views on these objects and hence different representations, highlighting different aspects. This leads to multiple subclassifications of the same concept, each reflecting a particular aspect. The result is a hierarchy for multiple representation. To realize effectively a multiple representation of a given entity, the frame representing this entity should belong to classes in multiple point of view subclassifications. Our changing view of a concept can lead to the introduction of new classes in the hierarchy, and even to the addition of an entire point of view subclassification. The entities represented in the system should be re-classified according to the enriched model. The system should also be able to reflect the changes of the entities themselves. Therefore, the class membership of a frame should be flexible. The multiple and evolutive representation features of the language ROME deal with these issues in the object-oriented context [Car89][Car90a]. In this paper we discuss multiple and dynamic representation in the frame context, as provided by the language FROME which is an extension to ROME [Car91b].

Accommodation

OccupationPoV

Occupied

ToBeFreed

TypePoV

Vacant Reserved

Flat

House

AreaPoV

Residential

DevelopmentArea

FinancePoV

...

...

...

LevelPoV

Ground Middle Upper

: is subclass of : isa

fig. 3: Multiple representation

f1

: exclusion

3.Multiple Representation 3.1. Multiple representation according to multiple points of view Let us assume our housing office not only controls flats but also other sorts of accommodations. An accommodation can be described from several points of view, according to different interests of the office. (See fig. 3). There will be an Occupation point of view, describing all characteristics about the occupation of an accommodation: the current tenant, the date he entered, a list of former tenants. Within this point of view, accommodations are (sub) classified as occupied, vacant and reserved ones. Other points of view could be a Type point of view, differentiating flats and houses, an Area point of view, and a Financial point of view, concerned with taxes, repair costs, etc. Within a point of view, there can be subclassing according to sub points of view, like the Level point of view for flats, partitioning them in ground floor, middle floor and upper floor apartments. A particular accommodation is for example a flat, which is situated on the 16th floor of an apartment building in a priority development area. The flat we are talking about will be freed by its actual tenant on 1st february and has already been reserved by a new tenant. To classify our flat according to the model, we need to link it with all appropriate classes within the relevant points of view. In FROME, multiple representation of a frame according to different points of view is possible through the “isa” link, which attaches a frame to classes it belongs to. Our flat on the 16th is represented by the frame f1, linked to all classes which describe its characteristics. It is only partially described here: it is not linked to classes in the Finance Point of View. The multiple representation of a frame is limited by coherence constraints between representation classes. When two classes Ci and Cj exclude each other, a frame cannot belong to both of them simultaneously. These constraints are expressed in exclusion relations: [Ci excludes Cj] The classes “Flat” and “House” are related by exclusion, because an accommodation can not be both a flat and a house. Properties of the exclusion relation are: - exclusion is symmetrical - exclusion is inheritable: if Ci excludes Cj, then Ci excludes all subclasses of Cj. Example: “Occupied” excludes “Vacant, so “Vacant” excludes “Occupied” and thus also “ToBeFreed”. 3.2. Subclassification selection according to a point of view When we are interested in an object, this interest very often focuses on a particular point of view on the object. The agent at the housing office in charge of the attribution of the flat represented by f1 will be interested in the Occupation point of view for example, because he has to contact the actual tenant in order to let the future one visit the apartment. The selection of a particular subclassification of a frame allows to consider the frame from a point of view leaving the other points of view apart.

3.2.1 The notion of Point of View in FROME Intuitively, a point of view may be seen as a specific part of a class hierarchy, describing a set of characteristics relative to a well-defined part of the knowledge domain. In FROME, each class within the hierarchy can be interpreted as defining a point of view on the frames it describes. Let the representation graph of a frame f the subgraph of the class hierarchy containing all classes the frame belongs to, that is all classes the frame is linked with by “isa” and their superclasses. The representation graph of f is denoted Rep(f). Let the dependency of C all its superclasses and subclasses and C itself. The dependency of C is denoted Dep(C). Then we define the Point of View of a class C on the frame f: PoV(C,f) = Rep(f) ∩ Dep(C) For example: PoV(Occupied, f1)= {ToBeFreed, Occupied, OccupationPoV, Accommodation} 3.2.2 Point of View expression A subclassification of a frame is selected using a point of view expression. The selection is expressed relative to one of the frame’s classes, when accessing slots to get or put their values, as follows: [(aFrame as classname) getvalue slotname] for read access, and: [(aFrame as classname) putvalue slotname value] for write access. On the example: [(f1 as occupied) getvalue contact] returns the telephone number of the actual tenant of the occupied flat. [(f1 as reserved) putvalue contact 19331214] writes the telephone number of the person who has reserved the flat. Accommodation

OccupationPoV

Occupied contact ToBeFreed date

Vacant

Reserved contact

f1

fig. 4 : Point of view selection

Note that the selection of a point of view focuses on characteristics defined within the corresponding subclassification. As a result, conflicts between homonymous slots defined in independent points of view, are avoided.

3.2.3 Slot description selection The selection of a point of view on a frame focuses on the description of the frame as given in the corresponding subclassification. The frame and its slots are interpreted from the selected point of view. This means that some slots are considered rather than others (see preceding paragraph), and that some slot interpretation is chosen rather than another when a given slot has multiple interpretations according to different points of view. Selecting one such interpretation provokes for example the triggering of reflexes defined in this point of view. However, it does not allow to bypass any constraint defined in another point of view1. This is inhibited by the principle of constraint multiplicity: If several classes refine the same slot , adding new constraints from their own point of view, must satisfy all of them. Let us consider again our flat f1 and extend its description with the Finance Point of View (fig. 5). Two sub points of view distinguish the financial interests of the owner and those of the tenant. The owner and the tenant each have their own rate to pay. Some repair costs are incumbent on the tenant and others on the owner. FinancePoV monthlyRent $type real $if-needed (* %totalSurface %coef)

OwnerPoV repairCosts ... rates ... dateReceived ... monthlyRent $after-get (v) (print “Rent of” v “received” %dateReceived)

TenantPoV repairCosts ... rates ... datePaid ... monthlyRent $after-get (v) (print “Rent of” v “paid” %datePaid) $verify (v) (< (* 1.05 %monthlyRent))

f1

fig. 5 : Multiple slot refinement

The tenant point of view is interested in the date the tenant paid his rent. Within the owner point of view, however, the date the money came in, is more important. So when we ask for the “monthlyRent”, the attached information from one point of view (tenant) is the date of the most recent check, whereas from the other point of view (owner), we get the date of the last rent encashment, respectively: [(f1 as TenantPoV) getvalue monthlyRent] > Rent of 1500 paid december 29 1991 [(f1 as OwnerPoV) getvalue monthlyRent] > Rent of 1500 received january 3 1992. The $after-get reflexes returning this information depending on the point of view are added as refinements of the slot “monthlyRent”, which was defined in FinancePoV.2 1. See the facet table in figure 1 for constraining and non constraining facets. 2. This is multiple refinement of the same slot, so f1 has a single slot “monthlyRent”. However, it has two slots “repairCosts” and two slots “rates”, each one with its own value.

Notice that the principle of constraint multiplicity guarantees the respect of all constraints even when a point of view is selected. For example: [(f1 as OwnerPoV) putvalue monthlyRent 1800] will fail. The new value 1800 will be rejected by the (constraining) $verify facet of the TenantPoV, which checks that a rent increase never exceeds 5 percent. 3.3. Multiple subclassing We have seen that the refinement of a frame description by addition or specialization of slots is realized through subclassing (§2.1). The subclass specializes the superclass. In the same way, specializing several classes requires the creation of a subclass. This is multiple subclassing. Multiple subclassing is constrained by exclusion relations which may exist between classes. The creation of a subclass of excluding classes is prohibited. Multiple subclassing leads to situations similar to those described in §3.2. Let us consider the Occupation Point of View subclassification again. Tenants who leave their apartment sometimes wish to convey it to a friend. We represent these apartments by the class “ReservedForFriend”, which specializes both the classes “Reserved” and “ToBeFreed” (fig. 6). OccupationPoV Occupied contact ToBeFreed date contact $before-get() (print “warning: tel.nb.until:” %date)

Reserved contact

Vacant

ReservedForFriend (contact as Reserved) $if-needed()(%contact as Occupied)

fig. 6 : Multiple subclassing

A subclass inherits all slots from its superclasses, i.e. both “contact” slots are inherited here. Each of them can be refined independently. Here, the contact inherited from “Reserved” is refined. In case no telephone number is known to contact the interested person, the telephone number of the leaving tenant is taken, since he knows his friend: (contact as Reserved)1 ($if-needed () (%contact as Occupied)). Point of view selection is thus also a means to choose a slot for refinement. Notice that refinement of a slot is always preserved within a point of view [Car90b], so that “(contact as Occupied)” takes into account the $before-get facet added in “ToBeFreed”. Let us consider now the State Point of View (figure 7), which classifies accommodations in Recent, NotTooOld, Old, depending on their age, and partitions 1. shortcut for ((self as Reserved) contact).

StatePoV age Recent

OccupationPoV

Old

NotTooOld

Renovated

Occupied contact

ToBeDemolished date

ToBeReplaced contact $before-get() (print “warning: a proposal has to be made before:” %date “to this number:”)

ToBeFreed date contact $before-get() (print “warning: tel.nb. until:” %date)

ToBeFreedForDemolition (date as ToBeFreed) $verify (d) (< d (%date as ToBeDemolished)) $if-needed () [(%date as ToBeReplaced) week-before] contact $before-get () (super as ToBeReplaced) newAccommodation $type Accommodation

fig. 7 : Multiple subclassing inter- point of view

Old in Renovated and ToBeDemolished. Imagine now that an accommodation, say a1, which has to be demolished, is still occupied. Then, steps have to be taken to find a new accommodation for the tenant of a1. Occupied and ToBeDemolished accommodations can be described by the class “ToBeReplaced”, which is an inter-viewpoint subclass. The “contact” slot is refined here with a $before-get reflex, which is a reminder for the urgent proposal to be made: contact ($before-get () (print “warning: a proposal has to be made before” %date “to this number:”). The subclass ToBeFreedForDemolition, inheriting two dates (the date of demolition and the date “ToBeFreed”), refines the latter, adding a method to compute it, depending on the demolition date. Clearly, the accommodation must be freed before demolition: (date as ToBeFreed) ($verify (d) (< d (%date as ToBeDemolished)) $if-needed () [(%date as ToBeReplaced) week-before]). Notice that “(%date as ToBeDemolished)” and “(%date as ToBeReplaced)” select the same slot; the selection of a point of view is not the selection of a class, but the selection of an entire subclassification related with the specified class. For the (multiply refined) “contact” slot, one of the two $before-get facets is chosen, again using Point of View selection: contact ($before-get () (super as ToBeReplaced))

4.Evolving Representation 4.1. Specialization of frames The description of entities within a point of view is seldom complete from the start. The hierarchy itself can contain for example the most general classes within each point of view, which allow to operate a rough classification of frames. Refining the hierarchy means adding new subclasses containing more details about their instances. The existing frames have to be specialized according to the refined hierarchy. Additional points of view can induce supplementary classifications of a concept, so that existing frames acquire a new “dimension”, being described from a new point of view. For example: the Financial Point of View description of our flat f1 can be added afterwards. 4.2. Changing frames Apart from incremental change, enriching a frame description, the representation of more radical change can be required, when the represented entity finds itself modified. A vacant flat for example, becomes occupied when a new tenant receives the keys. The membership of the class “Vacant” is no longer adequate for the representing frame. OccupationPoV

Occupied

Vacant

f2

fig. 8

This kind of change also occurs when we learn that an entity is not exactly what we thought it was. We then need to modify our representation accordingly. 4.3. Frame evolution in FROME The evolution of frame instances according to specialization or change is possible in FROME because the “isa” link of a frame instance with its classes, is dynamic. New “isa” links can be added and existing ones undone. This is expressed as follows: [aFrame isa ] links “aFrame” with the class . [aFrame no-more ]. detaches “aFrame” from . It remains a member of the superclasses of . For example: [f2 no-more Vacant] [f2 isa Occupied] expresses the evolution of f2 from Vacant to Occupied accommodation.

OccupationPoV

Occupied

Vacant

✂ f2

fig. 9: Frame evolution

A frame instance cannot belong to a class if it violates any constraint defined by this class, for example constraints on its slots, or the exclusion relation of the class with one of the frame’s classes. In our example, f2 can not be linked with “Occupied” if it is still “Vacant” because of the exclusion relation. When we try to link a frame with a class, these constraints are checked by the system. In particular, when evolution expresses a specialization, existing slot values must fit in refined domains. Consider for example a house (represented by h1). We want to add a Comfort Point of View to its description (see fig. 10). Specialization within this point of view is constrained by slot domain restriction. If the house represented by h1 has no heating at all, even if it has toilets and bathrooms, it cannot be called luxurious, so the evolution of h1 to “Luxurious” is inhibited. Only the class “Uncomfortable” would suit here! ComfortPoV bathrooms $interval (0 5) toilets $interval (0 5) showers $interval (0 5) heating $domain (no central electric coal) Uncomfortable bathrooms $default 0 toilets $default 0 showers $default 0 Basic showers $default 1 toilets $default 1 bathrooms $default 1 heating $domain (coal central electric)

Normal bathrooms $interval (1 5) toilets $interval (1 5) heating $domain (central electric)

Luxurious toilets $interval (2 5) bathrooms $interval (2 5) heating $domain (central)

? h1 bathrooms $value 2 toilets $value 2 heating $value no

fig.10 : Domain restriction

5.Implementation elements FROME is a frame language defined on top of the object-oriented language ROME. More precisely, it is an object-oriented extension of ROME, obtained by metaprogramming, [Mae87] [Fer89], i.e. classes and frame instances are objects of the underlying language, and as such themselves described by (ROME-) classes. Their manipulation is realized through message sending. A major advantage of object-oriented extensions is that the resulting language inherits all characteristics of the underlying one. In particular, all notions concerning multiple representation, point of view selection and evolution, provided originally by ROME for objects [Car90ab], are inherited by FROME and specialized for frames.

Another important “inherited” property is the extensibility of the system. For example, the frame language can easily be extended with new facets for particular kinds of slot. This makes it a flexible platform for knowledge representation. Details on the meta-implementation of FROME on top of ROME can be found in [Car91b].

6.Comparison to other work 6.1. Multiple subclassing and representation In systems with multiple subclassing, like FRL [Rob77], Shirka [Rec90] and YAFOOL [Duc86] homonymous slots defined in several superclasses of a class, are seldom distinguished. Multiple slot inheritance is often assimilated to multiple refinement of the same slot (FRL, Shirka [Rec90]). The principle of constraint multiplicity for multiple slot refinement is generally respected. FRL applies all inherited $require facets, but “non triggering” access operations allow to bypass them. Shirka merges the constraint facets of all superclasses. In KL-ONE [Goo79], the responsibility of slot refinement is left to the user, as well as the resolution of conflicts resulting from multiple refinements. Objlog however [Dug88] distinguishes slots with the same name if they are not originally defined in the same class and if they have not been declared semantically equivalent. Slots are semantically equivalent if they are multiple refinements of the same slot (same origin) or if they are explicitly declared as such. Semantically equivalent slots are unified as one slot. Objlog provides multiple subclassing as well as multiple representation. The system SHOOD [Ngu91] uses “complete names” to distinguish homonymous attributes with different semantics. The attribute name is extended with the name of the defining class. SHOOD provides multiple instantiation. For multiple specialization it defends the aggregation approach [Rie91]. TROPES [Mar90] (multiple representation) assimilates multiple homonymous slot descriptions, within the classification of a concept, to one slot. No instance may belong to two different concepts. The principle of constraint multiplicity for multiple slot refinement is generally respected in multiple inheritance as well as in multiple representation. Non constraining facets are applied according to multiple inheritance strategies which, in most systems, apply all inherited facets or only the first one encountered, following the order of a priority list. Yafool [Duc86] defines different strategies for the retrieval of a slot value, using inherited $default and $if-needed facets. The application order of reflexes is elaborated. All inherited reflexes are applied. Constraints are verified from the most specific up to the most general. 6.2. Points of view The necessity of describing entities from several points of view was identified first in the KRL project. Each point of view is represented in a separate object, a so-called perspective, so that the whole object appears as an aggregation of all its perspectives. Perspectives serve in KRL as a simulation of multiple specialization and have been applied also in Pie [Gol80] and LOOPS [Bob83]. The aggregation-oriented approach has been formalized in a theory of coreferentiality by Ferber [Fer88]

[Fer89]. The solution of FROME is fundamentally based on the subclassing feature of objectoriented languages, using inheritance [Car88]. Each class being interpreted as a description of its members from a particular point of view, we think that the taxonomic power of class hierarchies combined with multiple representation is sufficiently suited to model points of view. The following systems are based on the same idea. In Objlog as in FROME, the notion of point of view allows a selection of a slot among multiple homonymous slots. In Objlog however, a point of view selection on a frame does not allow to choose a particular refinement of a slot according to a point of view. Non constraining facets are inherited all and applied in depth-first order. The system TROPES, dedicated to the multi-point of view classification of frame instances, organizes the description of a concept in several points of view, each partitioning the concept in disjoint classes. An individual frame belongs to a single class in each point of view. TROPES uses the different points of view during the classification process. Multiple constraints due to slot refinements in different points of view, are ensured by the system. SHOOD also proposes automatic frame classification. Unlike TROPES, the notion of point of view does not seem to be of great importance in the classification process. The notion of point of view in SHOOD corresponds to the multiple instantiation facility: each instantiation link represents (implicitly) a point of view on the object. However, no point of view selection seems to exist on slots or slot refinements. 6.3. Evolution The aggregation-approach for points of view allows a restricted form of instance evolution, by adding or deleting perspectives, through operations like AddPersp and DeletePersp of LOOPS. However, the problem of evolution within a point of view remains. Evolution in the form of specialization of instances is available in Shirka (classification or specialization plus explicit linking with a (single) class), Objlog (explicit specialization and classification rules), and SHOOD (specialization and multiple classification). None of these systems seem to propose a mechanism for modification evolution (cf. §4.2), requiring a “no-more” operation. Only Shirka, when explicitly linking an instance to a class, implicitly overrides the former link, so that an instance can also become more general, or linked with an independent class, provided it satisfies all constraints.

7.Conclusion and perspectives In opposition to other knowledge representation systems, FROME offers a Point of View selection mechanism, which allows an expert to focus on the part of an entity description he is interested in. This selection allows to concentrate on characteristics defined within a particular point of view and on a particular interpretation of characteristics which are shared by several points of view, each of them refining the description independently. FROME provides multiple representation of frames, so that they can be directly linked to classes in several points of view.

Multiple subclassing is not rejected: it is needed for multiple specialization, when the resulting subclass is more than just the intersection of its superclasses, and really refines or adds characteristics. The evolution provided by FROME facilitates instance specialization as well as generalization and modification due to real world change or knowledge improvement. Current work concentrates on automatic classification of frame instances using the point of view, the multiple and evolutive representation features and the reflective properties of the system.

References [Bob77] Bobrow D.G. and Winograd T., “An Overview of KRL, a Knowledge Representation Language,” Cognitive Science, Vol. 1, 1977. [Bob83] Bobrow D.G. and Stefik M.S, The LOOPS Manual, Memo KB-VLSI-81-13, Xerox PARC, 1983. [Car88] Carré B. and Comyn G., “On Multiple Classification, Points of View and Object Evolution,” Artificial Intelligence and Cognitive Sciences, Manchester University Press, Demongeot J., Hervé T., Rialle V. and Roche C.,Eds., 1988. [Car89] Carré B., Méthodologie orientée objet pour la représentation des connaissances, concepts de point de vue, de représentation multiple et évolutive d’objet, Ph.D. dissertation, University of Lille, France, 1989. [Car90a] Carré B., Dekker L. and Geib J.M., “Multiple and Evolutive Representation in the ROME language,” Proc. of the Second International Conference TOOLS, Bézivin J., Meyer B., Nerson J.M., Eds., Paris, 1990. [Car90b] Carré B. and Geib J.M., “The Point of View Notion for Multiple Inheritance,” Proc. of the First Joint ECOOP/OOPSLA Conference, Ottawa, Canada, 1990. [Car91a] Carré B. and Dekker L., FROME The Manual, Technical Report ERA 92, LIFL, 1991. [Car91b] Carré B. and Dekker L., “Inheriting Object-Oriented Features through MetaProgramming, A Frame Extension to ROME,” Proc. of the East European Conference on Object-Oriented Programming, Bratislava, Czecho-Slovakia, 1991. [Duc86] Ducournau R., and Quinqueton J., YAFOOL, encore un langage objet à base de frames, Technical Report no. 72, INRIA, 1986. [Dug88] Dugerdil P., Contribution à l’Etude de la Représentation des Connaissances fondée sur les Objets, Le Langage Objlog, Ph.D. dissertation, University of AixMarseille, 1988. [Fer88] Ferber J., “Coreferentiality: the Key to an Intentional Theory of ObjectOriented Knowledge Representation,” Artificial Intelligence and Cognitive Sciences, Manchester University Press, Demongeot J., Hervé T., Rialle V. and Roche C.,Eds., 1988. [Fer89] Ferber J., Objets et agents: une étude de représentation et de communications en Intelligence Artificielle, Thèse d’Etat, Paris VI, 1989. [Fik85]

Fikes R. and Kehler T., “The Role of Frame-based Representation in

Reasoning,” Communications of the ACM, Vol. 28, No. 9, 1985. [Gol80] Goldstein P. and Bobrow D.G., “Extending Object-Oriented Programming in SMALLTALK,” Conference Record of the 1980 LISP Conference, Stanford, 1980. [Goo79] Goodwin J.W., Taxonomic Programming with Klone, Research Report LITH-MAT-R-79-5, Linköping University, Sweden, 1979. [Hat91] Haton J.-P., Bouzid N., Charpillet F., Haton M.-C., Lâasri B., Lâasri H., Marquis P., Mondot T., Napoli A., Le raisonnement en Intelligence Artificielle, InterEditions, 1991. [Len91] Lenzerini M., Nardi D., Simi M., (Eds.), Inheritance Hierarchies in Knowledge Representation and Programming Languages, Wiley, 1991. [Mae87] Maes P., Computational Reflection, VUB AI-Lab TR 87-2, Ph.D. dissertation, V.U. Brussels, 1988. [Mar90] Mariño O., Rechenmann F., and Uvietta P., “Multiple Perspectives and Classification Mechanism in Object-Oriented Representation,” Proc. of ECAI, Stockholm, 1990. [Mas89] Masini G., Napoli A., Colnet D., Léonard D., and Tombre K., Les langages à objets, InterEditions, 1989. [Ngu91] Nguyen G.T., Rieu D., “Database issues in Object Oriented Design,” Tools ’91, Paris, 1991. [Rec90] Rechenmann F., SHIRKA: Système de gestion de bases de connaissances centrées objets, Manuel d’utilisation, INRIA, 1990. [Rie91] Rieu D., Nguyen G.T., Culet A., Escamilla J., Djeraba C., “Instanciation Multiple et Classification d’Objets,” VIIèmes Journées Bases de Données Avancées, Lyon, 1991. [Rob77] Roberts R.B., and Goldstein I.P., The FRL Manual, Report AIM-409, MIT, Cambridge, 1977. [Weg86a]Wegner P., Classification as a paradigm for computing, Technical Report CS-86-11, Brown University, 1986. [Weg86b]Wegner P., “Classification in Object-Oriented Systems,” ACM SIGPLAN Notices, Vol. 21, no. 10, 1986.