A Workflow-based Architecture for e-Learning in ... - Semantic Scholar

4 downloads 7712 Views 255KB Size Report
full collaborative environment, online group activities are defined, tasks are ... example, consider a fluid mechanics course containing ... the architectural model in which it is based. In section ..... level of transparency regarding LOs computer.
A Workflow-based Architecture for e-Learning in the Grid Luiz Antônio M. Pereira Rubens N. Melo Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro - Brazil {lpereira,rubens}@inf.puc-rio.br Fábio André M. Porto Bruno Schulze Laboratório Nacional de Computação Científica - Brazil {fporto,schulze}@lncc.br

Abstract Effective e-learning distributed environments should promote high cooperation. Workflow techniques can certainly contribute to such effectiveness as the creation and delivery of learning contents are typically accomplished by groups of individuals executing specific and predefined sequences of activities. Reusable Learning Objects (RLOs or LOs) also play an important role in this context as learning content is broken into smaller parts to facilitate deployment and execution assignment. Additionally, some LOs may require high levels of computation as in the case of simulations in Hemodynamics in a Fluid Mechanics course. In order to cope with such an application, we envisioned a workflow-based Learning Management System (LMS) using web services as the communication infrastructure allied to the computational power of the Grid.

1. Introduction There are different techniques in collaborative learning that are proven to be efficient, not only in the cognitive domain - improving learning capacity and academic performance – but also in social and affective ones – improving group and individual selfconfidence [1]. Literature has recently evidenced the importance and effectiveness of collaborativenetworked learning environments. Some important research results can be found in [2, 3, 4, 5, 6, 7, 8 and 9]. In an e-learning environment, interaction and collaboration levels between participants and between

them and learning content range from solitary confinement [10] to full collaboration. In the solitary confinement, every task is executed by one student and the whole - or most of the - content can be downloaded to the student’s workstation and executed offline. In a full collaborative environment, online group activities are defined, tasks are accomplished by more than one participant and many electronic multimedia artifacts are often exchanged between students and between students and teachers. This case requires that participants be online in most of the time during content execution. It also requires task assignments and effective interaction coordination with execution duration control and synchronization. Despite being mostly applied to business processes coordination, workflow management systems (WfMSs) are also being used in e-learning. Besides automatically assigning the right task to the right participant in the right point in time, supporting individual planning of the work schedule and allowing students to learn at their own pace, they also provide students, as well as teachers, the ability to monitor individual and group activities. In addition to fostering the collaboration between humans, the WfMS may be responsible for coordinating the execution of tasks involving massive computation and/or data processing. In such a scenario, grid computing offers an adequate infrastructure to be integrated into the WfMS. As an example, consider a fluid mechanics course containing the simulation of a fluid path, which requires the computation of virtual particles trajectories [30]. A workflow task responsible for this computation requires resources available in a grid environment. In this the WfMS could seamlessly integrate resources from both inside and outside a grid infrastructure.

It is also important to break learning content into modules to facilitate deployment and execution assignment. The potential resulting reusability and standardization will contribute to reduce content development costs, as the modules can be re-combined to form other contents. For these reasons Reusable Learning Objects, or simply Learning Objects – RLO or LO – are being intensively studied and already applied. Some important results of these efforts can be found in [11] and [12]. Aiming LO reuse and interoperation, LO metadata (descriptions of LOs) are in their way to standardization, as per IEEE and IMS initiatives (see [13, 14]). The WWW protocols and resources compose a well-established paradigm. In our 3-tier architecture, we take advantage of the flexibility, broad application coverage and low deployment cost provided by this technology, specifically web-services, which work as the communication interface mechanism between tiers and between workflow execution engines, providing homogeneity to inevitably heterogeneous distributed operating platforms. In this paper we present TEAM, which is an architectural model conceived to derive peer-to-peer elearning supporting environments based on grid computing. In section 2 of this paper we present the characteristics of the e-learning applications that motivated us to develop TEAM having in mind a gridcomputing infrastructure. In sections 3 and 4 we present, respectively, the e-learning environment and the architectural model in which it is based. In section 5 we present an overview of the design and implementation aspects of the environment. Finally, in section 6, related and future works and the concluding remarks are presented.

2. Motivation We started our research motivated by the PGL (Partnership in Global Learning) project [16], which establishes a virtual organization for research, development and dissemination of e-learning in which secondary schools, universities, and corporations may participate. The structure of PGL includes five charter universities. Corporations, other universities and secondary schools become PGL associates. The PGL charter universities are: • The University of Florida, Gainesville, USA • Fundação Getúlio Vargas, São Paulo, Brazil • Universidade Estadual de Campinas, São Paulo, Brazil

• Pontifícia Universidade Católica do Rio de Janeiro, Brazil • Instituto Tecnologico y de Estudios Superiores de Monterrey, México. The PGL establishes a broad-based learning community to technologically accelerate economic, social and cultural advancement. The partnership implies the necessity to collect and integrate e-learning content developed or maintained by the partners. The physical distribution of the partners, which may be in any part of the world, requires the adaptation of data from one region to the other so that regional characteristics can be incorporated. The PGL project suggested us to consider using web, LO and workflow technologies in e-learning environments. Some results of our work can be found in [15] and [17], where we present a LO class meta-model and a discussion on ways to describe, use and manage LOs as also our proposal to the e-learning environment. Our research in these subjects is being conducted at the Laboratory on Database Technology – TecBD – in PUC-Rio. More recently, we studied another e-learning scenario with most of the characteristics of the PGL environment, but also requiring computationalintensive learning objects for simulation purposes; for instance, it must be possible for a student to access a learning module (a LO) capable of doing real-time computation of the path and velocity of particles in the vein system subjected to different blood pressure and viscosity conditions set by the student. It must be also possible for the module to do all the calculations required to render and show interactive 3-D images of vortex formation and other physical phenomena. In this case, computational power must be dynamically and automatically borrowed from other computers in the network. Another difference in terms of requirements is the number of partners (repositories of learning objects) that is now significantly greater than in the PGL environment. These new requirements led us to add grid technologies to the characteristics envisioned for the PGL project. This project is being conducted at LNCC – Laboratório Nacional de Computação Científica (National Laboratory of Scientific Computing) in Rio de Janeiro, Brazil. The main characteristics of the proposed environment are described in the section to follow.

3. The e-learning environment With the characteristics of the project in mind, we proposed the distributed e-learning environment. We assumed that students and teachers would execute instructional steps cooperatively, guided by a workflow management system capable of dealing transparently with distribution, autonomy and technological heterogeneity of the content repositories that are located in the partners’ sites. Content is LOoriented and is described using the IMS standard ([13] and [14]). The processing unit of our environment is called a peer. It works as a gateway to the environment and provides user’s authentication, user-environment interaction control and execution context management (more on this can be found in section 4). Each user needs to be associated to a peer (his/her home peer). A site is a logical collection of peers sharing a common learning purpose. Users have transparent access to resources within sites in which his home peer is included. A set of permissions is assigned to each user defining access restrictions to LOs published within his/her sites. Typically users have read and write privileges over LOs managed by his/her home peer. Other privileges can be given according to peers’ policies. The environment is logically divided in two scopes, external and internal, according to user roles. The external scope provides an environment for students accessing courses they are registered to attend. External users “see” the (distributed) environment as just one piece, using services, pulling and pushing artifacts from/to the environment, transparently (independently/regardless) of where they are physically located or have to be sent to. The workflow enactment services provide this transparent vision to external users, routing, retrieving and allocating resources to/from proper peers. The internal scope refers to the working context of the environment’s maintainers (e.g. technical support, application developers, database administrators) and learning content developers – the internal users. Learning content developers create new contents from scratch or by reusing existing LOs from various other peers of the site. LOs are found by replicating queries to each workflow engine, which takes control of the search process in their respective repositories, and sending results back to the originator of the query. Local search is done in the metadata base. Figure 1 illustrates the environment, showing the two possible scopes (internal and external) and views

External Users Internal Users

Peer 1 … Peer 2 Peer 4 Peer 3

Internal Users

Figure 1. The distributed e-learning environment scopes (local and global). A continuous double-lined border separates internal and external scopes. A dashed double-lined border illustrates the global view of the environment as seen by internal users. As we have already mentioned, learning content is LO-based and is structured in five hierarchical levels called section, lesson, module, unit and curriculum, according to the suggestion from [18]. Lower level LOs (sections) are called Atomic Learning Objects (ALOs) because they are the smallest contents provided with learning semantics. Despite being atomic, ALOs are composed of assessment, practice and content items, as also metadata. Higher-level LOs (from lessons to curricula) are recursively composed of references to other lower-level LOs, possibly located in other peers in the environment ([15], [17]). The LOs repositories in each peer compose a federation of weakly coupled semi-autonomous databases [19]. In our proposal, there is no functional distinction between peers, characterizing a completely distributed database system. We also assumed that the sites could adopt different data management technologies and data models. In most of the cases, the learning content is an aggregation of lightweight LOs in terms of computational power required to run them, i.e., despite of being eventually composed of big sets of bits (e.g., a high resolution image, an MS Power Point presentation with images inside, a movie file, etc.), they require to be shown or played a processing power normally

available in clients’ workstations. In some other cases, although, the amount of data or the complexity of the model is huge and/or the services that process them consume huge amount of CPU. This occurs typically in modeling, simulation and visualization in scientific applications. In these cases, Grid computing gives us a fundamental infrastructure to manage distributed computational resources. We named the environment as TEAM, which derives from Teamwork Applications Manager. TEAM is based on the architecture also called TEAM Environment Architectural (Teamwork-support Model). To avoid confusion on references to the architecture and to the environment, we added a superscript A or E to TEAM to designate the architecture and the environment, respectively (i.e. TEAMA and TEAME). In the next section we describe TEAMA.

include many computers. G1 and G2 may be considered as sites themselves. Each peer in TEAMA is a stack of three layers characterizing a 3-tier architectural model. There is at least one peer operating in one site (as illustrated by P2 and P3 of Site 1 in figure 2). Figure 3 illustrates the layout of a peer of a generic i-th site. A web browser or a .NET application, for example, may realize the user interface with the environment, which is a set of web services. The double dotted arrow represents one possible user interface realized by applications other than a web browser. Standalone applications, working as “experts”, “electronic tutors” or software agents with any other purpose, may also interface with the environment. The double dashed line represents the user interface to the environment. If the

4. The TEAM architecture User associated to site i We designed an architecture based on the classic architectural pattern for heterogeneous database integration consisting of mediator(s) and wrappers [27]. In an overall conceptual view, the architecture is composed of peers that communicate to each other using regular communication links. Peers are functionally identical but some of them run on top of a grid operating system to access resources provided by grid environment(s). Figure 2 illustrates one simple TEAMA instance formed by peers P1 thru P7. In this illustration, the system is composed of three sites (Site 1 thru Site 3) and two grids (G1, G2). P4, P6 and P7 act as interfaces of the environment to their respective grids that may

Application

Browser

JSP Web services Workflow enactment service

Site 1 Site

P2

P3

P1

Web services for data sources access P7

G1

P6 Data

Site P5

P4

Figure 2. TEAMA conceptual view

G2 Metadata

Control Info.

Figure 3. TEAM 3-tier architecture

access to the environment is done via browser, an intermediate JavaServer Pages – JSP – layer is used. The second layer is the functional core of the architecture and is composed of the workflow enactment service provided by its workflow engine [21]. Each engine manages a convenient portion of the whole workflow instance, processing rules and defining messages contents and interaction steps with the users. An enactment service is wrapped by a set of web services that form the interface with the first layer, and another set of web services to accept requests from enactment services of other peers in the network (interface 4 as defined by the Workflow Management Coalition in [21], not represented in figure 3). Besides dispatching requests to other engines, an engine may also retrieve, and possibly store, LOs directly from other repositories in the network. The workflow engines are also responsible for synchronizing and/or migrating workflow execution states [22]. Conceptually, the workflow engine layer, besides being the WfMS, also acts as a mediator [20, 19], providing to the layer above an integrated view of the distributed execution environment. The bottom layer of TEAMA provides persistency to the workflow enactment service layer. It is also wrapped by a set of web services that interfaces, via JDBC, with the possibly technologically diverse data sources. The three classes of data are the LOs metadata (XML descriptors in the IMS standard), LOs data (e.g., PPTs, DOCs, PDFs, Java applets and VRML specification files) and the workflow control information composed of workflow definitions and execution states. In the current release of TEAME, data and control info are stored using MySQL, while metadata in XML (according to the IMS standard) is managed using Apache Xindice. We are also working with other object persistence mechanisms like CAMDIES (Caching and Access Middleware for Distributed and hEterogeneous data Sources [23]), the prototype of an object-persistence and caching system, and ROSA (Repository of Objects with Semantic Access) [31]. For sites running within grid infrastructures, grid services are provided by Globus (see http://www.globus.org/) a de facto standard in operating infrastructure for grid computing. Globus provides important features such as reliable user authentication, resource access management (shared computational power dynamic allocation and deallocation) as also support for service and statistical information. Peers add to the grid environment the functionality provided by TEAM. From a user perspective, this

means that resources provided by TEAM and by the grid can be accessed transparently.

5. Design and implementation aspects Up until now, there are 31 functionalities listed in the use case view. These functionalities are grouped in the following categories: (1) elaboration of instructional content, including conception, search, development, assembly, revision, approval, registry and publication; (2) content execution modeling; (3) content execution (delivery) by students; (4) simulation, as a special case of content execution, (5) asynchronous or synchronous activities, such as mailing and meeting, and (6) content execution monitoring, such as statistics, individual or group assessment, etc. The actors’ roles are content development specialists, teachers or assistants (be human or software agents) and students. The workflow type we chose to coordinate the learning processes is the administrative one ([24, 25]), establishing pre-defined tasks’ according to predefined structures (sequence) with possible (and also predefined) routing alternatives during content execution. Workflows will be modeled using a declarative language also being designed as part of the project. This language will be able to specify the initial facts (or the initial state of the workflow process), the operations, with pre and post conditions, and restrictions for content manipulation (e.g., execution duration constraints, deadlines, etc.). The workflow engine class (meta) model is divided into two main packages: Coordination and Application. The Coordination package includes the classes that model each type of activity available in TEAME (branches, merges, forks, joins, assignment batches and environment-related activities that are specialized in the Environment package). The Application package is divided into two other packages: one comprising the classes that model execution environment-related resources or activities, such as chat-room, real-time white board and mailing, and another containing classes related to the (eleaning) business, formed by two other sub-packages: Artifacts and Entities. The Artifacts package contains classes of the LO class model [15, 17]. The other elearning entities, such as software tutors, assignments, groups, actors, roles and forms are part of the Entities package. Figure 4 illustrates the package hierarchy adopted in TEAME`s class model. The classes of the Coordination package (already mentioned) are specializations of class Activity, which

Engine

Coordination

Application

Environment

Business

Artifacts

Entities

Figure 4. TEAM workflow engine package hierarchy has the auto-association “precedes” to allow activity (instance) sequencing. Despite we do not consider transactions, or any form of activity compensation, a fundamental feature in e-learning, we added the autoassociation “compensates” to allow it. This workflow meta model may instantiate workflow models that can be represented by UML activity diagrams with swim lanes [26], for example, which are capable to easily represent the semantics of a convenient set of the patterns described in [27], as also roles and object exchanges. TEAME works in a mixed push/pull mode, meaning that it always indicates to the user what is to be done as the next step. It is up to the user to start the action. As an example, we briefly describe the steps of a typical interaction between a student and the environment. • Student logs in to the environment. • System retrieves the list of all learning programs (tracks) in which the student is enrolled. • System retrieves the execution states of all the tracks in the list. • System displays, as links, each track with respective execution state, also highlighting the ones requiring urgent actions from the student. • Student chooses a learning program from the list. • System computes next student action required. There are then five possibilities:

1. It is required to download new content: the system displays a page containing a description, instruction(s), deadline(s) and link(s) to download the necessary or recommended artifacts referring to the accomplishment of the next sub-activities in sequence. The case that more than one link is displayed in one page means that the respective activities may be executed in any sequence or even in parallel. After downloading a file, the due date for completion of the corresponding activity is automatically set as a new agenda item in the student’s agenda. These artifacts, after downloaded, can be read/executed offline. 2. It is required to execute a LO that consumes a lot of processing power or needs huge amount of data: when the link is activated a small interaction browser plug-in (e.g., an applet) is downloaded and starts communicating with the workflow enactment service that calls the necessary grid functionalities (possibly communicating with their peer(s) in the grid) in order to deploy and to coordinate distributed execution of the task. 3. It is required to upload an artifact: the system displays a page with the elements needed to upload a file from the student's workstation to the environment. TEAME will automatically direct the file, which may contain answers to questions or part of a group work, to the appropriate addressee. 4. A choice from multiple alternatives is required: the system displays a page containing a set of options and their descriptions. Each choice corresponds to a different content execution route. 5. A group chat is in course: the system displays a group web chat page for a session that is up to begin or is currently running. Orthogonally to the activities above, the student may also execute the following asynchronous activities by selecting links displayed on the upper part of each HTML page: • Access the web mail, with/out a sign that there are new mails. • Access to the personal agenda, with markings indicating new agenda items missed or scheduled for the near future. The agenda is maintained by the participant and by TEAME, which informs the due dates for the completion of the downloaded content. • Get a list of links to the participants currently online. By clicking a name in the list, the respective participant will be invited to participate in a web chat session.

• A link to the bulletin board. After the choice of a track has been made, a link to a page containing the execution state, to show the current position within the learning content execution graph, can also be displayed. Note that learning content may be executed offline, by downloading in a “save target as …” manner. TEAME automatically tracks students’ activities and is also responsible for routing artifacts to users.

6. Related and future works and concluding remarks At LNCC we are developing a grid infrastructure capable of supporting various different types of applications that can benefit from transparent access to grid resources and services. Our intention is to develop a configurable middleware system capable of integrating data and processes in conjunction with grid basic services, such as authentication, file transfer and resource allocation. Middleware functionality is encapsulated by a single web service, which is the grid interface perceived by user applications. One of these types of applications is e-Learning Management Systems (LMS). These systems support sharing e-learning content between partner institutions and remote collaboration between students and tutors. In this paper we present TEAM, which is a LMS being developed at PUC-Rio and LNCC. The system architecture is based on workflow technology and LO LOM standard. The proposed architecture comprehends peer components, corresponding to workflow engines and users home environment, which communicate in a peer-to-peer model during the execution of collaborative tasks. A set of peers forms a site, giving users a transparent view of their resources. Some sites may be part of a grid environment. In these sites, peers act as TEAM interfaces to grid resources, providing computing power to LOs requiring intensive calculations and massive storage for huge data volumes. As an example, we are developing a fluid mechanics course to be presented at LNCC, which includes LOs covering fluid path visualization. The trajectory of fluid virtual particles in a path is computed by integrating particles positions in a period of time. A simple visualization experiment involves hundreds of megabytes of data, including particles and model data, and takes minutes of computation elapsed time. Within TEAM, users, students or content developers, have at their disposal a uniform environment for developing their activities with high

level of transparency regarding LOs computer requirements. TEAM extension towards its integration with grid infrastructure is at its initial phase. We need to integrate user authentication between both environments, and develop a more refined authorization policy that will include information on user rights to access a LO. We need also to extend our current LO storage and query services. As the potential number of partners in a grid environment is considerable higher than in more conservative environments, we need to rethink how our search for LOs will be implemented. Replication is one service we are considering to include within TEAM. Finally, there are many references in the literature on different technologies for workflow management systems and e-learning. Few of them combine technologies in these two areas. It is not of our knowledge one that combines workflows and learning objects. A LO-oriented e-learning environment, called The Instructional Architect, developed at the University of Utah ([28, 29]) also helped us to understand, by practicing, how a web-based LO-based environment should operate, specifically in the assembly of a new e-learning content (re)using LOs.

References [1] Behar, P. A. , “As Novas Tecnologias da Informática e das Comunicações e o Novo Modelo Educacional”, in http://www.nuted.edu.ufrgs.br/biblioteca/public_html/4/22/, access in March/2003. [2] Sizilio, G. R. M. A., “Técnicas de Modelagem de Workflow Aplicadas à Autoria e Execução de Cursos de Ensino a Distância”. Master’s. Thesis, Universidade Federal do Rio Grande do Sul, Instituto de Informática, november/1999. [3] Lin, J., Ho, C., Sadiq, W., Orlowska, M. E., “On Workflow Enabled e-Learning Services, IEEE International Conference on Advanced Learning Technologies (ICALT’01), 2001. [4] Sizilio, G. R. M. A., Edelweiss, N., Modelo de Autoria de Cursos de Ensino a distância. Revista Brasileira de Informática na Educação, no. 10, april/2001. [5] Mangan, P., Sadiq, S., “On Building Workflow Models for Flexible Processes”, Thirteenth Australasian Database Conference (ADC2002), 2002. [6] Davis, J. et al, “Workflow Based Just-in-time Training”, 7th Australasian Document Computing Symposium, 2002.

[7] Davis, J. et al, “Using Workflow, User Modeling and Tutoring Strategies for Just-in-time Document Delivery”, Workshop on Technologies for Electronic Documents (AIEd), 2003. [8] Araujo, R. M.; Borges, M. R. S., “Extensions in workflow management systems elements for collaboration and process learning”. 7th International Conference on Computer Supported Cooperative Work in Design (CSCWD´2002), p. 375–380, 2002. [9] Santoro, F. M.; Borges, M. R. S. Santos, N., “Learning through collaborative projects: The architecture of an environment”. International Journal of Computer Applications in Technology (IJCAT), 2003. [10] Phillips, V., “Selecting an Online Course Authoring System”, Training Magazine, April, 1998. [11] Jacobsen, P. E-learning Magazine, http://www.elearningmag.com/elearning/article/articleDetail. jsp?id=5043, access in May/2002. [12] National University of Singapore, Centre for Instructional Technology, Courseware Development / EDtech, http://courseware.nus.edu.sg/Standards/rlo.asp, access in May/2002. [13] IEEE P1484.14.1/D6.4 Draft Standard for Learning Object Metadata, IEEE, March/2002. [14] IMS Global Learning Consortium, Inc., IMS Learning Resource Meta-Data Information Model, in http://www.imsglobal.org/metadata/imsmdv1p2p1/imsmd_in fov1p2p1.html [15] Pereira, L. A. M., Porto, F. A. M., Melo, R. N., “Objetos de Aprendizado Reutilizáveis: Conceitos, Padronização, Uso e Armazenamento”, ISSN 0103-9741, PUC-Rio, 2003. [16] Melo, R. N. et al, “I PGL Database Research Workshop Report”, in I PGL Database Research Workshop, April/2002. [17] Pereira, L. A. M., Melo, R. N., “Um Ambiente de Banco de Dados Para Ensino a Distância Baseado em Workflows e Objetos de Aprendizado”, ISSN 0103-9741, PUC-Rio, 2003. [18] Barrit, C., Reusable Learning Object Strategy, version 4.0, Cisco Systems, November 2001. [19] Özsu, T., Valduriez, P., Principles of Distributed Database Systems. second edition, 1999, Prentice Hall. [20] Wiederhold, G. “Mediation in the Architecture of Future Information Systems”. Computer, 26(3). 1992. [21] Workflow Management Coalition. The Workflow Reference Model, document number TC00-1003, 1995. http://www.wfmc.org/.

[22] Böszörmenyi, L.; Groiss, H.; Eisner, R., “Adding Distribution to a Workflow Management System”, in proceedings of the 10th International Workshop on Database and Expert Systems Applications (DEXA), 1999. [23] da Silva, V. F. V., Porto, F. A. M., “CAMDIES Caching and Access Middleware for Distributed and hEterogeneous data Sources”, BS final project, Pontifícia Universidade Católica do Rio de Janeiro, 2003. [24] Pereira, L. A. M., Casanova, M. A., “Sistemas de Gerência de Workflows: Características, Distribuição e Exceções”, ISSN 0103-9741, PUC-Rio, 2003. [25] Aalst, W.M.P. van der, “The Application of Petri Nets to Workflow Management”, The Journal of Circuits, Systems and Computers, volume 10, number 1, 1998. [26] OMG Unified Modeling Language Specification, Version 1.4, September/2001. [27] Aalst, W.M.P. van der et al, “Workflow Patterns”, Journal of Distributed and Parallel Databases, volume 16, 2003. [28] Instructional Architect, http://ia.usu.edu, accessed in January/2003. [29] The EduCommons Project, Utah State University, access to http://educommons.org/ in January/2002. [30] Rosenblum, L., et al.. ,Scientific, Visualization: Advances and Challenges, 1994, Academic Press. [31] Porto, F. M., Moura, A. M. C., Fernandez, A. P., Fernandez, A., Silva, F. J. C., Campos, G. H. B., Coutinho, L. “ROSA: A Data Model and Query Language for eLearning Objects”, Proceedings of the I PGL Database Research Conference, Rio de Janeiro, Brazil, April 10-11, 2003, PGLDB'2003.

Suggest Documents