The diagram in Figure 1 shows an interaction between three peers: p1, p2 and p3. Each peer knows different things:

• p1 knows that queries asking about p(Y) can be sent to p2 and that queries asking about q(Z) can be sent to p3. We write this as query_from(p(Y),p2) and query_from(q(Z),p3).
• p2 knows that p(a) is true. We write this as know(p2, p(a)).
• p3 knows that q(b) is true. We write this as know(p3, q(b)).

The interaction we require is depicted by the numbered messages in the diagram:

• p1 sends a message ask(p(Y)) to p2.
• p2 sends a message ask(p(a)) to p1.
• p1 sends a message ask(q(Z)) to p3.
• p3 sends a message ask(q(b)) to p1.

Figure 1. Basic Interaction Example

Let us first define an interaction model that does exactly the message passing defined above. There are two roles that agents take in this model: the role of a requester (which asks for information) and the role of an informer (which supplies information). We define a LCC clause for each role as shown below. For the requester (p1) we have simply given the sequence of four messages corresponding to those above. Then we have defined a clause for the role of informer that defines the behaviour expected of p2 and p3.

a(requester, A) ::
    ask(X1) => a(informer, p2) <-- query_from(X1, p2) then
    tell(X1) <= a(informer, p2) then
    ask(X2) => a(informer, p3) <-- query_from(X2, p3) then
    tell(X2) <= a(informer, p3)                                               (1.1)

a(informer, B) ::
    ask(X) <= a(requester, B) then
    tell(X) => a(requester, B) <-- know(X)

The LCC definition above covers the example but suppose we want a more general type of requester that takes a list, L, of the form [q(Query,Peer), ...], where Query is the query we want to make and Peer is an identifier for the peer to which we want to send the query. We want the requester to send an ask(Query) message to the appropriate Peer for each query and receive a tell(Query) reply each time. A standard way to do this is by giving L as a parameter to the requester role (so it becomes requester(L)) and making the definition of this role recursive, taking the first element of L and then applying the same definition to the remainder of the list, Lr, as shown below.

a(requester(L), A) ::
    (ask(Query) => a(informer, Peer) <-- L = [q(Query, Peer)|Lr] then
    tell(Query) <= a(informer, Peer) then
    a(requester(Lr),A))
    or
    null <-- L = []

a(informer, B) ::
    ask(X) <= a(requester(), B) then
    tell(X) => a(requester(), B) <-- know(X)
                                                                                  (1.2)

If we were to run the interaction model shown above, starting with the role of requester for the list of queries [q(ask(p(X)),p2),q(ask(q(Y)),p3)], then we get the message sequences shown in Figure 2. On the left is the sequence for a(requester([q(ask(p(X)),p2),q(ask(q(Y)),p3)]), p1). On the right are the sequences for a(informer, p2) and a(informer, p3) which are the roles undertaken by p2 and p3 in response to p1. The dashed lines indicate synchronisation via message passing between peers.

Figure 2. Event Sequences for the Example

In our earlier example (definition 1.1 above) we made some of the message passing events contingent on constraints. For example sending the message ask(X1) => a(informer, p2) was contingent on satisfying the constraint query_from(X1, p2). These constraints are satisfied by connecting them to methods for computing the constraint. Although some basic methods (such as for basic forms of visualisation) are pre-supplied by OpenKnowledge we expect that most methods will be specific to application domains and so will need to be written or re-used by interaction model developers. To make it possible to share these methods, we allow appropriately packaged methods to be shared, so that peers can accumulate repositories of methods that they find useful. We call these OpenKnowledge Components (OKCs). A more detailed description of OKCs can be found here.