[rules-dev] Re: Interval-based vs. Time-based semantics

[Matthias Groch]

Edson,

> Edson Tirelli <tirelli <at> post.com> writes:

>  Matthias,    I agree with you and I say interval-based semantics is a go.
I also agree on representing point-in-time events as events with 0 duration.

Good to hear :).

> Another question that bothers me is whether you also intend 
> to support > different "consumption modes" like 'recent', 'chronicle' or 
> 'unrestricted' > (see paragraph 4.4. in the paper I sent to you; i.e. page 11 
> + 12 of the pdf). > For our use case, 'recent' context is probably best suited 
> however at least 'unrestricted' should be supported too (e.g. in sliding 
> windows, no events can be discarded). What do you think?   My understanding
is that the unrestricted mode is the default operation mode of the engine, and
as such, we get it for free. 

Right.

> My understanding is also that you can constrain the matching patterns to
"emulate" recent and chronicle modes. So, my suggestions is we leave a more
transparent support to "recent" and "chronicle" modes to a second phase, 
> i.e., as soon as we have all the basics working in the engine.

Agreed. In my tests this sometimes led to an unintended behaviour, however it's
pretty straight-forward to "manually" implement 'recent' mode in a rule;
basically it's just a check whether there's no "newer" event (in terms of the
occurrence date) than the current one using the 'not' pattern. So for the
beginning, having the unrestricted mode (which is the most general one and which
we get for free) should be enough.

>   Regarding the ability of the engine to work with non-javabean facts, it
depends on a feature that is in our "to do list": pluggable extractors. The idea
is that you can configure the engine to use different strategies to obtain a
value from a fact. Example:
> Cheese( type == "stilton" )   The above pattern makes the engine to use an
extractor to read the value of "type" from the fact. As it is today, the engine
uses a "hardcoded" extractor that knows how to read that attribute value from a
javabean. What we need is to implement support in the engine to use a different
extractor configured (and eventually provided) by the user. So, if Cheese is a
JMS message, an XML element, an Ontology instance, or a CSV record in a file,
does not matter for the engine, as long as the extractor can "read" that value
and provide it to the engine.
>     So, not supported yet, but we need that too for our next major release.    

Thanks for clarifying that.

Regards,

Matthias