Experiences on Building Capture & Access Applications - CiteSeerX

Experiences on Building Capture & Access Applications Renan G. Cattelan1 , La´ercio A. Baldochi Jr12 , Maria da Grac¸a Pimentel1 1

Instituto de Ciˆencias Matem´aticas e de Computac¸a˜ o – Universidade de S˜ao Paulo Av. Trabalhador Sancarlense, 400 – C.P. 668 – 13560-970 – S˜ao Carlos, SP – Brazil 2

Faculdades COC Rua Abra˜ao Issa Halack, 980 – 14096-160 – Ribeir˜ao Preto, SP – Brazil {renan,baldochi,mgp}@icmc.usp.br

Abstract. Capture & access applications exploit the ubiquitous computing paradigm – populate the environment with computational devices and applications to transparently assist people on their activities – to support the automatic capture of information in live experiences and generate corresponding documents that can be further stored, accessed and extended. Traditional examples of such a class of applications include the educational, office and meeting domains, and most of them make extensive use of network communication, whiteboard interactions, web browsing, text and audio/video streams. Despite their common needs and architectural similarities, there is a lack of support for building capture & access applications. In this paper, we present a component-based infrastructure that reduces the construction burden of capture & access applications by providing abstractions for their most common functionalities. Each functionality is represented by a software component, an interface and a XML schema that structures the captured data. We also show how these components are integrated with a storage service, their use in the implementation of two sample applications and some commonsense lessons learned from the overall experience.

1. Introduction The ubiquitous computing paradigm foresees the raising of environments populated with computational devices and applications to transparently assist people on their activities [Weiser, 1991]. Such a scenario also constitutes great opportunities to support the automatic capture of information in live experiences and the generation of corresponding documents that can be further stored, retrieved, visualized and extended. Examples of these so called capture & access (C&A) applications range from the educational [Abowd, 1999a, Davis et al., 1999, Mukhopadhyay and Smith, 1999] to the office [Mynatt et al., 1999] and meeting [Pedersen et al., 1993, Richter et al., 2001, Streitz et al., 1994, Wilcox et al., 1997] domains, making extensive use of network communication, whiteboard interactions, web browsing, text and audio/video streams. In spite of having numerous demonstrations of C&A applications, to develop them is not an easy task. Composed from a set of components that must interact and work together seamlessly, C&A applications demand a lot of time to be built and require expertise

in a myriad of problem domains. Distributed systems, hypermedia and mobile computing, to name a few, are examples. Regardless of their complexity and design similarities, C&A applications have often been built according to an ad hoc approach – to reach specific goals and without focusing on extension and reuse. Hence, there is a need for a development model which allows the rapid prototyping of a C&A application, its deployment and modification in face of a continuous feedback provided by the community of users. This model’s tools must support aspects of software structuring, correct separation of concerns and software components integration techniques for a wide range of devices and computing environments [Abowd, 1999b]. Truong and Abowd have tackled the problem that, although presenting many architectural similarities, C&A applications had been implemented by following an ad hoc approach [Truong and Abowd, 2002]. Their basic solution was to provide network abstractions allowing transparent communication among applications. However, in order to allow developers to quickly model and prototype C&A applications, we need to provide them higher level abstractions. This paper presents a work in progress that aims at providing facilities for the development of C&A applications executing on a publish/subscribe distributed architecture. We extended Truong and Abowd’s work by developing reusable software components that encapsulate specific functionalities present in a large number of C&A applications and organizing the captured data in self-contained units that facilitate the composition of the corresponding documents. Each of our components has its own XML schema used to structure the information it produces. Using a data binding mechanism, we derive Java classes for the elements and attributes present in each XML schema. We also introduce the concept of session, which represents a period of interaction between components, allowing them to manipulate and exchange information. By following our approach, a C&A application can be built through the assembling of the desired components. The rest of this paper is organized as follows: Section 2 describes the INCA infrastructure, starting point of our research. Session 3 presents xINCA, the functional abstraction we built on top of INCA. Section 4 explains how xINCA fits in with StRES, a storage service for captured information. Section 5 shows how our approach has been applied in the development of two sample C&A applications – iClass and CAT. Section 6 covers some basic lessons learned from our experience. Finally, Section 7 concludes this paper presenting a summary of the discussed topics and pointing future research directions.

2. Starting Point: INCA When building C&A applications, many similarities can be noticed from the developer’s perspective. Truong and Abowd suggest to express the design of a C&A application according to the main tasks it usually performs: the capture of information as streams of data associated with attributes representing contextual meta-data, the conversion (transduction) of those streams into different formats and types, the storage of the streams and corresponding attributes and the access to multiple related (according to their attributes) streams of information in response to context-based queries [Truong and Abowd, 2002].

To validate their proposal, Truong and Abowd developed INCA (INfrastructure for Capture and Access Applications) which provides architectural support for building C&A applications by means of instantiation and implementation, respectively, of modules and interfaces corresponding to the key design concerns – capture, storage, transduction and access. Specifically, the part of the system responsible for the capture of information implements the Capturer interface and instantiates a CaptureModule. Similarly, there are the StorageModule, TransductionModule, and AccessModule modules and Storer, Transducer, and Accessor interfaces for the other respective functions of the system. INCA provides two layers of abstraction: network and information. 2.1. Network Abstraction When developers build C&A applications using INCA, they don’t need to worry about communication details, like sockets or network protocols. INCA provides mechanisms that abstract such process, relieving developers from having to know how the different parts of the system communicate with each other. INCA has a Registry entity that automatically controls the presence of all capture and access modules in the system. Capture modules publish the kind of information they provide, while access modules subscribe for the kind of information they want to receive. When their publish and subscribe attributes match, capture and access modules have the communication flow between them enabled. Figure 1(a) shows a distributed system whose modules (capture, access and storage) communicate through a single Registry. More complex arrangements are allowed since different Registrys can be (explicitly) made aware of each other, thus connecting networks of INCA modules (Figure 1(b)).

Figure 1: General architecture for systems built using INCA: (a) All modules running in the same machine; (b) Distributed modules running in different machines [Truong and Abowd, 2002]. (Boxes filled in gray color represent machines’ boundaries)

2.2. Information Abstraction When a application is built do support specific data types, such limitation can raise difficulties to its evolution as a whole. If new data types must be supported, large parts of the application may have to be re-implemented. INCA treats data as large binary objects. Information is assembled as (DataObjects) tagged with a list of name-value attributes associating meta-information about the data. By imposing to data this uniform representation, INCA abstracts specific information issues from the application.

3. Extending the INCA Approach: xINCA Besides architectural aspects, most C&A applications share recurrent functionalities, e.g., whiteboard, text, audio, video and web browsing capture and access, which can appear in any combination. Table 1 shows the functionalities present in some classical C&A applications reported on the literature. Table 1: Functionalities present in C&A applications.

DOLPHIN [Streitz et al., 1994] DUMMBO [Brotherton et al., 1999] Dynomite [Wilcox et al., 1997] eClass [Abowd, 1999a] Flatland [Mynatt et al., 1999] LiteMinutes [Chiu et al., 2001] TeamSpace [Richter et al., 2001] Tivoli [Pedersen et al., 1993]

Audio X X X X – – X –

Text X – X – – X X –

Video X – – X – X X –

Web log X – – X – – – –

Whiteboard X X – X X X X X

Similarly, there is a increasing expectation that advances in software productivity will depend on the ability to combine existing pieces of software to produce new applications [Boehm and Scherlis, 1992] and that the building of software from reusable blocks will allow the creation of large, high quality systems in a much more rapidly way than the “build from scratch” techniques that prevail most of software production [Garlan et al., 1995]. INCA is a pioneering endeavor on bringing in such vision to C&A applications’ development and we are extending its approach by adding a set of reusable software components for the most common functionalities present in C&A applications. The resulting infrastructure, named xINCA (Extended INfrastructure for Capture and Access Applications)1 , allows the building of a new C&A application through the arrangement of the desired software components. xINCA components implement instances of capture, access or both INCA modules, and are registered at runtime under capture and access session identifiers in an INCA’s Registry. A session represents a period of interaction between xINCA components and must have a unique identifier as long as it lasts. Once sharing the same session identifier, xINCA components from different C&A applications are able to communicate and exchange information. New xINCA components can be added or removed at any moment during a session. 1

xINCA is available under GPL license at http://xinca.sf.net

Figure 2 depicts the communication flow between four C&A applications with xINCA components registered in two simultaneous sessions. Application #1 has a whiteboard component registered for both capture and access on Session #1 and an audio component registered for capture on Session #1; Application #2 has an audio component registered for access on Session #1; Application #3 has a whiteboard component registered for capture on Session #2 and for access on Session #1; finally, Application #4 has a whiteboard component registered for access on Session #2. The whiteboard and audio information produced by Application #1 is received, respectively, by Application #3 and Application #2, while the whiteboard information produced by Application #3 is received by Application #4. The information exchange is coordinated by two linked Registrys. Such a network of C&A components can assume complex structures based on INCA’s ability to establish connection among its Registrys, allowing C&A applications to operate in a peer-to-peer fashion. As can be noticed on Application #3, the same xINCA component can be registered for captured and access sessions on different Registrys.

Figure 2: Communication flow between xINCA components in two simultaneous sessions. (Boxes filled in gray color represent machines’ boundaries)

3.1. Structuring the Captured Information In order to organize the information produced by xINCA components, we defined XML schemas2 for each of them. These XML schemas allow us to structure the captured information in more meaningful and manageable pieces, and to associate standard datatypes and constraints to them. Following is the XML schema for the xINCA web browsing component. As can be noticed, there is a weblogml root element (line 03) that contains zero or more logs (line 06). The log element comprises a string content (line 09) which stores the URL of the web page visited; and id, time-offset and person-id attributes (lines 10 to 12) that provide, respectively, the log’s identifier, a milliseconds timestamp of when it was created (relative to the beginning of the session) and the username of the person who visited the web page during the capture session: 01 02 03

2

http://www.w3.org/XML/Schema

04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20



Using JAXB (Java Architecture for XML Binding)3 , a Java-XML data binding API provided by Sun Microsystems, we derived Java classes for the elements and attributes present in the XML schema of each xINCA component. Instances of those classes are the primitive datatypes manipulated by xINCA components. They are made available to C&A applications through callback methods defined in a set of programming interfaces. Each xINCA component has its own programming interface, that must be implemented by the C&A application in order to make the component available. To allow extension, we provide XINCAComponent and XINCAListener base classes from which new components and interfaces, respectively, derive. Resuming the web browsing example, the xINCA web browsing component (XWebLog) provides Log objects to the C&A application through handleVisitedURL() callbacks defined on its interface (XWebLogListener). Figure 3 presents the UML model for the xINCA web browsing component.

Figure 3: UML model for the xINCA web browsing component.

The Log objects, received through the handleVisitedURL() callbacks, agree to the class definition generated via JAXB and compose a Weblogml object, which also agrees 3

http://java.sun.com/xml/jaxb

to the JAXB-generated class definition. Once the JAXB API provides methods for marshaling a content tree of Java objects into its XML representation, the Weblogml object can be marshaled into a XML document like: 01 02 03 04 05 06

http://w3.org

The access to the captured information provided by xINCA components occurs just during the lifetime of a session. Storing such information for further access is an application’s responsibility. However, the StRES service, described in Section 4, provides data management facilities to make this task as easy as possible for C&A application developers. 3.2. Creating New Components By using the xINCA model, a C&A application developer keeps having direct access to the INCA layer, being able to use its resources or to extend xINCA by adding new components. New xINCA components can be created by implementing and encapsulating the new functionality on a component, defining its interface and writing its XML schema. The classes XINCAComponent and XINCAListener serve, respectively, as parent classes for new components and interfaces. 3.3. Some Remarks on Using INCA While using INCA, we could point some advantages/disadvantages: • The fact that INCA is specialized for the capture and access domain facilitates the design of new applications and ensures that they follow the same generic model; • By providing several facilities and associated services, like monitoring (Inspector) and management (Manager), INCA eases the development and maintenance of applications; • The publish/subscribe approach used by INCA is easy to understand and very straightforward to use, but less flexible in terms of nodes interconnections than peer-to-peer solutions like JXTA4 ; • The fact that the Registry is a centralized point that can be common to a large number of modules can lead to scalability problems; • In contrast to pieces of information exchanged between xINCA components (e.g., Logs), DataObjects are just containers for data and their contents and associated attributes must be defined by the application developer.

4. Automatizing Storage: the xINCA-StRES Approach As INCA’s original storage model only supports the storage of information on a simplified basis (name-value pairs) and presents limited retrieval functionalities, we had to extend 4

http://xml.apache.org/xmlrpc

xINCA’s application model in order to improve the storage and retrieval of the captured information. This extension was implemented by means of a service called StRES (Storing, Retrieving and Extending Service) [Baldochi et al., 2002], providing abstractions for the generation and management of information produced in live capture sessions. Those abstractions are supported by a middleware infrastructure that hides implementation details, such as those related to the back-end database used to store information. StRES comprises two main elements: a client-side StorageComponent and a server-side Transducer. When a C&A application wants to have the information produced by xINCA components on a given session captured, it instantiates a StorageComponent for that session and informs which xINCA components should be monitored. The StorageComponent then contacts a server daemon, Sessiond, that instantiates a Transducer with corresponding xINCA access components. The Transducer, listening the callbacks provided by the xINCA components interfaces, starts to receive the information produced by the capture components and arranges this information on instances of the JAXB-generated classes. By the end of the session, when no xINCA capture components are active, the captured information kept in objects instances are marshaled into corresponding XML documents that represents the contents of the just-finished capture session. Figure 4 illustrates the whole process for a given application that makes use of the audio and whiteboard components.

Figure 4: The xINCA-StRES application model.

In order to generate an XML document for a captured session, StRES uses a session XML schema in a process analogous to the one used by xINCA. This session schema groups all information produced by the xINCA components together with a contextinfo element that provides context information about the session. Following, the session XML schema used by StRES is presented. In this schema, lines 10 to 14 show references to the XML documents generated for each xINCA component. The session schema also comprises information regarding context. However, we will not discuss context information details as it is not the focus of this paper (for a complete reference, see [Arruda Jr. et al., 2003]). 01 02 03 04

05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ... 25 26

The Transducer is an abstraction that represents a central point that gathers information produced by application’s peers and generates a XML document. After generating a document, it is necessary to store, retrieve and query its contents. More than that, it is necessary to provide operations that enable querying not only a single document, but a collection of related documents. In order to provide those operations we built a distributed document repository on top of instances of a native XML database called eXist [Meier, 2003]. eXist functionality is based on hierarchical collections, similar to the storage process in a file system. Besides the facilities for creating and removing collections, storing and retrieving documents, eXist provides a query mechanism based on XPath5 . eXist also provides a XML-RPC6 API, which was modified in order to implement our distributed storage service. An entity called DocumentManager is responsible for the implementation of the storage policy and manages a group of distributed document repositories that appears to applications as a single, centralized repository, providing network transparency. Its distributed storage policy is based on the full replication of XML documents, as widely used for the storage of regular data in distributed databases [Silberschatz et al., 2001]. For further information concerning the implementation of our distributed repository, see [Baldochi et al., 2003].

5. Capture & Access Applications Built with xINCA xINCA has been used to support C&A applications in different domains. In this section, we describe two applications built with xINCA: iClass, a live lecture C&A application [Cattelan et al., 2003], and CAT, a toolkit for capturing distributed meetings [Baldochi et al., 2002]. 5.1. iClass Similar in functionality to the eClass, formerly Classroom 2000, developed at Georgia Tech [Abowd, 1999a], the iClass system7 [Cattelan et al., 2003] is able to record several 5

http://www.w3.org/TR/xpath http://xml.apache.org/xmlrpc 7 http://iclass.icmc.usp.br 6

pieces of information produced during a college lecture, including strokes and slides from an electronic whiteboard, audio from a cordless microphone used by the instructor, video from an inexpensive web camera located in a fixed position in the classroom and web pages visited using the instructor’s web browser. As a result, at the end of the lecture, a XML document integrating the different captured media is produced and automatically processed to create documents in a variety of presentation formats. The core of the iClass system consists basically of a Java applet comprising one or more xINCA capture components, according to the selected functionalities (whiteboard, audio, video and web browsing) and available devices. The information is stored using StRES with a Transducer for each in-progress session. Corresponding xINCA access components running on the server receive the information produced by the xINCA capture components running on the client applet. Using the callback mechanism, the xINCA access components deliver the received information to be stored by the Transducer. Components of a specific session (lecture) are registered under the same session identifier allowing several sessions (lectures) to happen simultaneously. To enable the review of the captured contents, the generated XML document is then processed against style sheets in a Cocoon pipeline8 , producing derivative documents in a variety of presentation formats (HTML, SMIL and XHTML+SMIL). Synchronization is made by means of timestamping (every relevant piece of information in the generated XML documents have associated time-offsets attributes). Timestamping also guides the navigation mechanism in the access interfaces with links over timelines allowing jumps between slides, visited URLs and playback points of media streams. The current implementation of these interfaces is focus of another work [Andrade, 2003]. Some screenshots of the running system are available in Figure 5.

Figure 5: The iClass system: (a) course setup interface; (b) xINCA whiteboard component; (c) lecture reviewed in SMIL. 8

http://cocoon.apache.org/2.0/

The iClass system has been used at ICMC-USP since August, 2002, and up to the writing of this paper, has captured more than 150 lectures from 8 different graduate and undergraduate courses. 5.2. CAT Besides being quite straightforward to build a C&A application using xINCA, it still requires some programming skills from the designer since she has to be able to properly instantiate components and implement interfaces. The Capture and Access Toolkit (CAT)9 [Baldochi et al., 2002] allows ordinary people, with or without programming experience, to build a C&A application by selecting the demanded functionalities in a web interface. The user also provides some basic contextual information, like the session’s title, participants, location and constraints for access control. C&A functionalities correspond to xINCA components and compose a front-end (Java applet) returned to the user as a result of the whole process. This front-end represents a C&A application that meets the user requirements and is ready to use. When a new C&A application is built using CAT, it receives a unique session identifier that is used by the instantiated xINCA components to communicate among them. A StorageComponent contacts the StRES Sessiond daemon which instantiates a Transducer for storing the information produced on that session. Such information can be further retrieved by using the contextual information provided by the user at the application’s setup phase. The entire model is similar to iClass’s: XML documents representing the session’s content are produced according to the XML schemas of xINCA components and stored at StRES data repository. CAT allows the creation of local and distributed sessions. Users can join active distributed sessions, inheriting their features and receiving proper front-ends. Figure 6 presents some screenshots of CAT in use.

Figure 6: CAT in use: (a) session setup; (b) resulting front-end.

9

http://catuaba.icmc.usp.br/cat

6. Lessons Learned In the previous sections we have presented the results of almost two years of research activities in the field of C&A applications and direct practice in the building and use of compelling prototypes. In this section we try to enumerate the main lessons we have learned during this period. 6.1. Limiting the Scope In an instrumented setting, any device, application or process that collects data from the environment can be seen as a capture entity. This is a very generic scope and can easily create conditions for confusion and overwhelming. Moreover, some C&A application developers advocate that capturing as much information as possible is the best approach arguing that they can further find some new use for the now useless captured information and, if they lost something, there is no way to move back in time and capture it. It can be true for some cases, but on the other hand it will increase application’s complexity and hinder information storage and retrieval. Therefore, when developing a C&A application, it’s a good approach to keep this trade-off in mind. Furthermore, capture occurs in a vertical basis, ranging from bare devices, like microphones and cameras, to sophisticated pieces of software, like off-the-shelf components. This feature is particularly relevant when developing middleware infrastructures and services for C&A applications. Trying to cover all levels will end in a huge, complex and difficult-to-use solution. We advocate that a layered approach is the best policy. xINCA and StRES act like this, with the first providing abstractions to the former. 6.2. Structuring the Problem When building a C&A application, it is helpful to use a divide and conquer approach. Both iClass and CAT follow Abowd et alli’s suggestion to structure the capture and access problem in four phases [Abowd et al., 1996]: • • • •

Pre-production: preparation of materials for the capture session that will be held; Live recording: capture and synchronization of the relevant data streams; Post-production: gathering and integration of the captured data streams; Access: presentation of the captured data to end-users.

It is also possible to treat the second and third phases as a single one [Richter et al., 2001] without clear separation of the data’s capture, synchronization and integration processes. 6.3. Dealing with the Design Space Another relevant aspect when building C&A applications refers to the design space. Truong et alli define five dimensions for the design of C&A applications [Truong et al., 2001]: • Who are the users during capture and access phases? It is important to identify how many users are involved, their roles in the application domain and if the records are public, private or a mix of both;

• What is actually being captured? The capture session must be defined according to the handled artifacts and the data streams produced, how important and how accurate they are; • When does capture and access happen? How often? Patterns allowing predictions must be identified, as well as the time interval between capture and access; • Where does capture and access take place? Physical location and mobility aspects must be considered during capture and access phases; • How are capture and access made? The devices and tools used in the capture and access phases also need to be identified. Those dimensions are strongly related to context-aware concepts. In fact, they are context information and manipulate application’s sensitive data. Such data are often obtained in the pre-production phase described in the previous subsection, but they can also be collected at runtime and even after it. 6.4. Managing Captured Data Once there are simultaneous media streams being captured, we need to provide convenient ways to structure, store and integrate them. Due to its widespread use and consolidated advantages, like portability, extensibility and reusability, XML has posed as a compelling choice for structuring captured information. The granularity used when structuring information will determine the level of details that can be recovered. Storage can adopt a myriad of approaches including traditional file systems, relational, XML and multimedia databases or a mix of them. StRES makes use of file system to store large media streams, like images, audio and video; and a XML database to store XML documents describing the captured sessions. For media integration, timestamping is the most common technique. Captured information is tagged with timestamps that serves to determine its position in the presentation timeline. 6.5. Concerning Access Access can be thought as retrieval and presentation of captured information. It may occurs in different time scales, ranging from milliseconds (instantaneous or synchronous access) to years (long-term access), and users can have different expectations over it. For instance, thinking about an application for the educational domain like iClass, an instructor may be interested in reviewing a summary of the course’s contents so she can prepare her next classes; a student, on the other hand, may be interested in a more detailed review due to a upcoming test. We have been successful in using style sheets to provide such flexibility. Actually, style sheets come as a natural companion to the XML structuring of captured information. The access interface has another important characteristic: it usually serves as input for reuse and extension of the captured information. 6.6. Evaluating Results While traditional techniques for evaluation, like performance, scalability, security, robustness, usability and so on, can be directly applied to C&A applications, evaluating infrastructure that support them is a much more challenging activity. Edwards et alli enumerate a set of issues about the theme, some of which we experienced by our own [Edwards et al., 2003]:

• The technical capabilities of the infrastructure will express applications features and styles, and designers must abstract from them; • The only way to evaluate the user experience afforded by the infrastructure and its features is by building applications that use it, and then evaluating them; • The prototypes built for evaluation must express the core features and objectives of the infrastructure; • Test-applications and permissible uses of infrastructure must have a limited scope.

7. Conclusions and Future Work This paper presents a component-based infrastructure aimed at reducing the construction burden of C&A applications by providing functionality abstractions and data structuring capabilities. This work is an extension of previous research, held at Georgia Tech, which exploited the architectural similarities of C&A applications. Our resulting solution comprises reusable software components that encapsulate specific functionalities of C&A applications – whiteboard, text, audio, video and web browsing. A data binding mechanism is used to structure the information produced by each component, allowing both server and client sides of the built applications to define objects that manipulate and exchange the captured information. To illustrate the utility of our approach, we have shown how it fits in with the StRES model, which composes data captured by xINCA components into session XML documents and stores them in a distributed data repository. We also detailed the use of xINCA-StRES in the implementation of two sample C&A applications. Finally, we have presented and discussed some lessons learned from our experiences. Albeit not comprising all aspects of C&A applications and infrastructures, we expect they can begin a discussion on the theme. Our future work includes the definition of metrics for evaluating the effectiveness of xINCA for building C&A applications, the adaptation of its components to industry’s component standards, audio and video streaming and improvements on handling context information. Acknowledgments. The authors would like to thank FAPESP, CNPq, CAPES, NSF and Fulbright for their support.

References Abowd, G. (1999a). Classroom 2000: An experiment with the instrumentation of a living educational environment. IBM Systems Journal, 38(4):508–530. Abowd, G. (1999b). Software engineering issues for ubiquitous computing. In Proceedings of the 21st International Conference on Software Engineering, pages 75–83. Abowd, G., Atkeson, C., Feinstein, A., Hmelo, C., Kooper, R., Long, S., Sawhney, N., and Tan, M. (1996). Teaching and learning as multimedia authoring: The classroom 2000 project. In Proceedings of the 1996 ACM Multimedia Conference, pages 187–198.

Andrade, A. (2003). Visualizac¸a˜ o e apresentac¸a˜ o de sess˜oes capturadas em ambientes de computac¸a˜ o ub´ıqua. Monografia de Qualificac¸a˜ o de Mestrado. Arruda Jr., C., Bulc˜ao Neto, R., and Pimentel, M. (2003). Open context-aware storage as a web service. In Proceedings of the 1st International Workshop on Middleware for Pervasive and Ad Hoc Computing, pages 81–87. Baldochi, L., Cattelan, R., and Pimentel, M. (2003). Building a middleware infrastructure for capture and access applications. In Anais do 30o Semin´ario Integrado de Software e Hardware, pages 299–313. Baldochi, L., Cattelan, R., Pimentel, M., and Truong, K. (2002). Automatic generation of capture and access applications. In Proceedings of the 8th Brazilian Symposium on Multimedia and Hypermedia Systems, pages 100–115. Boehm, B. and Scherlis, W. (1992). Megaprogramming. In Proceedings of the DARPA Software Technology Conference, pages 63–82. Brotherton, J., Abowd, G., and Truong, K. (1999). Supporting capture and access interfaces for informal and opportunistic meetings. Technical report GIT-GVU-99-06, GVU Center, Georgia Institute of Technology. Cattelan, R., Andrade, A., Rocha, C., and Pimentel, M. (2003). iclass: um sistema para captura e acesso de sess˜oes em ambiente educacional. Revista Eletrˆonica de Iniciac¸a˜ o Cient´ıfica, 3(1):10–28. Chiu, P., Boreczky, J., Girgensohn, A., and Kimber, D. (2001). Liteminutes: an internetbased system for multimedia meeting minutes. In Proceedings of the 2001 International World Wide Web Conference, pages 140–149. 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 the 1999 ACM Conference on Human Factors in Computing Systems, pages 338–345. Edwards, W., Bellotti, V., Dey, A., and Newman, M. (2003). Stuck in the middle: The challenges of user-centered design and evaluation for infrastructure. CHI Letters, 5(1):297–304. Garlan, D., Allen, R., and Ockerbloom, J. (1995). Architectural mismatch or why it’s hard to build systems out of existing parts. In Proceedings of the 1995 International Conference on Software Engineering, pages 179–185. Meier, W. (2003). eXist open source XML database. Available in: http://exist-db.org. Mukhopadhyay, S. and Smith, B. (1999). Passive capture and structuring of lectures. In Proceedings of the 1999 ACM Multimedia Conference, pages 477–487. Mynatt, E., T., I., Edwards, W., and LaMarca, A. (1999). Flatland: New dimensions in office whiteboards. In Proceedings of the 1999 ACM Conference on Human Factors in Computing Systems, pages 346–353. Pedersen, E., McCall, K., Moran, T., and Halasz, F. (1993). Tivoli: An electronic whiteboard for informal workgroup meetings. In Proceedings of the 1993 ACM INTERCHI Conference on Human Factors in Computing Systems, pages 391–398.

Richter, H., Abowd, G., Geyer, W., Fuchs, L., Daijavad, S., and Poltrock, S. (2001). Integrating meeting capture within a collaborative team environment. In Proceedings of the 3rd International Conference on Ubiquitous Computing, pages 123–138. Silberschatz, A., Korth, H., and Sudarshan, S. (2001). Database System Concepts. McGraw-Hill, fourth edition. Streitz, N., Geibler, J., Haake, J., and Hol, J. (1994). DOLPHIN: integrated meeting support across local and remote desktop environments and liveboards. In Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work, pages 345– 358. Truong, K. and Abowd, G. (2002). Enabling the generation, preservation & use of records and memories of everyday life. Technical report GATECH GIT-GVU-02-02, GVU Center, Georgia Institute of Technology. Truong, K., Abowd, G., and Brotherton, J. (2001). Who, what, when, where, how: Design issues of capture & access applications. In Proceedings of the 3rd International Conference on Ubiquitous Computing, pages 209–224. Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3):94– 104. Wilcox, L., Schilit, B., and Sawhney, N. (1997). Dynomite: A dynamic organized ink and audio notebook. In Proceedings of the 1997 ACM Conference on Human Factors in Computing Systems, pages 186–193.