RE: RIF Core shortened

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 Saturday, 15 November 2008 08:04:49 UTC