Jérôme Euzenat
email: jerome.euzenat@imag.fr

Building consensual knowledge bases: context and architecture

Keywords:

A protocol and architecture are presented in order to achieve consensual knowledge bases (i.e. bases in which knowledge is expressed in a formal language and which are considered as containing the state of the art in some research area). It assumes that the construction of the base must and can be achieved collectively. The architecture is based on individual workstations which provide support for developing a knowledge base: formal expression of knowledge through objects, tasks and qualitative equations annotated with hypertext nodes and links. It also provides tools for detecting similarities and inconsistencies between pieces of knowledge. These bases can be grouped together in order to constitute a new reference knowledge base. The process for constructing this last base mimics the submission of articles to peer-reviewed journals. This is achieved through a protocol for submitting knowledge to the group base, confronting it with the content of that base, amending it accordingly, reviewing it by the other knowledge bases and finally incorporating it. The system is to be used by researchers in the field of genome sequencing.

as a medium. It is used for communicating informal text (by mail or ftp), but moreover for communicating the formal results of experiments (through the large general sequence data banks and small specialised ones [START_REF] Overton | GeneSys: a knowledge management system for molecular biology[END_REF][START_REF] Takana | A private knowledge base for molecular biological research[END_REF][START_REF] Karp | Representing, analyzing and synthesizing biochemical pathways[END_REF]). We have already developed knowledge management tools which have been used in the building of knowledge bases in molecular genetics [START_REF] Rechenmann | Building and sharing large knowledge bases in molecular genetics[END_REF] and other fields [START_REF] Willamowski | A development shell for cooperative problem-solving environments[END_REF]. We are currently involved in the development of a (software) workstation for molecular genetics research in close collaboration with two biology laboratories.

The "computer as medium" idea could be strengthened by extending it towards the knowledge itself. Hence, instead of merely reproducing the paper journals in computers, the principles of scientific journals must be applied to the knowledge formally expressed in a computer. The result should be a consensual knowledge base, i.e. which everybody in a group agrees to be a reasonable state of the art. It can be used for confronting new results and for learning new knowledge. A consensual knowledge base can also evolve with research results. For that purpose, a computer environment called Co 4 (for collaborative construction of consensual knowledge) is presented here. Co 4 is dedicated to the incremental and concurrent building of a knowledge base organised around formalised knowledge and a set of various annotations (text, bibliography, image, experimental data, etc.) from which this knowledge originates. It provides researchers with support for, on one hand, expressing, annotating and manipulating their knowledge, and on the other hand, submitting it to other people and achieving consensus.

The organisation of the paper is as follows: first the features of a researcher workstation are presented. This is basically an extrapolation from what already exists in biology laboratories. Then, the organisation of a college whose aim -from the computer point of view -is the constitution of a consensual knowledge base is presented. It includes the protocols for consulting and submitting knowledge to the base. The fourth section takes a closer look at the software ground for such a system and fundamental problems which remain open. Finally, an extended discussion places Co 4 in the many current trends of knowledge sharing and collaborative work.

2.THE RESEARCHER'S WORKSTATION

The aim of Co 4 is the construction of a formalised knowledge base: this means that knowledge is expressed in a formal language carrying a precise semantics. The formal structure of the corpus enables the use of consistency checking or comparison tools for helping the process of integrating knowledge into the base and the process of revising the base when necessary. As anyone would agree, this is far too formal and restrictive, so the formal knowledge is connected to informal knowledge (mainly in terms of text and image) structured in a hypertext network. This informal knowledge has two purposes: recording the reasons for acceptance and changes in the knowledge base and adding annotations to the formal knowledge. This section describes the components of a knowledge base and their manipulation by a user. The next section describes how the knowledge bases can communicate with each other.

. 1 . The knowledge model

Co 4 comes from two experiences with knowledge bases in the domain of molecular genetics. The first one, ColiGene [START_REF] Perrière | ColiGene: objectcentered representation for the study of E. coli gene expressivity by sequence analysis[END_REF], describes the regulation mechanism of gene expression in the E. coli bacterial genome. The second one, MultiMap, allows to describe and to manipulate mammalian genomic maps at the cytogenetic, genetic and physical levels. The researcher's workstation is an assistant to the researcher. It helps the description of knowledge and also its discovery by automating the more repetitive tasks of genome research. The design of these two knowledge bases has led to the identification of four types of knowledge to be represented:

• Descriptive knowledge on the biological entities involved is represented in an object-based knowledge representation system. This enables the representation of classes of objects (e.g. genes), subclasses (e.g. protein genes) and the identification of an object as belonging to such a class. • Methodological knowledge specifies the ways to select and link up methods for a given task. It is represented through a task management system able to integrate, represent, process and monitor the many computer programs for analysing the results of experiments. • Behavioural knowledge, which has not been introduced in these two knowledge bases, concerns the modelling of dynamic phenomena, such as the dynamics of gene inhibition or activation, through a qualitative modelling system. Such kind of knowledge has already been used for representing metabolism [START_REF] Karp | Representing, analyzing and synthesizing biochemical pathways[END_REF]. • Textual annotations on the various objects and tasks involved are achieved through a hypertext system which connects hypertext nodes with the components of the descriptive and methodological knowledge. It allows browsing among texts, objects and tasks (see figure 1).

Figure 1 (adapted from [START_REF] Rechenmann | Building and sharing large knowledge bases in molecular genetics[END_REF]): The navigational interface using hypertext. The user has selected a class in the class taxonomy (upper window) and has consulted the associated node of the hypertext (lower window). Some of the words of the text are links to other nodes. From a hypertext node, it is possible to come back to the entity it is attached to. The example is drawn from the ColiGene knowledge base, in which only the highest levels of the specialisation graph have been annotated, essentially for pedagogical purposes.

The knowledge, both formal and informal, is stored in an object-based knowledge representation system called TROPES [START_REF] Mariño | Multiple perspectives and classification mechanism in Object-oriented Representation[END_REF]. It comes with a clear and simple formal semantics and tools for classification, constraint management and task processing. In particular, it is able to organise objects into multiple separated taxonomies and allows the user to work on a subset of these taxonomies. It thus answers to the need to express several viewpoints on object classifications [START_REF] Overton | GeneSys: a knowledge management system for molecular biology[END_REF][START_REF] Karp | Representing, analyzing and synthesizing biochemical pathways[END_REF]. TROPES precursor, SHIRKA, has been connected to a hypertext management system [START_REF] Sylvain Grivaud | Navigation dans les bases de connaissances associant objets et hypertextes[END_REF] and it is planned that it will soon be the same for TROPES.

. . Software architecture

The architecture of the Co 4 workstation is as described in figure 2. It is made up of three main layers:

• A user interface allowing the researchers to communicate with their knowledge bases and with other knowledge bases; For the sole manipulation of the knowledge base, the user only accesses the revision and negotiation controllers through the graphic interface (see figure 3). The other components are used in the cooperative process; they are included here for completeness. However, the knowledge management system is accessed through an application programming interface which enables queries and tentative modifications of the base from both the graphic interface and messages coming from other bases (see §3).

. 3 . The user and the base

The present section shows how the user can interact with the knowledge base. It can seem obvious that the user can query and modify the base and that modifications must leave the base in a consistent state. However, the way this is achieved in Co 4 is particular since it must work when the researchers want to communicate a part of their bases to another base. Thus, the way individual stations work is useful for both the individual and the cooperative modes. The process is presented in figure 3.

The consultation or modification are ordered through the graphic interface and directly processed by the revision controller. However, in the usual mode, the modification is prepared by a confrontation query which asks for a comparison of a new piece of knowledge (made of objects, tasks, hypertext nodes and qualitative equations) and the knowledge base. The comparison of a corpus of knowledge with another results in a report about what is different, what is the same and what is contradictory. If the piece of knowledge does not contradict the knowledge base, it can be submitted for integration. If it contradicts it, the researcher can modify it in order to fit the group base. Concerning the informal documentation, if the user wants to create a hypertext node for instance, it is possible to detect if a node with the same name already exists and to negotiate its modification.

A first requirement for a formal knowledge base is consistency. Consistency is here defined with regard to what the system can deduce to be consistent or not: in typical object-based representation systems, a class whose extension is logically reduced to the empty set is inconsistent and an error is raised by the system. Apart from consistency checks, the system is able to deal with sophisticated queries asking if a piece of knowledge is redundant, subsumed or similar (w.r.t. some distance) to a part of the knowledge base. These queries are subject to limitations drawn by the expressiveness of the knowledge representation language and the expected degree of completeness of the answer.

When a change is attempted, it first goes through the update and revision controller which determines if the change does not introduce inconsistencies. The organisation of Co 4 is particular in that the revision controller, which is usually a part of the knowledge base management system, has been detached from the knowledge base itself. The revision controller should be able, given an operation on a knowledge base, to manage it in the most consistent way. If the proposal is consistent with the base, the change is committed and the knowledge base is simply modified. The controller also records all the modifications committed directly by the user in order to be able to transmit them later to the group base (the modifications must be recorded together with their rationale, etc.).

Change and query

Error message and answer Report Query Choice Figure 3: Interactions between the users and their bases. The arrows represent the flow of information: the user can query the knowledge base and get an answer or a report. The report can be made of a set of alternative changes to apply to the base in order for the user to achieve a modification of the base. This requires a dialogue between the revision and negotiation controllers for determining what are these possible changes.

When Co 4 detects some problem (misspelling, typo, inconsistency) it raises an error which is transmitted to the negotiation controller. The negotiation controller then opens a dialogue with the update controller in order to establish the putative causes of each error and the possible repairs. Then the negotiation controller is able to submit these diagnoses and repairs to the user through the graphic interface. It is up to the user to decide which one to apply (or to retract the tentative change).

The behaviour and decomposition of the architecture is directed by the wish to provide the most efficient response to a tentative change of the base. It is based on the idea that when users ask for a change, they express the will to see it committed. Thus if this change is not immediately possible, Co 4 must propose the best way to make it possible while preserving the majority of the base. This enforces the opportunities for the change to be accepted by the other partners when it is submitted to the consensual knowledge base. The same holds true for propositions of the system concerning similarity.

Moreover, in the context of the submission of knowledge to a collective base, the architecture allows to ask for a report and help from that base. This is presented below.

3.OVERALL ARCHITECTURE AND PROTOCOL

The primary aim of Co 4 is the construction of a consensual base. The principles underlying Co 4 are derived from those of peer-reviewed journals: before being introduced in a consensual knowledge base, the knowledge must be submitted and accepted by the community. This requires submitting knowledge to the base, letting it be reviewed by the other participants and accepting or amending it according to their reactions. The informal knowledge is also subject to submissions, reviewing and so on. At the end, it is intended that the knowledge stored in a consensual knowledge base be safe enough so that anybody can use it confidently and easily.

In this section we emphasise the collaborative facilities offered by Co 4 . The organisation of a college of knowledge bases is first presented. Afterwards, the interaction of a workstation with the consensual group bases is detailed before turning to the protocol implemented for dealing with knowledge submission and negotiation.

. 1 . The network of knowledge bases

Co 4 is made of a set of knowledge bases. Any cooperator is viewed by the system as a knowledge base. Knowledge bases are organised into a tree whose leaves are user knowledge bases and whose intermediate nodes are called group knowledge bases (see figure 4). Each group base represents the consensual knowledge shared by its sons (called subscriber knowledge bases). Each knowledge base can subscribe to only one group. However nothing prevents a human researcher from creating several knowledge bases (maybe subscribing to different group bases) representing different research trends, and nothing prevents anyone from transferring knowledge from one base to another. Also, nothing prevents several physical users from sharing the same base. The downward types of messages include the submission of a proposal and the reports of approval, rejection or alternate 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.

Group knowledge base

Subscriber knowledge bases

The knowledge bases are linked together in such a way that a particular knowledge base knows its subscribers and its group base. To its subscribers it mainly sends messages for broadcasting a change accepted by everyone and calls for comments in order to establish whether a change must be committed or not. To its group base it sends changes that it wants the group base to integrate. Of course, as a group base, it also receives changes to commit and as a knowledge base it also receives calls for comments and change broadcasts.

Each of these knowledge bases are made of the same structure and the same software. The main difference between group bases and researcher workstations is that the former are completely automated and only respond to the stimuli from other bases.

. 2 . The user and the group

The user of a workstation can subscribe to a consensual knowledge base. This is achieved very simply through the knowledge base definition controller which manages the description of the group to which the knowledge base subscribes (and for the group bases, the set of subscribers). This base definition enables the communication layer to route queries from one base to its group base and its subscribers. It is intended that it also describes the topics which the knowledge base is interested in, etc.

As soon as the base is part of a group base, it receives the complete content of that base (to which it is supposed to subscribe), it is entitled to give its opinion on all submissions currently under examination and is entitled to submit knowledge. The interesting point is the submission of knowledge, so let's see what happens.

When the researchers are confident enough with the specifics of their knowledge base corresponding to some research results, they can submit them to the group knowledge base to which they subscribe. This is achieved by circumscribing the submitted part (which can include hypertext annotations justifying them) through the graphic interface 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 base connected and the selected changes (they are logged in by the revision controller) and sends them to the group base. Usually, the group base, through its own revision and negotiation controllers issues a report describing how the submitted knowledge can be added to the group base. Thus, as usual, the user can choose a better (and consistent) way to achieve the submission. This proposal will be submitted to the other subscribers and committed if it reaches consensus.

As a subscriber of the group base, the user also receives the call for comments issued by the group base in response to the submission (by another user) of some material. The users can read the submission or play it in their own knowledge base by submitting it to the revision controller. This can result in a favourable report or an inconsistency detection that can be used by the user for issuing an alternate proposal. In response to the call for comments, the users must answer by one of the following: accepted when they consider that the knowledge must go in the consensual knowledge base, rejected when they do not, and alternate when they propose another change.

When the group base has gathered enough comments, it integrates, or not, the change in the base. The change being now 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 base. So the users can refuse the new knowledge (just as they can also modify parts of the group base knowledge in their local base) which is then stored in a change logbook for further change submission.

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

. . The submission protocol

The words consensus, message, etc. have been used freely so far. A protocol has been established for the communication between the knowledge bases. It is implemented in the cooperation controller of the knowledge bases. The protocol is very simple, since it only reproduces what happens for paper submission to journals plus the management of new subscriptions. The messages are expressed as a collection of speech acts: achieve (submit a proposal for inclusion into the consensual base), ask-all (ask for the acceptance of subscriber bases, call for comments), accept (accept the insertion of the piece of knowledge), reject (reject it), challenge (submit a concurrent proposal), deny (the submitter retracts the submission), tell (send an accepted proposal to each subscriber base). It seems quite general since the performatives can be found, for instance, in concurrent software engineering [START_REF] Narayanaswamy | Lazy" consistency: a basis for cooperative software development[END_REF][START_REF] Winograd | A language/action perspective on the design of cooperative work[END_REF].

The consensual aspect is dealt with through the acceptation of proposals which achieve acceptance by all of the subscribers and the rejection of other proposals (for instance, in the context of genome sequencing, a consensus map is a map that people involved in the research field think correct). Consensus could be replaced by some other definitions (like majority or intersection, see §4.1), but it has been retained for two reasons: (1) it enjoys interesting formal properties (if a consensual base contains only knowledge which is accepted by all the subscribers, this remains true if subscribers are added or retracted), and (2) it should lead to the discussion of proposals -not only conflicts -and thus the collaboration of the researchers.

In a first version of Co 4 , the group base applies the non destructive modifications without discussion. These modifications are always possible in the group base, since they are in the subscriber's base which contains it. In the case of destructive modification, a call for comments, identified by a unique number (surrogate), is issued towards all the subscribers. Among the answers provided by the subscribers, three cases may happen:

• They all agree that the modification must be accepted, then the modification is committed into the group base and broadcast to all the subscriber knowledge bases; • 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 discarded in all the subscribers knowledge bases); • One submitter sends an alternate proposal, then the call for comment is replaced by a call for comment about all the proposals available (those who already accepted the change, are asked to consider the new proposal and to answer again). It also can happen that the submitter retracts the proposal thus leading to the retraction of the call for comments from all the knowledge bases.

The protocol is made of a set of rewrite rules which state what a knowledge base must do when it receives a particular message from another knowledge base. Each rule specifies what happens when some performative is received by a knowledge base, for instance: s -reply(n,accept) -> g C:=C-{<n,achieve(p),1>}, K:=K+p, g -tell(p) -> S <n,achieve(p),1> C means that upon arrival of the last "accept" for a proposition with surrogate n, the group base discards the structure recording the call for comments process, adds p to its local knowledge base and broadcasts it to each subscriber. The group bases blindly apply these rules and the final decision comes from the researchers who are the holders of the leaves of the architecture. When a message is issued by a group base whose subscribers are also group bases, these last bases only dispatch the messages to their subscribers. The protocol is presented in figure 5 as a finite state automaton. It is worth noting that the protocol is (1) asynchronous, so that several proposals can be in different states concurrently, (2) parameterised by proposal p, so that the real situation in Co 4 is the Cartesian product of automata corresponding to all the proposals, and (3) abstracted from the status of each individual knowledge base with regard to the protocol. Some properties of the protocol can be proved (under additional assumptions): whenever a proposal is submitted, it reaches in a finite time the status of accepted or rejected, the protocol always takes into account the opinion of a reviewer (it never waits for a report when it is established that the proposal is to be rejected, etc. -see §4.3). The protocol is handled by the cooperation controller which acts differently on an individual base and on a group base: in the first case it submits the changes to the user interface while in the second one it dispatches them to all of its subscribers. The cooperation controller is also in charge of the management of the negotiation for applying a change in a group knowledge base (emitting the call for comments, receiving the answers, managing the alternate proposals and committing or retracting the changes). The negociation requires the identification of the change by a unique number, the count of positive answers, the management of alternate proposals and retractions of a proposal. It also requires the recording of the process in order to recall the reasons why some change is made or not.

4.SOFTWARE TECHNOLOGY

The development of the platform presented above is not yet complete and the representation of genetic knowledge is not a simple task. However, the technology for object based-knowledge representation is well known, and similar experiences that we have had, lead us to be confident of its achievement. Thus, the present section focuses on the specific problems concerning the cooperation between distributed knowledge bases. To our knowledge, the technology is not already established for such a proposal; thus the Co 4 proposal is an occasion to explore solutions for two particular fundamental research areas: assisted revision in knowledge bases ( §4.2) and cooperation protocols ( §4.3). Problems and solutions are presented below, but keep in mind that they should meet acceptance from the users before being declared successful. So, the properties of the architecture enabling a smooth integration of facilities are first presented ( §4.1).

. 1 . Modularity and genericity

The knowledge base architecture presented above included two particularly interesting design choices: it is the same for all of the bases, so they can be made out of the same software packages, and it is described in a modular fashion, so that it can be used with a very raw system or a very complex one. This leaves the door open for a trade-off between the complexity and power of each algorithm. This is very precious during Co 4 development since it allows us to start with very simple components and to enhance them progressively.

For instance, the knowledge repository can be a simple hypertext system which identifies nodes by a reference and raises an error when two nodes have the same reference (the simplest system is a text repository with the UNIX "diff" and "patch" utilities). The degré zéro of change control consists in routing error messages to the user, in order to have the error corrected.

Such a system can be enhanced, for example, in the framework of a logic clause representation system (say Prolog) by a revision module able to abduct the reasons for the errors and to display them to the user who can take the corrections into account. Going further in this direction the revision module can be a knowledge base combining algorithm able to automatically propose corrections (e.g. [START_REF] Baral | Combining knowledge bases consisting in first order theories[END_REF]).

Finally, the protocol can be easily replaced by another one, based for instance on a vote of the majority of the subscribers, on the intersection of all of the knowledge base or on economic decision making (for determining the introduction or not of knowledge into the base). The protocol is also designed independently of the content and language of the knowledge base. This enables to use it for different pieces of knowledge (hypertext or classes as well as tasks or equations). One could imagine to refine the protocol for dealing specifically with these expressions. However, the specific aspect is actually assigned to the revision module which issues the reports.

So, the architecture and the protocol provided above are independent of the knowledge repository and the modules which manage it.

. 2 . Assisted revision in object based knowledge bases

The aim of the update and revision controller is the modification of the knowledge base. It is usually a part of the knowledge base able to perform an authorised operation on a knowledge base or to raise an error. The revision controller should be able, given an operation on a knowledge base, to resolve it in the most consistent way (this covers truth maintenance or, when an error message is raised, finding the best way to achieve the operation). The aim of Co 4 will be to propose meaningful ways to realise it, the last word being that of the user or the subscribers.

Assisted revision of knowledge base -i.e. the ability of detecting error messages and proposing consistent changes -is related to the problematic of knowledge base revision. It is a real enhancement with regard to current knowledge base management systems and is required by the submission of the knowledge of a particular base to another.

Knowledge base revision has been introduced in [1]: from a set A of axioms which deductively leads to a theory Th(A), let the operation be such that A p is the set of maximal subsets of A such that p T h ( A ) . Retraction (-) and revision (+) operations are defined such that A-p A p if A p Ø, and A-p=A otherwise. A set of eight postulates defines what are the possible retraction operators (A p is deductively closed, does not entail p, contains Th(A) if p Th(A), etc.). These postulates can also be defined for revision.

Syntactically, existing knowledge representation systems are already capable of inference, consistency check and even revision since it is possible to add new objets (or classes or field values, etc.). Thus this framework can be applied to object-based systems: the set of axioms (A) is the content of a knowledge base communicated by the subscribers, the theory (Th(A)) is what is deducible from A.

The decision problem on what is deducible or what is inconsistent is computationally language dependent. In TROPES, it seems that it is decidable but that some predicates such as classifiability should be at least NPcomplete. In object-based knowledge systems, the foreseen revision operators should have the following properties:

• They strongly take into account the syntactic structure of the object-based representations, which defines the revision rules for the syntactic operators over objects (a class is less often modified than a simple instance for instance); • They correspond semantically to the postulates for preferred revision -the model preference being defined by a relationship between them -allowing the definition of a relational revision operator [START_REF] Alchourrón | On the logic of theory change: partial meet contraction and revision functions[END_REF]. TROPES is able to signal errors. This is the basis for update and revision. These errors are transmitted to the negotiation system (errors are not just messages, but structured objects enabling the identification of the error). This is systematically used in order to detect what are the causes of the error and then what are the possible alternative changes which may be issued. For instance, when an overly large domain is given to a field in a class, object-based systems issue errors such as "your domain includes values which are not possible for the field". However, the solution can be the restriction of the given domain or the enlargement of the domain for the superclasses of the class (there may be other errors: the class is not the right one, the field is not the right one, etc.). A system like TROPES must be able to find these simple causes for errors and to prepare a repair action.

More operationally, the aim of such operators is: 1) localising quickly all the sources of inconsistency; 2) finding repair solutions to these inconsistencies; 3) ordering these sources and solutions with regard to their syntactic nature; 4) presenting them to the user.

At least it is not intended that Co 4 applies the revision by itself, but rather that it helps the researchers to easily revise their knowledge when it is inconsistent. In the framework of such a system, there are strong constraints of speed and intelligibility. It seems that these constraints can be satisfied with the help of the use of interaction which allows fast feedback from the user and the constraining structure of objects (which limit the exploding character of abduction and can reduce the size of the search space).

Another promising idea is the revision operation based on what a the users know and what they are interested in. TROPES already supports, through viewpoints, the selection of a particular perspective on knowledge. Ordering the topics of interest has already been used for expressing the semantics of revision with several people involved (in the expression of knowledge) [START_REF] Cholvy | Reasoning with information sources ordered by topics[END_REF].

. 3 . Cooperation protocol

The cooperation protocol is based on the architecture of the knowledge bases (which ones are the group base and which ones are the subscribers) and a complete set of behaviour rules [START_REF] Euzenat | Building consensual knowledge bases: protocol[END_REF]. This protocol has several properties: -there is no need for human intervention in the group base; -there is no message but from group base to subscribers and back; -each decision has been approved by all the subscribers (recursively for a group of group bases). The actual protocol is routed automatically (once a knowledge base has subscribed to another), the performative and content levels are interpreted automatically in the group bases and the performative level is automatically interpreted by the individual knowledge bases (however, the system asks the user before committing these performatives).

The set of messages sent from one base to another are expressed through a speech act (loosely inspired from "speech act theory"). Speech acts are used here for building a set of relevant "artificial" acts rather than trying to understand the "natural" speech acts occurring in ordinary conversation (the same way the idea of a grammar has been borrowed by computer science from linguistics). Thus each particular act carries a precise semantics (taken as the goal of the sender). The notion of a speech act has several advantages for the particular architecture presented here:

• It allows the separation of knowledge from what its use (add or retract it from a particular base, for instance); • It is independent from the knowledge representation language and the protocol can thus be expressed abstractly and the library implementing it can be used with other systems; • It allows a speech act to refer to another speech act (retracting a submission, for instance). The inter-base communication uses KQML (Knowledge Query and Manipulation Language [START_REF] Finin | KQML as an agent communication language[END_REF]) which has been chosen because, in its early stages, it clearly distinguished the three levels required by Co 4 :

Communication: to be used for the communication layer in order to route the message; Performative: to be used by the negotiation and revision controllers in order to know what kind of action the message is intended to achieve; Content: to be used by the base management system.

While building the protocol, some formal properties are required and ensured. For instance, under the following assumptions: -there is always, in a finite amount of time, an answer to a query (to an individual base), -there is not an infinite number of alternate-proposal for a proposal, and, -different proposals are independent, each submission reaches the accepted or rejected status in a finite amount of time and this status is such that a submission is accepted if and only if it agrees each subscriber. The two first assumptions are part of the fairness assumption of Co 4 while the latter requires taking into account the interaction between proposals.

Difficulties with the cooperation protocol come from the fact that it must be closely suited to the needs of cooperative knowledge base building. Otherwise, subscribers would work around it. The ideal protocol should be mechanically interpretable (at least at the performative level) and rich enough for covering adequately all of the needs. The first requirement has been successfully achieved through the construction of an automatic group base protocol [START_REF] Euzenat | Building consensual knowledge bases: protocol[END_REF]. However, our present protocol is very simple (only 33 rules) and must be enhanced through experience and some assumptions may have to be relaxed. For instance, it does not take into account the demand from a reviewer to clarify some point (this is planned but informal communication is not very well taken into account by KQML).

5.DISCUSSION AND RELATED

WORKS

So far, the Co 4 system has been presented as an extension of existing systems and references to similar systems have been avoided. In this section, Co 4 is first placed in the many taxonomies of collaborative systems. Then the system is compared with the many current works on knowledge sharing. Co 4 is particular in several concerns for knowledge sharing and collaborative work, thus the third part is dedicated to the explaination of the principles governing Co 4 and of why they make it close to some systems.

. 1 . What is Co 4 ?

Co 4 can find its place among the many taxonomies of CSCW systems. With regard to [START_REF] Reinhard | CSCW tools: concepts and architecture[END_REF] it has asynchronous indirect interaction, system based coordination, data hiding and is collaborative aware and technically non flexible. While cooperative, Co 4 dictates the way the cooperation is achieved. This takes into account the usual context in which research is carried out (as opposed to "is a general purpose support for cooperative work") in order to deal with usual attitudes as advocated by [START_REF] Kling | Cooperation, coordination and control in computer supported cooperative work[END_REF].

Co 4 allows the coordination of people for publishing results they consider as achieved. So, as presented in [START_REF] Kraut | Relationship and tasks in scientific research collaboration[END_REF], it is only tailored for the execution stage and enables information sharing and activity coordination. As such, it does not aim at supporting the organisation of collaboration on a precise topic by planning experiments and analysis. Extending Co 4 is possible, but would require a very different interaction protocol such as the contract net protocol [START_REF] Smith | The contract net protocol: high level communication and control in a distributed problem solver[END_REF].

According to Ellis [START_REF] Ellis | Groupware -some issues and experiences[END_REF], Co 4 would not be a groupware system stricto sensu, but could be classified under coordinated multi-user editor. By opposition to Gibb's definition of groupware, people do not really share a common environment since they work on their own knowledge base. But they share the goal and the content of the consensual knowledge base.

Co 4 shares many features with the coordinator [START_REF] Winograd | A language/action perspective on the design of cooperative work[END_REF]. The coordinator is a system which allows people to submit requests and offers to others who can answer by declining, accepting or proposing an alternative. The system is able to store these proposals and to manage the state of each proposal. The main differences lie in the goal of building a consensual knowledge base (common to each individual), the formal treatment that Co 4 can apply to knowledge and the hierarchical construction of knowledge bases (and hence of the communication) instead of peer-to-peer communication.

. 2 . Co 4 and knowledge sharing

The knowledge sharing idea has been promoted as a way to avoid constructing multiple knowledge bases and multiple reasoning systems about the same domain. It defends, instead, the idea of sharing this achievement by either merging the knowledge of several bases into one (knowledge sharing approach [START_REF] Neches | Enabling Technology for Knowledge Sharing[END_REF]) or submitting the problems to several accessible knowledge based systems (software agent approach [START_REF] Genesereth | Steven Ketchpel[END_REF]).

There are some hints that knowledge sharing cannot be achieved without sharing the building of the knowledge base itself. Knowledge sharing requires not only the intelligibility of the knowledge description language semantics, but also the agreement on the meaning of concepts of the domain. A project for sharing the construction of a knowledge base has already been described in [START_REF] Rechenmann | Building and sharing large knowledge bases in molecular genetics[END_REF]: it aims at helping scientists to build a consensual knowledge base about their scientific research domain. In this context, shared with the knowledge medium idea [START_REF] Stefik | The next knowledge medium[END_REF], producing and maintaining the knowledge base constitutes an end in itself. Such a framework can also be used for huge scientific projects, distant collaborative works or knowledge elicitation in order, for instance, to achieve a corporate memory.

The Co 4 approach differs from the software agent approach because it considers a general architecture and the homogeneity of agents and from the knowledge sharing approach because it assumes that knowledge cannot be shared unless the elaboration process has been shared. The fact that all agents share a common goal represented by their common knowledge base is another unusual characteristics. This led to the design of a very specific interaction protocol and the enforcement of consistency in Co 4 .

However, the Co 4 principle is similar to that of the SHADE project [START_REF] Gruber | Toward a knowledge medium for collaborative product development[END_REF] which has one foot in each world. The SHADE project builds a knowledge medium which aims at supporting the collaborative design of an artefact; in Co 4 the artefact is the knowledge base. Such a system must enforce both the consistency and the agreement of everyone (human or software agent) involved into the design process. However, there are several technical differences between both systems:

• The SHADE project uses pre-existing knowledge bases (in the knowledge sharing fashion). It thus puts less emphasis on knowledge base revision than Co 4 . • In SHADE, agents can be very different while in Co 4 all agents are equal (peers) and play different roles (submitter, reviewer, etc.) depending on the situation. The variety of agents constrains to take into account a variety of behaviours (which changes to notify, etc.) and requires tools for expressing how to deal with them (publication of interest) which have not been considered here.

The agents (bases) of Co4 are very structured since they already share their goal (establishing of knowledge base) and a mode of organisation (subscription tree). The society as a whole has to process a contract (building a consensual base by submission) by opposition to establishing a plan for achieving the goal. It does not have resource allocation and coordination problems: the only problem is communication. This multi-agent architecture is like the federated systems of [START_REF] Genesereth | Steven Ketchpel[END_REF], in which agents communicate indirectly through facilitators. Here, each agent is connected to the other through its communication software which is a very specialised facilitator: only groups accept subscription and the communication is enabled only from one group to its subscribers and from the subscribers to the group. The group bases constitute the mediators between the actual users. Their routing level is like both a KQML router and a very simple KQML facilitator; as a consequence, each base has the same router and facilitator components (at the moment they have two: one for sending messages to the group base and one to send messages to its component bases). This is a divergence from the KQML facilitators which are considered as knowledge bases themselves able to dialogue with any other knowledge base.

In the scientific community metaphor [START_REF] Kornfeld | The scientific community metaphor[END_REF], close to the software agent approach, the emphasis was on solving problems rather than sharing knowledge. So the aspects of the building process of a corpus of knowledge have not been considered. However, the basic properties of the system (commutativity, monotonicity, pluralism and parallelism) hold true for Co 4 .

. 3 . The Co 4 principles

Co 4 is here presented in terms of a set of principles which provide the background of the system. These principles allow us to stress the differences between Co 4 and other efforts concerning knowledge sharing or collaborative processes.

. 3 . 1 . Uniformity

Co 4 is made up of a set of knowledge bases. Any cooperator is viewed by the system as a knowledge base. For simplicity, all the bases are equipped with the same software. Something interesting with regard to other cooperation schemes (and mainly the one used in the software agent trend) is that the knowledge bases have the same description language (this is to be contrasted with other approaches, in which agents are seen as knowledge bases but their languages can be heterogeneous). This simplifies the implementation and use of the system by allowing to stress the collaborative aspects, but, above all, this ensures that people are talking about the same representation formula instead of a translated item. Of course, each base cannot have its own representation system. However, the use of a language independent from the knowledge representation language (KQML), preserves the possibility to use heterogeneous representation languages (but communication between bases expressed in different languages is, to our knowledge, far from achieved). One can easily imagine a particular agent able to translate the content of some sequence data bank into TROPES and able to submit it to Co 4 .

. 3 . 2 . Consistency

The knowledge stored in group knowledge bases must be correct, consistent and consensual. This is in great contrast with what is currently developed over the networks: databases available through WAIS, Gopher or WWW do not have to be consensual nor consistent. The data is provided as such, without any warranty of consistency from the provider, and the retrievers have to make it consistent before introducing it into their own databases. Other frameworks are also different in this respect: neither the knowledge sharing (when the opportunity to modify the shared knowledge is considered) nor the software agents provide any warranty about the consistency of the knowledge they provide.

Moreover, the consistency is not only syntactic. The collaborative knowledge base building ensures that the collaborators agree on all of the details of the base and it is expected that they also agree on the meanings they assign to the terms. At the opposite, the knowledge sharing view allows the sharing of "ontologies" and mechanisms without caring that the meaning of the components are agreed (see also [START_REF] Karp | Representing, analyzing and synthesizing biochemical pathways[END_REF] about ambiguous names).

. 3 . 3 . Good will and fair use

Of course, a system such as Co 4 is not suited for just any purpose. It is designed for a community whose common interests lie in the results obtained by the community. In fact, Co 4 is firstly dedicated to the members of large groups of people sequencing genomes in different laboratories for which the better the results of the community, the better those of the subscribers. Thus Co 4 does assume from its users, their good will (they will submit their discovery and opposition to proposals) and a fair use (they will not delay some publication by not reviewing it, they will not consume more resources than necessary or submit proposals they know to be false). So, there is no place for financial refunding, quotas, deadlines or control on the queries emitted: it is assumed that the use of Co 4 will be fair enough (no systematic submission of unverified material, etc.).

However, this does not mean that there is no conflict: the conflicts are to be treated by negotiation upon a protocol a bit stronger than those used in scientific journals because it is more formal and it aims at reaching consensus. Co 4 includes an authentication of who proposed a modification and who issued an alternate proposal in such a way that the discoveries can be acknowledged. There is also the obligation of citing the sources in the hypertext annotations; this should be facilitated by the availability of a citation editor in Co 4 .

Co 4 could be enhanced first by deadlines (for returning answers, etc. [START_REF] Winograd | A language/action perspective on the design of cooperative work[END_REF]) and second by punishments for those reviewers who take a very long time for reviewing (for instance, suspension of their submissions). There also could be, for reviewing, an anonymity management system which provides both independence and recognition [START_REF] Stodolsky | Consensus journals: invitational journals based upon peer consensus[END_REF].

Assuming good will and fair use from the agents of a distributed system is not unusual but not always explicitly stated.

. 3 . 4 . The paper submission metaphor

Any system allowing the building of some artefact must have a particular change policy. The Co 4 protocol mimics that of scientific journals. To our knowledge, the scientific journal protocol has never been used for that purpose. The choice of such a protocol is not neutral: first it is well known within the community and, in the consensual version, it enforces the dialogue between people (rather than a simple majority or intersection protocol). The requirements of consistency and formality allow for more strictness concerning what is published and thus leads to a consensual rather than a review protocol.

6.CONCLUSION

An architecture able to support the proposal of [START_REF] Rechenmann | Building and sharing large knowledge bases in molecular genetics[END_REF] has been presented. This proposal is original in two respects: it allows for the sharing of knowledge instead of non formalised data and it emphasises the consistency and the global coherency of shared knowledge. In summary, it is a formalised peer-reviewed scientific journal rather than a dazibao. For achieving this, we propose a knowledge base system able to deal with formalised and non formalised knowledge, consistent, because the formalised knowledge constitutes a consistent corpus, consensual, because whatever is deposited in the base is agreed by everyone, whose aim is the sharing of the knowledge base elaboration process.

Co 4 has some limitations since the communication protocol is very restrictive (however, the same protocol does not prevent people from submitting to, reviewing for and reading scientific journals). However, it will have to be enhanced. The protocol itself is unable to account gracefully for the concurrent submission of mutually contradictory proposals. These major weaknesses are under consideration and will have to go through experimentation.

The framework presented here is not restricted to genome research but can be applied to other research fields, and to other activities such as the constitution of a corporate memory. Co 4 is based on deep experience with individual workstation design and use. A complete prototypical knowledge base management system has been designed and implemented along these ideas. It has been used, in various stages of achievement, for the development of ColiGene and MultiMap, and is now being used for the implementation of a complete cooperative computer system for genome sequence analysis. The collaborative part is in its beginning: a prototype system is currently developed in our team using the knowledge base management system TROPES and KQML as a communication support.

Figure 2 :

 2 Figure 2: The three-layered software architecture. Each box represents a software module, each circled unit is a data/knowledge repository and each arrow represents the call of a program functionality.

Figure 4 :

 4 Figure 4: The hierarchical architecture and message flow. The knowledge bases are organised in a tree whose leaves are individual knowledge bases and nodes represent the consensual knowledge of connected individuals.The downward types of messages include the submission of a proposal and the reports of approval, rejection or alternate 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.

Figure 5 :

 5 Figure 5: The automaton corresponding to the submission of proposal P at the scale of the whole system of group base plus subscribers. It reproduces four states of publication submission: initial state (Q), submitted (S), under review (R), accepted (A).

ACKNOWLEDGEMENTS

This research is being supported by GREG (Groupement de Recherches et d'Études sur les Génomes) and by GdR CNRS «Informatique et Génomes» (CNRS: Centre National de la Recherche Scientifique). The author thanks Steve Jones, François Rechenmann and Jutta Willamowski for their help.


Jérôme Euzenat
email: jerome.euzenat@imag.fr

KR and OOL co-operation based on semantics non reducibility

We argue that, due to semantics non reducibility, object based-knowledge representation systems (OBKR) and object-oriented programming languages (OOL) cannot be reduced one to another. However, being aware of this incompatibility allows to organise their cohabitation and co-operation accordingly. This is illustrated through the design of a new implementation of the TROPES system.

1.WHY ARE OOL AND OBKR DIFFERENT?

There have been several works on the many possible OOL and OBKR based on the remark that OOL and OBKR are very similar at a conceptual level [START_REF] Nebel | How well a vanilla loop fit into a frame?[END_REF][START_REF] Kaindl | Object-oriented approach in software engineering and artificial intelligence[END_REF][START_REF] Karp | The design space of frame knowledge representation systems[END_REF][START_REF] Wegner | Dimensions of object-based language design[END_REF][START_REF] Calvanese | A unified framework for classbased representation formalisms[END_REF]. As a matter of fact, involved concepts include individual entities (hereby called objects), to which attributes are assigned, and generic entities (called classes) describing the structure of individual objects and organised through a relation (called specialisation). A possible source of difference, at the conceptual level, is the ability of OOL objects to do (send messages) while OBKR object only are (accessed). However, the distinction is balanced by the possibility of having access-oriented programming in OBKR, that which is computationally equivalent to message passing.

On one hand, comparing OBKR and OOL on this conceptual level, as a whole or component by component, is possible but misses the meaning of the involved concepts [START_REF] Nebel | How well a vanilla loop fit into a frame?[END_REF][START_REF] Patel-Schneider | What's inheritance got to do with knowledge representation[END_REF]. Therefore each tentative characterisation of OOL with regard to OBKR is contradicted by some non typical system. On the other hand, in the last ten years, there has been fundamental work concerning the semantics attached to the notions of objects, classes, specialisation and so on [START_REF] Brachman | What is-a is and isn't: an analysis of taxonomic link in semantic networks[END_REF][START_REF] Black | Foundations of object-oriented languages[END_REF]. There are roughly three ways for establishing the semantics of object-based systems:

• designing an operational semantics which models the behaviour of the system without referring to the modelled domain [START_REF] Reddy | Objects as closures: abstract semantics of object-oriented programming[END_REF]; • designing a denotational semantics given by an interpretation function ranging from the object concepts to the represented domain (it can be a one-to-one correspondence in firstorder interpretations [START_REF] Levesque | Expressiveness and tractability in knowledge representation and reasoning[END_REF][START_REF] Nebel | Reasoning and revision in hybrid representation systems[END_REF] or an approximation through OSF-morphisms [START_REF] Aït-Kaci | Towards a meaning of LIFE[END_REF]). The domain can be characterised in two ways:

-an essentially mathematical domain (e.g. function spaces [START_REF] Cardelli | Operations on records[END_REF]); -a domain which could be the reality (with nothing more than set theory; e.g. [START_REF] Nebel | Reasoning and revision in hybrid representation systems[END_REF]); such a semantics will be called simple denotational semantics. The difference lays in the immediate intelligibility of the semantics by a user: what is modelled by an object is usually not a function, in consequence there is no reason why the meaning of objects should be a function. The two first trends are mainly those used in modelling OOL -the second one being more popular in theoretical computer science -while the third one clearly concerns knowledge representation. Of course, this distinction is not that clear: some works, close to OOL, rely on a simple denotational semantics (e.g. feature algebra [START_REF] Smolka | Feature constraint logics for unification grammars[END_REF]). However, the distinction seems pretty solid: it is admitted in the OBKR field that the foundation of knowledge representation is its relationship with reality (or rather a domain to be modelled) [START_REF] Nebel | Reasoning and revision in hybrid representation systems[END_REF], while researchers in OOL are looking for a computational model of object systems [START_REF] Touretzky | The mathematics of inheritance systems[END_REF].

As far as the difference is made on denotational versus operational semantics, the gap is not that large. They are not contradictory, just two different ways to see the same phenomenon. But some characteristics of OOL raise problems which render difficult the task to assign them a simple denotational semantics. As a matter of fact, the emphasis put on the extendibility of OOL led to the definition of as few concepts as possible in order to enable anyone to modify the system behaviour as a whole. This has the expected advantages. However, this has two important consequences for the semantics:

• It becomes very difficult to draw the boundary between the objects which belong to the modelled domain (denoting some particular individual) and those which are part of the computational machinery of the system (this is obvious when queues, windows, programs and messages are themselves objects [START_REF] Goldberg | Smalltalk-80 the langage and its implementation[END_REF]). • The meaning of a class as denoting, unambiguously and in itself, something (usually a set of individuals) in the modelled domain cannot be established very clearly, since the behaviour of that class is dictated by numerous changes made in the meta-class, the inheritance protocol and so on. Moreover, in many systems (e.g. [START_REF] Kiczales | The art of the meta-object protocol[END_REF]) this protocol is programmed in another language which must have a denotational semantics so that the OOL can have one. Of course, these problems culminate in reflective (or self-described) systems in which wellfounded sets cannot be used for defining the denotation of classes1 . The distinction drawn above is not an arbitrary distinction between these systems: it is the core of our argumentation. In order to implement its denotational semantics, a KR system has to behave accordingly with the represented domain. If anyone can legitimately modify the behaviour of the system, this is not ensured anymore. The next step of this dialectical argument consists in noting that the modelled domain itself is capable of self-representation (and self-modification), but we have been too far… Note that nothing prevents from implementing OBKR in an OOL by implementing the appropriate semantics, however, the simple denotational semantics of the OBKR cannot be straightforwardly deduced from the operational semantics of OOL.

2.WHY BRINGING THEM TOGETHER?

The conceptual similarity is a bad reason to try to unify OBKR and OOL: it is only surface similarity without semantic grounding. Of course, there are «real similarities» which are learned directly with such a unification, but it brings too much confusion. Meanwhile, there are good reasons to put them together:

• Object-oriented programming (OOP) is so widely used that it is not possible to imagine a useful KR system unable to communicate with some OOL. • OBKR, for their part, are a good way of representing knowledge, that which is not a strength of OOL. Thus, if an application requires knowledge representation, OBKR is a good solution. • OOP is a powerful way of developing systems: programming an OBKR in an OOL brings portability, extendibility and integrability. In summary, OOL and OBKR are condemned to cohabitate in real applications. These are tiny but promising arguments for putting OOL and OBKR together. They certainly justify numerous attempts to (generally) embed or implement OBKR on top of OOL by taking advantage of their extendibility [START_REF] Rathke | Object-oriented programming and frame-based knowledge representation[END_REF].

There is usually, in OOL applications, some part which could be considered as representing knowledge while the other is dedicated to the functioning of the system. Our purpose is to render this distinction more explicit rather than to hide it. To that extent, we start from an analysis of the different functions of classes in OBKR and show that some can be devoted to OOL classes while other concern OBKR classes. This does not provide integration of denotational and operational semantics of such systems, but bounds the domain of each of them in such a way that they are integrated but cannot interfere. The presentation is based on the OBKR TROPES [START_REF] Mariño | Multiple perspectives and classification mechanism in object-oriented representation[END_REF][START_REF] Euzenat | A purely taxonomic and descriptive meaning for classes[END_REF] which introduces a conceptual difference between concepts and classes.

3.TAXONOMY VERSUS ONTOLOGY

In classical OBKR, the membership of an object to a class has important consequences. Meanwhile some of them are necessary while others are contingent (exemplified by the fact that an object can change its class). The meaning of classes is too often overloaded and this raises at least two important problems:

• It merges the ontological aspects of instances (i.e. the conditions of their being: structure, integrity, identity) and the taxonomic aspects (i.e. the conditions for seeing them as a member of a class: domain restriction, relevant fields). Merging both views together raises problems of integrity: does some object change class (breaking the integrity of the object) or is it replaced by another object with similar characteristics but belonging to another class (giving up identity of objects)? [START_REF] Carré | On multiple classification, points of view and object evolution[END_REF] Classes cannot play their role of categories in an identification system without breaking the ontological link with the objects. • There exist several different ways of classifying objects (for instance, employees in your firm are not categorised the same way by yourself or by your account agent). It is thus important to be able to consider different concurrent taxonomies of classes organising the same set of objects. TROPES distinguishes ontological and taxonomic aspects of classes and assigns the semantics of each aspect to distinct entities with correspondent prerogatives: concepts and classes.

3.1.Concepts

Ontological prerogatives are attached to the concept. They are those which warrant the integrity of an object (i.e. that it cannot be modified in a way which would lead it to cease being an instance of the concept). This also includes the management of object identity. In TROPES, objects are identified by the mean of a key: a list of field values that corresponds to only one object. The usual consequences with keys are related to integrity: an object without a key cannot exist and there cannot exist two objects with the same key (thus accidental co-reference is avoided).

These prerogatives play an important role at instanciation when the object is created and registered. They have in charge the management of existential dependencies from objects to the components without which they cannot exist. During its lifetime, an object, belonging to some concept, is ensured that none of the above postulates is violated.

3.2.Classes

As soon as the classification is seen as contingent, there can be several different classifications of the instances of the same concept: in a particular firm, the individuals are not considered the same way by the project management staff, the account office and the restaurant. Therefore the same individual is seen differently under several viewpoints and each viewpoint can have its classification of the same set of individuals.

Under a particular viewpoint, an object is attached a class and can change class as soon as it has been further identified. This organisation is very useful since one can classify an object with regard only to the relevant fields for the viewpoint. As a consequence, the set of classes to be considered is small, while considering the whole lattice of possible structures (e.g. Vegetarian-Profit-sharing-Clerk) would confuse the user.

A class is (1) a projection of the structure of the concept retaining only relevant fields and, (2) a definition of constraints that objects must satisfy in order to belong to it. It thus provide the support for classification. As opposed to instanciation, objects can be attached to a class and can be detached from it at anytime. Classes also allow the expression of hypothetical knowledge in term of default values or default inference methods. The hypothetical knowledge is relevant here since, for instance, default values are given with regard to the specificity of the object class. These values are not to be seen as the true values of fields but as hypotheses which can be made under a particular viewpoint. As a matter of fact, default values returned from different viewpoints do not have to be identical. For instance, it could be the case that research directors are usually fat while vegetarian are usually thin: what about a vegetarian director?

4.TIGHT CO-OPERATION BETWEEN OBKR AND OOL

It is noteworthy that TROPES characteristics are a combination of those of OOL and OBKR. In fact, OOL classes have concept prerogatives (e.g. instanciation, integrity, weak typing) with instances which cannot change their class and OBKR classes have class prerogatives (e.g. default inference, strong typing) with instances which can migrate. The only missing aspects of OOL is message-passing. This distinction between concepts and classes led to the new implementation of TROPES in the context of a CLOS-like OOL (named ICOS -thus leading to the TROPICOS implementation of TROPES). In TROPICOS, the integration is such that any TROPES object can be considered as an ICOS object and any ICOS objet could be a TROPES… value. This avoids the rupture between OOL and OBKR objects. On one hand, OOL operations (e.g. integrity enforcement but also displaying, storing) can be applied to these objects without altering their representational aspects (e.g. slot values, class membership). On the other hand, pure OOL objects can freely be referred to by OBKR objects but are not interpreted as representation of an individual in the modelled domain.

4.1.Implementing TROPES in an OOL

As a matter of fact, concepts are implemented like particular instanciable, non-mutable ICOS classes. They provide to their instances (hereby TROPES objects) the services of indexing, integrity checking (no other object can have the same key and they always have the same structure). On the other side, several viewpoints (maybe none) are attached to these concepts with a taxonomy of classes in each viewpoint. Thus, TROPES objects can be seen from several viewpoints and classified in different classes in different viewpoints. They can be reclassified at any time and their aspect (visible fields) can change from one viewpoint to another.

As a consequence of this implementation, any TROPES object is an OOL object. It behave exactly in the same way. Of course, what cannot change is the behaviour of the object from the TROPES point of view. Thus, the implementation of this object (in OOL terms) must respect TROPES semantics. However, this semantics does not extend to the whole OOL action field but only a restricted area. For instance, displaying is not taken into account by TROPES it can thus be provided by the OOL. It is expected that both sides of the object do not interact so that both semantics are preserved.

4.2.Introducing OOL objects in TROPES

So far, only TROPES objects have been fully integrated into an OOL. The converse does not hold because for OOL object to be integrated into an OBKR, they should loose their flexibility by being assigned a strict denotational semantics. However, there is a need for a continuum between OOL objects and OBKR objects which is provided by enabling the OBKR to reference OOL objects in a minimal fashion. OOL objects are thus enabled to transit into TROPES objects (i.e. being in field values, being identified as belonging to a type) but they are not considered as TROPES objects but rather as values such as strings, boolean and so on.

For that purpose, TROPES types are declared through an abstract data type which provides a predicate for values of the type, an equality predicate and sometimes an order predicate allowing to express sub-types as enumerated domains or interval union. For instance, the date data type is provided with date-p predicate for testing if the given value is a date, a date-equal-p predicate for testing if two dates are equal and a date-anterior-p predicate. These data type are also provided with reader and writer functions. Thus, TROPES does not consider these objects as OOL objects (as a mater of fact they can be implemented as strings) but does not prohibit it. TROPES warrant that what should be a date is indeed a date and when the slot value is retrieved from a TROPES object field it can be sent the appropriate messages.

5.CONCLUSION

In summary, it has been argued that no merge is possible between OOL and OBKR but that strong pragmatic reasons appeal for co-operation. The TROPES OBKR has been briefly presented. It proposes a distinction between class and concept roles. Then, an implementation preserving differences while clarifying and strengthening links has been presented. ROME [START_REF] Carré | On multiple classification, points of view and object evolution[END_REF] has been the first system to explicitly separate ontology from taxonomy. It makes an object instance of an "instanciation class" borrowed from OOL and let it be classified under a "representational class" related to OBKR. But, it does not separate the base into different viewpoints: there is only one taxonomy. FRAMETALK [START_REF] Rathke | Object-oriented programming and frame-based knowledge representation[END_REF] proposes an implementation of frame concepts in CLOS which provides perspectives (similar to our viewpoints) [START_REF] Rathke | Multiple representation perspectives for supporting explanation in context[END_REF]. Classes are just extended OOL classes and no particular semantics is provided for the system. KRS is concerned with integration of external data types in the representation systems [START_REF] Gaines | A class library implementation of a principled open architecture knowledge representation server with plug-in data types[END_REF]. External data are integrated through abstract data types. No distinction between OOL and KR classes is considered and no semantics is provided. Recently, it has been argued that some sort of terminological logic is more general than frames and "object-oriented data models" [START_REF] Calvanese | A unified framework for classbased representation formalisms[END_REF]. However, it only concerns a restricted class of object models and features has not been taken into account (e.g. reflectivity).

The presented position takes into account the current state of object semantics in OOL and OBKR. Without neglecting the efforts towards the convergence of both semantics, it represents an already practicable way of integrating both kind of systems without weakening their respective position. The main drawback of our proposal lays in the fact that an OOL implementation of OBKR is dangerous due to the flexibility of OOP.

Figure .

 . Figure. The implementation of the OBKR Tropes in an object-oriented language.

While OBKR only have problems with the semantics of a concept which refers to itself[START_REF] Nebel | How well a vanilla loop fit into a frame?[END_REF][START_REF] Carré | On multiple classification, points of view and object evolution[END_REF], OOL have problems with classes which are instances of themselves.

ACKNOWLEDGEMENTS

Many thanks to Roland Ducournau for carefully reading and arguing (not that much) against my proposal. This research is partly supported by the French Groupement d'Études et Recherches sur les Génomes.