RE: RIF Core shortened

Hi Garry,  

 

Right, this task stretches us a little too much... :-/ 

I am happy to support your proposal "allow # and ## in Core in rule
conditions and *unconditional* rule conclusions" as long as in the
"unconditional conclusions" we limit ourselves to the creation of new
objects, not including the modification of the class of an already
existing object. 

 

 

 Patrick. 

 

 

 

-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: lundi 17 novembre 2008 02:23
To: Patrick Albert
Cc: kifer@cs.sunysb.edu; Dave Reynolds; Boley, Harold; Adrian Paschke;
Axel Polleres; RIF WG
Subject: Re: RIF Core shortened

 

Hi Patrick,

 

Thanks for your comments.  I think you are right that a 

PRD->typical-PR-engine translator really cannot reasonably implement 

unrestricted membership formulas.  I told you trying to have a useful 

Core was making me schizo :-)

 

Can we allow # and ## in Core in rule conditions and *unconditional* 

rule conclusions?  Would that make everyone happy?

 

Patrick Albert wrote:

> Hi Garry, 

> 

> 

> I don not think, that your proposal of allowing asserting a new class
to

> an already existing objects fits the PRD. 

> 

> Some PR systems have supported this feature, but it is in fact quite

> complex because such systems have a strong interpretation of the

> instantiation -- much more than asserting the belonging to the new

> class. Inheritance is taken into account as well as the management new

> attributes, the new types of the existing attributes, the changes in
the

> domain, and eventually the rules that become applicable to the object

> because of its new class and should be triggered. 

> 

> In some systems, such as constraint-based PRs, changing the class of
an

> object would trigger an failure, while others would just don't care. 

>  

> 

> So though it might be seen a limitation -- which indeed it is --

> not changing the class of an object is a core feature of PR systems.

> 

> What we can expect to see is that such features will happen at some

> point in time, and will probably be implemented in conjunction with
OWL

> or its successors if any.

> 

> About the translators, except for the trivial cases, there will be a

> need for a DSL to declare the mapping between non trivial constructs
of

> the dialects. 

>  

> 

> 

>  Patrick. 

> 

> 

> -----Original Message-----

> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]

> On Behalf Of Gary Hallmark

> Sent: vendredi 14 novembre 2008 22:07

> To: kifer@cs.sunysb.edu

> Cc: Dave Reynolds; Boley, Harold; Adrian Paschke; Axel Polleres; RIF
WG

> Subject: Re: RIF Core shortened

> 

> 

> I've been schizophrenic on this issue.

> 

> I don't know how to map (schema valid) xml documents to frames without
#

> 

> and ## in rule heads (although I prefer those rules to have no bodies,
I

> 

> think that is harder to nail down). 

> 

> So I propose that core allow # and ## everywhere that BLD allows them.

> Equality is allowed in the body only (for core).

> 

> Because most PR engines don't allow # and ## to be asserted except
when 

> the object is being created, the RIF translator may need to map # and
##

> 

> to a union of some external predicate and a logical predicate.  I feel


> that PR translators have to bear some small reasonable burden in order


> to get non-trivial overlap with BLD, and this looks to be part of that


> burden.  I'm willing to bear it, but other folks may not.

> 

> Michael Kifer wrote:

>   

>> On Fri, 14 Nov 2008 12:24:42 +0000

>> Dave Reynolds <der@hplb.hpl.hp.com> wrote:

>> 

>>   

>>     

>>> Hi Michael,

>>> 

>>> This looks fine.

>>> 

>>> I've done a set of very minor edits:

>>>    - standardized the "safely conformant" nomenclature across the

>>>       

> document

>   

>>>    - fixed a couple of minor formatting problems

>>>    - deleted a reference to external frames

>>>    - rephrased the links to BLD examples to give the numbers of the 

>>> referenced example to make it possible to understand the link when 

>>> reading the printed version.

>>> 

>>> Looking at the issues you have noted:

>>> 

>>> ** ISSUE: Did we really decide that ## cannot occur at all or that
it

>>>       

> 

>   

>>> can occur only in the rule bodies?

>>> 

>>> The former. To be more precise we discussed this in a Core telecon

>>>       

> and 

>   

>>> had two proposals from that:

>>> 

>>> PROPOSED: RIF Core will not include subclass (##)

>>> PROPOSED: RIF Core will include member (#) but syntactically

>>>       

> restricted 

>   

>>> its use in rule bodies. Note that in RIF-RDF the equivalent property


>>> rdf:type would still be permitted in rule heads.

>>> 

>>> However in the whole-WG telecons we passed the second of those but I


>>> don't think we ever formally voted on the first so technically I

>>>       

> guess 

>   

>>> it is still open.

>>>     

>>>       

>> I may have slept thought this, but I vaguely recall that there were

>>     

> objections

>   

>> even to removing it from the heads. I think Gary or somebody else

>>     

> pointed out

>   

>> that we have no way of specifying a simple subclass hierarchy without

>>     

> being

>   

>> able to use :: in the facts.

>> 

>>   

>>     

>>> ** ISSUE: What was decided about external functions?

>>> 

>>> In the same RIF Core telecon we had:

>>> 

>>> PROPOSED: Core should keep unrestricted equality and external

>>>       

> function 

>   

>>> and predicate calls in rule bodies and keep external functions calls

>>>       

> in 

>   

>>> rule heads.

>>> 

>>> I haven't managed to find the formal WG adoption of that.

>>>     

>>>       

>> Then the current syntax needs fixing, as it does not allow that.

>> 

>>   

>>     

>>> ** ISSUE: Need to give EBNF for RIF-Core

>>> 

>>> Isn't that section (2.6) an EBNF for Core? Is there some specific

>>>       

> error 

>   

>>> in that EBNF?

>>>     

>>>       

>> I don't see how this EBNF enables the use of external functions.

>> 

>> michael

>> 

>>   

>>     

>>> Michael Kifer wrote:

>>>     

>>>       

>>>> I had couple of spare hours and decided to finish my action item

>>>>         

> ahead of

>   

>>>> time to surprise everybody.

>>>>  As agreed in today's telecon, I have shortened the core

>>>>         

> significantly.

>   

>>>> So, it is now unabashedly dependent on RIF-BLD, but it is now much

>>>>         

> easier to

>   

>>>> see what is going on.

>>>> 

>>>> The old text and its history has been moved to

>>>> http://www.w3.org/2005/rules/wiki/Core-alternative

>>>> 

>>>> I did not touch the overview. In the EBNF sections I only made

>>>>         

> references to

>   

>>>> the examples (without repeating them). The EBNF section requires

>>>>         

> drastic

>   

>>>> cuts and the actual EBNF needs to better match the core. (I forgot

>>>> whether we decided to keep external functions. If not then ok.)

>>>> In particular, in RIF-Core there is no need to repeat the syntax
and

>>>>         

> most of

>   

>>>> the explanations. In fact, the material in this section is even

>>>> longer than in BLD itself -- a stale pasted copy from an older BLD

>>>>         

> document.

>   

>>>> The conformance section also needs shortening. For instance, it is

>>>>         

> not clear to

>   

>>>> me why we should keep much of Section 5.2. Maybe we could again

>>>>         

> refer to BLD?

>   

>>>> Section 6 (PRD) hasn't been touched. It requires much attention
from

>>>>         

> Gary and/or

>   

>>>> Adrian.

>>>> 

>>>> michael

>>>>       

>>>>         

>>>     

>>>       

> 

>