[rules-users] drools queries: strange dependency

[Davide Sottara]

I created a test case which shows a combination of traits+BC

http://pastebin.com/Wrq6Hj5L

it's pending a tiny but critical bug fix in core, so it won't be
"officially" available
until early next week.

What essentially happens is:
- dynamic traits are used to "inject interfaces" to a class - it's
stronger than simply
storing the class literal in a field (which it does anyway), because it
now allows to
use the object through the newly added interface.
I am working on a way to derive the interfaces - and some classification
rules -
directly from an ontology
- BC is used to resolve the transitive queries.
Consider that queries are "LHS" elements, so they are evaluated as
tuples are being
propagated.

If you run the example with the string "Como", it will look for a **
Country **
that the place called "Como" is also in (transitively)

The last pattern in the rule is redundant - for test purpose only - and
is remarking
that the returned Country is actually Italy :)

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/20130419/4bbba935/attachment.html