Re: [Arch] Action 319

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

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

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.

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

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

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.

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

> 
> 
> References:
> 
> 
> 1. A. Van Gelder, K. Ross, and J.S. Schlipf. Unfounded sets and well- 
> founded semantics for general logic programs. In 7th ACM Symposium on 
> Principles of Database Systems, Austin, Texas, 1988.
> 2. M. Gelfond and V. Lifschitz. The stable model semantics for logic 
> programming. In 5th Int’l Conf. on Logic Programming, Cambridge, 
> Massachusetts, 1988.
> 3. Piero A. Bonatti. Autoepistemic logics as a unifying
> framework for the semantics of logic programs. Journal
> of Logic Programming, 22(2):91–149, 1995.
> 4. Teodor C. Przymusinski. Autoepistemic logic of knowl-
> edge and beliefs. Artificial Intelligence, 95:115–154,
> 1997.
> 5. Marc Denecker, V. Wiktor Marek, and Miroslaw
> Truszczynski. Uniform semantic treatment of default and autoepistemic 
> logics. Artificial Intelligence,
> 143(1):79–122, 2003.
> 6. David Pearce and Agustín Valverde.
> Quantified Equilibrium Logic and the First Order Logic of 
> Here-and-There. Technical Report, Univ. Rey Juan Carlos, 2006
> 7. Pedro Cabalar, Sergei Odintsov, David Pearce and Agustín Valverde.
> Analysing and Extending Well-Founded and Partial Stable Semantics using 
> Partial Equilibrium Logic, Proceedings of ICLP 2006, Springer LNCS 4079, 
> 2006, 346-360.
> 
> 
> 
> hope this was somehow what was expected....
> 
> axel
> 
>

Received on Friday, 6 July 2007 09:02:02 UTC