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.
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.
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.
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:
- All of them agree on the modification acceptance, then the modification is
committed into the group repository and broadcast to every subscriber
repository;
- One of them rejects the proposal, then the changes are not committed and
the comments provided by the rejecter are sent to the submitter (the call for
comments is cancelled);
- One submitter sends a counter-proposal, then the call for comments is
replaced by a call for comments about all the available proposals (those who
already accepted the change, are asked to consider the new proposal and to
answer again).
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.