Anna Cicognani
{anna@arch.usyd.edu.au}
Key Centre of Design
Computing
Department of Architectural and Design Science
Faculty of Architecture, G04
University of Sydney
NSW 2006
Australia
An hypothesis for developing a Design language in a text-based Virtual Community, such as a MOO, through verbs and properties is based on the idea that commands can be developed in analogy with Speech Act Theory. In particular, illocutionary acts are supported by the view that cyberspace is language based. The analogy can be developed with consideration of the seven components of illocutionary force, in virtue of which a Speech Act becomes performative, and affects the environment. In a text-based virtual environment (specifically, a MOO), commanding is performative: issuing a command could mean exchanging communication, retrieving information, or temporarily or permanently changing the environment. The permanent change of the environment can be considered Design. Citizens of a Virtual Community have the possibility of defining their own space, by creating new objects and associating behaviours to them: they are the designers, the builders, and the users of that environment. A set of Design commands would help these users to control their creations. In this paper, an hypothesis, currently under development in a MOO, is discussed.
Since Internet has started becoming more and more a mass medium, it also represents a repository of different interpretations and uses of the electronic space. Personalising one's own space on the Internet is more easily possible and attractive.
Online Virtual Communities (VCs), in particular, represent an increasing resource for people using the Internet as a tool for various purposes, among others, information exchange and storing, communication, socialisation. More and more frequently, these communities are populated by a variety of citizens who look for more interactive aspects of online tools. Apart from obtaining information, there is the possibility of interacting with other users and ultimately to "leave a trace" of themselves in the online community.
Virtual Communities bear a consistent aspect of how language is used and works through online tools. The linguistic nature of cyberspace (Cicognani, 1997) addresses solutions using linguistic theories for plans and interactions in virtual environments. In particular, the necessity of Design in and of virtual places is an uprising issue for citizens of cyberspace. (Cicognani and Maher, 1997)
Text-based Virtual Communities, such as MOOs (MUDs Object Oriented), are composite environments in which both in-real-time (synchronous) and delayed (asynchronous) communication can take place. Moreover, in MOOs, citizens (players) can build their own spaces and objects and define their own virtual environment. The construction of the virtual environment goes in parallel with its use by the citizens. Users are invited, and stimulated, to enrich the space with representations of it, creating and programming new objects to facilitate their and others' life in the VC. Players can be at the same time, designers, builders and users of the objects and spaces they create.
Design in Virtual Communities needs an appropriate linguistic and command register, and a set of behaviours for players, in order to gain importance as a constructive component of cyberspace.
So far, computer graphics representations have been the only way by which Design and architecture were supported by computer environments. However, CAD systems represent (only) a metaphorical reconstruction of physical objects in a computer-supported system: the tools that they make available are designed to represent, as faithfully as possible, how the object will look like in real life, once built. Representing appropriate structures, textures, detailed and perspective views of the object is the purpose of CAD and representation systems: they certainly help the designer in following appropriate procedures so that the final object responds to the brief.
Greatly different are the components involved in designing "inside" cyberspace. Text-based VCs do not rely on graphical representations to expose their content. Text, verbal language - or at the most, icons - are the ways of exchanging communication, and the only responsible for the programming of the environment. In text-based VCs there is an equality between how the objects look like and how they work. The descriptions of the objects correspond to their functionalities. Objects in MOOs are text-based, written in MOO code, and the whole environment, composed by descriptions, response messages, tasks, verbs and properties, relies only on the MOO database and interpreter. In this way, words can be used "to do things," they can perform actions.
To link the text characteristic of MOO commands, to natural language, I have used the linguistic theory of Speech Acts to build the analogy between issuing commands and pronouncing successful Speech Acts. A successful Speech Act is an utterance which respects particular conditions of feasibility and roles (such as, being a marriage celebrant, and saying "I pronounce you man and wife"). Once the analogy is built, I will try to describe how to define a Design language in such a community, so that players can be more active designers of their own environment.
MOOs do not actually support specific Design functions, and Design is limited to textual descriptions of how the objects look like, and other very few commands. From the analysis of several room descriptions, I extracted a selection of properties for designed virtual environments, and defined a set of prototypes and objects for virtual places, so that designers are helped in their task of setting up specific rooms with some features already available. The prototypes represent pre-designed rooms, containing some objects functional to the room's purpose (eg. a blackboard in the teaching room).
Then, I developed a special command (@sketch) to draft rooms according to the prototype chosen: it is described as a way of meta-designing in the virtual space. Sketching allows users with no programming skills to produce objects of a certain complexity.
Some issues are open and ready to be discussed. Firstly, the analogy between Speech Acts theory and commanding is built on the analogy between successful sentences and Design commands (which "do things with words"). Secondly, in the room descriptions, some adjectives and words describe but do not create the functionality of the space: they stop at the description itself. I believe that there is a way to use these words so that the description dynamically reflects the room functions and capabilities.
Finally, all the matters of Design in text-based Virtual Communities evolve around the questions: "What is Design in a VC? What is `designable?'" So far I have found that a few things can be designed: how to handle conversations, mail systems, and in general communication facilities, accesses and restrictions, editors, repetitive tasks. Certainly the Design of space belongs to a different nature, different from supporting tasks related to communication. The fundamental question to debate is, then: "How does the Design register change?" I argue that SAs Theory represents an analogy to create SAs for Design in a text-based VC.
The hypothesis developed finds application in a MOO based Virtual Community developed within the network of the Faculty of Architecture, Key Centre of Design Computing, University of Sydney (telnet://moo.arch.usyd.edy.ay:7777 or http:www.arch.usyd.edu.au:7778).
Linguistic theories study and research languages, how they work, how they change, and how we use them. In particular, Speech Acts theory (Austin, 1962; Searle, 1971) studies the relationships between utterances and performance, the effects and changes on the environment produced by sentences uttered in natural language. Uttering successful performative Speech Acts (perlocutionary acts) means changing the environment by force of the words uttered. For example: "I pronounce you man and wife," represents a successful act when both speaker and hearer(s) are in the conditions of successfully perform that action (eg. a marriage celebrant pronounces the sentence and the two people are willing to get married).
The conditions of happiness of performative utterances are important to state how and when utterances are valid, in a real situation. A performative utterance can be void, unhappy, in two ways: 1) the conditions in which the utterance is performed do not satisfy the requirements for the utterance to be successful ("I baptize penguins"); and 2) the utterance is issued insincerely (such as, I am not in the position to utter a certain sentence. "I fire you" without being in a position which allows me to do so). Also, it is possible that after the utterance is issued, there may be a "breach of commitment", where the speaker does not operate under the performance of the utterance. (Cicognani and Maher, 1997)
Cyberspace and Virtual Communities are language based (Cicognani, 1997), and they are places where commands have a great power in changing scenarios. The following table shows the differences between uttering successful Speech Acts and commanding:
Speech Acts
|
Commanding
| |
| Speaker
|
variable
|
variable
|
| Hearer
|
variable
|
not
needed
|
| Sentence/command
|
variable
|
variable
|
| Interpretation
|
variable
|
invariable
|
The analogy between uttering Speech Acts and issuing commands in a MOO can be demonstrated by virtue of the seven components of illocutionary force, the force which makes of a general SA, a performative SA. In this paragraph, I will explain this analogy, finding similarities, differences and characteristics which can be compared for the purpose of defining a Design language in a MOO.
In the MOO environment, what I consider Speech Acts, are neither the single verbs called by the software, nor the content of the output messages (which has been instead considered in the analysis by researchers of Computer Mediated Communication): they are the commands typed by the designers (players) in order to achieve a specific goal and permanently affect the environment, for instance, creating a MOO object. So, a command like:
@create $thing named my_notepad
is the kind of Speech Acts I refer to in this paper.
Computer Mediated Communication researchers analyse and study the content of messages issued by players using `@say', `emote' or `@whisper' or any other communication command. (Cherny, 1995; Curtis, 1992; Reid, 1994; Serpentelli, 1992) Design Speech Acts, as I intend them, deal instead with which properties, how and why, a verb modifies, and how other verbs and properties are chained to that result. Design Speech Acts permanently affect the Virtual Environment, changing properties, creating new objects, modifying existing verbs.
Issuing a command, equals uttering an illocutionary act; issuing a command with the proper syntax, so that the computer system responds in the way we planned, equals a successful illocutionary act. To validate the analogy between SAs in-real-life and Design SAs in a MOO, I will look at how SAs work in-real-life (IRL) and how they can be compared to issuing commands in the text-based virtual environment of the MOO.
Some observations can be made on the two kinds of SAs before starting a comparison:
* the issuing of sentences IRL and commands in a MOO can be considered similar, if they respect the conditions by which they are able to "do things," such as change the environment, real or virtual;
* intentionality and meaning, which play a major role in the performance of SAs, are two components which become fixed, not variable, in the MOO environment;
* the presence of a speaker and a hearer is required for IRL SAs to perform, whereas in a MOO simply issuing commands may be considered a performance;
* performance IRL is the change of status of the environment and the effects on the hearer and speaker; performance in a MOO is the change of properties of MOO objects;
* Design IRL cannot be directly performed via Speech Acts; Design in text-based environments can be a result of Speech Acts (commanding).
There are some conditions to be respected if we want a Speech Act to be successful. "An act of excommunication, for example, can be successful only if the speaker has the institutional power to excommunicate someone with his utterance." (Searle and Vanderveken, 1985, pp.12-20) I report here the components, as theorised by Searle, which make up the conditions for the success of a SA. Then, a comparison with SAs in a text-based Virtual Community is made.
Searle (1985) shows seven components which make of a Speech Act an illocutionary act, and, if satisfactory, that act will be performed. These components are:
1. Illocutionary point; or the purpose which is essential to that act to have some consequences. For instance "the illocutionary point of an apology for having done act A is to express the speaker's sorrow or regret for having done A."
2. Degree of strength of the illocutionary point; which remarks the difference, for instance, between requesting somebody to do something, and insisting that somebody do something.
3. Mode of achievement; the set of conditions under which the illocutionary point has to be achieved. For example: "a speaker who issues a command from a position of authority does more than someone who makes a request."
4. Propositional content conditions; by which the speaker commits him/herself to do what s/he uttered. "For example, if a speaker makes a promise, the content of the promise must be that the speaker will perform some future course of action."
5. Preparatory conditions; by which a speakers knows that s/he is in the position of make of that Speech Act, a successful one. For instance, "the assertion that the King of France is bald presupposes that there exists a King of France."
6. Sincerity conditions; where the speaker must reflect the psychological condition of the Speech Act pronounced. For instance, in an apology, the speaker must feel regret for having done the act s/he apologises for.
7. Degree of strength of the sincerity conditions; by which the speaker can express different grades of intentionality to perform the act, for instance an apology. "In cases where illocutionary force requires that the psychological state be expressed with a degree of strength, we will call that degree of strength the characteristic degree of strength of the sincerity condition.
Following these conditions, I will now compare the seven components for SAs in a MOO. I will call the speaker "player," respecting the terminology of the MOO. (Player has, in my view, a meaning of agent, or a person who acts in the MOO via commands; the word has an acting/action meaning more than a simple communication one)
Some of the above components can be transferred to Speech Acts in a MOO, some others can be considered constant, they do not change either if the SA is uttered in real life, or in a MOO. Therefore, the comparison would be as follows:
1. Illocutionary point: the issuing of the command makes up the illocutionary point of the SA. This component is transferable.
2. Degree of strength of the illocutionary point: the strength of the request does not affect the grade of performance; this component becomes irrelevant.
3. Mode of achievement: only if the player has got the right permissions and access to that particular command (authority), the SA will be successful. This component is transferable.
4. Propositional content conditions: the commitment by the player is not variable, since the issuing of the command corresponds to its performance.
5. Preparatory conditions: when attributing a new value to a variable, that variable must exist. If not, the software interpreter will not be able to perform the act requested. Also, the existence of the issued verb/command over a specific object must be verified. This component is transferable
6. Sincerity conditions: when issuing a command, a player may also "lie" (ie: not want to perform that command) but the software will not interpret that "lie" and simply will parse the command. This is not a variable for SA in MOOs.
7. Degree of strength of sincerity conditions: as for the degree of strength of the illocutionary point, this degree of strength becomes irrelevant, since the sincerity when issuing a command is not questionable.
It has to be pointed out how the issue of interpretation ceases to be relevant, as well as the strength and sincerity of how the command is issued. The software interpreter always reacts in the same way to the same syntax. The preparatory conditions of commanding deal with the respect of the syntax and the permissions of the player (mode of achievement); similarly the fact that the speaker is authorised to utter a SA and s/he is in the position of maintaining the promise, will represent happiness in the performative act.
In the following table, the components and their relevance in SAs in-real-life and commanding are summarised:
Component
|
Speech
Acts IRL
|
Speech
Acts in MOOs
|
| Illocutionary
point
|
Essential
for that act to have consequences.
|
Essential.
|
| Degree
of strength of the illocutionary point
|
It
may change the effect of the act. Variable.
|
There
is not ambiguity in a command. Not variable.
|
| Mode
of achievement
|
The
authority of the speaker is essential.
|
The
permissions of the player to issue that command are essential.
|
| Propositional
content conditions
|
The
commitment of the speaker is essential.
|
Issuing
the command already demonstrates a commitment by the player. Not
variable.
|
| Preparatory
conditions
|
The
conditions is which the SA is uttered must be favourable to its success.
|
The
player and the software must be ready to perform that command. Essential.
|
| Sincerity
conditions
|
The
SA can be unsuccessful if it is not meant.
|
The
command issued does not include the intentions of the player. Irrelevant.
|
| Degree
of strength of sincerity conditions
|
It
may change the performance and the effect of the SA.
|
Irrelevant.
|
The idea of designing with words is independent from the content of communication commands. As seen above, a parallel can be drawn between commanding and issuing successful illocutionary acts. The effect of commanding is not a promise or a wish, but an effective action: commands perform actions on and through object properties of the virtual environment.
A MOO, needs a Design language which respects the structure of the supporting software. An hypothesis for structuring such language is now introduced. The software used is the LambdaMOO Server, in its 1.8.0p5 version. The code is written in LambdaMOO Programming Language.
The LambdaMOO Database works on the basis of properties and verbs assigned to individual objects. Behaviours are embedded in the objects through these properties and verbs. Each object has a set of properties which are used by the software interpreter to react to those objects' use by players. Properties can be built in, inherited, or newly added, they can be modified, and in the case of verbs, programmed to do a specific task, or output a specific response. Only the owner of an object, or a super-user (namely, a wizard or administrator) can add and remove properties in order to change its behaviour. A verb can call one or more properties, compare, manipulate them, so that a specific function and response are issued. The coincidence between the descriptive level, and the functional one, should be intended as the coincidence between the content of a particular property and its function in the context of the MOO. The strength of Design in a VC should be found in this correspondence.
As in any other programming language, verbs can be "chained," which means that a verb can call a series of other verbs and change a matrix of properties, plus output messages in response to the action. The proposed language includes verbs and properties which are functional to design. They are programmed to aid the designer in his/her job of matching appearance and functionality of the text-based designed objects.
My hypothesis for structuring a Design language in a MOO, is based on observations coming from:
* a selection from an English Dictionary (the online English Pocket Dictionary, found at http://www.apocalypse.org/pub/u/nelson/bin.cgi/dict, from ftp://sun.soe.clarkson.edu/pub/src/dictionary, now both expired; with the help of the online dictionary at http://gs213.sp.cs.cmu.edu/prog/webster) initially of 21,110 words, reduced to 721 words;
* some CAD and graphic Design software interfaces (AutoCAD&tm;, Photoshop&tm;, ArchiCAD&tm;, ClarisWork&tm;, PaintBrush&tm;);
* the actual LambdaMOO Database class of $builders and the actual LambdaMOO Psychotic Class of Player (Schmoo race, object #52563 on LambdaMOO);
* a selection of the most used verbs on the MOO NEMESIS (from Reid, 1994);
* an analysis of more than 100 room and object descriptions conducted on several MOOs.
I noted that more often room descriptions, the last item in the above list, still reflect a "real life" situation in which players figure out how to reproduce their physical places in the virtual environment. It is only when players understand that the function of the room, what they can do with it, and how it reacts to other players and objects are far more important than its verbal description, that they start defining a more specific (and appropriate) level of details.
For example, in this room description found on RiverMOO (river.honors.indiana.edu:8888):
City Slum (#2032)
This building was once a tire
manufacturer, but when the building was gutted by fire in 1954, it was
abandoned. You can still see the scorch-marks on the walls.
Now, it has been made into a place where those of RiverCity's less fortunate sort can sleep with a roof over their heads. But sometimes it seems as though the roof is going to cave in. The walls are bare concrete, with two barred, broken windows on the far corners of the room.
There is a light fixture squarely placed in the middle of the ceiling. It is swinging from a thin, fraying black cord. There are five cots along each wall. The legs of the cots are rusted. The sheets of the cots are gray [sic] and dirty.
The room is public. To make it your home, type @sethome.
There's a door leading back out to the Back Alley. The door is closed.
You are here. Manischewitz (asleep), Hardwick (asleep), Muttman (asleep), Translucent Adept (asleep), braindead (asleep), shakes the clown (asleep), and Curunir (asleep) are asleep here.You see Slum Jack, Slum Phone, and BerryMan (asleep) here.
Obvious exit: alley to Back Alley
the description does not cover the functionality of the room, in MOO terms. It gives more a narrative picture of how the room looks like, rather than how players can use it.
In this description, instead, found on Diversity University (moo.du.org:7777), we read:
MOOteach Learning Center (#1578)
THE MOOteach LEARNING CENTER is dedicated to teaching DU members MOO basics. It is also for the training and support of teachers who wish to conduct classes here in MOOspace. Resources are available for the self-directed study of basic MOO commands, MOO programming and special teaching strategies and techniques useful for MOOteaching. Enter DISPLAYS to see some of the resources already available then SHOW # (number of display item). Or, LOOK or READ (#) ON (DOCUMENTNAME) the documents in the room. We hope to be adding new things all the time, so if you have something to contribute please contact Zak or Jeanne.
To get *Elsie the cow to respond to you, type: ACTIVATE ELSIE
which only gives instructions on what to do with the room and the objects contained in it, and no information at all about how it looks like.
Each virtual place can be represented by a prototype with features which reflect their functions.
Examining rooms found in various MOOs, I identified a few recurrent ones, and objects contained, which can be grouped into:
* offices; containing desks, chairs, containers (eg. filing cabinets)
* store rooms (eg. library, objects repository); containing shelves, containers, indexes
* in-house and private rooms (eg. kitchen); containing storage objects, special objects (eg. bed, dishwasher)
* gardens and outside areas; containing vegetation, water, terrain levels, seats, special objects (eg. statue)
* workshops (eg. studio); containing benches, desks, chairs, working tables, brainstorming tools (eg. whiteboard, sketchpad)
* meeting and social rooms (eg. conference room); containing tables, chairs, brainstorming tools, drinking machines (eg. coffee machine)
* teaching rooms; containing tables, chairs, shelves, white/black-boards, special resources (eg. tutorials)
* connections (eg. elevator, corridor, foyer); containing doorways, buttons (for elevators, or mobile rooms), trap doors
* whole buildings (eg. post office); containing directories, built-in rooms, possible exits and connections
From the above, I designed prototypes, meta-room from which the designers can choose, and subsequently refine the properties and add new verbs as the room acquires specific functions.
Prototypes are the first steps designers take toward designing virtual places, using words, as commands and descriptions.
The command for creating a new room from one of the above prototypes is `@sketch.'
`@sketch' is a questionnaire-like command. The first argument of the @sketch command is which kind of room is being designed: the prototype, expressed with a `$' in front of the word (eg. $office, $outside, $teaching; according to the syntax required by the MOO interpreter), then the name of the new room. According to the prototype chosen, a special set of details and objects can be added by the designer. The command works as follows:
* asks the aliases for the new room;
* asks to type in a description of the new room;
* asks a name for an exit, from the room where the designer is, to the new room;
* gives a series of instructions on how to add, copy, use details contained in the room;
* moves the designer to the new room, and gives instructions on how to use it;
* asks a series of questions on which ones of the special objects contained in the prototype the designer wants to add to the new room.
The result of the @sketch is a new room, with details and object which specifically define the room for its function.
As seen, @sketch uses a meta-designed room, the prototype, which contains special details and objects apt to perform special functions. For example, in the $office we find chairs, a desk, a filing cabinet, a telephone; in the $outside area, there is a bench, some trees and a fountain. Cloned objects will be found in the newly created room. The new room will also inherit all the characteristics of the starting prototype. The administrators have the capacity of modifying the prototype parameters, and therefore modify all the descendants of that prototype.
Designers will need a very little understanding of how the programming language works, to create rooms with an advanced functionality. Moreover, the administrators would be able to control the whole hierarchy, since the inheritance of verbs and properties affects all the children of a prototype.
From linguistic theories, to Object Oriented programming, there seems to be a long step, yet it can be readily taken. Computer users normally type in commands (words) for a certain task to be executed. They do not think, and they don't need to think, about the architecture behind that typing. Virtual citizens use software tools and natural language to live their own "virtual life." Online virtual communities are examples of how language becomes the "social contract" which users evolve and expand. (Searle, 1995) The linguistic register of communication changes and is modified by the same users, and it becomes specific for the medium.
Design in VCs still hasn't developed an appropriate register, but the analogy with Speech Acts can introduce the possibility of using commands, appropriately written for Design, to "do things with words." We have noted, in this paper, how the step from Speech Acts to commanding is very short, then it can lead to the development of a Design language for a text-based Virtual Community, such as a MOO.
Therefore, a different perspective can be taken when we look at Design in cyberspace: on the one side, we can develop tools for creating metaphors of physical objects (buildings and CAD systems, newspapers and Web editors), on the other we can develop tools for experiencing and producing Design in cyberspace for cyberspace's sake. Wether the tools are graphically sophisticated or not, we can look at the language on which the community is based and use it to expand the possibilities of its citizens: these tools are linguistic tools.
Once we focus our attention onto how Design can transform online communities into more livable environments, a language for Design becomes highly desirable and most appropriate.
The support of the Key Centre for Design Computing, in particular Mary Lou Maher, is acknowledged. All the frequent users of the Key Campus and Diversity University have been extremely helpful in formulating ideas for this hypothesis.
Illocutionary act: "The minimal units of human communication are Speech Acts of a type called illocutionary acts. Some examples of these are statements, questions, commands, promises, and apologies. Whenever a speaker utters a sentence in an appropriate context with certain intentions, he performs one or more illocutionary acts." (from Searle and Vanderveken, 1985) Speech Act uttered by a speaker in order to achieve something. Illocutionary acts, to be successful, need to respect some constraints: the context in which they are issued, and the intentions of the speaker must be valid, so that the act can be performed. An illocutionary act consists of an illocutionary force and a propositional content. "Content is one of the determinants of the illocutionary act performed by an utterance." (Searle, 1985, p.27)
Illocutionary force: it is realised through the syntax of natural language: mood, punctuation, word-order, intonation contour, stress. It is a component of meaning.
Illocutionary verbs: according to Searle(1985), they are: assertives (assert, claim, affirm, state, deny, disclaim, assure, argue, rebut, inform, notify, remind, object, predict, report, retrodict, suggest, insist, conjecture, hypothesize, guess, swear, testify, admit, confess, accuse, blame, criticize, praise, complain, boast, and lament); commissives (commit, promise, threaten, vow, pledge, swear, accept, consent, refuse, offer, bid, assure, guarantee, warrant, contract, covenant, and bet); directives (direct, request, ask, urge, tell, require, demand, command, order, forbid, prohibit, enjoin, permit, suggest, insist, warn, advise, recommend, beg, supplicate, entreat, beseech, implore, and pray); declaratives (declare, resign, adjourn, appoint, nominate, approve, confirm, disapprove, endorse, renounce, disclaim, denounce, repudiate, bless, curse, excommunicate, christen, abbreviate, name, and call); expressives (apologize, thank, condole, congratulate, complain, lament, protest, deplore, boast, compliment, praise, welcome, and greet).
IRL: In real life.
MOO: MUD Object Oriented, refers to the characteristic of the software and database to organise information in objects.
MOO Command: a command typed in the MOO. Example: @move, @put, whisper.
MUD: Multi User Dungeon, or Dimension. Software and database which allow a Virtual Community to develop both synchronously and asynchronously.
Object Oriented Programming: a programming method based on common characteristics for families of objects.
Performatives: verbs which can perform an action. Example: to thank, to promise, to declare, to order.
Performative Sentence: a special class of sentences constructed with a performative verb in the first person tense of the indicative mood, with an appropriate complement cause. Example: I promise that I will come tomorrow; I order you to come here.
Perlocutionary Act: a Speech Act which, when uttered, provokes an effect.
Perlocutionary effect: the effect on the hearer of the illocutionary act. For example, saying "I promise I will come here tomorrow" produces the effect of an expectation on the hearer that tomorrow I will be here.
Speech Act: the utterance of a sentence.
VC: Virtual Community. A community which bases its existence on online media.
Austin, John Langshaw. (1962) How to do things with words. Boston: Harvard University Press.
Cherny, Lynn. (1995) "The Modal Complexity of Speech Events in a Social MUD." Electronic Journal of Communication 5 (4),
Cicognani, Anna. (1997) "On the linguistic nature of Cyberspace and Virtual Communities." Virtual Reality: Research, Development and Application (CVE Special Issue),
Cicognani, Anna and Maher, Mary Lou. (1997) "Design Speech Acts. "How to do things with words" in Virtual Communities." In CAAD Futures, Conference Proceedings, Munich, 3-6 August, edited by R. Junge, Kluwer Academic Publishers, pp.707-717.
Curtis, Pavel. (1992) "Mudding: Social Phenomena in Text-Based Virtual Realities." In DIAC 1992, Conference Proceedings, .
Reid, Elizabeth. (1994) Cultural Formations in text-based Virtual Realities. Master Thesis, Dept. of English, University of Melbourne.
Searle, John Rogers,(1971) edited by. The philosophy of language. London: Oxford University Press.
Searle, John Rogers. (1995) The Construction of Social Reality. USA: Simon & Schuster.
Searle, John Rogers and Vanderveken, Daniel. (1985) Foundations of Illocutionary Logic. Cambridge: Cambridge University Press.
Serpentelli, Jill. (1992) Conversational Structure and Personality Correlates of Electronic Communication. Electronic text: ftp://parcftp.xerox.com./pub/MOO/papers/conv-structure.txt.