Re: JESS: Jess error: Bad index

2005-11-02 Thread kip . c . lubliner



Hello,

as a new JESS user, this email was very
helpful, thanks!

Does anybody have any information about
websites that have similar design information, or even case studies?

Thanks,
Kip

Kip Lubliner
Developer, HSBC Securities
646-344-3113

[EMAIL PROTECTED] wrote on 11/01/2005 08:41:39
AM:

 While this reply does not deal directly with the rule under discussion,
I 
 continue to be amazed at the approaches used to engineer
rule-based 
 systems (which ultimately fail) and how little we hear from the the
Olympic 
 geniuses who are employed by the vendors (unless you are willing to
pay 
 $300/hr).
 
 To me, rules engineering (at the requirements/analysis level) is a

 discipline that is simple:
 
 (1) discover the rules that are found/described in the
textual portions of 
 the requirements.
 
 (2) describe possible information entities that the rule's
LHS uses to 
 test for truth and that the rule's RHS would take action with 
 (create/update/delete).
 
 (3) model this information in such a way that the potential interactions

 between the rules can be documented, i.e. what conditional testing
by LHS 
 would be impacted by actions of the RHSs of other rules.
 
 (4) elaborate on this information with a high-level control
system to 
 preclude the possibility of undesirable conflicts between rules.
 
 Ironically, much of this can be set down in an Excel spreadsheet.
The 
 principal problem is that the merit of this approach seems to be lost
on 
 people until they have endured multiple project failures (myself included)

 and begin to look at rules engineering as something that is 180 degrees
out 
 of phase from ordinary procedural programming - it is a radically
different 
 paradigm that is not intuitively obvious to the uninitiated.
 
 Once this technique becomes second nature to the rules designer, success

 (and $) will follow. I offer this advice free to beginners, but
as a 
 consultant I do not work for free.
 
 Rich Halsey
 - Original Message - 
 From: James C. Owen [EMAIL PROTECTED]
 To: jess-users@sandia.gov
 Sent: Monday, October 31, 2005 11:53 PM
 Subject: Re: JESS: Jess error: Bad index
 
 
  OK, this has been in my mail box for almost four hours and no
one has 
  said anything - so, here goes. FIRST - don't write B I
G rules !!! 
  Second, half of the logic is in the right hand side (AE) of the
rule. 
  Why? Third, there is absolutely NO explanation of what
the rule does or 
  what it is supposed to do, etc., etc. etc. Pretty much,
this is written 
  like a lot of rules that I see every day. Rules that show
a thought 
  process gone amok. So, break it down, think it out, make
it simple, THEN 
  see what's wrong with the logic. Actually, what is
wrong with the rule 
  is in the error message itself; apparently Jess thinks
that there is a 
  call to a Vector in the LHS of the rule and that index
123 is a bad 
  index. Probably is.
 
  On the other hand, even if you fix that part of the rule, it
should still 
  be taken out and shot for breaking the first three guidelines
mentioned 
  above. Anyway, it's almost midnight. Time for all
good little rule boys 
  to be in bed. Preferably with someone else. :-)
 
  SDG
  jco
 
  On Oct 31, 2005, at 8:35 PM, Eunice Palmeira wrote:
 
  I use Jess 6.1 p4 and JessTab 1.3, when a run big rules
like the rule
  below the Jess report an error:
 
  Jess reported an error in routine ValueVector.get
while executing rule LHS (MTELN)
while executing rule LHS (TECT).
   Message: Bad index 123 in call to get() on this vector:
  (MAIN::object (is-a :JESS-DEFTEMPLATE) (is-a-name :JESS-DEFTEMPLATE)
  (OBJECT External- 
  Address:edu.stanford.smi.protege.model.DefaultSimpleInstance)
  (:NAME Science_Instance_45) (:DIRECT-TYPE
  External-Address:edu.stanford.smi.protege.model.DefaultCls)
  (:DIRECT-INSTANCES ) 
 
  RULE:
  (defrule e_201_links
(object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED|

  EXTRACTED|LIST)
(is-a Processing-Monitor))
  ?s - (object (is-a Suggestion-Recognizer)
(What-to-Suggest
  ?kLINK|LINK-TEXT)
   (Class-to-Suggest
?c) (Cases $?cs))
   ?f - (Result (Page-Status ?))
  (not (Processed Links ?k))
(object (is-a Agent) (treats-Class ?ca) (name
?nsa))
?g - (object (is-a Case) (Concepts
$?cb:( (length$ $?cb) 0))
  (Keywords $?k) (Absent-Concepts $?ac))
(test (and
   (integerp (member$
(instance-address ?g) $?cs))
(or (eq ?c ?ca) (subclassp ?c ?ca
   =
(if (eq ?k LINK) then
  (insert-link ?nsa (search-in-list
(create$ (words-of-concepts
  $?cb) $?k)
  
 (slot-get [LINKS] Values) (slot-get [PAGE]
  Links)) ?f ?c 201)
 else (insert-link
?nsa (search-in-list (create$
  (words-of-concepts $?cb) $?k)
(slot-get [LINKS-TEXTS]
Values) (slot-get [PAGE] Links)) ?f 
  ?c 201))
(assert (Processed Links ?k)))
 
 
  Help me please,
 Eunice
 
 
  
  To unsubscribe, send the words

Re: JESS: Jess error: Bad index

2005-11-01 Thread Rich Halsey
While this reply does not deal directly with the rule under discussion, I 
continue to be amazed at the approaches used to engineer rule-based 
systems (which ultimately fail) and how little we hear from the the Olympic 
geniuses who are employed by the vendors (unless you are willing to pay 
$300/hr).


To me, rules engineering (at the requirements/analysis level) is a 
discipline that is simple:


(1) discover the rules that are found/described in the textual portions of 
the requirements.


(2) describe possible information entities that the rule's LHS uses to 
test for truth and that the rule's RHS would take action with 
(create/update/delete).


(3) model this information in such a way that the potential interactions 
between the rules can be documented, i.e. what conditional testing by LHS 
would be impacted by actions of the RHSs of other rules.


(4) elaborate on this information with a high-level control system to 
preclude the possibility of undesirable conflicts between rules.


Ironically, much of this can be set down in an Excel spreadsheet. The 
principal problem is that the merit of this approach seems to be lost on 
people until they have endured multiple project failures (myself included) 
and begin to look at rules engineering as something that is 180 degrees out 
of phase from ordinary procedural programming - it is a radically different 
paradigm that is not intuitively obvious to the uninitiated.


Once this technique becomes second nature to the rules designer, success 
(and $) will follow. I offer this advice free to beginners, but as a 
consultant I do not work for free.


Rich Halsey
- Original Message - 
From: James C. Owen [EMAIL PROTECTED]

To: jess-users@sandia.gov
Sent: Monday, October 31, 2005 11:53 PM
Subject: Re: JESS: Jess error: Bad index


OK, this has been in my mail box for almost four hours and no one has 
said anything - so, here goes.  FIRST - don't write B I G rules !!! 
Second, half of the logic is in the right hand side (AE) of the  rule. 
Why?  Third, there is absolutely NO explanation of what the  rule does or 
what it is supposed to do, etc., etc. etc.  Pretty much,  this is written 
like a lot of rules that I see every day.  Rules that  show a thought 
process gone amok.  So, break it down, think it out,  make it simple, THEN 
see what's wrong with the logic.  Actually, what  is wrong with the rule 
is in the error message itself; apparently  Jess thinks that there is a 
call to a Vector in the LHS of the rule  and that index 123 is a bad 
index.  Probably is.


On the other hand, even if you fix that part of the rule, it should  still 
be taken out and shot for breaking the first three guidelines  mentioned 
above.  Anyway, it's almost midnight.  Time for all good  little rule boys 
to be in bed.  Preferably with someone else.  :-)


SDG
jco

On Oct 31, 2005, at 8:35 PM, Eunice Palmeira wrote:


I use  Jess 6.1 p4 and JessTab 1.3, when a run big rules like the rule
below the Jess report an error:

Jess reported an error in routine ValueVector.get
while executing rule LHS (MTELN)
while executing rule LHS (TECT).
  Message: Bad index 123 in call to get() on this vector:
(MAIN::object (is-a :JESS-DEFTEMPLATE) (is-a-name :JESS-DEFTEMPLATE)
(OBJECT External- 
Address:edu.stanford.smi.protege.model.DefaultSimpleInstance)

(:NAME Science_Instance_45) (:DIRECT-TYPE
External-Address:edu.stanford.smi.protege.model.DefaultCls)
(:DIRECT-INSTANCES ) 

RULE:
(defrule e_201_links
 (object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED| 
EXTRACTED|LIST)

 (is-a Processing-Monitor))
?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest
?kLINK|LINK-TEXT)
   (Class-to-Suggest ?c) (Cases $?cs))
  ?f - (Result (Page-Status ?))
 (not (Processed Links ?k))
(object (is-a Agent) (treats-Class ?ca) (name ?nsa))
 ?g - (object (is-a Case) (Concepts $?cb:( (length$ $?cb) 0))
(Keywords $?k) (Absent-Concepts $?ac))
(test (and
   (integerp (member$ (instance-address ?g) $?cs))
 (or (eq ?c ?ca) (subclassp ?c ?ca
  =
 (if (eq ?k LINK) then
 (insert-link ?nsa (search-in-list (create$ (words-of-concepts
$?cb) $?k)
 (slot-get [LINKS] Values) (slot-get [PAGE]
Links)) ?f ?c 201)
  else (insert-link ?nsa (search-in-list (create$
(words-of-concepts $?cb) $?k)
(slot-get [LINKS-TEXTS] Values) (slot-get [PAGE]  Links)) ?f 
?c 201))

(assert (Processed Links ?k)))


Help me please,
   Eunice



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 owner-jess- 
[EMAIL PROTECTED]








To unsubscribe, send the words

Re: JESS: Jess error: Bad index

2005-11-01 Thread Eunice Palmeira
Well, the solution was to change the version of JessTab and Jess. Now
I use Jess 6.0b3 and JessTab1.1. However, when I run from eclipse many
errors are reported.
Can you help me?
Eunice




2005/11/1, Rich Halsey [EMAIL PROTECTED]:
 While this reply does not deal directly with the rule under discussion, I
 continue to be amazed at the approaches used to engineer rule-based
 systems (which ultimately fail) and how little we hear from the the Olympic
 geniuses who are employed by the vendors (unless you are willing to pay
 $300/hr).

 To me, rules engineering (at the requirements/analysis level) is a
 discipline that is simple:

 (1) discover the rules that are found/described in the textual portions of
 the requirements.

 (2) describe possible information entities that the rule's LHS uses to
 test for truth and that the rule's RHS would take action with
 (create/update/delete).

 (3) model this information in such a way that the potential interactions
 between the rules can be documented, i.e. what conditional testing by LHS
 would be impacted by actions of the RHSs of other rules.

 (4) elaborate on this information with a high-level control system to
 preclude the possibility of undesirable conflicts between rules.

 Ironically, much of this can be set down in an Excel spreadsheet. The
 principal problem is that the merit of this approach seems to be lost on
 people until they have endured multiple project failures (myself included)
 and begin to look at rules engineering as something that is 180 degrees out
 of phase from ordinary procedural programming - it is a radically different
 paradigm that is not intuitively obvious to the uninitiated.

 Once this technique becomes second nature to the rules designer, success
 (and $) will follow. I offer this advice free to beginners, but as a
 consultant I do not work for free.

 Rich Halsey
 - Original Message -
 From: James C. Owen [EMAIL PROTECTED]
 To: jess-users@sandia.gov
 Sent: Monday, October 31, 2005 11:53 PM
 Subject: Re: JESS: Jess error: Bad index


  OK, this has been in my mail box for almost four hours and no one has
  said anything - so, here goes.  FIRST - don't write B I G rules !!!
  Second, half of the logic is in the right hand side (AE) of the  rule.
  Why?  Third, there is absolutely NO explanation of what the  rule does or
  what it is supposed to do, etc., etc. etc.  Pretty much,  this is written
  like a lot of rules that I see every day.  Rules that  show a thought
  process gone amok.  So, break it down, think it out,  make it simple, THEN
  see what's wrong with the logic.  Actually, what  is wrong with the rule
  is in the error message itself; apparently  Jess thinks that there is a
  call to a Vector in the LHS of the rule  and that index 123 is a bad
  index.  Probably is.
 
  On the other hand, even if you fix that part of the rule, it should  still
  be taken out and shot for breaking the first three guidelines  mentioned
  above.  Anyway, it's almost midnight.  Time for all good  little rule boys
  to be in bed.  Preferably with someone else.  :-)
 
  SDG
  jco
 
  On Oct 31, 2005, at 8:35 PM, Eunice Palmeira wrote:
 
  I use  Jess 6.1 p4 and JessTab 1.3, when a run big rules like the rule
  below the Jess report an error:
 
  Jess reported an error in routine ValueVector.get
  while executing rule LHS (MTELN)
  while executing rule LHS (TECT).
Message: Bad index 123 in call to get() on this vector:
  (MAIN::object (is-a :JESS-DEFTEMPLATE) (is-a-name :JESS-DEFTEMPLATE)
  (OBJECT External-
  Address:edu.stanford.smi.protege.model.DefaultSimpleInstance)
  (:NAME Science_Instance_45) (:DIRECT-TYPE
  External-Address:edu.stanford.smi.protege.model.DefaultCls)
  (:DIRECT-INSTANCES ) 
 
  RULE:
  (defrule e_201_links
   (object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED|
  EXTRACTED|LIST)
   (is-a Processing-Monitor))
  ?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest
  ?kLINK|LINK-TEXT)
 (Class-to-Suggest ?c) (Cases $?cs))
?f - (Result (Page-Status ?))
   (not (Processed Links ?k))
  (object (is-a Agent) (treats-Class ?ca) (name ?nsa))
   ?g - (object (is-a Case) (Concepts $?cb:( (length$ $?cb) 0))
  (Keywords $?k) (Absent-Concepts $?ac))
  (test (and
 (integerp (member$ (instance-address ?g) $?cs))
   (or (eq ?c ?ca) (subclassp ?c ?ca
=
   (if (eq ?k LINK) then
   (insert-link ?nsa (search-in-list (create$ (words-of-concepts
  $?cb) $?k)
   (slot-get [LINKS] Values) (slot-get [PAGE]
  Links)) ?f ?c 201)
else (insert-link ?nsa (search-in-list (create$
  (words-of-concepts $?cb) $?k)
  (slot-get [LINKS-TEXTS] Values) (slot-get [PAGE]  Links)) ?f
  ?c 201))
  (assert (Processed Links ?k)))
 
 
  Help me please,
 Eunice
 
 
  
  To unsubscribe, send the words

Re: JESS: Jess error: Bad index

2005-11-01 Thread Alan Moore

Eunice,

Please provide the exact code and error messages you are getting. Please 
try to figure out whether the problem is with Protege, JessTab and/or 
Jess before posting to this list.


For example, copy key portions (e.g. function names, exception names) of 
the stacktrace you are getting and then try Googling for them. Often you 
will find answers listed in a FAQ or in a mailing list archive. Also, 
try searching the Protoge list archives/FAQ for JessTab. Rarely (if 
ever?) is a Protoge/JessTab related problem due to something in Jess.


Good luck!

alan


Eunice Palmeira wrote:

Well, the solution was to change the version of JessTab and Jess. Now
I use Jess 6.0b3 and JessTab1.1. However, when I run from eclipse many
errors are reported.
Can you help me?
Eunice




2005/11/1, Rich Halsey [EMAIL PROTECTED]:


While this reply does not deal directly with the rule under discussion, I
continue to be amazed at the approaches used to engineer rule-based
systems (which ultimately fail) and how little we hear from the the Olympic
geniuses who are employed by the vendors (unless you are willing to pay
$300/hr).

To me, rules engineering (at the requirements/analysis level) is a
discipline that is simple:

(1) discover the rules that are found/described in the textual portions of
the requirements.

(2) describe possible information entities that the rule's LHS uses to
test for truth and that the rule's RHS would take action with
(create/update/delete).

(3) model this information in such a way that the potential interactions
between the rules can be documented, i.e. what conditional testing by LHS
would be impacted by actions of the RHSs of other rules.

(4) elaborate on this information with a high-level control system to
preclude the possibility of undesirable conflicts between rules.

Ironically, much of this can be set down in an Excel spreadsheet. The
principal problem is that the merit of this approach seems to be lost on
people until they have endured multiple project failures (myself included)
and begin to look at rules engineering as something that is 180 degrees out
of phase from ordinary procedural programming - it is a radically different
paradigm that is not intuitively obvious to the uninitiated.

Once this technique becomes second nature to the rules designer, success
(and $) will follow. I offer this advice free to beginners, but as a
consultant I do not work for free.

Rich Halsey
- Original Message -
From: James C. Owen [EMAIL PROTECTED]
To: jess-users@sandia.gov
Sent: Monday, October 31, 2005 11:53 PM
Subject: Re: JESS: Jess error: Bad index




OK, this has been in my mail box for almost four hours and no one has
said anything - so, here goes.  FIRST - don't write B I G rules !!!
Second, half of the logic is in the right hand side (AE) of the  rule.
Why?  Third, there is absolutely NO explanation of what the  rule does or
what it is supposed to do, etc., etc. etc.  Pretty much,  this is written
like a lot of rules that I see every day.  Rules that  show a thought
process gone amok.  So, break it down, think it out,  make it simple, THEN
see what's wrong with the logic.  Actually, what  is wrong with the rule
is in the error message itself; apparently  Jess thinks that there is a
call to a Vector in the LHS of the rule  and that index 123 is a bad
index.  Probably is.

On the other hand, even if you fix that part of the rule, it should  still
be taken out and shot for breaking the first three guidelines  mentioned
above.  Anyway, it's almost midnight.  Time for all good  little rule boys
to be in bed.  Preferably with someone else.  :-)

SDG
jco

On Oct 31, 2005, at 8:35 PM, Eunice Palmeira wrote:



I use  Jess 6.1 p4 and JessTab 1.3, when a run big rules like the rule
below the Jess report an error:

Jess reported an error in routine ValueVector.get
   while executing rule LHS (MTELN)
   while executing rule LHS (TECT).
 Message: Bad index 123 in call to get() on this vector:
(MAIN::object (is-a :JESS-DEFTEMPLATE) (is-a-name :JESS-DEFTEMPLATE)
(OBJECT External-
Address:edu.stanford.smi.protege.model.DefaultSimpleInstance)
(:NAME Science_Instance_45) (:DIRECT-TYPE
External-Address:edu.stanford.smi.protege.model.DefaultCls)
(:DIRECT-INSTANCES ) 

RULE:
(defrule e_201_links
(object (Page-Status ?lRECOMMENDATION|REJECTED|CLASSIFIED|
EXTRACTED|LIST)
(is-a Processing-Monitor))
   ?s - (object (is-a Suggestion-Recognizer) (What-to-Suggest
?kLINK|LINK-TEXT)
  (Class-to-Suggest ?c) (Cases $?cs))
 ?f - (Result (Page-Status ?))
(not (Processed Links ?k))
   (object (is-a Agent) (treats-Class ?ca) (name ?nsa))
?g - (object (is-a Case) (Concepts $?cb:( (length$ $?cb) 0))
(Keywords $?k) (Absent-Concepts $?ac))
   (test (and
  (integerp (member$ (instance-address ?g) $?cs))
(or (eq ?c ?ca) (subclassp ?c ?ca
 =
(if (eq ?k LINK) then
(insert-link ?nsa (search-in-list (create$ (words-of-concepts
$?cb) $?k