[developers] MRS "constant" arguments

[Ann Copestake]

Hi Woodley,

sorry for the slow reply - I was on holiday last week, then at a meeting.

sweaglesw at sweaglesw.org said:
> LKB and PET both have special grammar-defined settings specifying which
> features correspond to constant arguments (only CARG, in both cases), so they
> allowed the *top* to be passed through the VPM, which conveniently had a "* >>
>  u" line, resulting in [ ARG2 u ] on the MRS.

that's convenient ... We've had bugs caused by *top* in the MRSs before now.

sweaglesw at sweaglesw.org said:
> 1. What is the formal status of these "constant" arguments?  Are they to be
> interpreted as part of the predicate itself, or objects in their own right?
> More to the point, is it conceivably legal for an EP to have more than one of
> them?

if I were writing these things out in a more conventional FOPC style 
representation, I'd write something like named(x,"Kim").  But in terms of the 
underlying semantics, lambda x [ named(x, "Kim") ] denotes a set, so 
semantically you could take them to be part of the predicate.  There's no 
formal reason why you couldn't have more than one, and I think we did that in 
Verbmobil days.  e.g., with a time expression, like 10:45, one could have a 
time-of-day predicate with two constant-taking arguments corresponding to 
hours and minutes.

> 2. What is the meaning of a node in an MRS-describing AVM whose type is not
> subsumed by "semarg"?  Is it meaningful to try to read anything into the
> relationship between those nodes' types and "semarg"? 

I regard the specification of `semarg' as the type of the arguments as 
something that's good coding style but that doesn't have any formal force.  
When I'm specifying MRSs in a language other than typed feature structures, I 
wouldn't expect to necessarily have an analogue of semarg.

> I believe there was a time when ACE behaved more like the LKB and PET, but
> something prompted me to change that -- most likely compatibility with some
> other grammar.  It could have been that I simply didn't feel like adding
> another configuration parameter indicating what CARG was in that grammar.  It
> would be nice to not require each grammar to specify that feature name, but
> if it's necessary, it's necessary.

My stance with respect to the LKB was that all feature and type names should 
be user-specifiable.  I don't think there are many non-DELPH-IN users around 
any more (though there are some), but it was important to me that it can be 
used very flexibly (and isn't specific to HPSGish grammars, even).  But maybe 
we can think of a cleaner way of doing this in the various systems.

All best,

Ann