The agent library supports the creation, maintenance, and use of databases, in the form of data solvables. Creation of a data solvable requires only that it be declared, as explained in Section 5.2.1. Querying a data solvable, as with access to any solvable, is done using oaa_Solve. Here, we clarify the ways in which these solvables are maintained and used, and mention some of the features associated with them.
A data solvable is conceptually the same as a relation in a relational database. The facts associated with each solvable are maintained by the agent library, which also handles incoming messages containing queries of data solvables. It is possible to refine the default behavior of the library in managing these facts, using parameters specified with the solvable's declaration. For example, the parameter single_value is used to indicate that the solvable should only contain a single fact at any given point in time. The parameter unique_values indicates that no duplicate values should be stored.
Other parameters can allow data solvables to make use of the concepts of ownership and persistence. Because data solvables are often used to implement shared repositories, it can be useful to maintain a record of which agent created each fact of a solvable; this agent is considered to be the fact's owner. In many applications, it is useful to have an agent's facts removed when that agent goes offline (that is, the agent is no longer participating in the agent community, whether by deliberate termination or by malfunction). When a data solvable is declared to be nonpersistent, its facts are automatically maintained in this way, whereas a persistent data solvable retains its facts until they are explicitly removed.
The agent library provides procedures by which agents can update (add, remove, and replace) facts belonging to data solvables, either locally or on other agents, given that they have the required permissions. These procedures may be refined using many of the same parameters that apply to service requests. For example, the address parameter is used to specify one or more particular agents to which the update request applies. In its absence, just as with service requests, the update request goes to all agents providing the relevant data solvable. This default behavior can be used to maintain coordinated ``mirror'' copies of a data set within multiple agents, and can be useful in support of distributed, collaborative activities.
Similarly, the feedback parameters, described in connection with oaa_Solve, are also available for use with data maintenance requests.
The ability to provide data solvables is not limited to client agents; data solvables can also be maintained by a facilitator, at the request of a client of the facilitator, and their maintenance and use shared by all the facilitator's clients. This can be a useful strategy with a relatively stable collection of agents, where the facilitator's workload is predictable.