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 14:29:13 -0500
To: Christian de Sainte Marie <csma@ilog.fr>
Cc: RIF WG <public-rif-wg@w3.org>
Message-ID: <28329.1199993353@cs.sunysb.edu>


> Michael Kifer wrote:
> >>
> >>How do commonly used implementations of basic logic rule languages 
> >>handle the case [...]
> > 
> > Usually they issue an error. But they do not have a model theory for it,
> 
> Which is why I am somewhat insistant that we should consider doing what 
> I call "not giving a semantics to error" and that Bijan calls (certainly 
> more appropriately, since you understand him :-): "support builtins 
> syntactically but say that their semantic  on error is implementation 
> dependent" [1] (Bijan: yes, this is what I propose as a third alternative).

What is "semantics on/of error" and what is "error"?
I propose to give semantics without errors (pun intended) and then deal
with "errors" at the compliance level.


> > and they do not write a document for W3C saying "this is THE semantics of
> > ...".
> 
> But we do not _have_ to write a document for W3C saying "this is THE 
> semantics of..."!
> 
> We have to write for W3C a "technical specifications of [a rule] 
> interchange format, suitable for implementers of rule engines and rule 
> language translation software", where "this format (or language) will 
> function as an interlingua into which established and new rule languages 
> can be mapped, allowing rules written for one application to be 
> published, shared, and re-used in other applications and other rule 
> engines".

We have to give semantics to the BLD dialect. Did we agree to this?
If not, then we have to go back 1.5 years and start from scratch.

> To me, this seems perfectly compatible with not supporting a specific 
> semantics for error if there is not one that is prevalent in current 
> implementations.
> 
> This is why I insist that we should consider alternative (c) in addition 
> of (a) and (b):
> 
> (c) to support builtins (and evaluated functions and predicates in 
> general) syntactically, and semantically within their domains of 
> definition, but to leave their semantics of error implementation 
> dependent. (Maybe requiring that the error not be processed silently, 
> though).

Christian, you are missing something very trivial, but fundamental.  Did we
agree to give a model theory to BLD? If we did, then we have to give it.  A
model theory is incompatible with what you call option (c).  As is, the
above paragraph is not a model theory but a model-theoretic gobbledeegook.
If you can turn it into something formal - fine. If not, let's not waste
time.

> I understand that alternative (c) would not work if we were chartered to 
> specify a rule language, but that is one of the benefits of having to 
> specify "only" an interchange format that it works for us!

What do you mean by "works for us"? Who is "us". I may be misinterpreting
you, but it seems that you are proposing to throw out most of what has been
done and go back some 18 months. 


	--michael  

> 
> Christian
> 
> 
Received on Thursday, 10 January 2008 19:29:31 GMT

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