I agree with Wolfgang and Peter regarding 'One of the shortcomings of Rete....',
The CEP functionality used by other Expert Systems is just managing the time slice and managing that information distro to Rete. Unfortunately some other expert systems that advertise CEP tend to bundle the feature list with the expert system itself (much like spreadsheet based rules & 'decision tables') and make it seem like their algorithm is more capable, when in fact its just open source libraries and middle-ware wrapped around a Rete. This is turn makes other expert systems seem less capable because they dont bundle in extra libraries. Not to let this go off on a tangent, i think its been well addressed at this point that Rete isn't limited. It is true that Jess doesn't automatically include a library with the functions related to CEP that you desire, but an expert system shell shouldn't automatically contain this any more than it should contain a Sudoku solver or Miss Manners ;P You just have to customize and create the functions you need. Going back to your original question, what is the problem you are trying to attempt to correct or solve with CEP and JESS? Perhaps with more detail we can guide you on how to do this with Jess. On Mon, Mar 14, 2011 at 8:48 AM, Peter Lin <wool...@gmail.com> wrote: > I read the paper when it first came out. The arguments proposed in the > paper are only applicable to rule engines that are object-oriented in > design and not applicable to expert system shells like JESS, Clips or > ART. > > The limitations are the result of the design of the rule engine and > not a limitation of the algorithm. Engines that use functional > LISP/Prolog like design do not have these limittions. Claiming RETE is > not good for CEP is a misunderstanding of RETE algorithm. Let's not > confuse the limitations of a specific product(s) with the algorithm. > > There are many ways to solve the problem that do not require having > 3600 facts. Trying to brute force a solution is neither elegant or > efficient. > > On Mon, Mar 14, 2011 at 11:08 AM, Tromm, Martijn > <martijn.tr...@ordina.nl> wrote: >> In CEP you may need sliding time windows. If you want to check for >> combinations of events or omissions of events in every time window that a >> particular triggering event belongs to, let’s say we have a time-window of >> one hour and need to update every second, then you have 3600 facts that >> match just one event. With many events and many event-patterns that need to >> be checked (subscriptions) you end up with a lot of nodes. This is >> especially problematic in a real-time setting. >> >> Also you may need to consider (and thus store) a history of states of the >> rete network. This is not natively supported. >> >> The following article >> http://www.rn.inf.tu-dresden.de/uploads/pikm32-walzer.pdf describes the >> problem pretty well and suggests an extension on the rete algorithm to deal >> with a sliding time window operator. >> >> I am curious if there are other implementations or workarounds in Jess that >> work well. >> >> Martijn >> >> >> >> But this is not a "Rete" issue. Rete is about managing facts for rules >> containing patterns that result in boolean values. You can invent any number >> of relational operators; they are just frontent syntactic sugar where >> otherwise you have to use a call to a boolean function. >> >> -W >> >> On 14 March 2011 15:29, Tromm, Martijn <martijn.tr...@ordina.nl> wrote: >> >> Hi, >> >> Does anybody have any experience with complex event processing in Jess? >> One of the shortcomings of Rete is that there is no native support for >> temporal operators besides matching on timestamps and checking time >> differences >> >> >> >> Disclaimer >> Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd >> voor de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u >> verzocht de afzender te waarschuwen en dit bericht met eventuele bijlagen >> direct te verwijderen en/of te vernietigen. Het is niet toegestaan dit >> bericht en eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar >> te maken, op te slaan of op andere wijze te gebruiken. Ordina N.V. en/of >> haar groepsmaatschappijen accepteren geen verantwoordelijkheid of >> aansprakelijkheid voor schade die voortvloeit uit de inhoud en/of de >> verzending van dit bericht. >> >> This e-mail and any attachments are confidential and are solely intended for >> the addressee. If you are not the intended recipient, please notify the >> sender and delete and/or destroy this message and any attachments >> immediately. It is prohibited to copy, to distribute, to disclose or to use >> this e-mail and any attachments in any other way. Ordina N.V. and/or its >> group companies do not accept any responsibility nor liability for any >> damage resulting from the content of and/or the transmission of this >> message. > > > > > -------------------------------------------------------------------- > 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. > -------------------------------------------------------------------- > > -- V/R -Socrates Frangis -Mathematician & Software Engineer -------------------------------------------------------------------- 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. --------------------------------------------------------------------
