Object-Oriented Modelling for Hypermedia Systems Using ... - CiteSeerX

In: A. Dogac, T.Ozsu, A.Biliris, T.Sellis (Eds.), Advances in Object–Oriented Database Systems, NATO ASI Series, Springer Verlag Berlin Heidelberg, 1994.

Object-Oriented Modelling for Hypermedia Systems Using the VODAK Model Language

Wolfgang Klas, Karl Aberer, Erich Neuhold GMD–IPSI, Dolivostr. 15, D–64293 Darmstadt, GERMANY email: {klas,aberer,neuhold}@darmstadt.gmd.de

1 Introduction Hypertext or hypermedia is an approach to information management in which multimedia data is organized in a network of nodes connected by links. Many hypermedia systems have been designed to support specific tasks, e.g., Writing Environment (WE) [31, 32] has been designed specifically to support the professional writer, Examiner [38] has been designed specifically for the on-line presentation of technical documents. Other systems provide general hypermedia facilities to be used in a variety of applications, e.g., idea processing and generic authoring (NoteCards [11, 12]), software engineering (Neptune [5]), or multi-user interactive education (Intermedia [6, 22]). KMS [2] is used in a number of applications including project management, electronic publishing, electronic mail, and bulletin boards. After initial experiments with the management of information through these experimental systems the limitations of traditional modelling and storage concepts used in such systems have become increasingly apparent. The problems reflect fundamental weaknesses in the hypermedia models around which these systems are built. The simple node and link model as well as the conventional database models like the relational data model are not rich and complete enough to support the storage and information management as well as the presentation tasks required by hypermedia applications [12]. File system based storage as in HAM [4] also falls short of what is needed. The semantics and the information of how to perform computations over a hypermedia network, e.g., actively deriving new information, or actively controlling the manipulation of the stored information with respect to its meaning, are not captured by the systems. Furthermore, pure navigational access has proven to be insufficient, what is needed are additional query-based access mechanisms. These approaches do not provide for concepts to extend and tailor the underlying data model to the needs of particular applications. For example, the basic hypermedia model of nodes and links lacks powerful composition mechanisms, i.e., a way of representing and dealing with complexly structured information. Current systems use the two primitive node and link constructs to build up more complex entities. Some of these limitations may be overcome by employing and extending database technology. Although conventional database systems do not provide the right mecha-

NATO ASI Series, Springer Verlag Berlin Heidelberg, 1994.

nisms and appropriate concepts for hypermedia systems [12] recent results in research on next generation database systems reduce the gap between the requirements and the available support through database systems. For example, transaction management based on open nested transactions [3, 24, 40], object-oriented serializability [27] which has been developed in cooperation with the design of SEPIA (Structured Elicitation and Processing of Ideas for Authoring) [10, 33, 34], or the concept of ConTracts [37] may provide appropriate support for the collaborative behavior with respect to the usage of hypermedia systems. The usage of an object-oriented database model will allow to specify more semantics of nodes, link types, and the manipulation and usage of hypermedia networks with the hypermedia system as it provides the encapsulation of structures and operations defined on these structures. Thus, e.g., the information of how to manipulate a hypermedia network consistently can be stored in the database and the hypermedia system can actively support the user according to such information. Within the VODAK project at GMD-IPSI we developed an open object-oriented data model which can be tailored to the needs of particular applications utilizing the concept of metaclasses. In this paper we show how this open object-oriented data model can be tailored to the needs of modelling hypermedia documents as they are used in the framework of, e.g., collaborative authoring environments. In this paper we abstract from the multimedia aspects of a hypermedia network. Requirements and solutions for integrating multimedia data in VODAK are described in [1, 16, 20, 28, 35, 36]. We propose an open database model which can be extended at the meta level. By this, system administrators may tailor the kernel data model to the requirements of specific applications and introduce, for example, additional types of links at the datamodel level. We show how behaviorally object-oriented data models may be employed and extended to meet the special requirements of hypermedia applications. The remainder of this paper is organized as follows: Section 2 introduces the key principles and main features of the VODAK Model Language VML. Section 3 discusses the application of VML for modelling hypermedia documents. Section 4 concludes the paper and gives an outlook of ongoing developments.

2 The VODAK Model Language VML 2.1 Some Preliminaries In the VODAK Model Language1 we distinguish between data values and objects. Each data value is out of a domain determined by a data type. Data values themselves exist only transiently inside the scope of a program. An object is out of a domain constituted by a class. Objects exist persistently, i.e., they exist independently of the scope of a program. Each object has assigned exactly one data value, called object 1) This description refers to VML Version 3, May 1993 [19]. Only the language features needed in this paper are introduced. Future developments will extend the language by additional concepts, including further support for multimedia applications.


identifier, which is the unique identifier of the object by a data value through the object’s lifetime. All objects of a class share the description for their interface, structure of the object’s state, and implementation. This description constitutes the type of an object and can be defined through object type definitions. The interface consists of a set of methods, more precisely a set of method signatures. The state of an object is constituted by a tuple of data values according to property definitions. Access to the object’s state is only possible via the execution of the methods in the interface. Class definitions determine the domains of classes. They refer to object types and define class objects which model the containers of sets of objects, i.e., the extensions of classes. Class objects are instances of classes, which are called metaclasses. A VML schema consist of class definitions, data-type declarations, and object-type declarations. 2.2 Data Types A data type characterizes a set of values, i.e., a domain, and a set of operations applicable to these values. Data types are built up from primitive data types, which include object identifiers, and some basic type constructors. datatype ::= primitive_type | structured_type | DataType_Identifier | Class_Identifier | ClassParam_Identifier

Identifiers referring to a class parameter (ClassParam_Identifier) can be used only in object-type declarations. Identifiers referring to a class (Class_Identifier) can be used only in class definitions. Their usage is explained later in detail in section 2.5. primitive_type ::= BOOL | INT | REAL | STRING | OID | enumeration_type | subrange_type

The primitive data types are those types whose values have no components. The operators available for these data types are the usual ones. OID is the type of unique object identifiers. The only relevant operator in this context for OID is the infix operator ”=” which tests whether two object identifiers are equal or not. Details about the usage of this data type are given in section 2.4.2. An enumeration type introduces a set of basic values by listing the values, which must be distinct. The subrange type specifies a subset of the integer values. structured_type ::= record_type | variant_type | set_type | array_type | dictionary_type

Structured data types are built from primitive data types, already defined structured data types, object types, and type identifiers using type constructors. In the following we will only describe the most important type constructors for records and sets. A record is a sequence of named variables, called the fields of the record. Different fields can have different types. The name and type of each field is statically determined by a record declaration.


record_type record_field

::= ::=

”[” record_field {”,” record_field} ”]” Identifier ”:” datatype

A field named f in a record r can be access only with the expression r.f. A record value is denoted by the expression [id1: v1, id2: v2, . . ., idn: vn] . A set is a collection of values taken from the same type. set_type

::=

”{” datatype ”}”

The values of a set type are all sets whose elements have the type specified by the declaration. Set values can be built either by explicitly enumerating the set members (e.g. {v1, v2, vn}), or using the set operators for union, intersection and difference. Set membership can be tested using the IN function. Two further operations are provided for set variables. INSERT elem INTO set inserts an element in a set, and REMOVE elem FROM set deletes an element from a set variable. A data type declaration binds types to identifiers. In the following we will use the phrase named data type for data types which are bound to an identifier. data_type_declaration ::= DATATYPE Identifier ”=” datatype {”,” Identifier ”=” datatype} ”;”

Named data types can be used inside a data-type declaration. Recursive type declarations (i.e. where the identifier can be used within datatype) are not allowed. 2.3 Object Types Object types play a central role in our object-oriented data model, as they define the structure and behavior of the objects stored in the database. An object-type declaration consists of a public and a private part, thereby separating the interface from the implementation. The interface declaration of an object type consists of a set of structural property definitions and a set of behavioral method definitions. The implementation definition provides implementations for all methods of the interface definition and may introduce additional structural and behavioral definitions. The values of the structural properties constitute the state of an object. The public methods are the means by which objects can communicate with each other. An object type is declared as follows: object_type_declaration ::= object_complete_declaration object_complete_declaration ::= OBJECTTYPE Identifier [”[” class_parameters ”]”] [subtype] ”;” INTERFACE object_interface IMPLEMENTATION object_implementation END ”;” class_parameters ::= Identifier ”:” ObjectType_Identifier {”,” class_parameters}


In the following we explain briefly how the interface and implementation sections of an object type can be defined. The role of the class parameter clause class_parameters is explained later. Multiple inheritance allows to build up object-type lattices for modular object-type definitions. subtype ::= SUBTYPEOF subtypes subtypes ::= ObjectType_Identifier [”[” class_parameters ”]”] {”,” subtypes}

Next we give the object interface definition: object_interface ::= [ PROPERTIES property_definition {property_definition} ] [ METHODS method_signature {method_signature} ]

/* public properties */ /* public methods */

property_definition ::= Identifier ”:” datatype ”;” method_signature ::= Identifier ”(” [formal_parameter_list] ”)” [”:” datatype][ READONLY ] ”;” formal_parameter_list ::= Identifier ”:” datatype [”,” formal_parameter_list]

In the interface only the signature of the methods is specified. Methods marked as read only are assumed to be side-effect free, so any update of the object (or some other parts of the database) is prohibited in these methods2. Updating the object (i.e. changing its internal state by changing the value of an object’s property) is performed by non-readonly methods (which may also delegate updates to other objects). We give now a simple example of an interface definition of an object type. Schema 1. Hypertext nodes interface. DATATYPE Coordinates = [x: INT, y: INT]; OBJECTTYPE Nodeinfo_type INTERFACE PROPERTIES label: STRING; content: STRING location: Coordinates; METHODS newCoordinates(x: INT, y: INT); IMPLEMENTATION /* not shown here */ END; 2)

This information is used by the compiler and the transaction management for optimization purposes.


Next we give the object implementation definition: object_implementation ::= [ datatype_declaration {datatype_declaration} ] [ PROPERTIES property_definition {property_definition} ] METHODS method_definition {method_definition} [no_method_clause] [commuting_definition]

/* local data types */ /* private properties */ /* public and private methods */

method_definition ::= [ SUBTRANSACTION ] method_signature method_body [ undo_definition ] ”;” method_body ::= ”{” [variable_declarations] statement_list ”}” no_method_clause ::= NOMETHOD method_body

The private part of an object-type declaration consists of the declaration of an object’s private properties and the implementation of an object’s methods. The optional datatype declarations introduce auxiliary types which are visible only in the implementation part. The implementation part may contain additional methods (which are not defined in the public part). These are private methods which can only be called by other methods of the same object type. Furthermore, the implementation part can specify a NOMETHOD clause which allows to specify a dynamic inheritance behavior, details of which will be explained in Sections 2.4.3 and 3. Method implementations consist of the method heading (specifying the method name and its signature), and the method body. The body of a method is an optional list of variable declarations followed by a list of statements. Inside a method body the object’s properties are accessed by their name only. The keyword SELF is used to denote the actual object. Methods can be specified as subtransactions. In this case an undo definition and a commuting definition have to be specified. For more details on transactions in VML see section 2.6.

Schema 2: Hypertext nodes implementation. OBJECTTYPE Nodeinfo_type INTERFACE /* as defined in Schema 1 */ IMPLEMENTATION METHODS newCoordinates(x: INTEGER, y: INTEGER); {location.x:=x; location.y:=y}; END;


2.4 Objects, Classes, and Metaclasses Objects represent material or immaterial real world entities, or abstract concepts such as data-model primitives, which are stored persistently in the database. Objects which are similar in their structure and behavior are organized into classes. Every object is instance of exactly one class. The only way to operate on an object is by sending it a message which identifies a method defined for the object and arguments for that method. Objects in VML obey the principle of object identity. Object identity is realized by object identifiers which are attached to objects. Each object has its own distinct object identifier, which is different from that of any other object and which does not change throughout its lifetime. Object identity is the basis for sharing and updating objects. A class describes the structure and the behavior of a collection of similar objects, called the extension of a class. The extension of a class is defined explicitly by creating instances of the class. The definitions needed to define the structure and behavior of instances of a class are specified with object types associated with the class. Due to the distinction of object types and classes, different classes can share the same object type. Details on the relationship between classes and object types are given later in this section and in section 2.5. Instances of classes are stored persistently in the database and are shared by any application which is allowed to access the database schema and operate on the classes. VML distinguishes between application classes and metaclasses: – Application classes are defined by an application developer to organize and classify the objects dealt with by the application. They correspond to application specific concepts like DOCUMENT, SECTION, NEWSPAPER, AUTHOR, PERSON, NODE and LINK. – Metaclasses are defined by system administrators together with application developers in order to organize application classes and to tailor the database model to the specific needs of an application, e.g., to meet the requirements of the modelling of complex structured documents, multimedia objects, database integration, or hypertext applications. Metaclasses are used to describe the common structure and behavior of application classes and their instances. Every application class has associated exactly one metaclass. A metaclass may have associated many classes. Classes (application classes and metaclasses) are treated as first class objects, i.e., a class C is an instance of its associated class MC (which is called the metaclass of the class C) like an object c is an instance of exactly one class, e.g., the class C. Such a class hierarchy can be of any depth. The root of the class hierarchy is the system predefined metaclass VMLCLASS (see Section 2.4.4 for a detailed description of this class). VML provides an initial class hierarchy containing a few predefined metaclasses by default. For a detailed description of this initial metaclass system see Section 2.4.4.


Treating classes as first class objects allows the user to operate on classes in the same way as he operates on individual instances of application classes. That is, classes can be retrieved and manipulated in the same manner as individual objects. For example, one can send a method display() to an individual instance representing a hypertext node or one can send it to the class NODE which organizes these individual objects. Depending on the concrete method implementation of display(), in the first case, the properties and property values of the node could be displayed on the screen. In the second case, the characteristic values of the collection of individual nodes like the class definition of the class NODE, the cardinality of the set of individual objects, or any access statistics could be retrieved. 2.4.1 Application Classes To create an application class one has to specify at least the name of the class with the CLASS clause, and the properties and methods defined for the instances of the class with the INSTTYPE clause. The syntax for the definition of an application class is as follows: application_class_definition ::= CLASS Class_Identifier [METACLASS Class_Identifier] [OWNTYPE object_type] INSTTYPE object_type [INIT method_calls] END object_type ::= ObjectType_Identifier [ ”[” type_to_class_map ”]” ] | /* named object type */ OBJECTTYPE [ subtypelist ”;” ] /* anonymous object type */ INTERFACE object_interface IMPLEMENTATION object_implementation END type_to_class_map ::= Class_Identifier { ”,” type_to_class_map } subtypelist ::= SUBTYPEOF ObjectType_Identifier [ ”[” type_to_class_map ”]” ] {”,” ObjectType_Identifier [ ”[” type_to_class_map ”]’ ] }

Now we want to discuss in detail the four constituents of an application-class definition, the metaclass, the own type, the instance type and the initialization. An application class is an object, and hence, it must be defined as an instance of a metaclass. This is specified by the clause of the form METACLASS Class_Identifier. The object representing the application class identified by the Identifier is created as an instance of the metaclass identified by Class_Identifier. The metaclass can be chosen from a set of classes which contains predefined metaclasses like KERNEL-APPLICATION-CLASS for standard applications or user defined metaclasses


provided by a metaclass library. If no metaclass is specified, KERNEL-APPLICATION-CLASS is taken as the default metaclass (see Section 2.4.4). An application class may have associated an object type as its own type, which defines application specific properties and methods for the object representing the application class. For example, an application class may require a specific object-creation method which initializes the individual new instances of the application class, or it may require a sort method which sorts the individual objects with respect to a specific property. The own type of an application class is specified by the optional clause of the form OWNTYPE object_type. With every application class an object type is associated as its instance type, which defines the properties and methods for the individual objects collected by the class. The instance type of an application class is specified by the clause of the form INSTTYPE object_type. Both, own types and instance types, can be specified either by an in-place anonymous object-type definition or by identifying the object type by name and optionally specifying the type-to-class mapping which resolves parametrized object types (see Section 2.5). The application specific initialization of the object representing the application class can optionally be specified with the init clause INIT method_calls. It consists of the specification of a sequence of method calls which will be executed after the application class has been created as an instance of the associated metaclass during the database creation process. As an illustration we give a schema for a simple hypertext model (Schema 3). Figure 1 visualizes the database according to the schema and introduces the graphical notation we use in this paper.

Schema 3. A simple hypertext model.

CLASS Node INSTTYPE OBJECTTYPE SUBTYPEOF Nodeinfo_type INTERFACE METHODS createlink(to : Node); /* this method must also update the to–Node */ IMPLEMENTATION PROPERTIES linkto: {Node}; linkfrom: {Node}; METHODS createlink(to : Node); {INSERT to INTO linkto; to³insertfrom(SELF);} insertfrom(from: Node); {INSERT from INTO linkfrom; } END; END;


Level 2: application classes

Node N2

Level 1: individual objects

linkfrom

Í Í Í

Nodeinfo_type

N1 N1

linkto

N2

(anonymous)

Fig. 1. A simple hypertext database according to Schema 3. Legend: Left side: Classes are drawn as ellipses, individual objects are drawn as black circles. An unlabeled arrow from one level to another level always specifies an instance-of relationship (e.g., N1 is an instance of Node). Object types associated with a class (directly or indirectly via type inheritance) are grouped together by a rectangle. Such a rectangle is attached to an object for which the types define properties/interfaces. A line drawn from a small rectangle (like at Level 1) to a class (like Node at Level 2) specifies the assignment of object types to classes. The pattern specifies that an (anonymous) object type is assigned as instance type to class Node. Right side: A hypertext graph that is represented on the left side in the database.

ÍÍ ÍÍ ÍÍ

ÍÍ Í

2.4.2 Metaclasses Metaclasses are used to describe the common structure and behavior of classes and their instances which may not be known at the time a metaclass is defined. This means that the types and the classes of the objects representing the application classes and their instances are not known at the time the properties and methods provided by a metaclass are specified. The designer of a metaclass only knows that the properties and methods provided by the metaclass operate on objects. To overcome this problem, VML provides the primitive data type object identifier OID which can be used to refer to an object whose class is not known. The concept of metaclasses is homogeneously integrated with the other concepts of VML. Metaclasses and application classes are treated uniformly as classes. Hence, the definition of metaclasses follows the same rules as given for application classes. In addition, it is possible to specify the common structure and behavior for the instances of the instances of a metaclass by associating an object type as instance-instance type to the metaclass.


meta_class_definition ::= CLASS Identifier METACLASS Class_Identifier [OWNTYPE object_type] INSTTYPE object_type INSTINSTTYPE object_type [INIT method_calls] END

Additionally to the clauses of an application-class definition, with every metaclass an object type is associated as its instance-instance type. This object type defines the common properties and methods for the individual objects collected by the instances of the metaclass, which themselves are classes. The instance-instance type of a metaclass is specified by the clause of the form INSTINSTTYPE object_type. Examples for metaclasses will be given in Section 3. 2.4.3 Determining the Structure and Behavior of Objects As previously mentioned, classes determine the structure and behavior of their instances. More precisely, an application class determines (i) the application-specific structure and behavior of its instances which represent the ‘‘real world” objects dealt with in an application program, e.g., the content and position of a hypertext node, and (ii) the application-specific structure and behavior of the application class itself, e.g., a specific object creation and initialization method for nodes. The specification of the structure and the behavior is given with object types which are associated to an application class. In case of (i), an appropriately defined object type is associated with the application class as its instance type (as it affects the instances of the class). In case of (ii), an appropriately defined object type is associated with the application class as its own type (as it affects the own structure and behavior of the class as an object). In this respect, metaclasses are more powerful than application classes. They determine not only the structure and behavior of their instances, but also the structure and behavior of the instances of its instances. That is, a metaclass determines (i) the structure and the behavior of the metaclass itself, e.g., a specific object creation and initialization method for classes, and (ii) the common structure and behavior of its instances which are classes, i.e., application classes or metaclasses, e.g., the general object creation and initialization method for instances of an application class, which does not consider any application-specific requirements, (iii) the common structure and behavior of the instances of its instances (which are classes), e.g., the common method that returns the class of an instance.


ÍÍÍÍÍÍÍÍÍ ÍÍÍÍÍÍÍÍÍ ÊÊÊÊÊÊÊÊÊ ÍÍÍÍÍÍÍÍÍ ÊÊÊÊÊÊÊÊÊ ÍÍÍÍÍÍÍÍÍ ÊÊÊÊÊÊÊÊÊ ÈÈÈÈÈÈÈÈÈ ÊÊÊÊÊÊÊÊÊ ÈÈÈÈÈÈÈÈÈ ÈÈÈÈÈÈÈÈÈ ÉÉÉÉÉÉÉÉÉ ÈÈÈÈÈÈÈÈÈ ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ ÇÇÇÇÇÇÇÇÇ ÇÇÇÇÇÇÇÇÇ ÇÇÇÇÇÇÇÇÇ ÇÇÇÇÇÇÇÇÇ own-type

instance-type

instance-instance-type own-type

instance-type

instance-instance-type

own-type

instance-type

ÉÉ ÉÉ ÉÉ ÉÉ ÍÍÉÉ ÍÍ ÉÉ ÍÍÉÉ ÍÍ ÉÉ ÈÈ ÊÊ ÈÈÊÊ ÈÈÊÊ ÈÈ ÊÊ ÇÇÇ ÇÇ ÉÉ ÇÇÇÇÇÉÉ ÇÇÇ ÇÇÇÇÇ ÇÇÉÉ ÉÉ

metaclass MMC

instance-of metaclass MC

instance-of application class C

instance-of an instance O

Fig. 2. The general scheme of determining an object’s structure and behavior through its class and the class’ metaclass.

In case of (i), an appropriately defined object type is associated with the metaclass as its own type (as it affects the own structure and behavior of the metaclass as an object). In case of (ii), an appropriately defined object type is associated with the metaclass as its instance type (as it affects the instances of the metaclass). In case of (iii), an appropriately defined object type is associated with the metaclass as its instanceinstance type (as it affects the instances of the instances of the metaclass). Figure 2 shows this scheme: The own type of the metaclass MC affects the structure and behavior of the metaclass itself. The instance type of the metaclass MC affects the structure and behavior of the instances of the metaclass MC, i.e., the class C. The instance-instance type of the metaclass MC affects the structure and behavior of the instances of the class C. The own type of the class C affects the structure and behavior of the application class itself. The instance type of the class C affects the structure and behavior of the instances of the class C. The interface defined for an object is the set of methods which are defined for the object, i.e., which can be executed directly for the object. The interface depends on the definitions given with the object types associated with the object’s class and with the class’ metaclass. In general, the interface defined for any object consists of – the methods specified with the own type of the object, if this object represents a class, and – the methods specified with the instance type of the object’s class, and


– the methods specified with the instance-instance type of the metaclass of the object’s class. For any message which specifies a method contained in the interface defined for the receiving object it is guaranteed that the method is executed for this object. A message is sent to an object by executing a statement of the form receiver_object³m(arglist).

In case the method is not contained in the interface defined for the object, the message handling system of VML tries to delegate the message to another object by executing the method implementation given in the NOMETHOD clause. Within the body of the NOMETHOD clause two predefined identifiers, currentMethod and arguments are available. The identifier currentMethod is bound to the method name m which has been sent to receiver_object. The identifier arguments is bound to the argument list of the message. If the NOMETHOD clause is not defined a run-time error is signalled. The implementation of the body of the NOMETHOD clause has to be specified by the user. For example different inheritance strategies can be implemented. Examples of method implementations using the NOMETHOD clause are given in Section 3. 2.4.4 VML Class System The class system in VML (see Figure 3 ) is logically partitioned into a set of systeminternal classes and a set of system-external classes. The latter ones are organized in four levels: 1. the individual object level (level 1), 2. the application class level (level 2), 3. the metaclass level (level 3), and 4. the root level (level 4). Presumably, an application user will see and use the bottom two levels. He will query, update, create, and remove individual objects of application classes. It is the task of an application developer, working on levels 2 and 3, to define new application classes as instances of some predefined metaclasses. At the metaclass level the system administrator may define new metaclasses and, thus, enhance the modelling capabilities of the predefined kernel model.


system administrator

Level 4: root METACLASS

other system internal classes, e.g. data dictionary

Level 2: application classes Audio

Atomic

Composite

Article

possible part Chapter

specialization Article asAtomic

content Level 1: individual objects

parts

chapter

application user

KERNEL-APPLICATIONCLASS

...

application developer

VMLCLASS Level 3: metaclasses

article specialization article as atomic system internal classes and objects

external classes and objects

instance-of initial predefined metaclasses in VML semantic relationship specialization semantic relationship partof

Fig. 3. A sample VML class system including the initial class system of VML.

The initial metaclass system of VML consists of the system-internal class VMLCLASS, METACLASS at the root of the metaclass system, KERNEL-APPLICATION-CLASS at the metaclass level and a few other system-internal metaclasses, which cannot be changed or modified. They are built-in classes3 and provide for the basic and system inherent capabilities. Changing or extending the definitions for these classes will change the standard modelling capabilities of VML. In Figure 3 the initial metaclass system is identified by the shadowed boxes. The system-internal classes provide the basic structures and behavior in order to deal with 3)

Following the approach of self-reflective architectures all the VML predefined classes are implemented like other user-defined classes. The boot-strapping problem associated with such an approach is reflected by the fact that VMLCLASS is an instance of itself.


classes, objects, and the data dictionary of a database. The class VMLCLASS provides capabilities like object creation, object deletion, and object storage. Schema 4 shows the definition of VMLCLASS. Schema 4. The initial VMLCLASS schema. CLASS VMLCLASS METACLASS VMLCLASS INSTTYPE VML-Class_InstType INSTINSTTYPE VML-Class_InstInstType END OBJECTTYPE VML-Object_Type INTERFACE METHODS class() : Oid; END OBJECTTYPE VML-Class_InstType SUBTYPEOF VML-Object_Type INTERFACE METHODS new(): Oid; /* creates and returns a new object */ allInstances () : {Oid}; /* returns the set of instances */ isInstance (obj: Oid) : Bool; /* is it an instance? */ delete (obj: Oid); /* removes an instance */ END OBJECTTYPE VML-Class_InstInstType SUBTYPEOF VML–Object_Type END

The object type VML-Object_Type defines properties and methods which are in common for all objects. For instance, since every object is defined to be an instance of a class, every object O must be able to respond to the message O³class() which returns the identifier of the object’s class, i.e., the method class() must be defined for every object. The object type VML-Class_InstType implements, e.g., a built-in method new() which allows to create a new object. Other methods defined by VMLClass_InstType are typical methods for the management of a set of object identifiers, which stands for the actual set of instances of a class. These methods allow to add a new object identifier to the set of actual instances (needed for the creation of a new object), to remove an object identifier from the set of actual instances (needed for the deletion of an object), to test whether a given object identifier identifies an instance of the class. The object type VML-Class_InstInstType is defined as a subtype of VMLObject_Type but implements no further public methods. However, it provides for a homogeneous object-type hierarchy and for further extensions. The class METACLASS serves as the container for any metaclass introduced and defined by a system administrator. The class KERNEL-APPLICATION-CLASS is the default metaclass for user-defined application classes. The instance types and instance-instance types corresponding to these two initial classes are derived from the instance type and instance-instance types of VMLCLASS according to Figure 4. This figure illustrates the initial object type hierarchy. All object types in the system are


organized by that type hierarchy. The root of this subtype hierarchy is the type Θ. This type does not define any properties and methods. Every object type is either a direct subtype of Θ (which is the default when no explicit supertype is specified) or it is a subtype of another object type, i.e., it is an indirect subtype of Θ. Every database schema contains this initial metaclass system. All object types, application classes and metaclasses are built up using this initial metaclass system.

Θ VML-Object_Type VML-Class_InstType Metaclass_InstType KernelApplicationClass_InstType instance-types of other metaclasses VML-Class_InstInstType Metaclass_InstInstType KernelApplicationClass_InstInstType instance-instance-types of other metaclasses own-types instance-types of application classes user-defined object types for metaclasses object types used for application classes

Fig. 4. The initial subtype hierarchy.

2.5 Parameterizing Object Types with Classes In VML a class definition has two roles: it serves as the definition of a container object to model the extension of a class (the extensional aspect) and it provides object-type definitions (intensional aspect) for describing the interface and structural properties of the instances of the class. Note, that the extensional aspect is an orthogonal concept, which does not exist for data values. Given this framework it is quite obvious to distinguish between type definitions and class definitions. An object-type definition comprises the full type description. A class definition is related to a class domain (i.e., the set of all possible objects defined by a class), refers to object types (e.g., own type, instance type, and instance-instance type), and is related to a class object.


By explicitly distinguishing between class definitions and object-type definitions VML facilitates the modelling of real world situations. Classes are used to organize a set of objects corresponding to real world entities and relationships between them. That is, classes are used to form an ontology of the application domain. Object types define the structure of objects and the operations defined on these structures. They are associated with classes in order to determine the structure and behavior of the class’ instances. VML does not allow the usage of class identifiers (see Class_Identifier in Section 2.2) as data types in property, parameter, and variable definitions within object-type definitions4: This is because object types should be considered without referring to concrete class definitions at all, e.g., for reuse in different schemas or different class definitions in a single schema. Since object types can be associated to various class definitions the class domains ( = classes) appearing in the property, parameter, and variable definitions in object types may vary from class to class. If class domains (which depend on other class definitions) will be used in object-type definitions the extensional aspects would not clearly be separated from the intensional aspects. As VML does not abandon the definition of properties over class domains, it provides class domain parameters for object-type definitions. These parameters are substituted by concrete class domains, when the object-type definition is used in a class definition. We call this substitution the type-to-class-(domain)-mapping according to [15]. Introducing these class domain parameters without any knowledge about them is not very useful. Therefore we impose object-type constraints on these parameters, which constrain the class domains to be substituted. Let us make an example which illustrates the type-to-class mapping mechanism: Schema 5. Parametrized hypertext-node object type. OBJECTTYPE Node_type[aNodeClass: Node_type] INTERFACE METHODS createlink(to : aNodeClass); insertfrom(from: aNodeClass); IMPLEMENTATION PROPERTIES linkto: {aNodeClass}; linkfrom: {aNodeClass}; METHODS createlink(to : aNodeClass); {INSERT to INTO linkto; to³insertfrom(SELF);} insertfrom(from: aNodeClass); {INSERT from INTO linkfrom; } END;

At this point, we defined an object type which is parametrized with a class-domain parameter (or shortly class parameter) aNodeClass. This class parameter is used as a data type to define the properties fromlink and tolink and it is used in the definitions of 4)

However, such a restriction does not apply to anonymous object-type definitions within class definitions (see Section 2.4.1).


the methods operating on these properties. So far, no concrete class (domain) is specified by this class parameter and, hence, no concrete domain is defined for the properties fromlink and tolink. The constraint aNodeClass : Node_Type imposed on the class parameter requires that the concrete classes which can be chosen to substitute the parameter aNodeClass must have Node_Type associated directly as instancetype, or Node_Type has to be a supertype of the instance-type. The parametrized object type can be used for class definitions as follows: CLASS NODE INSTTYPE Node_Type [ NODE ] END;

Class NODE now defines objects which can refer (through their properties tolink and fromlink) to instances of class NODE. Class NODE is a valid class for substituting the class parameter aNodeClass of the object type Node_Type as Node_Type is the instance type of class NODE. One can partition the universe of nodes into sets of white and black nodes. In that case one could define CLASS WHITEN INSTTYPE Node_Type [ BLACKN] END; CLASS BLACKN INSTTYPE Node_Type [ WHITEN ] END;

KernelApplicationClass

Level 3: metaclasses

Level 2: application classes Level 1: individual objects

WHITEN

Í Í ÍÍ

BLACKN

linkfrom linkto linkfrom

Node_type[WHITEN]

Node_type[BLACKN]

linkto: {BLACKN} linkfrom: {BLACKN}

ÍÍ ÍÍ ÍÍ ÍÍ

linkto

linkto:{WHITEN} linkfrom:{WHITEN}

Fig. 5. Parameterization of object types allows for semantic constraints on classes.


Class WHITEN defines now objects which can refer (through their properties fromlink and tolink) to instances of class BLACKN and vice versa. Thus one can enforce the constraint that any path in this hypertext network will visit alternating white and black nodes. WHITEN and BLACKN are both valid classes for the class-parameter substitution for type Node_Type because both classes have associated as instance type Node_Type. See Figure 5 for a visualization of the database. It shows the actual property definitions according to the actual type-to-class-(domain)-mappings. 2.6 Transactions In VODAK, we focus on two specific problems of transaction management. 1. Operations to read and edit (hyper)documents are typically complex, interactive and of long duration. A high degree of concurrency is required to reduce the number and length of times a transaction is blocked. 2. A publication environment has to handle existing database systems for using and modifying remote information and documents. Transaction managers of existing systems, i.e. concurrency control and recovery, have to be integrated in a transparent way utilizing the functionality of existing managers. Our transaction model is based on open nested transactions. For a detailed description see [24, 26, 27, 39]. Compared to conventional flat transactions, nested transactions allow more concurrency and are more flexible for recovery. A nested transaction is a tree-like structure, dynamically built up by the call of subtransactions until a bottom implementation level is encountered. There are two types of nested transactions. Closed nested transactions provide a high degree of concurrency by allowing the concurrent execution of subtransactions. Furthermore, they allow to abort subtransactions independently of the calling transaction. Open nested transactions utilize the semantics of operations, i.e. a commutativity relation is used to define conflicts between operations. By considering the nesting structure, conflicts of subtransactions can be ignored if the calling (sub-) transactions commute and the called subtransactions are executed in a consistent way (i.e. serializably). For example, two increment operations on a counter commute whereas the corresponding update operations on a page conflict. After the update subtransactions are committed, their conflict can be ignored and the calling transactions can be executed concurrently. We extended the open nested model from a fixed calling hierarchy of operations in a layered system (multi-level transactions) to an arbitrary calling hierarchy of operations in an object-oriented system [27]. Commutativity of operations is applied to system-defined VODAK methods, and to methods of user-defined object types. For the second type of operations, we developed a framework to specify commutativity and inverse operations in VML. The commutativity of methods and the inverse methods are specified in the implementation part of object-type definitions (see the clauses commuting_definition and undo_definition in Section 2.3). Their specification is not discussed in this paper.


We also developed an integration model for existing transaction managers. The open nested transaction model has been extended to support distributed transaction execution in a heterogeneous environment. The model provides ACID properties for global transactions if all existing transaction managers also provide these properties [24]. No assumptions about protocols, e.g. two-phase locking, are made. Subtransactions of existing systems constitute the leaves of our transaction tree. Again, we utilize the semantics of these transactions in order to achieve a high degree of concurrency. Recovery is based on inverse operations, compensating the changes of transactions which have to be aborted. Inverse operations are also used to ensure atomic commitment. Unilateral aborts as well as system crashes can be handled [25, 23].

2.7 Tailoring the Data Model One major benefit claimed for object-oriented database systems is extensibility. Although object-oriented data models allow users to define their own classes, they come with a fixed set of data-model primitives. We consider this a major problem as different application domains have different requirements on a data model. For example, database integration requires the possibility to overcome different representations of the same data. Hypertext applications need flexible concepts for organizing inter- and intra-document references. Multimedia applications need among other features support in handling different sources of data. If a data model is designed to cover many application domains, there are two dangers: On the one hand, the data model may be kept too general and does not fully meet the requirements of specific applications. On the other hand, the data model may be overloaded with too many specialized concepts and is hard to understand. Alternatively, different data models may be developed for specific application domains and thus take into account their needs. This solution, however, leads to disintegrated and isolated applications, each using a different data model. Metaclasses in VODAK provide a solution to that problem. They can be used to introduce new data-model primitives needed in specific application domains. The VODAK kernel data model contains primitive data types and classes commonly used in many different application domains. To handle specific application domains, such as database integration, multimedia applications, or hypertext applications, the kernel model is extended with additional modelling capabilities through metaclasses. In the following chapter we show how VML can be extended with specific modelling constructs to support the modelling of hypertext structures, hierarchies, object categories, and document versioning. In [20] it is shown how VODAK can be tailored such that a video laser disc providing all the database operations needed to view videos on a screen is transparently integrated into the system. [1, 16] show, how multimedia data can be modelled in VODAK. [17, 21] show, how VODAK can be tailored such that an external relational database system can be accessed and integrated into VODAK. In [18] we present a database model for argumentative networks (hypertext network according to the semantics of Toulmin schemas) for an authoring environment.


3 Modelling of Hypermedia Documents In this section we want to illustrate how the open object-oriented data model VML can be used to support the needs of hypermedia applications. We consider the following three aspects of hypermedia document modelling: Hypertext structures, hierarchical document structures and versioning of documents. In concrete applications [7, 30, 33] these three concepts are needed simultaneously and have therefore to be integrated. In the following we first will discuss alternative VML models for each of these concepts separately, then give a generic VML metaclass schema supporting all of the three concepts and thus extend the VML data model for hypermedia applications. Other aspects like modelling of the multimedia content and presentation of hypermedia documents will be omitted here. In the course of the subsequent discussion we will emphasize fundamental needs of complex software systems, namely correctness, extensibility, reusability and compatibility and discuss how these aspects are affected by design decisions in VML. Thus we will illustrate several issues of schema design which are particularly relevant when using the VML data model. We will discuss these issues by developing a series of VML schemas, each of which focusses on a different aspect in the modelling process. An overview of the interdependencies of these schemas can be found in the Appendix. 3.1 Hyperdocument Structures In the simplest case a hypertext structure can be conceived as a network of nodes which contain some piece of information, about which we do not care at the moment, and which are interconnected by links (Figure 6). From each node we can navigate through a set of outgoing links to other nodes. This model was captured in the VML class definitions given in Schema 3. When planning a generic support for modelling of hypermedia documents the approach described in these examples may not be appropriate, as in many cases links should be made available explicitly. Among these reasons are: links may have their own properties and methods, therefore a receiver object for them is needed; links may be referenced by other links; it may be necessary to distinguish different types of links, thus they should be classified by using classes. More abstractly all these reasons are a consequence of the fact that links can carry a substantial amount of applicationspecific semantics. Thus we consider from now on links as objects and arrive at the following VML definitions (Schema 6 and Figure 6).


Schema 6. A hypertext model with links as objects. CLASS Node INSTTYPE OBJECTTYPE INTERFACE PROPERTIES

END; OWNTYPE OBJECTTYPE INTERFACE METHODS END; END;

content: anything; /* not further specified */ tolink: {Link}; fromlink: {Link};

createnode(): Node;

CLASS Link INSTTYPE OBJECTTYPE INTERFACE PROPERTIES

END; OWNTYPE OBJECTTYPE INTERFACE METHODS

purpose: anything; /*e.g. meaning of link */ from: Node; to: Node;

createlink(from: Node, to: Node): Link; /* has to change nodes also */

END; END;

Level 2: application classes anonymous owntype

Node

anonymous owntype

Link

N2 L2


Í Í Í

anonymous N2 insttype

to from to N1

N3 from

L2

L1

ÍÍ ÍÍ ÍÍ

L1 N3 N1

anonymous insttype

Fig. 6. A hypertext database with links as objects according to Schema 6. Legend (in addition to the legend given in Figure 1): Rectangles surrounding own-type definitions are attached to classes for which the types define properties/interfaces. The pattern specifies that object types are assigned as own types to classes.


For object creation the receiver object of the creation method is the class of which a new instance is created. Therefore they are part of the own type of the class. Note that due to space limitations throughout the section we will consider whenever we present VML definitions with a few exceptions only the interfaces of object types and there only methods for object creation. The implementation is described by comments where needed and other methods, e.g. for navigation, retrieval and deletion, have to be added. In some applications links can behave almost like nodes, as they may have content and they may be referred to by other links (Figure 7). This amounts to the following two problems: (1) we have to refer to links and nodes by the same property, thus we have to provide a common domain for nodes and links; (2) the interfaces of links and nodes are very similar; thus we want to reuse as much of the type definitions as possible. We discuss two possibilities of how to tackle this in VML. Possibility 1. As links and nodes are already very similar in structure we just unify their types and use only one generic type. This results in the following class definitions. Schema 7. A hypertext model unifying nodes and links. CLASS NLobject INSTTYPE OBJECTTYPE INTERFACE PROPERTIES content: anything; from: NLobject; to: NLobject; fromlink: {NLobject}; tolink: {NLobject}; END; OWNTYPE OBJECTTYPE INTERFACE METHODS createnode(): NLobject; createlink(from: NLobject, to: NLobject): NLobject; END; END;

Objects, which are considered as nodes will have null values in the properties from and to. All other properties are used equally by links and nodes. Note that the knowledge about what is a link and what is a node has moved into the implementation. This is also reflected by the fact that two different methods for creation of nodes and links are available. Possibility 2. The idea of the next approach can be described as follows. We introduce two classes, namely a class whose instances represent links as well as nodes with their common features and a special class which represents the particular features of links. Thus we factor out the common part of the structure of links and node and exploit the assumption that links have all the properties of nodes.


Schema 8. A hypertext model using specialization. CLASS Node INSTTYPE OBJECTTYPE INTERFACE PROPERTIES content: anything; fromlink: {Link}; tolink: {Link}; specialization: Link; /* is NIL for Nodes */ END; OWNTYPE OBJECTTYPE INTERFACE METHODS createnode(): Node; /* creates Nodes which are not specialized to links */ END; END; CLASS Link INSTTYPE OBJECTTYPE INTERFACE PROPERTIES from: Node; to: Node; generalization: Node; /* never is NIL */ METHODS asnode(): Node; /* returns the generalization node */ IMPLEMENTATION NOMETHOD generalization³currentmethod(args); END; OWNTYPE OBJECTTYPE INTERFACE METHODS createlink(from: Node, to: Node): Link; /* this method has also to create a generalization node */ END; END;

An illustration of the instance and the class level of the schema is given in Figure 7. Now several comments are in place. The method asnode() is needed to switch for a link to its node context, for example a link connecting two links is created by the method call Link³createlink(asnode(link1),asnode(link2)). The NOMETHOD clause in the class Link is executed whenever a method is not found in the Link interface. In this case the method call is delegated to the node object which is related to the link object via the property generalization. Thus an instance of the class Link can behave in the same way as an instance of the class Node, in other words it dynamically inherits the properties and methods of the class Node. Alternatively to the class definitions from Schema 8 we could have considered one general class which would capture the common properties of nodes and links with two specializations, namely a link and a node class. This would have been appropriate when the links had not shared all of the properties and methods of nodes. Another design alternative one could consider is to let the link type inherit from the node type via subtyping and thus using static inheritance instead of dynamic inheritance. Thus a link class will also have the object type of the node class, which solves problem (2), but there exists no generalization for nodes and links for uniform access to them, which was problem (1).


Level 2: application classes anonymous owntype

Node

anonymous owntype

Link

N2 Level 1: individual objects

ÍÍ Í Í

from to N3 N2

anonymous insttype

N1 L2

specialization

from to

L2

L1

ÍÍ Í Í

L1

L2 N3

N1

anonymous insttype

message passing Fig. 7. A hypertext database using specialization according to Schema 8.

In the following we want to discuss the main differences between these two possibilities from the viewpoint of schema design. In the first case, we provide a pivot model with a generic structure, where on the one hand more application semantics is represented operationally, e.g., links and nodes have to be distinguished operationally, but on the other hand the structural part of the schema, which is stored persistently, is more flexible and may be used more easily for different hypertext models. In the second case, more of the application semantics is represented in a declarative way in the structural part of the schema. Thus more constraints of the data model are hard wired and the application is freed of the responsibility to maintain these constraints. It is also interesting to discuss the differences of these approaches from the viewpoint of complexity. Regarding time complexity, in the first case, more effort has to be spent in determining types of objects while in the second case more pointer-chasing operations are needed. With respect to space complexity in the first case many null values may occur while in the second case references for connecting the different parts of an object in its different contexts are needed. For the remainder of this section we will assume that we have chosen possibility 2, as it reflects the semantics of hypertext applications in more detail in the structural part of the data model. 3.2 Categorization The generalization/specialization principle discussed in possibility 2 of the subsection 3.1 can be considered of course independently of the hypertext modelling issue. It is considered to be a generic semantic relationship and such semantic relationships are the prototypical case for using the VML metaclass concept. The typical scenario is


given a general class (e.g. node, but also vehicle) and special classes (e.g. link, but also truck, car, van). The special classes are disjoint. In this case we have given a category generalization and specialization relationship. The classes which participate in this relationship can be considered as instances of particular metaclasses which provide the properties and methods needed to realize the category relationship. We first give the class definitions for the category relationship and, by exploiting the dual model, give the object-type declarations later. This is reasonable as we will reuse these type declarations for other purposes later. Schema 9. Category specialization and generalization. CLASS Specialization METACLASS Metaclass INSTTYPE Special_insttype INSTINSTTYPE Special_instinsttype END; CLASS Generalization METACLASS Metaclass INSTTYPE General_insttype INSTINSTTYPE General_instinsttype END;

The metaclasses have to control not only the relationship on the class level but also that on the instance level. This is the reason why the metaclass definition also comprises type definitions for the instances of the instances of the metaclasses, the socalled INSTINSTTYPE. Next we give the object types. These involve explicit object identifiers as we do not know which particular classes will participate in the category relationship. OBJECTTYPE General_instinsttype SUBTYPEOF Metaclass_instinsttype INTERFACE PROPERTIES specialization: OID; /* may be NIL */ END; OBJECTTYPE Special_instinsttype SUBTYPEOF Metaclass_instinsttype INTERFACE PROPERTIES generalization: OID; IMPLEMENTATION NOMETHOD generalization→currentMethod(args); END; OBJECTTYPE General_insttype SUBTYPEOF Metaclass_insttype INTERFACE PROPERTIES specClasses: { OID }; END; OBJECTTYPE Special_insttype SUBTYPEOF Metaclass_insttype INTERFACE PROPERTIES genClass: OID; METHODS initgen(g: OID); createspecial(g: OID): OID; /* g is the OID of a generalization class, createspecial creates general and special object and checks whether g is valid */ END;


The semantics of this particular generalization/specialization relationship is partially specified by the structural definitions and partially by the behavioral definitions. For example, the fact that the property specialization may be NIL corresponds to the fact that the categorization is non covering, i.e. not every general object has a specialization. The fact that the property generalization is single-valued implies that the categorization is non-overlapping, i.e. each object has at most one generalization. The NOMETHOD clause defines the inheritance behavior of this relationship: the specialized objects inherit the behavior from the general ones. Application classes for nodes and links, which realize the same model as Schema 8 can then use these relationships as follows. CLASS Node METACLASS Generalization OWNTYPE Node_owntype INSTTYPE Node_insttype END; CLASS Link METACLASS Specialization OWNTYPE Link_owntype INSTTYPE Link_insttype INIT SELF³initgen(Node); END;

The INIT clause is used to establish the fact that links are a specialization of nodes. The object types Node_owntype, Node_insttype, Link_owntype and Link_insttype are defined by the application programmer and provide the application-specific properties and methods of nodes and links. Level 3: metaclasses Level 2: application classes


ÍÍ ÍÍ ÍÍ

Generalization

General_insttype

Í ÍÍ

Specialization

specialization Node

Link

Node_owntype

ÉÉ ÉÍÉ ÍÍ

General_instinsttype

Node_insttype

to from

Special_insttype Link_owntype

ÉÉ ÉÉ ÉÉ ÍÍ ÉÉ ÍÍ ÉÉÍÍ É

specialization message passing

Special_instinsttype Link_instype

Fig. 8. A hypertext database using specialization introduced by metaclasses (Schema 9). Legend (in addition to the legend given in Figure 6): The pattern specifies that an object type is assigned as instance-instance type to a metaclass.


3.3 Generic Hypertext Modelling From the viewpoint of reusability the above class definitions for hypertext structures are not satisfying. We want to provide the structure and behavior of hypertext structures in a form such that it can be reused in different applications. We discuss in the following two fundamentally different possibilities of how this is accomplished in VML. For the generic hypertext models we will consider the content of a hypertext node no longer as inherent property. It will be added in the definition of application specific hypertext classes. A first approach is to exploit the dual model and provide only the parametrized object types within a library which can then be reused in different application class definitions. These object-type definitions also inherit all the properties needed to manage a category specialization relationship. Such a library can be given by the following object types (we omit the own types here). Schema 10. A generic hypertext model using parametrized object types. OBJECTTYPE Node_insttype[Link: Link_insttype] SUBTYPEOF Generalization_instinsttype INTERFACE PROPERTIES fromlink: {Link}; tolink: {Link}; END; OBJECTTYPE Link_insttype[Node: Node_insttype] SUBTYPEOF Specialization_instinsttype INTERFACE PROPERTIES from: Node; to: Node; END;

An application class designer may now use these object types as follows. CLASS MyNode INSTTYPE OBJECTTYPE SUBTYPEOF Node_insttype[MyLink] /* application specific definitions */ OWNTYPE Node_owntype END; CLASS MyLink INSTTYPE OBJECTTYPE SUBTYPEOF Link_insttype[MyNode] /* application specific definitions */ OWNTYPE Link_owntype[MyNode] END;

We observe the following problem with this approach. When using the object types a constraint has to be observed in order to get a consistent class definition. The parameters used in the class definition of MyLink express the fact that links of this class con-


nect nodes of the class MyNode. Vice versa the parameters used in the class definition of MyNode express the same fact. Thus it is the user’s responsibility to substitute these parameters properly in order to use the proper domains for the parameters and thus get a consistent schema. Relieving the user from the burden to control such constraints is one of the main motivations for the usage of metaclasses instead of parametrized object types. Metaclasses allow to control such constraints as they can control simultaneously the behavior of classes and their instances. We illustrate this by giving an alternative generic VML hypertext model based on metaclasses which ensure that the proper domains will be used (see Figure 9).

Schema 11. A generic hypertext model using metaclasses. CLASS Node METACLASS Metaclass INSTTYPE Node_insttype /* defines behavior of node classes */ INSTINSTTYPE Node_instinsttype /* defines behavior of nodes */ END; CLASS Link METACLASS Metaclass INSTTYPE Link_insttype[Node, Node] /* defines behavior of link classes */ INSTINSTTYPE Link_instinsttype /* defines behavior of links */ END; OBJECTTYPE Node_insttype SUBTYPEOF Generalization_insttype INTERFACE METHODS createnode(): OID; END; OBJECTTYPE Link_insttype[C: Theta, G: Theta] SUBTYPEOF Specialization_insttype /* C is the metaclass of node classes for connection, /* G is the metaclass of node classes for generalization*/ INTERFACE PROPERTIES possiblelink: { [from: C, to: C] }; METHODS isasnode(node: G); /* inits specialization relationship, uses initgen(), checks whether node in G */ haslinks(link: {[ from: C, to: C ]} ); /* sets possible link classes */ createlink(from: C, to: C): OID; /* creates a corresponding node instance in the appropriate generalization class G, from/to may be node or link */ END; OBJECTTYPE Node_instinsttype SUBTYPEOF Generalization_instinsttype INTERFACE PROPERTIES fromlink: { OID }; tolink: { OID }; END;


OBJECTTYPE Link_instinsttype SUBTYPEOF Specialization_instinsttype INTERFACE PROPERTIES from: OID; to: OID; END;

In the above schema the control over the relationship between node and link classes and their instances is maintained by the methods provided for example in Link_insttype. The relation between the Link metaclass and the Node metaclass is established by the parameters of Link_insttype. The domains of properties at the instance– instance level are of the data type OID, as the particular classes to which the property values will belong are not known at the time of definition of the metaclasses. The domains of properties at the instance level are specified by the class parameters C and G. C is used for specifying the kind of nodes that a particular kind of link connects. G is used for specifying the kind of nodes of which the links are specializations. This distinction will prove valuable when introducing versioning of hypertext structures in Section 3.6. The type restrictions on the instance types of C and G are specified as the empty object type Θ, which was introduced in Section 2.4.4 and which is denoted in the VML language by Theta. Level 3: metaclasses

ÍÍ ÍÍ ÍÍ ÍÍ ÍÍ

Generalization

Level 2: applicaGeneral_insttype tion classes Node_insttype Level 1: individual objects

General_instinsttype Node_instinsttype MyNode_insttype

É ÉÉ ÍÉÍ ÉÍ

Node

Link

specialization MyNode

Í ÍÍ Í Í

Specialization

MyLink

Special_insttype Link_insttype

to from


É ÉÉ ÍÉÍ ÉÍ

Special_ instinsttype

Link_instinstype MyLink_instype

Fig. 9. Usage of the hypertext metaclasses.

Once the metaclasses are defined an application designer who creates application classes as instances of these metaclasses cannot violate the consistency constraints of hypertext structures. A sample application of the metaclasses would be CLASS MyNode METACLASS Node; INSTTYPE MyNode_type; /* application specific definitions for MyNode */ END;


CLASS MyLink METACLASS Link; INSTTYPE MyLink_type; /* application specific definitions for MyLink */. INIT SELF³haslinks({ [from: MyNode, to: MyNode] }); SELF³isasnode(MyNode); END;

With the above metaclass schema we got something more for free. We can now introduce different kinds of links and nodes and specify connectivity constraints between them, i.e., constraints on the kind of nodes a class of links may connect. For example it is very natural to distinguish between a node class for nodes that cannot be links and one for those that can represent links. CLASS MyNode METACLASS Node; INSTTYPE MyNode_type; /* application specific behavior of this node class */ END; CLASS MyLinkasNode METACLASS Node; INSTTYPE MyLinkasNode_type; /* application specific behavior of MyLink*/ END; CLASS MyLink METACLASS Link; INSTTYPE MyLink_type; INIT SELF³haslinks({ [from: MyNode, to: MyNode], [from: MyNode, to: MyLinkasNode] }); SELF³isasnode(MyLinkasNode); END;

Thus we have a categorization principle for nodes and links working together with a mechanism to maintain connectivity constraints. But note that this categorization principle is very different from that introduced in the previous section used to model links as a specialization of nodes. The categorization is not realized by relating an instance of a generalization class with an instance of a specialization class, which represents the category, but by relating the classes that represent the categories to one metaclass. As a consequence this kind of categorization is not visible at the application level – no generalization class is available there – but only at the metaclass level. In some cases it may be favorable to hide some of the complexity of the above metaclass schema from the user. For example it may not be necessary that the user is aware of the fact that each link object is related to a node object, but that he simply wants to talk about links and nodes. This can be done by introducing anonymous classes. To this extent we introduce new metaclasses Nodeanonymous and Linkanonymous which are derived from the schema for the metaclasses Node and Link by adding additional behavior.


Schema 12. A generic hypertext with anonymous classes. CLASS Nodeanonymous METACLASS Metaclass OWNTYPE Node_owntype[Nodeanonymous] INSTTYPE Node_insttype INSTINSTTYPE Node_instinsttype END; CLASS Linkanonymous METACLASS Metaclass INSTTYPE Linkanonymous_insttype[Node, Nodeanonymous] INSTINSTTYPE Link_instinsttype END; OBJECTTYPE Node_owntype[N: Theta] INTERFACE METHODS createnodeclass(): N; END; OBJECTTYPE Linkanonymous_insttype[C: Theta, G: Theta] SUBTYPEOF Link_insttype /* C is the connected metaclass, G is the generalization metaclass */ INTERFACE METHODS initall(link: {[ from: C, to: C ]}); IMPLEMENTATION METHODS initall(link: {[ from: C, to: C ]}); { haslinks(link); g:=G→createnodeclass(); SELF→isasnode(g); }; /* this method creates an anonymous node class and instantiates it as the generalization class of the link class, receiving the method */ END;

Then the application programmer can write the class definitions this way. CLASS MyNode METACLASS Node; INSTTYPE MyNode_type; /* application specific behavior of this node class */ END; CLASS MyLink METACLASS Linkanonymous; INSTTYPE MyLink_type; INIT SELF³initall({ [from: MyNode, to: MyNode] [from: MyNode, to: MyLink] }); END;

The method call initall in the INIT clause of the class definition of MyLink instantiates an anonymous node class of which the link class MyLink is a specialization. The implementation of the method initall is shown in the declaration of the object type Linkanonymous_insttype. Note that this way of hiding structure from the user leads to additional constraints on the hypertext model. In this model node classes can either be named node classes with metaclass Node that contain ‘‘real” nodes or anonymous node classes with metaclass Nodeanonymous that contain ‘‘link” nodes. Classes that contain both are no longer definable. 3.4 Aggregation Hierarchies A concept which is even more fundamental in document structures than the concept of hypertext structures is the concept of hierarchical aggregation, as it is used, e.g., in


[13]. Each document consists of parts which in turn are composed of simpler parts and so on until one arrives at atomic units. For example, a paper consists of title and text, the text consists of sections, and the sections in turn consist of paragraphs of plain text. Of course parts of documents may also be hypertext structures, thus we will have to consider later the integration of the concepts of hypertext and hierarchical aggregation. But first we want to introduce hierarchical aggregation as an isolated concept, and restricted to a very simplified form. We do not consider the internal ordering of the document parts, nor do we consider sharing of document parts by different documents. We can distinguish two kinds of document parts. Those which are composed of others and which we call composite, and those which are not and which we call atomic. The relationship between composites and atomics is very similar to that between links and nodes. Composites refer to atomics and they can share all the properties atomics have. The main difference is that composites can exist without referring to any parts, while for a link the source and sink node always have to exist. We do not consider here all the design possibilities for aggregation hierarchies as they are quite similar to those for hypertext structures. Therefore we just present a complete schema for modelling aggregation hierarchies, which is based on the analogous design decisions that we took for hypertext structures. An application of this metaclass schema with one atomic and two composite document types is illustrated in Figure 10. Schema 13: A generic aggregation hierarchy model using metaclasses. CLASS Atomic METACLASS Metaclass INSTTYPE Atomic_insttype INSTINSTTYPE Atomic_instinsttype END; CLASS Composite METACLASS Metaclass INSTTYPE Composite_insttype[Atomic, Atomic] INSTINSTTYPE Composite_instinsttype END; OBJECTTYPE Atomic_insttype SUBTYPEOF Generalization_insttype INTERFACE METHODS createatom(): OID; END; OBJECTTYPE Composite_insttype[C: Theta, G: Theta] SUBTYPEOF Specialization_insttype INTERFACE PROPERTIES possiblepart: { C }; METHODS isasnode(n: G); /* inits specialization relationship, uses initgen() */ hasparts(p: { C } ); /*sets part classes */ createcomposite(): OID; /* create with empty set of parts */ END;


OBJECTTYPE Atomic_instinsttype SUBTYPEOF Generalization_instinsttype INTERFACE PROPERTIES partof: OID; /* may be NIL, no sharing of parts*/ END; OBJECTTYPE Composite_instinsttype SUBTYPEOF Specialization_instinsttype INTERFACE PROPERTIES parts: { OID }; /* may be empty */ METHODS insertpart(p: OID); /* checks whether allowed */ END;

Level 3: metaclasses

Atomic

Composite specialization

specialization Level 2: application classes

Articleas Atomic

Chapter

Journalas Atomic

Article

possible part

Journal

possible part parts

parts Level 1: individual objects specialization message passing


Fig. 10. Usage of the aggregation hierarchy metaclasses.

The metaclasses Composite and Atomic are used much in the same way as the metaclasses Node and Link. Thus we skip an explicit example of an application schema here and illustrate the application classes only within Figure 10. 3.5 Versioning Versioning is a fundamental issue in any document model. Here we will consider only one aspect of versioning, namely the aspect that a document or an arbitrary part of a document can have multiple states due to versioning. This is for example the starting


point of a full document-versioning model presented in [8], for which a complete VML implementation will be given in [9]. There, also the concept of tasks is introduced. This concept is important in order to describe the work flow that leads to the different states of document parts and thus is crucial for deriving views on documents versions. As a further simplification of the subsequent discussion of versioning and its integration with the other document concepts we restrict ourselves mainly to the structural aspects. The model we want to consider is described as follows: in document structures any part can consist of multiple states. We do not care about the semantics of these states, i.e., whether they carry a version number or can be related to a particular task within a work flow. We also do not consider the relationships between the different states of different document parts as these will be derived from the relationship of states to tasks and relationships between tasks. Thus we obtain for example for hypertext structures the following simple model derived from the hypertext model introduced in Schema 8.

Schema 14. A hypertext model with versioning at application class level. CLASS VersionedNode INSTTYPE OBJECTTYPE INTERFACE PROPERTIES versions: {VersionableNode}; IMPLEMENTATION NOMETHOD /* delegate each message to an appropriate subset of {versionableNode} depending on the context, specified e.g. by a query or a task */ END; END; CLASS VersionableNode INSTTYPE OBJECTTYPE INTERFACE PROPERTIES

content: anything; tolink: {LinkVersions}; fromlink: {LinkVersions}; specialization: LinkVersions; versionof: VersionedNode;

END; END; CLASS LinkVersion INSTTYPE OBJECTTYPE INTERFACE PROPERTIES

END; END;

from: VersionedNode; to: VersionedNode; generalization: VersionableNode;


Level 2: application classes

LinkVersions

VersionedNode


VersionableNode

versions

to from specialization

Fig. 11. Introducing versioning at the application class level (compare Schema 14).

Note that we could not reuse the class Node due to the different types of backward links and we had therefore to introduce the class VersionableNode. This implies that some import-export facility will be needed when creating a version of a non-versioned document. We will later see a way to avoid this. The class VersionedNode uses a NOMETHOD clause to delegate all document-specific method calls to the corresponding non-versioned document class. This step may depend upon a context which has to be defined by a query or a task which selects a subset of the different document versions. We have to observe the following restriction on versions of nodes: two instances of the class VersionedNode have to have disjoint sets in the versions property. Versions of a link object are obtained by versioning the versionableNode object which represents the generalization of the link object. However, there is also a restriction to observe on versions of links: in the case, that the value of the property versions of an instance of VersionedNode consists of instances of versionableNode which are generalizations of link objects, all these instances of versionableNode have the same instance of LinkVersion as specialization. In other words, versions of a link cannot connect different (versioned) nodes. Both constraints have to be maintained operationally. Versions in aggregation hierarchies are a little bit different as a constraint similar to that formulated for links does not exist for composite objects. In other words, versions of composite objects may consist of different (versioned) parts. Otherwise things are not very different from versioning in hypertext structures. CLASS VersionableAtomic INSTTYPE OBJECTTYPE INTERFACE PROPERTIES END; END;

content: anything specialization: CompositeVersion;


CLASS VersionedAtomic INSTTYPE OBJECTTYPE INTERFACE PROPERTIES versions: {VersionableAtomic}; IMPLEMENTATION NOMETHOD /* delegate each message to an appropriate subset of {VersionableAtomic} depending on the context, specified e.g. by a query or a task */ END; END; CLASS CompositeVersion INSTTYPE OBJECTTYPE INTERFACE PROPERTIES parts: {VersionedAtomic}; generalization: VersionableAtomic; END; END;

If one introduces versioning on an existing document schema in the way illustrated in this section this requires a schema translation process. That means from a given nonversioned document schema a new schema has to be generated, either by hand or automatically, according to certain translation rules, some of which should be clear from the above discussion. This new schema models versions of the documents which are structured in the same way as described in the non-versioned document schema. This contradicts again to our goal of a generic support for document modelling. Therefore we will discuss in the following section the modelling of the versioning concept at the metaclass level and how to integrate this with the other modelling primitives introduced at the metaclass layer earlier. 3.6 Integration of document concepts The goal of this section is to provide a metaclass system that integrates all of the three concepts introduced up to now, namely hypertext, aggregation and versioning. One important design decision we have made earlier, namely separating links and nodes, respectively atomics and composites. This separation will prove valuable in the integration step. It allows to distinguish the different behavior of nodes and links, respectively of atomics and composites with respect to versioning. More precisely, nodes and atomics are not so different at all and thus we unify them in one metaclass called DocObject, links and composites of which will be specializations. The second important decision we take is to derive the connectivity constraints for the versioned classes from the non-versioned classes. Thus we can avoid translation of document schemas for producing the schemas of versioned documents. We have to point out an observation which is fundamental for the process of integrating different concepts, where each of it is already existent in form of metaclass schemas (in our case the metaclasses generalization/specialization, nodes/links, and


atomic/composite). In the VML data model it is not possible to instantiate classes which belong to several metaclasses at a time. So we have first to integrate the object types corresponding to the different concepts by exploiting multiple inheritance and then to produce one integrated metaclass which carries the merged semantics. This appears to be an unnecessary complication, however, it is unavoidable: whenever we mix up different concepts we also have to think about the interdependencies between them. And these are exactly described in the integrated metaclass. For example, in our case one such dependency is exactly the identification of nodes and atomics. First we give the integrated schema for hypertext structures and aggregation without versioning. DocObject is the class that integrates nodes and atomics. Schema 15. An integrated hypermedia document model with versioning. CLASS DocObject METACLASS Metaclass INSTTYPE OBJECTTYPE SUBTYPEOF Node_insttype, Atomic_insttype INTERFACE METHODS createdocobject() DocObject; END; INSTINSTTYPE OBJECTTYPE SUBTYPEOF Node_instinsttype, Atomic_instinsttype END; END; CLASS Link METACLASS Metaclass INSTTYPE Link_insttype[DocObject, DocObject] INSTINSTTYPE Link_instinsttype END; CLASS Composite METACLASS Metaclass INSTTYPE Composite_insttype[DocObject, DocObject] INSTINSTTYPE Composite_instinsttype END;

The object types Node-, Atomic-, Link- and Composite_insttype (resp. instinsttype) are the same as defined for Schema 11 and 13. In order to deal with versioning we introduce classes that model objects that represent versions of nodes and atomics. CLASS VersionedDocObject METACLASS Metaclass INSTTYPE Versioned_insttype[DocObject] INSTINSTTYPE Versioned_instinsttype END; CLASS LinkVersions METACLASS Metaclass INSTTYPE Link_insttype[VersionedDocObject, DocObject] INSTINSTTYPE Link_instinsttype END;


CLASS CompositeVersions METACLASS Metaclass INSTTYPE Composite_insttype[VersionedDocObject, DocObject] INSTINSTTYPE Composite_instinsttype END; OBJECTTYPE Versioned_instinsttype INTERFACE PROPERTIES versions: { OID } IMPLEMENTATION NOMETHOD /* select subset of versions according to context and delegate message call to it */ END; OBJECTTYPE Versioned_insttype[C: Theta] INTERFACE PROPERTIES versionclassof: C; METHODS versionof(n: C); /* sets versionclassof */ createversion(n: OID): OID; /*creates a versioned object for nonversioned object n, checks if correct version class */ IMPLEMENTATION NOMETHOD {versionclassof³currentmethod(arg);} END;

Note how the parametrization of Link_insttype and Composite_insttype is used. The relationships between the classes and metaclasses of versioned and non-versioned hierarchical document structures is illustrated in Figure 12. We remark that a distinction as it is made between Atomic and VersionableAtomic in Schema 14 is no longer needed as the references used in the atomic objects, i.e. Chapter, in order to refer to their version objects, i.e. versionedChapter, are object identifiers when introducing these classes via metaclasses. With regard to composites, i.e. Article, two different classes are introduced for versioning. One is ArticlewithVersionedChapter, which models composites holding versioned parts, and the other is versionedArticleasDoc, which models versions of composites. We now give a sample schema making use of the metaclass schema, under the assumption that the user is aware of the difference between versioned and non-versioned documents. CLASS Chapter METACLASS DocObject INSTTYPE Chapter_type END; CLASS versionedChapter METACLASS VersionedDocObject INIT SELF³versionof(Chapter); END;


CLASS Article METACLASS Composite INSTTYPE Article_type; INIT SELF³hasparts({ Chapter }); SELF³isasnode(ArticleasDoc) END; CLASS ArticleasDoc METACLASS DocObject INSTTYPE ArticleasDoc_type END; CLASS versionedArticle METACLASS VersionedDocObject INIT SELF³versionof(ArticleasDoc); END; CLASS ArticlewithVersionedChapter METACLASS CompositeVersions INIT SELF³hasparts({ versionedChapter }); SELF³isasnode(ArticleasDoc); END;

Level 3: metaclasses DocObject Link Level 2: application classes Chapter

Composite

Composite Versions

versioned DocObject

LinkVersions

specialization ArticleasDoc

Article

possible part

Articlewith VersionedChapter

versionof

versioned Chapter versioned ArticleasDoc possible part

parts versionof

parts specialization Level 1: individual objects

message passing

specialization

message passing

Fig. 12. An integrated hypermedia document database including versioning and part-of relationships


This schema finishes our discussion of design alternatives in hypermedia document modelling. As a continuation we could consider to build upon this basic metaclass schema additional operations which make certain classes anonymous in order to hide some of the complexity of the underlying structures from the user. However this would be out of the scope of this presentation. Also we do not consider here the issues of how to control the different constraints explained earlier for versioned links and composites.

4 Conclusion In this paper we presented the VODAK Model Language VML and its application in the area of hypermedia systems. Only the most important features of VML have been introduced. The main principle we showed was the usage of metaclasses, the separation of object types and classes, the concept of instance-instance types, and the method delegation via the NOMETHOD clause for the construction of specific semantic data models for individual applications. The separation of types and classes, called the dual model, was not only used at the level of application classes, but also at the level of metaclasses. In combination with the concept of metaclasses and the parameterization of object types we demonstrated how modelling primitives and modelling constraints can be introduced into the data model. This approach tries to overcome the limitations of existing models, which come with a fixed set of predefined modelling primitives, which fit well into the original application domain the models have been developed in. But they provide neither adequate modelling primitives for other application domains nor extension or adaption mechanisms which would allow a designer to extend or adapt the model such that it meets specific application requirements. VML has been developed as a database programming language which allows to construct individual semantic data models based on a kernel object-oriented data model. The examples we used for the purpose of demonstrating the VML concepts come from real applications which have been prototyped at the institute: the cooperative authoring system SEPIA [33] which is based on the hypertext approach, the multimedia electronic news magazine Multimedia Forum which uses a SGML-based document database and which makes use of a document-versioning model, and a multimedia document archive which organizes all the documents in a hierarchical way according to the DFR standard [14]. These applications served as a test bed and evaluation framework for our concepts and have shown that VML meets the requirements of constructing adequate modelling primitives and of defining the concrete database schemas. The examples have also demonstrated some of the numerous design principles which have to be considered when developing data models for VML. Some of them are of a general nature, like the principle of semantic-free associations and the trade off between declarative and operational specifications in the data model. Others are specific for the different features of the VML data model, like the usage of metaclasses for introducing semantic relationships and their integration, the trade off between using parametrized object types and metaclasses, which emerges from using a


dual model, or the dynamic creation of anonymous classes, which is possible by treating classes as first class objects. Further developments with respect to VML include extensions for modelling multimedia data. So far, VML provides built-in data types for audio and video, and a prototype has been built which allows to transparently manage digital and analog video databases [29]. Extensions will include mechanisms to describe time dependency between multimedia data, or mechanisms to handle the interactive aspects of data like videos and audios. The VODAK prototype itself is currently extended by new modules, like a continuous object manager, which allows a real integration of multimedia data.

Acknowledgement We like to thank A. Haake and H. Schütt for fruitful discussions of which we benefitted greatly to become familiar with the document-versioning model developed within the thesis of A. Haake and the SEPIA prototype developed in the WIBAS group of GMD-IPSI.


Appendix: Interdependencies of the hypermedia schemas

Hypertext document structures Links as objects (Schema 6)

Alternatives only nodes (Schema 3)

common features of Links and Nodes Generalization of links and nodes (Schema 8)

Unification of links and nodes (Schema 7)

application independent support for generalization Generalization as metaclass (Schema 9) application independent support for hypertext Nodes and links as metaclasses (Schema 11)

Nodes and links as parametrized object types (Schema 10)

different node/link types Metaclasses for typed nodes and links (Schema 11)

Anonymous typed nodes and links (Schema 12)

Hierarchical document structures Hierarchical aggregation (Schema 13, based on Schema 11)

Versioning Versioning of hypertext (Schema 14, based on Schema 8) and hierarchical aggregation

Integrated application-independent support for hypertext and hierarchical documents with versioning Integration of concepts (Schema 15, based on Schema 11, Schema 13, Schema 14)


References 1.

Aberer, K., Klas, W.: The Impact of Multimedia Data on Database Management Systems. IEEE Workshop on Multimedia Computing, Pittsburgh, PA, (1993).

2.

Akscyn, R., McCracken, D.L., Yoder, E.: A distributed hypertext for sharing knowledge in organizations. In: Communications of the ACM 31, 7, 820–835 (1988).

3.

Beeri, C., Schek, H.-J., Weikum, G.: Multi-Level Transaction Management, Theoretical Art or Practical Need? In: Proceedings EDBT’88, Venice, (1988).

4.

Campbell, B., Goodman, J.M.: HAM: A General Purpose Hypertext Abstract Machine. In: Communications of the ACM 31, 7, 856–861 (1988).

5.

Delisle, N., Schwartz, M.: Neptune: A hypertext system for CAD applications. In: Proceedings of ACM SIGMOD ’86, New York, 132–142 (1986).

6.

Garret, L.N., Smith, K.E., Meyrowitz, N.: Intermedia: Issues, strategies, and tactics in the design of a hypermedia document system. In: Proceedings of the Conference on Computer-Supported Cooperative Work, 163–174 (1986).

7.

Goldfarb, C. F. : HyTime: A Standard for Structured Hypermedia Interchange. In: IEEE Computer 24(8), 81 – 84 (1991).

8.

Haake-Weber, A.: Publishing Tools Need Both: State-Oriented and Task-Oriented Version Support. In: Proceedings of the 15th Annual International Computer Software and Applications Conference (COMPSAC-91), Tokyo, Japan, 633 – 639, (1991).

9.

Haake, A.: Dissertation, Univ. Darmstadt, private communication (1993).

10.

Haake, J., Wilson, B.: Supporting Collaborative Writing of Hyperdocuments in SEPIA. In: Proceedings of the ACM 1992 Conference on Computer Supported Cooperative Work (CSCW’92), Toronto, Ontario, 138 – 146, New York: ACM Press (1992).

11.

Halasz, F.G., Moran, T.P., Trigg, R.H.: NoteCards in a Nutshell. In: Proceedings of the 1987 ACM Conference of Human Factors in Computer Systems (CHI +GI ’87), Toronto, Ontario, 45–52 (1987).

12.

Halasz, F.G.: Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems. In: Communications of the ACM, Vol. 31, No. 7 (1988).

13.

ISO/IEC International Standard 8879-1986: Information Processing — Text and Office Systems — Standard Generalized Markup Language (SGML) (1986).

14.

ISO/IEC International Standard 10166–1: Information Technology – Text and Office Systems – Document Filing and Retrieval (DFR) – Part 1 and Part 2, First edition (1991).

15.

Klas, W.: A Metaclass System for Open Object-Oriented Data Models. Doctoral Thesis, Technical University of Vienna (1990).

16.

Klas, W., Neuhold, E.J., Schrefl, M.: Using an Object-Oriented Approach to Model Multimedia Data. Computer Communications. In: Special Issue on Multimedia Systems, Vol. 13, No. 4, 204-216 (1990).

17.

Klas, W., Neuhold, E.J., Schrefl, M.: Metaclasses in VODAK and their Application in Database Integration. Arbeitspapiere der GMD, No. 462, Sankt Augustin (1990).

18.

Klas, W., Neuhold, E.J.: Designing Intelligent Hypertext Systems Using an Open Object-Oriented Database Model. Arbeitspapiere der GMD, No. 489, Sankt Augustin (1990).


19.

20.

21.

22.

23. 24.

25.

26.

27. 28. 29. 30.

31.

32.

33.

Klas, W., Neuhold, E.J., Bahlke, R., Fankhauser, P., Fischer, G., Kaul, M., Muth, P., Rakow, T., Turau, V.: VODAK Design Specification Document, VML-VODAK Model Language, Version 3.0. Working paper GMD (1992). Klas, W.: Tailoring an Object-Oriented Database System to Integrate External Multimedia Devices. Workshop on Heterogeneous Databases & Semantic Interoperability, Boulder (1992). Klas, W., Fischer, G., Aberer, K.: Integrating a Relational Database System into VODAK Using its Metaclass Concept. Arbeitspapiere der GMD No. 738, Sankt Augustin (1993). Meyrowitz, N.: Intermedia: The Architecture and Construction of an Object-oriented Hypermedia System and Applications Framework. In: Proceedings of the Conference on Object-oriented Programming Systems, Languages, and Applications (OOPSLA’86), Portland , Oregon, ACM SIGPLAN Not. 21, 11 (1986). Muth, P., Rakow, T.C.: Atomic Commitment for Integrated Database Systems. In: Proceedings of IEEE 7th Int. Conf. on Data Engineering, Kobe, Japan (1991). Muth, P., Rakow, T.C., Klas, W., Neuhold, E.J.: A Transaction Model for an Open Publication Environment. In: A. K. Elmagarmid (Ed.): Database Transaction Models for Advanced Applications. Morgan Kaufmann Publishers, San Mateo, California (1992). Muth, P., Klas, W., Neuhold, E.J.: How to Handle Global Transactions in Heterogeneous Database Systems. In: Proceedings of IEEE 2nd Int. Workshop on Research Issues on Data Engineering – Transaction and Query Processing (RIDE-TQP), Phoenix, Arizona (1992). Muth, P., Rakow, T. C., Weikum, G., Hasse, C., Broessler, P.: Semantic Concurrency Control in Object-Oriented Database Systems. In: Proceedings of IEEE 9th Int. Conf. on Data Engineering (1993). Rakow, T., Gu, J., Neuhold, E.J.: Serializability in Object-Oriented Database Systems. Proc. 6th Int. Conf. on Data Engineering, Los Angeles, California (1990). Rakow, T.C., Löhr, M., Moser, F., Neuhold, E.J.: Using Object-Oriented Database Systems for Multimedia Applications (in German). In: it+ti, 3, 93, Oldenbourg (1993). Rakow, T.C., Muth, P.: The V3 Video Server – Managing Analog and Digital Video Clips. In: Proceedings SIGMOD ’93, Washington DC (1993). Schütt, H.,Streitz, N.: HyperBase: A Hypermedia Engine Based on a Relational Database Management System. In: Rizk, A., Streitz, N., André, J. (Eds.), Hypertext: Concepts, Systems, and Applications: Proceedings of the First European Conference on Hypertext, Versailles, France, 95 – 108. Cambridge University Press, The Cambridge Series on Electronic Publishing (1990). Smith, J.B., Weiss, S.F., Ferguson, G.J., Bolter, J.D., Lansman, M., Bea, D.V.; WE: A writing environment for professionals. Technical Report 86-025, Dept. of Computer Science, University of North Carolina, Chapel Hill, N.C., Aug. (1986). Smith, J.B., Weiss, S.F., Ferguson, G.J.: A hypertext writing environment and its cognitive basis. In: Proceedings of the Hypertext ’87 Workshop, University of North Carolina, Chapel Hill, North Carolina (1987). Streitz, N., Haake, J., Hannemann, J., Lemke, A., Schuler, W., Schütt, H., Thüring, M.: SEPIA: A Cooperative Hypermedia Authoring Environment. In: D. Lucarella, J. Nanard, M. Nanard, and P. Paolini, (Eds.), Proceedings of the 4th ACM Conference on Hypertext (ECHT ‘92) , Milan, Italy, 11 – 22 (1992).


34.

Streitz, N., Hannemann, J., Thüring, M.: From Ideas and Arguments to Hyperdocuments: Travelling through Activity Spaces. Proceedings of HYPERTEXT’89, Pittsburgh (1989).

35.

Thimm, H., Rakow, T.C.: Upgrading Multimedia Data Handling Services of a Database Management System by an Interaction Manager. Arbeitspapiere der GMD, Sankt Augustin (1993).

36.

Turau, V., Rakow, T.C. : A Schema Partition for Multimedia Database Management Systems. Arbeitspapiere der GMD, No. 729, St. Augustin, (1993).

37.

Wächter, H., Reuter, A.: Transaction concepts and recovery mechanisms for object bases. Technical Report 322 672, Re 660/2–1, University of Stuttgart, FRG (1989).

38.

Walker, J.: Document Examiner: Delivery interface to hypertext documents. In: Proceedings of the Hypertext ’87 Workshop, University of North Carolina, Chapel Hill, North Carolina (1987).

39.

Weikum, G., Hasse, C., Broessler, P., Muth, P.: Multi Level Recovery. In: Proceedings of 9th Symp. on Principles of Database Systems (PODS), Nashville, Tennessee (1990).

40.

Weikum, G.: A Theoretical Foundation of Multi-Level Concurrency Control. In: Proceedings of 5th Symp. on Principles of Database Systems (PODS), Cambridge, Massachusetts (1986).

Object-Oriented Modelling for Hypermedia Systems Using ... - CiteSeerX

Object-Oriented Modelling for Hypermedia Systems Using ... - CiteSeerX

Suggest Documents

An Architecture for Hypermedia Systems Using

Server Support for Cooperative Hypermedia Systems - CiteSeerX

in Distributed Hypermedia-Systems - CiteSeerX

Modelling Electronic Service Systems Using UML - CiteSeerX

Dependability Modelling of Repairable Systems using ... - CiteSeerX

On Second Generation Hypermedia Systems - CiteSeerX

Evaluation of Adaptive Hypermedia Systems' Conversion - CiteSeerX

Third Generation Adaptive Hypermedia Systems 1 ... - CiteSeerX

Embedding Hypermedia into Information Systems - CiteSeerX

Modelling Synchronized Hypermedia Presentations - Unipd

Using a Hypermedia System for Systems Engineering - FernUni Hagen

An Architecture for Hypermedia Systems Using MHEG ... - PUC-Rio

Adaptive Intelligent Hypermedia using XML - CiteSeerX

Using Hypermedia Technology to Explore Connections ... - CiteSeerX

Teaching Computer Science Using Hypermedia - CiteSeerX

Modelling Distributed Systems - CiteSeerX

an XML implementation for hypermedia systems modeling ... - CiteSeerX

Hypermedia Modelling Using UML 1 Introduction - Semantic Scholar

Server Support for Cooperative Hypermedia Systems

DYNAMIC ADAPTIVE HYPERMEDIA SYSTEMS FOR E-LEARNING

Testing ObjectOriented Software

Software Engineering for Adaptive Hypermedia Systems

Modelling User Navigation Behaviours in a Hypermedia ... - CiteSeerX

Modelling User Navigation Behaviours in a Hypermedia ... - CiteSeerX