Hi Fred,
I am going to use Java irrespective of the inference engine. A collegue of
mine wrote a JNI wrapper around CLIPS some time back through which he can
register Java Objects and pass the commands as eval strings. Java methods
can also be called on the LHS of the pattern just like Jess. Works well with
(Name, Obj, Val) triplet representation. (Not the most convinient way, but
serves the purpose). The idea behind his implementation is to use CLIPS till
JESS achieves CLIPS efficiency levels(eagerly waiting for it to happen) and
then migrate to JESS with out to many changes. Cant blame him, his manager
wanted to see a big telecom application using JESS before going for it.
Luckily i have my options open.
-Satish.
PS: Are there any good papers on model based problem solving paradigms other
than MIT's Prof. Davis paper.
-----Original Message-----
From: Fred Freitas [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 06, 2001 1:28 PM
To: Satish boggavarapu; ejfried
Cc: jess-users
Subject: RE: JESS: Representation Paradigm
HI Satish
No doubt you must use Jess! Not only is it well supported and many of the
improvement decisions are voted (!) but also the popularity of Java and its
better OO implementation are relevant pros: packages for multi-agent
communication, networking, ontologies and many others are freely available
and the number is growing each day.
CLIPS advantages are efficiency and direct compatibility to Ontolingua,
where you can reuse directly a lot of ontologies.
Fred Freitas
----------------------------------------------------------
PhD. student - Artificial Intelligence & Internet
Universidade Federal de Santa Catarina - Brasil
Currently at University of Karlsruhe - Germany
-----Original Message-----
From: Satish boggavarapu [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 06, 2001 7:17 PM
To: 'Fred Freitas'; ejfried
Cc: jess-users
Subject: RE: JESS: Representation Paradigm
Hi,
I am working on a Network Fault Diagnosis System. Since it is going to be a
real time system performance is an important issue even though i cant ignore
expressiveness. As usal its a tradeoff mix and match and i have to find the
right mix. The network topology consists of a large number of (say
20000-30000) network elements with considerable number of attributes say
5-10.
Now coming to the representation issue. I have couple of choices as i
mentioned in my previous mail. Either represent it as (Name, obj, val)
triplets or as Objects (may not be java beans). I can use either CLIPS/COOL
or JESS. Before deciding on any one technology i want to have an idea of the
advantages and disadvantages on all sides.
Fred thanks for your views on the use of an object systems. The network
domain knowledge is more of a domain description than representing its
functionalities. And i am looking at an object based frame work on which i
can write rules for pattern matching. Some of the future work i am planning
to do involves hooking up a knowledge base editor and explanation
capability.
Ernest, the explanation you provided regarding slot modification in an
object system, is that a JESS specific statement? Or can that be applied in
general? Say for COOL aswell.
If i have java code (Normal java classes as opposed to beans) to represent
the taxonomy of Network, what are the problems i might face in creating
COOL/JESS objects out of them. Is it a good idea to store them in the
inference engine memory and keep the references in a manager object outside
and manipulate both from the inference engine and the java world?
Ernest, are there any plans of introducing sliding window timers and
counters to JESS which can be used on the LHS? Say i want to fire the rule
when certain patterns match certain number of times in a given time window.
I would appreciate if anyone can provide their insight in to these aspects.
Ernest and fred thanks again for your views.
-Satish.
-----Original Message-----
From: Fred Freitas [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 2:48 PM
To: ejfried; Satish boggavarapu
Cc: jess-users
Subject: RE: JESS: Representation Paradigm
Hi Satish,
For me,one important issue here is expressiveness. COOL (and now Jess
integrated with ontology editor Protege using JessTab package) provides
frame-based representation capabilities, what also brings some advantages:
. Multiple inheritance
. slots can be instances of other classes
. easy declarative knowledge reuse (there are lots of "off-the-shelf"
ontologies)
. concepts can be translated to other knowledge representation formalisms
. slots are usually more legible and trackable than methods (due to
information hiding)
* When i modify an attribute slot in Object representation, does it retract
> all the attribute slots in that object and assert them again? Or just that
> particular slot? (Sounds dumb?) :)
This is a quite important question. I heard in a conference that any change
in an object will fire the evaluation of ALL of its methods calls in any
rule LHS. If this holds true, this is one advantage for declarative
representations, which will only evaluate the LHSs referring to the
particular slot.
In my view, this choice must focus on what's important to your system -
expressiveness or efficiency -, what must be represented - a domain
description or its functionalities - and what is to be reused - frame-based
ontologies or objects and beans.
Fred Freitas
----------------------------------------------------------
PhD. student - Artificial Intelligence & Internet
Universidade Federal de Santa Catarina - Brasil
Currently at University of Karlsruhe - Germany
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of [EMAIL PROTECTED]
Sent: Thursday, April 05, 2001 7:33 PM
To: Satish boggavarapu
Cc: [EMAIL PROTECTED]
Subject: Re: JESS: Representation Paradigm
JavaBeans will have a little more performance overhead than plain
facts, but not too terribly much. There is no per-match storage
overhead. There is really no performance-related reason to avoid using
Beans.
If you modify a JavaBean property, a PropertyChangeEvent should be
sent to Jess. Jess then responds to this event precisely as if a
(modify) command were being executed on an ordinary fact: it retracts
the "shadow fact" that represents that Bean, modifies the slot, then
reasserts the shadow fact. If you call (modify) on a shadow fact
directly, what happens is that Jess set the corresponding Bean
property, anticipating that the PropertyChangeEvent will be received
and lead to the shadow fact being modified as above. As a result, the
performance overhead of using Beans amounts to basically one or two
method calls and a few variable accesses -- a negligible contribution
considering that this one modification may cause thousands of partial
matches to be created or destroyed.
Using pre-existing Beans is nice because it makes life easy if you're
connecting Jess up to some larger system. I imagine you could also
create fact types as Beans just for convenience sake, as you intimate
below, but honestly the thought had never occurred to me before.
I think Satish boggavarapu wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
> Hi All,
>
> What are the advantages and disadvantages of representing a network
taxonomy
> using objects (COOL, JESS objects) VS as (SlotName, Object, Value)
triplets
> in CLIPS and JESS.
>
> Are there any performance hits using object representation instead of
> triplet representation? Inheritence issues? Partial matches?
>
> When i modify an attribute slot in Object representation, does it retract
> all the attribute slots in that object and assert them again? Or just that
> particular slot? (Sounds dumb?) :)
>
> I think one known disadvantage of using triplets is readability
>
> For Ex: 10000 elements, each with 10 attributes.
>
> Any views?
>
> Thanks in Advance
> Satish.
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify
[EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) 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 (use your own address!) 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 (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
