W3C home > Mailing lists > Public > public-rif-wg@w3.org > December 2007

Re: Reminder: pending discussion "membership" (pending discussion on ACTION-350)

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Sun, 09 Dec 2007 13:24:50 -0500
To: "Paul Vincent" <pvincent@tibco.com>
Cc: "Dave Reynolds" <der@hplb.hpl.hp.com>, "Public-Rif-Wg \(E-mail\)" <public-rif-wg@w3.org>
Message-ID: <7929.1197224690@cs.sunysb.edu>


> > We have agreed at the last F2F that BLD is **not** core and that a
> profile
> > mechanism should be developed. The core will be a subset of RIF BLD.
> 
> Michael: just to be clear :) I fully agree with the following facts
> - BLD is not core
> - a profile mechanism should be developed
> ...although I think the statement "core is a profile of BLD" will lead
> to problems (ie a dialect should always be considered as a development
> of Core, even if in this case we are considering extricating core from
> BLD). 

Why would there be problems?
At the f2f it was discussed that

1. A dialect should be something that makes sense from the logical and
   practical point of view.
2. Core is only about a consensus on what minimum should be required.
   It would set the bar low, but too low for many people. If we just define
   the core, we will have very little to show for the 2.5 years of our
   work, and it would be useless for a lot of systems.
3. The profile mechanism makes it easy to define various subdialects.
   One does not need to repeat the syntax and semantics formally ---
   believe me it is a lot of work even for something relatively simple like
   BLD --- and instead just requires people to specify the features to be
   thrown out and constraints on the remaining people.


	--michael  


> Dave: would something like
> - BLD includes a notion of class membership
> - Core does not include a notion of class membership
> ...solve your objections? 
> Or would that depend on other differences between Core and BLD? 
> Or is there a requirement for 2 dialects: one with a strong notion of
> including data models (say BLD) and a profile thereof that excludes such
> notions? 
>  
> 
> Paul Vincent
> TIBCO | ETG/Business Rules 
>  
> > -----Original Message-----
> > From: kifer@cs.sunysb.edu [mailto:kifer@cs.sunysb.edu]
> > Sent: 07 December 2007 17:37
> > To: Paul Vincent
> > Cc: Dave Reynolds; Public-Rif-Wg (E-mail)
> > Subject: Re: Reminder: pending discussion "membership" (pending
> discussion
> > on ACTION-350)
> > 
> > 
> > 
> ...
> > >
> > > Most PR engines are implemented in a 3GL / import XML (etc) into a
> Java
> > > representation, which allows them some flexibility over object model
> > > definitions. So subclassing an XML-derived class is not a big issue.
> But
> > > it is NOT of interest to try and standardize these mechanisms (I
> > > suggest) in RIF. Hence I fully concur with Christian (PRD should not
> > > bother with such a mechanism).
> > >
> > > However, I can fully understand why an AI-type / knowledgebase
> > > application would want to include / embed schema info into its
> > > knowledgebase. Its just that this is not "core" to "RIF" IMHO.
> > 
> > We have agreed at the last F2F that BLD is **not** core and that a
> profile
> > mechanism should be developed. The core will be a subset of RIF BLD.
> > 
> > 
> > 	--michael
> > 
> > 
> > > Paul Vincent
> > > TIBCO | ETG/Business Rules
> > >
> ...
> 
> 
> 
Received on Sunday, 9 December 2007 18:28:51 GMT

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