Integration and Handling of Hypermedia ... - Semantic Scholar

1 downloads 0 Views 201KB Size Report
Gerald Huck, Frank Moser, Erich J. Neuhold. GMD - Integrated Publication and Information Systems Institute (IPSI). Dolivostrasse 15, D-64293 Darmstadt, ...
Integration and Handling of Hypermedia Information as a Challenge for Multimedia and Federated Database Systems Gerald Huck, Frank Moser, Erich J. Neuhold GMD - Integrated Publication and Information Systems Institute (IPSI) Dolivostrasse 15, D-64293 Darmstadt, Germany Fax: ++49-6151-869966 E-mail: fhuck, moser, [email protected]

Abstract In every aspect of today's professional and private life, information becomes the key to planning, decision making and cooperation. The current widely used databases have been developed for the storing and handling of business data of record and/or table format. Other types of data typically have to be stored in le systems of various complexities. Over the last ten years this de cit of databases has been recognized and new research/development e orts for extended/novel database management systems have been started. Object-oriented, deductive, active, multimedia, and hypertext databases are only some of these systems. In this paper we will argue that multimedia database systems will be needed for the handling of today's and tomorrow's information. These data again can be seen under a hypermedia document paradigm. To support these document structures and their manipulation, extensible object-oriented databases are one of the most promising avenues currently explored. We shall illustrate how such an approach can be used at the "data"end to integrate distributed and heterogeneous multimedia information sources and at the "usage" end to provide a broad range of paradigms for domain speci c representation and handling mechanisms both in multi-user and cooperating user environments. This exibility will ultimately be needed to support aspects like ubiquitous or domesticated computing for the information age to come.

started. Object-oriented, deductive, active, multimedia, and hypertext databases are only some of these systems. In this paper we will argue that multimedia data systems will be needed for the handling of today's and tomorrow's information. These data again can be seen under a hypermedia document paradigm. To support these document structures and their manipulation, extensible object-oriented databases are one of the most promising avenues currently explored. We illustrate how such an approach can be used at the "data" end to integrate distributed and heterogeneous multimedia information sources and at the "usage" end to provide a broad range of paradigms for domain speci c representation and handling mechanisms both in multi-user and cooperating user environments. The paper is organized as follows: The next chapter outlines the publication process as one possible scenario where hypermedia information handling is necessary and derives the most important system requirements from this scenario. The third section introduces the necessary extensions and concepts needed to support multimedia data in databases appropriately. The fourth section deals with the standardization of document archives and with document description standards as the means necessary to overcome current application and system dependent representations. The fth section introduces a framework for database interoperability and presents a methodology for schema integration based on uni cation by augmentation rules.

1 Introduction

2 New Requirements

The current widely used databases have been developed for the storing and handling of business data of record and/or table format. Other types of data typically have to be stored in le systems of various complexities. The Worldwide WEB and Gopher are rst attempts to overcome system boundaries and to provide a uniform access to information of various kinds including pictures, videos, audios and hyper documents. Over the last ten years the de cits of databases to handle these kind of data have been recognized and new research e orts for novel database management systems have been

Nowadays, information and knowledge is more and more available through electronic sources and libraries. We will brie y introduce a typical new application scenario, The Publication Process. The Multimedia Forum [18], a sample scenario of a publication process, was developed at GMD's IPSI (Integrated Publication and Information System Institute).

The Publication Process The main functionality of a publication process is the import (creation and acquisition), the processing and the export (retrieval and distribution) of complex structured documents. The import part is responsible for the initializing of information sources and the transformation of import formats. Processing consists of storing, retrieval, and manipulation of documents, by Multimedia-Editors on top of a rich semantic document model (e.g. Hypertext). The latter aspect deals

import

processing

export

status info

ext. doc.

retrieval and select

contr. info dig. doc.

mm doc.

edit

enrich

release mm doc.

digitize archiving anal. doc. store

enr. doc.

distribute

work. doc.

pro– duct

ar– chive access

gen. prof. selection ind. prof.

Figure 1: The Publication Process with export of information and its distribution to users. Administrative functions such as access control mechanisms, work ow-management and accounting are seen as important features, but will be neglected in the following. Figure 1 shows the Publication Process. 1. Import: Various input information for media types are imaginable. Paper or electronic documents, analog or digital media like graphic, video clips or audio, numerical data and hypertext documents are accessible via various information bases. Such sources can be e.g. paper archives, the user's mailbox, private archives, heterogeneous globally accessible or online databases, video/audio le-servers or public archives. The rst step in a publication process is the Digitalization of analog data input. All digital data need then to be prepared to (i) an appropriate document format (e.g. SGML), (ii) compressed data streams (e.g. MotionJPEG to MPEG) or (iii) manipulated media data (e.g. only the abstract). Categorization, the lling with content describing information and the actual insertion into the multimedia document pool are other necessary steps within the import function. The input to the document pool of our Multimedia Forum is a hypermedia document consisting of an SGML document and linked multimedia content data. With these next generation formats for document description, the shortcomings of speci c word processing systems, such as Word, have been taken into account. Even on this level there is a broad range of approaches to document description. At our institute the decision has been taken to focus on the Standard Generalized Markup Language (SGML) [1] and its extension by HyTime [20]. This decision has turned out to be advantageous due to the rich assortment of SGML-based systems and the general SGML-related research interest.

2. Processing: Documents are stored or archived in multimedia document pools. The editing process can be supported by help of a hypermedia information system, consisting of a hypertext editor (e.g. the hypertext editor SEPIA [27]) and a multimedia document pool. An integrated retrieval interface to the document pool and other media or task oriented tools (e.g. the terminology editor TEDI [16]) are other useful information processing tools in an hypermedia environment. The integration process of various (multimedia) pools, designed on heterogeneous database systems, is explained in 5. Editing is always a process among several editors. Cooperating tools are therefore required. Versioning is another important issue of a hypermedia processing system in a publication environment. 3. Export/Retrival: Selection and retrieval facilities are functions of an export component as well as for the application programming interface of the hypermedia system. Retrieval facilities can be based on formal query languages or navigational interfaces. A query language approach can be ad hoc or embedded, declarative or logic based. Application dependent interface navigators, which are built on their own query engine, can better support user needs in a speci c application context. The disadvantage is a lack of reusability and exibility. 4. Release: Release is the control mechanism which is applied before distributing the electronic product. From a technical point of view the distribution is mainly opening and transmitting data to a speci c communication channel. These could be networks, an external storage device (e.g. Disk or ROM), external or online databases, or an electronic archive. Typical new distribution channels are new services e.g. electronic bookstores or electronic libraries.

List of new Requirements The Publication Process is a good example for new requirements for information handlers which are not covered by the current state of the art in software technology. 1. Powerful data modelling possibilities: The transformation of hyperdocuments together with highly structured multimedia data into a system understandable form needs to be supported by a progressive objectoriented data model which supports e.g specialization / generalization, hierarchies, etc. 2. Advanced retrieval functionality: Nearly all components in a publication environment need retrieval functionality. Declarative, logic based, and navigational query languages are appropriate. 3. Support of concurrent access to data: Due to the nature of the editing process, access by multiple users at the same time to the same data has to be supported. This can be achieved by an underlying transaction processing system. 4. Multimedia Support: Various multimedia data types can be identi ed. Functional and realtime support is a must. Problems like synchronization of data streams, data independence, ecient placement of multimedia data, interruptibility of presentations, and device management are to be solved within the underlaying system layers and should not be left to the application. 5. Globally accessible publication data: Publication data is distributed globally. Suitable international standards for the global access are e.g. MHEG [22] or DFR [2]. Furthermore, it must be possible that document content describing standards as e.g. SGML, HyTime or HTML as a de facto standard can be modelled by means of the underlying technology. 6. Integration of heterogeneous data sources: Information sources are distributed globally. The contained data is modelled in di erent data models. The schemas normally focus on di erent aspects of the real world and even the same aspect in the models can di er in its structural representation and granularity. Integration of these sources is necessary to provide interoperability between the sources and to allow applications transparent access to the global information via a unifying, integrated schema.

3 Components of a Multimedia DBMS Most multimedia applications involve a diversity of di erent data types as well as storage and presentation devices. Especially, the di erent user categories, e.g. authors, editors and readers, of a cooperative publishing environment need to be supported in storing, retrieving, and accessing large amounts of multimedia information. Additionally, users should be able to access the information in an interactive manner which allows more than the conventional consumption of e.g. video and television. We consider an object-oriented database management system (OODBMS) best suited to implement the requirements of multimedia applications in a publishing environment. Multimedia database management systems, understood as an extension of OODBMS's, are especially required to handle small as well as huge data, to manage time independent as

CLASS Movie PROPERTIES video: Video; audio: Audio; IMPLEMENTATION METHODS stop(); { video–>stop(); audio–>stop() }; SCHEDULES play(); { video–>play() AT START SELF; audio–>play() AT START SELF; RETURN AT END video; } END;

schedule declaration start of subschedule with time reference to the start of the schedule end of the schedule with time reference to the end of a subschedule.

Figure 2: Sample Schedule in VML well as time dependent media, to present and control audio and video in a synchronized fashion, and to access storage devices of multimedia systems. The object-oriented database management system VODAK was developed and implemented at IPSI [19] and is currently extended towards multimedia capabilities. All new components of a MMDBMS can be motivated by the need for new functionality or the insuciency of existing ones. The principal components a ected are: (i) Synchronization Manager, (ii) Interaction Management, (iii) Continuous Object Management, and (iv) MM Storage Management.

Synchronization Manager VODAK's message handler, i.e. the component responsible to pass messages to the respective objects, is expanded by a Synchronization Manger (SYM) for time and event control. The component supervises time constraints, and it handles and synchronizes events. The exploitation of multiple media types in parallel is one factor for the attractiveness of multimedia applications. Hence in general the SYM must support parallel presentations of continuous data. We have to differentiate between two kinds of parallel presentations. (i) Parallel presentations without synchronization e.g. several videos independently presented in parallel or an audio presentation that provides background sound for one or several video presentations. (ii) Parallel presentations that have to be performed synchronously, e.g. a video and its soundtrack. To support the de nition of synchronization information for an application programmer, it must be possible to formulate such constraints in the database manipulating language. This was achieved by the integration of a language extension into VML (Vodak's Modelling Language), which allows the de nition of schedules. The main di erence between a normal method execution and a schedule is the possibility of non-serial command sequences, so that parallel presentations of di erent medias can be expressed. Let us explain the main ideas by help of an example (Figure 3). We declare a class Movie. A movie consists here of a Video (the picture data) and an Audio part. The user interaction stop() is speci ed by a normal VML-method de nition. However, a presentation of a movie instance has to take into account the parallel execution of the video and the audio part. This is realized by the integration of the notion of schedules, which handles time reference to start and end points of time-dependent data. The schedule are realized by respective language features in VML. For more information about schedules see [5].

It should be mentioned that neither the concrete intramedia synchronization strategy nor the managing of the actual used presentation device is de ned within the type and class declarations. This functionality is in the responsibility of the Interaction and Continuous Object Manager and is used by the SYM.

1

Interaction Manager The Interaction Manger (IAM) is aiming primarily at the ecient support to capture, present and manipulate continuous data and to control their presentation interactively. The relevant quality of service (QOS) parameters from the database's point of view are the average delay at the beginning of a presentation, the speed ratio between desired and actual speed, and the utilization of stored and presented data. The parameters themselves are not independent of each other, e.g. when presenting a video it might be appropriate to x the speed ratio and to change the utilization in order to overcome temporal bottlenecks. The single units of continuous data, e.g. the frames of a video clip, must not be presented at arbitrary points of time. Instead, the presentation has to be performed according to a certain speed rate. The IAM must be aware of the corresponding intramedia synchronization requirements according to the QOS. Some of the presentation control commands are addressed to currently running presentations like the stop-command. For more details of the IAM see [28].

Continuous Object Manager The Continuous Object Manager (COM) frees the applications from considering time-dependency of multimedia data. Continuous object management functionality can be categorized into object handling, direct access, and bu er resource management. Additionally, it has been found that traditional communication protocols, e.g. TCP/IP or OSI-like protocols are not sucient for real-time requirements of multimedia applications [14], [21]. Therefore, the integration of a multimedia transport protocol is needed. The normal client / server distribution of VODAK is constructed in such a way that a central server component performs all method calls coming from the di erent clients. In the case of a multimedia application this concept is not feasible, mainly due to the impossibility to support interactions on a media stream on client side without retransmission of the data which is not necessary in many cases. This strategy requires a distributed database bu er. The support of interactions for continuous data leads to a new understanding of bu er management strategies. The well-known statical bu er preloading and replacement strategies (e.g. Most Recently Used or Least Recently Used etc.) are to be substituted by more elaborate algorithms which consider the actual structure and behavior of continuous data streams. The primary idea is described by an example of the presentation of an M-JPEG (Motion JPEG) video clip (Figure 3). At the beginning of the presentation the method call play() is sent to the respective object Object. The COM initializes its bu er by preloading continuously the JPEGframes which are needed to best support the presentation state play. Here frame 4 is being presented, 1 to 3 were already displayed and frames 5 to 8 are preloaded. While consuming frame 4, the user change the presentation status from play to fastplay. The COM reorganizes its internal structure on behalf of the new message call fastplay().

ÉÉ ÉÉ ÉÉ ÉÉ ÉÉ ÉÉ ÉÉ ÉÉ ÉÉ ÉÉÉÉ ÉÉÉÉ ÉÉÉÉ ÉÉ ÅÅ ÉÉ ÉÉÉÉ ÅÅ ÉÉ ÉÉÉÉ ÅÅ ÉÉ ÉÉÉÉ ÅÅ ÉÉ ÉÉÉÉ ÅÅÉÉÉÉÉÉ Figure 3: Continuous Object Management Object–>play(...)

1

2

2

3

4

5

6

7

8

3

Object–>fastplay(...) 4 5 6 7 8 10 12 14

The fastplay is technically realized by dropping every second frame. Hence, the new preloaded frames are 10, 12 and 14. Frame 7 is no longer needed. When changing the presentation direction, the COM can use the same strategies by preloading "on the left". A state transition from fastplay to play is realized by frame stung of eventual missing frames. A simple and sucient replacement strategy is: replace frames which are farthest away from the actual presentation point and, therefore, least relevant for the presentation. Other relevant questions of Continuous Object Management are the intra-media synchronization of di erent media streams, how the bu er resource is distributed over several multimedia presentations and how and which scaling [8] or adaptation strategies on the client and the server side can be considered. See [17] for more details on the bu er management strategy, which is called Least/Most Relevant For Presentation (L/MRP).

Multimedia Storage Manager To achieve better performance a Multimedia Storage Manager (MSM) component is integrated, which stores only raw data of continuos objects and is explicitly used by the COM. Multimedia retrieval and storage systems as well as special storage devices (especially magneto optical storage devices) capable of storing large volumes of data are supported. Hence, small and large objects are managed together, but stored di erently. The placement of multimedia streams and the consideration of admission control algorithms which handles new multimedia presentation requests are other functions of this component. For the latter similar approaches as those suggested in [7], [24] were chosen.

4 Managing Documents within Databases The use of standards in new generation information management scenarios is especially attractive to achieve openness in an heterogeneous environment. In the context of e.g. a publication process two dimensions of open access can be distinguished: the description of the structure and access to a document pool and the de nition of the document content itself. In the following for each of the categories a standard is outlined. The standards were modelled in the DBMS VODAK.

Germany

ÇÇÇÇÇ ÇÇÇÇÇ ÇÇÇÇÇÅÅÅÅÅ ÇÇÇÇÇÅÅÅÅÅ ÇÇÇÇÇÅÅÅÅÅ ÇÇÇÇÇÅÅÅÅÅ ÇÇÇÇÇÅÅÅÅÅ Baden– Württemberg

Dire Strait Concert Bild

DFR–Root–Group

Southern Germany

Northern Germany

Hesse

Rhein– Main Area

Audio

Reference Frankfurt

ÇÇÇÇÇÇ ÇÇÇÇÇÇ ÇÇÇÇÇÇ ÇÇÇÇÇÇ ÇÇÇÇÇÇ ÇÇÇÇÇÇ ÇÇÇÇÇÇ Thuringia

Goethe’s Faust

Text

Video

Frankfurt

ÇÇÇ ÇÇÇ ÇÇÇ ÇÇÇ ÅÅÅ ÅÅÅ ÅÅÅ ÅÅÅ

DFR–Group

DFR–Document

DFR–Reference

Multimedia Content

Figure 4: A sample DFR-Archive

A Document Storage Standard The Document, Filing and Retrieval (DFR) [2] standard describes a distributed document ling and retrieval architecture, i.e. documents are stored independently of a speci c exchange or document structuring format in the document pool. A document pool is structured hierarchically to organize documents and to enable queries posed for a subset of documents. The DFR standard is suitable to support the user's need of accessing global document archives. Additionally, the requirement of storing multimedia data within documents impose some modelling and architectural improvements onto the DFR environment [25]. Thus, DFR can be used for a new generation of multimedia teleservices in a Publication Process environment. The information model of DFR arranges all objects in a tree structured hierarchy. The root of this tree is called DFR-Root-Group. This object exists exactly once in every DFR-Archive. The inner nodes of the tree are build up by DFR-Groups. Every object belongs to exactly one DFR-Group (except the DFR-Root-Group). Documents are stored in DFR-Documents. They contain uninterpreted bulks of data thereby enabling the storage of several kinds of document formats even in one DFR-Archive. The content is described by a prede ned but extensible set of DFRAttributes. A DFR-object can indirectly be contained in more than one group by using a DFR-Reference. A DFR archive is realized on top of multimedia VODAK [23]. The Calendar of Events (CoE) is a sample scenario of the DFR teleservice. Event descriptions consist of content describing parts as well as of multimedia parts. The descriptions can be inserted into an archive by an information provider, which is a speci c DFR-Client application. Customers can query descriptions according to their interests and can present them at their workstations. This behavior is implemented in the sample application, which triggers the appropriate calls at the DFR-Client. Events can be classi ed into di erent regions to sim-

plify the user's orientation when retrieving a large amount of events. The hierarchical structure of the DFR information model allows the "1:1" mapping of a speci c region to a DFR-Group. In Figure 4 the archive structure is illustrated. A DFR-Reference in CoE considers regions which cannot be incorporated in only one "higher" region.

4.1 Document Description Standards

In this section we brie y introduce the basic concepts of the document description standard SGML. Then we present a storage manager for arbitrary SGML documents, implemented on top of the OODBMS VODAK, to show how an object oriented design can model SGML documents appropriately.

SGML SGML [1] has received considerable attention as a standard for describing and exchanging documents of arbitrary structure. It provides the means to de ne the type of documents and their document instances. The document type de nition (DTD) describes the logical structure of documents using a grammar based approach. The documents themselves contain tags in addition to their content describing the logical and semantic document properties. With SGML, the identi cation of logical elements of an already existing document can be done in a markup process. The user inspects the contents of the document and inserts a speci c markup depending on the semantics of the document elements to be re ected. The markup process can be automated or assisted by tools if the underlying documents provide enough structure by themselves. The DREAM parser developed at our institute is able to enrich documents towards SGML documents using a DTD grammar that re ects their structure. Example scenarios for DREAM are the conversion of electronic mail into SGML

documents or the structural enhancement of textual database retrieval results (e.g. from literature databases) which normally provide only simply structured data [10]. MarkItUp! is a companion project with the goal to ease the creation of DTDs necessary for DREAM. MarkItUp! uses an incremental approach to build a DTD from scratch. The user has to de ne the structure of sample documents. These document structure hints are successively collected and transformed into a DTD which ts to all the examples [11]. Especially the publication industry tends to enforce and establish SGML compliance as a requirement to their information suppliers. Thus arises the additional need for tools like word processors which are able to support the generation, handling and modi cation of SGML documents in a user friendly and natural way. A SGML markup for the beginning of this subsection could be: SGML SGML [1] has received ... document properties. With SGML, ...done in a markup process... by themselves.

Based on the markup, an application can set up the layout structure of the document. This is normally done via rules, e.g. "Italicize newDef". From another perspective, the markup process contributes to document consistency. We de ne document consistency as follows: Document elements of the same type, i.e. with the same logical function, are treated in the same way by an application, e.g. have the same appearance in the nal document. Naturally this requires that a document type de nition is agreed upon by the persons involved in the publishing process. With currently available word processing software not dealing with logical document elements it might happen that di erent layout decisions for the same logical document elements have been taken by the authors. Thus the resulting documents might look di erent and can confuse the readers. Bigger e orts to coordinate the layouts are necessary to achieve a consistent layout, whereas in SGML the authors can concentrate on document content rather than layout. We complete the introduction to SGML with a short look on a possible document type de nition (DTD) for the above example: < < < < <
subsection lastChange CDATA > subsectiontitle CDATA > body paragraph* > paragraph (CDATA|newDef)* > newDef CDATA >

Each line starting with !ELEMENT de nes a production rule for a document element type (ET). CDATA is a SGML datatype comparable to string in programming languages. The zero and more repetition operator '*' is used to de ne a list of repeated element occurrences, 'j' expresses alternatives. Within SGML the de nition of document elements can be extended with attributes associated with ETs. This is accomplished by means of the keyword !ATTLIST (cf. the second line of the example). So additional information can

be associated with a document. This attribute concept can support powerful querying and retrieval facilities on documents which go far beyond normal content based search capabilities.

Storing SGML Documents in an OODBMS In this section we present the Document Storage Agent (DSTREAT), an application on top of the OODBMS VODAK and we show, how arbitrary SGML documents can be modelled, stored and managed within a database [3][4]. As SGML documents can become very large it is useful to split them into more manageable pieces. This is done by modelling a DTD by a set of classes where each class represents one ET de nition of the DTD. The instances of these classes are document elements of the appropriate ET. This design decision bears advantages in a cooperative environment where several people work on one document especially with respect to locking and transaction management. Concurrent access can easily be supported as necessary locks only a ect small pieces of the documents. To provide arbitrary SGML document types it is necessary to create the corresponding classes at runtime. This is possible because VODAK's metaclass concept treats classes also as objects. This allows for easy modi cations and extensions of existing DTDs at runtime. The fact that methods are part of the database schema is used by D-STREAT to extract the general SGML related semantic from applications. It is incorporated directly into the database schema. As a consequence, the object interfaces already provide SGML-speci c methods for traversing and retrieving of document parts independent of the application scenario. Thus applications dealing with SGML documents need not reimplement these methods again. The application independent semantic are de ned in a metaclass containing the classes for the di erent ETs of SGML DTDs. Thus newly created ET classes automatically receive their behavior from its metaclass. Figure 5 visualizes the mapping from SGML ETs to VODAK classes. The dashed ellipses represent the ET classes which are created by D-STREAT at runtime. The ellipse labeled 'SGML ELEMENT' is their metaclass. The bullets represent instances of ET classes, i.e. the parts of a normal SGML document. The arrows represent the 'instance-of' relationships1 . The DTDs themselves are modelled by a SGML MetaDTD which is also represented via VODAK classes and metaclasses. Thus, DTDs are treated the same way as normal SGML documents inside the database and can be accessed, queried and modi ed at runtime. Finally, the external interface to D-STREAT is realized by a SGML parser which creates the necessary classes from the DTDs and instances of the classes from the documents.

5 Database Integration Future application scenarios need to access a lot of information. It is not reasonable to assume that the necessary amount of information can be stored in one local database. The information sources are distributed all over the world and interoperability between them is a necessary requirement to t the needs of new applications. Databases can 1 This view is simpli ed. In reality exist more SGML speci c metaclasses which are left out for convenience.

< !ELEMENT < !ATTLIST < !ELEMENT < !ELEMENT < !ELEMENT < !ELEMENT

subsection subsection subsectiontitle body paragraph newDef

(subsectiontitle, body) > lastChange CDATA > CDATA > paragraph* > (CDATA|newWord)* > CDATA >

Mapping

SGML_ELEMENT SUBSECTION

NEWDEF BODY PARAGRAPH

SUBSECTIONTITLE

Figure 5: Representing DTD's by VODAK classes ful ll this requirement if they are able to model and manipulate local and external data simultaneously in a uniform way. The mapping of external formats to a uni ed view is known as schema integration. One of the major problems of schema integration has to deal with the design autonomy of the external databases. They use di erent data models (heterogeneity), model di erent aspects of the real world (domain perspective), and even the same situation may be represented in many di erent ways (semantic relativism)[6][26]. In this chapter we describe rst the necessary framework for database integration, then we introduce a schema integration methodology based on augmentation rules [9]. Finally we apply this methodology to an integration example showing how a graphical tool can support the principles of the methodology.

5.1 The Integration Process

In this section we describe the architectual framework for database integration, see Figure 6, and identify the di erent steps of the integration process. The rst step in the integration process is the Transformation of the external database schemas into the data model used for integration to overcome the above mentioned problem of heterogeneous data models. Therefore, the data model choosen for integration must provide at the one hand means for an adequate modelling of the structural and semantic concepts of the external data models and on the other hand means for the operational mapping of the external schema information onto the transformed schema. Both demands can be captured by a powerful, object oriented data model. Classes with properties and methods are used to de ne the mapping for the external schemas' structure and semantic. They also implement the manipulation operations used to handle the information stored in the external databases. A well de ned interface for the objects can hide the external operations themselves from the user and is able to prevent therefore abuse of the data. Thus transparency, encapsulation and integrity can be achieved. Even complicated operations on the external databases can be made to look like a simple property access. The mapping from an external data model to the object oriented one can be partially automated by translators which generate

the necessary object interfaces, their implementations and classes to reduce the burdensome work for the database integrator. Although this is an interesting and necessary eld of research, we focus in this section on the generation of integrated schemas from already transformed schemas. The next step, Redundancy Removal, is aimed at reducing redundancy within each of the transformed schemas. It can be seen as the integration of constituents within a single schema, with the result that similar aspects and relationships are presented only once, and useful abstractions of constituents with overlapping aspects are provided - usually by means of generalization. After this step, each transformed schema is now represented almost redundancy free in itself. Although these schemas allow for a uni ed data manipulation, they are still disjoint and there might be a large amount of overlapping data and semantics modelled twice { introducing redundancy and con icts. Additionally, these schemas are not connected, and distributed but related information has to be collected explicitly during retrievals. Therefore the goal of schema integration is to create one (partial) overall schema that combines all information needed in an application from the transformed and non-redundant schemas { again with as little redundancy as possible. These disjoint schemas are then matched with a normative conceptual network in a preintegration phase (cf controlled vocabulary in information retrieval). The purpose of this Semantic Enrichment is to present more semantics explicitly. Like redundancy removal, semantic enrichment requires a deep understanding of the schema and its constituents. Thus the database administrators responsible for each of these schemas must be involved. An assisting knowledge base representing a conceptual network for the domain of the application may help the administrators to explicate the implicit aspects of a schema, i.e. to clarify ambiguous names of constituents by choosing better names proposed by and retrieved from the knowledge base. If multiple schemas are enriched on the basis of the same knowledge base, only those parts of the schemas, which have not yet been anticipated in the knowledge base { the new ideas { need user interaction for further integration. The knowledge base itself may also be expanded due to novel concepts that appear in real schemas and have not been anticipated by the domain description in the knowledge base. Nevertheless, given the current state of the art in large knowledge base design, they provide only very generic hierarchies of concepts which are only loosely interconnected, i.e. the automatic disambiguation power by semantic enrichment is still very limited. In addition, it can not be assumed that a knowledge base re ects the particular world model of an individual user domain, and therefore the identi cation of all correspondences of heterogeneous subschemas via a common representation in the knowledge base can not be taken for granted. Thus Schema Integration is required to actually match the partially semantically enriched subschemas.

5.2 Uni cation by Augmentation Rules Based Integration Methodology

While complete integration is neither realistic nor required, a methodology is still necessary to dynamically integrate those portions of external databases which are needed to create a suciently broad basis for the application domain to lower the burden for the application designer of understanding in detail structure and semantic of the external schemas.

Individualized Query (Update) Application 1 Translation & Decomposition

Individualized Application m Mapping

Integrated Schema Integration Semantic Schema 1

Semantic Schema n Semantic Enrichment

NonRedundant Schema 1

Semantic Knowledge

Non Redundant Schema n

Redundancy Removal Schema n

Schema 1 Data Model Transformation External Schema 1

External Schema n

Instance Mapping & Merging

Figure 6: Framework for Database Interoperability Two major categories of schema integration methodologies have been proposed until now. On the one hand exist strict integration methods which are using upward inheritance, correspondence assertions and rules [6][26] to achieve integration. They are sound, but at the same time intolerant and restrictive with respect to the real semantic modelled in the schemas which shall be integrated. On the other hand heuristic techniques using best paths, spanning trees and structural similarity [12][13][15], can handle some of the arising semantic problems more pragmatically, but lack in soundness. The declarative integration methodology developed at our institute [9] extends strict uni cation techniques in such a way that structural heterogeneity, caused by modelling the same real world aspects by di erent means of the data model (semantic relativism), can be dealt with to a large degree. Additionally, the methodology puts speci c emphasis on the treatment of di erences in structural granularity introduced by the di erent levels of detail with which schemas may represent the same real world aspect (perspective). Our uni cation approach is based on augmentation rules applied to corresponding parts of the schemas (subschemas) participating in the integration process. These corresponding parts are expressed by path correspondences, where a path is de ned as a connected subgraph without circles from one vertex to another vertex in a schema graph (in the currently used data model, properties and classes are vertices, and references from a property to it's domain class and subclass relations are edges of a schema graph). The results of this augmentation rule based uni cation process are schema constituents in the integrated schema which retain as much of the original subschema information as possible, even if the information is only modelled by

some of the schemas to be integrated. Integration methodologies based on abstraction use a contrary strategy. They are only able to integrate those schema parts which have a common abstraction. Real world aspects modeled only by one of the schemas to be integrated can not be dealt with, because they do not have a corresponding counterpart in the other schemas. Therefore, these methodologies usually are not able to create an integrated schema preserving all the aspects of the schemas participating in the integration process. Users arm correspondences between parts of heterogeneous schemas regardless of structural di erences between them. They are assisted in nding additional correspondences, and are guided in turning these correspondences into operational mappings between the integrated schema and the corresponding parts. The declarative de nition of correspondences may lead to ambiguities or con icts during the integration process which are not assumed to be solved automatically, but in turn need user interaction and knowledge to resolve them properly. The presented methodology can assist top down as well as bottom up semantic integration. Bottom up integration starts with the local schemas to be integrated and successively creates a partial integrated schema which suits some application domains. Top down integration can take advantage from the existing requirements of application domains which must be ful lled by the integrated schema, i.e. the application already de nes its integrated schema, and the methodology provides the means to nd the appropriate mappings to the underlying external schemas. In the following, we present an architecture for a graphical tool to support our methodology, and discuss the most important aspects of our methodology via an example.

Retrieval of Vertices

Vertex Correspondences Knowledge Base

Embedding of Classes

Applying Unification Rules

Integrated Schema

Enriched paths

First schema:

inChargeOf

Person Integration Proposal Consistent correspondences

Correspon– Consistency Interaction/ dences Check Presentation Conflicts

street

city

Company

Thing value

Salesman

products

contains

employed

owner

salary

taxrate

Augmentation proposal PERSON

Possessions Correspondence candidates

Address

Second schema:

ADDRESS Best Paths

Schema 1

PERSON

Schema 2

street Address

Figure 7: The Integrators Workbench Architecture

5.3 The Integrators Workbench

The Integrators Workbench is a graphical tool, intended to assist the user in the integration process and to provide a comfortable interface for the complex task of schema integration. Figure 7 shows the principle architecture of the Integrators Workbench. The Interaction/Presentation module provides the means to graphically display the integrated schema and the schemas to be integrated. The user can declare path correspondences between subschemas and is guided during the integration process. The consistency check module takes the given correspondence assumptions and checks them for con icts or ambiguities. If there are con icts the system switches back to the presentation module where the con icts are presented to the user and proposals are given how to overcome the con ict situation. The same happens with ambiguities where the user has to choose how to proceed to resolve the ambiguity. If all correspondences are de ned correctly, they are given to the uni cation module which applies uni cation rules to transform the correspondences to an integration proposal. The modules on the left side of Figure 7 provide the means for semantic enrichment, identi cation of possible corresponding vertices and proposals for correspondence candidates in both schemas. They thus help to reduce the intellectual e ort needed to identify path correspondences, that arises from the complexity inherent in large schemas and the many di erent ways to model the same real world aspects. The Knowledge Base models the (real) world by a semantic network of concept names interrelated by di erent binary semantic relationships. Each relationship is additionally weighted with respect to the strength of hold between the two concepts it connects. Given such a semantic network it is possible to support the identi cation of corresponding concepts in the schemas. In addition, interrelated concepts in the schema can be used in the knowledge to overcome ambiguities (e.g. An editor can be some kind of software or a person, but if it has a property 'price' it is almost certain that it actually denotes software and not a person. If it has a property 'address' it is almost certain that it re ects a person which then again can correspond somehow to the concept author modelled in another schema). The re-

Client

Salary

ADDRESS Street

Product

Merchant

City Possesses

GOODS Value

city

SALE

COMPANY

Taxrate

Figure 8: Two schemas and a simple augmentation proposal trieved correspondence proposals can be propagated to the integrator person who then decides either to accept or to refuse them. The strength of the relationships modelled in the knowledge base can be taken into account by a path analysis algorithm to provide some kind of probability for the proposed correspondences and to propose a best path. Again the user has to decide if the result resembles his expectations, if it has to be re ned, or it has to be rejected. The embedding of new classes results in path enrichment and can be used to de ne some kind of a normalized representation of the aspects modelled in the di erent schemas. This feature makes it easier to identify the semantic similarities between new (related) aspects also modelled di erently in the schemas.

Integration of two example schemas

In the following we discuss the main parts of our methodology using a scenario of two example schemas to be integrated. A slightly simpli ed representation of the two schemas in the Integrators Workbench is shown in Figure 8. Classes are represented by labeled rectangles with bold lines, properties of the classes by ner lined labeled rectangles. The edges between properties and classes are undirected, edges with an arrow represent a reference from the property to its domain class. To illustrate the augmentation principle of the methodology we de ne the following two correspondences (cf grayed parts of Figure 8). Person-street corresponds-to (,)

!ADDRESS-Street !ADDRESS-City

Person-Address Person-city Person-Address

,

The result of this partial integration step leads to a par-

inChargeOf

PERSON

Client

Salesman

1

SALE

salary

Product

Figure 9: Augmentation along di erent paths tial integrated schema which re ects the ner granularity modelled in the second schema. It introduces the class ADDRESS to model a person's address despite the fact that the rst schema does not have a notion of 'address' objects. A methodology based on abstraction rules will not be able to preserve all schema information and the modelling granularity of the investigated schemas for this particular case. Its integration proposal most probably will re ect only the design used in the rst schema. Thus, the concept of an address as an object with its own identity is no longer available and applications using the integrated schema can not pro t from the ner granularity used in the second schema. The proposed augmentation has also to be re ected at the instance level. In this case, the mapping from person objects of the rst schema (where address objects are not modelled) can be achieved by introducing 'virtual' address objects in the integrated schema for object instances coming from the rst schema. The 'virtual' object's lifetime is limited to that of the associated person object and the deletion of a person object also implies the deletion of the virtual address object. We extend this example by adding the following three correspondences:

,

Person inChargeOf-Salesman-salary PERSON-Salary Person-products PERSON Client-SALE-Product Person inChargeOf-Salesman-employed Company PERSON Client-SALE-Merchant-Company

,

!

,

In this case our methodology can not nd a proper structural augmentation for the given path correspondences. This is due to the fact that the rst and second correspondence lead to the intermediate augmentation shown in Figure 9, but the third correspondence requires that the augmentation rule must follow Person inChargeOf-Salesman-salary for the rst schema and PERSON Client-SALE for the second schema. This contradicts to the condition that a path correspondence must be representable by exactly one path in the integrated schema. This inconsistency can only be resolved by involving the user in the integration process. Before the process is able to continue he/she has to decide which of the above three correspondences should not be considered any longer. In our example it seems to be very unlikely that the property Salary of PERSON in the second schema models the same real world aspect as Person inChargeOf-Salesman-salary, so that the rst correspondence assumption can be removed. Now the remaining two path correspondences have to be merged. In this example, three possible combinations for an augmented subschema exist for the two paths Person : : : Company in the rst schema and PERSON : : : COMPANY in the second schema (see Figure 10). Again the user has to decide which of the three possible cases the integration process should use. Merchant can correspond either to employed (1) or to Salesman (2) or to none of both (3). Choosing the second case leads to the nal par-

PERSON

2

PERSON

PERSON

3

Client

Client

Client

SALE

SALE

SALE

inChargeOf

inChargeOf

inChargeOf

Salesman

Salesman~Merchant

Salesman

employed~Merchant

employed

employed

COMPANY

COMPANY

Merchant

COMPANY

Figure 10: Possible augmentation alternatives PERSON

Client

Address ADDRESS Street

City

ÍÍÍÍÍÍ ÍÍÍÍÍÍ ÍÍÍÍÍÍ ÍÍÍÍÍÍ ÍÍÍÍÍ ÍÍÍÍÍ ÍÍÍÍÍ ÍÍÍÍÍ ÍÍÍÍÍ SALE

Product

inChargeOf

Salesman~Merchant

employed

COMPANY

Figure 11: The nal partial integrated schema tial integrated schema shown in Figure 11. The gray parts show the augmentations with respect to the rst schema and the hatched parts are augmentations with respect to the second schema.

6 Conclusions and Further Research Directions In the previous chapters we de ne the requirements to support successfully new multimedia and hypermedia applications accessing and manipulating distributed information sources. We show that advanced database technologies which provide on the one hand basic support for multimedia data and on the other hand powerful object-oriented data modelling capabilities are able to ful l these requirements. We explain that the support for multimedia data has to become part of future database architectures and describe some multimedia database aspects of an already existing implementation as part of the OODBMS VODAK. We motivate the need for standardization in both document archiving and document description, presenting an implementation of DFR as an example for document archiving and an architecture to support SGML documents on top of VODAK. Finally we suggest a framework for database interoperability and discuss an advanced schema integration methodology based on augmentation rules. Within the multimedia area the aspects of time dependency, synchronization, support of user interactions and fast, parallel, cooperative access to large amounts of e.g. video data remain important research topics. However, databases are not able to propose good solutions to all of the arising

problems if there will not be improvements in other research areas like operation systems or network technology as well. They have to provide the basic services for multimedia data, so that databases can rely on these services without reinventing the wheel all the time. Interoperable database research can be split into two directions: The distributed database systems have to provide new concepts for uniformly sharing and accessing data worldwide across many system boundaries. The other direction has to provide better integration of already existing databases (legacy systems). Especially standards like the Common Object Request Broker Architecture (CORBA) with its data model have to be investigated for their suitability or extendibility towards the needs of the database community. Therefore, our institute IPSI participates in a promising ESPRIT project, IRO-DB (Interchangeable Relational and Object oriented DataBases). IRO-DB's major goal is to provide interoperability between relational database technology and object oriented databases. This goal is going to be achieved on the one hand by using and extending the object oriented data model of CORBA's database management group (ODMG) towards a widely accepted exchange standard for databases and on the other hand by providing the necessary means and tools to map and integrate existing legacy and future database schemas.

7 Acknowledgements This article re ects many of the current projects at IPSI. We thank hereby the people who helped us in compiling this paper, especially Klemens Bohm and Karl Aberer (SGML and D-STREAT), Ralph Busse and Peter Fankhauser (Integration), Klaus Matzel (Publication Process example) and Heiko Thimm and Thomas Rakow (Multimedia Databases).

References [1] ISO-IS8879: Information Processing. In - Text and Oce Systems -Standardized Generalized Markup Language (SGML). Ref. No. ISO 8879-1986(E). International Organization of Standardization, 1986. [2] ISO/IEC 10166: Information technology. In - Text and oce systems - Document Filing and Retrieval (DFR) - Part 1 and Part 2, 1991. First edition 12/15/91. [3] K. Aberer, K. Bohm, and C. Huser. D-STREAT. In Arbeitspapiere der GMD 811, 1993. [4] K. Aberer, K. Bohm, and C. Huser. The Prospects of Publishing Using Advanced Database Concepts. In preparation for conference for electronic publishing, 1994. [5] K. Aberer and W. Klas. The Impact of Multimedia Data on Database Mangement Systems. In Proc. of the 1st IEEE Multimedia Conference 1994, Boston, 1994. [6] C. Batini, M. Lenzerini, and S. V. Navathe. A Comparative Analysis of Methodologies for Database Schema Integration. In ACM Computing Surveys, volume Vol. 18 No. 4, pages pp.323{364, 1986. [7] A. Billiris. The Performance of Three Database Storage Structures for Managing Large Objects. In Proc. of the ACM SIGMOD Conf., p. 276-285, 1992.

[8] L. Delgrossi. Media Scaling for Audiovisual Communication for the Heidelberg Transport System. In Proc. of the ACM Multimedia Conference., November 1993. [9] P. Fankhauser. Explorative Uni cation for Semantic Database Interoperability. In Dissertation Proposal. GMD-IPSI, May 1993. [10] P. Fankhauser and T. Gottke. DREAM2.0 User Manual. In Arbeitspapiere der GMD 660, July 1992. [11] P. Fankhauser and X. Yi. MarkItUp! - An Incremental Approach to Document Structure Recognition. In GMD-IPSI Internal Draft, 1994. [12] S. Hayne and S. Ram. Multi-User View Integration System (MUVIS): An Expert System for View Integration. In Proceedings of the 6th International Conference on Data Engineering, February 1990. [13] D. Lin and D. McGregor. A Distributed Approximation Algorithm for the Steiner Problem in Graphs and its Application in Natural Language Understanding. In Proceedings of the 13th Conference on Graphtheoretic Concepts in Computer Science (WG87), 1987. [14] T. D. C. Little and A. Ghafoor. Network Considerations for Distributed Multimedia Object Composition and Communication. In IEEE Network, Vol. 4, No. 6, pp. 32-49, November 1990. [15] A. Mehta, J. Geller, Y. Perl, and P. Fankhauser. Algorithms for Access Relevance to Support Path-Method Generation in OODBs. In RIDE-IMS, Vienna, April 1993. [16] W. Moehr and L. Rostek. An Object-Oriented Terminoloy Editor. In Terminology and Knowledge Engineering, Proceedings of the TKE' 93, Cologne, August 1993. [17] F. Moser, A. Kraiss, and W. Klas. L/MRP: A Bu er Management Strategy for Highly Interactive Continuous Data Flows in a Multimedia DBS. to appear in Proc. of the 21st Conference on Very large Databases 1995 (VLDB'95), Zurich, September 1995. [18] E. Neuhold and W. Putz. is-News: a Multimedia Information System. In Data Engineering Bulletin, volume Vol. 14 No.3, September 1991. [19] E. Neuhold and V. Turau. Database Research at IPSI. In SIGMOD RECORD, volume Vol. 21 No.3, pages pp. 133{138, March 1992. [20] S. Newcomb, N. Kipp, and V. Newcomb. The "HyTime" Hypermedia/Time-based Document Structuring Language. In Communications of the ACM, Vol.34, No. 11, November 1991. [21] C. Nicolaou. An Architecture for Real-Time Multimedia Communication Systems. In IEEE J. Select. Areas Commun. 8, No.3, pp. 391-400, 1990. [22] R. Price. MHEG: An Introduction to the Future International Standard for Hypermedia Object Interchange. In Proceedings of the ACM Conference on Multimedia 1993, pages pp. 121{128. ACM Press, 1993.

[23] T. Rakow, F. Moser, P. Dettling, and B. Paul. Development of a Multimedia Archiving Teleservices using the DFR Standard. In Proc. of the 2nd International Workshop on Advanced Teleservices and High Communication Architectures, Heidelberg, Springer, September 1994. [24] P. V. Rangan and H. M. Vin. Designing File Systems for Digital Video and Audio. In Proc. of the 13th Symposium on Operating Systems Principles, Operating Systems Review, Vol. 25, No. 5, pp. 81-94, October 1991. [25] J. Rueckert and B. Paul. Integrating Multimedia into the Distributed Oce Application Environment. In Datenbanksysteme in Buero, Technik und Wissenschaft, GI-Fachtagung, Braunschweig, SpringerVerlag, 1993. [26] S. Spaccapietra, C. Parent, and Y. Dupont. View integration: a step forward in solving structural con icts. In IEEE Transactions on Knowledge and Data Engineering. LBD, DI, EPF Lausanne 90, October 1992. [27] N. Streitz. SEPIA: A Cooperative Hypermedia Authoring Environment. In Proceedings of the ACM Conference on Hypertext (ECHT'92), Milano, Italy, pp.11-22, 1992. [28] H. Thimm and W. Klas. Playout Management - An Integrated Service of a Multimedia Database Management System. to appear in First International Workshop on Multi-Media Database Management Systems, Blue Mountain Lake, NY, IEEE Computer Society Press, August 1995.