[PromiseBook] / trunk / chap_logic.tex Repository:
ViewVC logotype

Annotation of /trunk/chap_logic.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1 - (view) (download) (as text)

1 : mark 1
2 :     \chapter{Reasoning about $\mu$-promises}
3 :    
4 :    
5 :     To secure a clear and consistent model of intent we must use formal
6 :     methods, but what formalism do we have to express the necessary
7 :     issues? Previous attempts to discuss the consistency of distributed
8 :     policy have achieved varying degrees of success, but have ultimately
9 :     fallen short of being useful tools except in rather limited arenas.
10 :     For example:
11 :    
12 :     \begin{itemize}
13 :     \item Modal logics: these require one to formulate
14 :     hypotheses that can be checked as true/false propositions. This is not
15 :     the way system administrators work.
16 :    
17 :     \item The $\pi$-calculus: has attractive features but focuses on issues
18 :     that are too low-level for our main purposes. It describes systems in
19 :     terms of states and transitions rather than policies (constraints
20 :     about states)\cite{parrow1}.
21 :    
22 :     \end{itemize}
23 :    
24 :     \section{Promise consistency and scope}
25 :    
26 :     How can agent promises be inconsistent? Is a conflict of intention
27 :     enough to speak of inconsistenct? In fact it is not, because we must
28 :     deal with the problem of scope. Two agents might have conflicting
29 :     intentions with respect to some imaginary higher purpose, but have no
30 :     knowledge of each other or this imaginary purpose.
31 :    
32 :     For example: A intends to have his son take over his trading business
33 :     when he retires. A's son intends to go to college and become a
34 :     scientist. A's wife intends to have him marry the daughter of a friend
35 :     and work the land to support them. Are any of these intentions
36 :     consistent or inconsistent? What imaginary goals does one measure such
37 :     consistency against?
38 :    
39 :     Promises may only be made by a specific agent, so a more careful
40 :     question is to ask how can an agent be inconsistent in making its
41 :     promises? At the extreme pole where every agent is independent and
42 :     sees only see its own world, there would be no need to speak of
43 :     inconsistency: unless agents have promised to behave in a similar
44 :     fashion, they will do as they please. This is the property of a local
45 :     theory.
46 :    
47 :     \begin{lemma}[Locality or promises of the first kind]
48 :     An agent cannot make an elementary promise (of the first kind) about
49 :     any agent other than itself, or its own behaviour.
50 :     \end{lemma}
51 :    
52 :     A contradiction can still occur if a single agent promises two
53 :     contradictory things. We call such a case incompatible or even broken
54 :     promises. When all information is promised by (and hence localized in) a
55 :     single agent, there is no need to go beyond that agent to look for
56 :     inconsistencies. If a specific agent promises to marry and
57 :     not to marry, then there is an obvious conflict. the locality means
58 :     we only need to look in one place for this.
59 :    
60 :     \begin{definition}[Inconsisent promises]
61 :     A promise of
62 :     $b_1$ from agent $A_1$ to agent $A_2$ is said to be inconsistent if there
63 :     exists another promise from $A_1$ to $A_2$, of $b_2$, in which
64 :     $b_1\not=b_2$.
65 :     \end{definition}
66 :     In the worst case, one could consider promising inconsistent promises
67 :     to be a case of breaking both promises.
68 :     This definition is very simple, and becomes most powerful when one
69 :     identifies promise {\em types}. It
70 :     implies that an agent can only break its own promises: if an agent
71 :     promises two different things, it has broken both of its promises.
72 :    
73 :    
74 :     \section{Indirection - a problem for deceptions}
75 :    
76 :     We have said earlier that the promise body should not normally contain
77 :     references to agents. When agents' names are absent from the promise
78 :     body, the logic is very simple. This is a desirable property.
79 :    
80 :     But there are promises that cannot be expressed like this.
81 :     Some complicated promises can be made (like the transference of
82 :     responsibility example in \cite{burgessdsom2005}). However there
83 :     are cases where we cannot avoid referring to third parties.
84 :     e.g.
85 :     \begin{itemize}
86 :     \item I promise I love you.
87 :     \item I promise I do not love Mary.
88 :     \item I promise Mary I do not love you.
89 :     \end{itemize}
90 :     Or ``I promise to you not to promise X to Y'', etc.
91 :     These levels of complexity must be built up step by step.
92 :    
93 :     This problem cannot be avoided if we keep to the rule that the promise
94 :     body may not refer to other agents, since one could reframe the promises
95 :     to avoid mentioning by name and providing the data about ``whom I love''
96 :     as a service.
97 :    
98 :     This matter can be resolved as incompatible promises.
99 :     We need some kind of taxonomy of promises that are related and incompatible.
100 :     Promises need to be classified into some kind of taxonomy/ontology
101 :     in order to know when certain promises are incompatible. e.g.
102 :    
103 :     ``I promise I love you''
104 :    
105 :     ``I promise Mary I don't love you''
106 :    
107 :     These are the same promise type. There is no impediment to promising this, but
108 :     the result is, of course, necessarily a lie.
109 :    
110 :    
111 :     \subsection{Di-graphs}
112 :    
113 :     In our definition of lies, we made an unwarranted assumption.
114 :     There is no probelm with the following:
115 :     \beq
116 :     \begin{array}{c}
117 :     A_1 \promise{\pi} A_2\\
118 :     A_1 \promise{\neg \pi} A_3
119 :     \end{array}
120 :     \eeq
121 :     $A_1$ can promise constadictory things to different agents without
122 :     making any contradiction, provided the promise body does not refer
123 :     to agents.
124 :    
125 :     \subsection{Tri-graphs}
126 :    
127 :     This is a lie to either $A_2$ or $A_3$, i.e. the assertion of two or
128 :     more inconsistent promises to a promisee, about the behaviour of
129 :     promising agent towards either the promisee or towards a third-party.
130 :     \beq
131 :     \begin{array}{c}
132 :     A_1 \promise{\rm Love~ you} A_2\\
133 :     A_1 \promise{\rm Don't~ love~ A_2} A_3
134 :     \end{array}
135 :     \eeq
136 :    
137 :    
138 :     \section{Promise analysis}
139 :    
140 :    
141 :     Logic is a way of analysing the consistency of assumptions. It is
142 :     based on the truth or falsity of collections of propositions
143 :     $p_1,p_2,\ldots$. One must formulate these propositions in advance
144 :     and then use a set of assumptions to determine their status.
145 :     The advantage of logic is that is admits the concept of a proof.
146 :    
147 :     Is there a logic that is suitable for analyzing promises? Modal logic
148 :     has been considered as one possibility, and some authors have made
149 :     progress in using modal logics in restricted
150 :     models\cite{ortalo1,glasgow1}. However, there are basic problems with
151 :     modal logics that limit their usefulness\cite{lupu2}.
152 :    
153 :     More pragmatically, logic alone does not usually get us far in
154 :     engineering. We do not usually want to say things like ``it is true
155 :     that $1+1 = 2$''? Rather we want a system, giving true answers, which
156 :     allows us to compute the value of $1+1$, because we do not know it in
157 :     advance.
158 :     Ultimately we would like such a calculational framework for combining
159 :     the effects of multiple promises. Nevertheless, let us set aside such
160 :     practical considerations for now, and consider the limitations of modal
161 :     logical formalism in the
162 :     presence of autonomy.
163 :    
164 :    
165 :     \subsection{Modal Logic and Kripke Semantics}
166 :    
167 :     Why have formalisms for finding inconsistent policies proven to be so
168 :     difficult? A clue to what is going wrong lies in the many worlds
169 :     interpretation of the modal logics\cite{modallogic}.
170 :     In the modal logics, one makes propositions $p,q$ etc., which are
171 :     either true or false, under certain interpretations. One then introduces
172 :     modal operators that ascribe certain properties to those
173 :     propositions, and one seeks a consistent language of such strings.
174 :    
175 :     Modal operators are written in a variety of notations, most often with
176 :     $\boxx$ or $\diamond$. Thus one can say $\boxx p$, meaning ``it is
177 :     necessary that $p$ be true'', and variations on this theme:
178 :    
179 :     \begin{center}
180 :     \begin{tabular}{ll}
181 :     \hline
182 :     $\boxx p$ & $\diamond p = \neg \boxx \neg p$\\
183 :     \hline\hline
184 :     It is necessary that $p$ & It is possible that $p$\\
185 :     It is obligatory that $p$ & It is allowed that $p$\\
186 :     It is always true that $p$ & It sometimes true that $p$\\
187 :     \end{tabular}
188 :     \end{center}
189 :     A system in which one classifies propositions into ``obligatory'',
190 :     ``allowed'' and ``forbidden'' could easily seem to be a way to codify
191 :     policy, and this notion has been
192 :     explored\cite{ortalo1,glasgow1,deontic,lupu2}.
193 :    
194 :     Well known difficulties in interpreting modal logics are dealt with using
195 :     Kripke semantics\cite{kripke1}.
196 :     Kripke introduced a `validity function' $v(p,w)\in\{T,F\}$, in which
197 :     a proposition $p$ is classified as being either true of false in a specific
198 :     `world' $w$. Worlds are usually collections of observers or agents in a system.
199 :    
200 :     Consider the formulation of a logic of promises, starting with the
201 :     idea of a `promise' operator.
202 :     \begin{itemize}
203 :     \item $\boxx p =$ it is promised that $p$ be true.
204 :     \item $\diamond p = \neg\boxx\neg p =$ it is unspecified whether $p$ is true.
205 :     \item $\boxx \neg p =$ it is promised that $p$ will not be true.
206 :     \end{itemize}
207 :     and a validity function $v(\cdot,\cdot)$.
208 :    
209 :     \subsection{Further problems with modal logic}
210 :    
211 :     Some modal logics begin the with assumption of idempotence of the core
212 :     operators. For example, one assumes that $\boxx\rightarrow
213 :     \boxx p \boxx p $. Many justifications for this have been attempted; indeed,
214 :     the left hand side can be phrased is several ways in English:
215 :    
216 :     \begin{itemize}
217 :     \item It is necessary that $p$ be necessary.
218 :     \item $p$ is necessarily a necessity.
219 :     \item It is required that $p$ be necessary.
220 :     \item $p$ must be necessary.
221 :     \item $p$ must be a requirement.
222 :     \end{itemize}
223 :     In each of these cases, the truth of this relation (the necessity of
224 :     necessity) seems to be simply false in a world of autonomous promises,
225 :     thus we reject this form of reasoning, autonomously and voluntarily
226 :     (see section \ref{invol}).
227 :    
228 :     \subsection{Single promises}
229 :    
230 :     A promise is usually shared between a sender and a recipient. It is
231 :     not a property of agents, as in usual modal logics, but of a pair of
232 :     agents. However, a promise has implications only directly on the behaviour of the
233 :     promiser, not the promisee.
234 :    
235 :     Consider the example of the Service Level Agreement, above, and let
236 :     $p$ mean ``Will provide data in less than 10ms''. How shall we express
237 :     the idea that a node $A_1$ promises a node $A_2$ this proposition?
238 :     Consider the following statement:
239 :     \beq
240 :     \boxx p, ~~~v(p,A_1) = T.
241 :     \eeq
242 :     This means that it is true that $p$ is promised at node $A_1$, i.e. node 1
243 :     promises to provide data in less than 10ms -- but to whom? Clearly, we must also
244 :     provide a recipient. Suppose, we try to include the recipient in the same world
245 :     as the sender? i.e.
246 :     \beq
247 :     \boxx p, ~~~v(p,\{A_1,A_2\}) = T.
248 :     \eeq
249 :     However, this means that both nodes $A_1$ and $A_2$ promise to deliver data
250 :     in less than 10ms. This is not what we need; a recipient is still unspecified.
251 :     Clearly what we want is to define promises on a different set of worlds: the
252 :     set of possible links or {\em edges} between nodes. There are $N(N-1)$ such directed links.
253 :     Thus, we may write:
254 :     \beq
255 :     \boxx p, ~~~ v(p,A_1\rightarrow A_2)=T.
256 :     \eeq
257 :     This is now a unique one-way assertion about a promise from one agent
258 :     to another. A promise becomes a tuple $\langle \tau,p,\ell\rangle$,
259 :     where $\tau$ is a theme or promise-type (e.g. Web service), $p$ is a
260 :     proposition (e.g.deliver data in less than 10ms) about how behaviour
261 :     is to be constrained, and $\ell$ is a link or edge over which the
262 :     promise is to be kept. All policies can be written this way, by
263 :     inventing fictitious services. Also, since every autonomous promise will
264 :     have this form, the modal/semantic content is trivial and a simplified
265 :     notation could be used.
266 :    
267 :     \subsection{Regional or collective promises from Kripke semantics?}
268 :    
269 :     Kripke structures suggest ways of defining regions over which promises
270 :     might be consistently defined, and hence a way of making uniform policies.
271 :     For example, a way of unifying two agents $A_1$, $A_2$ with a
272 :     common policy, would be for them both to make the same promise to a
273 :     third party $A_3$:
274 :     \beq
275 :     \boxx p, ~~~ v(p,\{ A_1\rightarrow A_3,A_2\rightarrow A_3 \})=T.
276 :     \eeq
277 :    
278 :     However, there is a fundamental flaw in this thinking. The existence
279 :     of such a function that unifies links, originating from more than a
280 :     single agent-node, is contrary to the fundamental assumption of
281 :     autonomy. There is no authority in this picture that has the ability
282 :     to assert this uniformity of policy. Thus, while it might occur by
283 :     fortuitous coincidence that $p$ is true over a collection of links, we
284 :     are not permitted to {\em specify} it or demand it. Each source-node
285 :     has to make up its own mind. The logic verifies, but it is not a tool
286 :     for understanding construction.
287 :    
288 :     What is required is a rule-based construction that allows independent agents to come
289 :     together and form structures that span several nodes, by {\em
290 :     voluntary cooperation}. Such an agreement has to be made between
291 :     every pair of nodes involved in the cooperative structure. We summarize this
292 :     with the following:
293 :    
294 :     \begin{figure}[ht]
295 :     \begin{center}
296 :     \includegraphics[width=5cm]{figs/coop2}
297 :     %\psfig{file=coop2.eps,width=9cm}
298 :     \caption{\small (Left) Cooperation and the use of third parties to measure the equivalence of agent-nodes in a region. Agents form groups and roles by agreeing to cooperate about policy. (Right) This is how the
299 :     overlapping file-in-directory rule problem appears in terms of promises to
300 :     an external agent. An explicit broken promise is asserted by file,
301 :     in spite of agreements to form a cooperative structure.\label{pmm}}
302 :     \end{center}
303 :     \end{figure}
304 :     \begin{assume}[Cooperative promise rule]
305 :     For two agents to guarantee the same promise, one
306 :     requires a special type of promise: the promise to cooperate with
307 :     neighbouring agent-nodes, about basic promise themes.
308 :     \end{assume}
309 :     A complete structure looks like this:
310 :     \begin{itemize}
311 :     \item $A_1$ promises $p$ to $A_3$.
312 :     \item $A_2$ promises $A_1$ to collaborate about $p$ (denote this as a promise $C(p)$).
313 :     \item $A_1$ promises $A_2$ to collaborate about $p$ (denote this as a promise $C(p)$).
314 :     \item $A_2$ promises $p$ to $A_3$
315 :     \end{itemize}
316 :     By measuring $p$ from both $A_1$ and $A_2$, $A_3$ acts as a judge of
317 :     their compliance with the mutual agreements between them (see
318 :     fig. \ref{pmm}). This allows the basis of a theory of measurement, by third
319 :     party monitors, in
320 :     collaborative networks. It also shows how to properly define
321 :     structures in the file-directory example (see fig \ref{pmm}).
322 :    
323 :    
324 :     \subsection{Example: dependencies and handshakes}
325 :    
326 :     Even networks of autonomous agents have to collaborate and delegate
327 :     tasks, depending on one another to fulfill promised services. An
328 :     important matter is to either find a way of expressing dependency
329 :     relationships without violating the primary assumption of autonomy, or
330 :     prove that it cannot be done\endnote{In nearly all cases agents are working
331 :     without irresistable forces guiding them, so the prospect of not being
332 :     able to express cooperative tasks as voluntary autonomous cooperation has
333 :     to be regarded as contrived to begin with. We claim it is `intuitively obvious'
334 :     that anything that can be achieve by force can also be achieved willingly.}.
335 :    
336 :     Consider three agents $A_1,A_2,A_3$, a database server, a web server and
337 :     a client. We imagine that the client obtains a web service from the web server,
338 :     which, in turn, gets its data from a database.
339 :     Define propositions and validities:
340 :     \begin{itemize}
341 :     \item $p_1 =$ ``will send database data in less than 5ms'', $v(p_1,A_1\rightarrow A_2)=T$.
342 :     \item $p_2 =$ ``will send web data in less than 10 ms'', $v(p_2,A_2\rightarrow A_3)=T$.
343 :     \end{itemize}
344 :     These two promises might, at first, appear to define a collaboration between the
345 :     two servers to provide a promise of service to the client, but they do not.
346 :    
347 :     The promise to serve data from $A_1 \rightarrow A_2$ is in no way connected to the
348 :     promise to deliver data from $A_2\rightarrow A_3$:
349 :     \begin{itemize}
350 :     \item $A_2$ has no obligation to use the data promised by $A_1$.
351 :     \item $A_2$ promises its web service regardless of what $A_1$ promises.
352 :     \item Neither $A_1$ nor $A_3$ can force $A_2$ to act as a conduit for database and client.
353 :     \end{itemize}
354 :    
355 :     We have already established that it would not help to extend the
356 :     validity function to try to group the three nodes into a Kripke
357 :     `world'. Rather, what is needed is a structure that
358 :     complete the backwards promises to {\em utilize} promised
359 :     services -- promises that completes a {\em handshake} between the
360 :     autonomous agents. We require:
361 :     \begin{itemize}
362 :     \item A promise to uphold $p_1$ from $A_1\rightarrow A_2$.
363 :     \item An acceptance promise, to use the promised data from $A_2\rightarrow A_1$.
364 :     \item A conditional promise from $A_2\rightarrow A_3$ to uphold $p_2$ iff $p_1$ is both present and accepted.
365 :     \end{itemize}
366 :    
367 :     \subsection{Acceptance}
368 :    
369 :    
370 :     We have deduced that three components are required to make a dependent promise.
371 :     This requirement cannot be derived logically; rather, we must
372 :     specify it as part of the semantics of autonomy.
373 :    
374 :     \begin{axiom}[Acceptance or utilization promise rule]
375 :     Autonomy requires an agent to explicitly accept a
376 :     promise that has been made, when it will be used to derive a dependent promise.
377 :     \end{axiom}
378 :     We thus identify a second special type of promise: the ``usage'' or ``acceptance'' promise
379 :     that we discuss in the next chapter. This is a promise to receive so it falls into the
380 :     class of promise bodies denoted $-b$.
381 :    
382 :     What use is this construction? First, it advances the manifesto of
383 :     atomicity, making making all policy decisions explicit. The
384 :     construction has two implications:
385 :     \begin{enumerate}
386 :     \item The component atoms (promises) are all visible, so
387 :     the inconsistencies of a larger policy
388 :     can be determined by the presence or absence of a specific link
389 :     in the labelled graph of promises, according to the rules.
390 :     \item One can provide basic recipes (handshakes etc.) for building concensus and
391 :     agent ``societies'', without hiding assumptions. This is
392 :     important in pervasive computing, where agents truly are politically
393 :     autonomous and every promise must be explicit.
394 :     \end{enumerate}
395 :     The one issue that we have not discussed is the question of how
396 :     cooperative agreements are arrived at. This is a question that has
397 :     been discussed in the context of cooperative game
398 :     theory\cite{sirisane,axelrod1}, and will be elaborated on in a future
399 :     paper\cite{siri2}. Once again, it has to do with the human aspect of
400 :     collaboration. The reader can excerise imagination in introducing
401 :     fictitious, intermediate agents to deal with issues such as shared
402 :     memory and resources.
403 :    
404 :    
405 :     \subsection{Temporal behaviour}
406 :    
407 :     As an addendum to this discussion, consider {\em temporal logic}: this
408 :     is a branch of modal logic, in which an agent evolves from one Kripke
409 :     world into another, according to a causal sequence, which normally
410 :     represents time. In temporal logic, each new time-step is a new
411 :     Kripke world, and the truth or falsity of propositions can span
412 :     sequences of worlds, forming graph-like structures. Although time is
413 :     not important in {\em declaring} policy, it is worth asking whether a logic
414 :     based on a graph of worlds could be used to discuss the collaborative
415 :     aspects of policy. Indeed, some authors have proposed using temporal
416 :     logic and derivative formalisms to discuss the behaviour of policy, and
417 :     modelling the evolution systems in interesting ways\cite{bandara1,bandara2,lafuente1}.
418 :    
419 :     The basic objection to thinking in these terms is, once again,
420 :     autonomy. In temporal logic, one must basically know the way in which
421 :     the propositions will evolve with time, i.e. across the entire ordered
422 :     graph. That presupposes that such a structure can be written down by
423 :     an authority for the every world; it supposes the existence of a global
424 :     evolution operator, or master plan for the agents in a network.
425 :     No such structure exists, {\em a priori}. It remains an open question
426 :     whether causality is relevant to policy specification.
427 :    
428 :    
429 :    
430 :     \subsection{Interlopers: transference of responsibility}\label{interxx}
431 :    
432 :    
433 :     One of the difficult problems of policy consistency is in
434 :     transferring responsibilities from one agent to another: when an agent acts
435 :     as as a conduit or interloper for another. Consider agents $a$, $b$ and $c$,
436 :     and suppose that $b$ has a resource $B$ which it can promise to others.
437 :     How might $b$ express to $a$: ``You may have access to $B$, but do not pass it on
438 :     to $c$''?
439 :    
440 :     \begin{figure}[ht]
441 :     \includegraphics[width=12cm]{figs/interloper}
442 :     %\psfig{file=interloper.eps,width=8cm}
443 :     \caption{\small Transference of responsibility.\label{interloper}}
444 :     \end{figure}
445 :    
446 :     The difficulty in this promise is that the promise itself refers to a third party,
447 :     and this mixes link-worlds with constraints.
448 :     As a single promise, this desire is not implementable in the proposed scheme:
449 :     \begin{itemize}
450 :     \item It refers to $B$, which $a$ has no access to, or prior knowledge of.
451 :     \item If refers to a potential promise from $a$ to $c$, which is unspecified.
452 :     \item It preempts a promise from $a$ to $b$ to never give $B$ along $a\rightarrow c$.
453 :     \end{itemize}
454 :     There is a straightforward resolution that maintains the autonomy
455 :     of the nodes, the principle of separation between nodes and
456 :     constraints, and which makes the roles of the three parties
457 :     explicit. We note that node $b$ cannot order node $a$ to do
458 :     anything. Rather, the agents must set up an agreement about their
459 :     wishes. This also reveals that fact that the original promise is
460 :     vague and inconsistent, in the first instance, since $b$ never
461 :     promises that it will not give $B$ to $c$ itself.
462 :     The solution requires a cooperative agreement (see fig. \ref{interloper}).
463 :     \begin{itemize}
464 :     \item First we must give $a$ access to $B$ by setting up the handshake promises:
465 :     i) from $b\rightarrow a$, ``send B'', ii) from $a\rightarrow b$, accept/use ``send B''.
466 :     \item Then $b$ must make a consistent promise not to send $B$ from $b\rightarrow c$, by promising ``not $B$'' along this link.
467 :     \item Finally, $a$ promises $b$ to cooperate with $b$'s promises about ``not $B$'', by promising
468 :     to cooperate with ``not $B$'' along $a\rightarrow b$.
469 :     This implies the dotted line in the figure that it
470 :     will obey an equivalent promise ``not $B$'' from $a\rightarrow c$, which
471 :     could also be made explicit.
472 :     \end{itemize}
473 :     At first glance, this might seem like a lot of work for express a
474 :     simple sentence. The benefit of the construction, however, it that is
475 :     preserves the basic principles of make every promise explicit, and
476 :     separating agents-nodes from their intentions. This will be crucial
477 :     to avoiding the contradictions and ambiguities of other schemes.
478 :    
479 :    
480 :     \section{Modal logic and reinterpretation using promises}\label{invol}
481 :    
482 :     The usual formulation of modal logical in terms of necessity is
483 :     unnecessarily fuzzy, even to the point of being incorrect. The
484 :     language of promises helps to clarify what is going on here.
485 :    
486 :     The problem lies in the semantics of the most basic assumptions about
487 :     necessity. The rule that $\boxx p \rightarrow \boxx\boxx p$ is pure
488 :     nonsense if $\boxx$ means necessity. It is not at all necessary that
489 :     things be necessary. One can choose `requirements' which is a
490 :     voluntary act about things defined to be necessary. Conversely, one
491 :     can mandate a voluntary choice in a multiple choice exam. Thus the
492 :     common language interpretation is simply wrong. However, all is not lost.
493 :    
494 :     Consider a reinterpretation of these quantities as follows:
495 :     \begin{center}
496 :     \begin{tabular}{ll}
497 :     \hline
498 :     $\boxx p$ & $V p = \neg \boxx p$\\
499 :     \hline\hline
500 :     $p$ is involuntary & $p$ is voluntary\\
501 :     \end{tabular}
502 :     \end{center}
503 :     Involuntary acts are made by an irresistable force, so we we are led
504 :     to the need to speak of forces that are beyond an agent's
505 :     control. However, every one of the following possibilities might be
506 :     true in some circumstances:
507 :    
508 :     \begin{itemize}
509 :     \item $\boxx \boxx p$: it was forced upon the agent to make $p$ involuntarily true (coercion).
510 :     \item $V \boxx p$: the agent chose to make $p$ involuntarily true (discipline).
511 :     \item $\boxx V p$: the agent was forced to make $p$ a voluntarily choice (authority).
512 :     \item $V V p$: the agent chose to make $p$ a voluntarily choice (decision).
513 :     \end{itemize}
514 :    
515 :     To handle this case, one can imagine making a proposition $p$ partially voluntary,
516 :     so that it consists of a voluntary (promised) part $p_v$ and an involuntary
517 :     part $p_\boxx$:
518 :     \beq
519 :     p &=& p_v \;\union\; p_\boxx - p_vp_\boxx\\
520 :     \boxx p &=& p_\boxx\\
521 :     V p &=& p_v
522 :     \eeq
523 :     Then we can say
524 :     \beq
525 :     p_v \; \intersect\; p_\boxx &=& \emptyset\\
526 :     V p \; \intersect\; \boxx p &=& \emptyset.
527 :     \eeq
528 :    
529 :    
530 :     \section{Promise graphs}
531 :    
532 :     The formulation of $\mu$-promises in the previous chapter has the
533 :     obvious characteristics of a network, or in graph theoretical terms a
534 :     so-called {\em directed graph} (a network of arrows). This is not a
535 :     particularly novel or unusual construction\endnote{Micropromises bear
536 :     a passing resemblance to the theory of capabilities in
537 :     ref. \cite{snyder1}}; many phenomena form such networks. However, its
538 :     commonality is a powerful identification of its ubiquity, and this
539 :     feature of promises will allow us to draw in many important insights
540 :     that have been made about networks in later chapters. For example,
541 :     directedness in graphs display the intricacies of {\em causation}: the
542 :     ordering of multi-agent phenomena.
543 :    
544 :     When a single agents makes a collection of promises to other agents,
545 :     some of these can be simplified or replaced by a single promise.
546 :     There can also be cases in which we attribute special meaning
547 :     (semantics) to particular combinations of promises, thus we begin
548 :     by discussing the basics of composition.
549 :    
550 :    
551 :     \section{The use promise is not primitive}
552 :    
553 :     The use-promise we have
554 :     referred to so far cannot be primitive promise type, since it includes
555 :     implicit information about the promise. We can express this by defining:
556 :     \beq
557 :     U(b) \equiv -\psi(b) \with \Upsilon(b).
558 :     \eeq
559 :     i.e.
560 :     \begin{quotation}
561 :     \begin{center}
562 :     Use $\equiv$ knowledge of content $\with$ intention to employ content
563 :     \end{center}
564 :     \end{quotation}
565 :     where $\Upsilon(b)$ is the primitive promise to act on an unconditional promise $\pi(b)$
566 :     that it has (necessarily) received directly.
567 :    
568 :    
569 :    
570 :    
571 :     \section{Transactions and duality}\label{not_duality}
572 :    
573 :     Each promise graph, classified in terms of $+$ and $-$ promise types
574 :     has at least two dual or complementary viewpoints.
575 :    
576 :     \subsection{Complementarity: Intent vs Implementation}
577 :    
578 :     The first concerns the duality between planning and implementation,
579 :     or declarative and imperative forms of a plan.
580 :     We can see this as in fig. \ref{duality}.
581 :    
582 :     \begin{figure}[ht]
583 :     \begin{center}
584 :     \includegraphics[width=12cm]{figs/duality}
585 :     %\psfig{file=serial.eps,width=4.5cm}
586 :     \caption{Alternative interpretations of a service interaction, in terms of
587 :     a service or transport.\label{duality}}
588 :     \end{center}
589 :     \end{figure}
590 :    
591 :     In the service view (a), the service provider takes ultimate responsibilty
592 :     by making a promise directly to the end reader, but it is a promise
593 :     conditional on the behaviour of the post office whose role is to
594 :     deliver the book. The positive aspect of this view is that it reflects
595 :     the reality of the trading interaction. The post office is merely an
596 :     assistant (see section \ref{assistance}). This is a version of
597 :     causation in which the original intention is the driver for events.
598 :    
599 :     In the transport view (b), we model this more closely related to the
600 :     physical implementation of the promise. The service provider
601 :     (bookshop) promises to pass the book to the post office, who in turn
602 :     promises the reader to deliver it, assuming that it gets the book in
603 :     the first place. This is a version of causation in which transactions
604 :     leading to fulfillment of the promise are in focus.
605 :    
606 :     In our view, the first of these is a more accurate representation of
607 :     the scenario, as it provides a deeper explanation for the events that
608 :     happen to transpire, and it places the end points of the service delivery in a
609 :     direct relationship with one another.
610 :    
611 :    
612 :     \subsection{Causation and time-reversal symmetry}\label{loops}
613 :    
614 :     Consider fig. \ref{timereversal} in its two incarnations. The
615 :     left and right hand versions tell exactly the same story, with
616 :     structually identical graphs, yet the $+$ and $-$ signs have
617 :     been reversed. The re-interpretation suggests (but does not prove)
618 :     that the reversal that takes place is the agent initiating the
619 :     relationship. It is often natural to assume that a $+$ promise
620 :     must come before a use-promise to make use of it. However, this
621 :     shows that no such rule is necessarily the case, as by renaming the
622 :     promises, we achieve the opposite result\endnote{Indeed, we
623 :     could interpret an initial promise to use a service as signalling a
624 :     request for a service (like placing an advertisement).}.
625 :    
626 :     \begin{figure}[ht]
627 :     \begin{center}
628 :     \includegraphics[width=12cm]{figs/timereversal}
629 :     %\psfig{file=serial.eps,width=4.5cm}
630 :     \caption{Alternative interpretations of a service interaction, in who initiates
631 :     the transaction.\label{timereversal}}
632 :     \end{center}
633 :     \end{figure}
634 :    
635 :     This insight is part of a general symmetry in transacations between
636 :     giver and receiver.
637 :    
638 :     The symmetry between $\pm$ promises is a fundamental one, what
639 :     physicists would call {\em time reversal symmetry}, or the lack of an
640 :     `arrow of time', in this case `who goes first'. Such is it with all
641 :     physical laws and mathematical expressions of change that there is no
642 :     implied direction to these causative arrows initially. It is up to the
643 :     analyst to break the symmetry by specifying a {\em boundary condition}
644 :     (or, in this case, initial condition), which manifestly breaks the
645 :     symmetry by deciding a given point at which we have certain knowledge
646 :     of the system concerned and in which direction from this milestone the
647 :     predictions (promises) of behaviour take us from that point.
648 :    
649 :     We should not assume anything about which agent makes or keeps a
650 :     promise first, simply from the structure of the graph. Additional
651 :     information is needed to specify the direction of causation.
652 :    
653 :    
654 :    
655 :    
656 :    
657 :    

Administrator
ViewVC Help
Powered by ViewVC 1.0.3