🚀 go-pugleaf

In article <1229@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:
>[...] When I look at the logic, I find it's doing the same
>analysis over and over for certain legal conclusions that are really
>"facts" for other rules to deal with. For example:
>	related(Taxpayer1, Taxpayer2) :-
>		tptype(Taxpayer2, corporation),
>		controls(Taxpayer1, Taxpayer2).
>
>Now, "controls" can be viewed as a fact when considering whether
>T1 and T2 are related, but actually it's a predicate that takes a
>whole lot of analysis (in its simplest incarnation, it looks for all

Using assert and retract as a caching mechanism for inferences has far
reaching implications.  What you really want to say is: in this fiscal year, A
controls B, but your are telling this using a predicate (assert) that really
means "It is a theorem that A controls B".

Under the logical interpretation, what you have asserted in one execution
should be present in the next execution of your program.  This would break
under your use of 'assert', because what is true in one fiscal year may not be
true in the next.

You may know that all information is related to only one fiscal year and,
under that assumption, you may convince yourself that no undesirable inference
will occur because of your extra assertions.  But I consider this to be
'programming' if the assumptions made (about time, say) are not or cannot be
put as axioms in the knowledge base. Furthermore, your reasoning probably
requires knowledge of the underlying implementation of 'assert'

Happy new June!
-- 

Jean-Francois Lamy	        CSNet: lamy@ai.toronto.edu
Department of Computer Science 	EAN:   lamy@ai.toronto.cdn
University of Toronto          	ARPA:  lamy%ai.toronto.edu@csnet-relay
Toronto, Ontario	       	UUCP:  lamy@utai.uucp
M5S 1A4                        	       {ihnp4,decvax,decwrl}!utcsri!utai!lamy