<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
<div class="moz-cite-prefix">On 31/12/2015 01:16, Michael Wayne
Goodman wrote:<br>
</div>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">Hi again, Stephan and all,
<div><br>
</div>
<div><span style="line-height:1.5">Sorry to focus more on the
case-sensitivity issue when you were more interested in the
string-vs-type issue. For pyDelphin, type predicates are
equivalent to both double-quoted and single-open-quoted
predicates. That is, </span><span style="line-height:1.5"> _dog_n_1_rel
== '_dog_n_1_rel == "_dog_n_1_rel". I think we've settled on
that being the correct behavior, but I'm prepared to
reintroduce the distinction (if we decide that we want
string preds to maintain case distinctions, for example).</span></div>
</div>
</blockquote>
<br>
I thought we'd agreed not to use the single quote syntax sometime
around the turn of the millenium ... Anyway, I definitely do not
think the user should need to be aware of the string/non-string
distinction, so if that's the main point of the discussion, all seem
to be in agreement.<br>
<br>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">I've created a wiki page for
the specification of predicates: </span><span
style="line-height:15.6px"><a moz-do-not-send="true"
href="http://moin.delph-in.net/PredicateRfc">http://moin.delph-in.net/PredicateRfc</a> .
I filled it out with what I know from our conversations and
from my own experience.</span></div>
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">I would also like
clarification on the status of grammar predicates. They
supposedly don't have internal structure, but I actually
need to rely on the POS value for determining if a pred is a
quantifier pred (e.g., udef_q_rel). </span><span
style="line-height:1.5">I've made pyDelphin decompose
grammar preds in the same way as regular (i.e. real- and
string-) preds so that I can check POS.</span></div>
</div>
</blockquote>
<br>
quantifiers are treated specially in the MRS Lisp code and that
actually predates the tripartite structure. But e.g., my scoping
code does not rely on the _q_rel but uses the presence of a feature
which is specifiable by the grammar writer and defaults to BODY.
Or a grammar writer can define a list of quantifiers. Incidentally,
you can check stuff like this by looking at the mrsglobals.lisp
file, which has some documentation.<br>
<br>
I don't think we at any point decided the gpreds in general could or
should have POS. In fact, it should be possible, because they are
all supposed to mimic real lexical predicates - e.g., compound_rel
behaves like a preposition. But making that change would be a pain
for everyone who is using the *MRS output (perhaps unless a
convertor was also supplied to back-convert *MRS to the existing
gpred vocabulary).<br>
<br>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span style="line-height:1.5"><br>
</span></div>
<div><span style="line-height:1.5">Also, for grammar preds like
compound_rel, I've been treating "compound" as the lemma
field (even if that's not entirely accurate), but </span><span
style="line-height:15.6px"><a moz-do-not-send="true"
href="http://moin.delph-in.net/RmrsPos" target="_blank">http://moin.delph-in.net/RmrsPos</a></span><span
style="line-height:1.5"> says it's the sense field. </span></div>
</div>
</blockquote>
<br>
I was surprised that you said this - I looked at the wiki page and I
think the use of `sense' in the description of the gpred format is
an inadvertent repetition rather than being meaningful. All it's
supposed to say is there is some string of characters followed by
_rel. Thinking of it as corresponding to any of the fields is a
mistake - gpreds should just be treated differently, as they are in
the .dtd<br>
<br>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span style="line-height:1.5">I can change pyDelphin to
call it the sense, but I see plenty of variation in
grammar-pred structure for the ERG (particularly the last
two in this list):</span></div>
</div>
</blockquote>
<br>
I'd say that's ok because we've never defined any structure for the
gpreds ...<br>
<br>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span style="line-height:1.5">There's some more discussion
here (ERG-specific, perhaps):</span></div>
<div><a moz-do-not-send="true"
href="http://moin.delph-in.net/ErgSemantics/Basics#Predicate_Types_.28And_Naming_Conventions.29"
target="_blank">http://moin.delph-in.net/ErgSemantics/Basics#Predicate_Types_.28And_Naming_Conventions.29</a><br>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
All best,<br>
<br>
Ann<br>
<br>
<blockquote
cite="mid:CAGXBFAo+pWxS_TR03qJ+M9C2NPWzhHwVz03veNTpZbfFEBne+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks!</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 29, 2015 at 6:33 AM Stephan Oepen
<<a moz-do-not-send="true" href="mailto:oe@ifi.uio.no"
target="_blank">oe@ifi.uio.no</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">hi again,
ann,<br>
<br>
> Anyway, I would prefer to make any changes to the main
body of the Lisp MRS<br>
> code myself, since I am currently working on this. I
am, of course, not<br>
> going to touch the MT code ...<br>
<br>
glad to know you are coding! i will of course try to not
get in your way :-).<br>
<br>
as the ERG and other grammars are starting to introduce
individual<br>
constraints, i had toyed with the idea of adding ICONS
support to the<br>
MRS construction, visualization, input, and comparison. but
maybe you<br>
have that on your current ToDo list already? if so, i would
be happy<br>
to look into ICONS visualization in the non-CLIM browsers
and ICONS<br>
interpretation in MRS comparison, once you add the basic
support to<br>
the MRS structures.<br>
<br>
i had played with generation from EDS over the past few
weeks, with<br>
promising results so far (see ‘EdsGeneration’ on the wiki).
thus, i<br>
had some pending local changes which included the periphery
of core<br>
MRS code (e.g. bug fixes in the ‘debug’ serialization format
and<br>
dispatching for various graphical browsers).<br>
<br>
i just checked these changes into the main LKB repository,
so we can<br>
work on synchronized code. in case you have started your
own<br>
revisions already, i would recommend you ‘svn up’ as soon as
possible,<br>
and i hope of course there will be no conflicts. i attach a
summary<br>
of my commit below, for your convenience.<br>
<br>
more soon, no doubt! oe<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>