Hi Alex,
Does it make any sense to specify the :content of KQML messages in KIF and
to parse into jess facts/rules where reasoning ability is required. One
advantage of this would be access to a lot of ontologies that actually exist
in KIF - and would help in agent interoperability (and correctness at the
semantic/knowledge level).
- Lalit
----- Original Message -----
From: Alex George Bejan <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 15, 1999 1:04 PM
Subject: Re: Distributed JESS (was JESS: Modules ...)
> 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
> the more interesting work requires meaningful sequences of messages (or
> conversations, as they call them), which is the work that Scott Cost and
the
> other folks at U of Maryland did with Jackal. And lastly, KQML can be
> extended if one needs richer functionality.
> 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
> 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
> 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
> the KQML side we need to extend the interpreters so that the Jess-content
> messages are routed to the proper Jess engine, in the proper format. A
> correct, full implementation of KQML should not be too far from that last
> part. Sorry, these are very simple thoughts, aimed to maybe starting a
> discussion.
> 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
> proprietary (IBM or the CIIMPLEX group), and that ACL may not have a full
> implementation yet.
>
> Alex George Bejan
>
> ----- Original Message -----
> From: Ernest Friedman-Hill <[EMAIL PROTECTED]>
> ......
> >
> > A number of folks have mentioned on this list or in private email with
> > me that they have use Jess with one of the various KQML
> > implementations available in Java. It's apparently fairly easy to do.
> >
> .......
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
