Copyright: Jennifer Robins
May 5, 1999

Stone Soup:
A Distributed Collaboratory Using Software Agents

Jenny Robins
Graduate School of Library and Information Science
University of Illinois, Urbana Champaign


Abstract
A collaboratory is an online community where members share ideas, information and digital resources. It is a type of digital library where community members build the collection. Because of this, a collaboratory has three advantages over a digital library: The central challenge in building a collaboratory is achieving a critical mass of participating members. Studies have found Computer Supported Cooperative Work systems, such as a collaboratory, that reach a state of critical mass are likely to succeed. Critical mass is defined as threshold of individual actions that must be reached in order to produce a public good. For the collaboratory to become a public good it must reach a state where its value increases with use while the cost of its operation does not. In order to accomplish this, I propose two strategies:
  1. Encourage pro-social behaviors within the collaboratory community.
  2. Add value to the collaboratory every time members use it.
Twenty-three activities providing methods for implementing the two strategies are suggested herein. The capabilities needed to support one of the activities is explored in depth matching these capabilities with the functionality software agents provide. Using software agents to automate activities is a way to keep the cost of the collaboratory constant as usage increases.


1. Introduction
The folk tale “Stone Soup” is the story of a community in famine. A poor harvest and long winter had depleted the food supply in the village. Malnutrition threatened every household. One day an old lady who had lived in the village began going from house to house knocking on doors, “Please come to my house tonight. I am serving stone soup.” Her neighbors were perplexed, “What is stone soup?” they asked.
“Oh I put this magic stone in a pot of boiling water and let it simmer all day.” The old woman replied.
One neighbor said, “That is kind of you to invite us, can I bring something? I can’t bring much, all I have left are potatoes.”
“Wonderful” the woman said, “bring a potato.”
Another neighbor said, “I have only carrots here. Can I bring one to contribute to the soup?”
“Oh yes,” the old woman replied.
And so it was through the entire village, one contributed a potato, one a carrot, others contributed beans or a handful of barley. That evening, the entire village was treated to nutritious soup and there was enough of the magic stone leftover for another meal.

There are lessons in this folktale for developers of information systems. Besides the obvious message of increasing the richness of a collection by pooling resources, there is a secondary lesson to be found in the old lady’s method. She did not search the village looking for a carrot or a potato, she put out an invitation to join the collective. The community members, inspired by the old woman’s kindness, contributed as they were able. In the same way, global villagers in the information age can collectively build the type of digital library referred to herein as a collaboratory. What distinguishes a collaboratory from a digital library is that members supply the resources that become the library’s collection. Because of this, the collaboratory has three advantages over a digital library:

The term “collaboratory” was coined by W.A. Wulf in 1989 and was originally used to describe the Unidata Program, a collection of resources and data used to study atmospheric science (Fulker, et.al., 1996). The term is used herein to describe an online community where members can share ideas, information and resources as outlined in the next section. That section is followed by a look at the challenge of building a successful collaboratory. Next two strategies to meet that challenge are explored. Then, an overview of activities designed to implement the strategies is presented. Finally, a single activity is highlighted and the capabilities needed to conduct that activity are matched with those afforded by software agents in order to demonstrate the suitability of using agents to implement the strategies. This paper is speculative in nature. It is hoped that future research will support or refute the hypothesis herein.


2. The Collaboratory Collection
The collaboratory being proposed is capable of collecting ideas, information and resources that have been digitized. The resources are distributed, residing on each contributor’s server instead of being copied into a central repository. This serves two purposes: first it reduces the load on the collaboratory’s server. The collaboratory’s server only has to store links to and information about the resources. Perhaps even more important than the efficient use of the collaboratory server, is that because they are distributed, resources are explicitly, always the property of the contributor. The contributor is able to remove them from the collaboratory by simply renaming them or moving them to a different directory on his or her server. This way individual members maintain control of their intellectual property, making them more willing to contribute to the collection (Connally & Thorn, 90; Schmidt & Bannon, 1992). The following types of objects can be linked in the collaboratory collection:
  1. Text materials such as documents, HTML files and XML files
  2. Multimedia files, ranging from database files, spreadsheet files, graphics, movies, and sound files
  3. Software and simulation materials; i.e. executable programs
  4. Project spaces where members can collaborate on projects and store mutually developed products
  5. Discussion spaces such as Web boards, databases and chat rooms where members can collaborate
  6. Any combination of the other types of objects
In addition to objects that are linked in the resource directory, the following databases maintain information of interest to the collaboratory community:
  1. Member directories including profiles of collaboratory members
  2. A directory of links to resources
  3. Organization directories, if members are involved with the collaboratory due to the activities of a specific organization
  4. Evaluation information for each resource, including usage counters
  5. A query processing database with the parsing information necessary to process queries
  6. Correspondence databases which include text used to automatically generate email to members and their organizations
  7. A list of frequently asked questions about technical subjects involving collaboratory activities, along with a list of providers of technical support for hardware and software problems members encounter
  8. A directory of Internet sites that might be of interest to the collaboratory community


3. The Challenge
The central challenge in creating a collaboratory is assembling a community of users willing to sacrifice time and effort in order to share resources with others. What if we build a collaboratory and nobody uses it? From multiple studies, Gruden & Palen conclude that if a Computer Supported Cooperative Work (CSCW) system, such as a collaboratory, reaches critical mass, it is likely to succeed (1995). Critical mass is a metaphor borrowed from physics that refers the amount of radioactive material needed for fusion to occur. Applied to social theory concerning collective behaviors, it refers to the threshold of individual actions that must be reached before a public good is produced. A public good refers to a resource that’s value increases with the number of people who use it, while its cost does not. (Oliver et al, 1985). The Stone Soup in the folk tale is an example of a public good. The value of the soup reflected the number of contributors, not the cost of its preparation. Value refers to the equivalent in money, commodities, etc. that it would take to recreate a collection.


Figure 1: Comparing a public benefit with a public good.

The figure above compares a collection that performs a public benefit with one that would be considered a public good. In the case of a public benefit, the value of the collection is proportional to the cost of its development. With a public good the value of the collection is proportional to the number of users. The aim of the strategies proposed in the next section is to establish a collaboratory as a public good.


4. Two Strategies to Meet the Challenge
The two strategies suggested below are derived from the theory of critical mass. They are meant to increase the number of users and to increase the value of the digital collection, without producing a corresponding increase in the cost of the collaboratory. These particular strategies are chosen because they lend themselves to automation as will be described in Section 6 of this paper.


4.1 Encourage Prosocial Behavior
One strategy aimed at increasing the value of the collaboratory is to encourage prosocial behaviors. Prosocial behaviors are actions that are intended to promote the well being of others. As a result of a 1986 meta-study on prosocial behaviors, Brief and Motowidlo describe the climate that optimizes prosocial activity. An organization, such as a collaboratory should be characterized by warmth, friendliness, supportiveness, and cooperation. It should demonstrate high levels of reciprocity and group cohesiveness. It should put in place formal and informal reinforcement contingencies which reward prosocial acts and role models. These reinforcements become the social mores of virtual communities like the collaboratory.

Moreover, in a virtual communities, it has been noted that prosocial behavior tends to be self-reinforcing. People develop a high regard for organizations that embed acts of kindness in their activities. They show their regard by performing still more prosocial acts. In this way individuals become more committed to the organization. Improving the organization then becomes a goal of individuals, which insures the success of the organization’s endeavors or in this instance, the success of the collaboratory (Brief & Motowidlo,86; Crown & Rosse, (95).

A collaboratory owes its existence to members performing the prosocial act of donating information and resources. Members might donate resources out of a desire for reciprocity, hoping their act will encourage others to do the same; or they might contribute out of a sense of altruism. Both are examples of prosocial behavior (Connolly & Thorn, 90). Donating resources provides a double benefit to the collaboratory, as the act not only promotes prosocial behavior, it adds value to the collaboratory directly, as will be discussed in section 4.2

Performing acts of kindness, such as help-giving; offering advice or passing along information, increases self-esteem. Also, members have an opportunity to demonstrate expertise and experience, earning respect and status (Wellman et al.,1996; Constant et al.,1996). A collaboratory can be designed in such a way that members’ acts of kindness are visible to the entire community as a means of gaining recognition. Prosocial behavior begets prosocial behavior. When members see others benefiting from these acts, they are more likely to behave in the same manner (Brief & Motowidlo,86)


4.2 Adding Value through Member Activity
Another way of ensuring the success of the collaboratory is to capture the value that can be added to the collection through members’ usage. The obvious way members increase the value of the collection is by donating resources; but there are other ways value can be added. For example, a good index adds value to a collection. Many schemes exist for indexing a heterogeneous set of files, such as the ones the collaboratory is likely to contain, but not all rely on work performed by users of the collection. In 1987, Furnas et al. reported that adaptive indexing is an accurate and efficient method for labeling objects. These researchers note that objects can employ multiple aliases and that these aliases can be accumulated “relatively painlessly” by collecting them from real users under authentic conditions. Resources can be “indexed” using the full text description, key words, and titles supplied by the contributor, as well as keywords and descriptions solicited from users of the resource. Furnas et al. found, in their experiments, that the indexes grew rapidly from the contributions of the first 24 users. After that only one user in 50 added a new term. Using this method, it might not be necessary to commit administrative effort to index the resources of the collaboratory. The users themselves build the index.

Another way that usage can add value to the collaboratory is by collecting feedback from members who use resources. Feedback provides a means to evaluate the usefulness of individual resources. A history of comments can accompany resources, as can usage counters. A public good often encounters the problem of the “free rider,” people who benefit, but make no contribution to the collection themselves (Connolly & Thorn, 90). But, usage counters can create value from the acts of casual users. Usage counters provide a context in which to communicate appreciation to contributor. In addition, they are a means to evaluation the usefulness of resources. Thus, there are no “free riders” in the collaboratory envisioned herein. Every user’s act, no matter how small, increases the value of the collaboratory in some way. Occasionally extensive feedback might be collected, if it includes information about how a resource was used, it might become a separate resource in itself (Twidale et al, 97; Karamuftuoglu, 98). Moreover, by acknowledging to users that their feedback has been received, members are made aware that offering feedback is a way of contributing to the collaboratory. This helps maximize the flow of personalized communication between the collaboratory and its members, reinforcing the community through acts of personal recognition.

Usage can also increase the value of the collaboratory by providing information about the types of resources the collaboratory should contain. User requests for resources that fail, meaning that the resource is not contained in the collaboratory can activate outside searching for that resource on the Internet. The resource can then be “wrapped” (Knoblock, et al., 1994). Wrapping a resource refers to creating a link to the resource within the collaboratory in the form of a Handle. A Handle is an information data type that include a field of descriptive information as well as code for accessing the resource (Sun,1999). This way the collaboratory includes outside resources of interest to its members. Those resources can then be seamlessly retrieved along with collaboratory resources.

Still another way to add value to the collaboratory is by capturing the search strings. Karamuftuoglu (1998) points out that while some searches are designed to retrieve objects that are known to exist, some are exploratory in nature. The aim of exploratory searches is to increase knowledge by discovering new combinations and connections between resources. These searches can be saved and stored within the collaboratory for other members to use as a form of collaborative browsing (Twidale et al.,1997) . Thus the value of the collaboratory is increased by the creative and inventive behavior of its members.


5. The Collaboratory Activities
The activities in the lists that follows are intended to promote prosocial behaviors and/or add value to the collaboratory. Thess lists are suggestive not inclusive. Moreover, depending on the needs of the collaboratory, all or none of these activities might be required. For example, a collaboratory serving an organization where there is a rigid command structure might be successful using only a few of these activities, because workers are required to contribute to and use the collection (Gruden, 89). On the other hand a collaboratory for public school teachers, a diverse, distributed group, might require all of the activities listed below, as illustrated in section 6.2. The collaboratory activities presented below were chosen because they can be supported by automated processes, thereby keeping the cost of operation low (see Section 6.3). Table 1 illustrates how member activities encourage pro-social behavior and add value to the collaboratory. These items are reviewed row by row in Section 5.1. Table 2 illustrates how administrative activities encourage pro-social behavior and add value to the collaboratory. These items are reviewed in Section 5.2.


5.1. Member Activities
Both members and administrators can perform activities in the collaboratory.
The following list presents activities that members of the collaboratory can perform. Table 1 below matches member activities with strategies designed to bring the collaboratory to critical mass.


Table 1.: Prosocial and value added collaboratory member activities


5.1.1 Prosocial Member Activities
Prosocial member activities designed to promote donating are M1, which makes sharing resources as simple as possible; and M3, which does the same for resources created by members using composites of other resources. M5 provides a way for members to share descriptions of how to use resources in the collaboratory. In some situations, these descriptions become collaboratory resources (Twidale et al., 97). Using M9, members donate by offering online workshops to meet the needs of the collaboratory community.

Prosocial member activities that promote help-giving are M4, which provides a way for members to offer feedback about a resource; M5, where members describe how resources are used; and M6, where members provide alternative descriptions and keywords for resources. Members can also offer help by opening or joining discussions on topics that interest them, activity M8. Moreover, they can give help explicitly by offering workshops, M9.

All the member activities of the collaboratory offer a way of gaining recognition. Donations made in M1 and M3, descriptions provided in M5, discussions introduced in M8, and workshops created in M9 carry the identification of the contributor. Members can also choose to make their profiles public in activity M7, as a way of introducing themselves to other members. In this case, when members request resources, they are provided with a means of introduction to the donating member. Thus the act of requesting resources (M2) connects members with similar interest. When members provide positive feedback or constructive criticism in activity M4, or keywords and descriptions in M6, they do so with the understanding that their contribution will be passed on to the resource creator. Thus through many means, members of the collaboratory are given an identity in the virtual community.


5.1.2 Value Adding Member Activities
Member activities can also add value to the collaboratory. As mentioned earlier, donating is a way to behave prosocially and a way to add value to the collection. Donating resources in activities M1 and M3 enriches the collaboratory directly. But descriptions of how resources are used are themselves, resources. Thus, through activity M5, those descriptions also enrich the collection through donating. The more ideas about how a resource can be used, the more valuable the resource becomes.

A good index adds value to a collection. Using adaptive indexing, members create the collaboratory index. Contributors provide indexing information when new resources are created in activities M1 and M3. Also, descriptions of how resources are used result in additions to the indexing system in activity M5. Members can provide keywords and other types of descriptions of resources directly in activity M6. Thus, the index is enlarged to include multiple perspectives regarding resources (Karamuftuoglu, 98).

Activity M4 provides a variety of ways for members to contribute feedback. Collecting feedback from members is a way for members who do not have resources to donate to contribute ideas and information to the collaboratory.

Even failed collaboratory searches performed during activity M2 can add value to the collaboratory, if outside searching over the Internet proves successful. The resources retrieved are more likely to match the needs of the community than undirected Internet searches. Regardless of whether they were successful, the searches can be stored and made available for analysis by other collaboratory members with similar needs. By permitting their searches to be stored and accessed by others, members engage in collaborative browsing (Twidale et al., 97).


5.2 Administrative Activities
The following list presents activities that administrators of a collaboratory can perform. Again, this list is suggestive rather all inclusive. Table 2 below matches administrative activities with strategies designed to bring the collaboratory to critical mass.


Table 2.: Prosocial and value added collaboratory administrative activities


5.2.1 Prosocial Administrative Activities
The prosocial aspect of donating is supported by administrative activity A1, which updates the databases listed in section 2 when a new resource is created. Members are linked with their donations, making ownership explicit. The collaboratory administration also provides a means for members to collaborate in creating resources or in offering workshops, supporting prosocial activities in A9 and A10 respectively.

The administration activities promote prosocial behaviors such as help-giving. Fulfilling member’s requests for resources is a help-giving activity, A6, but other ways of help giving are possible. In open collaboratories, where nonmembers have access to the collection, information about joining the collaboratory is offered via web page, in activity A2. With activity A7, members can choose to be informed of resources that other members with similar profiles have found useful. If desired, activity A8 will put these members in touch with each other. A10 and A11 provide virtual space and infrastructure respectively. These spaces act as common meeting ground for members holding a discussion, offering a workshop, sharing a resource, or creating one.

A number of the administrative activities of the collaboratory are meant as a way of gaining recognition for members, acknowleding their contributions to the collaboratory. The purpose of the member, resource, organization, and correspondence databases, maintained through activity A1, is to acknowledge contributed resources. A member profile is maintained for all collaboratory members in activity A3. Members can find information about each other via these profiles. When a new resource is added to the collaboratory, a thank-you acknowledgment is sent to the contributor. Additional acknowledgments might be sent to members’ organizations as well, as a way of publicly recognizing the value of the contribution. Acknowledgments are sent in activity A4. When a resource is contributed, it is sometimes helpful to have more information about its design or use. In such cases, activity A5 generates email to the contributor requesting more information. Activity A7, suggests resources to members. This activity provides recognition by tacitly acknowledging that members belong to a community. The collaboratory recognizes and ‘remembers’ members and their actions. Evaluative reports created in activity A12 can also be used as a way to provide recognition. The reports can be used in collaboratories that offer awards or rewards for outstanding contributions.


5.2.2 Value Adding Administrative Activities
Donating is the defining activity for adding value to the collaboratory. The value added by donating is enhanced by administrative activities like A1, which updates the resource database. The size of this database and the member database are indicators of the net worth of the collaboratory. Activity A3 assures that contributors are also members. Furthermore, administrative activities help members to create new resources, by providing workspaces, A9, and other infrastructure supports, A10. Problems encountered while creating resources can be directed to collaboratory technical support staff, A11. The administrative side of the collaboratory can also ‘donate’ by turning certain types of feedback and queries into resources, or by encapsulating them with Handles and assigning them keywords and descriptions. This is done in activity A13. A14 creates new resources directly by duplicating existing items in the collection using other common file types. For example, an Excel spreadsheet might be turned into a gif file. In this case the new file is linked and associated with the original resource.

Adaptive indexing is accomplished primarily through the updating of the resource database in activity A1. If information about a resource is inadequate, activity A5 will solicit additional information from the contributor. Among other things, the new information can be used for indexing. Activity A12 solicits feedback from members who use a resource. Feedback will include requests for additional keywords for resources.

The collaboratory administration also maintains a database (in activity A1) of feedback collected from users in activity A5 and passed on to contributors in activity A4. Collecting feedback also provides data for reports highlighting future needs and directing the activities of the collaboratory in activity A12. These reports might be of interest to vendors outside the collaboratory who are interested in creating and testing products designed to meet the needs of the collaboratory community.

Value is added by administrative activities through outside searching also. If while fulfilling member requests for a resource, activity A6, the collaboratory locates the resource on the Internet, the site is added to a directory of sites with resources of interest to users. This database is maintained by activity A1.

Another administrative activity that adds value is collaborative browsing, which is supported through administrative activity A7. In this activity, information about resources and searches is made available to members based on their profiles. In activity A8, members with similar interests are matched up, making it possible for them to share their search strategies and results. Activity A9 opens spaces for members to use for collaboration as they search for interesting resources. Browsing can also incorporate evaluative information gained from past actions in activity A12 (Twidale et al.,97).


6. Performing Member Activity M1
In the prior section, 23 activities aimed at implementing strategies for building a successful collaboratory identified. Describing the capabilities needed to perform all these activities is beyond the scope of this paper. The capabilities that support a single activity, M1, are described in this section. In M1, users contribute resources to the collaboratory. M1 was chosen, because it precedes the other activities. In the section below, an existing system that supports this activity is described. Following this, is a description of the same activity performed in a collaboratory that supports prosocial and value added behaviors.


6.1 The Inquiry System in 1999, performing M1

Figure 2: The current Inquiry Page collaboratory.

The Inquiry Page collaboratory, a joint product of the Schools of Education at Purdue and the University of Illinois, Champaign Urbana is in its first incarnation. Currently it consists of a web site with pages of information about Inquiry Learning and a question web which is a directory of links to the resources in its database. A web form has been designed that will allow users to submit a description of their Inquiry lessons along with the URL to the resource. Another HTML form is provided as a template to support teachers who are inexperienced with Inquiry Learning or don’t have access to a web server. A FilemakerPro CGI script reads the information submitted through the web forms and uses it to update a database with fields corresponding to each piece of information.


6.2 Enhancing Inquiry Page Activity M1
The current collaboratory does not draw upon the potential of the system to incorporate prosocial behaviors as a way of building and strengthening membership in the online community. Nor does it provide a means to add value to resources through use. Some activities that could be added to the M1 activity are to:
6.2.1 Capabilities Needed for the M1 Activity Enhancement
In order to add the enhancements necessary for the M1 activity, the system needs the following capabilities:
6.2.2. Affordances of Software Agents
The list of capabilities in section above are adapted from Bradshaw’s (1994) article describing the capabilities of software agents. Software agents are high level programming objects. They are designed with properties and methods that make it easy to adapt them for certain programming tasks. As with all high level languages, flexibility has been traded for ease of use and speed in programming. For example, it is impossible (or at least extremely difficult) to build a software compiler using software agents as they usually lack devices for direct computer memory manipulation. Software agents are designed to be used as building blocks in systems that need the particular functions listed above. New agents can be added to agent systems indefinitely, providing they “know” the communication language of the other agents within the system. In the next section, the capabilities needed to provide the M1 enhancements will be matched with capabilities of software agents in order to demonstrate the suitability of using an agent system to accomplish the M1 activity in the collaboratory.

6.2.3 The Enhanced Collaboratory, Performing M1
From the point of view of the contributing member, donating a resource to the Inquiry Page Collaboratory, looks the same whether the activity is performed in the current system or in the enhanced system. However, the capabilities of the new system use prosocial and value added activities to encourage members to contribute to the collection. In activity M1, these strategies include:
Figure 3: The Enhanced Inquiry Page collaboratory.

Performing activity M1, contributing resources, in the enhanced collaboratory sets a number of agents into action. First, the Member’s Agent is identified. If the user submitting the Inquiry Lesson does not have a Member Agent, one is created. The Member Agent contains a log of member activity, including search histories and contributions. The agent also contains profile information such where the member works, and an email address (which might be used to identify the member's organization). Member’s profile information and history can be edited by the members themselves. Ideally this agent would reside on the member’s server.

Second, the Member Agent calls for a new Resource Agent to be created. The Resource Agent consists of a ‘Handle’ containing the URL and the keywords and/or description of the resource. In addition, the Resource Agent checks to see if the resource can be converted into a more common file type. If so, a copy of the resource is created in the new file type, which then resides as part of the Resource Agent. The Resource Agent also contains a usage counter and other fields used for evaluation.

Third, the Resource Agent sends a communication to the Broker Agent which advertises the resource using keywords supplied by the Resource Agent. Fourth, the Resource Agent sends a request for acknowledgments to the Mediator Agent. Finally, a timer is set up within the Resource Agent that will activate periodically in order to test the link to the resource. (If the link is broken for several days, the Broker Agent and the Mediator Agent are notified. The Broker Agent takes the advertisement off-line for that resource and the Mediator Agent contacts the contributor.)

The Mediator Agent handles communication between the collaboratory, the contributing member, and the outside world. Most correspondence is handled through the correspondence database. The collaboratory correspondence needs to be extremely adaptive in order to support human activity, which is, in itself, unpredictable. Much of the human-like behavior in the agent system comes from the personalized correspondence generated by the Mediator Agent. In the Inquiry Page collaboratory, the Mediator Agent acknowledges new resources to the contributor, his/her school and school district.

The Broker Agent contains a centralized index of the resources available. It also has a list of Member Agents along with pertinent profile information. When a new resource is received, it is entered into the Broker Agent’s database. Advertisements for new resources are also emailed to other members based on information given and options selected in their member profiles. Depending on the volume of collaboratory activity, these notices can be sent periodically in the form of a catalog.


7. Discussion
The last section presented detailed specifications for a single activity performed by the collaboratory. Creating the specifications for an enhanced collaboratory is a simple task. The task of augmenting software agents to perform the activities described herein is also relatively minor, as suitable agents are available commercially (Infosleuth,99). A more difficult task is processing natural language queries. Fortunately proprietary parsing engines are also available today (Basch,99). The ultimate difficulty in building an enhanced collaboratory is in creating the correspondence database with the text necessary to automatically generate email to members and their organizations.

By and large, the task of creating and maintaining the correspondence database will fall to humans. Software agents do not have the innate ability to interact with humans. They can only make a selection from a list of responses based on a given criterion. The task of maintaining the database is complicated by the likelihood that the enhanced collaboratory might effect the way members do their work, which will, in turn, effect the tasks the collaboratory needs to perform (Yates, 93). This means the activities of the collaboratory must adapt to the changing needs of its members. While this continuing evolution of the collaboratory is worthy goal, collaboratory projects, such as the one proposed here, are never complete.

Given a task so daunting needn’t be discouraging. The upside to needing human labor is that humans can manually perform the activities that implement the strategies aimed at building a successful collaboratory. If, for example, an activity relies on correspondence, the query parsing activities humans perform manually can be captured and the text of the correspondence they generate can be added to a database. When a similar event occurs again in the collaboratory, the activity is performed by software agents mimicking human parsing behavior and using the correspondence database. The author refers to this process as “augmented design”. Software agents with general capabilities will be augmented to perform specific tasks throughout the life of the collaboratory. With this design process, the collaboratory is fully functional from its inception and automated over time. Moreover, while collaboratory activity is low, the human labor requirements are also low. As activities increase, labor requirements are expected to increase proportionally for a time, then level out as activities become automated. Figure 4, below, illustrates this.

Figure 4. The collaboratory at critical mass.

In Figure 4, when point A occurs, the need for human labor ceases to be proportional to the value of the collaboratory.
b1 < b2
At this time, the value of the collaboratory increases, but its development costs remain relatively constant. The collaboratory can be said to be at critical mass. Future research is needed to validate whether or not this can be done.


8. Summary
A collaboratory is an online community where members share ideas, information and digital resources. It can be viewed as a way of collection development where the task of building the collection falls to the users of the collection rather than an administrative staff. This way both the cost of the resources and the work of collecting them are distributed.

The challenge in building a collaboratory is achieving a critical mass of participating members. Gruden and Palen (1995) report that CSCW systems, such as a collaboratory, that reach the state of critical mass are likely to succeed. Critical mass is defined as threshold of individual contributions and/or actions that must be reached in order to produce a public good. For the collaboratory to become a public good it must reach a state where its value increases with use, while the cost of its operation does not. In order to accomplish this, two strategies have been proposed;
  1. Find ways to encourage prosocial behaviors.
  2. Find ways to add value to the collaboratory when members use it.
These strategies need to be automated in order to keep the cost of operating the collaboratory low in proportion to its activity.

Twenty-three activities are suggested as methods of implementing the two strategies. A single activity, contributing a resource to the collaboratory, is explored in depth. This is done by providing a description of the method currently used for adding resources to a collection. It is followed by a description of the same activity enhanced with strategies for promoting prosocial behavior and adding value from member activity. A list of capabilities needed to support the enhancements for this activity is provided. A match is made between the capabilities needed to enhance the activity and the functionality that can be provided by software agents. This match demonstrates the suitability of using software agents to perform this activity in a collaboratory.


References
Basch, Reva (99). High Ajeevers: Valet-added searching from Ask Jeeves.Database, 22(3), 28-34.

Bradshaw, Jeffrey M (1994) “An introduction to software agents.” In Software Agents. J. Bradshaw (Ed.), AAAI/MIT Press, Menlo Park, California, 1997.

Brief, Arthur P. & Motowidlo, Stephan J.(1986) Prosocial organizational behaviors. Academy of Management Review, 11(4), 710-725.

Connolly, Terry & Thorn, Brian K.(1990). Discretionary databases: Theory, data, and implications. In J. Fulk & C. Steinfeld (Eds.), Organizations and Communication Technology (pp. 219-233).Newbury Park:Sage Publications.

Constant, D., Kiesler, S.B. & Sproul, L.S.(1996). The kindness of strangers: The usefulness of electronic weak ties for technical advice. Organizational Science,7(2), 119-135.

Crown, Deborah F. & Rosse, Joseph G.(1995) Yours, Mine, and Ours: Facilitating Group Productivity through the integration of Individual and group goals. Organizational Behavior and Human Decision Processes, 64(2),138-150.

Fulker, David, Bates, Sally & Jacobs, Clifford (1997).Unidata: a virtual community sharing resources via technological infrastructure. Bulletin of the American Meteorological Society,78(3), (457-468).

Furnas, G.W., Landauer, T.K., Gomez , L.M. & Dumais, S.T.(1987). The vocabulary problem in human-system communication. Communications of the ACM,30(11),964-971.

Grudin, Jonathan (1989) Why groupware applications fail: Problems in design and evaluation. Office: Technology and People, 4(3)245-264.

Grudin, J., and Palen, L. (1995). Why Groupware Succeeds: Discretion or Mandate?, In Marmolin, H., Sundblad, Y., and Schmidt, K. (eds.), Proceedings of the Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work (pp.263-278). Kluwer Academic Publishers: Dordrecht.

Infoslueth (99). Available at: http://www.mcc/com/projects/infosleuth2.

Karamuftuoglu, Murat, (1998). Collaborative Information Retrieval: Toward a Social Informatics View of IR interaction, JASIS, 49,1070-1080.

Knoblock, Craig A. & Ambite, Jose Luis (1997).Agents for information gathering. In Software Agents, J. Bradshaw (Ed.), AAAI/MIT Press, Menlo Park, California.

Oliver, Pamela, Marwell, Gerald & Teixeira, Ruy (1985). A theory of the critical mass: I. Interdependence, group heterogeneity, and the production of collective action. American Journal of Sociology, 91(3) 522-556.

Schmidt, Kjeld & Bannon, Liam (1992). Taking CSCW seriously: Supporting articulation work. Computer Supported Cooperative Work,1(1-2), 7-40.

Sun, Sam X. (1999). “Handle System: A persistent global naming service”. Internet-draft available at: http://www.handle.net/draft-sun-handle-system-01.html.

Twidale, M.B., Nichols, D.M. & Paice, C.D. (1997). Browsing is a collaborative process. Information Processing and Management, 33(6), 761-783.

Wellman, Barry, Carrington, Peter J. & Hall, Alan (1988).Networks as personal communities. Chapter 6 in B.Wellman and S.D.Berkowitz (Eds.) Social Structures:A network approach (pp.130-184).

Wellman, Barry, Salaff, Janet, Dimitrova, Dimitrina , Garton, Laura, Gulia, Milena & Haythornwaite, Caroline (1996). Computer networks as social networks: Collaborative work, telework , and virtual community. Annual Review of Sociology, 22:213-38.

Yates, JoAnne (1993). Co-evolution of Information -Processing Technology and Use: Interaction between the life Insurance and Tabulating Industries, Business History Review, 6 (1), 1-51.