[developers] predicate naming in MRS
aac10 at cl.cam.ac.uk
Mon Dec 28 23:54:41 CET 2015
Before going any further, I would like to ask Dan whether he intends to
keep proper names, abbreviations etc as having CARG values? I recall a
suggestion at the last Summit that the named_rel/CARG approach should be
changed. The relevance of this is that I think it would be a mistake to
lose case information for such words (which will usually have
The case issue also relates to treating the predicates as having a
three-part structure (lexeme/pos/sense) throughout the codebase (with an
option to allow simpler names for toy grammars). This is something we
have been discussing for a long time ... I believe that this is the
right way to look at predicate symbols in *MRS - i.e., as an additional
annotation on lexemes. There would be advantages to doing this in the
grammar - it allows for alternations that change sense to be implemented
in lexical rules. If we do this, then the lexeme part should reflect
the conventional spelling, which might include case variation (and,
naturally, non-ASCII characters).
(This would complicate the use of predicates for selection in the
grammar (reflecting the current type/string split), but I think there
are cleaner ways to handle this. The need to check each lexical entry
to see whether the value of the predicate is a string or not is a pain
from the perspective of the generator interface anyway.)
Anyway, I would prefer to make any changes to the main body of the Lisp
MRS code myself, since I am currently working on this. I am, of course,
not going to touch the MT code ...
On 28/12/2015 18:15, Stephan Oepen wrote:
> dear colleagues,
> in these days of reflection, i would like to ask for opinions on an
> aspect of the DELPH-IN informalism where dan and i recently discovered
> that we held conflicting opinions. thus, we are looking for folks
> with a deeper understanding of the issue.
> for MRS predicate symbols, we have long established that we do not
> want case differences or type vs. string distinctions to be
> meaningful, i.e. we do not expect foo, Foo, or "foo" to name different
> relations (see ‘MrsRfc’ on the wiki). from this, i had concluded that
> no grammar would ever use both foo and "foo", whereas dan has found it
> convenient in the ERG to use comparable type names and strings (across
> lexical entries of different syntactic categories) in the expectation
> that they would be treated as equivalent MRS predicate symbols, e.g.
> _downtown_a_1_rel and "_downtown_a_1_rel".
> my assertation that the above was an undesirable property for a
> DELPH-IN grammar is supported by currrent software: MRS comparison,
> transfer, and generation do not treat types and strings as equivalent;
> a creator of input semantics for generation, for example, needs to
> know about the distinction and make a choice.
> what dan beliefs, however, arguably makes good sense (to me at least).
> i believe i can see how the various pieces of MRS manipulation
> software could be extended to yield the interpretation of equivalence.
> i would volunteer to make these changes in the Lisp implementation of
> MRS-related code.
> before suggesting a course of forward action, i would like to ask (a)
> whether anyone has strongly held positions (and supporting arguments)
> on the general question and (b) whether woodley and mike would be
> prepared to make software changes in ACE and pyDelphin, respectively,
> regarding this choice?
> with thanks in advance, oe
More information about the developers