Re: [TED] Action-188, ISSUE: production rule systems have "difficulty" with recursive rules in RIF Core

> > > In particular, you didn't
> > > address my attempts at defining what you call "conformance" more precisely
> > > and also Frank's arguments.
> > 
> > Perhaps I missed them, although I think I read everything in this
> > thread.  Pointer?
> 
> This was the main point of the message to which you were replying.
> 
> Anyway, here it goes again.
> 
> Conformance is to be defined by a semantics-preserving 1-1 mapping from a
> rule system (RS) to a (possibly subset of a) RIF dialect (RIFD).

Can you rephrase that into a constraint on products?  That's where you
lost me the first time through. 

> To avoid a
> misunderstanding, 1-1 means into, not onto. The mapping may only map a
> subset of the RL for a whole number of reasons.

I'm okay with saying only a subset needs to be mapped -- every rule
language is likely to have features that go beyond the nearest RIF
Dialect -- but I think users need to be warned (at least in "standards
mode") when they create rules outside the mapping.  Are you okay with
that?

> To exchange a ruleset, R, between RL1 (with mapping f1) and RL2 (with mapping
> f2), you do inverse-of-f2(f1(R)). If f1(R) is not in the co-domains of f2, yo
> u
> get an exception.
> 
> If the vendors of RL1 and RL2 have sufficiently good technical people, then
> they should be able to describe precisely what the co-domains of f1 and f2,
> then it would also be possible to describe the co-domain of f1 composed
> with the inverse of f2. In this way you, as a user, would know what you can
> or cannot exchange. But if those vendors don't have good technical people
> then no big deal. Getting an exception is good enough.

I don't think getting an exception is good enough.  I think users need
to know when they buy a product which RIF dialects it fully implements.
You'd agree, at least, that users would like that, right?   (Better to
know the limitations at purchase time instead of run-time...)

   - Sandro

Received on Monday, 18 December 2006 18:56:43 UTC