<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Emily,<br>
<br>
I'll be on (non-emailing responding!) vacation for three weeks from
this weekend, so thoughtful discussion would have to wait till after
that. But quick comments below again.<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> The UW group
has been reading and discussing
Copestake et al 2001<br>
and Copestake 2007, trying to get a
better understanding of the MRS<br>
algebra. We have a few questions---I
think some of these issues have been<br>
proposed for the Summit, but I'm
impatient, so I thought I'd try to get<br>
a discussion going over email. UW
folks: Please feel free to chime in<br>
with other questions I haven't
remembered just now.<br>
<br>
The two big ones are:<br>
<br>
(1) Copestake et al 2001 don't
explicitly state what the purpose of
the<br>
algebra is. My understanding is that
it provides a guarantee that the MRSs<br>
produced by a grammar are well-formed,
so long as the grammar is<br>
algebra-compliant. Well-formed MRS
(in this sense) would necessarily<br>
have an interpretation because the
algebra shows how to compose the<br>
interpretation for each sement. Is
this on track? Are there other
reasons<br>
to want an algebra?<br>
</blockquote>
<br>
</span> We have never managed to prove
that MRSs constructed according to the
algebra will be scopable, but I think that
is the case. But more generally, the
algebra gives some more constraints to the
idea of compositionality which isn't the
case if you simply use feature
structures. It excludes some possible
ways of doing semantic composition and
therefore constitutes a testable
hypothesis about the nature of the
syntax-semantics interface. It also
allows one to do the same semantic
composition with grammars in formalisms
other than typed feature structures.<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>I'm still trying to understand why it's
important (or maybe interesting is</div>
<div>the goal, rather than important?) to
exclude some possible ways of doing</div>
<div>semantic composition. Are there ways
that are problematic for some reason?</div>
<div>Is it a question of constraining the
space of possible grammars (e.g. for</div>
<div>learnability concerns)? Related to
issues of incremental processing?</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
The following may sound snarky but I really don't mean
it this way - would you have the same type of questions
about syntactic formalism? Because I can answer in two
ways - one is about why I think it's important to build
testable formal models for language (models which aren't
equivalent to general programming languages, so more
constrained thn typed feature structures) and the other
is about what the particular issues are for
compositional semantics. I don't want to reach the
conclusion that semantic composition requires arbitrary
programs without looking at more constrained
alternatives. So yes: learnability, processing
efficiency (human and computational), incrementality and
so on, but one can't really look at these in detail
without first having an idea of plausible models.<span
class=""><br>
<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>Not snarky and totally a fair question. Our syntactic
formalism in fact isn't constrained.</div>
<div>Part of what's appealing about HPSG is that the
formalism is flexible enough to state</div>
<div>different theories in. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I guess for me, the typed feature structure formalism was developed
(largely) independently of HPSG and what's attractive about it is
that it seems to be a particularly good programming language for
grammar engineering. <br>
There are restrictions on what people are willing to call HPSG, but
these are flexible/inconsistent, and the community (or subparts of
the community) changes its mind sometimes. I'm not at all unhappy
with this, as long as there is progress. Anyway, some of these
restrictions can be elegantly encoded in typed feature structures
and others can't. Working out what the restrictions amount to
formally should be an objective, even if we don't then change
formalism.<br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>(As opposed to certain other approaches that have to
hard code </div>
<div>theoretical claims into the formalism.) </div>
</div>
</div>
</div>
</blockquote>
<br>
they could all be encoded in typed feature structures, of course,
but in some cases the claims/constraints can't be represented
particularly nicely in TFSs. for example, if we're representing a
categorial grammar, we have to implement forward and backward
application in feature structures, and there's an implicit claim
there are no additional rules. We do a similar thing with our
grammar rules, of course, but HPSG allows for differing number of
constructions in a grammar without a claim that the framework has
changed, while in categorial grammar the formalism and framework is
defined by the rule inventory. However, if at some point we really
do decide we know how to do syntactic subcategorization (say), it
would make sense to work out precisely what we're doing and relate
it to other frameworks. <br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>So at that point, I think it makes sense to see the</div>
<div>algebra as a theory of composition that can be
implemented in the HPSG formalism </div>
<div>(or others). </div>
</div>
</div>
</div>
</blockquote>
<br>
except that we don't formally constrain composition in TFS in the
way that the algebra assumes ... <br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>I'm totally with you on building testable formal models
(and testable at</div>
<div>scale), so the program of formalizing the general
approach of the ERG and then </div>
<div>seeing whether the whole grammar can be made consistent
with that set of 'best practices'</div>
<div>makes a lot of sense. I guess the piece that's new to
me is why this should be considered</div>
<div>for composition separate from the rest of the grammar.
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The first point would be that different bits of the syntax need
different types of restriction - e.g., subcategorization is
different from agreement, although they obviously interact. The
second point is that what we're trying to accomplish with semantics
is different, specifically that the primary interest is relating
structures for sentences/phrases to structures for words and that we
never filter structures by the compositional semantics. This is
actually something that has a reflex in the implementations, since
we don't need to compute the compositional semantics until we have a
complete parse.<br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>(Also, for the record, I'm always skeptical about
arguments grounded in learnability,</div>
<div>since I think they require a leap that I'm not ready to
make that our models are actually</div>
<div>relatable to what's 'really' going on in wet-ware. </div>
</div>
</div>
</div>
</blockquote>
<br>
actually that wouldn't follow - learnability results are
fundamentally about information rather than implementation. But I
don't actually have anything useful to say about learnability.<br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>But processing efficiency, incrementality,</div>
<div>etc are still interesting to me.)</div>
</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> <br>
Subquestions:<br>
<br>
(1a) I was a bit surprised to see the
positing of labels in the model. What<br>
would a label correspond to in the
world? Is this akin to reification of
propositions?<br>
Are we really talking about all the
labels here, or just those that survive
once<br>
an MRS is fully scoped?<br>
</blockquote>
<br>
</span> the model here is not a model of the
world - it's a model of semantic structures
(fully scoped MRSs).<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>Oh, I missed that in the paper. So are
we then talking about "interpretation"</div>
<div>because the fully scoped MRSs are assumed
to have interpretations via </div>
<div>a second layer of modeling?</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> yes<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> (1b) How
does this discussion relate to what Ann
was talking about at IWCS<br>
regarding the logical fragment of the
ERG and the rest of the ERG? That is,<br>
if all of the ERG were
algebra-compliant, does that mean that
all of the ERSs<br>
it can produce are compositional in
their interpretation? Or does that
require<br>
a model that can "keep up"?<br>
</blockquote>
<br>
</span> it's really orthogonal - what I was
talking about at IWCS was about the complete
MRSs.<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>Got it.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> (2)
Copestake et al state: "Since the
constraints [= constraints on grammar
rules<br>
that make them algebra-compliant] need
not be checked at runtime, it seems<br>
better to regard them as metalevel
conditions on the description of the
grammar,<br>
which can anyway easily be checked by
code which converts the TFS into the<br>
algebraic representation." What is the
current thinking on this? Is it in fact<br>
possible convert TFS (here I assume that
means lexical entries & rules?) to<br>
algebraic representation? Has this been
done?<br>
<br>
</blockquote>
<br>
</span> `easily' might be an exaggeration,
but the code is in the LKB, though it has to
be parameterised for the grammar and may not
work with the current ERG. You can access it
via the menu on the trees, if I remember
correctly. The small mrscomp grammar is
algebra compliant, the ERG wasn't entirely
when I tested it.<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>In the spirit of keeping the discussion
going without delays, I haven't actually</div>
<div>played with this yet. But: accessible
from the trees seems to suggest that the</div>
<div>testing takes place over particular
analyses of particular inputs, and not
directly</div>
<div>on the grammar as static code analysis.
Is that right?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</span> I think one could use static analysis based on
that code on a grammar which was very careful about not
having pointers into the semantics other than those
licensed by the algebra. Either no such pointers at
all, or ones in which there was a clear locality, so it
was never possible for information to sneak back into
the semantics bypassing the official composition.
Proving that can't happen with a grammar like the ERG is
difficult.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Would it be possible at least to detect pointers into
the semantics, for hand-investigation?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
well, yes, you'd just have to traverse the graph, I guess. I think
there actually is some code that might do what is needed, related to
the check that ensures the semantics can be separated off from the
syntax.<br>
<br>
All best,<br>
<br>
Ann<br>
<br>
<blockquote
cite="mid:CAMype6cMLGYr-ZsipjaYox5Gr3o25oUTAkPkr7rZ8Q1e_WX+HA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Emily</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Thanks again,</div>
<div>Emily</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
you're welcome! <br>
<br>
All best,<br>
<br>
Ann<br>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">Emily M. Bender<br>
Professor, Department of Linguistics<br>
Check out CLMS on facebook! <a moz-do-not-send="true"
href="http://www.facebook.com/uwclma" target="_blank">http://www.facebook.com/uwclma</a><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>