ToMaTe: A Toolbox for Managing Telemeetings

Transcription

1 ToMaTe: A Toolbox for Managing Telemeetings Constantin Arapis Abstract Conducting meetings is one of the most important and frequent activities in a business environment. This paper presents a prototype software environment for managing the complete life-time of telemeetings/teleconferences: modeling telemeetings, conducting telemeetings, archiving telemeetings in a telemeeting database, annotating telemeetings and querying the telemeeting database. 1 Introduction Conducting meetings is one of the most important and frequent activities in a business environment. Meeting participants may undertake long trips to attend a meeting. The reduction of travelling time and costs spent by meeting participants is the raison d etre of telemeetings. A telemeeting is a meeting where participants are geographically dispersed and use a computer and networking infrastructure for communicating. Recent developments in networking and multimedia technologies are promising for the wide dissemination and use of telemeeting/teleconferencing technology and services [3]. Archiving meetings is often a necessity. Minutes of meetings, conducted at any level of an organisation, are documents that are consulted over long periods. Depending on the working context archives of minutes of meetings may serve various purposes. They allow employees in an enterprise to trace back to decisions made in the past and retrieve the context in which decisions were made and the rationale. In a research context, members of a research group may access presentations and scientific discussions made during their regularly conducted group meetings. We identify three consecutive periods that cover a telemeeting: the pre-meeting period, the meeting session period and the post-meeting period. During the pre-meeting period the meeting administrator (MA) defines a meeting agenda. The MA is responsible for the meeting organisation in its entirety. During the meeting session period participants use a teleconferencing system for communicating. In order to automate the archiving process of telemeetings the teleconferencing system should be able to store telemeeting sessions in a telemeeting database (TDB). The post-meeting period corresponds to the period when users query the TDB. Depending on the type of meeting and the level of detail in which meeting activities should be stored, the recording process of telemeetings can be more complex than the simple text-editing of minutes. For example, in the case of a telelecture [1], which we consider to be a particular instance of a telemeeting session, simply storing minutes of a telelecture in a database is of little help to learners, who would prefer to listen to the narration performed by

2 58 ToMaTe: A Toolbox for Managing Telemeetings the lecturer. Thus, recording telemeeting activities often requires the use of a variety of media types including audio and video streams, still images, presentation documents, electronic ballots and text in various formats. A challenging issue for telemeeting archives is the development of query mechanisms. A typical scenario for querying a telemeeting archive is the retrieval of parts of telemeetings satisfying a set of selection criteria. A part of a telemeeting is identified by means of a time interval (TI) which has a start and end time point. A TI can be displayed: "play" the media streams and reproduce the various activities that occurred during the TI. For example, a query to a research group telemeeting archive could be "retrieve those parts of meetings conducted during the first half of the year 1997 where a presentation of a paper on data mining was made". The system should be able to identify and present to the user the parts of meetings satisfying the above query. Answering the query with entire meetings is not fully satisfactory since the user would have to browse the entire meeting to locate the part of interest. Multimedia DBMs [5] [6] implement basic services required for storing and retrieving multimedia data. Multimedia DBMs have been designed to be general enough for being used for a variety of multimedia data intensive applications. ervices that are specific to a particular type of application, e.g. management of telemeetings, are not included in the core DBM. Therefore multimedia DBMs cannot be considered as such a telemeeting management system. However, multimedia DBMs can be used as lower level components on top of which a telemeeting management system is developed. Content based information retrieval (IR) systems propose solutions where the desired information is extracted directly from media data (audio and/or video) [7]. IR techniques are certainly useful for retrieving parts of interest of telemeetings stored in the TDB. However, we cannot exclusively rely on content-based IR systems. We consider content based IR techniques as an essential complement to a set of indexing techniques which all together provide users convenient access to telemeeting archives. There are several problems inherent to IR for which it is difficult to provide satisfactory solutions. For example, during a research group meeting a paper is presented without mentioning the name of its author A. A query searching the TDB for presentations on papers authored by A, using audio IR techniques alone, will fail to identify the TI during which the paper was presented. The interested reader is referred to [8] where strong and weak points of using a content-based system for segmenting the audio stream of meetings are reported. A system specifically developed for recording, annotating and querying meetings is described in [4]. Their approach is summarised as follows: record the meeting activity in files and enable users to add annotations to the recorded stream. The recorded activity can be replayed much like a tape in a video tape recorder. Their approach requires substantial media editing effort, the annotations have a simple text structure and access to the stored meetings and their contents is performed sequentially. In addition no particular facilities are reported for querying large collections of telemeetings.

3 C. Arapis 59 ToMaTe [2] (Toolbox for Managing Telemeetings) is a prototype software environment implemented at the University of Geneva. ToMaTe comprises a set of tools for managing the complete life-time of telemeetings. The originality of ToMaTe lies in the following points: ToMaTe is extensible to variety of telemeeting types including board of directors meetings, research group meetings and telelectures. A telemeeting type is modelled with a meeting agenda template. An agenda template is a generic definition of a set of telemeeting sessions. The definition includes both the semantic description and the definition of the temporal structure of a set of telemeetings. For example, the MA may define a researchgroupmeeting agenda template describing the common structure of this type of meeting. An agenda template can be used for communicating to meeting participants a description of the telemeeting session. Telemeeting sessions of the same type are associated with meeting agenda instances created from the corresponding agenda template. An agenda instance contains data specific to a telemeeting session, in particular, data describing the temporal decomposition of a telemeeting session in terms of TIs and associations between TIs and annotations. For example, TIs identified during a particular research group telemeeting session are contained in an agenda instance created from the researchgroupmeeting template. ToMaTe provides facilities for annotating the raw telemeeting data stored in the TDB. The annotation process is simple without requiring audio/video-editing skills. It should be noted that this is one of the strongest point in favour of ToMaTe. Audio/video editing is a time consuming process. In most cases users are not willing to spend time neither for learning complex multimedia editing tools nor for editing the media streams after a telemeeting session. Annotation data are stored in relational tables. The relational schema used for storing annotation data is user defined. In addition to browsing, the system provides more elaborate mechanisms for querying the TDB. ToMaTe uses annotation data for indexing parts of the audio stream recorded during a telemeeting session. More precisely, results of queries against annotation data are associated with TIs of telemeeting sessions. ToMaTe provides the user with tools for replaying the activities delimited by the start and end time points associated with the TI. This paper is structured as follows. In the second section we describe the teleconference module of ToMaTe. In the third section we describe ToMaTe s concepts and tools for modelling telemeetings. In the fourth section we describe the query mechanisms of the TDB. In the fifth section we briefly describe implementation issues. In the last section we present our conclusions. 2 The teleconference module The teleconference module is implemented according to a client/reflector architecture. The client part provides an interface to the user. Each client is connected to a reflector. The

4 60 ToMaTe: A Toolbox for Managing Telemeetings reflector acts as an intermediary between all clients. The main role of the reflector is to repeatedly accept messages from a client. The reflector then either forwards the received message to all clients or does some processing and broadcasts the processed message to all clients. The message received from the reflector might not contain all necessary information that the receiving client needs for further processing. In that case the message sent to the client is a sort of reference for where to find the target data. Figure 1 illustrates ToMaTe s teleconference module architecture. Rectangles denote hosts, ovals denote software processes, cylinders represent data repository units and unidirectional or bi-directional arrows represent data transfers. MA Agenda Definition Module TDB erver TDB User session module Participant reflector User session module http server Participant User session module webcam server Figure 1 Teleconference module architecture The services provided by the teleconference module are the following: The Telepresentation ervice allows users to make a slide-like presentation during the telemeeting sessions. This service is based on WWW concepts and techniques. More precisely, a user may get the floor and become a presenter. The presenter may navigate over the WWW and the pages visited by the presenter are broadcast to all other participants. The Audio ervice allows users to have full duplex audio communication with all other participants.

5 C. Arapis 61 The Image Broadcast service is similar to the service offered by webcam client/server programs. More precisely, it allows users to broadcast to all other participants images refreshed at low rates (few images per minute). The Electronic Mail allows users to broadcast messages to all the participants of a session. The Text Chat allows users to broadcast a line of text to all the participants of a session. Figure 2 shows the user interface of the telepresentation and image broadcast services operated during a telelecture. A more detailed description of ToMaTe s teleconference module can be found at [2]. Figure 2 User interfaces of telepresentation and image broadcast services In addition to the services we have already described the reflector records the telemeeting activity in the TDB. Currently the TDB is implemented using a relational DBM. Our choice for a relational DBM has been driven by the fact that relational DBMs are ubiquitous and by the fact that the QL query language for querying relational DBMs is now a standard. The reflector is the best candidate for implementing the recording process since the reflector is aware of all events occurring during a telemeeting session. Recorded data fall into two categories: stream data and discrete data. The TDB has been designed to be extensible to a variety of stream data types and formats, for example audio, video and animation. However, due to storage limitations, currently the only type of recorded stream data is the mixing of the audio streams of all the participants. tream (audio) data are stored in a file and the URL of the (audio) file is stored

6 62 ToMaTe: A Toolbox for Managing Telemeetings in the TDB. Our decision for not storing stream data in the TDB was driven by the fact that access and delivery of stream data may be subject to various requirements, such as compression standards and transfer protocols not supported by the DBM implementing the TDB. Our approach for storing and accessing stream data requires the availability of streaming servers and client programs for each type of stream data. For audio data we provide such a pair of server and client programs. Recorded discrete data includes user attendance, (i.e. the time when the user joins and leaves the telemeeting session is stored for each user), changes of presenter, URLs of WEB pages that have been broadcast during presentations, messages exchanged using the service, and lines of text exchanged using the text chat service. Discrete data are associated with a timestamp indicating the time the data was processed by the reflector. Images broadcast using the "Image Broadcast" service are not stored in the TDB due to storage capacity limitations. 3 Modeling Telemeetings ToMaTe s Agenda Definition and Manipulation Module (ADMM) allows a user to define meeting agenda templates and create agenda instances from agenda templates. Both agenda instances and agenda templates are stored in the TDB. The TDB s schema used for storing agenda templates, agenda instances, telemeeting session data and metadata consists of a few relational tables. We name these tables system tables (T). Figure 3 shows the relational schemas of Ts. meetingagendas(meetingagenda_id, agenda_name, description, template) intervals(interval_id, meetingagenda_id, parent_interval_id, interval_type, annotation_table_name, child_number, ordered, mandatory, max_iterations, min_iterations, expected_start_date, expected_start_time, expected_stop_date, expected_stop_time, expected_duration, valid_start_date, valid_start_time, valid_stop_date, valid_stop_time, valid_duration, state) discrete_data(ddata_id, meetingagenda_id, ddata_type, ddata, ddata_date, ddata_time) stream_data(stream_id, meetingagenda_id, stream_type, stream_url) annotation_tables(table_name) Figure 3 ystem Tables The meetingagendas table stores information relative to meetings. Each meeting is identified with a unique meetingagenda_id attribute value. The intervals table

7 C. Arapis 63 contains the TIs into which meeting agenda templates and meeting agenda instances are decomposed. The notion of TI is described in more detail in the remainder of this section. The discrete_data table holds information relative to discrete data recorded during a telemeeting session. The ddata_type attribute allows us to distinguish between the various types of discrete data. The ddata_date and ddate_time hold the date and time when the data were produced. The ddata attribute maintains the data itself. For example, when the discrete data type is the broadcast of a WEB page, its URL is stored in the ddata attribute. The streams table maintains the association between files containing streaming data in general and telemeeting sessions. The stream_url attribute contains the URL of the file containing the data and the stream_type attribute the type of the stream. Data stored in Ts are related to data stored in annotation tables (AT). ATs are user defined. The table annotation_tables contains the names of ATs. ATs are intended both to provide the semantic description of various types of telemeetings and for storing annotation data relevant to telemeetings. Relationships between T and AT are based on data values stored in attributes meetingagenda_id, interval_id, ddata_id and stream_id. The definition of attributes meetingagenda_id, interval_id, ddata_id and stream_id in ATs should be consistent with the definitions of these attributes in Ts. The ability to associate user defined ATs with agenda templates makes ToMaTe extensible to new types of meetings and allows us to enrich telemeeting sessions with semantics relevant to a particular meeting type. Note that the annotation_tables table need not be stored. It can be computed by projection on the attribute annotation_table_name on the intervals table. 3.1 Agenda Templates An agenda template describes the temporal structure of telemeetings in terms of TIs. The name of the AT further describing the TI is stored in the annotation_table_name attribute of the intervals table. A TI is associated with the following expected values: expected start date and time, expected end date and time, and expected duration. Attributes prefixed with "expected_" in the intervals table store expected values. The definition of expected values is optional. In most cases the MA specifies only the expected duration of the TI. Expected values serve as an indication when the TI is expected to start and/or what would be its duration during the agenda instantiation. During the telemeeting session, expected values are compared against their peer valid values: valid start date and time, valid end date and time and valid duration computed from the previous valid values. Attributes prefixed with "valid_" in the intervals table store valid values. Valid values are recorded during the agenda instantiation and denote the time and date values when a TI started and ended during the telemeeting session. Expected values are not constraints. When an expected value does not match the corresponding valid value the system simply notifies the MA and continues its execution. Expected values serve two purposes. First, to communicate the expected timing

8 64 ToMaTe: A Toolbox for Managing Telemeetings schedule of the telemeeting to the meeting participants by giving out the meeting agenda template prior to the telemeeting session. econd, to establish statistics about several telemeeting sessions of the same type, for example, identify the parts of meetings which are often significantly extended or shortened in time. We classify TIs into four types: basic TI, sequence TI, alternative TI and iteration TI. The interval_type attribute in the intervals table contains this information. A basic TI cannot be further decomposed. A sequence TI represents a sequence of TIs. An alternative TI interval represents a choice of TIs. An iteration TI represents the iteration of a set of TIs. TIs in an agenda template are structured in a tree like structure. Thus, an agenda template is identified with a tree T of TIs. The parent_interval_id attribute in the intervals table is used for storing the parent node of a node. Figure 4 shows the temporal structure of the research group meeting type. Rectangles represent nodes of the tree and are labeled using a hierarchical notation prefixed with the letter N. Light gray rectangles represent sequence nodes, dark gray rectangles represent alternative nodes, black rectangles represent iteration nodes and white rectangles represent basic nodes. Arrows connect parent and children nodes. Parents are placed at the tails of arrows and children are placed at the heads of arrows. Names of ATs associated with TIs follow the "AT:" string. Figure 5 shows the user interface provided by the ADMM for defining meeting agenda templates. TIs are classified as mandatory or non-mandatory. The boolean attribute mandatory in the intervals table contains this information. In Figure 4 mandatory nodes contain the label MANDATORY. A mandatory TI will eventually be started. A non-mandatory node may never be started, meaning that the corresponding TI may never take place. Note that when a TI is started and has children then at least one of its children should also be started. A sequence TI models the fact that its children intervals should take place in sequence. A sequence TI may be ordered or unordered. The boolean attribute ordered in the intervals table contains this information. In Figure 4 ordered nodes contain the label ORDERED. For an ordered sequence TI its children should take place in the order in which they have been defined (the attribute child_number stores the definition order of TIs having the same parent TI). For an unordered sequence, the order in which children TIs start is determined during the telemeeting session. A sequence TI and its children TIs should satisfy the following constraint: the total duration of children TIs should be the same as the parent node duration. In addition, the time periods of children should be contiguous. In Figure 4 node is an example of a mandatory unordered sequence TI associated with AT reports. Node has three children associated with the following ATs: coursereport, PhDprogressReport and ongoingprojectreport. Even though all children are non mandatory at least one of them must be started since their parent is mandatory. Figure 6 illustrates the schemes ATs associated witn children nodes of node. PhDprogressReport associates the name of a PhD student with her/his progress level. coursereport associates a course with an evaluation report produced on the date date. ongoingprojectreport associates a project identified with a

9 C. Arapis 65 project_id and a (summary of a) report on that project. The attribute interval_id establishes the relationship between tuples of ATs and tuples of the intervals table. ORDERED MANDATORY AT: researchgroupmeeting MANDATORY AT: reports.1 AT: coursereport.2 AT: PhDproressReport.3 AT:onGoingProjectReport.2 AT: scientificpresentation.2.1 AT: paperpresentation.2.3 AT: projectproposal AT: researchideas AT: miscpart.3.1 AT: miscellaneous Figure 4 Research group meeting agenda

10 66 ToMaTe: A Toolbox for Managing Telemeetings Figure 5 Agenda definition and manipulation module interface

11 C. Arapis 67 PhDprogressReport(interval_id, name, progress_level) coursereport(interval_id, course_name, date, evaluation) ongoingprojectreport(interval_id, project_id, report) Figure 6 Examples of ATs An alternative TI is used for modelling the fact that one of the children TIs will be started during the telemeeting session. However, before the telemeeting session it is not known which one will be chosen. An alternative TI should satisfy the following constraint: the duration, time and date value of each of its children is the same as the duration, date and time values of the alternative TI. In Figure 4 node.2 is an example of an alternative TI. It has three children associated with ATs projectproposal, paperrehearsal, researchideas. Note that an alternative TI is always exclusive: only one of its children will be started. A non-exclusive alternative TI (one or several of its children are started in sequence) is modelled as an unordered sequence TI with non mandatory children nodes. An iteration TI models the fact that its child TI (and therefore the subtree for which the iteration node is the root), can take place sequentially several times. In Figure 4 node.3 is an example of an iteration TI. Its child TI is associated with AT miscellaneous. The schema of table miscellaneous is shown in Figure 7. Attribute initiator holds the person who initiated a discussion on a given subject while the summary of the discussion is stored in the attribute summary. During the telemeeting session node.3.1 will be started as many times as there is something to be discussed which is not modelled by the remaining subtree. The MA may specify the minimum and maximum number of iterations. The minimum and maximum number of iterations are stored in attributes min_iterations and max_iterations respectively in the intervals table. The maximum number of iterations is unlimited when no value for max_iterations is defined. miscellaneous (interval_id, initiator, subject, summary) Figure 7 Relation schema of the miscellaneous AT 3.2 Agenda Instances During the meeting session the MA creates a meeting agenda instance from a meeting agenda template. If T is the tree corresponding to the agenda template, a copy T of T is the agenda instance. The boolean attribute template in the metingagendas table indicates whether a meeting agenda is a template or an instance. The agenda instantiation process lasts during the whole telemeeting session period. It consists of partitioning the meeting into TIs, annotating TIs with the semantic description of the agenda template and informing the MA whether the fragmentation matches the definition of the temporal structure of the meeting agenda template. Nodes of T may be in one of five states: initial, candidate, started, expired and rejected. The attribute state in table intervals stores the node's state. Figure 8 shows node state transition diagram.

12 68 ToMaTe: A Toolbox for Managing Telemeetings initial candidate started expired rejected Figure 8 Node state transition Initially all nodes of T are in state initial except the root node of T which is in state candidate. A node being in state rejected models the fact that the node will never be started. A node being in state candidate models the fact that the node could be chosen for instantiation. The fact that a node enters the started state models the fact that the TI corresponding to the node is now taking place. A node reaches the state expired when the corresponding TI ends. The MA may execute two operations on every TI: start a candidate TI and end a started TI. The start of a TI requires valid values for attributes valid_start_time and valid_start_date and triggers the state transition to the state started. The end of a TI requires valid values for attributes valid_stop_time and valid_stop_date and triggers the state transition to the state expired. On iteration nodes it is possible to apply the new_iteration operation. Applying the new_iteration operation on a node IN models a new iteration of IN and increases the number of nodes of the agenda instance. Let T be an agenda template, I be an iteration in T and B the subtree under I. Let T be an agenda instance of T and I in T the peer iteration node of I. Each time the new_iteration is applied on node I, a copy B' of B is created and the root node of B' becomes an immediate child of I. A start or end operation on a node N may trigger state transitions for nodes other than N. More precisely, the system performs the following computations. First, it determines which initial nodes should become candidates. econd it determines which candidate nodes should return to the initial state. Third it determines which initial and candidate nodes should become rejected. In order to give the reader a better understanding of the way the instantiation process executes, we illustrate in Figure 9 a sequence of node operations applied to a partial TI tree. We use the same conventions we have used in Figure 4 for identifying nodes and denoting node types. Inside rectangles we place the first letter of state identifiers (for example for started) for denoting the current state of the node. The node operation applied on a configuration is indicated at the bottom of the tree. For example, in Figure 9 (a) the operation start is applied on node and the effect of the operation is shown in Figure 9 (b): the state of node is started and the state of node N.2 is initial. In Figure 9 (c), node enters the state started after applying the operation start on it. Applying the operation new_iteration on node creates the node.1 immediate child of node in state candidate as shown in Figure 9 (d). From the descriptions of Figure 9 (a)-(d) it is now easy to identify the state transition caused by the operations shown in Figure 9 (e)-(j).

13 C. Arapis 69 C N.2 C C C N.2 C I C C C (a) start (b) start N.2 C C N.2 I I R R C.1 (c) new _iteration (d) start.1 N.2 I R R.1 N.2 I R R E.1 (e) stop.1 (f) new _iteration N.2 I R R E.1 N.2 I R R E.1 C.2 (g) start.2 (h) stop.2.2 N.2 N.2 R R C E.1 E C E R R E.1 E.2 E.2 ( i )stop ( j) Figure 9 Example of a sequence of node operations and state transitions

14 70 ToMaTe: A Toolbox for Managing Telemeetings 4 Querying the TDB Users familiar with database technology can directly query the TDB using the query engine of the DBM implementing the TDB. ince TDB is currently implemented on top of a relational DBM the query language is an (extended version) of QL. For users not familiar with databases the MA in cooperation with the TDB administrator should provide higher level query interfaces than bare QL language. The MA and the TDB administrator may also use scripting languages and tools provided by the DBM for developing elaborate query interfaces. ToMaTe provides users with discrete data players and an audio server and client programs for displaying discrete data and playing audio data respectively. The audio server streams the part of the audio file its client has requested. Thus whenever the result of a TDB query contains TIs, the valid start and end time and date values can be used for requesting the sound corresponding to the TI from the audio server. We have developed two types of discrete players, one for displaying HTML documents and one for displaying text. The HTML player is fed an array of pairs (timestamp, URL). The text player is fed with an array of pairs (timestamp, text). A player displays the data it is fed satisfying the order and delays derived from the set of timestamps associated with the data. The difference between the two types of players is that the HTML player renders HTML pages referenced by the URLs while the text player appends pieces of text in a text subwindow. The HTML player is used for redisplaying presentations. A text player is used for displaying either messages, text chat lines or user attendance. All players implement the four operations "play", "stop", "pause" and "resume" having similar semantics to that of tape players. Figure 10 shows the query interface we have developed for retrieving TIs stored in the TDB. The left window allows the user to issue QL queries to the TDB. The user may select a TI identifier appearing in the result of the query and then press the "TI player" button: the "TI player" program starts popping up a window shown in the right part of Figure 10. The "TI player" displays all the information relevant to the selected TI. Figure 11 shows the TI player's interface. The user may select a set of discrete and stream data to be displayed. Pressing the "play" button in the "TI player" window starts the execution of a player for each selected type of data. In Figure 10 two types of data have been selected: audio and HTML. The "TI player" allows the user to pause, resume and play the selected streams. The TI player simply requests the executing players to perform the same operation. The HTML player has a similar user interface to the user interface of the telepresentation service shown in Figure 2. The audio player does not display any window on the screen, it only produces an auditing effect. Finally, the buttons "parent", "child", "next" and "previous" in the "TI player" window allow the user to navigate from one TI to another; "next" and "previous" buttons allow us to navigate to nodes having the same parent (a sequence TI or an iteration TI), the ordering being based on valid start date and time values.

15 C. Arapis 71 Figure 10 Query interface of the TDB Figure 11 The TI player interface

16 72 ToMaTe: A Toolbox for Managing Telemeetings 5 Implementation ToMaTe is an inherently distributed environment: ToMaTe s services are provided to users connected through Internet and LANs. The majority of ToMaTe is written in Java 1.1 and is highly portable. Until now, the Java part of TeME has been ported to a variety of environments without requiring any adaptation effort. Only parts that access audio devices and modules which should execute efficiently in real time, like compression/decompression of audio data, are written in C/C++ and are less portable. For the storage and management of the TDB ToMaTe requires a relational DBM which provides a JDBC interface [9]. This currently holds for most popular relational DBMs. Note also that the data type of Ts attributes are either integer or string. Thus the TDB could be supported by any DBM satisfying the JDBC requirement. The audio communication between a user and the TDB server used when querying the TDB is implemented using a TCP connection for signalling and UDP for the audio data transmission. Finally, the telepresentation service and the HTML viewer used for querying the TDB are based on the HotJava HTML component developed by UN [10]. 6 Conclusions In this paper we have presented ToMaTe: a prototype system for modeling and managing the complete life time of telemeetings. ToMaTe has been designed to satisfy a number of requirements including: providing users with mechanisms for annotating telemeetings stored in the telemeeting database, freeing users from the time consuming media editing effort, extendibility of ToMaTe to a variety of telemeeting types and support for elaborate telemeeting database query/access mechanisms. From our experience in using ToMaTe we believe we have succeeded in fulfilling these requirement to a large extent. Our future development plans fall in the following directions: provide support for additional media types like video and animation, integrate voice based identification of speakers, implement application sharing services allowing applications to be shared among users attending a telemeeting and investigate additional query interfaces and tools for accessing the TDB. References [1] C. Arapis, D. Konstantas and T. Pilioura. Design Issues and Alternatives for etting up Real-time Interactive Telelectures. Proceedings of the 1998 ACM ymposium on Applied Computing (AC 98), Atlanta, Georgia, February-March 1998, pp [2] C.Arapis and D. Thanos, Telemeetings: managing their temporal structure. IEEE International Conference on Multimedia Computing and ystems'99, Florence, Italy, June [3] D. Dutta-Roy. Virtual meetings with Desktop Conferencing, IEEE pectrum, Vol. 35, No. 7, July 1998, pp [4]. Minneman,. Harrison, B. Janssen, G. Kurtenbach, T. Moran, I. mith and B. van Melle. A Confederation of tools for Capturing and Accessing Collaborative Activity, Proceedings of the 3 rd ACM Multimedia Conference, an Francisco, California, November 1995, pp

17 C. Arapis 73 [5] "Research and Advanced Technology for Digital Libraries", econd European Conference on Digital Libraries, ECDL'98, ed. by C. Nicolaou, Lecture Notes in Computer cience 1513, Crete, Greece, eptember [6] "Database emantics, emantic Issues in Multimedia ystems", IFIP TC2/WG2.6 Eighth Working Conference on Database emantics (D-8), Kluwer Academic Publishers, ed. by R. Meersman, Z. Tari and. tevens, Rotorua, New Zealand, January 4-8, [7] J. Foote. "An Overview of Audio Information Retrieval", Multimedia ystems, ACM and pringer, Vol. 7, No, 1, 1999, pp [8] D. Kimber and L. Wilcox. Acoustic egmentation for Audio Browsers, Proceedings Interface Conference, ydney, Australia, July [9] JDBC specification. Available on the Web at [10] HotJava HTML Component. Available on the Web at