RE: RIF: soundness and semantics --> functional requirements?

Regardless of the CSF/goal/requirement debate, a design constraint is not a requirement. If I could prove that rule interchange could be achieved best with wet pasta, would that make wet pasta a requirement? I think not!

The act of rule interchange (from the producer and consumer perspective) has no requirement on the design of RIF. Ergo, statements about the design of RIF are not RIF requirements per se. They may well be design/functional requirements though. This is important to differentiate IMHO.

Paul Vincent
Fair Isaac Blaze Advisor Product Manager

> -----Original Message-----
> From: Paula-Lavinia Patranjan [mailto:paula.patranjan@ifi.lmu.de]
> Sent: Thursday, May 18, 2006 8:51 AM
> To: Vincent, Paul D; public-rif-wg@w3.org
> Subject: Re: RIF: soundness and semantics --> functional requirements?
> 
> Vincent, Paul D wrote:
> > The *requirement* is interchange, and a *solution* to achieve that would
> be a declarative semantics interchange format.
> >
> 
> I think that most of the RIF-lers have already agreed that interchange
> is one of our goals, so not a requirement. It might be the case that
> (technical) requirements have a 'solution' flavour, however a solution
> for meeting the requirement on semantics would be e.g. to have a
> concrete declarative semantics for sets of deductive rules.
> 
> Regards,
> Paula
> 
> > In my systems engineering days, we used the term "functional
> requirements" in order to specify the design constraints deduced from the
> requirements to guide the implementation. Generally these are the
> consensus / obvious deductions from the (business or high level)
> requirements - such as if a data store is required then the functional
> requirement is to use a database. Perhaps we need candidate functional
> requirements listed like this, separate from the critical success factors
> + requirements?
> >
> > Paul Vincent
> > for Fair Isaac Blaze Advisor  -- Business Rule Management System
> > @ OMG and W3C standards for rules
> >
> >> -----Original Message-----
> >> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-
> request@w3.org]
> >> On Behalf Of Francois Bry
> >> Sent: Thursday, May 18, 2006 8:21 AM
> >> To: public-rif-wg@w3.org
> >> Subject: Re: soundness and semantics
> >>
> >>
> >> ewallace@cme.nist.gov wrote:
> >>
> >> Thanks, Evans for nicely and accurately rephrasing my thougths.
> >>
> >>>> 3. In most cases, the specification of a semantics for interchange
> >>>> purposes is only possible or meanningfull if this specification is
> >>>> simple enough (ie expressible in a few words, not in ten thousand of
> >>>> lines of code) and abstract enough ("abstract" being understood here
> as
> >>>> "factoring out some aspects").
> >>>> As a consequence, simple and abstract specifications of semantics for
> >>>> RIF rules and rule sets should be a requirement.
> >>>>
> >>>>
> >>> This last bit describes a qualitative aspect of a RIF feature, rather
> >>>
> >> than
> >>
> >>> a feature itself.  I am not sure how one can compare abstractness,
> much
> >>> less understand what "simple enough" or "abstract enough" is.  Thus
> >>>
> >> while
> >>
> >>> this seems a good goal, I don't see it as a requirement.
> >>>
> >>>
> >> An interchange format to be used between rule languages L1 and L2 must
> >> have a declarative semantics in which the declarative and the
> >> operational semantics of both L1 and L2 can be mapped (or expressed)
> into.
> >>
> >> This, in my opinion, is should be taken as a requirement.
> >>
> >> This is what was meant be the poinrt 3 mewntioned above. An example
> >> might explain it better: the Stable semantics  of non-monotonic
> >> negation  make it possible to express what can be derived/computed from
> >> a XSB-Prolog rule set without built-ins. In contrast, the semantics of
> >> standard Prolog does not make it possible to declaratively express what
> >> can be derived/computed from  a XSB-Prolog rule set without built-ins
> >> (one can program it in Prolog, but this is not what a RIF streives
> for.)
> >>
> >> François
> >>
> >
> > This email and any files transmitted with it are confidential,
> proprietary
> > and intended solely for the individual or entity to whom they are
> addressed.
> > If you have received this email in error please delete it immediately.
> >
> >
> >

This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.

Received on Thursday, 18 May 2006 08:06:51 UTC