Abstract (02)
Collaboratories consisting of systems of information tools are increasingly important as mediators of joint work in distributed groups. These systems should be constructed in a testbed development process. This process is far from trivial, and must be continously improved. To aid in this improvement process, a tool context model is presented, in which the information system, usage, design, and improvement contexts of the information tools making up a collaboratory can be represented. Using ontological, norm and rule definitions, the various context processes can be systematically defined and analyzed. (03)
The Internet, having outgrown its infancy, connects ever more people. It gives them access to a wide range of information tools that allow them to better retrieve and process information. Most importantly, these tools greatly enhance the power to communicate. Professional communities distributed in time and space now have great potential for improved collaboration, increasing the efficacy of their work, for instance, of the production of joint documents. However, for communities to work together, more is needed than just providing their members with access to a set of tools and hope that collaboration will spontaneously emerge. Instead, the focus should be on achieving strong collaboration, in which a group synergistically develops and improves a structured artifact much more efficiently than possible by the same group of people working independently [1]. To realize this synergy, these tools should not be examined in isolation, but as part of an integrated socio-technical system. (05)
Collaboratories are one interesting type of information tool-based technical systems supporting joint work in the research domain. A collaboratory consists of "various tools and technologies [...] integrated to provide an environment that enables scientists to make more efficient use of resources wherever they are located [2]." Although a few successful collaboratories are already operational, there are no standard solutions for these very complex and volatile socio-technical systems. As the mission statement of the Science of Collaboratories alliance states: "[T]he design, deployment, and adoption of new collaboratories remain difficult and uncertain processes. Each collaboratory has been built as an independent effort. Since these efforts involved complex responses to often idiosyncratic mixtures of social and technical factors, general lessons about collaboratory design remain elusive1." (06)
The question now becomes: what kind of design principles are needed? For these types of systems, an iterative socio-technical design approach is required. This approach should acknowledge that there are different contexts in which collaboration takes place in different ways by different scholarly populations [3]. In this paper, we examine the parameters of such an approach, and outline how it could be practically implemented in the PORT project. (07)
Thirty years ago, Douglas Engelbart had a dream. In a "Knowledge Workshop 'mission-oriented communities' explore applications by explicit progression, beginning with tested techniques, whose 'cultural shock' and financial investment are relatively low, and offering paced, open-ended evolution with time, experience, and perceived payoff [4]". In his view, the only feasible approach is a long-term, pragmatically guided whole-system evolution. It is crucial not just to create good socio-technical systems, consisting of co-evolving Human and Tool Systems. Also, one should continuously improve this design process, in other words "improve the improvement capability of the organization". He therefore asks the very important question whether there is a set of basic capabilities whose improvement would signficantly enhance both operational and self-improvement capabilities? Engelbart then goes on describing his CODIAK (COncurrent Development, Integration and Application of Knowledge) process, which aims to address this question [5]. (09)
Engelbart's insight is a fundamental conceptual step on the way to effective, or pragmatic testbed development. Many projects have focused on tool and infrastructure development, or at most the development of tailored systems for particular activities and domains, like computer simulation and healthcare [6]. However, so far only little systematic attention has been paid to the context of these systems, in which they are used, developed, and improved. (010)
Building on and generalizing from Engelbart's views on socio-technical systems design, we distinguish a hierarchy of tool contexts: (011)
The units of analysis in each layer are processes. These we call information and communication processes (information system context), workflows (usage context), design processes (design context), improvement processes (improvement context). (018)
In collaboratory development, the various systems of tools, processes, users and their contexts are key. A system is a collection of parts that interact with one another to function as a whole [7]. For each of the system processes, all interacting with other parts of the same or other systems, interfaces and integration aspects need to be defined. (019)
An interface is the place at which independent and often unrelated systems meet and act on or communicate with each other. One meaning of integration refers to blending into a unified whole2. Regarding process definition, we interpret the interface of a process to be its constituting entities that are visible to system entities outside the process, while the internal workings of the process may remain a black box. In this way, the knowledge essential for system design is shared, while leaving as many degrees of freedom for implementing or customizing the functionality of the individual tools. For instance, when defining the archival process, core interface entities are the actors involved (e.g. authors, system manager), the objects (e.g. archive directories, files), and functions (saving and indexing files). (020)
Integration is defined as the existence of any link between two process entitites in any of the systems. For example, a design discussion process may be linked to an archival process (design context) by having any discussion thread on which tool to use for archiving purposes, stored and indexed separately on the PORT web site. The more system processes are linked, the higher the level of integration. In some cases, a high level of integration may be desirable, whereas in other cases, having loosely coupled processes may be more useful. (021)
Using this contextual framework, testbed development methods for collaboratories can be constructed and tested more systematically. Context elements can be changed at any particular layer, while leaving other layers unchanged. This means that analyzing and comparing different approaches becomes much easier. Such a meta-methodological approach is essential, since still so little is known about what makes a collaboratory development process adequate: "Researchers themselves will build this New World largely from the bottom up, by following their curiosity down the various paths of investigation that the new tools have opened. It is unexplored territory. [6]" A contextual framework can help chart this terra incognita, making the process of exploration safer and more fruitful. (022)
In the next section, we describe and illustrate the PORT collaboratory in its contexts, and show how it is well suited for meta-modelling the collaboratory development process. (023)
The PORT (Peirce On-Line Resource Testbeds) project has two main foci: (1) developing a model collaboratory for distributed scholarly Peirce manuscript analysis and (2) meta-modeling the testbed development process, making use of Peirce's pragmatism to help guide collaboratory participants in the design process. Both objectives can and need to be developed simultaneously, but also need to be clearly delineated. The contextual framework may help in keeping both development processes and their interactions in focus. (025)
Instead of extensively describing the (continuously changing) PORT improvement system, we instead illustrate the use of the framework by giving key example processes taken from existing web site or papers on PORT, and tools supporting these processes. In this way, we roughly indicate how the various initiatives and project elements are related. Note that we do not describe the interface and integration issues here. This framework, however, provides a good basis for such more detailed analysis. (027)
Information/communication processes: text editing, mailing, file management, annotating. (029)
Workflows: image capturing, catalogue development, document editing. (031)
Design processes: ad hoc discussions on PORT development (as conducted on the PORT mailing list), conversations for specification (in the RENISYS method of legitimate user-driven specification, selected users discuss requested changes to the socio-technical system. In a series of well-defined conversational moves, they produce only acceptable changes to system knowledge definitions [8]). (033)
Improvement processes: in [8], we propose to use a pragmatic inquiry process, using Peirce's abduction, deduction, and induction of hypotheses on effective systems development. This is a good example of improving the development process, by structuring the conversations for specification. (035)
In PORT, various classes of tools can be distinguished. (037)
These tools provide support for processes in different context layers. Generic tools, such as web browsers, can be used in every layer, acting as gateways to all activities of the virtual community. Specialized work tools are especially useful to support processes in the information system and usage context layer. RENISYS and Engelbart's AUGMENT5 cover the higher layers. RENISYS mainly supports legitimate community information systems development, but so far has not been able to self-improve its methodology. Incorporating the mentioned pragmatic inquiry approach is one step on the way to a more adequate improvement context. AUGMENT provides many tailorable functionalities that could play a role in systematically improving the socio-technical design process, although improvement processes still seem to be quite implicit. (042)
Given that there is a great variety of tools, which serve complex processes in different contextual layers, formal models can be of great help in organizing and reasoning about collaboratory development knowledge. Conceptual graph theory is of great help here, among other things because it is well suited for generalization/specialization operations and context modelling. These properties are important for developing diverse views on, links between, and embedding of collaboratory system and contextual entities. (044)
To build formal models, three core knowledge categories are needed: (045)
Ontologies can be used to make definitions of concept types, defining the type hierarchies and meaning of concepts. Each contextual layer has its own ontologies. For example, part of an ontology of the usage context layer could be: (047)
Workflow >
Archive
Archive_Images
Archive_Transcripts (048)
Whereas part of the pragmatic inquiry process ontology of the improvement context is (see [8]): (049)
Hypothesis >
Proposed_Hyp
Tested_Hyp >
Failed_Hyp
Succ_Hyp (050)
Ontological concepts are the basis for relevant knowledge definitions, such as norms and states-of-affairs ("state") definitions. One example of a state definition that can be used to define links (integration aspects) between entities from the system and usage context is that of the support-relation [9]: (051)
[State: [Support:#145] - (Poss) <- [User: #John] (Inst) -> [Inote: #1] (Obj) -> [Workflow_Mapping:#123]]. (052)
This definition explains that John uses the INote tool for supporting his workflow #123, which could be, for instance, a certain kind of review process-by-annotation. (053)
A norm is a principle of right action binding upon the members of a group, and serving to guide, control, or regulate proper and acceptable behaviour. Norms can thus be used to direct processes at the various context levels. For example, a RENISYS composition norm at the design context level could be: (055)
[Req_Comp: [Editor] <- (Agnt)-
[Eval] -> (Obj) -> [Specify] -> (Rslt) -
[Type: [Archive]]]. (056)
This norm states that the editor must evaluate (i.e. approve of) any change in the specification of the archival process properties. (057)
Using the ontological (and state knowledge) and norms, the whole collaboratory improvement system can be defined. In order to activate this declarative knowledge, CG tools that provide such a procedural instead of merely declarative knowledge support are needed. Examples are PROLOG+CG (which allows PROLOG rules to reason about CG knowledge definitions) or tools that enable conceptual graph actors to fire (like CharGer). Using rules, design and improvement events can be triggered, thus leading to more adequate systems development processes. For example, if a new tool is introduced that enables a new type of communication processes (system context), a discussion at the design level could be automatically started, in which the support for the workflows provided by the current tools is reconsidered. (059)
Collaboratories are composed of systems of information tools. In this paper, we stressed the importance of systematically describing and analyzing the system, usage, design, and improvement contexts of these tools. In this way, complex collaboratory development processes can become more systematic and pragmatic. Douglas Engelbart already foresaw the importance of such a structured approach a long time ago, summarized by his motto of "improving the improvement process". With the advent of the Web, the maturing of Web-based information tools, and sophisticated knowledge representation and reasoning formalisms like conceptual graph theory and applications, the time has come to make Doug's dream come true. (061)
1. Johnson, P. and C. Moore, Investigating Strong Collaboration with the Annotated Egret Navigator. 1994, University of Hawaii. (063)
2. Committee Toward a National Collaboratory: Establishing the User-Developer Partnership, N.R.C., National Collaboratories: Applying Information Technology for Scientific Research. 1993, Computer Science and Telecommunications Board. (064)
3. Sumner, T. and S.B. Shum. From Documents to Discourse: Shifting Conceptions of Scholarly Publishing. in Proc. of CHI'98: Human Factors in Computing Systems, Los Angeles, 18-23 April 1998. 1998: ACM Press. (065)
4. Engelbart, D.C. Coordinated Information Services for a Discipline- or Mission-Oriented Community. in Proc. of the 2nd Annual Computer Communications Conference, San Jose, California, January 24. 1973. (066)
5. Engelbart, D.C., Toward High-Performance Organizations: a Strategic Role for Groupware. 1992, Bootstrap Institute. (067)
6. National Research Council, Issues for Science and Engineering Researchers in the Digital Age. 2001, National Academy of Sciences. (068)
7. Maani, K.E. and R.Y. Cavana, Systems Thinking and Modelling: Understanding Change and Complexity. 2000, Auckland: Pearson. (069)
8. de Moor, A., M. Keeler, and G. Richmond. Towards a Pragmatic Web. in Proc. of the 10th International Conference On Conceptual Structures (ICCS 2002), 15 - 19 July, Borovets, Bulgaria. 2002. (070)
9. de Moor, A. and W.J. van den Heuvel. Making Virtual Communities Work: Matching their Functionalities. in Proc. of the 9th International Conference on Conceptual Structures, Stanford, July 30-August 3. 2001. (071)
1 http://www.scienceofcollaboratories.org/html/AboutSOC/Mission.html (073)
2 http://www.merriam-webster.com (074)
3 http://peirce.monmouth.edu/~bill/, http://www.darmstadt.gmd.de/~dirsch/port/ (075)