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
>>>>       
>>>>         
>>>     
>>>       
>
>

Received on Monday, 17 November 2008 01:24:03 UTC