[rules-users] drools queries: strange dependency

Davide Sottara dsotty at gmail.com
Wed Apr 17 21:59:57 EDT 2013


Hi Upal, I've been trying to model your use case in what seems the best
currently supported mode. (Un)fortunately this uncovered a little bug in
the engine,
I'll get it fixed and then I'll get back to you.

As for the fuzzy logic extension, I have a partially working PoC

https://github.com/droolsjbpm/drools-chance/tree/master/drools-chance-core

Examples are here:

 https://github.com/droolsjbpm/drools-chance/blob/master/drools-chance-core/src/test/java/org/drools/chance/kbase/fuzzy/FuzzyKBTest.java

 https://github.com/droolsjbpm/drools-chance/blob/master/drools-chance-core/src/test/java/org/drools/chance/kbase/usecases/FuzzyControllerTest.java

Some of the features we are (co)planning for 6.x will help a full
integration
Best
Davide



On 04/15/2013 09:45 PM, Upali Kohomban wrote:
> hi Davide,
>
> Your summary is quite accurate about my case.
>
> Thanks for the pointer, I will look in to hybrid chaining once I do a
> little investigation on why exactly the original problem occurred. I'm
> still having little issues with the 5.5.1 source compilation (for
> which your help worked flawlessly to get the source working, but there
> were test fails during the compilation. I will try myself to fix them
> before asking questions on that).
>
> As i said, the bigger problem is with the rules that are transitive in
> nature. Let's say there is a is_in rule which is used to derive
> spacial relationships. For instance, a concrete example
>
> is_in (uni_of_michigan, ann_arbor).
> is_in(ann_arbor, MI).
> is_in(MI, USA).
> is_in(A, C) <- is_in(A, B), is_in(B, C).
>
> I want to deduce (in general course of reasoning) such stuff as
> is_in(uni_of_michigan, USA), but if I do it in the regular drools way,
> I'd end up with a load of unnecessary deductions. This is the biggest
> problem I have. If you want a more involved concrete example, say I
> define (for the sake of simplicity)
>
> romantic(A) <- scenic(A), secluded(A).
> scenic(A) <- next_to(A, B), scenic_artefact(B).
> scenic_artefact(B) <- lake(B) or waterfall(B) or ... and so on
> secluded(A) <-  [ situated further than N km from the nearest city ]
>
> Now this last rule is where logic gives way to POJO and databases. It
> seems to me that this is the most sensible thing to do. Also, this is
> as far as I want to go at the moment. (Having known the non-boolean
> reasoning ability of drools from your mail, I can think of many ways I
> want to use it :) )
>
> I looked into your profile and saw that you have a background on the
> ontologies. Especially what you have mentioned under Drools - "Open
> Source Knowledge Integration and Reasoning Platform" in your
> university profile seems quite intersting and seems to be exactly the
> things I might be needing in the near future. I was thinking that I'll
> have to implement non-boolean reasoning using some fuzzy toolkit, if
> it becomes available with drools I'll be really happy to give it a try.
>
> If you have any material to share for further reading on your drools
> research, I'd be grateful.
>
> Thanks,
> Upali
>
>
> On 15/04/2013 03:10, Davide Sottara wrote:
>> Correct me if I'm wrong, I would summarize your requirements as follows:
>> - you need some "A-box" reasoning, but you are fine with a rule-based
>> approach
>> - the object-oriented integration Drools provides is quite convenient
>> - you have large data sets for which an opportunistic,
>> "query-oriented" approach
>> would work better rather than a fully generative "forward chaining"
>> approach
>>
>> Drools "hybrid-chaining" approach could be very useful here - I'm not
>> sure how
>> well documented it is, and how you are planning to use it, but it
>> would be interesting
>> to see one of your rules - even "stripped" of the details you don't
>> want to show -
>> to discuss the behaviour of the engine and its implications.
>>
>> I had a use case apparently very similar to yours some time ago.. I'm
>> working even
>> now on some experimental forms of rule/object/ontology integration.
>> The "trait"
>> feature might be an alternative to the explicit addition of classes
>> to objects .. it was
>> enhanced a few days ago to support updates and modifications.
>> If you have an ontology to begin with, you might also be interested
>> in the ontology -> class
>> conversion tool I'm working on even now
>>
>> Davide
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20130417/b5c17274/attachment-0001.html 


More information about the rules-users mailing list