Information Technology Reference
In-Depth Information
up
(
s
1
)
up
(
s
3
)
s
+
relay
trap-open
at-trap
(
t
)
?
s
+
up
(
s
2
)
alive
(
t
)
?
+
light
b)
?
j
up
(
s
1
)
up
(
s
2
)
detect
Y
a)
c)
Figure 2.13.
Graphs representing the structural dependencies between fluents re-
garding a) Example 2.6.3, b) Example 2.10.1 (where
t
abbreviates
turkey
), and
c) state constraint
up
(
s
1
)
up
(
s
2
) (inducing a cycle), respectively.
Problem. Introduced in the context of Situation Calculus [74], it concerns
the at rst glance trivial but in fact highly problematic challenge to specify,
in logic, that non-aected fluents keep their truth-values during the perfor-
mance of actions. To see where the diculties lie, observe rst that na¨ vely
describing the eects of actions such as
toggle
(
x
) by means of classical
material implication does not work. E.g., the specication
Do
(
toggle
(
x
))
(
:
up
(
x
)
up
(
x
))
(2.52)
is inconsistent with, say,
:
up
(
s
1
)
^Do
(
toggle
(
s
1
)), i.e., the seemingly natu-
ral logical formalization of a situation where switch
s
1
is down and is about
to being toggled. This is why Situation Calculus introduces an additional so-
called situation argument to each action and fluent, restricting its scope to a
particular one out of many possible situations. The eect description (2.52)
thus becomes
:
up
(
x; s
)
up
(
x; Do
(
toggle
(
x
)
;s
))
where
s
denotes some abstract situation and
Do
(
toggle
(
x
)
;s
) the succes-
sor situation resulting from performing
toggle
(
x
)in
s
. This representation
technique, however, raises the problem of how to conclude that some other flu-
ent which holds in
s
,say
(
s
2
), still holds in situation
Do
(
(
s
1
)
;s
).
up
toggle
