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 <[email protected]> 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 Sciences, Sandia National Laboratories > >>> PO Box 969, MS 9012, Livermore, CA 94550 > >>> http://www.jessrules.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > >>> 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]. > >> -------------------------------------------------------------------- > > > > --------------------------------------------------------- > > Ernest Friedman-Hill > > Informatics & Decision Sciences Phone: (925) 294-2154 > > Sandia National Labs > > PO Box 969, MS 9012 [email protected] > > Livermore, CA 94550 http://www.jessrules.com > > > > > > > > > > > > -------------------------------------------------------------------- > > 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]. > -------------------------------------------------------------------- > >
