Automatic Generation of Capture and Access Applications Laércio Augusto Baldochi1,2
Renan G. Cattelan1
[email protected]
[email protected]
Maria da Graça Pimentel
[email protected]
1
Khai N. Truong3
[email protected]
1
Instituto de Ciências Matemáticas e de Computação - Universidade de São Paulo Avenida Trabalhador São-Carlense, 400 - C.P. 668 - 13560-970 - São Carlos – SP 2
Faculdades COC Rua Abraão Issa Halack, 980 - 14096-160 - Ribeirão Preto - SP 3
College of Computing & GVU Center - Georgia Institute of Technology Atlanta - GA - 30332-0280
Abstract. In ubiquitous computing environments, many applications have been built in order to generate documents as a result of the automatic capture of information in live experiences. Many of those examples present similar functionalities that include the extensive use of whiteboards and the capturing of audio and video streams. Previous work has reported on an infrastructure supporting the implementation of capture and access applications for several domains, basically providing network abstractions that make communication transparent between peers of applications. As an evolution of this work, we present a toolkit that allows the construction of capture and access applications based on specifications of desired functionalities. Keywords: ubiquitous computing, capture and access, data schemas, data binding.
1. Introduction Using ubiquitous computing environments, many applications have been built in order to support the automatic capture of information in live experiences towards providing future access to the captured material. This is more evident in the educational [Abowd 1999, Davis et al. 1999, Mukhopadhay & Smith, 1999] and meeting [Chiu et al. 1999, Richter et al. 2001, Streitz et al. 1994, Wilcox et al. 1997] domains. These examples present similar functionalities: the extensive use of whiteboards and the generation of audio and video streams. However, in spite of those common functionalities, capture and access applications have been developed as ad hoc efforts. In order to solve this problem, relieving developers from repetitive work, an infrastructure is provided to aid the implementation of capture and access applications for several domains, by basically providing network abstractions that make communication between applications transparent [Truong & Abowd 2002]. As an evolution of this work, we are now developing reusable software components that encapsulate the functionalities of specific parts of capture and access applications. Examples of components are whiteboards, chat, audio and video capturers.
These components are being developed to allow automatic use of the facilities they provide. So, in order to make use of a component all an application has to do is instantiate the component’s object and implement its respective interface. This paper presents a toolkit called CAT – Capture and Access Toolkit – that embodies this set of components in order to allow the assembling of applications based on specifications of functionalities. Our approach to automate the generation of capture and access applications is based on an extensible client/server architecture. We define a specific data schema for each of our components and use those schemas to structure the information they produce. Using a data binding mechanism, we derive Java classes for the elements and attributes present in each schema, allowing both server and client sides of applications to define objects that manipulate and exchange the captured information. For each application’s configuration, we provide an associated data schema generated by the combination of each component’s schema. The generated schema represents the structure of all possible information produced by the application. This schema is submitted to a schema compiler, which produces the classes used to generate an entity called Storage Module, responsible for gathering the information produced by the clients and generating an XML document that represents a captured session. The Storage Module is part of a service called SRES – Storing, Retrieving and Extending Service – which aims at providing an ubiquitous service for the manipulation of the information produced by capture and access applications. Each document generated by the Storage Module is sent to another SRES module called Document Manager, which is responsible for storing the resulting document in a native XML database. This approach generates classes of XML documents that conform to a set of well know data schemas. This fact makes the development of access applications easier because the designer can make use of the schemas to process and present information. The initial toolkit’s interface is a web page where the user can choose between accessing a captured material or capture a new activity. In the first case, the user receives a browsing mechanism to search for the desired session. When the user selects a captured session, the toolkit automatically provides a front-end application provided with access modules of the components needed to present the captured material. When viewing a captured session, the user may extend the captured information with annotations. If the user chooses to capture a new activity, two options are provided: interacting with an already running application or creating a new application. By choosing the first alternative, the user receives a list of all running applications. Otherwise, she receives a list of all available components in order to create a new application. In the former case, the server sends a client’s interface with the same components as the chosen application. In the later case, the user must select the desired components and submit her choice to the server, which sends the appropriate client’s interface. For the sake of demonstrating the utility of our toolkit, we show the impact of its use in the implementation of a distributed discussion application. We show how our approach automatically provides an interface and tools for the capture of distributed meetings.
This paper is organized as follows: Section 2 presents the INCA and xINCA infrastructures, emphasizing the development of xINCA components used in our toolkit. Section 3 explains the mechanism that allows the automatic generation of capture and access applications using xINCA components. Section 4 presents how the information management provided by SRES eases the implementation of access applications. Section 5 shows how our toolkit automatically generates a distributed discussing application based on the whiteboard and chat components. Section 6 explains how the toolkit allows the extension of the set of supported xINCA components. Section 7 concludes the paper and discuss future work.
2. INCA and xINCA Due to their distributed nature and large number of devices involved, the design of capture and access applications has been a challenging activity. However, many similarities can be noticed from the designer perspective. Truong suggests a divide and conquer approach [Truong & Abowd 2002] by expressing the design of capture and access applications in terms of separate concerns: •
Part of the system is responsible for the capture of information as streams of data.
•
Part of the system is responsible for the storage attribute-tagged (representing contextual metadata) information.
•
When information needs to be converted into different formats and types, part of the system must transduce the information.
•
Part of the system provides access to multiple related, or integrated, streams of information that are gathered as response to context-based queries.
To validate his theory, Truong developed INCA (Infrastructure for Capture and Access Applications) which provides architectural support for building capture and access applications through the set of key design concerns explained above – capture, storage, transduce and access. Each of those has a correspondent interface and encapsulated module defined by INCA. According to their needs, developers must implement and instantiate the desired interfaces and functional modules. INCA also provides two layers of abstraction: network and information. The first relieves developers from knowing how the different parts of the system communicate with each other. INCA provides an entity called Registry that runs in a well-known location and maintains a list of available modules. This entity is responsible for managing the data transfer betwen modules, as is shown in Figure 1. Information abstraction is reached by treating data as large binary objects. When applications are built to support a specific data type, the need for new kinds of data implies in the reimplementation of large portions of the system. INCA allows information to be assembled as DataObjects with a pair name-value that expresses meta-information about it. By imposing to data this uniform representation, INCA abstracts specific information issues from the application.
Figure 1. Generic architecture for applications built with INCA [Truong & Abowd 2002].
Besides architectural aspects, most capture and access applications presents recurrent functionalities, e.g. whiteboard, chat, audio capture, video capture and Web browsing history capture. These functionalities can appear in any combination and suggest a component-based approach. With this in mind, we developed xINCA (Extended Infrastructure for Capture and Access Applications), an extension of INCA that provides a set of reusable software components, each one responsible for a specific functionality between those mentioned. xINCA was built as a layer above INCA making use of its modules and abstractions as depicted in Figure 2.
Figure 2. Layered architecture for capture and access applications built with xINCA.
Figure 2 also shows that the developer still has direct access to the INCA layer, being able to use its resources or to extend the xINCA by adding new components. Using xINCA, a new capture and access application is built through the arrangement of the desired software components. These components communicate using a session identifier. A session represents a period of interaction between components and must have a unique identifier as long as it lasts. Otherwise, the behaviour of one application can interfere in another. New components can be added or removed at any moment during a session. The xINCA components implement instances of capture, access or both INCA modules. These modules are registered under a session identifier at runtime in a Registry entity, which can be local or remote. Modules of components registered under the same session identifier in a Registry entity are able to exchange data.
Figure 3 depicts the communication flow between components in two simultaneous sessions. On the left, there is a capture and access application (App #1) with two components, a chat and a whiteboard. In the upper right, there is a capture and access application (App #2) with a chat component. Below App #2, there is another capture and access application (App #3) with a whiteboard component. The chat components of App #1 and App #2 are registered under the same session identifier (Session #1) and, consequently, have an active communication channel that allows them to exchange information. The same way, App #1’s and App #3’s whiteboard components are registered under a same session identifier (Session #2) and are able to exchange data. For this last case, the communication flow is unidirectional since App #1 only captures information in the whiteboard and App #2 only accesses the information captured from the whiteboard.
Figure 3. Communication flow between components in two simultaneous sessions.
Information captured by the components is made available to applications through callback methods that should be implemented according to well defined programming interfaces. Each component has a correspondent programming interface that must be implemented by the application in order to make the component available.
3. A Component-Based Toolkit The development of our toolkit is mainly motivated by the fact that almost all capture and access applications have common functionalities based on the capture of audio and video streams and the use of shared devices, such as whiteboards. As shown in Section 2, the INCA infrastructure provides facilities that allow automatic interchange of captured material. Using those facilities, components for the most common captured-based interfaces have been developed, speeding up the implementation of capture and access applications. Our next step is to allow the generation of applications based on the automatic aggregation of xINCA components. In order to achieve this goal, we are developing a toolkit that provides a mechanism for the inclusion of new components. Our approach to allow the extension of the toolkit is based on the definition of data schemas for each defined component. The schemas aim at structuring the content of the information produced by the components, allowing the implementation of a storage service based on XML documents.
3.1 Data Schemas We defined a contextual schema that contains the elements common to all capture sessions, such as the name of the people involved, the place or places where the activity occurs and the date (start time and end time) of the session. Depending on the application’s needs, optional elements may be included in this schema. For each component of the toolkit, we also generated a proper schema that defines the structure and the content of the information produced by the component. The component schemas are used to generate what we call session schemas. For each possible combination of components, we automatically build a session schema, which results from the aggregation of the contextual schema with the schemas associated to the components used in the session. To illustrate this mechanism, consider our contextual schema shown bellow. Our current implementation uses DTDs since the version of the schema compiler we are using does not support XML Schemas. A future version will be based on XML Schemas.
context_info (session_title, person+, place+, date)> session_title (#PCDATA)> person (#PCDATA)> place (#PCDATA)> date (#PCDATA)> person id CDATA #REQUIRED place_id CDATA #IMPLIED>
One possible application can combine the components whiteboard and chat. Therefore, the following two boxes show the whiteboard and chat DTDs.
whiteboard (slide+)> slide (title, keyword*, url, stroke*)> title (#PCDATA)> keyword (#PCDATA)> url (#PCDATA)> stroke (x0, y0, x1, y1)> x0 (#PCDATA)> y0 (#PCDATA)> x1 (#PCDATA)> y1 (#PCDATA)> slide timestamp CDATA #REQUIRED> id_person CDATA #IMPLIED>
The session schema for an application with those two components is the following. %c_info; %chat; %wb;
Examining the generated session schema we notice that its root element (session) is composed by the root elements of the context_info, whiteboard and chat schemas. To make it possible, we had to “import” the context_info.dtd, the whiteboard.dtd and the chat.dtd. We did this with the ENTITY tag. 3.2 Data Binding The set of session schemas are submitted to a data binding mechanism called JAXB – Java Architecture for XML Binding [Lin 2002]. JAXB compiles each session schema into a set of Java classes. The generated classes handle all the details of XML parsing and formatting, allowing developers build applications that can read, manipulate and create XML documents without writing any logic to process XML elements. The set of classes produced by JAXB is part of the Storage Module, which receives the data generated by each application’s component and stores this information into the objects provided by those classes. So, for each combination of components, a different instance of the Storage Module is generated. Besides the set of classes produced by JAXB, it is necessary to write the class that handles the transduction of the component’s data into XML documents. This class, called Transducer, instantiates accessor objects for each component present in the application. It also instantiates objects from the classes generated by JAXB. Using the accessor objects, the Transducer receives all the information generated by the application’s components and transduces this information to the objects provided by the data binding mechanism. The transduction process is divided in two tasks. The first is very simple and consists in receiving external objects and mapping them to local ones provided by the classes generated by the data binding mechanism. The second, more complex, consists on receiving external objects together with a file. This happens, for instance, when a new slide is generated – the whiteboard accessor component receives a JPEG file with the slide image together with metadata that gives additional information about the slide (title, time of creation, keywords, etc.). In this case, besides mapping the metadata to the correct objects, the Transducer must also store the JPEG file in a predefined URL and use the value of this URL to set the URL variable in the Slide object (URL is a slide attribute – see whiteboard.dtd). According to this functionality, during a capture session the Transducer keeps mapping the information received by the accessor components to objects derived from a session schema. When the session finishes, the Transducer calls the marshal method on the
session object (the root object). The marshaling process produces an XML document, which is sent to an external entity called Document Manager. The Document Manager maintains a repository of XML documents generated by capture applications. As explained above, the data binding mechanism eases the development of the Storage Module. All the developer must do when implementing a new Transducer class is to provide a bridge between the accessor components and the classes automatically generated by JAXB.
4. Accessing and Extending the Captured Content As far as the support to long-term use of automated captured-based application is concerned, an active growth of the information repository can be observed at the same time that there is an intrinsic referencing among the information captured and stored in the repository, resulting in what is called evolutionary information [Pimentel et al. 2001a]. The active growth occurs as a result of the automatic generation of documents associated to captured sessions. The instrinsic referencing occurs because, although many capture sessions may be related to each other (for instance, the several meetings of a software project are bound to be strongly related), applications are usually not built so that such referencing be made explicit. Therefore, those two features must be considered in the design of any long-term capture and access ubiquitous computing application and its underlying infrastructure. In order to build a repository that supports these two features we are developing a service called SRES – Storing Retrieving and Extending Service. SRES manages a repository of evolutionary information and provides a set of services to store and manipulate the information generated by capture and access applications. Figure 4 shows SRES architecture.
Application 1
Application 2
Application n
SM/EM
SM/EM
SM/EM
SRES Linking Service
Links
Document Manager
Documents
Medias
Annotation Service
Annotations
Figure 4. SRES architecture (SM = Storage Module; EM = Extesion Module).
Figure 4 indicates that each capture and access application is associated to a Storage Module and, optionally, to an Extension Module. The Storage Module is composed of the elements presented in Section 3.2 (Transducer, accessor classes and classes generated by JAXB) and an interface that allows the application to communicate to the Document Manager. This interface is provided by an API – Application Programming Interface – called Storer, which is responsible for both storing and retrieving information produced by capture and access applications. Similarly, the Extension Module implements, through the Extender API, a set of abstractions that provide extension services to the applications. These services allow applications to perform annotations and set up links between documents. The services provided by the Extension Module are presented in Session 4.2 and 4.3. The Document Manager, entity responsible for the maintenance of the evolutionary information repository, manages all the information stored in the SRES. In order to provide the intrinsic referencing among related documents, SRES implements a storage model based on contextual information available during the capture phase. The storage model used by SRES is explained below. 4.1 Modeling an Evolutionary Repository Truong et al. [Truong et al. 2001] define five dimensions that must be considered when developing capture and access applications. These dimensions are: •
Who are the users during capture and access? Refers to the identity, roles and number of users.
•
What is captured and accessed? Refers both to the definition of the artifacts that need to be captured and to what level of fidelity is required between the live experience and the playback of the captured experience.
•
When does capture and access occur? Refers to the frequency of the captured activity and the existence of patterns that predict its occourrency.
•
Where does capture and access occur? Refers to the determination of the place of occurrence of the experience in order to instument it adequately for the capture.
•
How is capture and access performed? Refers to what kind of devices and tools are required both to capture the activity and to access the produced material.
Those five dimensions are basically contextual information available during the capture phase. The SRES explores this information in order to structure the repository of evolutionary information. The Document Manager stores a document in a native XML database according to its class, which is determined by its associated schema. For each class of documents there is a corresponding collection of documents. This shows the dimension how being used in the storage process. The other four dimensions are also used, as described below. Each time a new document is sent for storage, the Document Manager identifies through its associated schema, which of its nodes correspond to the contextual information who, what, when and where. Remember we have in our DTDs the elements person (who), place (where), date (when), title of sessions and title and keywords for slides (what).
When a node corresponding to the dimension who is identified, the Document Manager searches the repository for documents of the same class that have nodes with the same content for the dimension who, and establishes a bi-directional link between the node of the new document and the corresponding node of the most recent document already stored in the repository. An analogous process happens to the dimensions what and where. The dimension when is explored implicitly, as the model considers the most recent documents when establishing contextual links. 4.2 Linking and Annotation Services In order to build the evolutionary repository demanded by capture and access applications, SRES uses an external linking service called Web Linking Service (WLS) [Bulcão Neto et al. 2002], shown in the left-hand side of Figure 4. WLS is an XML based open linking service that aims at providing hypermedia functionalities to nonhypermedia applications. Managing an external and independent link base, WLS extends applications so that they became hypermedia-enabled. WLS will also be used to offer linking services to access applications. Part of the Extender API aims at providing facilities for the extension of the captured information through the definition of links, allowing both users and applications to define navigational trails other than those provided by the contextual information (who, what, when and where. Another important extension mechanism added to SRES is the GroupNote [Pimentel et al. 2001b], an open annotation service that supports collaborative annotations as first class hyperdocuments. 4.3 Building Access Applications The storage model implemented by SRES eases the development of access applications. As sessions are represented by XML documents, and these documents are organized accordingly to the schemas they conform, access applications need only to instantiate access components for the class of documents they wish to present. This is the case with most of the access applications provided by our toolkit. However, in some cases, we decided to provide the user more than exactly the same interface used during the capture phase. We did this because during the access phase the user can be overwhelmed with the amount of information, and may experience difficulties to find the information she wants. So, in order to provide a better visualization of the captured material, we are developing access applications that use components provided by xINCA with visualization tools that help the navigation through the captured material. One of these visualization tools is a timeline with marks that indicate the arrival of new participants in the session, the presentation or generation of slides, the visit to web pages, etc. The benefits of SRES to the development of access applications go beyond providing Web-like access. Through the Extender API we provide high-level abstractions that aid the implementation of applications that leverage the utility of the captured information. The generation of navigational trails and customized annotation over the captured material are some of the forms in which the captured content may be extended.
5. Generating a Distributed Discussion Application In this section we show a detailed description of how a distributed discussion application based on whiteboard and chat components is generated using our toolkit. Initially we show the generation of the capture application and next we describe the generation of the application used to access the captured content. These descriptions aim at clarifying the architectural aspects of our toolkit, showing how its parts interact to provide the expected application. 5.1 The Capture Application A user starts to interact with our toolkit specifying desired components and providing contextual information. Figure 5 shows an interface where the user chooses the application’s desired components: in this example, chat and whiteboard. Notice that, in the upper right-hand side of Figure 5, the user is asked to inform contextual data about the session, such as its title, the name of the people involved and optionally, where the session will take place. It is also important to note that the user must make it explicit whether the session is local or distributed. This is important because local sessions do not allow the joining of users, what may happen in distributed ones. Finally, the user must inform whether the session is public or private. The access to the content captured during a public session is not restricted. For private sessions, the access to the captured material is only allowed for the participants of the sessions. The contextual information, such as those that identify users and places are kept in XML documents managed by SRES. We do this to avoid inconsistencies in the identification of people and places and also to allow the authentication of users during the access phase. SRES also manages the generation of session ids. The ids are used to register the session components in the Registry, as well as to index the resulting XML documents in a native XML database managed by SRES. The setup process is controlled by a PHP script that process the user’s choices defining an appropriate application front-end composed by the chosen components. As shown in Figure 6, this application receives the session information and uses this information to contact an entity called Session Daemon (Sessiond). Based on the received information, Sessiond instantiates an appropriate Storage Module to process the information to be produced by the new application. In the instantiation process, whiteboard and chat accessor components are registered in the Registry entity using the session id passed by the application. When the instantiation of the Storage Module finishes, the application instantiate its components causing the registration of capture components under the same session id. That automatically allows the communication flow between the application and its Storage Module, as is shown in Figure 6.
Figure 5. The toolkit’s setup interface for capture applications.
As our example is a distributed discussion application, it is expected that other users join the session. As discussed earlier, the user may choose between creating new sessions or joining existing ones. In order to join our example’s session, all the user must do is to select it in the list of active distributed applications. As a result, she receives a Java-based front-end application with capture and access modules ready to interchange information. Figure 7 shows our example application’s front-end. Note that the whiteboard component supports the uploading of slide images previosuly prepared, allowing users to write over those slides, as shown by the ink drawings in Figure 7. In order to control the end of sessions, Sessiond maintains a list of all active sessions, updating periodically this list by calling a method named getActCapSess() in the Registry, as depicted in Figure 6. This method returns a list containing the ids of all sessions that have active capture modules. Sessiond compares the new received list with its old list. For the session ids present in the old list but not present in the new one, Sessiond find their associated Storage Modules and calls the stop() method on them. Calling the stop() method on a Storage Module results in the generation (marshaling) of an XML document that represents the structure and content of a session, as discussed in Section 3.2. The resulting document is then sent for storage.
Figure 6. The toolkit’s data flow when creating and running the whiteboard+chat capture application.
Figure 7. A capture application with whiteboard and chat components.
5.2 Accessing the Captured Content The development of access applications benefits from our storage model, which organizes documents representing captured sessions according to the schemas they conform. Therefore, to present a certain class of documents, the developer instantiates the access components needed to present that class of documents. During the access phase, the user interacts with our toolkit by accessing a web page where we list the classes of captured sessions. On choosing a certain class, the user receives a list of captured sessions with associated contextual data, such as the name of the people involved, the places where the sessions took place and the session’s date. Supposing the user chooses to access the class of sessions generated by our capture application shown in Section 5.1, the toolkit would automatically provide an access application with facilities to present slides and messages. As we mentioned earlier, we are extending the functionality provided by our components in order to allow VCR like control over the presentation of captured material. To provide access to the material produced by our capture application example, we used the stroke information saved in the XML document to playback the generation of slides. We allow the user to navigate through the set of slides using the buttons bellow the slide presentation area, as shown in Figure 8. Synchronously to the playback of each slide, the chat component presents the messages exchanged, providing users a rich access experience.
Figure 8. An access application for content generated by a whiteboard+chat capture application.
Finally, in order to provide a notion of the length of a session, we added a timeline to present content captured with the whiteboard component: as indicated in Figure 8, the timeline marks the start of a new slide with a vertical bar. The user may interact with those bars to jump to the slide being presented at that moment. So, clicking on the 5th bar causes the presentation of the 5th slide.
6. Extending the Toolkit xINCA provides software components for the capture of the most common forms of human interaction, including chat, whiteboard, audio, video and web browsing. The set of components provided is sufficient to build a wide range of applications. However, it is necessary to consider the evolution of devices used to capture information. Eventually, an application developed for a new device will need a different component than those provided by xINCA. This fact implies the necessity of an extension mechanism in order to allow the inclusion of new components in the toolkit. Fortunately, our toolkit provides an easy mechanism for the inclusion of new components. When implementing a new component, the first step is the definition of the component’s data schema, which is used both to implement the storage service in the server side, and the front-end applications, in the client side. Besides implementing the set of Storer classes in the server side, the developer must implement a set of front-end applications – one front-end for each combination of components where the new component is present. This is not a hard task: the implementation effort involves the instantiation of components in a Java applet.
7. Conclusions and Future Work This paper presents a work in progress that aims at providing facilities for the development of capture and access applications. Previous work reports the implementation of an infrastructure that abstracts communication and information issues related to the implementation of this type of applications [Truong & Abowd 2002]. Based on this work, we developed software components that encapsulate functionalities of specific parts of capture and access applications. Those components have leveraged the developement of applications since they relieve developers from writing repetitive code. In order to provide even higher abstractions for the development of capture and access aplications, we are now developing an extensible toolkit that provides means for the automatic definition of different applications based on the combination of components. Our toolkit is being developed to be used by people without programming skills. To set up a new application, all a user must do is interact with GUI elements, as shown in Section 5. The novelties present in our toolkit include: (a) an extension to the INCA infrastructure, (b) a systematic methodology for the development of client/server capture and access applications, (c) an architectural support for the generation and maintenance of an evolutionary information repository produced by capture applications, and (d) a web interface that spreads the availability of capture and access applications to the whole web.
Up to now we have driven our efforts in the automation of the capture and access process. Our next step is the implementation of the Extender API, aiming at providing high-level abstractions in order to allow applications extend the captured material with annotations and links between session elements.
Acknowledgements The authors would like to thank CNPq, FAPESP and NSF for their support.
References Abowd, G. D. (1999) Classroom 2000: An experiment with the instrumentation of a living educational environment. IBM Systems Journal, Volume 38. Bulcão Neto, R.F., Izeki, C., Pimentel, M., Fortes, R., Truong, K. (2002) An open linking
service supporting the authoring of web documents. To appear in the Proceedings of the Symposium on Document Engeneering. Chiu, P., Kapuskar, A., Reitmeier, S., Wilcox, L. (1999) NoteLook: Taking Notes in Meetings with Digital Video and Ink, in Proceedings of ACM Multimedia, Orlando. Davis, R., Landay, J., Chen, V., Huang, J., Lee, R., Li, F., Lin, J., Morrey, C., Schleimer, B., Price, M., and Schilit, B (1999) NotePals: Lightweight Note Sharing by the Group, for the Group, in Proceedings of CHI, Pittsburg. Lin, T.W. (2002) Java Architecture for XML Binding (JAXB): A Primer. Available in http://developer.java.sun.com/developer/technicalArticles/xml/jaxb/ Mukhopadhay S., Smith, B. (1999) Passive Capture and Structuring of Lectures, in Proceedings of ACM Multimedia, Orlando. Pimentel, M., Kerimbaev, Y., Abowd, G., Guzdial, M. (2001a) Supporting long-term educational activities through dynamic Web interfaces, Interacting With Computers Journal, 13:353-374.
Pimentel, M.G.C., Izeki, C.A., Arruda Jr C.R.E. (2001) An XML-based Infrastructure Supporting Collaborative Annotations as First-Class Hyperdocuments. Simpósio Brasileiro de Hipermídia e Multimídia (SBMIDIA). Richter, H., Abowd, G., Geyer, W., Fuchs, L., Daijavad, S., Poltrock, S. (2001) Integrating Meeting Capture within a Collaborative Team Environment, in Proceedings of Ubicomp, Atlanta. Streitz, N.A.T., Geibler, J., Haake, J.M. and Hol, J. (1994) DOLPHIN: integrated meeting support across local and remote desktop environments and liveboards, in Proceedings of CSCW’94, pages 345-358. Truong, K. N., Abowd, G. D., Brotherton, J. A. (2001) Who, What, When, How: Design issues of capture & access applications, in Proc. eedings of the International Conference on Ubiquitous Computing, Atlanta. Truong, K.N., Abowd, G.D. (2002) Enabling the Generation, Preservation & Use of Records and Memories of Everyday Life. GATECH GIT-GVU-02-02. Wilcox, L., Schilit, B. N. and Sawhney, N. (1997) Dynomite: A Dynamic Organized Ink and Audio Notebook, in Proceedings of CHI, Atlanta.
