Sign

The predicate "sign" does not denote an inherent feature of an Object, but rather a specific way of treating it. In fact, almost anything can be used as a sign by someone. Clouds can be taken as a sign of rain, smoke as a sign of fire, footprints as a sign of a human, clothes as a sign of life-style. However, it is a fact that some objects are particularly popular as signs and obtain value solely from this function. This is true of letters, vocal sounds and pictures whose primary reason for being is to function as signs. It is not true of clouds and footprints that occur independently of whether someone uses them as signs or not. Still other objects are not primarily used as signs, but regularly participate in secondary semiotic processes. This is true of many artefacts; although the primary purpose of cars is transportation, the meaning of the design is important to the buyer since it signifies social status and life-style. However, even the most dashing design cannot sell a car that cannot run. >> sign object

Computer systems resemble letters more than clouds and cars because their primary function is to enter into semiosis. A payroll system stands for employees and wages, a flight reservation system for planes, seats, and flights, a geographic information system for buildings and streets, an economic model for incomes, expenditures and taxes, and an action game for soldiers, guns and combat. If such systems cannot participate in semiosis and their data cannot be interpreted as employees, wages, planes, seats, houses, streets, etc., they are normally considered faulty. >> semiosis data

Note that we do not as yet require the systems to stand for true properties of their domain. This requirement is only sensible for some kinds of systems but not for others. For example, the employee can rightfully expect that the payroll system correctly accumulates the amount of money he has received up till now, and the geographical information systems should not place a house on a location where the real town has a road. But in other cases, truth is not relevant: you cannot get your money back because […] your action game does not assert true facts about reality. >> truth fact

In still other cases, a system may contain data that creates the state of affairs they stand for and for this reason cannot be true of false. This is e.g. true of the booking data of flight reservation systems: booking a seat on a flight does not reflect a pre-existing state of affairs, but creates a social obligation involving passenger and company: the company promises to let the passenger occupy the seat and transport him to the agreed destination, whereas the passenger promises payment in return. However, the system will also contain data that is intended to be taken as true statements about the present or the future: for example the number of seats of a plane or its destination. >> social obligation

Thus, the main motivation for creating a discipline of computer semiotics is that the primary function of computer systems is to work as sign-vehicles. The reason why Peter Bøgh Andersen is not proposing a discipline of aeroplane-semiotics is that the main purpose of aeroplanes is transportation and not semiosis. For this reason semiotics can be expected to reveal basic and important properties of computer systems but not of aeroplanes.

Our discussion has also exemplified how semiotics can be useful for designing and understanding computer systems, namely by offering more precise concepts for understanding semiosis. If it is true that computer systems are primarily used as sign-vehicles, then non-semiotic approaches will have to deal with the same phenomena as semiotics do. We will expect to find semiotic concepts in other approaches, although used in a more naive and less systematic way, and this is indeed true.

One example is object-oriented design and programming. The method distinguishes between a computer model and a domain of the model, the computer model being similar to aspects of its domain. The classes of the model are said to correspond to collections of objects in the domain, the instances of the classes to objects of the domain, methods of the classes to actions and events in the domain, and variables of the classes to properties of the domain objects.

⇒ Model (p. 3–4)

In the notion of "model" there is a clear invitation to see a computer system as a collection of true statements about the domain, but a systematic semiotic analysis of real computer based signs reveal a more complex picture. Let us start by classifying the computer model as a signifier and the domain as the signified, assuming that the model is taken by designer or user to stand for some aspects of its domain. But since we know there are many kinds of relationships between signifier and signified, we will not stop here but insist on a careful analysis of the relationship between signifier and signified. In some cases we will classify data as statements about the domain and relate them to the class of representative signs; but in other cases we will see them as forces that change the domain (directive or commissive signs) or discover that they stand for fictive phenomena. In short, we replace the simple idea of "modelling" by a more detailed description of signifier-signified relations. >> model

A closer look at semiosis will have the same effect. The computer model is assumed to stand for the domain, but to whom? The model itself, in the shape of source code and diagrams, is normally only perceived by systems developers, and thus can only be said to stand for the domain to this group of people. Users have no contact with the global model in their daily work, but only interact with small pieces of model executions. The semiosis taking place here is very different from the one system developers experience, and there is absolutely no reason to expect that the meanings created during systems development automatically migrate to the use situation. >> computer model domain

Putting systems development under the semiotic microscope reveals new interesting sign-types. We quickly discover that it is only a half-truth that the source code stands for the domain. Many lines of source code turn out to stand for the computer hardware or software. As an illustration to this, suppose we have an object such as employee:

The variables and methods of this object can easily be taken to stand for domain features: an employee has a name, lives at an address, pays so much tax, has earned a certain sum and can receive a payment. But the object must also contain a method for displaying itself on a screen, say Display(), and this method will contain code specifying where to place the variables on the screen, say Print(Name, 10, 20) that prints the name on line 10 starting in position 20. Now, "10, 20" does not stand for the domain, but for a location on the hardware.

Besides references to hardware, the code contains many references to other pieces of code, i.e. references to itself. Consider a definition of Display():

The definition says that performing "Display" is the same as performing the "Print"-method three times, where "Print" refers to the definition of "Print" somewhere else in the code. Thus, calling the "Print" method implies a reference to its declaration. In general, most uses of concepts in programs involves a reference to another location in the program where the concept is defined; and the definition normally uses new concepts for which the same is true. The unravelling of such references to references is routinely performed by any compiler (where the process is called "linking") .

Instead of having one sign-type standing for the domain, we find ourselves with at least three sign types distinguished by their reference: domain, hardware or software, and real programs reveal even more layers than three.

We can also begin wondering which forces maintain the relation between signifier and signified. What guarantees, for example, that instance #0099 of class employee in fact represents me? It probably turns out that the relation between #0099 and myself is guaranteed by a conventional rule: I just happen to have the name Name and live at the street named Address, but I and my street could easily have had other names. Signs that are based on conventional relations between signifier and signified are called symbols (this class includes the natural languages), but botanizing a bit more reveals another type of signs that is not based on a convention but rather on a cause-effect relation. We only have to visit the local power plant to discover signs that are not entered into the computer by a human following a set of conventions, but are produced mechanically by a gauge measuring pressure and temperature in boilers. This sign type is called indexes and includes the clouds, smoke and footprints mentioned before. >> symbol cause effect relation index

Thus, semiotics furnishes a more precise vocabulary and enables us to discover differences we might otherwise not have noticed. In addition, it helps us comparing computer systems to other kinds of sign-systems. >> compare computer sign system

ANDERSEN, P. B., 1997. A theory of computer semiotics: semiotic approaches to construction and assessment of computer systems. Updated ed. Cambridge ; New York, NY, USA: Cambridge University Press. Cambridge series on human-computer interaction, 3. ISBN 978-0-521-44868-0, p. 2–3; ⇒ Model p. 3–4; p. 4–5