OpenKnowledge peers must have at least one OKC in order to play a role but may have arbitrarily many. Each OKC is a set of methods, and these methods provide information on how constraints should be satisfied. It may be the case that an OKC is designed for a particular role, so that methods to satisfy all the constraints for that role are contained within the OKC. This is useful because it means that this OKC can be shared across the network and any peer that downloads it has the necessary methods for performing that role. However, when playing a particular role, a peer may use methods from many different OKCs. For example, a peer may have a util.okc in which it keeps many common methods that are used to solve constraints that reappear in a large number of roles. This prevents the peer from having to keep many copies of the same method; however, it is not forbidden for the peer to have more than one copy of the same method: it may download an OKC for a particular role that contained methods it already had and it would not be obliged to remove all of these duplicates.

Although the sharing of OKCs is central to the concept of OpenKnowledge, there will be many situations in which peers wish to use their own trusted OKCs rather than ones developed by unknown others because this allows them more control over their actions. This can lead to the situation where peers need to play a role using an OKC that only imperfectly matches that role: this situation is dealt with through mapping constraints to methods.

Peers are more than the sum of their OKCs. At the very least, peers subscribe to interactions and interact with their users, whereas the OKCs they contain merely provide methods for solving constraints. But, crucially, we would expect most peers to have their own knowledge that will be used to assist in these methods, because most methods access the peer's internal state. Thus, different peers may download the same OKC and yet produce different results and outcome when performing the same role.

One of the central tenets of OpenKnowledge is that IMs and OKCs can be shared between peers on the network without any prior agreement about semantic standards. When a peer takes on a role, it performs it in its own manner: this may be through using an existing OKC for the role, through making a choice of many existing OKCs or for reusing its own OKC that is generally appropriate for the role. For example, a peer playing a buying role may have an OKC for buying but may be searching for IMs that already have selling peers attached. Thus they may end up taking part in an interaction that their OKC was not specifically designed for. This flexibility is crucial to the vision and feasibility of the OpenKnowlege project but it leads to the problem of semantic mismatch. Therefore, we have developed a matching component that can match the first-order constraints in an IM to the first-order methods within an OKC.

This matching process returns a value in [0 1] indicating how similar the constraint and the method are. This allows the peer to form its own notion of good enough and determine whether this match meets this standard. If the match between a method and a constraint is below a certain threshold (determined by the peer), it may decide that this method is not good enough to satisfy the constraint and either decide not to play that role or decide to search for an OKC that better matches the role.

For more details of this, see Good Enough Answers.

OpenKnowledge does not place any restrictions on or have any expectations of peers. Anything that is able to run the OpenKnowledge kernel and to solve constraints can act as OpenKnowledge peer. Therefore, we cannot either have any expectations of what ontologies these disparate peers will have and how they will be represented: peers are fully autonomous and must make their own choices.

However, there are many reasons why having a well-formed ontology will allow the peer to perform more successfully in interactions. Firstly, some of the machinery of OpenKnowledge - the matching service and the trust component - rely on peers having a taxonomy of terms. Both of these services will work without this - especially the matching service, where use can be made of facilities such as WordNet - but their success rate will be very low if the peers cannot provide any semantics. Additionally, peers may find it hard to satisfy constraints even if the matching process is successful if they do not have well ordered knowledge.

Therefore, we would recommend that peers have at least a basic taxonomy to represent their knowledge.

This page tells you how services can be used as peers.