Followon to specifying meaning…
Specifications are often written as if they communicate social norms: the diameter of the nail’s shaft must be 4 mm plus or minus .01 mm. This is not to say the nail has taken on a moral obligation, but rather is shorthand for saying that before you claim that X meets specification Y, you must make sure that the must conditions of the specification are met by X.
Last time I talked about specifications for communicating agents. One is tempted to say that the meaning of a message is a property of the message, which is part of the agent (before it is sent at least), in the same way that the diameter of a nail is a property of the shaft, which is part of the nail. So if it is possible to specify that (a) the nail’s shaft diameter must be 4mm, then it should be possible to specify that (b) the agent’s message’s meaning must be that the battery is charged.
There is something funny about putting “meaning” in a position like this. One can measure a nail’s shaft diameter, and as there is general agreement on how to take such measurements, it is unlikely that two parties (say, a supplier and a buyer) will disagree. The specification (a) is objective and actionable. But what about (b); is there a way to make “the meaning of M is P” objective and actionable the way “the diameter of the shaft it 4mm” is? (Remember that P is a proposition such as the proposition that the battery is charged.) Probably not in the sense of “what does agent A mean by message M”. Here “mean” has the sense of “intend” and intention is subjective, i.e. unfalsifiable. The agent could mean X and do Y. What it means (intends) doesn’t matter in an engineering context; only observable behavior such as action or speech matters.
But “the meaning of M is P” could be objective if interpreted as
- the meaning of A sending M is P, or
- A’s sending M correlates with P, or
- P determines whether A sends M, or
- A sends M if and only if P.
which are all mostly equivalent. (Correlation is not causation, but it’s hard to tell them apart, and the difference may not matter if your goal is engineering.) Instead of M being the bearer of meaning, the act of sending M is the bearer.
Reporting is now a clear, testable property of the agent in question. You can check for 4. as follows: If A transmits M when P, and does not transmit M when not P, then the meaning of [A sending] M is P.
(This test has to be modified if there is competition between M and other messages for use of the communication channel; failure to send M might just mean that the channel or the agent is preoccupied with other things. But I hope you get the idea.)
If there are too many states to test exhaustively, sample the state space. If this is a seller/buyer situation, the buyer ought to be very skeptical, performing a wide variety of clever tests to ensure that A meets the specification (that it sends M if and only if P). (Perhaps the seller could provide a warrantee, or a mathematical proof, to reassure the buyer.)
Any of the interpretations 2, 3, 4 eliminates the word “meaning” without sacrificing what was originally expressed using that word. All suggestion of intent and propositional attitudes (belief, intent, truth, fidelity) has gone away. We are left with a clearer, more actionable specification.
Of course this is the simplest kind of communication: a single message whose meaning is independently specified and testable. More general scenarios have parts: either there are multiple coordinated messages, or there is a single message that has parts. The messages or parts combine somehow to form behavior that can be tested. For example, the correctness of an answer depends on what the question was, and the correctness of the predicate (in a sentence) depends on what the subject is. Parts that can’t necessarily be tested in isolation can combine to form wholes that can be.
Consider the problem of specifying a question-answering robot. Suppose the robot ‘understands’ (accepts, responds to) two ‘question’ messages, DZ and QS, and it can answer each question in any of three ways, RD, GE, or UL, with the correct choice depending on its circumstances. Suppose that the robot has a camera, and in its visual field are a disk and a square; that the disk and square can independently be either red, green, or blue; and that the robot can sense the color of the disk and square.
We want to specify the following:
|question||answer||if and only if …|
|DZ||RD||the disk is red|
|DZ||GE||the disk is green|
|DZ||UL||the disk is blue|
|QS||RD||the square is red|
|QS||GE||the square is green|
|QS||UL||the square is blue|
That is, the answer in the answer column is the correct (specified) one, if the question is the one in the question column and the condition in the third column holds.
The claims (that the disk is red etc.) and therefore the correctness of an answer can be verified through testing or through other objective, skeptical means, as above. Color is notoriously difficult to pin down, and if “is red” is too vague for one of the negotiating parties, a more precise condition can be negotiated, such as a function of the readout of a sensor operating under controlled conditions; and the better condition can be recorded as part of the specification.
We can enumerate all possible question/answer pairs like this, giving the necessary and sufficient condition for each pair, although it gets tedious if there are more than a few questions and answers. Looking at this list it is much more appealing to take the questions and answers as having meaning in themselves. It appears that DZ asks what the color of the disk is, QS asks what the color of the square is, and RD, GE, UL express that the color (of whatever is in question) is the corresponding color.
Folk semantics says that the questions and answers have meanings, and that the sender and receiver should know these meanings. One might say that the meaning to the sender is (one hopes) the same as the meaning to the receiver. But statements like these are impossible to assay and of little use in a specification. How do you test to see whether a robot gives any particular meaning to some question?
I’ve suggested a way to specify the meaning of a complete message – give the preconditions for generation, or postconditions for interpretation. Maybe we can reduce the question of the meaning of message parts, or dialog parts (such as a question/answer pair), to the case that’s already been solved.
Remember that a specification is part of a negotiation between two parties, say a seller and a buyer. The seller and buyer are the ones that have agreed, or hope to agree, on whether the question-answering artifact (robot) meets the specification. This boils down to agreeing on how to evaluate the robot for conformance. They need to have a shared method to go from a question and an answer, to a test that helps determine whether or not the answer is the correct answer to the question. (As before this is a simplification, since we have guarantees and so on, but the idea of objectivity remains no matter how complicated things get.)
One way is for the two parties to agree between them on the meanings of questions and answers, and then to agree that a question/answer scenario is tested in given circumstances by combining the question with the answer in some agreed manner, yielding a test (or a testable proposition).
That is, they agree that DZ “means” to ask what is the color of the disk (and so on), RD “means” that the color under consideration is red (and so on), and the method of the combination of Q with A is the obvious one: the proposition to test is the proposition that the answer that A “means” is true, given that what Q “means” (e.g. what the color of the disk is) is something the answer applies to.
I use “means” here but this is only to play with your mind; it could be any placeholder relationship, since its only purpose is to be introduced (by the spec) and then discharged (in an application of the combination rule in the spec). We could just as well have said DZ “is associated with” what the color of the disk is, and RD “goes along with” that the color is red. There is no objectivity to these relationships; they are just local definitions within the specification, obtaining their truth and legitimacy only by private agreement among users of the specification, and meaningful only in the context of the specification. And importantly they only address evaluations of the behavior of the robot, not the robot’s implementation. There is no need to appeal to “representations” or “intent”.
|question||is associated with|
|DZ||what color the disk is|
|QS||what color the square is|
|answer||goes along with|
|RD||the color is red|
|GE||the color is green|
|UL||the color is blue|
Now we have two tables with a total of five entries, instead of one table with six entries, that is, M+N things to explain in the spec rather than M*N. Not only does this yield economies in implementation and verification but it means that question/answer pairs that have never been seen before in design or training can have agreed semantics – which I take to be the heart of compositional semantics.
This “association” approach to meaning may sound completely vacuous, and it is meant to sound that way. But going this route is very different from the folk semantics I gave above. In the folk semantics, meaning resides in the robot or in what it says. But in the preceding treatment, meaning (of questions and answers, or of message-parts) is only part of the dialog between the users of the specification (seller and buyer, or whatever). Meaning is taken up, in a controlled way, in the specification, not in the robot.
Here are three wonderful references for all you fellow meaning skeptics:
The idea of equivalence of question/answer pairs and declarative sentences is from Yablo (Aboutness, section 2.2).
Horwich (Truth, Meaning, Reality) inspired me to look for a deflationist treatment of compositional semantics.
I cheer when I read Reddy’s article “The Conduit Metaphor”, which argues that the widespread metaphor of messages as carriers of meaning is not helpful.
To be written: what all this has to do with vocabulary specifications, IAO, linked data, and httpRange-14.