A solvable has three parts: a goal, a list of permissions, and a list of parameters, which are declared using the format
solvable(Goal, Parameters, Permissions)
The goal of a solvable, which syntactically takes the form of an ICL structure, is a logical representation of the service provided by the solvable. (An ICL structure consists of a functor with 0 or more arguments. For example, in the structure a(b,c), `a' is the functor, and `b' and `c' the arguments.) As with a PROLOG structure, the goal's arguments may themselves be structures.
Various options can be included in the parameters list, to refine the semantics associated with the solvable. First and foremost, the type parameter is used to say whether the solvable is data or procedure. When the type is procedure, another parameter may be used to indicate the handler to be associated with the solvable. Some of the parameters appropriate for a data solvable are mentioned in Section 6.
In either case (procedure or data solvable), the private parameter may be used to restrict the use of a solvable to the declaring agent. This parameter is valuable when the agent intends the solvable to be solely for its internal use and wants to take advantage of OAA mechanisms in accessing it, or when the agent wants the solvable to be available to outside agents only at selected times. In support of the latter case, it is possible for the agent to change the status of a solvable from private to nonprivate at any time.
The permissions of a solvable provide the means by which an agent may control access to its services. They allow the agent to restrict calling and writing of a solvable to itself and/or other selected agents. (Calling means requesting the service encapsulated by a solvable, whereas writing means modifying the collection of facts associated with a data solvable. ) The default is for every solvable to be callable by anyone, and for data solvables to be writable by anyone. A solvable's permissions can be changed at any time, by the agent providing the solvable.
For example, the solvables of a simple email agent might include
solvable(send_message(email, +ToPerson, +Params), [type(procedure), callback(send_mail)], ) solvable(last_message(email, -MessageId), [type(data), single_value(true)], [write(true)]), solvable(get_message(email, +MessageId, -Msg), [type(procedure), callback(get_mail)], )
The symbols `+' and `-', indicating input and output arguments, are at present used only for purposes of documentation. Most parameters and permissions have default values, and specifications of default values may be omitted from the parameters and permissions lists.
A programmer who defines an agent's capabilities in terms of solvable declarations is, in a sense, creating the vocabulary with which other agents will communicate with the new agent. The problem of ensuring that agents will speak the same language and share a common, unambiguous semantics of the vocabulary, is called the ontology problem. The OAA provides a few tools (see more about agent development tools in [[Martin et al. 1996]]) and services (automatic translations of solvables by the facilitator) to help minimize this issue; however, the OAA still must rely on vocabulary from either formally engineered ontologies for specific domains (for instance, see http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html/) or on ontologies constructed during the incremental development of a body of agents for several applications.
Although OAA imposes no hard restrictions (other than the basic syntax) on the form of solvable declarations, two common usage conventions illustrate some of the utility associated with solvables.
As an illustration of the above two points, ``Send mail to Bob about lunch'' will be translated into an ICL request send_message(email, `Bob Jones', [subject(lunch)]), whereas ``Remind Bob about lunch'' would leave the transport unspecified (send_message(KIND, `Bob Jones', [subject(lunch)])), enabling all available message transfer agents (e.g., fax, phone, mail, pager) to compete for the opportunity to carry out the request.