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]
---------------------------------------------------------------------
