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 do not know what you mean, but I think I am not talking about those.

A simple extension is, for example, when you add nonmon inheritance to our
frame syntax in BLD.

In BLD, if we have a##b and b[foo->bar] then it does not follow that
a[foo->bar]. But a true object-oriented extension (a la F-logic, for example)
would add nonmon inheritance and a[foo->bar] would follow.

Other examples can be found in WSML hierarchy. Jos can fill you in on
those. This is quite common.


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

Of course, the user must say which semantics to use. The dialect should be
indicated upfront.

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

We probably think of different things, but the above example should clarify
what I meant.


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

I am not sure what you mean by "the same thing". The meaning is defined by
entailments  (or, at least, reflected in the entailments). So, one could
argue that the same doc actually means different things. (Unless you can
define the meaning of "same meaning".)


> 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 they will be either extensions or restrictions of some other
dialect.


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

It is known that some extensions are combinable, but it might be possible
to combine others. I do not think there is any certainty that some
extensions are not combinable. For instance a few  years ago people thought
that DL and rules are not combinable in useful ways, but now several combos
are known.


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

Not sure what you want to say here. Presentation syntax is certainly very
important and it plays an important role in RIF. I cannot think why
anybody would argue for not keeping consistency among presentation
syntaxes in cases where it is feasible and not too awkward.


	--michael  

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

Received on Monday, 22 October 2007 04:13:24 UTC