Introduction to the CO4 protocol

In order to specify CO4, requirements for the software manipulating repositories and communicating between them must be designed. The specification of the software is presented below together with the way it is used either manually or automatically.

The organisation of repositories in order to contribute to a consensual repository is first introduced before providing the principles of the CO4 protocol form the viewpoint of the individual users and from that of consensual repositories.

The network of repositories

In CO4, any cooperator is viewed by the system as a repository. In order to build a consensual repository, the individual repositories must be linked together. Repositories are organised into a tree whose leaves are user repositories and whose intermediate nodes are called group repositories (see ). Each group repository represents the knowledge consensual among its sons (called subscriber repositories). This structure imposed to the collaboration can be stuck on the structure of a particular firm or that of a particular group in the firm, but it can also be independent from that structure. A repository can subscribe to only one group. A human user can create several repositories (possibly subscribing to different group repositories) representing different trends, and knowledge can be transferred from one repository to another. Also, nothing prevents several human users from sharing the same repository.

Figure . The hierarchical architecture and message flow (dark arrows). The repositories are organised in a tree whose leaves are individual repositories and nodes represent the consensus between of connected individuals. The downward types of messages include the submission of a proposal and the reports of approval, rejection or counter-proposal about a submitted proposal. The upward messages include the broadcast of accepted proposals and the call for comments (ask-all) about a submitted proposal.

Individual users can subscribe to a consensual repository by sending a register request which has to be accepted by the group repository (thus by the current subscribers). Upon acceptance the respective repository definitions of the group repository and the individual repository are aware of each other. As soon as the repository is part of a group repository, it receives the complete contents of that repository (that it is supposed to accept). It is also entitled to give its opinion on all submissions currently under examination and is allowed to submit knowledge. The interesting point is the submission of knowledge which is described right below.

Some independent repositories can subscribe to group repositories as observers: the group repository sends to these repositories whatever is introduced in the repository they but cannot modify the group repository. Observers are not further considered in this presentation.

A group repository sends to its subscribers messages for broadcasting a change accepted by everyone and calls for comments in order to establish whether a change must be committed or not. A (group or individual) repository sends to its group repository changes which it wants the group repository to integrate. Of course, any group repository, as an individual repository also receives calls for comments and change broadcast.

A glimpse at submission from the user viewpoint

When subscribers are confident enough with some pieces of knowledge, they can submit them to the group repository to which they subscribe. This is achieved by circumscribing the submitted part and calling the submission procedure of the negotiation controller. In order to complete the submission message, the negotiation controller collects the sets of differences between the consensual group repository connected and the selected changes (logged by the revision controller) and sends them to the group repository. Usually, the group repository, through its own revision and negotiation controllers, issues a report describing how the submitted knowledge can be added to the group repository. Thus, the user can eventually choose a better (and consistent) way to achieve the submission. This proposal is then submitted to the other subscribers and finally committed if it reaches consensus.

As subscriber of a group repository, the user also receives the calls for comments issued by the group repository in response to the submission of some material. Users can read the submission or apply it in their own repository by submitting it to the revision controller. This can result in a favourable agreement report or an inconsistency detection that can be used by the user for issuing a counter-proposal. In response to the call for comments, users must answer by one of the following: "accept" when they consider that the knowledge must be integrated in the consensual repository, "reject" when they do not, and "challenge" when they propose another change.

When the group repository has gathered enough comments, it integrates, or not, the change in the repository. If the change is consensual, it is broadcast to all subscribers. It may happen, however, that the research they are currently involved in contradicts what is in the group repository. So users can refuse the new piece of knowledge (just as they can modify parts of the group repository knowledge in their local repository) which is then stored in a change logbook for further change submission.

The fact that anyone can maintain a repository different from the consensus obviously allows the exploration of concurrent paths. On a more basic ground, this enables communication, negotiation and acceptation to be asynchronous. It reproduces the way papers are submitted, discussed and accepted or rejected in a scientific journal: reviewers can take time for carefully examining a proposal since it will not stop the work of the repository which issued it.

Paper submission metaphor as implemented by consensual repositories

Any system allowing to build some artefact must have a particular change policy. The CO4 protocol mimics that of editorial boards: before being introduced in a consensual repository, knowledge must be submitted and accepted by the community. To our knowledge, the peer-reviewing protocol [Peters 1995] has never been used for building knowledge bases. The choice of such a protocol is not innocent: it proved to be practicable within the scientific community and, in the consensual version, it enforces the dialogue between people (rather than a simple majority or intersection protocol).

Consistency and formality require more strictness in the protocol than pure peer-reviewing; this leads to the consensus requirement (i.e. in which, a modification, for being accepted, must have been agreed by all other members -- for instance, in the context of genome sequencing, a consensus map is a map that all the people involved in the research field think correct). Integrating knowledge requires its submission to the repository.

When a group repository receives a submission it issues a call for comments towards all of its subscribers. Among the answers provided by the subscribers, three cases may happen:

It can also happen that the submitter retracts the proposal thus leading to the retraction of the call for comments from all the repositories.

The CO4 protocol applies to several levels: the group repositories can be grouped together into a more important group repository and so on. However, the behaviour of such a group repository is still subject to the consensual approbation of its subscribers. Thus, for instance, a consensual representation could be achieved inside a particular firm before being submitted to the inter-institution repository.