Re: minimal requirements for Arch document

kifer@cs.sunysb.edu (Michael Kifer) writes:
> >
> >             * No Language Conflict: every dialect MUST give the same
> >               semantics as each prior dialect does to any document
> >               which has a defined meaning in both dialects.
> 
> This may be too strict. An extension dialect should be allowed to make more
> inferences, but should not invalidate existing inferences of the subdialects.

Are you talking about what we might call an "invisible extension", where
an extension is being used by the author, but there is no trace of that
fact in the generated document?  That seems like a bad idea, and
unnecessary.  (The fact that it's done in the RDF/OWL stack -- as far as
I understand it -- is no excuse.  IMHO, that's a bug, not a feature.)

I think whatever one might want to achieve by using such a thing can be
done by adding a required flag, indicating that the author is using
different semantics.  For a (silly) example, one could extend BLD with
an opposite-day-extension (ODE) [1] indicating that conditions authored
on certain days are to be understood as being implicitely negated.
Obviously BLD+ODE has very different semantics from BLD, but we're still
in conformance with the no-conflict rule because there is no syntactic
overlap: every BLD+ODE document (and no BLD document) would have some
flag, such as an <oppositeDayExtension> as child of the root element.

In general, I think global flags like that are a bad idea -- it's better
to have the language change localized -- but if it's needed, it can be
done.

> What this means precisely is open to interpretation. For instance, with CWA
> the above should probably apply only to positive inferences (but I am not
> sure whether this does not have undesirable side-effects).

Harold used an example on the call, saying (if I recall correctly) that
when you add negation to a language, you change the meaning of rules,
such they they also entail their contrapositives.

I think, to generalize, the problem is that in different dialects (ie
with different extensions present) the same document might essentially
mean the same thing, but the actual entailments will be quite different.
Some logics will easily generate infinite entailments, etc.

Am I right in thinking that fact is hidden from us at the test-case
level, where we're querying for ground variable bindings and/or watching
ground actions be triggered?  Maybe for non-conflict the language needs
to be changed to reflect this kind of behavior -- an implementation must
be able to simultaneously conform to the specifications of all dialects.

> >             * Maximize Overlap: every dialect SHOULD reuse as much of
> >               the the syntax as possible from prior dialects. 
> 
> Certainly as far as the XML syntax goes it should preserve all the syntax.
> Otherwise, documents in a subdialect will not be legal docs in an extension
> dialect.

I'm just thinking about XML syntax here.  I've given up on thinking
about abstract syntaxes (for now, at least).

Extensions by definition preserve all the syntax, but I'm not currently
assuming all dialects will be formed as extensions of anything.

> >         I think we should try defining some dialects using these
> >         principles, coordinating loosely as we like, but eventually I
> >         think we need to figure out how to open the process to 3rd
> >         parties.  That's going to involve some careful work around
> >         defining "prior dialect".
> > 
> >     3.  What does one need to do to define a RIF extension?
> > 
> >         As I see it, an extensions is a "delta" between dialects where
> >         one dialect is a superset of the other.
> > 
> >              NewDialect = OldDialect + Extension
> > 
> >         What is challenging about extensions is that we want them to
> >         be orthogonal; we want users to be able to combine extensions
> >         which were developed independently.   For this example, I'll
> >         assume Lists end up in an extension, instead of in BLD.  I don't
> >         want to do that, but it makes a good example:
> >  
> >              BLD_with_NAF = BLD + NAF_Extension
> > 
> >                     The BLD_with_NAF dialect should be fully specified
> >                     by the NAF_Extension spec read in combination with
> >                     BLD.
> >  
> >              BLD_with_Lists = BLD + Lists_Extension
> > 
> >                     The BLD_with_Lists dialect should be fully specified
> >                     by the Lists_Extension spec read in combination with
> >                     BLD.
> >  
> >              BLD_with_Lists_and_NAF = BLD + NAF_Extension + Lists_Extension
> > 
> >                     We would like the semantics here to be fully
> >                     determined by the two extension specs and BLD.  This
> >                     is the challenge.  How can the documents be written
> >                     such that this is the case?
> > 
> >         At the syntactic level this is clear enough, if you think of the
> >         sets of strings/documents conforming to the syntax.  An
> >         extension provides a set of strings, and "+" above is set-union.
> >         The question is how do we address this at the semantic level?
> >         Is there a way to address it across all approaches to defining
> >         semantics, or is this easy to do for model-theoretic semantics
> >         and impossible for procedural semantics?  (My sense is that it's
> >         trivial for proof-theoretic semantics; I'm unclear on the
> >         others.  I think Michael Kifer has in mind how to do this with
> >         MT semantics on BLD, but I don't understand that part yet.)
> >
> >         It may well be that some extensions are incompatible (such as
> >         NAF and classical negation?), in which case the combination
> >         procedure should fail, I would hope.
> 
> Many extensions are orthogonal both syntactically and semantically. But not
> all, as you said. We should strive to define extensions that are orthogonal
> as much as possible, and when they are not we should indicate that.

Can we determine with certainty where extensions interact?  How hard
will it be for others to tell, when they are defining extension?

> We should advise/encourage to make the presentation syntaxes compatible as
> well, but it should not be a requirement, I agree. This is because the
> usual presentation syntaxes do not have as many tricks in their hat as XML
> does.

While it makes some sense, I have mixed feelings about making the
presentation syntax have more weight as a standard because I don't
really like it as a language.....

   -- Sandro


[1]http://en.wikipedia.org/wiki/Opposite_Day

Received on Sunday, 21 October 2007 22:19:49 UTC