<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'll have a go, but I do realise from previous discussion that you
are intentionally simplifying, and that some cases where I regard
something as an unhelpful oversimplification, you may still think
this is justified. So, if I may, let me take one example from that
page and try an explanation, and then see whether we can come to
some mutual understanding. This isn't actually anything to do with
predicate naming conventions, but I want to take a more
straightforward case:<br>
<br>
<blockquote type="cite">The semantics corresponding to nominals
prototypically involves an <span class="anchor" id="line-152"></span>instance
variable and a (generalized) quantifier, which jointly we take <span
class="anchor" id="line-153"></span>to denote a <em>set</em>,
possibly one of singleton cardinality (for quantifiers <span
class="anchor" id="line-154"></span>introduced by singular
determiners, e.g. <em>a</em> or <em>this</em>) or even an <span
class="anchor" id="line-155"></span>empty set (for the <em>no</em>
quantifier, as in for example <em>no dogs bark</em>). </blockquote>
<br>
I take it here that you're talking about the semantics of a phrase
like "every dog". If we're interpreting `every' as an ordinary
quantifier, `every dog' could be written as \lambda P \forall x [
dog(x) => P(x) ] - it's of type <<e,t>,t> since it
requires something of type <e,t> (e.g., an intransitive verb,
like barks) to give a truth value. In fact, `every dog' denotes the
set of all sets of which the set of dogs is a subset (so it does
denote a set, but not, I think the one that your text would imply).
With generalised quantifiers, something similar is going on, except
that the quantifier is expressed in terms of the cardinality of the
set of dogs and the set of Ps. <br>
<br>
Of course, in MRS, the BODY of the quantifier is missing (and this
actually means that we can do the composition more straightforwardly
though I won't go into that here). But that doesn't mean that the
MRS for `every dog' denotes the set of all dogs. The semantics
we've given for MRS is not in terms of real world denotation at all,
but in terms of how it corresponds to a set of expressions in some
object language, which might be predicate calculus with generalised
quantifiers, but does not have to be. So there is an inconsistency
with the MRS paper. (For me, this matters a lot, not least because
this object language doesn't work as a general account of semantics,
although it has its uses.) <br>
But we have never provided a way of giving a semantics for partial
MRSs in terms of lambda expressions. (We didn't develop an
underspecified form of lambda calculus although, if I remember
correctly, that's what UMRS did.) Anyway, even talking in an
underspecified representation, because the body of the quantifier is
uninstatiated, I think I would still say that an informal gloss of
the meaning of `every dog' has to be the same as in the fully scoped
version - i.e., as above, the set of all sets of which the set of
dogs is a subset.<br>
<br>
So, technically, one cannot talk about an MRS denoting anything in a
model corresponding to the real world. If you decide to make a
loose translation of a partial MRS into the lambda calculus rough
equivalent, that's OK, though I think you would have to make it much
clearer that is what you are doing (and the gloss you've given here
is incorrect, even viewed in that loose way). To draw an
(imperfect) analogy - it's a bit like talking about an HPSG in terms
of phrase structure trees. It can be a useful thing to do, both in
terms of getting points over to non-specialists and in talking
informally about some analyses, but it's vital that it is clear in
such a discussion that we are only using the trees as some sort of
abbreviation and that a syntactician unfamiliar with HPSG does not
go away with the idea that we are really manipulating trees.
Something that I hope we (possibly me and Guy) can do in advance of
the LREC tutorial is to show a translation of an ERS fragment into
something like a database query application - where quantifiers
actually matter ... This might make all this clearer.<br>
<br>
As I say, I can understand if your reaction to these comments is
that you're just trying to give an intuition of ERS for people who
know no formal semantics. I don't personally think it works to do
this (or at least, a really informal account might work, but I'd
avoid talking about denotation in that case) but I understand you
feel it is helpful. If you do want me to go through line-by-line
and explain the formal issues with other parts of the pages, I can
do that, but I don't think I should start that exercise unless we've
got a common idea about the objective.<br>
<br>
Happy New Year!<br>
<br>
Ann<br>
<br>
PS - in the paper that Dan and I co-authored in Corbett and Kibort's
`Feature' volume (which I should put on my website) there is a
discussion of what might be involved in `translating' ERS into a
formal account of plurals. Perhaps this should help to indicate why
I think it is a very positive feature of *MRS in general (and ERS)
that it can be translated into different object languages.<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/01/2016 00:32, Stephan Oepen
wrote:<br>
</div>
<blockquote
cite="mid:CA+_Fm6Kg_NpyAoPc-zq3Drea8eppam1iH7240Gqt3E0U-fH-ww@mail.gmail.com"
type="cite">
<pre wrap="">a happy new year, everyone!
</pre>
<blockquote type="cite">
<pre wrap="">My problem with this document is not so much that it's ERG-specific but that
it is in contradiction to the MRS paper in various places. Which is
unfortunate.
</pre>
</blockquote>
<pre wrap="">
i authored that page jointly with dan and emily, and i do not recall
intentional deviations from the various publications on MRS. it would
be helpful for us to know the specific contradictions you have in
mind.
all best, oe
</pre>
</blockquote>
<br>
</body>
</html>