Diary

Internal Reports

Completed Papers

Papers in Progress

Conference Presentations

Site Visit and Quarterly Reports

Main DLI Page

Web Client- DeLIver

Making Infrastructure: The Dream of a Common Language

footnote 1.

Laura Jeanne Neumann

Professor Susan Leigh Star

12 June, 1996

Please address correspondence to Laura Neumann.

Abstract

How does one understand the connection between emerging infrastructure, knowledge, and practice? Can the principles of participatory design be applied in large infrastructure projects? What scales and what does not? We address our experience as social scientists co-developing a larger digital library project funded by the US government. We focus on how to understand the ways in which potential use, new and old infrastructure, and large project organization interact. We use three concepts: commitments, object worlds, and trajectories, and their associated processes (crystallization, maintaining ambiguity, finding users, and building wtih the inertia of the installed base). We discuss the importance of linked visions and dreams as well, drawing on Verran- Watson's notion of "imaginary."

Resources appear, too, as shared visions of the possible and acceptable dreams of the innovative, as techniques, knowledge, know-how, and the institutions for learning these things. Infrastructure in these terms is a dense, interwoven fabric that is, at the same time, dynamic, thoroughly ecological, even fragile. (Bucciarelli, 1994: 131)

Tell that its sculptor well those passions read Which yet survive, stamped on these lifeless things -Percy Bysshe Shelley, 1817

How does one understand the connection between emerging infrastructure, knowledge, and practice? Can the principles of participatory design be applied in large infrastructure projects? What scales and what does not? In this paper we address our experience as social scientists co-developing such a project, part of a larger digital library initiative funded by the US government. Through participation and interviews with designers, we focus here on how to understand the ways in which potential use, new and old infrastructure, and large project organization interact. Throughout, we struggle with a kind of paradox: good working infrastructure is transparent to use, yet good participatory design makes the problematics of use visible.

There have been some excellent studies of the development of large-scale infrastructure in recent years. Hughes studied the development of the electricity networks in America. A technical and political campaign of grand magnitude marshaled many kinds of networks in order to get the infrastructure up and running (1983). But information systems also have some unique aspects. Unlike electricity or water, they are simultaneously technical and semantic -- bits are not simply undifferentiated matter being piped over the net. Additions and modifications to the infrastructure are highly decentralized and subject to dispute. As well, there are hundreds of standards to be adjudicated. Whether the system is "working" or "not working" may be much less clear than whether or not enough "water is coming out of the tap." No one, in short, is in charge of large-scale information systems. No one has an overview, and there is in fact no overview to be had (Hewitt, 1986). This is both for reasons of scale and scope, but also because semantics mean interpretation, and interpretation means differing viewpoints.

After over one year as social science partners on a large information infrastructure- building effort, we are struggling to understand how these complex degrees of coordination and interpretation involved come to work together, when they do. In this, we are linking the historical work on the building of infrastructure (Hughes, 1989; Bowker, 1994a and 1994b, Bowker and Star, 1994; Desrosires, 1993) with the ethnography of technical design (Forsythe, 1993; Henderson, 1991a and 1991b; Suchman, 1987; Bucciarelli, 1988 and 1994) and the sociology of scientific knowledge.

Articulating a large infrastructural project within a globally changing electronic infrastructure is no easy matter. The challenge for us is no less than simultaneously to understand the work practices of designers and users, the emergence of large-scale technical systems, and the encoding and decoding of information, including its heterogeneity and disputed character as well as its conventional aspects. People understand these in a variety of ways, depending on where they stand in relation to the project. We draw on Watson-Verran's (1994) notion of connecting epistemic imaginaries used to communicate across cultural understandings to envision how it is that infrastructure building might in fact occur through the interaction of diverse groups. We also draw on social psychology (Becker's concept of commitments (1982) and side bets (1960) and medical sociology (Corbin and Strauss, 1988; and Timmermans'(1995) use of the notion of trajectory).

Project Background

In 1994, as part of its commitment to the National Information Infrastructure (NII), the US government funded six digital library projects at different universities (under the Digital Library Initiative, called "DLI" for short). The projects range in topic from geographical information systems, to indexing of archived public television footage, to general navigation tools for full-text retrieval and web retrieval. Eventually, it is hoped that the six projects and affiliated efforts will form the basis for the conversion of substantial public library resources into internet-accessible format. Our project at the University of Illinois, "Building the Interspace," is geared toward engineers and computer scientists. It has a major methodological component which is developing protocols for federating repositories of data.

Within the DLI effort, there are several subprojects, each with differing foci and levels of involvement. The Testbed Team is constructing working prototypes for deployment in the local engineering library and on campus; the testbed is eventually to migrate to the world wide web. The National Center for Supercomputing Applications (NCSA) is developing a complex architecture for public repositories of electronic text and cyberspace navigation; they are as well working on user interface issues. The Interspace Team is developing next-generation protocols and smart thesaurii for the transfer of information across federated repositories of data, which themselves employ a wide range of standards and formats. Several departments, NCSA, and the University Libraries are all investing some resources in the project. In addition, the project is aided by the Corporation for National Research Initiatives (CNRI) in Washington, a high level corporation and policy advisor to the NII about such issues as copyright, control and access.

Our subgroup, the Social Science Team, has a mandate to study potential and actual use of prototypes, and the web more generally; as well as to understand how the work of engineers will be impacted/impact the growth of the information infrastructure. Coordination of the subprojects at Illinois is the purview of the office of the principal investigator and an executive committee from the University, as well as the funding agencies. The project is geographically distributed across the campus, spanning a distance of a couple of miles in some cases, as well as the infamous "north of Green Street/south of Green Street" cultural division between the College of Engineering and the liberal arts and professional schools.

Our Social Science Team has from the beginning articulated a commitment to a 3-way relationship between users, designers and social scientists, following in a general way the principals of participatory design originating in Scandinavia. We were especially concerned with trying to fit our formative evaluation work to the ideal of this method: close contact and communication between designers and users, via a series of mutually-generated, iterative prototypes. We understood that these are continuously modified for the best fit to the target workplace, and are important in maintaining clear lines of communication between designers and users (B¿dker, et al., 1991; Ehn, 1988 ). To this end, we have conducted usability studies with the emergent testbed, plus observations of current users of electronic systems in the traditional library, focus groups with potential users, and interviews with faculty and staff. However, we had difficulties in fulfilling what we saw as our role in participatory design. Project communication was not often clear or straightforward. The trajectory of the project was much more complex than we originally anticipated and we found it difficult to establish our role or find our niche. Sometimes it was hard to either define or find the prototypes. This paper is an attempt to frame this stage of the project in a way that may be helpful to project managers and others working in the participatory design tradition or similar venues.

The material in this paper draws primarily on interviews we did with project staff and with university faculty, as part of gaining an understanding the different aspects of design and project coordination, as well as concerns of potential users. Our studies of potential users are reported elsewhere.footnote 2

The central problem for the entire Digital Library Initiative, including our Social Science Team, is to locate themselves within a rapidly-changing external environmental ("the net" or "the web"), while being innovative enough to capture scientific attention yet serviceable enough easily to work for a range of as-yet unknown users. Our focus on infrastructure here means that these qualities (which are common in any engineering project) have the added emphasis of a kind of trajectory of self-erasure, as we noted above. That is, good working infrastructure is almost invisible to the user: ready-to-hand, transparent, and quietly supportive. Star and Ruhleder (in press) define the qualities of infrastructure in the following fashion (p.4 of manuscript):

For our project to be a successful one, these qualities need to become part of our "end product." Fulfilling these criteria is no simple matter. Each has repercussions in the day to day choices in people's work as well as the overall construction of the project. A wide variety of participants on our project, each with their own perspectives and agendas, must be accounted for. The bounds of the project must be managed so that each of these varying efforts can be included and yet can also be give the space to be creative. The difficulty occurs in doing the articulation work and talking across the boundaries of each group to create common understanding.

Watson-Verran's "Imaginary": Creating a Meta- Language

What is the most successful outcome of the DLI? World peace. It sounds like a Miss America question. I don't know. On a big picture scale, I would say that the scientists, around the world even, not just ethnocentrically in the United States, are able to communicate better and not do as much competitive work, in that they rely on each other for what they are doing so that they enhance their own work. And hopefully bring... well, this does sound like a "world peace" question and answer... enable some leapfrogging as far as underdeveloped nations. Doesn't that sound like a world peace answer? (DLI 11, p.5)

Although the nitty-gritty of budgets, code and copyright negotiation is critical to the Interspace effort, dreams and visions must also be meshed for a successful project. Helen Watson-Verran's analysis of the relationship between farmers and Aborigines in Australia gives us an important tool for imagining one aspect of the successful outcome of linking these visions. She uses the term "ontic-epistemic imaginary" to describe the whole material-cultural field of working-dreaming. Linking these imaginaries, she asserts, means that both Aborigines and farmers must come to understand the legitimacy of each others' dreams and practices. Traditional Western science has often excluded this aspect of things from, in her case, the discussion of the quantification of land areas or the ownership of land, "Through our practices of quantification with their denied imaginary, we know and own land, maintaining the myth that knowable space is at once ordered and empty. An outcome of this is that all space is equivalent; a uniform grid." (p. 16 of manuscript) She contrasts this with Aboriginal representation of space, which includes a recursion of kinship relationships and the particular local relationships each person has with the land:"The words of the song which celebrate this imaginary are not memorized. It is the general picture of the network of places and their interconnections that is memorized. This is a complex set of spatial images, a 'cognitive map' which can be understood as quite analogous to the Western imaging of qualities in material objects as held in varying extents pictured as infinite linear extensions, which can be made analogous to the infinitely extending line of integers." (p. 18) She goes on to note (just as in the DLI project):

"It is knowing the 'map,' which we can understand as a matrix of vectors with each place defined through relations of varying intensity and direction, and coming up with metaphoric insights to express this map in performing songs and stories, that is valued as Yolngu intellectual work. There is a correct 'map' which everyone knows in greater or lesser detail, but the 'map' may be expressed in more and less elegant ways" (p. 18 of manuscript).

There is logic and imaginary in both systems of knowledge, but Watson-Verran argues that the Aborigines have much to teach us about the co-constitution of "map and territory." "The people and the land come into being together, and thus are deeply implicated in and by each other. the inherent uncertainty, messiness, and multiplicity of action.." are included.

Watson-Verran goes on to discuss how by first recognizing and adding more imaginary into Western thought, both cultures can create common understandings by translating each side into a common metaphor or way of imagining the world. In so recognizing the imaginary in all of our world views, we can learn to talk between cultures and negotiate multiple world views.

One means of talking between world views is through common metaphors. These metaphors can be used as common points of understanding as well as a means for shaping how we make sense of what it means to build a piece of information infrastructure. In the course of the project and as we were writing this paper, we kept thinking of different metaphors to describe the different aspects of infrastructure. In trying to understand the course of self- erasure we thought of the monster as it rises and falls at the surface of the Loch Ness. In trying to think about the installed base, we liked imagining a game of Tetris, new pieces must be quickly fit into old. Finally, to deal with ideas about multi- dimensionality and interconnectedness, we have thought about textures in different bits of cloth that make up a quilt. These are difficult to get a handle on without some other means of talking about them, yet, it is important to do so because of the impact they have on what we are doing. We have not yet found a metaphor that we like well enough to promote, and still search for one that will carry the important aspects of infrastructure. But the very search for metaphors, shared by all project members, is indicative of the search for a shared imaginary in precisely Watson- Verran's sense.

Central Concepts: Commitments, Object Worlds, Trajectories

There are three central questions facing the builders of infrastructure which also impact designer-user relationships:

1. How do individuals come to make commitments to systems building projects, and on what basis? We use Howard Becker's model of "commitments and side bets" to illuminate this issue.

2. How can working systems builders find both interesting technical problems to solve and at the same time build a sturdy, usable piece of infrastructure? Many have noted (e.g., Star and Ruhleder, in press; Weedman, 1995; Markus and Bjorn-Anderson, 1987) the different incentive structures between designers and users and its impact on system development. Louis Bucciarelli's "object worlds" concept is useful in explaining more about this tension from the design point of view.

3. Since pieces of infrastructure, project members' problem solving, user's skill, acceptance, and problem spaces are all moving at different rates of development, how may they be coordinated while respecting the rhythms of each? We use Juliet Corbin and Anselm Strauss' concept of "trajectory," drawn from the complex work and biographical setting of chronic illness and care, to discuss this question.

In the concluding section, we show these are interrelated.

1. Commitments and Side Bets

How and why does a person commit to a large project? The article we use here, Howard Becker's "Notes on the Concept of Commitment," tries to explain the shape and consistency of a person's plans and actions without relying on the popular concept of psychological motive (1960). Becker presents a theory about how someone comes to enact plans as part of an organizational and biographical landscape, where multiple contingencies and guesses are as much a part of the act as what might later come to be retrospectively reconstructed as unproblematic motive-plan-outcome. His paper foreshadows Suchman's famous discussion of "situated action" (1987), perhaps not surprisingly, since both are arguing against a cognitivism which would place planning abstractly in the mind of an individual.footnote 3.

Becker's landscape requires negotiation and enticement of others in order to make a successful plan work. This often involves not just direct recruitment to the scheme, but tangential or linked stakes as well: "The committed person has acted in such a way as to involve other interests of his, originally extraneous to the action he is engaged in, directly in that action." (1960:35). An action becomes "consistent" as those things which are piled up onto the plan begin to take on increasing importance: "By his own actions prior to the final bargaining session he has staked something of value to him, something originally unrelated to his present line of action, on being consistent in his present behavior. The consequences of inconsistency will be so expensive that inconsistency in his bargaining stance is no longer a feasible alternative." (1960: 35)

So, for example, someone who is post facto committed to a religion has over a period of time mingled friendships, career possibilities, social networks, recreation, hobbies and perhaps romance in with the original ideals or beliefs. The notion of dedication is a composite of all of these things over time which shape the actions -- one did not join the church strictly in order to meet a mate, but that was a side bet in the joining, and once it occurred, added another element to the commitment to the religion.

No side bet, and therefore no commitment, is absolute -- they are always valuable within some specific group:

"Many sets of valuable things have value only within subcultural groups in a society and that many side bets producing commitment are made within systems of value of limited provenience.... These esoteric systems of value must be discovered if the commitments of group members are to be understood." (1960:39)

On any large project, the key to good management is precisely understanding these "esoteric systems of value" and the nature of the commitments they encompass. Failure to do so means project failure. Weedman (1995), for instance, describes the failure of Sequoia 2000, large information systems development project which linked computer scientists building systems for earth scientists. In an elegant analysis of the differing incentive structures for the two groups, she shows how the lack of technical challenge in the project for the computer people combined with the lack of career payoff for the earth scientists in "fooling around with machines" was fatal.

Within the DLI, one encounters a maze of subcultural side bets and multiple commitments, some of which are cohering into a larger group commitment, and some of which have not yet (whether they will or not is an empirical question):

On this project you just don't see people very often. So that is different. The other difference is that this isn't any body's real job. At {another job} that's all we did, and here it is just what everybody is doing for like a third of their life or something. So that makes it more amorphous than a real world project... because there, in the real world, it is something that people have to sit down and think out. (DLI 4, p.1)

In addition to the "side bets" in the form of how central the project is to someone's career, another important component is how to judge and count on others' side bets:

And seeing the different production constraints and the different sorts of database constraints... all finding a solution that works together. Getting the distributed repositories to work together and getting them to work together in a production mode where they can be continuously updated without having to have a lot of downtime. That is a lot of details that have to come together. (DLI 3, p.6)

Judging this complex interdependency is part of everyone's work on the project; several liaison people have been hired in recognition of the difficulty of doing so.

1.1 Multiplicity of Commitments

Infrastructure building is about designing linkages between multiple groups, making connections between many people, their world views, and their goals in order to make strong connections to extant infrastructure. In the case of the DLI funding agencies, publishers, software developers, librarians, and users all need to be brought together. In addition, while the project should build on an installed base, the infrastructure is also extending into the unknown. Each of these different groups has their own interests and idea of what this unknown will be, and their needs ideally should all be met.

The funding agencies have a more broad, national agenda that they would like to see played out in the project, which may or may not conflict with other project goals. Their vision, for the most part, is very large scale and their sense of direction is based on long time lines across many borders. The funding agencies for this project are jockeying for each individually funded project to be ready to merge with the other five at the end of the funding period. These projects, as mentioned, are quite different in their media and approach, and this task presents no small difficulty.

What role do you see the funding agencies playing?

They are driving it towards some national goals. They all have their own agendas for the national DLI, which I think they will push us toward to keep their funding. Which is good. I am glad, because they are the ones who are going to force this thing to globalize... ARPA, especially ARPA. They, ARPA, seem to be the ones who have the sharpest people. Every time I have had any discussions with them they know everything about what we are doing, they know all the technical ins and outs of the project and they know the political side to, they know the politics in Washington. Maybe ARPA is just more concerned and is sending higher level people.... (DLI 7, p.5)

In addition, as we pointed out earlier, the DLI has a very dual nature which is difficult to get a grasp of: it is both research and production of a working system. As one of our respondents pointed out:

I think part of the problems we have defining this project are due to the sort of schizophrenic demands made by NSF/ARPA/NASA in funding the six projects. The funders specified that there be a testbed component to each project .... and a research component and an interconnectivity component. All the projects are trying to better understand the testbed vs. the research component question. And NSF/ARPA/NASA themselves still seem fuzzy, at best, about the mix of testbed and research and evaluation and linkage. (DLI 13, p1).

The publishers involved in the digital library as well have their own set of interests. They provide SGML tagged text to the Digital Library on their own time, in return they want to learn how this process of producing digital, searchable text can be done. They are giving their materials to the Digital Library free of charge, but will not allow their journals to be displayed if the formatting of the text is not to their specifications. Negotiations with the publishers hinge on a mutual need, but the publishers are not in any way obliged to cooperate. Their investment in this project is based on their idea of future infrastructure including digital journals:

What about the publishers? Are they pushing the project in any particular direction?

They all have their own vested interest and they have got some specific goals in mind. Most of them have the same goals in mind, but we are really working in the same direction they are. (DLI 12, p. 5)

A significant part of the project is about juggling the specifics of the tasks at hand. The building of infrastructure is about grafting that new infrastructure onto the old. The new infrastructure must be compatible and recognizable to the old in order to be useful. But, to complicate matters, when a group such as the Digital Library project is building infrastructure for some future date, part of the work of the DLI is to project not only their place in the future, but also the positions of other components of future infrastructure. These multiple trajectories of old and new infrastructure must come together in time and space at some point in the future. This involves a great deal of guess work and prediction on the part of everyone involved in the project. It requires them to use tools that are new and unstable, truly "bleeding edge." In so using beta version software, the project is then required to also negotiate with software developers for functionality that is important to the Digital Library, but which is not necessarily of the highest priority for the software developers:

They have had enormous problems. It is very difficult to render scientific journals and put them on the screen. It is not easy to index them, as it turns out. And I think we have a very solid schema for doing this, it is just a matter of getting these recalcitrant software packages to work. A lot of this is outside of our control. We are relying, in a lot of ways, on commercial packages. And these are bleeding edge software packages and we are actually trying to take some of them and paste them together. And it is kind of like handling play- dough. (DLI 12, p.2)

This project in the future also presents even more smaller scale difficulties that are very problematic. Such things include figuring out how to render scientific equations when there is no standard format for doing so, mediating formats that are possible (through software companies) with the expectations of the publishers, and selecting a server and a programming package that will be able to stand the test of time and scale.

Thus the work of building infrastructure is about mediating demands of multiple groups and making connections between them possible. Additionally, it is about having a vision of where, in the future, all of these multiple trajectories will come together, facilitated by the infrastructure that is being built. The building of infrastructure is based on a certain amount of gambling with the future, and project members are very aware of that. Investments that they have made and are making in software, in standards, in a vision may or may not prove unfounded. One project member expresses this concern over the choice of the markup language for the database of articles:

What is a failed DLI?

Hmmm. That the whole world takes off in something other than SGML? That would probably be a big, major failure for the DLI. But since the other projects, the other groups are working on... the majority of them are also working in SGML, I would say that is not likely to happen, but.... I don't know. (DLI 11, p.5)

Everyone in digital publishing efforts at this moment is concerned with how large-scale "side bets" will play out: which markup and information interchange languages will become most widespread, and what effect that will have on current investments in computers and people's skills.

2. Object Worlds

How do designers reconcile the tension between innovation and users' demands for what is known and stable? Bucciarelli 's Designing Engineers (Bucciarelli, 1994) is an ethnographic study of engineering practice which addresses this question. It defines the "object worlds" within which engineers work, and analyzes how the ways that the fixed, reductionist, and Platonically ideal aspects of those worlds interact a) with the open-endedness of design, b) others' object worlds with whom engineers interact, and c) the life of the organization which dialectically shapes and is shaped by both of the above. The overall analysis he terms ecological (in a manner similar to (Star, 1995) and (Star and Griesemer, 1989)).

Because engineers design things that work, their practice is materially oriented toward what Bucciarelli terms "object world thinking." Those of us who have worked with engineers and systems designers will recognize the qualities of object world thinking:

These qualities are mediated by an iterative process of consideration and refinement, which Bucciarelli conceptualizes as a matrix:

"After the matrix has been filled once, the team reconsiders each option in turn and, focusing on those criteria that are poorly met, tries to reformulate the option to eliminate its deficiencies.... "(p. 152)

However, he notes, neither the list of object world characteristics nor this ideal inductive process become fully realized design. There is no absolute starting point for the matrix, nor any absolute closure. Rather, it is an iterative, practice-based process, and:

"The object is certain, determined, abstract, conserved, and so on. The process of designing is ambiguous and uncertain; there is the unknown. Ambiguity and uncertainty are especially evident at the interfaces where participants from different object worlds must meet, agree, and harmonize their proposals and concerns." (p. 188)

It is this very multiplicity which is both source of ambiguity and coin of the realm in large engineering projects. As Henderson has explored in her linkage of "conscription device" with "boundary object," tools such as engineering drawings or requirements both specify and serve multiple, even conflicting purposes. In addition, Henderson points to the very visual orientation of engineering work. The focus is on representations of the design object (Henderson, 1991a and b). All ethnographic studies of design (that is, those which include the lived experience of engineers and a sense of the cultural organization of engineering) have noted that the heterogeneous concerns of engineers cannot be reconciled by technology alone. Bucciarelli notes that "There is no overriding perspective, method, science, or technique that can control or manage the design process in object-world terms. The process... requires the participants to negotiate their differences and construct meaning through direct, and preferably face-to-face, exchange." (p. 159)

We have found precisely the tensions, and the iterative traversing of the matrix described by Bucciarelli, in our work with information systems designers. The Digital Library Initiative is made up of several distinct teams, each with their own emphasis, each with members from different disciplines and different departments where team members have other responsibilities:

You see the DLI as a big pie with little slices.... is there a goal that all the slices hold in common?

Well, we are all very interested in similar issues. We would all like to bring information systems... of what ever stripe, to people in general. They are different flavors, which normally predominate. Typically in technical realms, you make these minute, hair-splitting differentiations between the technical issues you are dealing with and you talk less about the fact that indeed, we are all more or less using or going toward the same goal. The technologies dominate in the discussion. So I would say we are all going to the same goal, however the methodologies and the techniques we are using are so different that they make us look separate and we are functionally separate in that sense. (DLI 1, p.2)

While the project is cooperative, these teams work very much on their own, the organization of the project is more along the lines of a loose federation, although in the end, the goal is to have an integrated project here at Illinois, and also to have an integrated project at the national level as well.

2.1 Multiplicity of Object Worlds

Typically each engineer has his or her own specific interest in a particular design problem or thing. This is not so in the world of building infrastructure. There is much more space between team members and between teams. The scope is greater, as it is bringing together the object worlds of many groups, embodying their standards and practices.

Thus the unity of infrastructure building projects is much looser than one focused on building a thing, rather than an "object world" we are dealing with a "objects universe." By leaving that much more space in the scope of the focus of the project, several things result. Teams are much more independent. Each team in and of itself has its own agenda that only loosely corresponds to the work as a whole:

There are several distinct chunks, but they all have a relationship to each other. Obviously if we don't build the testbed, you can't do the sociological research. And if we don't design some of the software that enables us to convert some of the scientific communications that include illustrations, equations, as well as text. If we don't design and build the software to convert that, then we can't build the testbed. So there are separate and distinct chunks but they have a relationship that come together in the overall project. (DLI 10, p.2)

Team members deal with this lack of rigidity by finding their own niche and focusing on that. In a sense, they have "downward focusing" on the project, many team members expressed their uncertainty as to what other people, particularly on other parts of the project, were doing.

I found myself working on little widgets like the keyword list and the keyword in context list and basically still sort of coming up on the learning curve of visual basic, learning how to access databases and manipulate data and those kinds of things, while still building some tools that are quite interesting. And then in January, I started tinkering around with thesaurus displays, that is where basically there was this rift in... me off doing my own little thing... now I am getting into the stage where I really have put myself on sort of the fringes of the group, or several groups. I am not doing what the group is doing, I am off doing my own thing. (DLI 3, p.3)

They were too far away from these other team members mentally and in work practice to follow what the group as a whole was doing. In some ways, the work of the rest of the project is actually irrelevant to the individual, asking a programmer involved in building repositories to follow what the social science team is doing would not be a fruitful use of time and energy for either team:

Explain the different components of the DLI?

Well, I am sure it does have components, but I am really restricted in what I am exposed to. I mean, this is it .... I haven't really been exposed to what is going on with the Interspace section or you guys [the social science team]. (DLI 8, p2)

This looseness in organization can also be problematic. Not surprisingly, problems crop up when teams are supposed to be coordinating work but the structures to do so are not obvious. Other problems include some frustration in not only communication but in vision for the project: This project is extremely disorganized, and resources haven't been allocated properly. We have had a lot of battles over that and.... I am not sure everybody is on the same page in this project. (DLI 12, p.3)

In addition to the diversity within the project, connections are also being created and maintained with other collaborating and cooperating groups. These links outside of the project are necessary, the new infrastructure being built must be compatible and imbedded in the existing infrastructure in order to be useful. The variety of groups being brought together in the space of this project is large, and each of these groups has their own interest in the project.

Sponsors want to see their money well invested in answering open questions about the nature and construction of digital libraries. To follow up on their financial support, they visit the project to see demonstrations of a prototype and what has been done. Their nudging in different directions stems further from there along varying levels of specificity and practicality for the project.

Yes, they [the funding agencies] are definitely influencing this project. They have some ideas which they have made clear to not just the DLI here, but everybody. ARPA, for example, does not see in 3 years having viable DLI projects, they are not interested in that. They are more interested in infrastructure issues, as well as the set way of doing things that people use. And that is their great goal. And what that really means is that they want all the 6 DLIs to work together and to come up with some common software products rather than specialized ones. NSF and, I think, NASA want to see products coming out of this work and they are really pushing for it. And they are pushing for all of us to be for us to be ready as soon as possible. So you see how this is driving us... they are dropping strong hints left and right. (DLI 9, p.3)

The publishers are involved in this project by giving marked up articles from their engineering, physics, or computer science journals. These articles come free of monetary charge to the DLI, but in return for the articles, the publishers expect the Digital Library Initiative to facilitate their introduction to the world of electronic publishing. The project is supposed to be able to answer questions for the publishers in terms of feasibility and usefulness of electronic publishing from the publisher's point of view. In addition, the publishers put strict parameters on how their articles must be displayed and whom is allowed to view them. In this way, they complicate the project's dealings with the people providing the software for viewing and in creating security measures for the digital library.

The Digital Library Initiative has different implications for each of the campus groups involved in it. For the University Library system, it is a testing ground for the new Grainger Library Laboratory which were set up to experiment with the university library of the future.

Well, there is a broader objective here. ... From a campus perspective, the DLI is a direct illustration of the collaborative environment that we have on this campus. Where the major units of this project have not been brought together just for this project. We have a natural relationship to each other. A successful DLI will point out the collaborative environment we have on this campus. Now a failed DLI will show some limitations in that collaborative environment and will question the effectiveness of the Grainger labs as an instrument for the development of the University Library. So that is looking at two different levels. (DLI 10, p.5)

For NCSA, it is a chance to work on developments in repository building and a chance to stretch the operations of Mosaic. For the individuals working on the project, the Digital Library ranges from being just a job and another line on a resume to being an extension of a career path that was begun twenty years ago in library automation.

Insofar as infrastructure building is about projecting and facilitating linked object worlds at some future point, this ambiguity and space in the project are necessary. When tasks are defined too rigidly or parameters set too narrowly, the connections that the infrastructure is meant to facilitate are compromised.

What do you like least?

There are so many different people in it that everyone has a different vision of what it is and I don't think it is really clear cut to anyone... I'm with the NCSA background, I have a completely different vision than the people over at Grainger, although the grad students have some similar ideas, but it is the people in charge who have somewhat different view points. So I think that that produces a lot of tension. It can be kind of stressful at different points. (DLI 7, p.4)

What do you like best about the project?

Can you refine that question? The people! [why?] In some ways, it is the cross disciplinary aspect. I function best in that environment, the cross-disciplinary approaches. Before I was not sure what sociologists would do, but now I know what you might be doing too. (DLI 9, p.5)

As Watson- Verran (1994) points out, communication across groups with different world views is made possible by flexibility, and imaginaries and metaphors are used to translate between world views. The attempt to bring so many dispersed and varying views together in one unified project necessitates a lack of specificity or all the diverse views and groups cannot be accommodated.

3. Trajectories

A trajectory is an analytical tool developed by sociologists Strauss and Corbin (Strauss, 1993; Corbin and Strauss, 1988) to describe the temporal shape of courses of action and events. Originally borrowed from engineering as a metaphor (for example, the trajectory of a bullet through air), it has a dual nature: "(1) the course of any experienced phenomenon as it evolves over time (an engineering project, a chronic illness, dying, a social revolution, or national problems...(2) the actions and interactions contributing to its evolution." (1993: 54) Complex phenomenon do not just "unfold" or "emerge"; they are collective accomplishments which are refreshed in the shaping.

Different aspects of the trajectory may have different rhythms or directions, and pull on each other. A fast-moving disease trajectory pulls the biographical trajectory metaphorically "down"; on the other hand, positive events in the family may pull the body's trajectory (even temporarily) "up." A career may be unaffected by minor chronic illness, or effects may be delayed by an individual's determination or dissembling.

Panorama {a piece of software used in the testbed} is another problem. They have been.... We have a shopping list of 10 major items that they have to have done before some of these publishers will let us show their journals to people. And we have been waiting all summer for them to get any of these 10 items done, and right now they have not. We talked the other day....

What will you do if they don't?

Well, we talked the other day and we have a plan now. As of 2 days ago, we have an alternative display format that we are going to start working with. (DLI 12, p.2)

Here, modeling others' trajectories and projecting into a mutual future becomes part of the project articulation work.

3.1 Multiplicity of Trajectories

As with commitments and object worlds, trajectories are also multiple. Respondents refer to the trickiness of timing as unknowns multiply:

And seeing the different production constraints and the different sorts of database constraints... all finding a solution that works together. Getting the distributed repositories to work together and getting them to work together in a production mode where they can be continuously updated without having to have a lot of downtime. That is a lot of details that have to come together. (DLI 3, p.6)

Team members must juggle and guess a variety of others' trajectories, or their best guess about them: Do you think the users should be playing a greater role?

No. Because we are in such a testbed stage right now. Maybe in 6 months. (DLI 11, p.3)

Creating information infrastructure means first forecasting what will happen in the future, then shaping the trajectories of work to converge at some future point. For example, in our project, the Testbed Team has chosen to do their work on IBM PCs and in Visual Basic, but no other parts of the project work on these machines or in this language. Translations of data must be made from where the journal articles are stored to where they are displayed; the interface must also be rewritten for the web. Juggling all of these in real time, situated daily practice is difficult.

Toward Boundary Infrastructures: Managing Multiple Commitments, Trajectories and Object Worlds

Multiplicity is inherently important in understanding a project of this nature, in the sense that there are many individuals, subprojects and interested parties all working both in parallel and serially. Project management tools, or analyses which use such concepts as "critical path," or even the complex multivariate analysis of operations research, often emphasize only one or two aspects of this multiplicity. Critical path, for example, gets at the notion of coordination across divergent temporal trajectories, and "what must be where" in order for a project to come together. It does not pick up on the tension between front stage and back stage issues (Goffman, 1959) in managing multiple side bets; that is, people may not wish to reveal exactly how far along they are on something, or make public the mistakes and messes along the way. They may not be able to take account of the complex ways in which people make and break promises based on mutual understandings of limitations and ambiguities in deliverables and longer-term relationships than a single project (see for example the critiques of Winograd and Flores' (1994- 1995)"Coordinator" system).footnote 4.

A working infrastructure consists of thousands of such arrangements, where both ambiguity (as needed) and structure (often in the form of standard) is afforded. Dšpping and Bowker have coined the term "boundary infrastructure" to describe how these tradeoffs are managed in nursing work.footnote 5. In some sense, the ultimate success of infrastructure comes in its self-erasure or invisibility; the ultimate success of a career or an enduring physical structure may be the opposite:

Do you have an influence over the outcome?

No, not the final product. I am involved in the intermediate products that have to work at a certain rate within certain error limits or that will effect the final product. I don't decide the final color that the menu comes up in... I think it is important ... but it is not... it is one of those deals where you know you have done your job right because nobody will notice. (DLI 8, p.4)

In watching the project develop, we get a peculiar sense of the Janus-faced nature of infrastructure: the different parties need to coordinate, cooperate, and have a good sense of each other's "inner workings", and they need to have the project represent different things for different audiences:

What comes next in this project?

The software stuff I think is going to continue. I think there is basically, an unlimited amount of stuff to provide systems to support the DLI as a production system. I know I don't have enough time to do all that and there are not enough resources dedicated to it. If you talked to someone about doing all this stuff, they'd say "well, this is a research project" so it is sort of a two faced project, what ever is convenient. You can call it a research project when things are klugey and then there are times when you call it a production system when you are not really doing research. It is kind of handy. (DLI 4, p.2)

The concept of boundary infrastructure begins with the notion of "boundary objects" developed by Star and Griesemer (1989). These are those scientific objects which satisfy the informational requirements of several communities; they are both plastic enough to adapt to local needs, yet robust enough to maintain a common identity. They are weakly structured in common use, and become strongly structured in individual-site use.

Boundary objects are good at describing medium-to-long term arrangements with some stability. Star and Griesemer conceptualized more wide-spread linkages between multiple boundary objects; systems of boundary objects, which as well have the characteristics of infrastructure (more fully developed in Star, 1994).

We conclude this paper with a focus on some of the processes involved in crafting boundary infrastructure, returning us to our initial questions about scalability and the use of participatory design in building infrastructure.

1. Crystallization

Analyzing biographical trajectories, Corbin and Strauss coin the term "crystallization" (1988:85) to speak of moments where the individual realizes clearly the direction and shape of a trajectory. They cite the experience of a patient who was paralyzed from an automobile accident, "who, when he first encountered a reserved parking spot for the handicapped, suddenly realized: 'The sign, I don't know, crystallized things for me...down to a little cold hard place inside me that said -- This is it'. " (Citing Nasaw, 1975:210). Chrystalization is a two- phase process; at first, one realizes what performances are no longer possible; then one regroups, and projects a new future.

This process is clear in the lives of DLI researchers as they encounter constraints (of funding, of choice of standards, of the web itself), crystallize their vision of what is now possible (and what is impossible), then move on to reconceptualize the DLI. This often takes the form of settling a negotiation about a particular software package, language, or standard. The choice to use Panorama to display the full text is a good example of this. This piece of software is not in its final version and changes still need to be made to it; the software developers are trying to make it marketable to a large audience and this sets their agenda, while the testbed needs it to display the articles in a way that will make the publishers happy. There are other choices:

Everything we are doing is not being done very well anywhere. So we are having problems. Everything we do is kind of out there, a leap into the unknown. We are running two different database packages, the Microsoft Sequel server and Open text. We spent a lot of time at the beginning of this project evaluating database software, deciding which database software we really needed, what we wanted to buy. And after a long evaluation process where we looked at Open Text and another package... and Ovid and OCLC and some of the Sequel packages, we decided that the Open text package would be most advantageous for us. (DLI 12, p.3)

The negotiation of how the full text articles will be displayed is up for grabs. It will be settled through negotiation between the software developers, the Testbed team, and the publishers. When a consensus is reached on this, issues of display, compatibility, and time investment will be crystallized.

2. Maintaining Ambiguities

The interaction of multiple commitments, object worlds and trajectories forms a project space which is filled with ambiguity. At this stage in the unfolding infrastructure, there are several threads attached to this ambiguity: the sense that "no one is in control"; the speed of external events and the difficulty of matching them to internal project trajectories and commitments; and trying to anticipate user needs.

In terms of the technical efforts, I see three. I see the testbed effort, I see NCSA and I see the research team, which I am a part of. And I have to make sure that these different components, at the critical time, they have to coalesce, that they will in fact coalesce... that the repositories, the semantic retrieval facilities- that is the thesaurus and the ... concept space and so on, at the full text indexing will all work together. (DLI 3, p.3)

In addition to these sorts of coordination issues, respondents also spoke of coordinating the different standards and packages in the project as a source of ambiguity. Competition is as well a potential source of ambiguity:

How do you see the different DLI teams working together (on the IL project?

When the other groups were here, when the other projects were here and we all broke up into smaller sections, I really felt that we were all supposed to be working together and intermingling. Talking about all the SGML problems that we had, talk about all these things we had, so that maybe as a big group of all the DLI projects together, we could all help each other to resolve them. And... I didn't feel like that at all, I felt like they were being competitive, like oh, we've got this and you've got that and we are not going to tell you. (DLI 11, p.5)

All of these sources of ambiguity can be a source of confusion and frustration for the people involved in the project. But as we pointed out earlier, some ambiguity is a necessary and inescapable component of such a project. This is because of the many multiple connections and linkages between groups and people and world views that are being built up; removing ambiguity would also necessarily alienate some elements of this project:

Overall, the problems we are facing in project definition and resource allocation and information technology application are quite common in these types of projects; they are probably intrinsic, organic, and maybe healthy. One needs to constantly question ones' methodology, focus, and raison d' etre. (DLI 13, p.1.)

3. Grappling with the inertia of the installed base

One of the greatest challenges in building infrastructure is making solid and robust connections with existing infrastructures. These must be taken into account and followed in a somewhat rigid way- the installed base presents and inertia that is not easily changed. Such connections are necessary for new developments to be useful. In addition, infrastructure building such as the Interspace project is also about making these connections at some point in the future. The area of computer software develops and changes at a blinding speed when compared with the rest of the world, what is brand new today is old hat and incompatible tomorrow. This world is extremely difficult, if not impossible to predict without a crystal ball. As one respondent pointed out, "people tend to underestimate what can be done in 18 months, but over estimate what can be done in 10 years." (DLI 7, p.7)

The testbed team is often caught up in dealing with contingencies and problems that arise out of things that they did not realize would be problematic. For example, as has been previously mentioned, the project is depending on publishers to mark up and deliver their own articles, which they are learning to do as they go along. SGML is not yet a "real" standard, and the testbed has to deal with variation in what they get from the publishers. These contingencies cause slowdowns. This again makes it doubly difficult to coordinate work with other teams within the project.

These elements of fundamental uncertainty as to the nature and dimensions of the testbed makes prediction difficult. On the largest scale, such as saying there will be a digital library in the future are easy to make and seem obvious. However the contours, the context, the functionality, and the scale of that digital library is up in the air. These questions can only be answered as time and work unfold.

Even so, in something of a contradiction, the work of the individual team member lies as a relatively certain path before each person. Team members have a fairly clear idea of what they will be doing in the upcoming months and even a year. This is another instance of the downward focusing that was discussed earlier, team members can visualize and understand small parts of the overall project quite well, but the greatest difficulty lies in figuring out how these small parts will come together.

4. Finding "Users"

The Social Science Team's responsibility is that of studying the users of the system. But immediately we ran into problems. Who are the users of a system that is not built? And, in addition, who are the users of an unbuilt system that changes seemingly on a daily basis?

In keeping with the ambiguity, space and variety of the rest of the project, the place of the users is also shifting and difficult to pin down. As discussed earlier, the actual testbed is in a constant flux due to difficulties with software, text markup, publishers, funders. Each of these groups and things are bringing their own biases and angles and each of these must be accommodated. This causes the testbed and the ideas about the testbed to shift and change as well. As the testbed shifts and changes, for example, because a new professional organization for computer scientists agreed to supply SGML tagged articles, and thus the effort to include electrical and computer engineers drops off, the envisioned users of the testbed also change. These sorts of shifts make it impossible for the social science team to begin a long term study of a group of users.

It would seem that time would weed out these practical difficulties, that eventually the focus of the testbed would be more or less set and more user studies and cooperative design could get under way. This is not yet the case. The testbed, as one user states, is "a leap into the unknown. No one has ever tried this before." They are, as was discussed earlier, using very new software, an unsettled markup language, and untried viewers. Their prototype is a collage of beta version software that they have been adapting. It is not robust enough for anyone, much less the unskilled "user," to touch. For this reason, it seems obvious to the testbed team that cooperative design and early user feedback is not possible.

Do you feel that the users influence decisions you make?

At this point, no. At this point, we are still building the capability to have a meaningful relationship with the users.

Do you feel the decisions for and the time to interact with users will be after the testbed is built?

Yes. Yes. In a sense the people who are involved in developing the testbed you might call informed users. We are all users, including those people making the system. But what we want to do is get to the point where we can have something that we can use to relate to a broader base of users. And that is when I think the users' influence on this project will be at its peak. (DLI 1, p.6)

The difficulty for the social science team then becomes the lack of articulation work going on between the testbed team and the social science team. While on the one hand we do not know and cannot know the details of what they are doing on a daily basis, we do need to understand how they are thinking about the users and what role they see the users playing. This is a great source of difficulty for us, coming from a totally different discipline, with very different expectations about how such a project would work. And, as happens with the other various groups and organizations involved, we look at the loose language of the original proposal and its mandates and find our own vision reflected. It is not, however, the same one that the testbed team holds.

Closely intertwined with this issue of user ambiguity is that of the differing meanings of the project as a whole for the people working on it. For some, there will be no real users of the system; they see the project as pure research. From this perspective the difficulties encountered with beta software and publishers' articles are not sources of frustration but of new information.

For others, they see the project as aimed toward producing a system that will contain X number of tagged, indexed and viewable documents, to be used by N users. These people are concerned less with answering questions and are more concerned with production of a viable production system. These people feel the project is user centered, although cannot be directly so just yet.

These conflicting views play out in different and interesting ways, but most obviously when people talk about the system and what it has to do with users.

Where do the users fit in?

Well, the users have not come into the project yet, because we don't have anything for them to use... so, obviously that is why I have not been talking directly about them. But as soon as we can get something out there, after that, they will have a role in interface development and that sort of thing. They are the ones... we are going to be trying to measure their response to all of this. So clearly, in terms of the future of the project, they are the ones that are going to determine the future of the project. (DLI 5, p.7)

These conflicting views play out in different and interesting ways, but most obviously when people talk about the system and what it has to do with users.

Imaginary and Metaphor: Airy Integration

Every cultural or ethnographic study of engineers and systems designers has alluded to the aesthetic pleasures of building, the visionary or even utopian language in which people speak of their work. At times this has been criticized as hype or techno-centrism (Kling and Iaconco, 1995), or seen as an externally motivating factor of sorts. Yet, if we are, in Latour's words, to stop reifying the great divide between primitive and modern (1993) -- and by extension between emotions and reason, situated and global, then the way to stop is to recenter the imaginary of engineering and systems development, as Watson-Verran suggests. The developers we work with see webs of access and information, as they talk one can almost "see" the world wide web:

What is the most exciting aspect of the Digital Library Project?

It is our future. This isn't just a research project that we will carry out and move onto something else. The Grainger is both an engineering library, and a laboratory for the University Library. And it is in those laboratories that we will help to define what the University Library will be in he future. So the most exciting part to me is actually bringing up a prototypical digital library and giving users access to it. (DLI 10, p.2)

Best possible outcome for Digital Library Project?

I think that too for them to be... to realize the way the technology is going and as long as nothing funny happens. Politics or what ever. As long as they realize which way it is going and we get a bunch of information providers on there, and it works out that we are storing and spitting out information in SGML or HTML or what ever formats people store them in, that is accessible by everyone for free, I think that would be the best outcome. With a variety of search engines, anything that allows it to be changed at any time. Flexibility and modularity are key, I think. If that gets built in... (DLI 7. p.4)

"Seeing" this map in more detail, imaginary intact, would mean an evolving infrastructure that affords multiple metaphors and dreams as well as standards and protocols. Watson- Verran suggests coming up with ways to talk about a combination of all points of view in a common metaphor that each person can make sense of. This metaphor could be used as a tool; managing ambiguity, very complex multiple contingencies, in a distributed and open-ended project is at the heart of crafting infrastructure. As in the case of Watson- Verran's "mediation" of a land dispute, we need to bring together various visions on a common ground that recognizes the validity of all points of view. A meta-language, even for imagination, needs to be negotiated.

Part of creating this meta-language is also part of creating a space for this project. Law and Callon (1995), illustrate how a space is created within the larger network for a local network and negotiation. A lesson we could learn from their analysis is that we need to build an internal project space where the elements necessary to build good infrastructure come together and where people working on our project can come together. A meta-language is not useful if there is no "safe" space in which to use it.

A lesson can be taken from Campbell's (1986) analysis of disciplines. One of the difficulties in academia specialization and isolation. While this is sometimes useful, it is often dysfunctional. Campbell calls for a "fish scale" model, where interconnections between schools of thought are easier because people are no longer sticking to a narrow specialty. Articulation work and "interdisciplinarism" is a part of everyone's work practices.

Lacking a crystal ball, we cannot predict the project's outcome, but it is at this stage "appropriately" messy and confused given the scope of problems and the range of people and things involved. What we do have at this stage in the project, in addition to multiple commitments, object worlds and trajectories, are partially overlapping visions, dreams, and senses of "the whole." While no one has an overview per se, each person and each team has a picture in their imagination of the territory to be covered, their own disciplinary roots and tools, and preferred styles of working. Each of these holds some part of our project as a whole, and none of these is embodied in one person. As Hutchins (1995) and others have pointed out, we need to recognize such social loci of knowledge. "When these have been assimilated, the locus of "truth" and"knowledge" will have clearly shifted from individuals "minds" to a collective social product" (Campbell, 1986). When this view is recognized, the need for a common meta-language is obvious.

Infrastructure building is different from more self- contained, object oriented projects; infrastructure links many communities of practice. Projects to build infrastructure are bigger, they involve more disparate groups with more multiple agendas so that the infrastructure can become an embedded part of many communities of practice. In order to build on the installed base, they require more connections to the outside world, and these connections must be stronger and tighter than on other projects. It is not just a matter of managing monetary and resource flows, but making the larger network active participants. The foci of infrastructure projects is something that is not usually visible to those involved, nor should the end product remain visible. This makes the project even harder to talk about. This leads to precisely what might be so difficult at the beginning of the project: creating common language and common understandings.

In infrastructure there is a sense in which map and territory merge. To design something is to use it, and there is no global testability. For these reasons, understanding commitment, object worlds and their paradoxes, and the myriad of trajectories involved is crucial. Linking them through shared imaginaries is one way in which infrastructure projects become successful.

We would like to thank our social science team members on the Illinois Digital Library Project for ongoing conversations and support: Ann Bishop, Pauline Cochrane, Emily Ignacio, Frances Jacobson and Bob Sandusky. The work of Geof Bowker and Jesper Dšpping on boundary infrastructures has been very helpful, and we thank our anonymous respondents, our project partners, for their time and generosity. The larger project is supported by the NSF-ARPA-NASA Digital Libraries Initiative. The URL for the project is http://www.grainger.uiuc.edu/DLI.

A different version of this paper has been submitted to the Participatory Design Conference for 1996.

Becker, Howard. (1960). Notes on the Concept of Commitment. American Journal of Sociology, 66: 32- 40.

Becker, Howard S. (1982). Art Worlds. Berkeley: University of California Press.

B¿dker, Susanne; Christiansen, Ellen; Ehn, Pelle; Markussen, Randi; Morgensen, Preben; and Trigg, Randy. (1991). Computers in Context: Report from the AT Project in Progress. Report of the 1991 MES-SAM Conference, Ebeltoft, Denmark.

Bowker, Geoffrey. (1994a). Information Mythology and Infrastructure. In Lisa Bud-Frierman (Ed.) Information Acumen: The Understanding and the Use of Knowledge in Modern Business. London: Routledge.

Bowker, Geoffrey. (1994b). Science on the Run: Information Management and Industrial Geophysics at Schlumberger, 1920-1940. Cambridge, MA: MIT Press.

Bowker, Geoffrey and Susan Leigh Star. (1994). Knowledge and Infrastructure. In Lisa Bud-Frierman (Ed.) Information Acumen: The Understanding and the Use of Knowledge in Modern Business. London: Routledge.

Bucciarelli, Louis L. (1988). An Ethnographic Perspective on Engineering Design. Design Studies 9: 59- 168.

Bucciarelli, Louis L. (1994). Designing Engineers. Cambridge, MA: MIT Press.

Campbell, Donald T. (1986). Ethnocentrism of Disciplines and the Fish- Scale Model of Omniscience. In Daryl Clinbin, Alan Porter, Frederick Rossini, and Terry Connolly (Eds.) Interdisciplinary Analysis and Research. Mount Airy, Maryland: Lomond.

Corbin, Juliet and Anselm Strauss. (1988). Unending Work and Care. San Francisco: Jossey-Bass.

Desrosires, Alain. (1993). Les Politiques des Grandes Nombres: Histoire de la Raison Statistique. Paris: Editions la DŽcouverte.

Dšpping, Jesper and Geoffrey Bowker. (1995). Personal communication.

Ehn, Pelle. 1988). Work-Oriented Design of Computer Artifacts. Stockholm: Arbetslivscentrum.

Forsythe, Diana. (1993). Engineering Knowledge: The Construction of Knowledge in Artificial Intelligence. Social Studies of Science 23: 445- 477.

Goffman, Erving. (1959). The Presentation of Self in Everyday Life. Garden City, New York: Anchor Doubleday.

Henderson, Kathryn. (1991a). On Line and On Paper: Visual Representations, Visual Culture and Computer Graphics in Design Engineering. Ph.D. Dissertation, University of California, San Diego.

Henderson, Kathryn. (1991b). Flexible Sketches and Inflexible Databases: Visual Communication, Conscription Devices and Boundary Objects in Design Engineering. Science, Technology and Human Values, 16: 448 -473.

Hewitt, Carl. (1986). Offices are Open Systems. ACM Transactions on Office Information Systems, 4: 271- 287.

Hughes, Thomas P. (1983). Networks of Power: Electrification in Western Society, 1880- 1930. Baltimore, MD: Johns Hopkins University Press.

Hughes, Thomas P. (1989). The Evolution of Large Technological Systems. In Wiebe Bijker, Thomas P. Hughes and Trevor Pinch (Eds.) The Social Construction of Technological Systems. Cambridge, MA: MIT Press.

Hutchins, Edwin. (1995). Cognition in the Wild. Cambridge, MA: MIT Press.

Jones, Patty. (1995). Personal communication.

Kling, Rob and Suzanne Iacono. (1995). Computerization Movements and the Mobilization of Support for Computerization. In Susan Leigh Star (Ed.) Ecologies of Knowledge: Work and Politics in Science and Technology. Albany New York: State University of New York Press.

Latour, Bruno. (1993). We Have Never Been Modern. Cambridge, MA: Harvard University Press.

Lave, Jean and Etienne Wenger. (1992). Situated Learning: Legitimate Peripheral Participation. Cambridge: Cambridge University Press.

Law, John and Michel Callon. (1995). Engineering and Sociology in a Military Aircraft Project: A Network Analysis of Technological Change. In Susan Leigh Star (Ed.) Ecologies of Knowledge: Work and Politics in Science and Technology. Albany New York: State University of New York Press.

Markus, M. Lynne and Niels Bj¿rn-Andersen. (1987). Power Over Users: Its Exercise by System Professionals. Communications of the ACM, 30, 6: 498-504.

Monteiro, Eric, Ole Hanseth and Morten Hatling. (1994). Developing Information Infrastructure: Standardization vs. Flexibility. Working Paper 18 in Science, Technology and Society, University of Trondheim.

Nasaw, Jonathan. (1975). Easy Walking. Philadelphia: Lippincott.

Neumann, Laura. (1996). What About Leech Treatment? Classification Systems, Women's Work, and Professionalization. Working paper.

Rich, Adrienne. (1978). The Dream of a Common Language. New York, NY: Norton.

Star, Susan Leigh. 1994). Misplaced Concretism and Concrete Situations: Feminism, Method and Information Technology. Working paper, Gender, Culture, Nature Network Series, Odense University, Denmark. June.

Star, Susan Leigh, (Ed.) (1995). Ecologies of Knowledge: Work and Politics in Science and Technology. Albany, NY: SUNY Press.

Star, Susan Leigh. (In press). Working together: Symbolic Interactionism, activity theory and information systems. In Yrjš Engestršm and David Middleton (Eds.) Communication and Cognition at Work. Cambridge: Cambridge University Press.

Star, Susan Leigh and Griesemer, James G. (1989) Institutional Ecology, 'Translations,' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-1939. Social Studies of Science, 19: 387- 420.

Star, Susan Leigh and Ruhleder, Karen (in press) Steps Toward an Ecology of Infrastructure: Problems of Design and Access for Large Information Spaces. Information Systems Research.

Strauss, Anselm. (1993). Continual Permutations of Action. New York: Aldine de Gruyter.

Suchman, Lucy. (1987). Plans and Situated Actions: The Problem of Machine-Human Communication. Cambridge: Cambridge University Press.

Timmermans, Stefan. (1995). Saving Lives: A Historical and Ethnographic Study of Resuscitation Techniques. Ph.D. Dissertation, University of Illinois, Urbana- Champaign.

Watson-Verran. (1994). Working Disparate Knowledge Traditions Together: Partially Connecting Ontic-Epistemic Imaginaries. Paper given at the Society for the Social Studies of Science, New Orleans, October.

Weedman, Judith. (1995). Incentive Structures and Multidisciplinary Research: The Sequoia 2000 Project. Paper presented at the American Society for Information Science, Chicago, October.

Winograd, Terry and Flores. (1994- 1995). Computer Supported Cooperative Work: An International Journal. 2, 3; 3,. 1. Boston, MA: Kluwer Academic Publishers.