RE: extensibility -> pxfim

Gary - quite true. Practically, a warning of an entailment change will
almost always cause a rejection action though. 

For example:
- contract compliance use case: if we change entailment in a compliance
rule, then the rule / ruleset / contract is not longer valid. [In theory
one could then determine if that compliance rule is significant per the
data for a particular transaction - but if you have trimmed the
significant part of the rule, that might not work!]
- medical monitoring use case: ditto

But perhaps there are other use cases for non-rejection based on
entailment changes?  

Paul Vincent
TIBCO | ETG/Business Rules 
 

> -----Original Message-----
> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: 07 November 2007 20:59
> To: public-rif-wg@w3.org
> Cc: public-rif-wg@w3.org
> Subject: Re: extensibility -> pxfim
> 
> 
> Speaking pragmatically, I'd say the following:
> 
> A RIF Document contains metadata tags and language tags that describe
> and define rules.  Metadata tags occur only within the <metadata>
> element of a RIF Document.
> For forward compatibility, a RIF System may ignore unknown tags using
a
> trim-to-fit strategy.   Trimming metadata tags never impacts the
> entailment (meaning) of the rules.  Trimming language tags almost
always
> does change the entailment of the rules.
> 
> In some cases, e.g. monotonic rule sets, it is possible to work out
> whether the entailment is larger or smaller than it should be.
Removing
> a rule or a disjunct from a monotonic rule set may reduce the
> entailment.  Removing a conjunct may increase the entailment.
> 
> A RIF System should warn the user when ignoring tags, and further warn
> about possible entailment changes when ignoring language tags.
> 
> And that's pretty much all I think we need to do for extensibility at
> present.
> 
> Paul Vincent wrote:
> > While I agree with Michael that from a pragmatic point of view, and
> > especially for an operational rule system, the only usual fallback
will
> > be a rejection, the idea of a generic extensibility mechanism for
XML
> > seems to make a lot of sense.
> >
> > So +1 to Michael (its probably not really a RIF version 1 issue)
> > And +1 to Sandro (its probably solving a wider content mgmt related
> > problem in a standard way).
> >
> > Paul Vincent
> > TIBCO | ETG/Business Rules
> >
> >
> >
> >> -----Original Message-----
> >> From: public-rif-wg-request@w3.org
> >>
> > [mailto:public-rif-wg-request@w3.org]
> >
> >> On Behalf Of Michael Kifer
> >> Sent: 07 November 2007 18:28
> >> To: Sandro Hawke
> >> Cc: public-rif-wg@w3.org
> >> Subject: Re: extensibility -> pxfim
> >>
> >>
> >>
> >>
> >> I doubt that such a general theory alone would be more useful for
RIF
> >>
> > than
> >
> >> a
> >> simple policy of rejecting documents that have new tags. It could
be
> >> useful as an XML framework for fallback mechanisms, but then the
hard
> >>
> > part
> >
> >> would be to figure out how to specialize it for RIF and make it do
> >> something non-trivial.
> >>
> >> Of course, this is just my general feeling. It is based only on the
> >> understanding that the problem is very hard.
> >>
> >> But divesting RIF from the responsibility of doing something in
this
> >> respect is a very tempting proposition :-)
> >>
> >> 	--michael
> >>
> >>
> >>
> >>> I'm trying to understand whether it makes sense to factor the
> >>> extensibility mechanism out of RIF entirely.
> >>>
> >>> As sort of a trial balloon, I've given it a name and thrown
together
> >>>
> > a
> >
> >>> skeletal editor's draft, so we can point non-RIF folks at it.
> >>>
> >>>    http://www.w3.org/2007/11/pxfim/
> >>>
> >>> I have no idea at this point where this document will go.  It
might
> >>>
> > well
> >
> >>> be discarded as silly, if no one outside of RIF is
> >>>
> > motivated/interested.
> >
> >>> But if there is enough interest from outside of RIF, it might
> >>>
> > continue
> >
> >>> and RIF might be able to divest itself of this technical work.
> >>>
> >>>       - Sandro
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> 
> --
> 
> 
> Oracle <http://www.oracle.com>
> Gary Hallmark | Architect | +1.503.525.8043
> Oracle Server Technologies
> 1211 SW 5th Avenue, Suite 800
> Portland, OR 97204

Received on Wednesday, 7 November 2007 23:46:11 UTC