Distributed Knowledge Management in Cooperative ... - CiteSeerX

sTeam: Structuring Information in Team– Distributed Knowledge Management in Cooperative Learning Environments THORSTEN HAMPEL and REINHARD KEIL-SLAWIK Computers and Society, Heinz Nixdorf Institut

Learning is a socially embedded design process. But most of today’s hypermedia systems fail to properly support the design-related and the social aspects of learning. Authoring and Web-publishing systems aim to support the authors’ design processes. Consequently, the activities of learners are confined to selecting and reading. Based on some fundamental reflections on the role of technology in learning processes, we conclude that top priority must be given to the construction of infrastructures that support cooperative learning processes if we are to properly harness the technology’s potential. We present a learner-centered, wholly Web-based approach for structuring information in teams (sTeam). In sTeam the key concept is virtual space. It draws cooperation and communication together, while at the same time embodying the common external memory of a (virtual) learning group. Hence, the focus is not on interactive systems for individual access of knowledge bases, but on the cooperative management and structuring of distributed knowledge bases. Categories and Subject Descriptors: H.5.3 [Information Interfaces and Presentation]: Group and Organization Interfaces—Computer-supported cooperative work; Web-based interaction; H.5.4 [Information Interfaces and Presentation]: Hypertext/Hypermedia —Architectures; H.1.2 [Models and Principles]: User/Machine Systems—Human factors; K.3.1 [Computers and Education]: Computer Uses in Education—Collaborative learning; K.4.3 [Computers and Society]: Organizational Impacts—Computer-supported collaborative work General Terms: Design, Human Factors Additional Key Words and Phrases: Cooperative learning, cooperative support, learnercentered approaches, sTeam (structuring information in a team), Web-based learning and teaching

1. INTRODUCTION Mainstream discussions on the role of technology in teaching and learning center on two basic paradigms. Hypermedia systems aim to support individual

Authors’ address: Computers and Society, Heinz Nixdorf Institut, Fürstenallee 11, Paderborn, 33102, Germany; email: [email protected]; [email protected]. Permission to make digital / hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and / or a fee. © 2001 ACM 1531-4278/01/0600 –0003 $5.00 ACM Journal of Educational Resources in Computing, Vol., 1, No. 2, Summer 2001, Article #3, 27 pages.

2

•

T. Hampel and R. Keil-Slawik

learning processes, with special emphasis on new didactic qualities, which are attributed to the interactive combination of various media types such as text, graphics, audio, video, and so on. The second paradigm embodies the notion of “delivering education,” that is, networking technology used to distribute and access study materials as well as establish communication channels between students and teachers. Although the idea of utilizing net services has strong collaborative connotations, the main argument in its favor is the temporal and spatial independence it offers and, consequently, independence from close collaboration with others. Students can now learn individually at their own pace and at their own chosen location. However, many studies evaluating the role of technology in learning yield conflicting results, indicating that there is no general, clear-cut connection between the effort required to produce high-quality multimedia educational material and improvement in the learning process. The problem is attributing certain benefits to a single variable—say, the specific technology used. The results are mostly a combination of different variables such as didactic style, educational strategy, technology deployment, appropriate selection of content, and the personal qualities of teachers and students [Hesse et al. 1998; Keil-Slawik et al. 1996]. Thus, the widely accepted idea that learning can be improved by individualizing learning processes using hypermedia and networking technology is not generally borne out by scientific research. Our approach is based on the general assumption that technology can only solve technological problems, and that didactic problems require didactic solutions. Teaching activities cannot be replaced by technology, and embedding technology in teaching and learning must be studied carefully. To design a learning-supportive infrastructure, it is necessary to identify which problems in the learning process are technological and which are the main technological solutions to the problems. In the following sections, we briefly sketch a theoretical framework enabling us to identify the role of technology in learning. Building on this, we show that the design of hypermedia learning environments has so far been author-centered, in which content and content structures are defined by the teachers and in which learners assume a largely passive role. With sTeam, we offer an alternative approach, featuring a consistently learner-centered perspective. The sTeam approach focuses on the collaborative exploration and maintenance of a complex hypermedia knowledge base by students—a concept we call self-administration.

2. MEDIA AS EXTERNAL MEMORY Theoretical frameworks fail to provide a sufficient basis for the design of cooperative learning-supportive infrastructures. They do, however, help to define a general strategy for their development, especially when the overall development cycle spans several years. Such a framework must provide ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

sTeam: Structuring Information

I

•

3

ARRANGE

CREATE

primary media functions TRANSMIT LINK

II didactic concepts

secondary media functions

III adaptive systems tertiary media functions Fig. 1.

Media functions.

some guidance on how to specify goals, set priorities and formulate hypotheses to be validated in actual use, as well as help to distinguish between technical and nontechnical problems and analyze how they are interconnected. Two general ideas might be useful to briefly illustrate the approach we have adopted. The first is based on an argument put forward by Gibson [1979]. Gibson came to the conclusion that it is human information processing that allows us to distinguish between what is imagined and what is real. When we view a phenomenon from different perspectives, or when we modify what we perceive and interpret the changes, we gather information through our bodily activities. We cannot, as Gibson claims, gather information about a purely imagined phenomenon because the result of any purely mental modification or change in perspective is completely controlled by our minds. Thus, no difference between what is imagined and what is real can be detected. To carry this argument a step further, we could say that nothing can be learned about a certain phenomenon if we are unable to generate and interpret different patterns of perceivable responses. Learning, then, requires feedback through personal observation or social response; it is generally a combination of both. Hence, in order to gain information about a certain phenomenon, we must create an environment that can be perceived and manipulated (i.e., an experimental setting or symbolic description). The second idea draws on the fact that the biological (genetic) basis for cognition has not changed for at least the last several thousand years of human evolution. Our cultural accomplishments do not reflect an improvement in our biological capacity for intelligent behavior, but rather our ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

4

•


ability to create ever better means of expression to support productive thinking and to create a socio-symbolic universe that enables us to base our learning activities on the ideas and accomplishments of our ancestors [Elias 1988]. In terms of both the evolution of culture in general and the evolution of the individual’s mental capacity, it can be said that learning is an inherently social activity based on the use of physical artifacts, semiotic artifacts—such as drawings, calculations, and verbal descriptions—formal notations also play a crucial role. Of course, symbolic artifacts are of paramount importance: “...the use of signs appears to be indispensable to the use of reason.” [Polya 1971, p.135]. However, the use of symbolic artifacts requires technology, so the crucial question is: Which specific technological functions adequately support learning? To answer this question, we begin by distinguishing between the terms memory and storage. Human memory is dynamic, irreversible (one cannot deliberately forget or erase something), selective, and subject to individual experiences and views. A storage is a repository generally used for depositing physical items for later retrieval. The storing and retrieving functions should not modify the items being stored (authenticity). Human memory, then, processes information, whereas computers store data. Apart from the human brain and its memory functions, we talk of external memories in cases where the items in storage are continuously interpreted and modified as a result of some individual or socio-intellectual process. A university library, for instance, is not just a storage (a repository for books and magazines), but a living body of knowledge available to a scientific community and continuously modified to reflect the current state of knowledge. To this extent, a library serves as an external memory. The same holds for course material in an educational context. During a course, students learn to explore the material, associating meaning with formulas and data, to assess and discuss the relevance of examples and to add their own material (which may be individually produced, copied from some other source, or the result of collaborative work). The way they use external memory reflects their current state of knowledge, changing as they become more knowledgeable. By the end of a course, participants will have acquired their own personal understanding, but they will also share a common understanding of the material, commensurate with their active involvement in its collaborative use and redesign; a somewhat arbitrary repository of semiotic artifacts has thus evolved into an external memory. Items in a storage can be created, moved, arranged, or deleted to express people’s understanding and support their mental activities. However, the actual physical state of an external memory can only embody this knowledge to a limited extent, since it fails to provide a detailed account of the knowledge’s evolution and why it evolved in that particular way. This holds for textbooks, formal notation, and software. By way of conclusion, it may be said that technology supports learning processes by providing appropriate means to create and maintain a storage that functions as an external memory. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

5

3. ENHANCING LEARNING VS. REPLACING TEACHING The concept of external memories constitutes an initial attempt to separate the technical from the human. However, to design suitable external memories, we have to go a step further by distinguishing three classes of media functions and showing their implications for the interplay of technology and learning. The proposed classification primarily reflects the type of knowledge required to develop corresponding learning environments. Such a differentiation allows priorities to be set and development strategies to be formulated, depending on other use factors. 3.1 Primary Media Functions Media are generally viewed in terms of communication, based in most cases on the classical transmitter/receiver or producer/ consumer model. The integration of different media types such as text, image, and sound (multimedia) made possible by computers, together with the fusion of transmission channels and services (the Internet), means that we must extend the concept of media. Media are no longer simply a means of communication; they are—and have always been— both a means of expression/ cognition and of organization. Without media, our cultural achievements are unthinkable. Complex social processes based on the division of labor are just as reliant on media as science and education. Media, for their part, require technology to create an objective, mostly symbolic world. To determine the potential and possibilities offered by the new media, we must first remind ourselves of what constitutes, in technical terms, the benefits they provide. Here, four basic categories can be defined for technical functions, whose implementation can help better support cognitive processes: Creating: Media serve to create a perceptual space, allowing conception and reality to be correlated by action and the relevant conclusions to be drawn. Scientific instruments, experimental apparatus, models, and simulation programs are just as much instances of artifacts that perform this function as are symbolic descriptions, diagrams, images, formalisms, and visualizations of large datasets. Arranging: To attain new insights, it is necessary to correlate different documents. Problem solving and learning invariably involve identifying differences and concurrences, combining different types of descriptions and representations or weighing statements from different sources against one another. To support these processes, the artifacts to be correlated must be brought into the field of perception, simultaneously if possible. Here, logical connections should be represented, if possible, by spatial connections as well, to enable them to be swiftly identified and processed. Transmitting: Cultural learning achievements are social processes. Reducing learning to the individual processing of a document, for example, means failing to appreciate that this document is already being used, assessed, and passed on in a specific social teaching/learning situation. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

6

•


Furthermore, contemporary university learning situations are often such that course materials are processed, exchanged, or compared in groups. In such a context, learning is a disparate process taking place in a variety of forms in different places and at different times. The required material must be uniformly available at all learning locations, i.e., it must be transmitted there. Linking: Arrangements embodying an important connection should be preserved after the act of arranging, so that they do not need to be regenerated at a later point in order to continue being worked on. Suitable links, for example, enable users– ideally in a single step—to refer to all relevant documents for the respective meaning context. Equally important here is the fact that the meaning context may cover only part of the material and documents. For instance, an author may refer to the works of other authors by citing or paraphrasing them, linking together certain statements by these authors to form a new line of reasoning. The relevant statements, quotes, and paraphrases are fused with the author’s own statements to form a new physically coherent textual entity, e.g., an anthology or an article. Besides a physical coupling of this sort, such linking can also be done by grouping, i.e., the physically unconnected objects are brought together at a specific place and, if necessary, structured, i.e., arranged according to one or more criteria. And it is also possible, instead of linking the artifacts themselves, to create references to them and then link them physically via these references (hypertext). The rationalization potential of the new media lies in the implementation and integration of these primary media functions, the concern being to achieve more effective handling of the physical rtefacts in terms of the four basic areas of functionality. Here, the new media offer a wealth of new forms for effectively generating, transmitting, arranging, and linking semiotic artifacts, ranging from the integration of different types of media to net-based services and search facilities. To this extent, learning-supportive infrastructures, like the Paderborn DISCO (Digital Infrastructure for Computer-Supported Cooperative Learning [Keil-Slawik 1999]), make use of all materials at any location where learning takes place. 3.2 Secondary Media Functions Primary functions are essential for creating and maintaining external memories, to the extent of allowing students and teachers to create and arrange any sort of educational material in any way, without enforcing specific teaching methods or didactic concepts. This allows a high degree of flexibility, but it may not provide adequate support. A textbook or CD-ROM is not just an arbitrary physical arrangement of different media types such as text, graphics, or video; it constitutes specifically selected and designed material, taking the form of, say, introductions, examples, exercises, or ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

7

suggestions for further reading. The arrangement and selection of the material follows didactic principles, and in many cases it may be useful to suggest a certain sequence of learning activities (select and arrange materials) or guide learners through the material along a prespecified path. We call technological functions that support learners or enforce specific sequences of activities according to underlying didactic principles, secondary media functions of the external memory, because these functions embody specific (empirical) knowledge about learning processes and their context. We group these functions into three categories: Structure: Providing operations to create and maintain specific arrangements of tools and documents such as learning units, which may be defined as a compound document containing a specification of the learning goal, an introductory text, some examples, a set of interactive tests, and further references. Instruct: Developing means for instructional design, especially tutoring and feedback mechanisms for self-guided learning. Cooperate: Creating environments that support specific methods for cooperative learning and problem solving, such as brainstorming, role games, or future workshops. The implementation of secondary functions requires careful analysis of the specific knowledge to be taught, and should be based on theoretical principles and empirical investigations to justify the additional resources needed to design the tools and materials. Since secondary functions are tied to a specific didactic approach, they have to be reimplemented for different learning environments. 3.3 Tertiary Media Functions There are instances of attempts to implement tertiary functions in the literature, although such approaches have not yet yielded very promising results. Tertiary functions embody generic knowledge of problem solving and human understanding. The idea is to build smart or intelligent systems that are capable of understanding users or learning from their behavior, enabling the systems to adapt to the learners’ individual needs. Tertiary functions are as follows: Adaptation: Designing mechanisms that analyze the learner’s input and change the system’s behavior in accordance with this ongoing analysis. Intelligent tutoring: Developing systems that are able to cope with unanticipated or wrong input by users in an intelligent manner. The system must embody models of the learner’s knowledge, the problemsolving knowledge of domain experts, and knowledge about teachers’ intervention strategies. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

8

•


Natural-language processing: Enhancing the system’s ability to “understand” the input of learners by incorporating natural-language processing mechanisms. Tertiary functions represent the most ambitious goals in designing learning environments, and it is doubtful that this approach will ever lead to practical solutions. This is why we made it our highest priority to implement the primary media functions, which allow collaborative solutions. Secondary functions are often regarded as playing a key role for a new generation of learning environments, such as computer-based training (CBT) or computer-aided instruction (CAI). However, implementing secondary functions generally culminates in supporting individual learning and thus often runs counter to attempts to establish infrastructures that support collaborative learning. 3.4 Implicit Knowledge and Formal Systems In a formal system each operation performed by a machine is determined by the form and arrangement of symbols in the input sequence—the machine storage being independent of what these symbols represent. Every software system, then, embodies a syntactic machine. In teaching and learning, however, signs and symbols have to be interpreted in terms of personal experience and knowledge, individual preferences and interests. The respective consequences become apparent through human actions. This sort of knowledge is therefore often described as tacit or implicit. Implementing different classes of media functions forces us to make more and more tacit/implicit knowledge explicit. In the case of tertiary media functions, and to some extent secondary media functions, the kind of knowledge involved is typically that possessed by teachers. The learner can proceed individually because the teacher’s functions are increasingly replaced by a machine that the learner can use anywhere, any time. Incidentally, the same is true of traditional print media. The closer we come to the technical implementation of tertiary media functions, the greater the risk we run of trying to build a technical solution for a nontechnical problem (a hugely expensive undertaking). Another factor here is the huge effort required to implement tertiary media functions, which has meant that it has so far hardly been worthwhile developing them, or only in a very few special cases. It can generally be said that the primary media functions have the greatest potential for deploying digital media in learning processes. And they do not tie either learners or teachers to a specific didactic approach (process), which means that they provide the best foundation for constructivist approaches to learning. They also form the basis on which the secondary media functions can begin to unfold. However, these basic theoretical considerations are not sufficient to design learning-supportive infrastructures. The specific requirements of the application domain and empirical findings must be taken into account. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

9

4. THE PADERBORN APPROACH Based on the above considerations, in 1994 we began building learningsupportive infrastructures. The initial focus was on implementing the primary media functions, ensuring the availability of all materials at all times and at every learning location. This involved creating electronic seminar rooms and lecture halls and networking them, as well as making the entire course material available via the WWW. With regard to the primary media functions, a key aspect of accompanying evaluations was identifying media discontinuities under everyday usage conditions and developing corresponding solutions to eliminate them [Brennecke and Keil-Slawik 1995]. Media discontinuities occur when various materials are not available or cannot be combined as the situation requires. They occur at all levels of media usage, and can have technical, spatial, pedagogic, and conceptual causes. For instance, the WWW does not allow documents and reference structures to be administered separately. This means that, unless they have write access to the documents published in the Web, learners are unable to create their own reference structures. By using Hyperwave, we were able to make significant progress here (see Brennecke et al. [1997]). Our distributed document-management approach is a marked improvement on classical Web publishing, but it still has its shortcomings: the volume of the teaching material and the access authorizations are determined by the teachers. This is basically due to the concept of authoring systems and Web-based publishing. Authoring systems consist of an author and a reader component. The former is used to create and modify content and references, the latter to read or browse through content following predefined references (hyperlinks) and indexes. To maintain the integrity and authenticity of the material, it cannot be modified with the reading tool. This means, however, that learners only have reading access to material created in this way, though various mechanisms are available to them for selecting potential presentation results: following up a reference; starting an animation sequence; selecting an instruction sequence by ticking multiple-choice questions; specifying a simulation run by entering marginal conditions or initial values; selecting predefined presentation sequences (guided tours). This confinement to reading selection or selective reading gives the readers only a very limited advantage, but makes a great deal of additional effort for the authors. This effort consists in anticipating all possible interaction processes, implementing them properly, and designing the material in such a way that it remains plausible and comprehensible, ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

10

•


whatever read mode is chosen. The additional value for the readers is very limited here, because as long as they can only follow up references, they remain in a passive, receptive role and obtain no advantage over classical print media. Even printed course material or a textbook may contain a variety of references and is not normally read sequentially. On the other hand, in terms of reading, there are further disadvantages due to the much poorer readability of the text on the computer screen, since the text is cut up into tiny snippets of information because of the screen’s limited size. This involves more effort in navigation and greater technological overhead (a reading device). The advantages of using digital media, e.g., integration of database and search functions, are not directly connected to the hypermedia concept and can be implemented independently of it. In an authorcentered learning environment, the learner’s scope is invariably confined to the content and access structures laid down by the teacher. The extent to which learners can arrange and structure the material to suit their own needs is therefore limited. It is, of course, possible in principle to use all the material freely available on the Net in different contexts. But to effectively utilize and manage such material, activities like copying, transforming, or indexing are needed, which can soon involve a great deal of effort. Also, such individually structured knowledge bases are an obstacle to cooperative processing and generation. The learners are then not able to establish their own learning environment, in which they could, for example, link documents from different courses or even different universities to match their own learning path and knowledge level. However, this means that essential elements are missing: viewing learning as a social process in which different materials are exchanged as needed by people with occasionally differing roles, evaluated individually as well as cooperatively, rearranged and relinked. The social external memory degenerates into a one-way media street. To appreciate the real advantage of hypermedia, then, the concept must be divorced from the authoring systems and traced back to Ted Nelson’s original definition. He coined the term “hypertext” back in 1965, defining it as “nonsequential writing” [Nelson 1987], not as “nonsequential reading.” In fact, the hypertext idea only develops its real additional value in media terms when it is implemented as a nonsequential writing concept—writing in this context always means actively working on material, annotating it, and rearranging and supplementing it. This applies to the first design of a hypertext machine as a personal memory extension (Memex) by Vannevar Bush in 1945, as well as to new forms of literary discourse using annotations and to Nelson’s vision of a global networked literature system (Xanadu), in which everyone can integrate their own documents and attach private references to other people’s documents. Ultimately, this view also opens up the prospect of learners structuring the material themselves. However, to be able to implement this in technical terms and avoid any media discontinuities, it is necessary to combine the concept of hypermedia-based document management with event-driven ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

11

techniques that have been employed in the context of adventure games (MUDs and MOOs). By using the sTeam approach, we aim to avoid the discontinuities in the use of media and the shortcomings like the ones mentioned above. The sTeam approach is a sort of learning lab for studying new forms of distributed knowledge organization, implementing them to meet everyday practical requirements and providing the necessary tools for this purpose on an open-source basis. The sTeam is not a finished product in this respect, i.e., a learning tool, but is itself the object of a learning process that needs to be further developed cooperatively. 5.

STEAM:

OUR PHILOSOPHY

In its basic sense, distributed knowledge organization entails the cooperative generation, management, and maintenance of artifacts embodying knowledge. Artifacts represented by documents, graphics, notes, and comments, and their linking by learners, form the basis of any method for supporting learning processes using suitable environments and tools. The temporal component of an interaction or communication between learners can be seen as another essential factor, as well as the spatial differentiation of cooperation. Existing environments and approaches can in most cases be assigned either to the class of synchronous, i.e., temporally concurrent, systems (supporting one session), or to the class of asynchronous systems centering on a common location [Ellis et al. 1991]. The sTeam approach focuses on integrating the learners’ temporal and spatial differentiations. Asynchronous mechanisms for handling multimedia learning components or hypertexts, such as those familiar from document management, are combined with strongly synchronous approaches from the area of session support. Such a synthesis allows new, less familiar, hybrid forms of asynchronous and synchronous cooperation between learners. 5.1 MUDs and MOOs—Interactive Learning Environments Cooperation-supporting environments such as Multi-User Object-Oriented Environments (MOOs) and Multi-User Domains (MUDs) [Curtis 1992] are basic architectures that have proved well suited for bringing learners together in common learning and working areas. Although not widely known, these virtual environments (originally conceived as Net-based adventure and fantasy worlds) developed into independent interaction and communication forms. At the same time, MUDs, and in particular their object-oriented variants, MOOs, have their own highly autonomous architectural design, which served as a model for large sections of the sTeam architecture. When Trubshaw and Bartle developed the first MUD at the University of Essex, England (henceforth the Essex MUD) [Bartle 1990], the emphasis was on the MUD’s character as a game. For many users of the subsequent early MUDs, however, they evolved more and more into social meeting places, the so-called social MUDs. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

12

•


As early as 1980, the user group, initially confined to students at the University of Essex, was extended to include external players linked via modems. This was achieved by connecting, on an initial trial basis, Essex University to the American ArpaNet, the precursor of the Internet. It is an interesting fact, then, that MUDs, along with email and FTP, can be seen as the first services or users of the Internet. They are among the pioneers of new forms of human interaction via the new medium, the Internet. In the years since, a multitude of different MUDs and their specialized variants have evolved [Reid 1994]. Special mention of the MOO should be made here [Curtis 1992], developed in the late 1980s as a strictly objectoriented version of the MUD. Unlike MUDs, MOOs are seen primarily as social MUDs, i.e., virtual online meeting places for users. Their architecture is database-oriented and based on interacting objects communicating about specific events. In addition to the special technical features of MUDs, there are entire series of conceptual and metaphorical characteristics that have contributed to the wide success of the MUD idea. These include the symbolic representation of MUD players/users in the form of avatars or, for instance, the consistent application of a room metaphor. In his definition of a MUD, Curtis primarily emphasizes its basic technical characteristic, i.e., as a software system that establishes network connections between different users and offers access to a common database. At the same time, though, he stresses the importance of a common, electronically represented, place1 Users move within a virtual world and “see” and interact with objects that are placed within virtual rooms. Rooms are connected via “exits” which allow navigation between rooms. Apart from the informal synchronous communication between users, it is these interactions between persons and objects and between different persons that constitute the truly new quality of MUDs, compared with classical electronic media like conventional chatting—similar features were also mentioned by Bartle in his definition of a MUD. For him, the MUD is a system of interaction between players and artifacts and between players and other players (“ ’interactive’ emphasizes the requirement that players be able to do things with and to each other.” [Bartle 1990]. Rheingold [1993], who coined the term “virtual community,” extends the idea of a common online meeting place for users. In their article, Kelly and Rheingold [1993] examine “serious” MUD applications and existing virtual communities. They give a brief overview of different MUDs and MOOs, and

1 “A MUD is a software program that accepts ‘connections’ from multiple users across some kind of network (e.g., telephone lines or the Internet) and provides to each user access to a shared database of ‘rooms’, ‘exits’, and other objects. Each user browses and manipulates this database from ‘inside’ one of those rooms, seeing only those objects that are in the same room and moving from room to room mostly via the exits that connect them. A MUD, therefore, is a kind of virtual reality, an electronically-represented ‘place’ that users can visit.” [Curtis 1992].

ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

13

also emphasize the importance of the common meeting place as the basis of all virtual communities.2 More recent work in the area of MUDs and MOOs, like that of Mynatt et al., depart from the idea of the MUD as a role-playing environment and emphasize the key characteristics of a persistent virtual world in which theme-oriented interactions take place between users—interactions that may also relate to the domain of training and further education3MUD is becoming socially acceptable, and is seen by a whole series of authors as a serious application for supporting cooperation. To give a complete overview of the application domains of MUDs and MOOs would be beyond the scope of this article. By the early 1990s, there was already a surprisingly large number of different MUDs, according to Bartle’s MUD Report, which undertook an analysis of existing MUDs [Bartle 1990]. MUDs and MOOs are used in a wide range of application domains [Evard 1993; Mynatt et al. 1997]. An analysis of existing approaches reveals three fundamental application sectors. First, there is the classical application area of MUDs and MOOs as a communication and cooperation platform. Here, the virtual environment is not used to directly convey course content. Represented by avatars, learners and teachers meet at specified places within the MUD’s room-based structure in order to communicate on a theme-oriented basis. Of particular importance in this connection is the relatively informal communication within the MUDs and MOOs in which students participate via their avatars. This communication may not necessarily be confined to textoriented chatting. In a whole range of cases, forms of audio and video communication are also incorporated, turning the MUD or MOO into a so-called media space. In terms of organization and technology, MUDs and MOOs can be easily integrated into an existing learning situation. Apart from an Internet connection, they require no special access tools and are easy to operate. At most of the application sites studied, the Lambda MOO system is used as the technical platform. It offers good persistency characteristics and, thanks to its database architecture, requires little administration effort. A whole series of successful attempts to use MUDs and MOOs in teaching belong to this first group. The number of such MUDs and MOOs is relatively high. An extensive list of MOOs for learning purposes is kept at the University of California at Berkeley.4

2 “Well, if 100 other students were to show up in the same virtual “place”, you could have a party, devise pranks, do some role-playing, scheme, even build a better world. All at the same time. The only thing you’d need is a place to meet.” Kelly and Rheingold [1993], 3 “MUDs are computationally-based environments that provide access to a persistent, online ‘world.’ MUDs allow users to establish and describe their worlds and interact or collaborate according to preestablished themes such as combat, education or professional activities.” Mynatt et al. [1997]. 4 see ,http://cinemaspace.berkeley.edu/˜rachel/moolist/edu.html..


14

•


The second, relatively small, group of potential applications makes didactic use of MUDs and MOOs for directly imparting course content. Course material for this purpose is deposited within a MUD or, in a reflection of MUD’s role-playing roots, knowledge is imparted in the form of tasks to be solved. As in an adventure game, learners are given an incentive to solve the subtasks by the avatar’s obtaining experience points or enhanced social status. The tasks are mostly not the sort that can be solved by one player/learner alone; cooperation between learners and between learners and teachers is strongly encouraged. A number of environments also contain especially designed teaching tools and illustrative objects to help impart course content more graphically or to enable learners to interact with the artifacts of the virtual learning environment. Examples from the second group are Hill and Slator’s [2000] Geology Explorer, which helps geology students to analyze geological formations and types of rock, and the ProgrammingLand MOO, an environment for learning programming languages. The third group using MUDs and MOOs for teaching purposes sees them ultimately as virtual learning and working environments designed to enable users to work actively on and with material. In keeping with the sTeam idea, they are seen as providing primary media functions, and are a repository for jointly used material. Unfortunately, there are no, or only very few, examples of successfully integrated MUDs and MOOs in teaching in this context. The Pueblo system is one of the few examples [O’Day 1996]. Pueblo is a MOO-based virtual learning community for students and teachers operated cooperatively by the Longview Elementary School, Phoenix, Arizona, and Xerox PARC. As already indicated, the sTeam system borrows a number of conceptual and architectural ideas from MUDs and MOOs. The original idea was to link a conventional MUD to a document management system, i.e., provide primary media functions within MUD. In subsequent development steps, sTeam evolved more and more into an independent architectural solution, although one still largely shaped by experience gained from the MUD and MOO domains. 5.2 sTeam: A MUD- and Web-Based Cooperative Learning Environment Rooms are a key concept in all these approaches [Henderson and Card 1985]. They are structured entities that can be linked dynamically. The room structure enables positions to be defined for objects, representing people, documents, tools and services, that allow a knowledge space to be cooperatively established and, at the same time, responsibilities, rights, or competences to be mapped structurally. To this extent, rooms constitute a key metaphor for virtual learning communities. Irrespective of the chosen representation of the room structure (two-dimensional, three-dimensional, as a tree structure, or a textual description), the room is viewed as the meeting place, “playground,” and “lifeline” of a virtual community. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

15

The sTeam system combines the idea of a room-based virtual world with the basic functionalities of document management. Rooms function not only as social meeting places and centers of a virtual learning community, but also as a collective external memory, providing the primary media functions as a basis for cooperative learning. In the various virtual rooms, it is now possible to observe which cooperative partner is currently dealing with which documents and knowledge sources, provided this is explicitly permitted by the students. One use of such mechanisms is to create new forms of cooperative learning. During a seminar, for example, all the participants can be assembled in specific rooms and a “virtual ballot” conducted to evaluate specific documents. Another application is to set up a shared whiteboard that allows not only the students currently present in the room, but also those hooked up externally, to jointly process objects or to transfer elements of their desktops, graphics, references, or entire documents to the synchronous work area, i.e., a work area that is simultaneously visible to all participants at a virtual location, using drag and drop functions. For instance, dragging a reference from a browser directly generates a link object in the room corresponding to the whiteboard. In the following section we focus on the technical architecture of the sTeam environment; for a description of typical learning scenarios of the sTeam system, refer to Hampel [2000]. 6. TECHNICAL ARCHITECTURE To support the primary media functions within a cooperative learning environment, a specific Web-based architecture is needed. It proved possible to continuously develop such an architecture further through a series of different prototypes, culminating in an open, modern platform. The architecture reflects the current status in the development of the Paderborn sTeam, and pursues a rigorous open-source approach. The sTeam architecture (see Figure 2) consists of the sTeam server, an external Web server connected to the sTeam server, and various clients. A standard Internet browser can also be used as an sTeam client to access most of the asynchronous functionality. Specific functionalities such as synchronous communication (chatting) or cooperative applications are provided via Java clients. In early sTeam prototypes, the Web server was integrated into the sTeam server proper. In the latest version, an external Web server was coupled with the sTeam server. Here, the sTeam server acts as a kind of virtual file system for the Web server. This type of architecture allows Web accesses (requests) to be handled by the Web server. The freely available Roxen Web server5 currently in use is a modern Web server supporting all essential features, e.g., different security facilities, Javascript, and server-site Java. The sTeam server proper comprises the sTeam core server, a number of extension packages, and an external SQL database used as an object 5

cf., ,http://www.roxen.com.. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

16

•


clients

LPC

modules Roxen

Web-interface

COAL COAL

sTeam core

database Fig. 2.

The sTeam architecture.

repository. Extension packages can be easily integrated into the sTeam server. For instance, there is currently an initial extension package (sTeam module) providing a Web front-end for access to sTeam functionality via a standard Internet browser. The architecture of the actual sTeam server was tailored to the need to support cooperative processes. Human interaction in virtual space, awareness mechanisms, and, in particular, cooperative use of teaching material, such as documents or arbitrary objects, calls for a specialized management of objects, users, and various events. In terms of its realization, the sTeam server is based on an implementation of the classes and object structures in the interpreter language, LPC. LPC is a C-style interpreted programming language developed by Lars Pensjö for LP-MUD. The freely available (subject to GNU Public Licence, GPL) and widely used LPC interpreter, PIKE7 serves as the runtime environment. Besides good performance, PIKE features a broad code basis and a large number of existing libraries that can be implemented in the C programming language—for instance, the PIKE database interface for coupling SQL databases and an HTML parser8 were used. The sTeam system is completely object-oriented. The sTeam environment maps both users and documents internally (and also rooms as specific variants of objects). These have particular attributes or content, e.g., the document types. Interaction between objects takes place via mutual method calls or events. This is an extension of the well-known concepts from the 7 8

,http://pike-community.org/.. ,http://www.gingerall.com..



object

•

17

container User

group

link Fig. 3.

document

room

The sTeam class structure.

MUD family, or more specifically their object-oriented relations, the MOOs (MUD Object-Oriented relations). 6.1 sTeam Class Structure To illustrate the specific features of the server architecture, the classes and object structure are shown in simplified form, along with their basic object types, e.g., “object,” “container,” “user,” “group,” and “document” (Figure 3). In a second step, the event system as well as the sTeam server’s access rights model are sketched. The sTeam class structure consists of the basic components “object,” “container,” “user,” “group,” and “document.” All classes are derived from the basic class “object.” It is therefore imperative that, to maintain elementary system security, an sTeam object be derived within the environment of “object.” Object: An “object” constitutes the basis of every element of the sTeam environment. Essential features here are object persistence, an unequivocal Object ID, available methods, events that can be linked with objects, and a number of possible attributes (which can be specified or reregistered when instantiating objects). Objects are persistently administered in the sTeam database. For the server, unequivocal object ID serves as a primary key to definite identification. Objects within the sTeam environment have an unambiguous environment, which we henceforth simply term the “environment.” This is intended to create an object structure, every object existing at precisely one point within the sTeam system. (Such a structure forms a tree and has its root in the sTeam root room.) Container: One of the simplest variants (derivations) of an object is doubtless the sTeam container. It is used for the logical encapsulation of objects. In accordance with the object-oriented philosophy, a container can hold other objects. To this extent the internal object representation is implemented analogously to a semantic grouping of materials (documents, graphics) in containers. Similarly, a user’s rucksack, in which materials can be carried around and exchanged with other users, is realized by the object representation as a container. The fairly universal characteristics of ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

18

•


containers within the sTeam environment are direct results of this feature, e.g., the grouping of arbitrary objects. This basic MUD feature enables a room to be implemented as a specific variant of a container. A room groups materials, documents, graphics, and tools, i.e., all sTeam objects as well as users. The only other features are special methods for communicating within the room. Connections between rooms are implemented as sTeam objects, for whose use special rights are needed. Using an exit or entering another room, then, presupposes the authorization to use “execute” for a room object. User: There exists precisely one user object for each user within the sTeam environment. This user object is located within a specific room, depending on the “position” of the user. Communication between the real user, who has logged on to the sTeam system via a client, and the user object is implemented by means of a communication object attached to the user object. (Since users can be connected to the sTeam system via several clients simultaneously, they can be in possession of several communication objects at the same time.) As can be seen in the class structure, the user object is inherited from the class container. It extends the class container by adding different attributes and methods. And, as a feature derived from the container’s class, it may also contain different objects. This means that users’ rucksacks (their “inventories”) enable them to take “objects” (to use MUD terminology) with them. Examples of special user attributes are a user’s name, access password, and so on. These are administered as attributes in the corresponding user object. Like in MUDs, the chosen user name should be unequivocal, to address the user object within the sTeam environment. Communication between users within a room is realized by means of events. As in the case of a MUD, a user’s chat message (in a MUD, the “say” command) triggers an event within a room (“user X says: text”), which is processed by the recipients of the event. Various awareness mechanisms (in the simplest case, a list of the current visitors to the room) notify users about who is taking part in a discussion or cooperative session. Group: A group encapsulates a number of users. The class “group” is directly derived from the class “object,” and has a similar status to that of a user. User groups may contain other groups and other users. This makes it possible to build a hierarchy of groups and users. Document: All interactions within the sTeam environment are based essentially on generating, manipulating, and exchanging sTeam objects. Like the primary media functions, objects serve as a basis for learners’ potential artifacts. Unlike a conventional object, a document is characterized by the fact that it has content. This comprises the data of any file stored in the database, e.g., a graphic, a word-processing document, or the content of a Web document. Different document types are distinguished by a MIME type stored within an attribute— hence no specific document objects are needed for different types of learning materials or application objects introduced to the sTeam system. The only exception here is the management of hypertext documents. The object type “document” is derived ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

19

from a container’s basic class, hence being able to encapsulate different objects. Such a mechanism enables, say, potential user annotations or comments on documents to be stored simply and neatly in the environment of the respective object. Technologies such as version management or multilinguality of documents will in future be realizable using mechanisms of this sort. Separating the document object itself from its content also allows documents to be simply and efficiently managed within sTeam rooms. Only actual access of document content by the user (e.g., through an upload or download) causes the document content to be loaded from the database. Special rules apply to the handling of various types of hypertext documents such as HTML or XML.9 These can contain links to external documents (URLs) in the document (i.e., in the object content). To avoid inconsistencies when inserting such documents in the sTeam environment or when subsequently shifting documents, links are to be handled separately. In the current implementation, a parsing of the HTML documents takes place, and links are extracted and replaced by links that are unequivocal, in the sTeam environment. (Replacement is carried out when inserting document content into or reading it out of the database by overwriting the corresponding functions in the object.) 6.2 Factories—Selective Generation of sTeam Objects If new instances of objects are generated, it is by using so-called factories, which are available for each object type. Every class has an assigned object with a function for providing instances of the class. The idea of having a definite location for generating new objects has a number of advantages. For one, objects can be updated at runtime—a feature that few systems offer, and one which strengthens sTeam’s claim to be a flexible, userextendable system. Here, factories administer the instances of objects at runtime, updating them, among other things. This enables attributes or methods to be added to existing classes without having to restart the sTeam server. Active instances of the relevant object type are updated. A second advantage is that attributes are registered to objects within the factory. Such a mechanism enables clients to register new attributes to existing objects, or even new object types, and implement specific required features without modifying the sTeam core server. For instance, if a specific client needs an attribute for the local distance of people from a table, perhaps to represent some sort of seating arrangement, the client can register this new attribute at the factory of the class room and use it thenceforth. Finally, the idea of special objects that generate instances of a class allows security to be extended to the object and class structure of the sTeam server. Only authorized users or user groups are able to generate instances of a class, and thus permanently modify the system. No security

9

For information on the Extensible Markup Language (XML), see ,http://www.w3.org/XML/.. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

20

•


check is made, then, at the level of the user interface, since the sTeam has a thoroughly uniform security concept, right down to the generation of individual objects. Thus, factories are basic prerequisites for building a cooperative application at runtime and for extending the environment by the users themselves. The idea of self-administration, i.e., granting system users the right to administer, restructure, and extend the environment, was based originally on this sort of protected object instantiation. 6.3 The sTeam Event System Like MUDs, the sTeam server is event-driven. Events play a prominent role in the design of the sTeam system’s overall architecture. Nearly all communication between objects within the sTeam system is done through events, e.g., “a user addresses the room.” Inside the sTeam core server, such events are processed in the order they occur and are then forwarded to affected objects. The sTeam environment is based on a flexible event system. Events are triggered by arbitrary objects and can be processed by other objects. A whole series of events have already been defined, and adding new events is easy. Events may globally address all objects in the environment or have a limited range, for example, be transmitted to only a limited number of objects—the subscribers to the event (e.g., all users in the room). All the sTeam server’s internal structures are event-driven. For instance, the security module, the sTeam’s key security system, subscribes to all global events and, after a required security check, forwards them to the relevant objects. The sTeam’s entire authorization system is based on this mechanism. The ability to generate new tools or document types shows just how powerful the sTeam’s event system is. Cooperative applications such as a shared whiteboard (a cooperative synchronous drawing area in which the users of a room can draw, diagram, or deposit documents) can be easily integrated into the sTeam environment using a powerful event system of this sort. To do so, a new shared whiteboard object is generated in the room (e.g., derived from a container) which (functioning, so to speak, as the common external memory of the room’s users) manages the cooperatively administered drawings and documents. At the same time, special methods are provided, enabling the data to be accessed inside the shared whiteboard container. If a user now accesses the database via a special client that suitably edits the whiteboard content (e.g., by drawing a new element in the drawing area), these state changes are passed on via events to all subscribers, i.e., those clients (objects) participating in the whiteboard session. Essential characteristics of cooperative applications of this sort are a common persistent data space and the propagation of events to the relevant participants in a cooperative session. Other, less complex tasks can also be performed using the sTeam event concept. For instance, a simple protocol tool for recording chat conversations in a room can be easily implemented using a container object that ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

21

subscribes to the relevant communication events of a discussion’s participants. The sTeam event concept is rigorously implemented right up to the client level. Like any server objects, clients can process events, call server functions, and thus trigger events. For this purpose, a special COAL-based (Client Object Access Layer)10 server API was designed to forward events via so-called sTeam connectors to the Java client. This enables a completely object-oriented representation of server objects within the sTeam clients. The benefits of object-oriented design, often attributed to pure Java clientserver solutions, are thus integrated into the hybrid sTeam architecture. 6.4 sTeam Access Rights Model Multiuser systems such as operating systems traditionally make access rights to a file dependent on ownership conditions and membership of a specific user group (the UNIX operating system in which access rights to a file can be specified for the user, the user group, and other system users by three access-right attributes only.) These rights are evaluated according to a user’s membership in specific groups. The Access Control List (ACL) is the classic model for assigning the access rights of users and groups to objects [Lampson 1974]. For every single sTeam object, the users and groups are defined in an ACL along with their respective access rights: read, write, delete, and delegate rights to others (sanctioning). Sanctioning is an extension of administrative rights as proposed by Satyanarayanan [1989]. This right allows the explicit modification of an ACL (in the case of our system, the ACL of a directory), and so is an important first step toward decentralized administration. The sTeam system extends the right to administer an object, i.e.. to modify access rights (sanctioning), by adding the option of delegating responsibility for an object. The delegation option for objects is taken from access-right models in drafts for relational databases. A formal model for the delegation of access rights to database tables was already drawn up by Griffiths and Wade [1976]. (The creator of a table can delegate administration rights to other users.) A meaningful and widely used strategy for administering access rights is to tie such rights primarily to user groups. With this approach, access rights are tied to the relevant user groups and only rarely granted to individual users. (Thus, most ACLs for a particular object list user groups only). The objective is to keep track of who has access to specific objects by granting as few rights as possible. Such an approach implies that in many cases it will be difficult (if not impossible) to express a specific state of affairs in terms of purely positive rights. For instance, if an individual user is to be denied access to a particular object, the above approach would appear to necessitate removing the user from the group granted the access right in question, and explicitly redefining all other access rights relating to that group (certainly a lot of

10

The acronym COAL was also chosen because a sTeam engine cannot function without coal! ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

22

•


effort to express the simple situation that “person X is not allowed to access object Y”). One solution here would be to use exclusive access rights, so-called negative rights, that explicitly exclude users or user groups from a particular access right. Unlike some database systems, the sTeam system currently uses a model in which negative rights are only admissible for individual users, not for whole groups of users. While such an approach admittedly restricts the scope and power of the negative-rights model somewhat, it makes it easier to keep track of access rights already granted and interpret them unequivocally in cases of conflict. In daily life, authorizations and rights are dynamic, but at the same time shaped by social laws and norms. We take it, then, as a matter of course that, when passed from one person to another, materials will adapt their status in a number of ways to the context in which they will be used, the actors involved, or the place in question. For instance, a set of test questions changes its status from that of a highly confidential object accessible only to the teacher before the test, to a freely available document that can be publicly discussed and commented on after the test. In cooperative teaching and learning processes especially, it would appear essential to dispense with a strict assignment of access rights to documents. Certainly the simplest example of access rights to documents and materials is the assignment of rights to users or user groups described above. If access rights are granted to a user group as a whole, all members of the group, and all members of its subgroups, acquire those rights. Such a mechanism can be used to map access rights resulting from a user’s social status, i.e., his or her permanent membership in a user group, but also dynamic processes such as the allocation of roles. For instance, if a participant in a discussion is appointed moderator and admitted to a corresponding group, he or she automatically acquires the access rights to documents and materials, or to the discussion environment, that go with this appointment. Besides the characteristics of the access-rights model described here, sTeam allows such rights to be derived from the environment of an object or from a fixed object (e.g., the room). Rights can also be granted to groups as a whole, e.g., to set up groups of administrators. These options are not elaborated on here. 6.5 sTeam Clients sTeam clients constitute the real use interface to the sTeam system. At an appropriate point in the development process, implementation focused first on designing a powerful server and enhancing the required server interfaces. This resulted in a corresponding Java API and a number of experimental Java clients. One of the key design decisions with respect to the sTeam client-server architecture was to make the client-server interface as universal as possible, thus allowing server and clients to be largely decoupled in terms of enhancement. Hence, one of its essential characteristics ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

23

is the lean client-server interface. Thus, the only commands provided by COAL are for logging a client on and off the server and for uploading and downloading files, as well as a universal function for calling methods of objects in the server. For each server object, a corresponding Java object can be replicated in sTeam clients. The sTeam clients simply work with the replicated cooperative objects (methods and attributes). Access to attributes and methods within the corresponding server objects is mapped on to the server by the COAL interface. This process is transparent to the programmer of the client application. Events are thus subscribed to by the clients and transferred to them from the server. To give a concrete example: to implement a chat in a client, so-called chat listeners can be attached to the corresponding user objects which, on receipt of a chat message, call an appropriate function to display the chat message. In this way, an sTeam client generates its own personal view of objects in the server. The sTeam structure, consisting of persistent objects and their attributes linked by events, is rigorously implemented right up to the clients. To this extent, the external Roxen Web server connected to the sTeam server works like an sTeam client. Access to the Web server (requests) are interpreted and converted into corresponding sTeam object requests. The sTeam server controls the authentification/authorization of Net accesses (requests), manages the content from the requested Web sites, and simulates a structure of URL addresses. Similarly, uploading and downloading documents generates events in the server. The universal nature of the COAL interface means that no special interfaces are needed to attach the Web server to the sTeam server. 6.6 Structure of Objects in the sTeam Environment: Object Request Broker (ORB) All learning materials such as documents and graphics (but also sTeam users themselves) are represented in the server as sTeam objects. Some sort of basic order in this free structure is provided by sTeam rooms and containers that serve to encapsulate documents and users. In this way, materials and persons can be assigned an unequivocal position within a virtual world. The so-called “root” room forms the basis of a hierarchy of rooms and containers. Rooms are generally connected to other rooms by links and are subrooms of a parent room or of the root room. Architecturally, this means that each object has a definite environment from which attributes, for example, can be inherited. There are various situations in which the sTeam structure of rooms and documents must be searched or transformed. For instance, if documents are transferred to the server via a file system-oriented protocol like FTP, a completely different structure must be mapped than, say, in the case of a search request for objects in the server. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

24

•


Viewing the sTeam structure from different angles and perspectives is performed by the sTeam ORBs (Object Request Brokers). An ORB is used to access the sTeam object structure. There are currently three different ORBs: (1) one that simply assigns an unequivocal ID to sTeam objects (used, for instance, in object searches; (2) one that enables an sTeam object to be accessed via a URL represented by a name. This is typical on standard Web servers, where arbitrary sTeam objects can be assigned a URL attribute that represents a sort of alias for accessing a particular document via a WWW client); and (3) a special ORB that manages the mapping of the sTeam structure by means of a hierarchy of rooms, containers, and objects (here, each object has a definite environment). Only the first ORB, which assigns objects an unequivocal ID, can access all objects in the server. The hierarchical room structure and the identification via name URLs only map part of the server structure in each case. 7. RELATED WORK A comprehensive treatment of the sTeam approach in relation to other work on computer-supported cooperative learning is beyond the scope of this article. Engelbart and English [1968] were definitely among the first to address the idea of computer-supported group work with their “augmentation system” research on supporting human skills by computer technology. There are a whole series of methods that resemble the sTeam architecture in specific features (see Appelt and Mambrey [1999]; Chabert et al. [1998]; Patterson et al. [1990]; Roseman and Greenberg [1996]), but none offer the sTeam’s open and flexible object/event structure. The GMD, for example, is developing the COAST platform [Schuckmann et al. 1996] and its purely Java-based successor DyCE for designing Net-based cooperative applications. A characteristic feature of DyCE is its replicated system architecture consisting of cooperative Java objects. But the developers were not primarily concerned with learners’ self-administration and the idea of fusing communication and document-management mechanisms. The idea of developing an environment for cooperative work based on MUD architectural concepts has already been tried by the MITRE Corporation11 with its CVE environment. Unfortunately, CVE’s room structure is quite rigid and provides only weak mechanisms for the distributed administration of rooms. 8. CONCLUSIONS The sTeam’s cooperative learning approach aims to provide primary media functions from the learners’ perspective. In the sTeam concept, rooms offer users considerable scope for self-administration. Ideally, the participants in a virtual learning community design their own learning environment. This cf., the open source Collaborative Virtual Workspace Web site, MITRE Corporation, ,http:// cvw.mitre.org/ http://cvw.sourceforge.net/..

11



•

25

process begins with the creation of a virtual room and involves processing objects such as documents, graphics, and slides as well as selecting cooperative tools that will be available throughout the learning process. However, the solutions presented in the sTeam approach are not meant to compete with advanced technological solutions for individual applications. Providing solutions for practical everyday use (a goal calling for the integration of different tools and environments into a sustainable infrastructure) is a research goal in itself. It is not sufficient that technology work in principle; it must work on a practical, everyday basis (a requirement that has certainly been responsible for the spread of the World Wide Web and its fundamental success over the past ten years). Similar efforts and quality standards must be applied in the future to the further development of cooperative teaching and learning environments. This article attempts to bridge the gap between our underlying theoretical ideas and our practical implementation of an open and flexible clientserver structure. It focuses on cooperatively building and maintaining distributed knowledge structures, not on reading and browsing on the Net. The desire to create a learning environment by learners for learners drives sTeam research. It is in this spirit that we hope to find new impetus and support, especially from proponents of the open source idea, in our effort to develop a free and flexible computer-supported cooperative learning platform. The rigorous application of open standards (e.g., providing comprehensive support for XML documents or developing powerful, interactive Java clients) will constitute an important challenge in the near term.

ACKNOWLEDGMENTS

Our special thanks to Thomas Bopp and Ludger Merkens and all the other programmers and designers of the open-sTeam system for their unceasing efforts to realize sTeam. Special thanks also to Phil Bacon for polishing the manuscript’s style and idiom. The work here is part of our contribution to the German Research Foundation’s (DFG) keynote program, Knowledge Communication in Groups. REFERENCES APPELT, W. AND MAMBREY, P. 1999. Experiences with the BSCW shared workspace system as the backbone of a virtual learning environment for students. In Proceedings of the World Conference on Educational Multimedia, Hypermedia and Telecommunications (ED-MEDIA 99, Seattle, WA, June). 1710 –1715. BARTLE, R. 1990. Interactive multi-user computer games. Res. Rep., British Telecom plc. BRENNECKE, A. AND KEIL-SLAWIK, R. 1995. Notes on the Alltagspraxis of hypermedia design. In Proceedings of the World Conference on Educational Multimedia, Hypermedia and Telecommunications (ED-MEDIA 95, Charlottesville, VA), H. Maurer, Ed. 115–120. BRENNECKE, A., SCHWOLLE, U., AND SELKE, H. 1997. The evolution of an electronic teaching and learning environment. In Proceedings of the World Conference on Educational Multimedia and Hypermedia’97 (Calgary, Alberta, Canada). 98 –105. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.

26

•


CHABERT, A., GROSSMAN, E., JACKSON, L. S., PIETROWIZ, S. R., AND SEGUIN, C. 1998. Java object-sharing in Habanero. Commun. ACM 41, 6, 69 –76. CURTIS, P. 1992. Mudding: Social phenomena in text-based virtual realities. Intertek 3, 3, 26 –34. ¨ ber die Zeit. Suhrkamp, Frankfurt, Germany. ELIAS, N. 1988. U ELLIS, C. A. AND REIN, G. 1991. Groupware: some issues and experiences. Commun. ACM 34, 1 (Jan.), 39 –58. ENGELBART, D. C. AND ENGLISH, W. K. 1968. A research center for augmenting human intellect. In Proceedings of the on AFIPS Fall Joint Computer Conference (San Francisco, CA, Dec.). AFIPS Press, Arlington, VA, 395– 410. EVARD, R. 1993. Collaborative networked communication: MUDs as systems tools. In Proceedings of the Seventh Conference on Systems Administration (LISA VII, Monterey, CA, Nov.). 1– 8. GIBSON, J. 1986. The Ecological Approach to Visual Perception. Lawrence Erlbaum Associates Inc., Hillsdale, NJ. GRIFFITHS, P. G. AND WADE, B. 1976. An authorization mechanism for a relational database system. ACM Trans. Database Syst. 1, 3 (Sept.), 243–255. HAMPEL, T. 2000. Scenarios of a new dimension of learning by the co-operative structuring of knowledge. In Proceedings of the World Conference on Educational Multimedia, Hypermedia and Telecommunications (ED-MEDIA 2000, Montreal, Que., June 26-July 1), J. Bourdeau and R. Heller, Eds. 369 –374. HENDERSON, D. A. AND CARD, S. 1986. Rooms: The use of multiple virtual workspaces to reduce space contention in a window-based graphical user interface. ACM Trans. Graph. 5, 3 (July), 211–243. HESSE, F. W., BUDER, J., AND SCHWAN, S. 1998. Some theoretical and practical aspects of knowledge communication in netbased learning groups. In Proceedings of the Sixth International Conference on Global Education on the Net: Computers in Education, T.-W. Chan, A. Collins, and J. Lin, Eds. Springer-Verlag, New York, NY, 408 – 411. HILL, C. AND SLATOR, B. M. 2000. Computer science instruction in a virtual world. In Proceedings of the World Conference on Educational Multimedia, Hypermedia and Telecommunications (ED-MEDIA 2000, Montreal, Que., June 26-July 1), J. Bourdeau and R. Heller, Eds. 406 – 411. KEIL-SLAWIK, R. 1999. Evaluation als evolutiona¨re Systemgestaltung. Aufbau und Weiterentwicklung der Paderborner DISCO. In Aufbau und Weiterentwicklung der Paderborner DISCO: Digitale Infrastruktur fu¨r computerunterstu¨tztes kooperatives Lernen, M. Kindt, Ed. 11–36. KEIL-SLAWIK, R., KLEMME, M., AND SELKE, H. 1996. Information and communication technologies in education and training (Part A) STOA programme. European Parliament, Directorate General for Research, PE: 165.710., Luxembourg. KELLY, K. AND RHEINGOLD, H. 1993. The dragon ate my homework. Wired 1 (July/Aug.). LAMPSON, B. 1971. Protection. In Proceedings of the 5th Princeton Symposium on Information Sciences and Systems (Princeton, NJ, Mar.). 437– 443. 1997. Design for network MYNATT, E. D., ADLER, A., ITO, M., AND O’DAY, V. L. communities. In Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI ’97, Atlanta, GA, Mar. 22–27), S. Pemberton, Ed. ACM Press, New York, NY, 210 –217. NELSON, T. S. 1987. Computer Lib/Dream Machines, DM 29. revised ed. Microsoft Press, Redmond, WA. O’DAY, V. L., BOBROW, D. G., AND SHIRLEY, M. 1996. The social-technical design circle. In Proceedings of the 1996 ACM Conference on Computer-Supported Cooperative Work (CSCW ’96, Boston, MA, Nov. 16 –20), M. S. Ackerman, Ed. ACM Press, New York, NY, 160 –169. PATTERSON, J. F., HILL, R. D., ROHALL, S. L., AND MEEKS, S. W. 1990. Rendezvous: an architecture for synchronous multi-user applications. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW ’90, Los Angeles, CA, Oct. 7–10), F. Halasz, Chair. ACM Press, New York, NY, 317–328. POLYA, G. 1971. How To Solve It. Princeton University Press, Princeton, NJ. ACM Journal of Educational Resources in Computing, Vol. 1, No. 2, Summer 2001.


•

27

REID, E. 1994. Cultural formations in text-based virtual realities. Ph.D. Dissertation. University of Melbourne, Melbourne, Australia. RHEINGOLD, H. 1993. The virtual community. Homesteading on the electronic frontier. Res. Rep. ROSEMAN, M. AND GREENBERG, S. 1996. TeamRooms: Network places for collaboration. In Proceedings of the 1996 ACM Conference on Computer-Supported Cooperative Work (CSCW ’96, Boston, MA, Nov. 16 –20), M. S. Ackerman, Ed. ACM Press, New York, NY, 325–333. SATYANARAYANAN, M. 1989. Integrating security in a large distributed system. ACM Trans. Comput. Syst. 7, 3 (Aug.), 247–280. SCHUCKMANN, C., KIRCHNER, L., SCHÜMMER, J., AND HAAKE, J.-M. 1996. Designing objectoriented synchronous groupware with COAST. In Proceedings of the 1996 ACM Conference on Computer-Supported Cooperative Work (CSCW ’96, Boston, MA, Nov. 16 –20), M. S. Ackerman, Ed. ACM Press, New York, NY, 30 –38. Received: March 2001;

revised: May 2001;

accepted: July 2001
