torus6.gif (1371 bytes)


cctext.gif (2384 bytes)

Services Tips Theory WebPoems Workshops Books Articles Lisa Jonathan

Our Articles ...

On Complex Documentation


  On Personalizing Content

On Complex Documentation

  On Kids' Software

On Home Software

On TV and Video

On Art, Poetry, & Drama

Using complexity theory to understand what's happening to technical communication

Speech to IPCC 97, October, 1997; final version available in Proceedings, IEEE Professional Communication Society, 17-27.

Jonathan Price

Complexity theory offers concepts that can help technical communicators understand the exponential growth in the volume of inter-related and interacting information objects as the result of the law of increasing returns, which has brought us through a phase transition to a new environment, with emergent properties, demanding new behaviors.

As organizations expand the amount of information they expect us to publish on the World-Wide Web, the work-world of technical communicators grows more complicated. We see tools changing every few months, we watch our responsibilities seem to shift even more quickly than they did five years ago, and we see that our ideas of what we do for a living must face, to put it mildly, some adjustment. In talking with other technical communicators, I hear several interrelated questions coming up with increasing intensity:

* Why are so many of our organizations heading for the Web so fast, and why does it keep changing so often?

* How can we organize and control the enormous volume of material we are asked to put up on our organization's Web site? How can we read, edit, or even conceive of the thousands, even millions of different documents we are supposed to shepherd onto the site?

* Is anyone really in charge of the Web, or our corporate Web site?

* Is what's happening to us just another flurry of technogreed? Or have these changes really taken us to a new level, an environment in which new properties emerge, and new behaviors are required?

To make sense of what's happening, I suggest we turn to some ideas developed in such disparate fields as economics, biology, neurosurgery, anthropology, and artificial life. Pioneers in each of these fields have begun developing theories specifically to cope with situations that are too complex to explain by earlier principles. Complexity theory is not yet a unified, single idea. But, through the work brought together at the Santa Fe Institute, originally a spinoff of Los Alamos but now a completely independent thinktank, we see parallel approaches in many disciplines. Perhaps complexity theory can help us, as technical communicators, understand the work world in which we find ourselves.

One, two, many complexity theories

In a complex system many, many independent agents interact with each other in so many different ways, building together, exchanging objects, that the agents seem to be spontaneously organizing themselves into one new system after another-systems that adapt to changing circumstances, always playing at the edge of chaos, that is, with components that never crystallize into a fixed structure, but never fly out of control, either. "The edge of chaos is where life has enough stability to sustain itself and enough creativity to deserve the name of life," as Waldrop remarks in his brief history of the growth of complexity as a discipline, focused at the Santa Fe Institute, in Santa Fe, New Mexico. (Waldrop, 1992, p. 12)

We can see that such complex, adaptive systems bear some resemblance to the systems we have to deal with in technical communication, most spectacularly, the World Wide Web. Because so many of us are caught up in transforming legacy documents for use on company intranets or extranets, let me use the Web as an example of the complexity we face.

* Growth of the Web, and any one information site, seems to have a life of its own, as the Web itself seems to be organizing itself, veering now in one direction, now another, without following discernible principles, more like a crowd in motion than a rational or law-abiding individual.

* The Web cannot be said to be run by anyone; individual agents interact, and the Web is the result, whether they are students putting up home pages, government agencies posting every regulation they ever issued, or companies tossing documentation, press releases, and the annual report up on the corporate site.

* Within this system there are many levels of organization, each building on the blocks below.

* Increasing returns dictate many fads. Each site changes, adding, for instance, more video, which bogs down the system, which forces Internet Service Providers to buy more high-end routers, which encourage more people to put up more video, and soon, you have an avalanche. These bursts of increasing returns occur every two or three months.

* The system changes by reorganizing and revising its building blocks in response to multiple inputs from millions of agents.

* The system seems to anticipate the future, preparing for certain circumstances, and if those occur, redoubling its effort in those directions.

* Within the whole World-Wide Web there are niches, in which individual agents, or groups of agents, adapt to live as parasites, predators, or symbiotic partners.

In this paper, I'll borrow some ideas from the work of several complexity theorists to give you an intellectual model for grappling with the changes that are taking place around us.

But First a Caution

We have no complexity theory for communication. We should, but we don't. What I am about to suggest is that there are some interesting analogies between the thoughts of several complexity theorists and our own situation, as technical communicators. But analogies are not science.

Metaphors, Berthoff remarks, can act as "speculative instruments." Speaking specifically of writers, she says that when we create metaphors for the work we do, we use these artifacts "to find out what we are trying to do." [1981, p.7] Metaphors are tools for thinking, feeling, sensing, comprehending.

But, if we treat them as a complete explanation of an experience, metaphors fall apart. Beck, for instance, surveyed metaphors that technical communicators use to describe themselves, and found each useful at suggesting part of the work, but limiting when treated as a complete explanation [1991]. For instance, adapting the Shannon-Weaver model of communication, which says we are transmitting ideas along a channel to receivers, despite the noise in the system, several authors describe us as transmitters. Beck comments, "Taken to an extreme, this model equates the dissemination of an environmental impact statement with the dissemination of confetti." [1991, p.5]

The model I'm about to present resembles a dollhouse or tabletop railroad, more than a mathematical model. As King points out in his meditation on "Models as Metaphors," dollhouses and toy railroads are like other forms of metaphor [1991].

* They let us represent something in miniature, which means we emphasize salient aspects, dropping many details, to give the impression of the original. [King, 1991, p. 106; LÚvi-Strauss, 1966, p. 23]. We change the scale, to look at essentials. [King, 1991, p. 107]

* They abstract the processes involved, letting us move through an artificial world in neatly repeatable patterns not always available to us when we are on the ground, in the real original. (King, 1991, p. 113)

* They let us manipulate the model in "as-if" scenarios, without having to affect the system we are exploring, as Watson remarks on his work on DNA, [Watson, 1980, p. 201) Such manipulations often give us a new perspective on the original, and a feeling of control (King, 1991, p. 110; Wyschogrod, 1990, p. 244)

Obviously, it would be wonderful if we could control our environment simply by adopting a new model. But, because we can't work that magic, let's borrow some ideas that have mathematical substantiation in their own fields, and play with them as glimpses of the world around us.

Increasing Returns

As we wonder what tools we should use for our next project, we ask ourselves which companies will survive for two or three more years, and which competitor will win. We can imagine several possible outcomes, but we cannot be sure any will occur, and we face the likelihood of an unpredicted avalanche, in which a surge of customers ratify one particular product, even if it is not the best. We are interested in getting our work done, but we must choose tools in an economic context that is increasingly governed by the law of increasing returns, a law which is a particular favorite among complexity theorists.

Traditional economics postulates a steady state, or equilibrium. Based on observations of an 1880's economy based primarily on bulk production, the law of diminishing returns argued that any company that won an advantage in the market place would eventually bump into some kind of limitation, so that prices and market shares would settle into equilibrium. But in a knowledge-based economy, Arthur argues, you have more pockets in which the underlying mechanism follows the law of increasing returns.

Increasing returns are the tendency for that which is ahead to get farther ahead, for that which loses advantage to lose further advantage. They are mechanisms of positive feedback that operate-within markets, businesses, and industries-to reinforce that which gains success or aggravate that which suffers loss. Increasing returns generate not equilibrium but instability: If a product or a company or a technology-one of many competing in a market-gets ahead by chance or clever strategy, increasing returns can magnify this advantage, and the product or company or technology can go on to lock in the market. [Arthur, 1996, p. 1].

Arthur argues that technology comes in waves, and during each wave, the market is unstable, tilting quickly toward one winner (rather than preserving multiple competitors with fixed market shares for each). In high technology, the upfront costs are so high that competitors are easily frozen out; no one company can create every product needed in a certain area, or ecology, such as local area networking, or printing, so to maintain a lead, the major players must carefully develop a web of supporting developers, and once begun, such a web reinforces the leaders; customers demand that everyone on a particular network be able to communicate (tilting toward standardization), and customers find the products so difficult to learn and use that they never want to learn another. Increasingly, a company depends on the next killer application, and therefore must reorganize into smaller teams, with more ability to set off on a new quest, develop hot products, and create new markets than ever before. "Every time the quest changes the company needs to change. It needs to reinvent its purpose, its goals, its way of doing things. In short, it needs to adapt."[Arthur, 1996, p. 6]

Many of us live within this economy, so our whole organizations live or die by the law of increasing returns on our products. But, as technical communicators, we may see a similar law at work when we find ourselves mounting thousands of documents on a Web site. Some quickly become more popular than others; a tidal wave arises, with email, phone calls, and pressure in meetings, as users ask questions, point out problems, demanding more, more, more about that particular topic. Like a product surging to market domination through the law of increasing returns, the Web has taken over our world.

Agents and Dispersed Control

In an economy, we are all agents buying and selling, making individual economic choices that coalesce with millions of other choices to reenforce one product's market share, or drop another like a stone. No one person can be said to be in charge, not even Allan Greenspan, head of the Federal Reserve. Of course, there are many other levels of agents in an economy, from the Mom-and-Pop store up through corporations to the Department of Defense, and international whoppers like AT&T. But even with agents on the large scale, we cannot say that any one agent controls the economy. So we are faced with millions of agents, at various levels, all pursuing their own self interest, who work together, somehow, to create the complex system of an economy. It is in this sense that complexity theorists say that an adaptive system appears to organize itself.

You need a lot of agents, though, to create such a complex, adaptive system. And now the number of agents is increasing in technical communication.

The advent of the Web has confronted us with the millions of other people who are contributing to the vast, interconnected network of information. Instead of being able to hang out with our own, we must now mingle with every other department, posting their materials, conversing with them by email, helping them post information for customers and other staff. Even our customers become fellow publishers.

We may have felt we controlled out destinies, a little, in the past; but with the Web, control is so dispersed throughout our own company, and then throughout the Web, that we see our acts become statistically, not individually, important. We have become part of a trend. The number of fellow agents we have to consider has expanded from the one or two needed when we wrote an installation booklet, past the dozen or so needed for a suite of documents or a big hypertext, to thousands. That's an exponential jump, and it means that what we work with, and how we work, will never be the same again.

Building Blocks

Complex adaptive systems grow through the interactions of many agents, who put together small chunks into larger chunks, building much bigger phenomena. An aircraft manufacturer, for instance, brings together subassemblies from hundreds of subcontractors to keep the assembly line going; in turn, each subcontractor may have relied on dozens or even hundreds of sub-subcontractors to supply boxes of bolts, flanges, and valves. The system, then, depends on thousands, even millions of tiny building blocks.

What are the blocks we must work with as we create our niches in the complex adaptive system known as the Web? At a fairly high level, we could say that an entire suite of documents concerning a particular product line might form one block. But we need to make connections within that block, so we must also consider the electronic documents as blocks, at a lower level. But within those documents, we must also jump from place to place, so we need to consider the information objects within our materials. To understand these low-level building blocks, we take a cue from the object-oriented approach to software design [Gamma, et al., 1995;Martin & Odell, 1992;Taylor, 1992; Yourdon, 1994].

Each type of object has its own function. In a communication, each type of object has been created to answer a particular kind of question we expect from users. For instance, over time, technical writers have recognized that many users ask the question, "How do I accomplish a task using your product?" The response comes in the form of a procedure. The question "Where do I find the gizmo? is answered with an illustration. Each information object, then, has its own job to perform.

* Objects send messages to each other, triggering actions. You can see this most clearly if you think of a hypertext link as an object that sends a message to a glossary definition saying, "Please display the answer to the user question, 'What does this word mean?'" The other object, receiving the message, performs its job.

* Objects also have attributes. One attribute is the data an object contains-the actual text, or picture, or sound. Other attributes might include the author's name, departmental owner, subject matter (keywords), date, file format. (Such attributes become extremely useful when you need to locate, say, all the objects dealing with a particular subject, created in 1997.)

* Taking an object orientation helps us rework legacy documents so they perform their functions more efficiently. We can more easily spot one object masquerading as another (a procedure step that merely announces a result), an object that fails to perform its function (a conceptual overview that leaves out key concepts), an object that lacks required components (a command reference without a discussion of parameters). Thinking in terms of objects helps a writer or editor analyze an existing document, spot objects that fail, and repair them.

* If we have a mandate to move to SGML, or XML, the effort to identify the objects buried within our documents also helps us create our Document Type Description [Goldfarb, 1990; Travis & Waldt, 1995; Turner, et al., 1996; Van Herwijnen, 1994]. But even if we have managed to postpone conversion to SGML, the effort to think in terms of information objects helps us clarify the structure of our materials, and strengthen their effectiveness. Even equations can be looked at as built up from individual objects; hence, a user can click on any one expression and go directly to the passage explaining it. Because of the object-orientation, the equation becomes interactive.

* Identifying individual information objects allows us to reuse some, and ignore others. Reusability becomes very important whenever you want to be able to present users with customized selections from your information; essentially, you can use one set of objects for one document you print on demand, then reuse some of those, but not all, in an email message to a different client. With an object orientation, searching, filtering, and reporting on selected objects becomes much easier than rereading, copying, and pasting. [Price, 1997]

* As we become agents on the Web, we find ourselves thinking more like information facilitators than writers. We need to help others post information, exchange information, receive information. We need to provide access to giant databases of frequently answered questions, bug reports, technical support responses, and we may need to recast all earlier documentation in object-oriented databases [Christophides, et al., 1994; Croft & Stemple, 1987; Dobson & Burrill, 1995; Guting, et al., 1989; Gyssens, et al., 1989; Koch, 1997; Yoshikawa, et al., 1996]. Instead of spending most of our time creating individual documents, or even coherent hypertext systems like Help, we must act, increasingly, as hosts at a very large party, in which all the guests are talking at once. Being able to pick out individual objects and dispatch them to a customer on the fly helps us perform our new role more quickly than if we had to look up a document, look for a passage, copy it and paste it into our email.

* Looked at this way, the Web as a whole is an assemblage of found objects, objects that were lying around at hand, invented objects, what LÚvi-Strauss (1966) called a bricolage. What is astonishing, though, is the scale. An average 300-page manual, with 100 different types of objects, may have a total of 20-odd objects per page, or about 6,000 objects. Now combine that volume with the other 200 manuals from your organization, plus several hundred press releases, data sheets, price lists, white papers, sales brochures, speeches, and the contents of half a dozen gigantic databases, and you have, well, a lot of objects to deal with. That change in the volume of objects you and your fellow agents have to "relate to" takes the information through a phase transition, and results in properties and behaviors you may never have had to cope with before.

Emergent Properties and Phase Transitions

Imagine a molecule of water. Two hydrogen atoms hang onto an enormous oxygen molecule. Atomic physicists know how that molecule works, and can express those workings in mathematical equations. But what happens if you put a lot of those atoms together? "Suddenly you've got a substance that shimmers and gurgles and sloshes. Those zillions of molecules have collectively acquired a property, liquidity, that none of them possesses alone." [Waldrop, p. 82]. That liquidity is not inherent in the original molecules; rather, it is a property that emerges.

When new properties emerge, the ensemble-the lake, if you will-becomes capable of acting in new ways, freezing, flowing, and steaming. Bring in an Arctic front, and the water on the surface becomes crystalline as ice; that water has gone through a phase transition. Warm it up, and the lake becomes liquid again; bring in a heat wave, in the early morning, and you can see the substance go through another transition from one phase to another, as the mist rises up, in vapor. These behaviors, impossible to predict by looking at a water molecule, are emergent.

Physicist Philip Anderson [1972, 1988] points out that when objects gather together on a large scale they tend to coalesce into a new, more complex phenomenon, acquiring emergent properties and exhibiting emergent behaviors.

At each level of complexity, entirely new properties appear. At each stage, entirely new laws, concepts, and generalizations are necessary, requiring inspiration and creativity to just as great a degree as in the previous one. Psychology is not applied biology, nor is biology applied chemistry. [1972, p. 2]

If we consider the brief history of technical communication, we can see that we have gone through several phase transitions of our own.

Phase One: Traditional Composition. The document appears on paper, and gets distributed physically. When word processing appears, it sweeps through the technical writing field like wildfire in the 1980's, in its second or software wave (on personal computers), eliminating typewriters in most shops.

Transition: Hypertext Makes Documents Interactive. Envisioned by Vannevar Bush [1945] and Ted Nelson [1987a, 1987b], hypertext came out of the academic ghettos with products like Owl's Guide(r) and Apple's HyperCard(r), giving technical communicators a way of making interactive documents that could serve as help systems, and computer-based training [Nielsen, 1990].. Small events, magnified by positive feedback, set a trend, locking people into a technology that hardly looked important, back in 1986 and 1987. Prigogine (1980) compares this mechanism to the gentle breeze moving over water in the Caribbean, urged on by sun, reenforced by the heat, becoming that complex structure known as a hurricane. As a result of this phase transition, we saw help systems appear everywhere, and CD-ROM disks pop out of companies, loaded with corporate info, in the early 1990s. The emergent property, here, was the ability to establish links from one piece of information to another, electronically, so users could jump hither and yon in ways we cannot completely predict.

Phase Two: The Information Designers. Now writers had to work together as a team to produce a series of modules (not published documents, or even chapters) that could be linked together to form a single hypertext. But we still saw our hypertext as a single coherent assemblage of information.

Transition: The Web Expands. A little tinkering in a nuclear research lab, and Tim Berners-Lee comes up with a little protocol for transferring files with embedded graphics and, oh yes, hypertext. From that tiny start, the Web has taken over the high-tech landscape, another instance of increasing returns blessing a particular technology, forcing even powerhouses like Microsoft to change direction, to respond. Now, knowing that every document in the building is in electronic form, management wants them all put up on the Web, by tomorrow afternoon. We see that the increase in volume is leading to emergent properties such as the exponential growth in communal conversation.

Phase Three: The Web of Participants Now each writer must respond to a constant influx of email, or shuffle it forward to subject matter experts; subject matter experts must go online more; customers expect to get answers within twenty-four hours, so writers are no longer working solo on a fixed document that gets published and can then be forgotten. Instead, writers must pursue a particular subject like a reporter on a beat, updating the online information on a weekly basis, and engaging in a wide-ranging conversation with users, other staffers, and engineers.

How does Growing Complexity Affect our Work?

Of course, as writers and editors, we may still be working on some Phase One jobs, creating individual paper documents, and some Phase Two jobs, putting together single, coherent hypertexts like help systems.

But increasingly we must look below the level of document, or even single hypertext, to recognize that the building blocks we have been using are thousands of individual objects such as procedures, definitions, or screenshots. We may now find ourselves building a web of connections between millions of these objects, not just between documents, or within one document. Here are some other ways our work may change:

* We may find ourselves designing the flow of information, rather than creating individual packages of information; we'll certainly have to work more closely with systems analysts and designers over in Information Technology (IT) departments.

* We may find more of our actual writing is done for online delivery via email, short articles for the Web site, two-paragraph notes for the database. We'll be under pressure to be brief, informal, to the point.

* When we edit, we may find we are focusing on Level Three editing (larger issues of structure and purpose), less on Level Two (consistency and coherence within the prose), and just skimming for Level One accuracy and correctness. [Buehler, 1981; Bush & Campbell, 1995)]

* We may have to do more work creating databases of information objects, less creating independent books, brochures, help systems, CD-ROMs.

* We may have to develop search mechanisms that let users filter out certain types of objects (no introductions, please), or focus only on other types (just the procedures).

* We may be called on to grab quotes, chunks, bits, and pieces, and package those in our email responses, bulletin-board postings, and chat responses, so that we can provide the latest specific information to users, even if it has never been published in a book, and may never appear on paper.

* We may have to get involved in regular ongoing conversations with customers, developers, other staff, and subject matter experts, through email, chats, and bulletin boards, as the representative of our organization, focusing on a particular topic. We may even have to act as a host.

* We may become impromptu consultants.

Managers may need to reconsider the way they assign staff to projects. With less emphasis on getting a new set of books out for each release, and more on updating electronically, managers may need to assign one writer to monitor and update the information about a particular product or product line, on an ongoing basis.

* Instead of checking on progress toward a completed book, you may need to set weekly and monthly quotas for number of emails responded to, number of postings to the bulletin board, number of updates (no matter how minute) made to the electronic documentation on the web site.

* You may need to integrate more closely with the engineers who set up and run the web site, the engineers who maintain the corporate databases.

* You'll definitely need more technical support people to tweak server software, database software, and online publishing software.

* Time-frames for planning will shrink because of the speed of change on the Web.

* You'll have fewer projects that reach closure, like books; most will simply be ongoing assignments, plus a few major development projects.

So the future looks complex, but perhaps, if we consider it in the light of complexity theory, we'll see that we're still at the near edge of chaos.


Anderson, P.W., "More is Different," Science, 1972.

Anderson, P.W., Arrow, K.J., and Pines, D., (Eds.), The Economy as an Evolving Complex System (Santa Fe Institute Studies in the Sciences of Complexity, vol. 5). Redwood City, CA: Addison Wesley, 1988.

Arthur, W.B., "Competing Technologies, Increasing Returns, and Lock-in by Historical Events." Economic Journal, 99 (1989), 116-131.

____. "Positive Feedbacks in the Economy," Scientific American (February, 1990), 92-99.

____. Increasing Returns and the Two Worlds of Business. Santa Fe, NM: Santa Fe Institute, 1996. (Reprinted in Harvard Business Review, July 1996).

Beck, C.E., "Implications of Metaphors in Defining Technical Communication," Journal of. Technical Writing and Communication, 21:1 (1991), 3-15.

Berthoff, A.E., The Making of Meaning: Metaphors, Models, and Maxims for Writing Teachers. Montclair, NJ: Boynton/Cook, 1981.

Buehler, M.F., "Defining terms in technical editing: The levels of edit as a model," Technical Communication, 28: 4 (1981), 10-14, 1981.

Bush, D.W., and Campbell, C.P., How to Edit Technical Documents. Phoenix, AZ: Oryx, 1995.

Bush, V. "As We May Think," Atlantic Monthly., July 1945. Reprinted in Literary Machines. Palo Alto, CA: Project Xanadu, 1987.

Christophides, V., Abiteboul, S., Cluet, S., and Scholl, M.. "From Structured Documents to Novel Query Facilities," Proceedings of the ACM-SIGMOD International Conference on Management of Data, Minneapolis, MN: 1994, 313-324.

Croft, W.B. and Stemple;, D.W.. "Supporting Office Document Architectures with Constrained Types." In Proceedings of the ACM-SIGMOD International Conference on Management of Data.. San Francisco, CA: 1987, 504-509.

Dobson, S., and Burrill, V. "Lightweight Databases," in Proceedings of the Third International World Wide Web Conference. 1995.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.

Goldfarb, C. The SGML Handbook. Oxford, UK: Clarendon, 1990.

Guting, R.H., Zicari, R., and Choy, D.. "An Algebra for Structured Office Documents," in ACM Transactions on Office Information Systems, 7:4 (1989), 123-157.

Gyssens, M., Paredaens, J., and Van Gucht, D.. "A Grammar-Based Approach toward Unifying Hierarchical Data Models," in Proceedings of the ACM-SIGMOD International Conference on the Management of Data, Portland, Oregon (1989), 263-272.

King, J.R., "Models as Metaphors," Metaphor and Symbolic Activity, 6:2 (1991), 103-118.

Koch, C. "Authors, authors, everywhere," WebMaster, 1:7 (January, 1997), 36-40.

LÚvi-Strauss, C., The Savage Mind. Chicago: Univ. Chicago, 1966.

Martin, J. and Odell, J.J., Object-Oriented Analysis and Design. Englewood Cliffs, NJ: Prentice Hall, 1992.

Nelson, T.H., Literary Machines. Palo Alto, CA: Project Xanadu, 1987.

______.Computer Lib/Dream Machines, (Rev. Ed.). Redmond, WA: Microsoft Press, 1987.

Nielsen, J. Hypertext and Hypermedia. Boston, MA: Academic, 1990.

Price, J.R. "Introduction: Special issue on Structuring Complex Information for Electronic Publication," IEEE Transactions in Professional Communication, 40:2 (1997), 1-9.

Prigogine, I., From Being to Becoming: Time and Complexity in the Physical Sciences. San Francisco, CA: Freeman, 1980.

Taylor, D., Object-Oriented Information Systems: Planning and Implementation. New York: Wiley, 1992.

Travis, B., and D. Waldt, D. The SGML Implementation Guide: A Blueprint for SGML Migration. Berlin, Germany: Springer-Verlag, 1995.

Turner, R.C., Douglass, T.A.,and Turner, A.J. Readme 1st: SGML for Writers and Editors. Upper Saddle River, NJ: Prentice Hall, 1996.

Van-Herwijnen, E. Practical SGML. Berlin, Germany: Kluwer, 1994.

Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and Chaos. New York: Simon and Schuster, 1992.

Watson, J. D. The Double Helix. New York: Atheneum, 1980.

Wyschogrod, E. "The Logic of Artificial Existents: John Dewey and Claude LÚvi-Strauss," Man and World, 14:3, 235-250.

Yoshikawa, M., Ichikawa, O., and Uemura, S. "Amalgamating SGML Documents and Databases," in Proceedings of the 5th International Conference on Extending Database Technology, 1996, 259-274..

Yourdon, E., Object-Oriented Systems Design: An Integrated Approach. Englewood Cliffs, NJ: Prentice Hall, 1994.

Copyright 1998-2001 Jonathan and Lisa Price, The Communication Circle
Return to our site at
Email us at