Fork me on GitHub
#clara
<
2018-06-27
>
mikerod00:06:30

@jeremy642 I believe what you are referring to was a bit of an experimental project and not actively maintained.

mikerod00:06:05

@tony.kay you can provided collections of rule structures to mk-session. It doesn’t only accept namespaces. You can also define a var that holds a collection of rules and give it metadata :production-seq. So that single var name can be passed.

mikerod00:06:18

Different ways to do things. Depending on your goals.

mikerod00:06:01

However sometimes it can be fine to combine into larger rule sets. Rules that don’t match facts won’t contribute much to runtime.

tony.kay00:06:21

Ah, I misunderstood how mk-session worked…my bad

mikerod00:06:10

No problem!

jeremy64202:06:43

@mikerod Thanks

jeremy64217:06:58

I have a bunch of rules that derive some final state fact. What I run into is that multiple rules might match and in the end I get multiple results. So in the standard decision tree, there is order to the final state precedence. Would it be appropriate to add a priority property to these final state results and then query on that priority to narrow it down to a single result?

mikerod17:06:21

@jeremy642 that is one approach

mikerod17:06:33

I think I’ve answered variations of this question a lot of times, but don’t think it’s saved anywhere

mikerod17:06:43

you can prioritize rules by building a tiered structure to them

mikerod17:06:49

or you can let them all fire

mikerod17:06:55

insert some “intermediate fact”

mikerod17:06:13

then have 1 more rule to accumulate all “intermediate facts” and insert your final fact based on the aggregate of them

mikerod17:06:27

I can give examlpes in a bit if needed

jeremy64218:06:36

Thanks. I'll check it out and play with it.