Re: A Rule Interchange Format VS a Rule Language for Interoperability and other issues

Christian de Sainte Marie <csma@ilog.fr> wrote:
> 
> Hi Gerd,
> 
> Gerd Wagner wrote:
> >>If FOL is not a good 
> >>candidate (as Jim at least hinted), I would be interested to 
> >>understand 
> >>why; and we would also need to find out what would be a good 
> >>candidate;
> > 
> > 
> > What do you mean by FOL? Do you mean classical standard
> > (i.e. textbook) first-order predicate logic? Or do you
> > mean Common Logic, which is also a FOL (since its 
> > higher-order constructs can be eliminated)? Or do you
> > mean partial first-order predicate logic, which would
> > be more suitable, since it allows indeterminate truth
> > values, as we have them in SQL and OCL?
> 
> I had classic/textbook first-order predicate logic in mind. But, as I 
> said, any formalism with a sufficient expressiveness and a well-know 
> semantics would do ('sufficient expressiveness' meaning: most practical 
> rule languages can map onto it easily and completely enough, where 
> 'most' and 'easily and completely enough' remain to be defined; and a 
> 'well-known semantics' meaning one that the developers of software to 
> translate rules between the RIF and a specific language do not need a 
> PhD in logics to know and understand it).


"Any" in your statement implies that you know of at least one. Do you care
to share this knowledge with us? (The "classic/textbook first-order
predicate logic," which you mentioned, cannot be one of those, as was
pointed out repeatedly.)


> As regards indeterminate truth values, I do not know: could you give me 
> an example where you need indeterminate truth values to express a rule?
> 
> >>- Non-monotony: most applications/engines/rule bases that 
> >>rely on SNAF 
> >>also rely on monotonic inference/languages (well, I do not know for 
> >>most; but some certainly do). It works because they actually rely on 
> >>bounded monotony, only the bound is implicit (and, in most of 
> >>the cases, obvious: a session, an inference cycle, whatever). 
> > 
> > How would you define your notion of "bounded monotony"? 
> > It's not clear for me what you mean by that.
> 
> Oh, I have only a naive notion, here; nothing that amounts to a definition.
> 
> What I had in mind is what happens, for instance, in an application 
> where the rules operate on the data in a data base: typically, the 
> system will operate under the closed-world assumption, it will rely on 
> negation as failure within the scope of the DB, and it will infer 
> monotically, until there is a change in the database (change that can be 
> induced by the application of a rule, as in a production system, or that 
> can result from purely external events): in that case, the reasoning 
> just restarts with the new state of the DB. The inference is monotonic 
> (no defeasible inference), but bound by the next change in the DB.
> 
> Does it make sense?

No, it make no sense whatsoever. (Sorry to break it to you like that.)
Databases are ***non**monotonic. Not "bounded monotonic" (whatever it might
mean) and not "foobar/shmoobar monotonic."

I am afraid that you may need to check the definition of monotonic and
nonmonotonic logical languages. You don't need a PhD to understand them,
but it would be really helpful if we all were discussing the same thing.

These are **established** -- and very basic -- notions. They are important
because there are fundamental theoretical results about them, which state
that you cannot do certain things. The technical problems with the draft
that Dieter and I have pointed out are based on these results.


	--michael

Received on Thursday, 25 August 2005 15:21:17 UTC