> It's easy to put all the Jess stuff in the CONTENT field and make the
> LANGUAGE field 'Jess', and with the right interpreter the Jess theory will
> be sent directly to the Jess engine. But this is just the beginning,
> because there are other elements of the KQML language that can be exploited
> for far more nuanced work. Let's not forget KQML was developed to work with
> knowledge bases, so there are some means there to handle the functionality
> you would expect from a distributed knowledge base (ASK-ONE, ASK-MANY,
> IN-RESPONSE-TO, INSERT-ONE, DELETE-ONE, SORRY, EVALUATE, etc). And again
> this is only the beginning, because it refers to singular messages, whereas
This is what I do with my (fledgeling) project. I have some java-side
functionality that waits for incoming mail, and asserts unordered-facts
that correspond to KQML syntax. Then I have a bunch of jess rules that
respond appropriately. It's actually pretty inefficient, because the
rules end up defining new rules. For example, the ask-one rule defines
two rules (that differ in salience), one that triggers on something
matching the content field as a pattern and sends off the matched rule as
a tell messsage, and one that automatically fires at low salience with a
sorry reply. Both rules undef each other, so only one will fire. But
what ends up happening is a lot of dynamic run time changes to the
rulebase (which is a bit of an efficency no-no). If anyone wants to see
the exact code, let me know.
> KQML can work over RMI, or with JavaBeans, or using iBus, to enumerate a
> few communication-layer possibilities. However, at the language level it's
I am using RMI, coupled with some RMI-aware objects and a generic
mailbox/post office message passing pattern. It was pretty
straightforward.
> important that Jess and KQML can be used together in meaningful ways. Some
> folks use KQML with KIF, which I believe was the originally intended
> marriage (by DARPA at least who sponsored both), but there is no reason for
> not having a modus operandi for KQML and Jess. On the Jess side we need a
The one thing that is worth considering here is that (theoretically) KIF
is the portable interchange format, so getting our JESS agents to speak
KIF in their communications rather than straight JESS type queries would
allow the agents to send queries to non-Jess entities (although who would
write an agent _not_ in Jess?)
> way of accessing and using remote facts (and rules) using KQML. Also we
> need to be able to synchronize with the KQML messages sent and received. On
Java thread facilities allow for some easy work here. My base agent model
is:
block on mailbox until newmail
dump all new messages into the jess engine
run the jess engine until it decides to stop
repeat.
The blocking is achieved by calling a wait() method on the mailbox object,
and the post office object's deliver method (which is invoked through
RMI) calls the other half of that method (I can't remember the name of the
method, is it signal()?) to get the blocking thread to return from the
wait.
> A comparison between FIPA's ACL and the Jackal KQML would show many
> similarities. At that point one may want to consider that Jackal is
Have the Jackal people published any source yet? The last time I looked
(about 4 months ago), they had a descriptive paper, but nothing to poke
at.
Eric Eslinger
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
