W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2008

Re: model theory of error

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Thu, 10 Jan 2008 13:04:03 -0500
To: Bijan Parsia <bparsia@cs.man.ac.uk>
Cc: Christian de Sainte Marie <csma@ilog.fr>, RIF WG <public-rif-wg@w3.org>
Message-ID: <23611.1199988243@cs.sunysb.edu>


> On 10 Jan 2008, at 14:49, Michael Kifer wrote:
> 
> >> Michael Kifer wrote:
> >>>
> >>> It is clear like mud.
> >>
> >> Ok...
> >>
> >>> You still fail to understand that we are supposed to
> >>> give formal semantics: model-theoretic, denotational, operational  
> >>> in that
> >>> order.
> >>
> >> Let me try another angle to attempt to get my message through.
> >>
> >> How do commonly used implementations of basic logic rule languages  
> >> (e.g.
> >> various implementations of Prolog, datalog, whatever) handle the  
> >> case of
> >> evaluated functions or predicates when some argument is out of there
> >> domain of definition?
> >
> > Usually they issue an error. But they do not have a model theory  
> > for it,
> > and they do not write a document for W3C saying "this is THE  
> > semantics of
> > ...".  They give the semantics in conference papers and do not include
> > builtins in it.
> 
> Although, see:
> 	http://citeseer.ist.psu.edu/apt92theory.html

Thanks Bijan for pointing this out. But...
This paper does not invalidate what I said. First, it was written after the
fact to explain the behavior of certain builtins. Second, it still does not
give the exact semantics for Prolog builtins.  I did not read it carefully,
but it seems clear that the semantics of Apt does not deal with errors. It
just treats them as false. This is not how Prolog works.

> The issue of course is how to describe *existing* systems correctly.  
> I think that's very hard (and probably would have to look for  
> inspiration at programming language semantics like domain theory).
> 
> However, as I understand it, Michael is offering a "sensible default"  
> not a hard requirement. One way to think about it is if you had to  
> deviate from your system's *actual* error raising behavior, what's  
> the most sensible alternative? Consider sensibility along the  
> dimensions of implementability, user surprise, etc.
> 
> So, let's say I have a production rule system (R) which adds an error  
> tuple to the WM on errors and a Prolog system (P) which throws an  
> exception. Now suppose I have a rule set, K, that I developed with R  
> in mind. Suppose it is syntactically RIF representable but uses built- 
> ins. Consider the three scenarios:
> 
> 1) If I write K out to K(rif) and read it back into R, I should get  
> the same answers from R whether I query K or K(Rif). Including when  
> there are errors.
> 
> 2) If I write K out to K(rif) and read it in to P, I'll get different  
> answers, cause sometimes I'll never get an answer to
> 	?- error(X, ThrownBy, Message)
> 
> 3) If I write K out to K(rif) and read it into P or to K *and flip  
> the switch to use option (a)* semantics, then presuming both systems  
> are sound and complete for RIF + (a), they'll return the same answers.
> 
> If P or K don't have that switch to flip, then they are not ever  
> compliant *with that part of rif* and that will be visible in their  
> conformance profile. If you write K out to K(rif) then you are not  
> ensured to get exactly R's behavior in *any* RIF compliant system,  
> but if R's semantics eventually got speced out, one could add it as  
> an option.
> 
> So, I think Christian and Michael, if they disagree, disagree on how  
> the compliance/conformance stuff works.

Christin says that we should hand-waive in defining the semantics, while I
am saying that we should hand-waive in defining compliance.

The result is pretty much the same, but the difference is big: people
expect that the semantics is formal and the compliance clause is not.



	--michael  


> Cheers,
> Bijan.
Received on Thursday, 10 January 2008 18:04:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:44 GMT