LORE(ID:1337/lor002)Object-oriented language for knowledge representationObject-oriented language for knowledge representation. CGE, Marcoussis, France. Frame-set-based language. Christophe Dony Structures: Related languages
References: in IEEE Software 3(01) January 1986 (Multiparadigm language projects) view details in IEEE Software 3(01) January 1986 (Multiparadigm language projects) view details in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details Intelligence and Database applications has led to the development of a new OOP model that satisfies requirements for expressiveness and efficiency. Extensibility provides true expressiveness without loss of efficiency, which is critical in a language used with large databases. This paper presents the new model that was developed[Caseau87]. Emphasis is placed on the use of a self-description of this model to get a extensible language, and the solution this set and relational approach to OOP may provide concerning multiple inheritance questions. The language is reflective because it holds a description of its model within itself, to which it always conforms. Some examples are given on how to take advantage of such features. DOI Extract: Why Do We Need a New Model for Object-Oriented Programming? Why Do We Need a New Model for Object-Oriented Programming? First, the need is for extended paradigms for knowledge representation. The classical object-oriented model derived from SMALLTALK [Goldberg83] and the actor model, is too narrow to introduce new kinds of sets or relations. Especially, externally defined relations require that the already existing relations of an object-oriented system be explicit. Moreover, the type aspect is not clearly taken into account, in the older objectoriented languages. Though correct operational semantics has been given to the classical multiple inheritance[Touretzky84], inheritance as virtual copy is not a concept powerful enough to handle multiple inheritance conflicts, nor is the delegation principle. We prefer to base inheritance semantics upon types rather than graphs. From a more general point of view, it can be said that most existing object-oriented models have been designed with a local viewpoint about the object, whereas all of our requirements demand a global point of view. Typing, inheritance conflict resolution, and relation manipulation are meaningful only with a global object system. The model presented is concerned with this global database point of view. Extract: THE LORE MODEL 3.THE LORE MODEL 3.1 A Set and Relation Approach to OOP Knowledge representation consists of defining concepts (e.g., table, person), properties attached to these concepts (having four legs, being made from wood, etc.), that will also represent the relations among real world objects, and instances of these concepts (my table, this table, etc.). Our object model allows to perform these operation in an integrated theoretical framework. Here me preference is to build concepts as sets, and to describe them with properties, rather than considering properties as parts of the concept definitions. The membership relation is deduced from two relations: a superset/subset relation among concepts (which is inclusion) and a class/instance relation between instances and concepts. Once defined, concepts are described with properties, represented by relations. Classes are these concepts linked to objects by the instantiation relation. The big difference with other approaches to class hierarchy is that the directed acyclic graph of the superset relation is transformed into a true lattice. This will prove useful for multiple inheritance and means that for any pairs of concepts {a,b}, there exists an "upper(a,b)" node in the "superset" graph that is the smallest node bigger than a and b (there also exists a "lower(a,b)" node). This is obtained with transformations such as: Extract: Reflection Provides LORE Extensibility Reflection Provides LORE Extensibility This section provides an example of reflexivity. A new kind of class is developed whose instances are tuples of an external database. We shall assume that the external database allows the creation of a relation of any given arity, and provides many retrieval mechanisms. Instead of representing the relational knowledge with binary relations, this database is used. On the other hand, these new concepts are used in an object-oriented way to get some inheritance properties. DBSCHEME is a new class defined as a subset of CLASS. We inherit from most the properties of CLASS and only add what is new and retract what is no longer relevant, since we want to store the object in the external database. Then a new kind of restriction, FIELD, is defined, which is included in the set of binary relations. Defining these new kinds of sets and relations allows the use the external databases within our system, in an object-oriented way, as in the following definition: course /sa DBscheme with (field t~h-= range person) (field t~pi¢ range (Maths CS Physics)) (field schedule range time)] [cl isa course teacher Mr Who topic CS schedule (Monday 11.30) ] [c2 isa course topic CS teacher Mr Who] [bzoadcast-=~zse is DBscheme superset course with (field topic range (Math Physics)) (field sLat.ion range 'IV stanion)] [BBC-2 isa broacLcast-course teacher Mr Wellknown topic physics station BBC schedule (Saturday 7.00)] The existing concepts could also have been modified (e.go, adding a creation date to each object), or the existing restrict2ons (e.g., defining methods with demons, such as in FLAVORS). 4.2 LORE is a Compiled Language Compiling is based on "weak-typing". For each instruction, a weak type is a set to which the value obtained by evaluation must belong. This is not necessarily the type of the value but is one of its supersets.Weak-typing of messages is provided by our query semantics. The information provided by this weak-typing mechanism is used by the compiler to choose the correct restriction, before compiling it into underlying code. This choice is made possible each time the weak typing is precise enough to determine one unique restriction. Of course, there remain some instructions where it is impossible to choose the good restriction (this makes them powerful), but the key point is to prevent losing efficiency in all the other cases (95%). in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details |