The most direct way to assist in constructing LCC is by providing an editor in which editing operations are based on structural patterns that are meaningful in terms of the engineering of the specification. For example a common pattern for specifying recursive roles is as follows:

a(F(A1...An),X) ::
     ( then a(F(A1...An-1,AnN),X))
     or
     null <- 

where: F(A1...An) is a role definition with functor F and arguments A1...An; the new argument AnN is derived as a consequence of the earlier definition in the recursive part of the definition; and the base case is determined by some constraint, .

Patterns like the one above provide skeletal definitions for LCC specifications that can then be elaborated using further editing operations. This view of structured design is similar to the idea of techniques editing for logic programs. A basic structure editor for LCC is described in detail, along with examples of the system in operation, in our technical report on techniques editing.

Structure editors of the sort described above provide assistance in design but assume that those being assisted are interested in manipulating the target language (in our case LCC) directly; the engineer is always aware that he or she is working on a LCC specification. There are other forms of editing where this need not be the case and in the next section we consider one of those.

LCC is a process language in which the definition of a process orders message passing events. Consequently, there is no explicit representation in LCC syntax of the space of states that can be encountered in an interaction; this space can be inferred from a LCC specification, rather than being directly described by it. Some systems of design, however, start from a finite state model of interactions, in which the different states of the interaction are explicitly represented and events in the interaction appear as transitions between these states. One such style of specification in the multi-agent systems community is that of electronic institutions. Here the nodes represent the different states of the conversation and the directed arcs connecting the nodes are labeled with the actions that make the scene state evolve. The Electronic Institutions Development Environment (EIDE) is a tool for describing electronic institutions, with a translator that produces, automatically, LCC from the electronic institution specification. This means that designers who prefer a state-oriented rather than a process oriented view of interaction can still contribute to OpenKnowledge.

The mechanism for translation from electronic institutions in EIDE to LCC is described in Section 5 of the OpenKnowledge report on visualiser components and visual authoring tools. The basic idea is that definitions for the sequencing in LCC definitions of roles correspond to traces through the finite state machine of the electronic institution. This translation does not preserve some of the distinctions made in an electronic institution model because electronic institutions have, as primitive, a concept of scene composition that is absent (for reasons of parsimony) in LCC. The relationship between electronic institutions and LCC is described in detail in the OpenKnowledge report on Ambient LCC.

In Sections 1 and 2 we described systems to support the construction of LCC specifications. In order for interactions to do useful work, however, it is necessary to supply OpenKnowledge components that can be used by peers to satisfy the constraints in an interaction. Although component design inevitably involves some application programming, we can make this programming simpler by supplying a higher level, Java-compatible language targeted at component design.

Groovy is an agile and dynamic language for the Java Virtual Machine, it builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and other scripting languages. Groovy also increases developer productivity by reducing scaffolding code. It integrates with all existing Java objects and libraries seamlessly, therefore Groovy can be used to create OKCs that run within the OK kernel. Moreover Java developers are able to use Groovy with almost-zero learning curve, and it's also relatively easy for novice programmers to learn and use, enlarging the group of programmers able to write OpenKnowledge components themselves.

To demonstrate Groovy in use for component definition we applied it to one of our bioinformatics service coordination examples. The technical details of this (along with an illustrative example) are in our technical report on Groovy.