ORLOG : A Logic For Semantic Object-Oriented Models ... - CiteSeerX

ORLOG : A Logic For Semantic Object-Oriented Models M. Hasan Jamil

Laks V. S. Lakshmanany

Department of Computer Science Concordia University Montreal, Quebec H3G 1M8

Department of Computer Science Concordia University Montreal, Quebec H3G 1M8

Abstract

of data with the introduction of the concept of behavior and methods. The notion of inheritance in OO programming is intimately related to reusability and sharing. The notion of encapsulation brings modularity and implementation independence to this paradigm. It is believed that combining OO concepts with databases will result in clear bene ts [19]. There is currently signi cant interest in object-oriented database (OODB) systems. Much of the research on OODBs was sparked by the need to provide adequate database support for next generation database/knowledge-base applications such as engineering design, software development, and VLSI design. In general, such applications necessitate features such as complex objects, object identity, behavioral aspects of objects, reusability (of designs or software code), and modularity and implementation independence of subparts of the (software) design objects. There have been numerous proposals for objectoriented (OO) data models. Many of them do not take advantage of the experience accumulated by the database community in semantic data modeling. Semantic data models (SDMs) already possess several of the OO features, as well as additional useful features (like relationships and the associated constraints), which have no counterpart in the OO models. Semantically rich and expressive conceptual models can be built by extending the functionality of the SDMs in the direction of database programming so as to enhance software reusability, modularity in design, and programmer productivity. There have been several proposals to this end [2, 5, 7, 8, 9, 14]. Many of the models proposed lack one or the other desirable properties of an OO SDM as stipulated in [9, 10, 17]. For example, (i) the DERDL [8] model does not support methods, object identity, encapsulation, etc.; (ii) methods and encapsulation are not supported in the OSAM/OQL [2]; (iii) in the DK model [9] object identity, n-ary relationships, multiple inheritance, derived objects and global constraints are not supported; and the other proposals (e.g., [7]) concentrate mostly on ways of specifying constraints in OO models. In this paper we present an OO SDM called Object Relationship model, or OR model. It incorporates a balanced mix of the features in SDMs and OO models. It also incorporates a limited form of security features [3] in the form of privatization of methods and attributes and the notion of legal access to objects and methods. In addition to developing a conceptual model, unlike many other proposals, we go one step further and formalize the logical foundations of our model. Logical foundations are important for (i) providing a clean declarative semantics for the model, (ii) enhancing productivity by encouraging high level database programming, (iii) oering a hierarchical approach

We argue that powerful models for supporting next generation database and knowledge-base applications can be built by extending semantic data models (SDMs) in the direction of Object Oriented (OO) modeling. SDMs possess several of the OO features, as well as additional useful features (e.g., relationships and the associated constraints) which have no counterpart in the OO models. We present a conceptual semantic OO data model called Object Relationship (OR) model. OR model captures most of the semantic modeling as well as OO modeling features needed for the new database applications. As a second step, we lay down the logical foundations of the OR model and develop a logical language called ORLOG in the spirit of deductive database languages such as Datalog, providing a basis for high level OO programming. Use of a logical language like Orlog opens up the possibility of applying knowledge representation techniques for semantic and OO data modeling. We illustrate our conceptual and logical models with a substantial design example. Keywords: semantic data modeling, object-oriented databases, declarative semantics, logic based knowledge representation.

1 Introduction Semantic data models (SDM) are very powerful in specifying database structures and schema at varying levels of abstraction. SDM features have been found to be extremely useful in the modeling and development of data and knowledge base systems, as a design technique and documentation/communication tool. SDMs tend to hide the implementation speci c details while focusing on the logical organization of the databases. In that way they serve as a great conceptual design tool as required by the three level architecture of databases. Programming with taxonomically organized data which are encapsulated with operations has led to Object Oriented (OO) programming. The OO programming paradigm is not only able to handle and manage complex and hierarchically structured data, it is also able to express the dynamic aspects

 This author's research was supported in part by grants from the Canadian Commonwealth Scholarship and Fellowship Plan and the University of Dhaka, Bangladesh. The author is on leave from the University of Dhaka, Bangladesh. y This author's research was supported in part by grants from the Natural Sciences and Engineering Research Council of Canada and the Fonds Pour Formation De Chercheurs Et L'Aide A La Recherche of Quebec.

1

to implementation, and (iv) providing a basis for query optimization. Finally, providing a logical basis for the model also opens up the possibilities of applying logic based knowledge representation techniques to semantic and OO data modeling. There have been several attempts (e.g., see [1, 13, 16]) at combining logic programming and OODBs. As pointed out in [13], most of the approaches either do not support object identity, inheritance or typing; or restrict the type of complex objects and queries allowed, or sacri ce declarativity. (See [13] for a detailed survey.) The F-logic model proposed in [13] is a very nice declarative formalism for OODBs. It provides a foundation for further research in this direction. It by far captures most of the OO features in a logical framework, compared to similar proposals. Among others, a strength of F-logic is that it uses rst order terms to capture object ids. This eliminates the need for a system de ned function NEW to generate new object ids. F-logic also allows variables to range over type names and hence supports schema browsing. However, the semantics of F-logic is complex. Moreover, F-logic treats everything as an object; it thus forces concepts like basic values and relationships to be treated as objects, which appears to be unnatural from a SDM viewpoint. The notion of encapsulation, in our opinion, is not fully supported. Constraints are not part of the model and are left to the user. We propose a language, called ORLOG, as a logical formalization of our OR data model. Orlog has a very simple rst-order semantics. Orlog also supports global and local constraints, relationships, and basic values. Several forms of re nement and extension of methods are also addressed. In comparison with F-logic, Orlog has a simpler semantics. However, it does not support schema browsing. Indeed it supports a balanced mix of OO and SDM features, while keeping the sematics simple. We put forward the notion of admissible databases which essentially captures the true spirit of encapsulation. In Section 2 we discuss the OR model and illustrate its features using a substantial design example. In Section 3 we develop the language Orlog, give its syntax and semantics, and develop the notion of admissible databases. We also illustrate the applicability of Orlog by reference to the design example in Section 2. Then, the conclusions are given in Section 4.

types in the subclass hierarchy { inheritance can be multiple, and non-monotonic if so speci ed explicitly using some form of modi ers, (viii) descriptive attributes or methods in relationships, (ix) encapsulation, (x) method polymorphism { overloading, extension, re nement, and overriding, (xi) local and global integrity constraints and type constraints, (xii) con ict resolution of constraints and attributes, as arising in multiple inheritance, etc. We next illustrate these features using a detailed example. Example: Figure 1 shows a partial scheme of the McDonnel Douglas aircraft design database using OR-diagrams. Only the database scheme is shown without any instances. The legends in Figure 1 describe the meanings of the symbols used in the diagram.

2.1 Components of the OR Model Objects: An object is a distinct entity with a unique iden-

ti er. It has intrinsic characterizing properties called attributes. It stores data in attributes in order to save its state, and responds to instructions for carrying out speci c operations on its attributes when a request for that operation, a message, is received by the object. A message speci cation always includes a context (i.e. a reciepient) saying which object should receive and respond to that message. The set of operations that can be performed on an object are determined by the object. Thus an object exhibits its behavior in terms of these operations. In the example, passengeraircraft, DC10-30, seat, etc. represent (classes of) objects. Class and Instance: In the OR model, objects are grouped into classes and classes are organized in a specializationgeneralization (SG) hierarchy. In the spirit of the ER model, this leads to specialization (in most of the cases) where the classes lower in the SG hierarchy inherit the properties of those higher up. In our example, class DC10-30 is a specialization of the class passengeraircraft. Class DC10-30 has all the properties of the class passengeraircraft, and some more. Classes have objects as their instances, which may have specialized properties. The SG hierarchy naturally induces (super)class/subclass associations among classes. For example, with respect to class DC10-30, passengeraircraft is a superclass and MD10 is a subclass. It is possible for an object class or an object to be part of multiple (super)classes at the same time, if it shares properties with each of these classes. In our example class MD10A is a subclass of the classes cargoaircraft and MD10. Attributes and Methods: The properties of an object are speci ed using attributes. Attributes are named data which describe the properties of an object/class. For example, in Figure 1, company in passengeraircraft, and takeoen in DC10-30 are attributes. There are two kinds of attributes in the OR model. The kind of attributes that store data explicitly in the database are known as extensional. Intensional attributes have a procedure associated with them in order to compute the value of the attribute at run time. For example, in the object class passengeraircraft, company is an extensional attribute, while tseat is an intensional attribute. The latter represents the total number of seats in an aircraft. This is dependent on the oor space left after placing the kitchens in the aircraft and on the type of seats that are being used in dierent accommodation classes in the aircraft. Since the values of intensional attributes are computed using a procedure, in terms of functionality they capture the concept of methods in OO models. Methods have an underlying context, which is the object/class or relationship where they are operative, and a set of typed input arguments. Thus, a message should have a matching context and arguments in or-

2 OR Model for Conceptual Modeling In this section we shall present the OR model. First we summarize the important features of our model. Subsequently, we shall explain all these features using a substantial design example for the aircraft industry. The OR model is a semantic data model which extends conventional SDMs by incorporating important OO features. The features in the OR model are represented using OR-diagrams, which play a role analogous to that played by ER-diagrams for the ER model. The OR model supports the following features: (i) extensional and intensional objects, (ii) extensional and intensional attributes { the latter being known as methods according to OO terminology, (iii) complex typing for objects and attributes, (iv) basic and constructed values, (v) associations among classes of objects in the form of relationships, between attributes and objects/classes called aggregation, and between classes of objects known as hierarchy or subclass association, (vii) inheritance of attributes/methods and their

2

tseat(classcat):integer

engines : integer

maxtilt : real

facility : {string}

legspace : real

extensional attribute company : string calss : string

type part intensional attribute/method

rule/constraint part

name part

range : integer

tseat : integer

tseat : integer

seat

space : real

extensional object

rule / constraint part

kitchens : integer

passengeraircraft

useseat

classcategory

intensional object

attribute/method reintroduction

cockpit:mitshubishi

section : string

radar : comsat

attribute/method inhibition

relationship symbol

name rule part

section : string

radio : string takeofflen:integer

DC10-30

attribute/method blocking

company : string

company : string

gspeed : integer

usebody

floor(string):real

intensional relationship symbol

floor : real radio : string

many-many relationship or object attribute connection

object to private attribute/ method connection

hierarchy or subclass association

one-many relationship connection

usekitch

MD10

kitchens : integer

fuel : grade1 engine:rollsroyce

body cockpit : bombardier facility : {string}

kitchen

radio : string wing : highwing

MD10.cockpit:mitshubishi

cargoaircraft

space : real

standard : string

Legend B100.kitchens:intg cargocap : integer

wheelsys:dunlop3

strategicbomber

tseat : integer

bombs : {string} MD10A

refuelsys:shell weapontrans : GE

tseat(classcat):integer

weapon : {string}

B100.radio:string commsys:siemens radar : comsat

range : real

country:string missileunit : integer

DC10-30.kitchens:intgr range : integer

cockpit:bombardier

B100

bomberunit : string

computer : cray

airforce : string

Figure 1: OR diagram for the McDonnel Douglas Aircraft Design Database. der to be accepted by a method. An accepted message leads to a successful invocation of a method (procedure). The implementation of a method is hidden in its class/relationship. E.g., tseat is a method in the object class passengeraircraft. Types: Attributes and methods in an object/class have a type. A type of an attribute speci es what type of value (described next) an attribute can have. A type associated with a method, also called a signature, is a tuple of the types of its input arguments and the type of the computed value, of the form 1  : : :  n !  . The types associated with the method tseat in passengeraircraft are passengeraircraft!integer, and passengeraircraftclasscategory!integer, where passengeraircraft is the type of the context and is implicit, classcategory is the explicit input argument type, and integer is the type of the output value. Note that OR model allows multi-typing for methods. This is essential for supporting polymorphism, described later. When a method tseat is invoked, which method type will be activated will now depend on the speci cation of the message. The type of an object is composed of its constituent property types { attribute and method types. Hence the type of the class passengeraircraft is . Values: In the OR model, there are two types of values { basic values and constructed values. Many of the existing OO models (e.g., see O2 model [14] and F-logic [13]) treat basic values also as objects. We believe this is unnatural from a SDM viewpoint and make a clear distinction between them. Basic values are atomic elements of basic domains such as integer, real, string, etc. Basic values are just values, not objects, and are naturally treated as just values. They do not participate in any SG hierarchy (described next) unlike

real objects/classes. On the other hand, objects are values of constructed types. Constructed or complex types of values may be built from the basic ones. Thus, the value that can be associated with an attribute may be simple or structured. For example, the value of engines in passengeraricraft is basic, the value of the attribute weapons in the class strategicbomber is set structured, while engine in DC10-30 refers to another object of type rollsroyce and thus is of constructed type. Associations: In the OR model, associations are of three kinds. Aggregation association results when objects are used as values of attributes or methods, thereby forming an attribute to object association. Since the method has the handle on the object through its id, it can now refer to its properties, and those properties may arbitrarily refer to properties of other objects in turn, which are essentially aggregations of properties. Using aggregation, it is possible to have nested data structures of any depth, even recursive structures. An instance of aggregation in our example is refuelsys in the class B100 which refers to an object shell8 of constructed type shell (for want of space, the type shell and its instance shell8 are not shown in Figure 1). A second kind of association is the hierarchy or Is-a association between objects and classes, and between two classes, resulting from the SG hierarchy. The third kind of association is the relationship association among classes of objects. Relationships among classes of objects may be n-ary in general. We contend that relationships have a character distinct from classes of objects. Thus they are relations involving dierent classes of objects, and do not participate in the SG hierarchy. As in the relational model, the objects in the participating classes form the key of the relation. Relationships can be one-one or one-many. In gure 1, useseat is a 3-ary relationship involving the classes passengeraircraft, seat and classcategory, which says that an aircraft

3

mentation independence, modularity, and abstraction. In our example, the attributes computer, weapons, airforce and bombs are private to the class strategicbomber and are not visible from outside. Suppose the method weapons makes use of the attribute airforce to decide the set of weapons and bombs that the aircraft will carry. The methods bomberunit and weapontransport in B100 then use the methods weapons, bombs and missileunits to decide the kind of bomb transport and launching system to be installed in the aircraft. Here the methods weapons, bomberunit and weapontransport use private methods to respond to a message. Although these attributes and methods are inheritable, no other object or relationship can access these methods except via inheritance. Method Polymorphism: Methods in the OR model are polymorphic. Let us consider the family of methods \tseat". The method tseat in passengeraircraft and in all its subclasses wherever it is applicable, computes the total number of seats in the aircraft. Yet again, tseat(classcategory) re nes the method tseat, by overloading it by giving it the argument classcategory, which then computes the total number of seats in certain classes in a given aircraft. On the other hand, the method tseat in the class seat represents the total number of seats that are in use in dierent aircraft, and, hence, has a completely dierent meaning than the previous versions. All these forms of overloading of method names are known as method polymorphism. Polymorphism aids re nement and extension of behavior through overloading, and enhances reusability. Rede nition is also possible in the OR model. For example, in Figure 1, the attribute range in MD10A is rst inhibited (withdrawn), and then rede ned with a dierent type, i.e. real. In general, rede nition only shares the attribute or method name in immediate superclasses. It can completely change the type or the signature of the corresponding attribute or method, as well as its implementation. Constraints: Type de nition of attributes and signature of the methods can be viewed as constraints on the type of value that attributes can have and the type of input/output arguments the methods may accept and return. Since the type of objects, or relationships, is the composite of their attribute types and method signatures, the type constraints above also impose corresponding constraints on the scheme or type of the objects or relationships. Other forms of constraints include integrity constraints (IC). Some ICs may only involve attributes/methods applicable to a class or relationship, or only to classes participating in a relationship. E.g., functional dependencies and referential ICs t into this category. Other ICs may involve several classes, methods, and relationships. For example, we may de ne the following constraints: (i) a global constraint saying all aircraft should be able to cross the Atlantic (range > width of the Atlantic); and a set of local constraints such as (ii) the total number of seats in passengeraircraft should be more than 100, and (iii) no passenger seats are allowed in a cargoaircraft, etc. Similar to attributes and methods, the local constraints in objects get inherited down the SG hierarchy. There can be con icts among dierent constraints that the objects and relationships must satisfy. For instance, if in our example we move constraint (ii) to the global level, the cargo liners will not be able to satisfy that constraint. In the example, constraint (ii) is meaningful for all passenger aircraft. But since MD10A is basically a passenger aircraft that is being redesigned as a cargo carrier, constraint (ii) does not make sense here. The situation can be more complex. Constraint (iii) de ned for cargo aircraft is in clear con ict with constraint (ii) if they are both monotonically inherited in MD10A. Such con icts are resolved by attaching priority to constraints. In the OR model constraints are placed in different strata. The lower the stratum the higher the priority.

uses a type of seat in possibly more than one accommodation class ( rst class, club class, etc.). Methods in Relationships: Many OO models do not support relationships as a rst class component, and most of the models which do, do not support methods in the relationships. In the OR model, relationships may have descriptive attributes/methods in exactly the same way as objects. The only dierence is that in the case of methods of objects, the context is the object (or class) and the type of the object/object class takes part in the signature of the method. In the case of relationships, the context is the key of the relationship and, hence, the type of this key takes part in the method signature instead. Inheritance: The objective of organizing objects in a hierarchy of classes is to share properties of the objects in useful, economical, and meaningful ways. Properties of superclasses can be inherited by their various subclasses. The class DC10-30 in our example inherits all the attributes in the class passengeraircraft. In other words, the attributes and methods that are available in passengeraircraft are also available in DC10-30. In this case, the inheritance is called monotonic. However, it is possible that a subclass or instance may not inherit all the properties from a superclass, because they do not make any sense in the subclass. For example, suppose that the class MD10 is a redesigned version of DC10-30 with almost no changes in the basic design of DC10-30, except perhaps a minor change in body structure and a radio replaced by a computerized radar (see Figure 1). Due to the merger of McDonnel and Douglas, the company name is changed to McDonnel Douglas. The DC10-30 s are still manufactured and maintained by the Douglas, but the MD family belongs to the new company. Clearly the company name in the attribute company in passengeraircraft is not applicable to MD10. Somehow, the inheritance of the attribute company should be made ineective in MD10. The way this situation is handled in the OR model is by using a non-monotonic inheritance. There are two mechanisms for achieving non-monotonic inheritance { inhibitance and blocking. An inherited method in a subclass can be withdrawn by inhibiting it. On the other hand, inheritance of a method can be prevented by blocking it in the superclass. For instance, in MD10 we inhibit or withdraw the method radio (which would otherwise be inherited) from the superclass DC10-30. The methods radio and kitchens are selectively blocked in MD10A for B100, while cockpit in MD10A is blocked for all subclasses of MD10A. Reintroduction is a mechanism for inheriting a method from an ancestral superclass as long as it is not blocked. In MD10A, the radio from the ancestor DC10-30 is reintroduced as the communication instrument in place of the costly radar system. Since an object class can be a subclass of multiple superclasses, multiple inheritance is possible. In that event the subclass inherits properties from all its superclasses. Encapsulation: In the OR model the implementation of all the intensional attributes, or methods, is private to the object/class or to the relationship where they are de ned. Users only see the interface to the objects or relationships, through which the set of methods applicable, as well as their signatures, are visible. It is possible to de ne some attribute or method to be private to the object/class or relationship. Private attributes and methods are not visible from outside, and are only accessible by the object/class or the relationship in which they are de ned, for the implementation of other methods in it. This provides a limited form of security addressed in some research work [3]. The concept of providing an interface to objects and relationships through which all legal methods are visible, and of localizing the implementation of the methods to the objects or relationships, is known as encapsulation. Encapsulation enhances imple-

4

sorted symbols C for individual constants, (4) an in nite set of function symbols M for method names, (5) an in nite set of many sorted id variables VO , (6) an in nite set of many sorted symbols VB for basic domain or individual variables, (7) a nite set of symbols TB for basic type names, and (8) an in nite set of symbols TO  IO for object or constructed type names. Each function symbol m 2 M is associated with a set of types of the form 1  : : :  n !  and corresponding arities. This sort of multityping is necessary for supporting method polymorphism. Also, each predicate in R is associated with a type 1  : : :  n . The alphabet also includes usual logical connectives and quanti ers (_, ^, 8, 9, :, !, etc.). We let Vb = C [VB denote the set of all basic values, Vo = IO [VO be set of all constructed or objectV values , V a = V b [ Vo be the set of all atomic values, Vs = 2 b [ 2Vo be the set of all set structured values, and nally let V = Va [ Vs denote the set of all possible values in L. Let V = VO [ VB denote the set of all variables. Now let T = TB [ TO = f1 ; 2 ; : : :g, be the set of all basic and constructed type names in L. Note that object ids have the duality of representing an actual object or the type or class of (other) objects. The reason for allowing this duality will be clear when we will discuss the semantics of Orlog. Formulae of Orlog are built from the set of terms T by means of the logical connectives and quanti ers. We will follow the convention of using strings starting with upper case letters for variables and strings of only lower case letters for constants in this paper. A value term, or v-term, is of the form Method = Result or Method = fResult1 ; : : : ; Resultk g. In general, Method is of the form m(Q1 ; : : : ; Qn ), where m is an n-ary function symbol in M and each Qi is a value in Va , and Result; Resulti 2 V . If m has no arguments, i.e. n = 0, then we will drop the parentheses for convenience. We will also distinguish between the v-terms applicable to objects and v-terms applicable to relationships. The types that are associated with m in an object v-term are of the form o  1  : : :  n !  , where o is in TO , and i ;  2 T . On the other hand, the type of m in a relationship v-term will look like o1  : : :  ok  1  : : :  n !  , where oi 2 TO and o1  : : :  ok is the type of the relationship predicate R for which the v-term is de ned. We require that the set of object method names and set of relationship method names be disjoint to facilitate unique reference to methods. A type term, or t-term, is of the form [modifier] Methodtype : ftype1 ; : : : ; typem g, where the Methodtype is of the form m(t1 ; : : : ; tn ). Each ti and typej is any type name in T , for i = 1; : : : ; n, and j = 1; : : : ; m. The modi er is one of [Q]#; [Q]$; [@][Q]%; @, where Q is an oid and [.] means optional. E.g., Q%M (T1 ; : : : ; Tn ) : fType1 ; : : : ; Typem g is a type term. The modi ers are used to achieve non-monotonic inheritance with respect to method implementations as well as signatures, in a manner to be described shortly. As with v-terms, we distinguish between object t-terms and relationship t-terms. Finally, the set T of terms in the language L consists of the following terms:

Global constraints are placed in stratum 0 and, hence, have the highest priority. The local constraints are in stratum 1 and the inherited constraints in stratum 2. Thus, if an inherited constraint is in con ict with the local one, the local one is given preference. E.g., to solve the con ict in our running example, we copy constraint (iii) from cargoaircraft to MD10A, which makes it local, giving it a higher priority than constraint (ii). In the case of multiple inheritance, con icts may also arise between inherited attributes because of dierences in types, values, implementations or the semantic meaning. This form of con ict can be eectively resolved using inhibition and blocking. In our example, the method cockpit which is inherited from cargoaircraft and MD10 is in con ict in MD10A. So we selectively inhibit MD10.cockpit (notice the pre xing of the class name in front of the attribute name) in MD10A to favor the inheritance of cockpit from cargoaircraft. Similarly, selective blocking shown in the class MD10A and discussed earlier, can also be used to resolve such con icts. Accessibility: In the OR model the only way to reference the properties of the objects is by invoking the attributes/methods using messages. The set of methods that are visible from outside the objects are the only ones that can be invoked. There can be methods in objects and relationships which are private to them, and thus are invisible from the interface. Also, not all methods that are visible through the interface are always available. We require that only relevant methods can be invoked. A method is relevant if the objects or relationships involved are related. Two classes/objects are related if they are involved in a hierarchy association, a relationship association, or an aggregation association. For example, the object class B100 or its instances are related to DC10-30 through hierarchy association (but not to the speci c instances of DC10-30). The class B100 is related to seat through relationship association useseat. The attribute engine in DC10-30 is of type rollsroyce (aggregation), hence DC10-30 and rollsroyce are related. The related objects or relationships are allowed to refer to the public properties of each other, and such accesses are called legal accesses. The notion of legal access is thus in uenced by the notions of inheritance (monotonic/non-monotonic), associations and encapsulation. For complete details on the OR model, the reader is referred to [12].

3 ORLOG { A Logical Formalization of the OR Model In this section, we develop the logical foundations of the OR model. To this end, we propose a new logic called ORLOG. Orlog provides a declarative semantics and a sound theoretical basis for the OR model. Similar to F-logic [13], Orlog has a higher order syntax while the semantics is rst-order. In the following sections we give the syntax and semantics of Orlog. We illustrate the features of Orlog with an example. Finally, we propose the notion of admissible databases/programs in Orlog. While several features of Orlog have been inspired by the F-logic of Kifer et. al. [13], the semantics of Orlog is quite dierent and is simpler.

1. An is-a term, is of the form P Is-a Q, where P and Q are oid s. Is-a terms are used to de ne subclass relationships or hierarchy associations among objects. 2. An object term, or o-term, is of the form P [E1 ; : : : ; En ], n  1, where P is an oid, and each Ei is an object vterm. Here, we call P the descriptor of the o-term. 3. A relationship term, or r-term, is of the form R[E1 ; : : : ; En ], n  1, where R is a predicate symbol

3.1 Syntax of ORLOG Orlog is a language L with an alphabet consisting of (1) an in nite set IO of many sorted symbols (called oid s for object identi ers), (2) an in nite set of typed predicate symbols R each with a xed arity n, (3) an in nite set of many

5

of arity n in R, and each Ei is a relationship v-term. Here, we call R the descriptor of the r-term. 4. A constraint term, or c-term, is of the form P (T1 ; : : : ; Tn ), n  1, which represents typing constraints for methods, where each Ti is an object t-term when P is an oid, and Ti is a relationship t-term when P is a predicate symbol in R. (Again, we call P the descriptor of the c-term.) The signature terms, or typing c-terms, are used to describe the types of the arguments with which the method can be sensibly applied in an object, or a relationship set. By the type of the method we mean the input/output speci cation 1  : : :  k !  for any method m. All i s are understood to be the input argument (implicit and explicit) types, and  is the type of the output returned by the method. The set of modi ers have the following connotations: (i)# denotes inhibit, % denotes block, $ denotes reintroduction, and @ denotes private. The intended meaning of the notions of inhibit, block, reintroduction and private is discussed in detail in Section 2. Private methods are allowed in order to model encapsulation thereby providing implementation independence. For obvious reasons, except for @, other modi ers are not allowed in conjunction with methods de ned on relationships. 5. A participation term, or p-term, is of the form R  [!]T1 ; : : : ; [!]Tn , where R 2 R and Ti 2 TO , for i = 1; : : : ; n. Intuitively R  T1 ; !T2 ; T3 means R is a relationship involving classes of objects of type T1 , T2 and T3 , which is many-one from T1 and T3 to T2 .

The partial ordering O on D de nes a recursive and acyclic subclass association on the objects in the domain D. Intuitively, a O b means that object/class a is a subclass (or instance) of the class b. The relation O is not de ned on the elements of the basic value domain B, simply because they do not participate in the SG hierarchy. Since O is a partial order, it properly models the fact that the SG hierarchy is acyclic. We use the notation [A ; B ] to denote the set of all partial functions from A to B . The function Id interprets each symbol in L as follows:

 Id associates each object id i in IO with a unique object in O of appropriate sort, i.e. Id (i) = o 2 O.  Id maps each constant c of sort  in C to an element of the corresponding basic domain D , i.e. Id(c) 2 D  B.  Each basic type name  in TB is associated with a basic domain of the same type, and each constructed (object) type name  is associated with an object o 2 O that encodes the domain of objects of type  in O. That is, Id ( ) = D  B for  2 TB , and Id ( ) = o 2 O for  2 TO , where o is the semantic counterpart of the 1 object type  .

 Each symbol R in R of type 1  : : :  n is assigned a relation on D1  : : :  Dn , i.e. Id (R)  D1  : : :  Dn .

 Each symbol m in M is associated with a set2 of partial functions of the form f : Do1  : : :  Dok  D1  : : :  Dj ; [D [ 2D ], where there is exactly one such function in the set for a xed type associated with m. That is, Id (m)  [1 k=1;j=0; [Do1  : : :  Dok  D1  : : :  Dj ; [D [ 2D ]]. Here, oi 2 TO , i = 1; : : : ; k, and l 2 T , l = 1; : : : ; j .

The formulae of L are de ned as follows. Each term in T is an atomic formula, or simply an atom. A literal is either an atom or its negation. Every literal is a well formed formula (WFF). If F and G are well formed formulas and X is a variable, then so are F ^ G, F _ G, :F , (F), 8X (F ), 9X (F ), and F ! G. A formula that contains no variables is called a ground formula.

Note that the set of partial functions associated with m by Id relates m to a unique function for each type associated with m. This helps us overload method names and re ne them by allowing them to accept any number of arguments, and use dierent implementations for each type associated with the same method name. Furthermore, we also allow one function per type. E.g., we can de ne a method child with a signature person(child(year):fpersong) which refers to all the children of a person in a given year, and another method child with a signature person(child(spouse):fpersong) which refers to the set of children with a given spouse. (Here person is the context of the method.) Note that (i) for methods m de ned in objects the index k = 1 and Dok refers to the implicit argument (the object acting as the context for the method); (ii) for methods in relationships, k  1 and in this case Do1  : : :  Dok refers to the (explicit) key of the relation R of type 1  : : :  k . In this case, the key acts as the context of the method. Also, note that a method may return a single or a set structured value, depending on its signature. We next consider the function Is .

3.2 Semantics of ORLOG

A semantic structure S of the language L is a 4-tuple hD; O ; Id ; Isi, where D is the domain of interpretation, O is a partial order on domain D, and Id and Is are two interpretation functions which assign meaning to the symbols in L. Intuitively, D includes the objects and basic values, needed to interpret the oids and constants in L. The partial order O is the semantic counterpart of the is-a association. The function Id interprets each symbol in the vocabulary of L into the data concept it is intended to model, while Is relates each such symbol to its type, or signature. Formally, the domain D of the semantic structure S includes (i) a set of objects O, (ii) a set of elements B corresponding to basic values, and (iii) a set of elements, one each corresponding to each type name  2 T . For simplicity and clarity, we suppose that the latter set in (iii) above is T itself. Clearly, there is no loss of generality in doing so. So we can suppose that D = B [ O [ T . Notice that D includes the domain of elements D corresponding to each type  2 T . In order to keep the semantics rst-order, we treat objects and classes as well as subclasses and instances in a uniform manner. Thus, an object could be viewed as an instance of its superclass object as well as a subclass of instances below it in the SG hierarchy. This mirrors a standard trick in mathematical logic [6] which is adopted here in order to provide a rst-order semantics for a language which is syntactically higher order. Models such as F-logic [13] and \Higher-Order" logic [16] also follow this approach.

 Is acts as the identity function on each oid i 2 IO , i.e. Is(i) = i 2 TO . 1 Note that we use object ids  2 TO  IO to represent object types that are associated with their semantic counterpart { the actual object o 2 O that the id  represents. It is useful to think of o as a concise representation of the domain corresponding to all its instances in the structure S . 2 Recall that each method has a set of types associated with it.

6

 Each constant c in C is associated with its intended type, i.e, Is(c) =  , for some type  2 TB .  Is acts as the identity function on type names, i.e. Is( ) = ; 8 2 T .  Each predicate symbol r 2 R is assigned its type, i.e, Is(R) 2 TOk , where k is the arity of R.  Each symbol m in M is associated with a set of type tuples of the form < o1 ; : : : ; ok ; 1 ; : : : ; j ; ft1 ; : : : ; tn g >, which represent the type o1  : : :  ok 1  : : :  j ! ft1 ; : : : ; tn g. That is, Is(m)  [1k=1;j=0 [TOk  T j  fTB [ 2T g].

 For an o-term of the form P [m(Arg1 ; : : : ; Argn ) = V alue], S j= P [m(Arg1 ; : : : ; Argn ) = V alue] i   

The functions Id and Is assign meaning to each symbol in the language independently of each other. The data concepts into which symbols are interpreted by Id should be consistent with the types associated with these symbols by Is. The following well typing conditions enforce this consistency3 .



 For each constant c in C , Id (c) 2 D , where  = Is (c)

is the type of c and D is the domain of  . That is, each constant is mapped to an element of a domain of its intended type.  For an object method m, an object o 2 O, and elements p1 ; : : : ; pk 2 D, if Id(m)(o; p1 ; : : : ; pk ) is de ned, then (i) there is a type tuple of the form < o ; 1 ; : : : ; k ;  >, or of the form < o ; 1 ; : : : ; k ; ft1 ; : : : ; tl g >, in Is (m), where o is the type of the context o and i is the type of pi , i = 1; : : : ; k, and (ii)  (ft1 ; : : : ; tn g) is the type (set of types) associated with the output Id (m)(o;p1 ; : : : ; pk ) of the method.  Similarly, for a relationship method m, a relationship predicate R 2 R, objects o1 ; : : : ; oj 2 O, and elements p1 ; : : : ; pk 2 D, if Id(m)(o1 ; : : : ; oj ; p1 ; : : : ; pk ) is de ned then (i) there is a type tuple of the form < o1 ; : : : ; oj ; 1 ; : : : ; k ;  >, or of the form < o1 ; : : : ; oj ; 1 ; : : : ; k ; ft1 ; : : : ; tn g >, in Is (m), where ol is of type of ol , l = 1; : : : ; j , and pi is of type i , i = 1; : : : ; k, and (ii)  (ft1 ; : : : ; tl g) is the type (set of types) associated with the output Id (m)(o1; : : : ; oj ; p1 ; : : : ; pk ) of the method. Also, the type tuple of the relation R is < o1 ; : : : ; oj >, i.e. Is (R) = < o1 ; : : : ; oj >.  For each R in R, if the type of R is Is (R) =< 1 ; : : : ; n >, then Id (R)  D1  : : :  Dn .

Id (m)( (P );  (Arg1 ); : : : ;  (Argn )) =  (V alue). For an r-term of the form R[m(K1 ; : : : ; Kk ; Arg1 ; : : : ; Argn ) = V alue], S j= R[m(K1; : : : ; Kk ; Arg1 ; : : : ; Argn ) = V alue] i Id (m)( (K1); : : : ;  (Kk );  (Arg1 ); : : : ;  (Argn )) =  (V alue). For a typing c-term for an object P of the form P ([modifier] m(Arg1 ; : : : ; Argn ) : fType1 ; : : : ; Typek g), S j= P ([modifier]m(Arg1; : : : ; Argn ) : fType1 ; : : : ; Typek g) i <  (P ); Arg1 ; : : : ; Argn ; fType1 ; : : : ; Typek g > 2 Is (m). For a typing c-term of a relationship R of the form R([modifier]m(K1; : : : ; Kk ; Arg1 ; : : : ; Argn ) : fType1 ; : : : ; Typek g), S j= R([modifier]m(K1; : : : ; Kk ; Arg1 ; : : : ; Argn ) : fType1 ; : : : ; Typek g) i < K1 ; : : : ; Kk ; Arg1 ; : : : ; Argn ; fType1 ; : : : ; Typek g > 2 Is(m). For a p-term R[!]P1; : : : ; [!]Pn, S j= R [!]P1; : : : ; [!]Pn i R is a relation of type P1  : : :  Pn . Furthermore, the eects of \!" representing a many-one constraint, are captured as follows. E.g., S j= R  P1 ; : : : ; [!]Pi; : : : ; Pn i 8t1 ; t2 2 Id (R); t1 [P1 ; : : : ; Pi?1 ; Pi+1 ; : : : ; Pn] = t2 [P1 ; : : : ; Pi?1 ; Pi+1 ; : : : ; Pn ] ) t1 [Pi] = t2 [Pi ], where we use the usual notation for restrictions of tuples, from the relational model [18].

Let  and be any formulae. Then - S j=  ^ i S j=  and S j= . - S j= : i S 6j= . - S j= (9X ) if for some  that agrees with  everywhere, except possibly on X, S j= . Satisfaction of other formulae can be obviously derived from the above. If is a closed formula, its meaning is independent of a variable assignment, and its satisfaction in S can be simply written as S j= . The semantic structure S is a model of if S j= . If ? is a set of sentences and  a sentence, then ? j=  i  is true in every model of ?.

3.3 ORLOG Databases and Admissibility

A variable assignment  : V ! D is a function that assigns each basic domain variable X an element of B of appropriate sort, and assigns each id variable X an object from O. Variable assignments can be extended recursively to all terms in T in the obvious manner. Let S be a semantic structure and  be a variable assignment. A term T in L is true under the semantic structure S with respect to the variable assignment  , denoted S j= T, i S has an object, relationship, or a value with properties speci ed in  (T ). Formally:

An Orlog database, or program, D is a set of Orlog formulae in the form of Horn clauses [15]. Not all databases are admissible. To be considered admissible the formulae in Orlog are required to respect the legal access property as described in Section 2. If a typing c-term is de ned to be private using the modi ers, then the typing c-term and its corresponding o- or r-term is only de ned within the object or relationship, and is not accessible from outside that object or relationship. Similarly methods are unavailable in parts of the SG hierarchy whenever they are explicitly withdrawn/prevented using the modi ers (using inhibit and block). Since our language is logic, for programming of methods and constraints, we adopt the (Horn clause) style of programming used in logic programming and deductive databases [15, 18]. We propose the following de nitions. De nition 3.1: An atomic c-term, which denotes a method signature, is locally de ned if it is de ned to be private using the modi er @, otherwise it is globally de ned. A c-term is de ned in a subclass if (i) it is de ned in its superclass and is not inhibited or blocked, or (ii) it is reintroduced in the subclass. We use the convention that an o-term or r-term is locally (globally) de ned if its corresponding c-term is. 2

 For an is-a term Q Is-a P, S j= Q Is-a P i  (Q) O

 (P ). This says that object  (Q) is a subclass of object  (P ), equivalently an instance of  (P ), in the semantic structure S 4 .

3 Some of our well typing conditions are reminiscent of those of F-logic [13]. However, since our language and semantic structure are quite dierent from those of F-logic, there are important dierences between the two sets of well typing conditions. 4 Recall the dual treatment of instances and subclasses. This is important for keeping the semantics rst-order.

7

c-terms:

md10a[cockpit = bomberdier-b56, cargocap = 20000, range = 5000.00]. narrowbody[foor("nose section") = 300.00]. t1[space = 30.00]. s1[legspace = 8.0, maxtilt = 60.00, facility = f"stereo", "table", "lamp"g, space = 12.00]. usebody[passengeraircraft = md10, body = narrowbody]. useseat[passengeraircraft = md10, classcategory = fc, seat = s1, section(md10, fc, s1) = "nose section"]. usekitch[passengeraircraft = md10, kitchen = t1, section(md10, t1) = "main section"]. Method implementations: A[tseat = X] A Is-a passengeraircraft ^ A[tseats(fc) = F, tseat(ec) = E, tseat(bc) = B] ^ X = F + B + E. A[tseat(C) = X] A Is-a passengeraircraft ^ usekitch[section(A, K, S) = Section] ^ useseat[section(A, C, Seat) = Section] ^ B[ oor(Section) = F] ^ A[kitchens = N] ^ K[space = Kspace] ^ Seat[space = Sspace] ^ X = (F N*Kspace / Sspace). Queries: ? - md10[cockpit = ?, tseat(fc) = ?, company = ?, radar = ?]. ? - md10a[radio = ?, cockpit = ?, company = ?]. ? - b100[range = ?]. Answers: md10[cockpit = mitshubishi-m17, tseat(fc) = 22, compnay = "Mcdonnel Douglas", radar = bell23] md10a[radio = "Sony", cockpit = bomberdier-b56, company = "Mcdonnel Douglas"] b100[range = 5000.00]

passengeraircraft(company : string, tseat : integer, tseat(classcategory) : integer, engines : integer, kitchens : integer). dc10-30(radio : string). md10(radar : comsat, #radio : string, #compnay : string, company : string). md10a($radio : string, #tseat : integer, #tseat(classcategory) : integer, b100%radio : string). body( oor(string) : real). seat(tseat : integer, legspace : real, maxtilt : real, facility : fstringg, space : real). useseat(passengeraircraft : passengeraircraft, classcategory : classcategory, seat : seat, section(passengeraircraft, classcategory, seat) : string). usebody(passengeraircraft : passengeraircraft, body : body). usekitch(passengeraircraft : passengeraircraft, kitchen : kitchen, section(passengeraircraft, kitchen) : string). Is-a terms: dc10-30 Is-a passengeraircraft. dragon y, md10a Is-a md10. butter y, b100 Is-a md10a. narrowbody Is-a body. s1 Is-a seat. t1 Is-a kitchen. p-terms: usebody  !passengeraircraft, !body. useseat  !passengeraircraft, !seat, classcategory. usekitch  !passengeraircraft, kitchen. o-terms and r-terms: dc10-30[radio = "Sony", company = "Douglas", cockpit = mitshubishi-m17]. md10[radar = bell23, company = "Mcdonnel Douglas"].

Figure 2: Partial McDonnel Douglas Database in Orlog.

De nition 3.2: Let P and Q be two objects or relationships and D be a database. Then P is related to Q with respect to D, denoted P * Q, i one of the following holds: (i) P and Q are (classes of) objects, and D has either the is-a term P Is-a Q, or a c-term of the form P ([modifier]m(T1; : : : ; Tk ) : Q), k  0; (ii) P is a relationship and Q is a class, and D has a p-term of the form P  [!]T1; : : : ; [!]Q;: : : ; [!]Tn , n  1; (iii) Q is a relationship and P is a class, and D has a p-term of the form Q  [!]T1 ; : : : ; [!]P;: : : ; [!]Tn , n  1; (iv) P and Q are identical, i.e. P * P always holds for any D; (v) there is a P 0 (object or relationship) such that P * P 0 , and P 0 * Q holds with respect to D. Whenever two descriptors P , Q are

for each Bi , if Bi is locally de ned then the descriptors of A and Bi are identical (i.e., A and Bi pertain to the same object or relationship). 2 Since our language is logic, we implement the methods using Horn clause rules. An implementation of a method m in an object or relationship P is a set of Orlog rules, where the consequent is an o-term or r-term corresponding to the method m. De nition 3.5: Let P (m(A1; : : : ; Ak ) : fT1 ; : : : ; Tl g) be a method signature (i.e., c-term), k  0; l  1. Then a de nition for a method m is a set of Orlog formulae of the form P [m(A1; : : : ; Ak ) = X ] B1 ; : : : ; Bn , where k; n  0, the consequent P [m(A1; : : : ; Ak ) = X ] is the corresponding oterm or r-term, and Bi s are any atoms in T. 2 A constraint is an Orlog formula of the form A B1 ; : : : ; Bn , n  1, where A, Bi are any atoms in T, and A is possibly empty. In Orlog, we use a syntactically dierent notation to distinguish constraints from program clauses, for clarity. Thus, we denote a constraint as above by B1 ; : : : ; Bn ! A, n  1, instead. De nition 3.6: A constraint C of the form B1 ; : : : ; Bn ! A, n  1, is admissible provided 8C; D 2 fA; B1 ; : : : ; Bn g, there exists a sequence C = C1 ; : : : ; Ck = D such that either Ci * Ci+1 or Ci+1 * Ci , i = 1; : : : ; k ? 1. 2 A constraint can be local to an object/relationship P , or global. The following de nition clari es this distinction. De nition 3.7: Let C be a constraint of the form B1 ; : : : ; Bn ! A, n  1. If the descriptors of all the atoms { Bi and A { in C are identical (and, say, are equal to P ), then C is local to the object or relationship P . C is also local to P where P is a relationship, if the set of descriptors in C

related, then we say that all terms constructed with P and Q are also related. 2 De nition 3.3: An Orlog formula is a Horn clause formula of the form A B1 ; : : : ; Bn , n  0, where A; Bi are any atoms in T. In such a formula, A is the consequent and Bi s are the antecedent atoms. 2 We remark that all terms that are de ned may not be accessible. In other words, we require that for a formula to be semantically meaningful the literals in the formula be related and respect the notion of encapsulation. As discussed earlier, the implementation of a method should be private to an object or relationship, and all private parts of an object or relationship including the method implementations should not be visible (available) from outside the object/relationship. Hence, no formula should contain any terms that are not semantically related to each other, or refer to methods not visible with respect to that formula. The following de nition makes this notion precise. De nition 3.4: An Orlog formula of the form A B1 ; : : : ; Bn , n  0, is admissible i A * Bi for all i = 1; : : : ; n, and either (i) all Bi s are globally de ned, or (ii)

8

is a subset of the descriptors appearing in the p-term for P . Otherwise C is global. 2 Finally, we have the following de nition for an admissible database. De nition 3.8: A database or program is a collection of Horn clause formulae (as described above) which includes object/relationship de nitions, subclass de nitions, type definitions, method de nitions, and constraints. The database D is admissible exactly when each clause/rule in D is admissible. 2 In [11] we have developed an algorithm for verifying the admissibility de ned above. The algorithm also ensures proper con ict resolution upon multiple inheritance, and guarantees encapsulation in its true spirit. Example: We use the same database we used in Section 2 and give an admissible Orlog program for a part of it (see Figure 2), where we show some implementation of methods and example queries.

[2]

4 Conclusion

[8]

[3] [4] [5] [6] [7]

Object-Oriented data models have attracted wide interest in the database community. Of the many models that have been proposed in the literature, relatively few take advantage of the rich experience gained by the database community in semantic data modeling (see Section 1 for a review of the relevant literature and a commentary on some of the representative works). It has been the aim of this work to show that powerful data models for next generation applications can be built by extending semantic data models with additional features. This means that we need to extend SDMs using (i) data structuring capabilities beyond what they already possess, and (ii) behavioral aspects to extend them in the direction of database programming. With this in mind, we rst presented a conceptual model called the OR model supporting a balanced mix of the features available in SDMs and OODBs. We then developed a logical language called Orlog, which also served to lay down the logical foundations of the OR model. Similar to some of the logic based OO models, such as F-logic [13], Orlog features a high-order syntax which makes it a convenient formalism to express the SDM features and OO features above, while still having a rst-order semantics. Orlog has a simple semantics. Orlog provides the strength of high level database programming and the advantages of a declarative approach. Besides being declarative, Orlog is also equipped with the salient features of OO models and more, e.g., relationships, constraints, con ict resolution upon multiple inheritance, etc. For database programming, we have adopted the logic programming style which is based on the Horn clause notation. This makes it possible to apply the deductive database technology and logic based knowledge representation techniques to tackle issues related to semantic and OO data modeling. In addition, the sophisticated query optimization methods developed for logic based query languages (with extensions) will become applicable to models based on Orlog. These are some of the issues we seek to investigate in further research. We are also working on a proof theory for Orlog.

[9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

References [1]

[19]

Abiteboul, S. and Kanellakis, P.C., \Object Identity as a Query Language Primitive"; Proc. ACM SIGMOD; ; pp 159-173; 1989.

9

Alashqur, A.M., Su, S.Y.M. and Lam, H., \A Rule Based Language for Deductive Object-oriented Databases", Proc of the 6th IEEE Intl. Conf. on Data Engineering; pp 58-67; 1990. Bertino, E., \Data Hiding and Security in Objectoriented Databases", Proc of the 8th IEEE Intl. Conf. on Data Engineering; pp 338-347; 1992. Cardelli, L., \Semantics of Multiple Inheritance", Semantics of Data Types, Lecture Notes in Computer Science No. 173, NY, Springer-Verlag; pp 5167; 1984. Cacace, F., Ceri, S., Crespi-Reghizzi, S., Tanaca, L. and Zicari, R., \Integrating Object-Oriented Data Modeling With a Rule-Based Programming Paradigm"; ACM SIGMOD; pp 225-236; 1990. Enderton, H.B., \A Mathematical Introduction to Logic"; Academic Press; London; 1972. Formica, A. and Missiko, M., \Integrity Constraints Representation in Object-Oriented Databases"; Manuscript; 1991. Han, J. and Li, Z., \DERDL - A knowledge-Based Data Language for a Deductive Entity-Relationship Model", Computing and Information; Elsevier Science Publishers B. V., North-Holland; pp 317-325; 1989. Houtsma, M.A.W and Apers P.M.G, \Data and Knowledge Model: A Proposal"; Advances in Database Programming Languages; ACM Press; pp 387-402; 1987. Hull R. and King, R., \Semantic Database Modeling: Survey, Applications, and Research Issues", ACM Computing Surveys; Vol 19, No 3; pp 201-260; September 1987. Jamil, M.H. and Lakshmanan, L.V.S, \ORLOG : A Logic Language for Object Oriented Databases"; Tech. Rep.; Department of Computer Science, Concordia University; In Preparation. Jamil, M.H., Lakshmanan, L.V.S. and Soliman, M., \OR Model for Semantic Database Modeling"; Tech. Rep.; Department of Computer Science, Concordia University; In Preparation. Kifer, M., Lausen, G. and Wu, J.; \Logical Foundations of Object-Oriented and Frame-Based Languages"; Tech. Rep. 90/14; 1990; SUNY; (To appear in JACM). Lecluse, C., Richard, P. and Velez, F., \O2 , An Object-Oriented Data Model"; Advances in Database Programming Languages; ACM Press; pp 257-276; 1987. Lloyd, J.W., \Foundations of Logic Programming"; Springer Verlag; 1987. Manchanda, S., \Higher-Order" Logic As a Data Model; Proc. of 2nd Intl. Work. on DBPL; pp 330341; June 1989. Peckham, J. and Maryanski, F., \Semantic Data Models"; ACM Computing Surveys; Vol 20, No 3; pp 153-189; Sep 1988. Ullman, J.D., \Principles of Database and Knowledge-base Systems"; Computer Science Press; 1988. Zaniolo, C., Ait-Kaci, H., Beech, D. and Cammarata, S., Kerchberg, L., and Maier, D., \ObjectOriented Database and Knowledge Systems"; Technical Report DB-038-85, MCC; 1985.