Re: JESS: How do I assert ordered facts from a map

2010-08-15 Thread Donald Winston
Ok, that works. Thanks. It didn't make sense to me that I couldn't do this. I 
remember reading in the book Jess in Action (page 55) where it said eval and 
build were synonyms and (build ...) was used for constructs and eval for 
functions out of convention/tradition/historical reasons and not because they 
did things differently. It is an old book even though I bought it recently. 
Maybe things have changed since it was written.

In addition or maybe in place of data structures like maps, lists, and sets I'd 
like to load a jdom Document object into the rule engine and have the rules do 
their thing and read and write to it. That's why I want to be able to create 
assertions from a data structure and not a bean. 

It looks like the add, addAll, and getObjects methods just load and retrieve 
java objects(beans) that are used for shadow facts. Is this true? So I'll be 
just using store and fetch because this seems to be the only way to get non 
shadow fact objects in and out of the rule base. The rules won't be doing 
anything else but reading and writing from and to the stored Document data 
structure and updating the fact base. No querying or updating databases, 
reading or writing files, reading and writing from sockets, sending e-mails, or 
spawning threads, i.e. no side effects. These things will be done outside the 
rule engine based on the info from the updated Document object.

On Aug 14, 2010, at 2:50 AM, Wolfgang Laun wrote:

 (eval (str-cat (assert ( ?key   ((fetch request-parameter-map) get ?key) 
 )) ) )






To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




Re: JESS: How do I assert ordered facts from a map

2010-08-15 Thread Wolfgang Laun
On 15 August 2010 14:09, Donald Winston satchwins...@yahoo.com wrote:

 Ok, that works. Thanks. It didn't make sense to me that I couldn't do this.
 I remember reading in the book Jess in Action (page 55) where it said eval
 and build were synonyms and (build ...) was used for constructs and eval for
 functions out of convention/tradition/historical reasons and not because
 they did things differently. It is an old book even though I bought it
 recently. Maybe things have changed since it was written.


Jess did change since that book was written. As with any SW product, go with
the doc that comes with it. The reference part is satisfactory.

In addition or maybe in place of data structures like maps, lists, and sets
 I'd like to load a jdom Document object into the rule engine and have the
 rules do their thing and read and write to it. That's why I want to be able
 to create assertions from a data structure and not a bean.

 For XML content into and out of WM, I've frequently used JAXB generated
Java classes. I've found this a satisfying, stable approach, with a small
footprint due to changes in the data. (Caveat: the XML structure should be
reasonable.)

It looks like the add, addAll, and getObjects methods just load and retrieve
 java objects(beans) that are used for shadow facts. Is this true?

Yes.


 So I'll be just using store and fetch because this seems to be the only way
 to get non shadow fact objects in and out of the rule base.


No: it is (assert) and (retract). The functions (fetch) and (store) are for
non-WM objects, in a (kind of) global Map provided for the CLIPS interface.


 The rules won't be doing anything else but reading and writing from and to
 the stored Document data structure and updating the fact base. No querying
 or updating databases, reading or writing files, reading and writing from
 sockets, sending e-mails, or spawning threads, i.e. no side effects. These
 things will be done outside the rule engine based on the info from the
 updated Document object.


Truth be told, I've never done much work in the marshalling direction, i.e.,
from WM to a DOM tree. But, here again, I'd investigate the option of
building an Object tree (with shadow facts) and use JAXB's marshalling for
serializing to XML.

-W


 On Aug 14, 2010, at 2:50 AM, Wolfgang Laun wrote:

  (eval (str-cat (assert ( ?key   ((fetch request-parameter-map) get
 ?key) )) ) )





 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 




Re: JESS: How do I assert ordered facts from a map

2010-08-14 Thread Wolfgang Laun
Try this:

(clear)
;;
;; There's no need for an artificial fact to trigger some initial
processing.
;;
(defrule assert-request-parameters-rule
  Assert stored data one time.
  (declare (salience 100))
;; implied: (eval true)
=
  (foreach ?key (((fetch request-parameter-map) keySet) iterator)
;; produce an assert and eval it
(eval (str-cat (assert ( ?key   ((fetch request-parameter-map) get
?key) )) ) )
  )
)

(defrule got-one
  (one ?val)
=
  (printout t one has the value  ?val crlf)
)

(bind ?map (new java.util.HashMap))
(?map put one 1)
(?map put two 2)
(?map put three 3)
(store request-parameter-map ?map)
(reset)
(run)
(facts)



On 14 August 2010 04:15, Donald Winston satchwins...@yahoo.com wrote:

 I just don't want to have to write a lot of Java code to support he use of
 the rule engine. I realize now I  can use the rete.store() to store a Map
 and put the data in the fact base. I just have to know the keys when I'm
 coding the rules and use

(assert (param-name ?param-value))

 I cannot  do this:
(assert (?param-name ?param-value))

 correct?

 I can also assert unordered facts by using slot names for the keys  and use
 one template for the map instead of creating a lot of little facts
 vertically.

 I don't mind changing the rules when the data changes. I do mind having to
 modify java classes every time some new data is added or deleted.

 I've used the Blaze Advisor rule engine before. We passed a large hash
 table of data to it and created the initial fact base for the rules. We
 passed data back to the app the same way after applying the rules.

 On Aug 13, 2010, at 2:41 PM, Wolfgang Laun wrote:

 Donald,

 Assuming you could assert facts from Map.Entry resulting in simple ordered
 facts such as
 (key value) you'd still have to adjust the rules to each change in the key
 set. This is usually more demanding than adding another deftemplate.

 In a map all keys are necessarily distinct. This would mean that you create
 as many different fact types as there are entries. It's difficult to see how
 you can write rules for this setup (but my bean might be too bean-oriented
 to see that.)

 Anyway, you can always (in Java) iterate over the key set, write a simple
 .clp file containing a deftemplate for each key and slurp this file in
 (using (batch)) from your main .clp file.

 Also, you have the option of defining a single fact type (ordered or
 unordered) for two values, say
(deftemplate Entry (slot key) (slot value))
 and assert all your Map.Entry things as such. (Rules will have an unusual
 look-and-feel.)

 BTW, to execute an (assert ...) from a string you'd have to call (eval).
 Function (build) is for constructs, i.e., deftemplate, defrule, and cousins.

 Finally, I have the uncanny feeling that whatever you are trying to solve
 with this approach might be better solved in a fundamentally different way.
 But that's just a feeling, like Swing ;-)

 HTH
 -W



 On 13 August 2010 19:27, Donald Winston satchwins...@yahoo.com wrote:

 ok. Thanks. I won't bother you anymore about this issue. It looks like the
 proper way to do what I want is to use the Jess java api and create ordered
 facts from my map using the Fact class and assert them after the rules.clp
 file has been loaded instead of just storing the map from my java app. (I
 was looking to minimize the use of the java api when working with the rule
 engine, but this doesn't look too bad)

 On Aug 13, 2010, at 11:59 AM, Ernest Friedman-Hill wrote:

  Java classes are totally optional in Jess -- in fact, templates and
 facts created directly from the Jess language are always more efficient.
 
  If Jess were to store the properties of an object in a Map -- so that
 they were dynamic and extensible at runtime -- then it would be considerably
 slower, for the same reason that fully dynamic languages in which objects
 are maps of code and variables are slower than compiled languages.
 Construction of a fast Rete network requires knowing what properties are
 being dealt with. Think of a database in which all the data was stored as
 object-attribute-value triples -- would it be as fast as a database with
 fixed tables and columns?
 
 
  On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:
 
  So I have to create a template and know all the identifiers before
 loading data into the fact base? This means I'll have to create java bean
 objects for all my data. Every time the data changes I'll have to modify the
 java classes. I don't believe in creating objects for things that have
 little or no behavior. That's what Maps and Lists  are for.
 
  I suppose I could generate a init-facts.clp file when my app starts
 up and load it along with the rules.
 
  On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:
 
  Basically for the same reason that you can't say something like this
 in Java:
 
  String theMethodName = toString;
  String myString = myObject.(theMethodName)();
 
  but instead you have to use reflection to find the method 

Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Ernest Friedman-Hill
Basically for the same reason that you can't say something like this  
in Java:


String theMethodName = toString;
String myString = myObject.(theMethodName)();

but instead you have to use reflection to find the method toString  
and call it using the Method object. The compiler needs to know the  
correct template to use to compile the code, and it can't do that if  
the name of the template is in a variable.


Now, you may ask *could* it work the way you want? Indeed, it could --  
but it doesn't at this time. We've talked in the past about allowing  
this kind of thing, and it has its pros and cons.



On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:


Can anyone explain to me why this does not work? Why can't I use

(deffacts initial-facts
  Facts to trigger a few appropriate salient initialization rules.
  (assert-request-parameters))

(defrule assert-request-parameters-rule
 Assert stored data one time.
  (declare (salience 100))
 ?x - (assert-request-parameters)
=
 (foreach ?key (((fetch request-parameter-map) keySet) iterator)
  (build str-cat (assert ( ?key   ((fetch request- 
parameter-map) get ?key) 
   ; why not (assert (?key ((fetch request-parameter-map)  
get ?key

 (retract ?x))

(bind ?map (new java.util.HashMap))
(?map put one 1)
(?map put two 2)
(?map put three 3)
(store request-parameter-map ?map)
(reset)
(facts)
(run)
(facts)

Jess, the Rule Engine for the Java Platform
Copyright (C) 2008 Sandia Corporation
Jess Version 7.1p2 11/5/2008

This copy of Jess will expire in 207 day(s).
f-0   (MAIN::initial-fact)
f-1   (MAIN::assert-request-parameters)
For a total of 2 facts in module MAIN.

f-0   (MAIN::initial-fact)
For a total of 1 facts in module MAIN.


-
Ernest Friedman-Hill
Informatics  Decision Sciences, Sandia National Laboratories
PO Box 969, MS 9012, Livermore, CA 94550
http://www.jessrules.com








To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Donald Winston
So I have to create a template and know all the identifiers before loading data 
into the fact base? This means I'll have to create java bean objects for all my 
data. Every time the data changes I'll have to modify the java classes. I don't 
believe in creating objects for things that have little or no behavior. That's 
what Maps and Lists  are for.

I suppose I could generate a init-facts.clp file when my app starts up and 
load it along with the rules.

On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:

 Basically for the same reason that you can't say something like this in Java:
 
 String theMethodName = toString;
 String myString = myObject.(theMethodName)();
 
 but instead you have to use reflection to find the method toString and call 
 it using the Method object. The compiler needs to know the correct template 
 to use to compile the code, and it can't do that if the name of the template 
 is in a variable.
 
 Now, you may ask *could* it work the way you want? Indeed, it could -- but it 
 doesn't at this time. We've talked in the past about allowing this kind of 
 thing, and it has its pros and cons.
 
 
 On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:
 
 Can anyone explain to me why this does not work? Why can't I use
 
 (deffacts initial-facts
  Facts to trigger a few appropriate salient initialization rules.
  (assert-request-parameters))
 
 (defrule assert-request-parameters-rule
 Assert stored data one time.
  (declare (salience 100))
 ?x - (assert-request-parameters)
=
 (foreach ?key (((fetch request-parameter-map) keySet) iterator)
  (build str-cat (assert ( ?key   ((fetch request-parameter-map) 
 get ?key) 
   ; why not (assert (?key ((fetch request-parameter-map) get ?key
 (retract ?x))
 
 (bind ?map (new java.util.HashMap))
 (?map put one 1)
 (?map put two 2)
 (?map put three 3)
 (store request-parameter-map ?map)
 (reset)
 (facts)
 (run)
 (facts)
 
 Jess, the Rule Engine for the Java Platform
 Copyright (C) 2008 Sandia Corporation
 Jess Version 7.1p2 11/5/2008
 
 This copy of Jess will expire in 207 day(s).
 f-0   (MAIN::initial-fact)
 f-1   (MAIN::assert-request-parameters)
 For a total of 2 facts in module MAIN.
 
 f-0   (MAIN::initial-fact)
 For a total of 1 facts in module MAIN.
 
 -
 Ernest Friedman-Hill
 Informatics  Decision Sciences, Sandia National Laboratories
 PO Box 969, MS 9012, Livermore, CA 94550
 http://www.jessrules.com
 
 
 
 
 
 
 
 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 
 






To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Ernest Friedman-Hill
Java classes are totally optional in Jess -- in fact, templates and  
facts created directly from the Jess language are always more efficient.


If Jess were to store the properties of an object in a Map -- so that  
they were dynamic and extensible at runtime -- then it would be  
considerably slower, for the same reason that fully dynamic languages  
in which objects are maps of code and variables are slower than  
compiled languages. Construction of a fast Rete network requires  
knowing what properties are being dealt with. Think of a database in  
which all the data was stored as object-attribute-value triples --  
would it be as fast as a database with fixed tables and columns?



On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:

So I have to create a template and know all the identifiers before  
loading data into the fact base? This means I'll have to create java  
bean objects for all my data. Every time the data changes I'll have  
to modify the java classes. I don't believe in creating objects for  
things that have little or no behavior. That's what Maps and Lists   
are for.


I suppose I could generate a init-facts.clp file when my app  
starts up and load it along with the rules.


On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:

Basically for the same reason that you can't say something like  
this in Java:


String theMethodName = toString;
String myString = myObject.(theMethodName)();

but instead you have to use reflection to find the method  
toString and call it using the Method object. The compiler needs  
to know the correct template to use to compile the code, and it  
can't do that if the name of the template is in a variable.


Now, you may ask *could* it work the way you want? Indeed, it could  
-- but it doesn't at this time. We've talked in the past about  
allowing this kind of thing, and it has its pros and cons.



On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:


Can anyone explain to me why this does not work? Why can't I use

(deffacts initial-facts
Facts to trigger a few appropriate salient initialization rules.
(assert-request-parameters))

(defrule assert-request-parameters-rule
Assert stored data one time.
(declare (salience 100))
?x - (assert-request-parameters)
  =
(foreach ?key (((fetch request-parameter-map) keySet) iterator)
(build str-cat (assert ( ?key   ((fetch request- 
parameter-map) get ?key) 
 ; why not (assert (?key ((fetch request-parameter-map)  
get ?key

   (retract ?x))

(bind ?map (new java.util.HashMap))
(?map put one 1)
(?map put two 2)
(?map put three 3)
(store request-parameter-map ?map)
(reset)
(facts)
(run)
(facts)

Jess, the Rule Engine for the Java Platform
Copyright (C) 2008 Sandia Corporation
Jess Version 7.1p2 11/5/2008

This copy of Jess will expire in 207 day(s).
f-0   (MAIN::initial-fact)
f-1   (MAIN::assert-request-parameters)
For a total of 2 facts in module MAIN.

f-0   (MAIN::initial-fact)
For a total of 1 facts in module MAIN.


-
Ernest Friedman-Hill
Informatics  Decision Sciences, Sandia National Laboratories
PO Box 969, MS 9012, Livermore, CA 94550
http://www.jessrules.com








To unsubscribe, send the words 'unsubscribe jess-users y...@address.com 
'

in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov 
.










To unsubscribe, send the words 'unsubscribe jess-users  
y...@address.com'

in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov 
.




-
Ernest Friedman-Hill
Informatics  Decision Sciences  Phone: (925) 294-2154
Sandia National Labs
PO Box 969, MS 9012ejfr...@sandia.gov
Livermore, CA 94550 http://www.jessrules.com






To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Jason Morris
As one who's soul is currently languishing in RDF, RDFS, OWL
purgatory, let me answer Ernest's rhetorical question: NO000!  ;-)

On Fri, Aug 13, 2010 at 11:59 AM, Ernest Friedman-Hill
ejfr...@sandia.gov wrote:
 Java classes are totally optional in Jess -- in fact, templates and facts
 created directly from the Jess language are always more efficient.

 If Jess were to store the properties of an object in a Map -- so that they
 were dynamic and extensible at runtime -- then it would be considerably
 slower, for the same reason that fully dynamic languages in which objects
 are maps of code and variables are slower than compiled languages.
 Construction of a fast Rete network requires knowing what properties are
 being dealt with. Think of a database in which all the data was stored as
 object-attribute-value triples -- would it be as fast as a database with
 fixed tables and columns?


 On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:

 So I have to create a template and know all the identifiers before loading
 data into the fact base? This means I'll have to create java bean objects
 for all my data. Every time the data changes I'll have to modify the java
 classes. I don't believe in creating objects for things that have little or
 no behavior. That's what Maps and Lists  are for.

 I suppose I could generate a init-facts.clp file when my app starts up
 and load it along with the rules.

 On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:

 Basically for the same reason that you can't say something like this in
 Java:

 String theMethodName = toString;
 String myString = myObject.(theMethodName)();

 but instead you have to use reflection to find the method toString and
 call it using the Method object. The compiler needs to know the correct
 template to use to compile the code, and it can't do that if the name of the
 template is in a variable.

 Now, you may ask *could* it work the way you want? Indeed, it could --
 but it doesn't at this time. We've talked in the past about allowing this
 kind of thing, and it has its pros and cons.


 On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:

 Can anyone explain to me why this does not work? Why can't I use

 (deffacts initial-facts
 Facts to trigger a few appropriate salient initialization rules.
 (assert-request-parameters))

 (defrule assert-request-parameters-rule
 Assert stored data one time.
 (declare (salience 100))
 ?x - (assert-request-parameters)
      =
 (foreach ?key (((fetch request-parameter-map) keySet) iterator)
        (build str-cat (assert ( ?key   ((fetch
 request-parameter-map) get ?key) 
         ; why not (assert (?key ((fetch request-parameter-map) get
 ?key
   (retract ?x))

 (bind ?map (new java.util.HashMap))
 (?map put one 1)
 (?map put two 2)
 (?map put three 3)
 (store request-parameter-map ?map)
 (reset)
 (facts)
 (run)
 (facts)

 Jess, the Rule Engine for the Java Platform
 Copyright (C) 2008 Sandia Corporation
 Jess Version 7.1p2 11/5/2008

 This copy of Jess will expire in 207 day(s).
 f-0   (MAIN::initial-fact)
 f-1   (MAIN::assert-request-parameters)
 For a total of 2 facts in module MAIN.

 f-0   (MAIN::initial-fact)
 For a total of 1 facts in module MAIN.

 -
 Ernest Friedman-Hill
 Informatics  Decision Sciences, Sandia National Laboratories
 PO Box 969, MS 9012, Livermore, CA 94550
 http://www.jessrules.com







 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify
 owner-jess-us...@sandia.gov.
 






 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 

 -
 Ernest Friedman-Hill
 Informatics  Decision Sciences          Phone: (925) 294-2154
 Sandia National Labs
 PO Box 969, MS 9012                            ejfr...@sandia.gov
 Livermore, CA 94550                             http://www.jessrules.com





 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 





-- 
Cheers,
Jason
--
Morris Technical Solutions LLC
consult...@morris-technical-solutions.com
(517) 304-5883


Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Donald Winston
ok. Thanks. I won't bother you anymore about this issue. It looks like the 
proper way to do what I want is to use the Jess java api and create ordered 
facts from my map using the Fact class and assert them after the rules.clp file 
has been loaded instead of just storing the map from my java app. (I was 
looking to minimize the use of the java api when working with the rule engine, 
but this doesn't look too bad)

On Aug 13, 2010, at 11:59 AM, Ernest Friedman-Hill wrote:

 Java classes are totally optional in Jess -- in fact, templates and facts 
 created directly from the Jess language are always more efficient.
 
 If Jess were to store the properties of an object in a Map -- so that they 
 were dynamic and extensible at runtime -- then it would be considerably 
 slower, for the same reason that fully dynamic languages in which objects are 
 maps of code and variables are slower than compiled languages. Construction 
 of a fast Rete network requires knowing what properties are being dealt with. 
 Think of a database in which all the data was stored as 
 object-attribute-value triples -- would it be as fast as a database with 
 fixed tables and columns?
 
 
 On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:
 
 So I have to create a template and know all the identifiers before loading 
 data into the fact base? This means I'll have to create java bean objects 
 for all my data. Every time the data changes I'll have to modify the java 
 classes. I don't believe in creating objects for things that have little or 
 no behavior. That's what Maps and Lists  are for.
 
 I suppose I could generate a init-facts.clp file when my app starts up and 
 load it along with the rules.
 
 On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:
 
 Basically for the same reason that you can't say something like this in 
 Java:
 
 String theMethodName = toString;
 String myString = myObject.(theMethodName)();
 
 but instead you have to use reflection to find the method toString and 
 call it using the Method object. The compiler needs to know the correct 
 template to use to compile the code, and it can't do that if the name of 
 the template is in a variable.
 
 Now, you may ask *could* it work the way you want? Indeed, it could -- but 
 it doesn't at this time. We've talked in the past about allowing this kind 
 of thing, and it has its pros and cons.
 
 
 On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:
 
 Can anyone explain to me why this does not work? Why can't I use
 
 (deffacts initial-facts
 Facts to trigger a few appropriate salient initialization rules.
 (assert-request-parameters))
 
 (defrule assert-request-parameters-rule
 Assert stored data one time.
 (declare (salience 100))
 ?x - (assert-request-parameters)
  =
 (foreach ?key (((fetch request-parameter-map) keySet) iterator)
(build str-cat (assert ( ?key   ((fetch request-parameter-map) 
 get ?key) 
 ; why not (assert (?key ((fetch request-parameter-map) get ?key
   (retract ?x))
 
 (bind ?map (new java.util.HashMap))
 (?map put one 1)
 (?map put two 2)
 (?map put three 3)
 (store request-parameter-map ?map)
 (reset)
 (facts)
 (run)
 (facts)
 
 Jess, the Rule Engine for the Java Platform
 Copyright (C) 2008 Sandia Corporation
 Jess Version 7.1p2 11/5/2008
 
 This copy of Jess will expire in 207 day(s).
 f-0   (MAIN::initial-fact)
 f-1   (MAIN::assert-request-parameters)
 For a total of 2 facts in module MAIN.
 
 f-0   (MAIN::initial-fact)
 For a total of 1 facts in module MAIN.
 
 -
 Ernest Friedman-Hill
 Informatics  Decision Sciences, Sandia National Laboratories
 PO Box 969, MS 9012, Livermore, CA 94550
 http://www.jessrules.com
 
 
 
 
 
 
 
 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 
 
 
 
 
 
 
 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 
 
 -
 Ernest Friedman-Hill
 Informatics  Decision Sciences  Phone: (925) 294-2154
 Sandia National Labs
 PO Box 969, MS 9012ejfr...@sandia.gov
 Livermore, CA 94550 http://www.jessrules.com
 
 
 
 
 
 
 To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to 

Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Wolfgang Laun
Donald,

Assuming you could assert facts from Map.Entry resulting in simple ordered
facts such as
(key value) you'd still have to adjust the rules to each change in the key
set. This is usually more demanding than adding another deftemplate.

In a map all keys are necessarily distinct. This would mean that you create
as many different fact types as there are entries. It's difficult to see how
you can write rules for this setup (but my bean might be too bean-oriented
to see that.)

Anyway, you can always (in Java) iterate over the key set, write a simple
.clp file containing a deftemplate for each key and slurp this file in
(using (batch)) from your main .clp file.

Also, you have the option of defining a single fact type (ordered or
unordered) for two values, say
   (deftemplate Entry (slot key) (slot value))
and assert all your Map.Entry things as such. (Rules will have an unusual
look-and-feel.)

BTW, to execute an (assert ...) from a string you'd have to call (eval).
Function (build) is for constructs, i.e., deftemplate, defrule, and cousins.

Finally, I have the uncanny feeling that whatever you are trying to solve
with this approach might be better solved in a fundamentally different way.
But that's just a feeling, like Swing ;-)

HTH
-W



On 13 August 2010 19:27, Donald Winston satchwins...@yahoo.com wrote:

 ok. Thanks. I won't bother you anymore about this issue. It looks like the
 proper way to do what I want is to use the Jess java api and create ordered
 facts from my map using the Fact class and assert them after the rules.clp
 file has been loaded instead of just storing the map from my java app. (I
 was looking to minimize the use of the java api when working with the rule
 engine, but this doesn't look too bad)

 On Aug 13, 2010, at 11:59 AM, Ernest Friedman-Hill wrote:

  Java classes are totally optional in Jess -- in fact, templates and facts
 created directly from the Jess language are always more efficient.
 
  If Jess were to store the properties of an object in a Map -- so that
 they were dynamic and extensible at runtime -- then it would be considerably
 slower, for the same reason that fully dynamic languages in which objects
 are maps of code and variables are slower than compiled languages.
 Construction of a fast Rete network requires knowing what properties are
 being dealt with. Think of a database in which all the data was stored as
 object-attribute-value triples -- would it be as fast as a database with
 fixed tables and columns?
 
 
  On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:
 
  So I have to create a template and know all the identifiers before
 loading data into the fact base? This means I'll have to create java bean
 objects for all my data. Every time the data changes I'll have to modify the
 java classes. I don't believe in creating objects for things that have
 little or no behavior. That's what Maps and Lists  are for.
 
  I suppose I could generate a init-facts.clp file when my app starts up
 and load it along with the rules.
 
  On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:
 
  Basically for the same reason that you can't say something like this in
 Java:
 
  String theMethodName = toString;
  String myString = myObject.(theMethodName)();
 
  but instead you have to use reflection to find the method toString
 and call it using the Method object. The compiler needs to know the correct
 template to use to compile the code, and it can't do that if the name of the
 template is in a variable.
 
  Now, you may ask *could* it work the way you want? Indeed, it could --
 but it doesn't at this time. We've talked in the past about allowing this
 kind of thing, and it has its pros and cons.
 
 
  On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:
 
  Can anyone explain to me why this does not work? Why can't I use
 
  (deffacts initial-facts
  Facts to trigger a few appropriate salient initialization rules.
  (assert-request-parameters))
 
  (defrule assert-request-parameters-rule
  Assert stored data one time.
  (declare (salience 100))
  ?x - (assert-request-parameters)
   =
  (foreach ?key (((fetch request-parameter-map) keySet) iterator)
 (build str-cat (assert ( ?key   ((fetch
 request-parameter-map) get ?key) 
  ; why not (assert (?key ((fetch request-parameter-map) get
 ?key
(retract ?x))
 
  (bind ?map (new java.util.HashMap))
  (?map put one 1)
  (?map put two 2)
  (?map put three 3)
  (store request-parameter-map ?map)
  (reset)
  (facts)
  (run)
  (facts)
 
  Jess, the Rule Engine for the Java Platform
  Copyright (C) 2008 Sandia Corporation
  Jess Version 7.1p2 11/5/2008
 
  This copy of Jess will expire in 207 day(s).
  f-0   (MAIN::initial-fact)
  f-1   (MAIN::assert-request-parameters)
  For a total of 2 facts in module MAIN.
 
  f-0   (MAIN::initial-fact)
  For a total of 1 facts in module MAIN.
 
  -
  Ernest Friedman-Hill
  Informatics  Decision 

Re: JESS: How do I assert ordered facts from a map

2010-08-13 Thread Donald Winston
I just don't want to have to write a lot of Java code to support he use of the 
rule engine. I realize now I  can use the rete.store() to store a Map and put 
the data in the fact base. I just have to know the keys when I'm coding the 
rules and use

   (assert (param-name ?param-value))

I cannot  do this:
   (assert (?param-name ?param-value))

correct?

I can also assert unordered facts by using slot names for the keys  and use one 
template for the map instead of creating a lot of little facts vertically.

I don't mind changing the rules when the data changes. I do mind having to 
modify java classes every time some new data is added or deleted.

I've used the Blaze Advisor rule engine before. We passed a large hash table of 
data to it and created the initial fact base for the rules. We passed data back 
to the app the same way after applying the rules. 

On Aug 13, 2010, at 2:41 PM, Wolfgang Laun wrote:

 Donald,
 
 Assuming you could assert facts from Map.Entry resulting in simple ordered 
 facts such as
 (key value) you'd still have to adjust the rules to each change in the key 
 set. This is usually more demanding than adding another deftemplate.
 
 In a map all keys are necessarily distinct. This would mean that you create 
 as many different fact types as there are entries. It's difficult to see how 
 you can write rules for this setup (but my bean might be too bean-oriented to 
 see that.)
 
 Anyway, you can always (in Java) iterate over the key set, write a simple 
 .clp file containing a deftemplate for each key and slurp this file in (using 
 (batch)) from your main .clp file.
 
 Also, you have the option of defining a single fact type (ordered or 
 unordered) for two values, say
(deftemplate Entry (slot key) (slot value))
 and assert all your Map.Entry things as such. (Rules will have an unusual 
 look-and-feel.)
 
 BTW, to execute an (assert ...) from a string you'd have to call (eval). 
 Function (build) is for constructs, i.e., deftemplate, defrule, and cousins.
 
 Finally, I have the uncanny feeling that whatever you are trying to solve 
 with this approach might be better solved in a fundamentally different way. 
 But that's just a feeling, like Swing ;-)
 
 HTH
 -W
   
 
 
 On 13 August 2010 19:27, Donald Winston satchwins...@yahoo.com wrote:
 ok. Thanks. I won't bother you anymore about this issue. It looks like the 
 proper way to do what I want is to use the Jess java api and create ordered 
 facts from my map using the Fact class and assert them after the rules.clp 
 file has been loaded instead of just storing the map from my java app. (I was 
 looking to minimize the use of the java api when working with the rule 
 engine, but this doesn't look too bad)
 
 On Aug 13, 2010, at 11:59 AM, Ernest Friedman-Hill wrote:
 
  Java classes are totally optional in Jess -- in fact, templates and facts 
  created directly from the Jess language are always more efficient.
 
  If Jess were to store the properties of an object in a Map -- so that they 
  were dynamic and extensible at runtime -- then it would be considerably 
  slower, for the same reason that fully dynamic languages in which objects 
  are maps of code and variables are slower than compiled languages. 
  Construction of a fast Rete network requires knowing what properties are 
  being dealt with. Think of a database in which all the data was stored as 
  object-attribute-value triples -- would it be as fast as a database with 
  fixed tables and columns?
 
 
  On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:
 
  So I have to create a template and know all the identifiers before loading 
  data into the fact base? This means I'll have to create java bean objects 
  for all my data. Every time the data changes I'll have to modify the java 
  classes. I don't believe in creating objects for things that have little 
  or no behavior. That's what Maps and Lists  are for.
 
  I suppose I could generate a init-facts.clp file when my app starts up 
  and load it along with the rules.
 
  On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:
 
  Basically for the same reason that you can't say something like this in 
  Java:
 
  String theMethodName = toString;
  String myString = myObject.(theMethodName)();
 
  but instead you have to use reflection to find the method toString and 
  call it using the Method object. The compiler needs to know the correct 
  template to use to compile the code, and it can't do that if the name of 
  the template is in a variable.
 
  Now, you may ask *could* it work the way you want? Indeed, it could -- 
  but it doesn't at this time. We've talked in the past about allowing this 
  kind of thing, and it has its pros and cons.
 
 
  On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:
 
  Can anyone explain to me why this does not work? Why can't I use
 
  (deffacts initial-facts
  Facts to trigger a few appropriate salient initialization rules.
  (assert-request-parameters))
 
  (defrule