Re: How core is Core?

Paul Vincent wrote:
>> From: public-rif-wg-request@w3.org
> [mailto:public-rif-wg-request@w3.org]
>> On Behalf Of Bijan Parsia
>>
>> On Jul 4, 2007, at 9:32 AM, Dave Reynolds wrote:
>>
>>> Bijan Parsia wrote:
>>>
> ...
>>>>> This subset of Core is implementable in both production rule and
>>>>> LP settings.
>>>> [snip]
>>>> I thought a sticking point was recursion?
>>> I don't think so, I believe the issue is the ability to build
>>> recursive data structures.
>> Well, I recall that the last time this discussion occurred, the point
>> was that PR systems generally didn't have recursive rules and that it
>> was not desirable to add them, e.g.:
>>
> http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0103.html
> 
> [PV>] I'm pretty sure that 100% of implemented PR-engine rules (ie
> millions) do not do "recursion" as meant* here, implying this core
> feature would simply not be used in RIF PR. A RIF PR translator could
> optionally handle a recursive rule as a recursive method.
> 
> * PR rulesets that do lots of inferencing to solve complex planning etc
> problems probably do a "form" of recursion, but in the style that
> several rules cooperate and repetitively cause new inferences to
> existing rules in order to solve a problem. Of course, they do this by
> updating data (aka asserting new facts) which cause rules, which may
> have already fired for other data, to fire again.
>>> Certainly is known (e.g. [1]) that for both datalog and semi-
>>> positive datalog[*] the production style fixed-point semantics and
>>> the declarative (minimal model) semantics coincide.
>> Sure, but that's not at all the same as saying that practical systems
>> based on one or the other approach happily coincide.
>>
>> In any case, it seems to me that if you are going to force new
>> features on a class of systems (which I do think is one
>> legitimate...if tricky...thing for a standard to do), 
> 
> [PV>] I disagree on that point, but understand why some "standards"
> efforts exist to "push the envelope" in developing technology. One could
> argue for example that the entire semantic web effort is an attempt to
> introduce a technology via a standard, rather than standardizing
> existing (ie implemented) solutions. On the other hand, few PR vendors
> would be upset to see a RIF PR++ that actually benefited users,
> providing that RIF PR existed for all the existing users. On the other
> hand, any requirements for RIF PR++ should come from said end-users (and
> use cases), not from us. 

I didn't want to reopen the recursion debate again, that wasn't the 
purpose of my original message.

No one that I'm aware of, certainly not me, is talking about pushing the 
envelope. I've no idea where this came from. This is a non-option for 
RIF so let's not get distracted by it.

I believe our default option is to say Core is not really *core* and 
continue as MichaelK has advocated. The interoperability points are then 
the dialects, not Core, and the dialects use Core but limit and subset 
it as well as extend it. This has implications for the Core design in 
terms of modularity, e.g. we should be able to separate function symbols 
from predicates to make them removable by dialects. That's why the issue 
is relevant now.

The tone of the discussion on the telecon (and of most of the previous 
email discussion on this from last year) was that the alternative of a 
reduced Core which did give more interoperability would be so brain dead 
limited to not be of interest to anyone. There was an implicit action 
from the telecon to propose any counter evidence to that.

My counter evidence is that in terms of RDF rules there are at least two 
languages - N3 and JenaRules - which have had significant use over 
several years and could more or less fit within such a reduced core. At 
present N3 has both production engine implementations (cwm, Pychinko) 
and a goal-directed LP style implementation (Euler). Likewise JenaRules 
has both a RETE-based production implementation and an SLG-WAM (without 
negation) implementation.

My only point was that whilst datalog + builtin predicates + RDF 
compatibility is indeed a very limited language that there are some 
communities that might find even such a limited interoperability point 
better than nothing.

I'm not saying this is a compelling case, it is not. I'm simply saying 
that the intersection is not *completely* useless to everyone.

This thread has turned into a discussion on whether even that reduced 
core is mutually implementable between LP and PR. That may not be the 
productive place to focus since the question at hand is the utility of 
it (and I expect it to fail at that hurdle and not need to worry about 
the rest of the course :-)).

Certainly pure datalog is mutually implementable, that's what the 
equivalence theorem tells us. At least it tells us that the production 
rule operational semantics correctly implements the logical semantics 
(which is the direction most people have been worried about), it doesn't 
preclude particular engines with limited search strategies like prolog 
non-terminating.

Clearly with builtin predicates then models are no longer necessarily 
finite (e.g. the factorial example) so you can get differences in 
termination. I don't think that would be a fatal problem for 
interoperability in practice and cite the existing two datapoints as 
(circumstantial) evidence. Certainly over many years of use of JenaRules 
I've never seen a user get caught out by implementing an infinite 
predicate in the LP engine and then expecting it to work in the PR 
engine. This is because in the RDF rule setting it is extremely common 
to essentially ask for the whole deductive closure so such rules are not 
normally of interest in the first place. Interoperability over rulesets 
with finite minimal models would be just fine here.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 5 July 2007 09:25:39 UTC