The protocol semantics are embedded in the tuple centre as ReSpecT reactions. With ReSpecT it is possible to define rules that capture how a dialogue state changes when a locution is made. In [177], Uroviet.al use automated work-flows with interactions gov- erned by a dialogue game implemented inTuCSoN. I use a similar approach where each reaction to a locution has rules regarding how the dialogue state changes. A reaction has the following format:
reaction(Event, Body).
In the “Event” the locution is specified and in theBodyof the reaction the precon- ditions and post-conditions of the locution are implemented in the form of rules that need to be true for the reaction to be executed. So, semantics for a locution represented as a reaction are of the form:
reaction(out(Locution1()), P reconditions, P ostconditions).
Whenever a tuple matching the templateLocution1 is inserted in the tuple centre,
• a set of preconditions is checked (e.g. Is the syntax locution valid?, Does the current dialogue stage allow the locution?) and
• postconditions are executed (e.g. The dialogue history is updated, the dialogue stage changes, the agents’ commitment store is updated).
The flow of a reaction for the enter dialogue locution in Table 6.3 and for the open dialogueis presented in Figure 6.1.
out (open_dialogue (Ag))
Start Reaction Execute checkValid()
Preconditions Check syntax
Check dialogue state Check previous locutions
Postconditions Insert history tuple Insert participant
Increase participant counter
Abort reaction Commit reaction
if error
No Yes
Table 6.2: ReSpecT reaction pseudo-algorithm to the enter dialogue() locution.
ReSpecT Reaction Comment
1. out (enter dialogue(Ag)) Reaction specification 2. Start reaction
3. While no error Start a transactional process
4. Check locution syntax Check if there exists a tuple that matches the entry 5. Check dialogue state = idle Validates if the dialogue state is idle
6. Insert history Tuple Inserts a valid history tuple
7. Insert participant RegisterAg as a dialogue participant 8. Increase participant counter
9. End while
10. If Error If there is an error in any of the reaction 11. Roll-back and Abort reaction instructions roll-back the transaction 12. End If
13. End Reaction
The semantics for theenter dialogue() andpropose() locutions inReSpecT are given in Tables 6.3 and 6.4. The semantics of the protocol as ReSpecT reactions are given in Appendix B. Note that the public commitment stores are not implemented in the ReSpecT language.
Table 6.3: ReSpecT reaction for the semantics of theenter dialogue() locution
ReSpecT Reaction Comment
reaction(out(enter dialogue(Di, Ag)), Tuple is inserted (outr(checkV alid(loc(enter dialogue(Di, Ag))))). Check locution
reaction(out r( Internal reaction to check the locution, checkV alid(loc(enter dialogue(Di, Ag)))),
Preconditions
rd r(loc(enter dialogue( , ))), If tuple is part of the syntax rd r(dState(open)), Check dialogue state
no r(dhistory(enter dialogue( , Ag))), Check previous locution by same agent no r(dhistory(open dialogue( , Ag))), The dialogue should not be
opened by the same agent Postconditions
out r(participant(Di, Ag)), Register participant
in r(n participants(N)), Increase the participants counter N1 isN + 1,
out r(n participants(N1)),
out r(dhistory(enter dialogue(Di, Ag))), Insert dialogue history tuple in r(checkV alid(( ))), Clean auxiliary tuples in r(enter dialogue( , ))))
Table 6.4: ReSpecT reaction for the semantics of thepropose() locution
ReSpecT Reaction Comment
reaction(out(propose(Di, Ag, P r)), Propose plan tuple to react Preconditions
(rd r(loc(propose( , , ))), Check the locution is in the protocol syntax rd r(dState(open)), Check the dialogue state
rd r(participant(Di, Ag)), Check participant Ag is in the dialogue Postconditions
out r(dhistory(propose(Di, Ag, P r))), Insert dialogue history tuple out r(dState(proposing)), Change dialogue state
in r(dState(open)), Delete previous dialogue state
out r(role(Di, roleP r, Ag)), Assign role“ proponent” to the agent in r(propose plan( , , )))). Clean auxiliary tuples
The syntax of the critical questions is the following:
cQ(layerN umber, questionN umber, elementIdentif ier, typeof Attack) where:
• layerN umbercorresponds to the critical question layer (cf. Chapter 3),
• questionIdentif ier refers to the critical question identifier,
• elementIdentif ier is the element identifier that could be the plan, action or a condition identifier,
• typeof Attack refers to the type of attack.
In this way all the questions are specified in the tuple centre determining the way in which the proposal can be questioned and/or attacked. The format of the critical questions is given in Table 6.5 and Figure 6.2 presents a screen-shot of the tuple centre in the system. Figure 6.3 presents an overview of how the tuple centre is formed.
Table 6.5: Critical QuestionsReSpecT format
Critical Questions Examples Description
cQ(layer1,qA06,startEffects,possibility) Layer 1, question CQA-06, questions the possibility of a start effect of an action cQ(layer2,qAT02,startTime,possibility) Layer 2, question CQAT-02, questions the
possibility of the start time of an action cQ(layer3,qAC01,Action1,Action2,concurrency) Layer 3, question CQAC-01, questions
concurrency of two actions
cQ(layer4,qPP02,norm,validity) Layer 4, question CQPP-02, questions the validity of a norm
cQ(layer5,qPPT01,startTime,possibility) Layer 5, question CQPT-01, questions the possibility of the start time of the plan cQ(layer6,qSE01,value,demotionSideEffect) Layer 6, question CQSE-01, questions
demotion of a value
cQ(layer7,qAO01,value,alternativePlan) Layer 7, question CQAO-01, inquires for an alternative plan to promote the same value
out ( ) in ( ) out_r ( ) in_r ( ) Internal events Protocol Syntax Respect reactions reaction(out(propose_plan(D,A,P,Id)), reaction(out(enter_dialogue(D,A)), reaction(out(propose_plan(D,A,P,Id)), reaction(out(norm(D,A,P,Name,Id,Value,Token)), reaction(out(currentCirc(D,A,P,Name,Id,Value,Token