Tabled and transactional predicates

[Robert Goldman]

Today is a good day for ErgoAI coding queries!

I am writing some Ergo that captures parts of the US tax code.

That code needs to be applied to cases, which have case-specific facts.

One way of handling this is to add some case flag, and when I want to reason about a case, facts tagged with that case flag are added, and when I am done, they are removed.

This seems to have the unpleasant feature of causing "transactionality" to spread all over the ErgoAI program, doesn't it?

This kind of case-based/counterfactual/conditional reasoning seems like it would be a common occurrence in ErgoAI programming.  Is there a standard idiom for this?

[Theresa Swift]

I don't know of a \switch statement in ErgoAI, but it does seem like a good idea.  

Just to let you know, Robert, we've received some funding from the CLARA project to add probabiilistic reasoning to ErgoAI via the PITA system.  This will involve a lot of work, but I think it will be a valuable addition if we can put everything together.

--
You received this message because you are subscribed to the Google Groups "ErgoAI and XSB Users Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ErgoAI-XSB-for...@coherentknowledge.com.
To view this discussion visit https://groups.google.com/a/coherentknowledge.com/d/msgid/ErgoAI-XSB-forum/3d9ea117-8287-4e0c-b6a4-4cca4841160en%40coherentknowledge.com.

[Robert Goldman]

As far as I can tell, case-based reasoning in Ergo requires one of these approaches:

1. 1. Just load everything normally, and when you want to switch between cases, smash the Ergo process and restart.  This feels gross, but it's simple (this is what the SARA project does when translating the tax code into Prolog).
2. 2. Put stuff in modules, but then you need to pass module arguments all over the place. At this point, though, it's not side-effecting, so we can just use the tabling.
3. 3. Put tags on facts. Again, no longer side-effecting, so you can use the tabling. The down side, similar to modules, is you need to decide which predicates get the tag arguments and which don't.
3. 4. Some kind of case activation and deactivation that is accompanied by table smashing.  I suppose one could put information in the descriptor that states which facts should be deleted when a case is deleted, but I don't claim to understand table smashing.  I don't see anything in Chapter 24 ("Ergo and Tabling") that explains how to do this.

In some of the code that you (Theresa) distributed, you put tags on contextual things, but then only frames could be contextual.

It seems possible to me that one could treat cases modally, put case knowledge in modules and have a knowledge generalization meta rule (ϕ → Kϕ) -- everything that is true is true in the case world, too.

@!{caseTruth}

case(?Tag)(?x) :- ?x@?Tag.

@!{backgroundTruth}

case(?)(?x) :- ?x.

I have not tried the above and it might not work!

Since the cases we have been looking at often have facts asserted without the antecedent facts that justify them (e.g., "Mary has an eligible dependent."), I think we might want to have the case facts override the background facts:

\overrides{caseTruth, backgroundTruth}

But even doing this, there's no way for  backgroundTruth to apply rules to case facts, or at least not without explicitly phrasing all of the rules in terms of the case higher-order predicate, which seems cumbersome and because cumbersome, error-prone, since we don't have the knowledge rule Kϕ→ϕ, since the "case" modality is not the same as the knowledge modality!

Again, this kind of contextual or conditional reasoning is extremely common, so I suspect I am simply ignorant of some standard idiom/code pattern.

[Robert Goldman]

Sorry -- \switch ?

On Friday, August 7, 2026 at 8:43:42 AM UTC-5 theres...@gmail.com wrote: