3 Representation of knowledge in SDML

3.2 Databases

In SDML, a database is a collection of clauses. Each clause on a database represents something that is known to be true.*1 Clauses can be placed in databases explicitly by the modeller, or they can be deduced in the course of a simulation (by rules firing as described in Section 4).

Thus, clauses can be used to represent logical predicates, and each clause on a database represents a predicate that is definitely true. For convenience, let us say that such clauses are true. The absence of a clause from a database does not necessarily mean that it is false, but merely that it has not been deduced to be true. It should be noted that some clauses, such as those representing lists, do not correspond to logical predicates and should only be placed on databases as arguments of other clauses.

The keywords of clauses that can be used in a database are defined, along with the legal types of the arguments, in a clause definition group. Modellers use clause definitions to specify how specific kinds of knowledge are to be represented, as clauses on databases. Checks are performed automatically to ensure that clauses adhere to the syntax specified in their definitions.

As mentioned earlier, clauses can contain subclauses, and a large amount of information can be stored in a single clause on a database. In practice, most clause definitions restrict their arguments to numbers or symbols (or specific subtypes), and such cases are optimised for more efficient access.

There are three main operations that can be used to access databases:

Retrieve. This operation finds all the clauses in a database that match a particular clause, using unification. If there are any variables in either clause, then they are bound to corresponding terms in the other clause. A mapping from variables to the terms they are bound to is known as a bindings dictionary. Retrieval may yield zero, one or many solutions, with a different bindings dictionary for each solution. Retrieving a clause determines whether it is known to be true, and what values the variables must have for the clause to be true if it contains any.
Assert. This operation adds a clause to a database, unless it is already present. Asserting a clause notes that it is true.
Retract. This operation removes all clauses which unify with a particular clause from a database. Retracting a clause notes that it may not be true.

All three of the above operations can be performed by a modeller, using an appropriate tool, to check or modify knowledge on a database. However, clauses cannot be retracted during a simulation.*2 Every clause on a database represents the knowledge that something is true; if the simulation later deduces that it is false then the clause should not have been asserted in the first place. Logical inconsistencies would arise if asserting a clause caused further deductions to be made and the clause was later retracted.

In the real world, things that are true at one time (or date) can become false later. Instead of allowing such knowledge to be retracted, the period of time during which it is known to be true is noted. This is done using subdatabases, each of which contains clauses that are true at a particular time. Knowledge that is always true, or will remain true after a particular time, is represented on permanent databases. Every permanent database has a subdatabase corresponding to each time period of the simulation.*3 Clauses in a permanent database are inherited by its subdatabases, so that retrieving from a subdatabase determines whether a predicate is true at the appropriate time.

Retaining all the subdatabases generated during a simulation could waste a lot of memory, so a facility is provided to automatically dispose of old subdatabases that are no longer required. In order to ensure that this does not result in incorrect results, an error is reported if it is attempted to retrieve from a database that has been disposed of.

In common with the rest of SDML, databases were designed to provide modellers with a large amount of flexibility and a sound logical basis, without much loss of efficiency. Databases are represented in such a way that common operations, such as retrieving clauses with numbers and symbols as arguments, can be dealt with particularly efficiently. Internal representations can easily be changed, for example to interface with a relational database.

Efficient Forward Chaining for Declarative Rules in a Multi-Agent Modelling Language - 16 FEB 95

[Next] [Previous] [Up] [Top] [Contents]

Generated with CERN WebMaker