キキジキ
キキジキ

Reputation: 1453

SWI Prolog multiple knowledge bases

Im my application I have a number of agents, each with his own knowledge base.
My original idea was having multiple engine instances, but swi prolog allows at most one instance.
The other way is adding an additional term representing the agent id to each fact and rule, but it seems very cumbersome.

For example, instead of:

position(10, 20).
do(action(X)):-...

I would have to write everywhere:

position(agent0, 10, 20).
do(Agent, action(X)):-...

Because I will update one agent at a time, even saving and restoring everything each time may be ok, even if I don't know how to do that. Or using modules?
What would be a good way to separate the different knowledge bases?

Upvotes: 2

Views: 1201

Answers (1)

user206428
user206428

Reputation:

I think your suggestion of adding an atomic ID to your facts to identify the agent it corresponds to is a nice one, but agree this could be cumbersome to add to your code in retrospect.

Here are some other suggestions, roughly in order of my preference...

  1. Use the recorded database. With this, you can actually record facts with atomic keys, so presumably, you could use recorda/3 and like predicates to record facts for each agent separately with agent IDs, then use recorded/2,3 to retrieve them. Nearly precisely what you want.
  2. Use modules. Presumably you could simply create new module names for each agent, thus separating the facts for each, much like the way namespaces are used. For example, asserting agent0:position(10,20).
  3. Keep explicit track of the facts you assert for each agent using assert/2 which returns clause references. By keeping a list of references which identify all facts asserted for a particular agent, you can quickly retract them using erase/1. Be aware that using clause references with a combination of clause/3 to retrieve clauses via their reference together with retract/1 could potentially retract like-clauses belonging to other agents.
  4. Depending on how your program is structured, you could simply pass around a large data structure with all the facts for each agent in a list like: [agent0-[fact1(..), fact2(..), ...], agent1-[...], ...] and update this term as you go. Note that this isn't as efficient as using the database itself, as it would require a lot of linear scans for particular facts; hash-lookups can't be used.

Upvotes: 4

Related Questions