Re: [Arch] Action 319

Dave Reynolds wrote:
> 
> Looks great to me Axel, very helpful. A couple of comments/questions ...
> 
> Axel Polleres wrote:
> 
>> Dialect1: For Dialect1 we need a syntactic condition over the
>>    ruleset for being stratified. Sine this is not a condition which
>>    we can "express" in asn06, I could use the LP-style constraint
>>    approach, proposed during the one but last f2f, see:
>> http://lists.w3.org/Archives/Public/public-rif-wg/2007Feb/att-0083/RIFRAFOntology.pdf 
> 
> Seems like a good way to formally express the constraints in the 
> specification.
> 
> [I don't think it would be needed at runtime since any stratified 
> reasoner would already have stratification checking built in and would 
> be able reject an un-stratified ruleset.]

agreed. It is more a way to formalize, what a condition like 
stratification means. and it could be nice that we could use RIF like 
constraints and rules to express these.

>> Dialect2: For Dialect2, I need to restrict all uses of naf to wfnaf.
>>
>> Dialect3: For Dialect3, I need to restrict all uses of naf to smnaf.
>>
>>
>> I could think of RIF Core as Dialect0 here, whereI need to restrict
>> CONDITIONS not to contain any naf.
>>
>> I could think of a super-dialect 4 which though has an unclear semantics
>> mixing well-founded and stable semantics. Results on the logical 
>> formalisation of both, stable and well-founded negation under one 
>> framework [3,4,5,6,7] could serve as a basis, but I would still 
>> consider this a topic of research and not (yet) a RIF issue, since 
>> also these works cover mostly the propositional case only.
> 
> 
> An alternative is to only have NAF in the CONDITION syntax and to label 
> the whole ruleset indicating the intended semantics (well-founded, 
> stable, stratified).

As mentioned in the papers below, logically one could think of 
embeddings/combinations of both well-founded and stable semantics in one 
logical framework. This might sound awkward, but at second thought, e.g. 
if you want to combine rulesets using either, I wouldn't rule it out 
upfront.

> Originally I thought we were going to do that sort of thing via metadata 
> flags. I understand Sandro's comments to imply that we should rather 
> have different subclasses of RULESET for sets with different intended 
> semantics - RULESET-STRAT, RULESET-SM, RULESET-WF.

What I wanted to make clear, is that SMNAF and WFNAF are not the same, 
only in the stratified subset.

> That would avoid the issue of how to interpret within-rule mixing of sm 
> and wf semantics (though I'm ignorant of the literature on that).

As I said, one could consider this not relevant for us, but rather topic 
of research, but, on the other hand, as I said, knowledge combination 
might make this necessary.

>> Issues/questions:
>> -----------------
>>
>> - May I subclass classes and reuse their properties as I do here for
>> naf,wsnaf,smnaf?
> 
> I believe so.
> 
>> - If I add some subclasses to CONDITION, as proposed here for 
>> extending Core, would I not change the menaing of CONDITION and thus 
>> RULESET, anf thus Core? Or would I need to redefine CONDITION/RULESET 
>> by new classes in such an extension?
> 
> Not sure but the above is a possible argument for doing so anyway.
> 
>> Compatibility/Semantics:
>> ------------------------
>>
>> *  FWD Compatibility:  "A RIF dialect is forward compatible if a 
>> conformant implementation will process instances of any future or 
>> unknown extension according to the specification of the said
>>    extension."
>>
>>  I'd guess Core is unlikely to be Forward compatible towards
>>  Stratified Normal Logic Programs as described here,
>>  however, by ignoring
>>    (i)  all naf atoms with predicate symbols not occurring in any
>>         rule head in the rule set
>>    (ii) deleting all rules involving naf, after
>>         applying (i)
>>  one could achieve a soundness-preserving treatment.
> 
> 
> Transform (i) is, of course, a whole-ruleset pattern and beyond the 
> fallback machinery proposed so far. 

Note: stratification is also whole-ruleset

> However, transform (ii) on its own 
> would still be sound (just a bit over cautious) and seems within at 
> least the spirit of the current proposal.

yes.

> So what happens under the suggestion of ruleset labelling?
> 
> If the fallback for RULESET-STRAT was RULESET then a dialect 0 processor 
> given dialect 1 would treat it as a horn ruleset but would either abort 
> if it found a rule containing NAF, or apply your transform (ii) if that 
> was supported. That seems correct.
> 
> Similarly the fallback for RULESET-WF and RULESET-SM would be 
> RULESET-STRAT.
> 
> It seems to me a minimum level of forward compatibility would be that if 
> a ruleset was written in a dialect with negation but didn't use any 
> negation at all then it should be interpretable by dialect 0 system. If 
> we do whole-ruleset labelling then this does seem to require that we 
> have minimal fallback machinery able to fallback ruleset labels.
> 
>> * Backward compatibility: Dialects 2 and 3 should both be backwards 
>> compatible with Dialect 1. However, I am not sure about whether/what 
>> we mean by backwards compatiblity with Core. I'd guess, e.g. the 
>> logics presented in [6] could serve as a backwards compatible 
>> extension of
>> Horn towards Dialect1 and Dialect3.
> 
> 
> Presumably backward compatibility means that any dialect 1 (or 2 or 3) 
> processor presented with a dialect 0 ruleset would arrive at the same 
> entailments as dialect 0. Wouldn't this be automatically true in this 
> case? I'm afraid I don't know [6] and don't quite understand what the 
> issue is here.

The logics of [6] is a non-classical logic which assigns some minimal
models to logic programs with negation (actually, it takes arbitrary 
formulae and presents a model theory for negation as failure which 
coincides with the stable semantics on normal logic programs) Anyway, 
there are several such logics, it was just one example.
  It is backwards-compatible with Horn with respect to minimal models. 
However, what I meant to say was, that I was not sure what we had 
defined so far that for Core we only talk about minimal models (although 
I'd guess this would make sense)

Another thing: Many systems dealing with Normal Logic programs or 
datalog make an additional restriction, ie. they only allow safe rules, 
that is rules where each variable needs to occur in a positive body 
literal. That is a furtherrestriction made commonly in systems that use 
a bottom-up evaluation strategy.

best,
axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Monday, 9 July 2007 10:49:12 UTC