tag:blogger.com,1999:blog-5869426.post4213099232899614809..comments2020-06-06T14:53:35.943+01:00Comments on Drools &amp; jBPM: Synasc 2007 slidesMark Proctorhttp://www.blogger.com/profile/03304277188725220501noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5869426.post-90772153577502039332007-10-27T16:13:00.000+01:002007-10-27T16:13:00.000+01:00In order to properly implement temporal logic, a c...In order to properly implement temporal logic, a concept of modal operators needs to enter into the picture, because the relationships between the strong and weak temporal operators are none other than different modes of truth assertion. This is the track that I've been focused on since I parted on good terms with the Drools team some years ago. I'm certainly glad to see that Drools is looking toward temporal logic, but as it constitutes only one special case of modal logic, I wonder whether they have considered creating a general framework for nontrivial modes of truth assertion? The follow-up question is whether RETE is sufficiently robust to operate in a mixed-modal assertion lattice? My research indicates that it is not, and that new foundational algorithms need to be devised for these purposes. I look forward to carrying this discussion on with Mark and the other guys at Drools.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5869426.post-30068142534916946082007-10-02T00:07:00.000+01:002007-10-02T00:07:00.000+01:00Some random thoughts about using rule languages to...Some random thoughts about using rule languages to express temporal logic. I've been thinking about this quite a bit the last few weeks/months and it's become apparent to me that rule languages are ill suited for CEP/ESP. By that I don't mean RETE is inappropriate. I think RETE with temporal extensions is more than capable of handling CEP/ESP logic.<BR/><BR/>By express, I mean having a language that makes it easy for an user to succintly communicate their ideas. the user could be a programmer or analyst. Using the existing semantics feels awkward to me and it leaves a lot of room for interpretation, which means it's doomed to failure. Since many rule languages are inspired by CLIPS, they've all inherited the same limitations.<BR/><BR/>An user should be able to write a rule like this, without having to know if it uses a particular feature in a rule engine.<BR/><BR/>"if a matching order is found within 4 hours or 2 hours before the market closes, then execute the trade."<BR/><BR/>To the rule engine, this is two rules. One has a absolute expiration time of closing time minus 2 hours. The second has a relative time of 4 hours. Both of these can be expressed better through temporal facts and not through collect, accumulate, or a rule specific time window.<BR/><BR/>The more I think about it from a temporal logic perspective, streamSql and rule languages are horrible for expressing temporal concepts succintly.<BR/><BR/>The limitation I see with hardcoded time window in a rule is that it's brittle and forces the systems to deploy/redeploy/undeploy rules.<BR/><BR/>The problem can be divided into two parts. The first is extending RETE to support temporal logic. The second is designing a language that is better for expressing temporal logic.<BR/><BR/>Even though accumulate and collect both can be used to simulate temporal logic, I think it would be more optimal to extend RETE with special temporal nodes. Both accumulate and collect were not designed for temporal logic, and will eventually create more problems than it solves.<BR/><BR/>Some random food for thought.woolfelhttps://www.blogger.com/profile/13814445471254728002noreply@blogger.com