ORF 2009

Greetings:

Yes, we are already planning for next year - although I may not do this one. But, at least I can get it started... For next year we will have to change things a bit. Here are some ideas floating around.

Finances: First is that the attendance fee will have to be be $300 minimum but probably more like $500 for all three days. I can't see that the attendance charge will mean much since the local folks didn't come anyway (not many) and another $500 for those who did stay at the hotel will be just under what the hotel room itself costs. And we'll have to negotiate the coffee expense next year: $68 per gallon for Starbucks is outrageous since that comes out to a bit over $3 per 6-ounce cup of coffee. Starbucks is good but...

Speakers: We probably should pay them about $1,000 each honorarium to help with their time and expenses. I'm not sure that we can get Dr. Forgy, Gary Riley and some of the others back next year unless we have something like that. Without them as a drawing card I seriously doubt that there can even be an ORF 2009. Also, we need to get John Zachman to come and be one of the keynote speakers. (No more managers as speakers - not even for keynotes!!) Yes, that will run the cost of the conference up by about $30K but it should return its value in the quality of speakers.

Speakers Per Vendor: Only one per vendor-sponsored per day. Period. EOL. Even with two or three tracks.

Vendor-sponsored lunch: If the Lunch period is two hours each day then we could have three vendor presentations (which would not count as a regular presentation) and a free lunch for attendees. The vendors (only the Platinum ones) would be allowed to also present a full-blown demo during lunch for about an hour. I'm sure that we would have lots of folks who would attend a demo for a really good (free) lunch, right? :-)

Time Allowed for presentations: Maybe the presentations should be 1.5 hours each with a 15 minute break in between. That will leave about 20 minutes for Q&A time plus some time in between to allow setups. That means two in the morning if we start at 8:30 and three in the afternoon for a total of only 15 presentations. BUT, if we have two tracks then we will have 30 talks available. Just some thoughts - comments are encouraged and welcome.

Talks: ALL presentation will HAVE to be submitted en toto not later than June 1, 2009, before approval and publication. We got sandbagged this year by some abstracts that said one thing and the talk that floated in the week before the conference was quite something else. Talks will have to be in two formats; one is the traditional PPT or PDF but the other will be a "White Paper" suitable for publication. Also, we should have an approval board that is completely independent of the conference that will approve all talks - meaning that the talks will now be juried presentations and suitable for publication as a booklet or a book after the conference is over.

Location: We need some feedback on the hotel. Most seemed to think that it was OK but could be better. Also, maybe next year we could do this in San Antonio on the River Walk near the original Alamo. San Antonio is also just about 5 miles south of a VERY large German community. Or Austin which is just north of the German Community. Hawaii or The French Rivera would be nice too but we would have to raise the price to $1,500.

Logo: If we have it in France, then the ORF logo could be emblazoned on "an itsy bitsy, teeny weeny, yellow, polka-dot bikini" and we would have the ORF-Dog logo on 1-liter steins, coffee mugs and T-Shirts. :-)

Time of Conference: I still like having it the week before BR Forum BUT it has to be in late October when it finally gets cool here in Texas. Geeks at ours, Business guys at theirs. And, hopefully, they will meet up at their various companies when they get home. If we have it in France, then maybe late Summer. (Yes, I really was serious about that.)

Something that we had not considered is having memberships (stock ownership) for sale that would help to sponsor all of the events. If each share costs $1,000 and each share had one vote then that would follow good accounting principles.

Anyway, just some thoughts... let me know what you think.

SDG
jco

ORF 2008 - First Report

Greetings:

Third day just starting. This supposed to be the "meat" of the conference. We had desert the first day. Veggies the second day. Raw meat today. Brief recap of the most memorable presentations:

--- Wednesday ---

Rolando Hernandez did a great explanation of Zachman's framework showing how rules fit into the the enterprise. Several Red Hat guys (not the Drools guys) commented that this was what they needed; something that was not so geeky but at a higher level.

Jason Morris: Great talk on Ontology, a subject that few rulebase people ever consider since most are not AI graduates but probably computer science and C/C++ or Java geeks who just drifted into the field.

Edson Terelli: Covered what Drools is doing with the early stages of Complex Event Processing without drifting too much into a product demonstration, something that seems really difficult for the Drools guys because they are all so hyped by their own product. Even Dr. Frogy commented that the talk was really good.

Michael Neal stayed home with his pregnant spousal unit who was due on Thursday of ORF week.

Kris Verlaenen stepped up to delive Mic's talk Guvnor. But he got interrupted by yours truly when he announced that he would now do a Drools demo, something that is totally against the spirit of ORF. I'm sure that his talk would be perfectly suited for some other forum, perhaps a Drools marketing seminar or Java User's Group somewhere but not here. So, we got some wires crossed and Mark Proctor's personality and mine crossed for a few minutes and the talk was over. Me? I blame Mic for hanging Kris out to dry like that. :-)

Pub Night One turned out to be OK since most of us just sat around the hotel lounge and swapped war stories. Some went to supper at one place and some to others.

--- Thursday ---

Dr. Dan Levine opened with a keynote of how the human brain process various thoughts, rules and emotions. I think that knowing how rules are processed in the brain would play a very important role in knowledge acquisition. After all, this whole field owes the origins to the psychology field.

Carole Ann Berlioz-Matigon: Showed us the "other world" of Business Intelligence and Business Analytics and how a rulebase fit into that environment, especially the score card part. I think that most rulebase guys rarely consider that rules play a small part of an overall enterprise IT approach such as that provided by Fair Isaac and other companies.

Carlow Seranno-Morales: Covered Enterprise Decision Management (EDM) from front to back in a gritty (fairly technical) point-of-view. What he and Carole Ann demonstrated was that a rulebase is not the complete answer for a large enterprise - rather it takes of vendors and products that are tightly integrated and rules can be only a small part (sometimes 1/10) of the total solution. The two talks were excellent.

Daniel Selman gave a presentation on sequential rules that verged on product marketing but stayed just out of reach of the "the hook". One thing that he said was that ILOG has a product that is called Rete Non-Node-Merging or something like that. Rete without node merges is not Rete and Dr. Forgy confirmed it later.

Pub Night Two proved to be another bust but lots of great conversations because of the many groups. One such group was composed of Dr. Forgy, Dr. Hicks, Mark Proctor, Gary Riley, Edson Terelli and myself with Steve Nunez joining late. I wish that we had a recorder for what we discussed but one thing came out of it: a slide for my presentation the next day. :-)

--- Friday ---

Rick Hicks: Validation and Verification - mostly verification. This guy is the guru of gurus on this subject and has created modules for CLIPS, OPSJ, Jess and others. He is a professor at Texas A&M but he has his own company, EZ-Xpert. He has published several white papers on his two-tier system; these papers explain WHAT any verification system needs to do to be called a verification system. Excellent talk. Of course he seems to believe that all of the Conflict Resolution Strategies are wrong and that inference engines are most times not needed. See the site for his paper or video presentation.

Gary Riley: (inventor of CLIPS, C Language Integrated Production System) who started at NASA and has been working on the one set of code for 23 years. Being free (or $300 from Comix, the official vendor for CLIPS) this is the "standard" by which so many other rulebased systems are judged. Gary was a very capable speaker and led us deeper into the labyrinth of CLIPS. Beginning with the early days of CLIPS and the reasons for why he did things. He stressed that we need more documentation and many, many more examples to aid the users to understand the systems. Speed is essential. He also talked about how he improved performance on the CLIPS system. A really excellent presentation.

Mark Proctor: (inventor of Drools) did a great discussion on pattern matching, collections, from, etc. Mark also discussed more on multiple entry points on rules for parallel processing.

James Owen: (Yours Truly) Gave a substitute talk (Gary stole my benchmark presentation!) on the original 1979 Rete Algorithm, a second part on the Four Forms of Chaining and, finally, a really brief, four-minute introduction to The History of Parallel Rulebased Programming.

Dr. Charles Forgy gave us a heads up on Parallel Rulebased Programming and why it will be the future of rulebased programming. From what he presented, we, as rulebased systems professionals, need to plan how to parallelize our products and services. Excellent presentation.

Yaakov Kohen showed up and listened in. Interesting fellow.

Pub Night Three turned out pretty good since about 25 of us went to Bone Daddy's, a popular Texas Bar-B-Que joint in North Dallas. Kind of like Hooters but with much younger girls. The food is so good that my wife takes me there from time to time. I'm not allowed to go by myself. :-)

--- Conference Wrap-up ---

LOOONNNGG session on what we wanted more of, less of, suggestions, questions, etc. I hope Rolando and Greg took good notes because we ran out of film before we got very far into it. Here is what little that I gathered:

What attendees want:
1. More question time
2. More time for talks.
3. Donuts and Bagels for breakfast
(David Butler brought donuts on Thursday)
4. Warmer room / Cooler Room / Dimmer Room / Brighter Room
5. MORE Technical talks and less B.S. about products UNLESS it was applicable
6. Maybe two tracks next time; one for beginners and one for Uber Geeks.
7. BOOKS on the subject - what we have is old
8. How To Books on the subject
9. Field is too hard to get into and understand
10. Three days is just about right, not five and not two.

However, we did point out that even selling the few shirts that we had we would probably lose money on the event so everyone agreed that the event should be between $300 and $500 next year (if there is a next year) to help pay for expenses. Apparently setting the cost to $150 to encourage students backfired on us since not one student from the USA attended and only one from the UK.

BTW, if you are an attendee and did not get a shirt and want one, let me know - for a mere $35 + ($10 S/H USA - $15 for outside USA) we'll send you one. Just let us know your size of S / M / L / XL / XXL / XXXL. Greg and I both wear an XXL and Edson Terelli took a Medium so judge accordingly.

------------------------------------------

My conclusions: Great presentations, good coffee, nice folks. For once, it was about 90% Geek and 10% marketing / sales rather than the other way around. If you missed, maybe next year at ORF 2009.

Last thing: Only one person had a comment about my photo. The photo is that of person (a really good friend of mine) throwing a flying side-snap kick with perfect form. What you don't see in the picture is that the person is about 6 feet tall and weighs 215 pounds at the time. If you could see the whole photo you would see that his striking foot is about 5'6" above the ground and he is not using a trampoline to get that high - just lots and lots of training and determination. It proves one thing; success is not easy but it can be done with hard work, determination, proper training and an extremely positive mind set. That's why I keep the photo around - to remind me to keep going when the going gets tough. (Yeah, it's corny but it's true.) Most failures happen because people just give up and begin to see how they can salvage the most from a failure.

Our field is not an easy one and entry to the top level will never be easy. Reading and hard study hurts the head. Planning hurts more. But remember the Seven P's: Proper Prior Planning Prevents Piss-Poor Performance. Also, it is not practice that makes perfect but Proper Perfect Practice Makes Matchless Perfect Performance. (Say that one three times fast!)

SDG
jco

Full Opportunistic Backward Chaining Rulebased Systems

Greetings:

In this blog I will try to dispel the myth you can do Full Opportunistic Backward Chaining (FOBC) with a Forward Chaining (FC) rulebased system without making significant changes to the FC system. Actually, you can do backward chaining with a forward chaining system - BUT it would take a drastic re-write of all of the FC logic to achieve this and even then probably it would not work properly. So, what do you call it when you want to do backward chaining (BC) with a FC engine? Most of those in this field call it Goal-Driven FC - a misnomer if ever there was one. Which is another good reason to drop the explanation of a Backward Chaining system as "goal-driven" and the Forward Chaining system as "data-driven." A BC engine is or can be just as data-driven as a FC engine.

Before discussing chaining, we have to discuss Conflict Resolution - CR. All forward-chaining rulebased systems have some kind of method that will determine which rule to fire if there are more than one rule wherein all of the condition elements are true. This CR varies from vendor to vendor but, for the most part, they all seem to have recency (whether MEA or LEX or something else) as the first or second element in the CR algorithm. Usually this means for any given set of rules, they are resolved in the following order:

1. Refraction
2. Priority
3. Recency
4. Specificity
5. Arbitrary

OPSJ, a Java version of other systems developed by PST (Dr. Forgy) uses a slightly different variation on this where recency takes a higher order than

1. Refraction
2. Rule Class
3. Recency
4. Priority
5. Specificity
6. Arbitrary

At one time, most vendors posted (documented) their CR Strategy but not many do any more. In Jess and CLIPS you can (or used to be able to) set whatever CRS you wanted - usually depth was sufficient for most applications.

First, for the uninitiated, let's discuss a Forward Chaining (FC) engine. In the normal FC engine all of the data are loaded into objects (either embedded or external to the engine itself) and the rules are instantiated, initialized, started, whatever you want to call it. The rules will interact with the data in a non-monotonic manner until there are no more rules left to "fire" - meaning, to execute the "then" part of the "IF - THEN" rule. This is normal FC and what has come to be called "data-driven" rulebase, which is a misnomer because all rulebased systems use data to drive the rules one way or the other.

Now, what if we use a Goal-Driven approach with a FC? In that case (what is normally done today) the first condition element (CE) of a rule would be something like "if the goal.name == (goalName) " and, due the the recency factor or the CR discussed above and elsewhere, then rules would be "clustered" into those that have the same goal name when a new goal is asserted by any rule. The "goalName" could be a String, Integer, whatever you like. This is NOT backward chaining - this is simply clumping rules together much in the same manner that you might run a sub-routine in C/C++ program. It is the same effect as using a "focus" command in CLIPS or Jess. If this were C++ or Java it would be leaving the main chain of thought to run a sub-routine that might or might not return some value but would operate on whatever objects it needed. Nothing fancy here; Goal-Driven is nothing more than regular old rulebase logic with a first CE that would follow the goal.

Now, on to true Full Opportunistic Backward Chaining: The first thing is that the objects themselves must support this by being able to report to a calling routine whether the value of the slots (attributes) are known, unknown, not known, true / false / value. If a slot is known, then the object returns the value of that slot. But now we have two more wrinkles in the system in that of "not-known" - meaning that we do not know the value and we have not tried to find the value - and "unknown" - meaning that we have tried to find the value and we could not find the value. (Sometimes these are reversed in meaning but, regardless, you should get the idea.) I have always used the rule, "unknown and unknowable" to mean that we cannot find the value. If it were the other kind of state system, then I would use "not-known and never-knowable."

Here is where the wicket gets a bit sticky: If the value is not-known, then there must be some mechanism that will allow the rulebase to try and find the value. This is normally done via question handlers that will either ask the user to enter a value or go back to the database for an answer. If the answer can not be found, then the status of the slot (and the object) is changed to unknown. If this is an AND, NAND, XOR, NXOR gate, it forces the whole object to become unknown. If the object is an OR or NOR gate then other slots have to be checked until all return unknown and then the entire object is unknown.

The bottom line here is that the engine itself must generate the goals to find the value (and state) of the slots, not the programmer. This CAN be done with a forward chaining engine IF and ONLY IF the engine is programmed to do this. Haley (at one time) said that the Haley Expert Rules engine did this for you and OPSJ at one time did this for you. I'm not sure that either does it any longer since it does tend so slow things down if you don't need this.

Why would you need FOBC? Mostly for problems involving diagnostics (medical, instrumentation, processing plants, etc.) or configuration (manufacturing, computers, etc.) where you need to find all of the possibilities for your system. As you can see, this gets to be quite complex with many objects but if answer can be found with just a few backward chains, then the result would be much faster than using a FC rulebase or a "Goal-Oriented" FC rulebase.

SDG
jco