[developers] Detecting quantifiers in *MRS

[Ann Copestake]

Hmm - I think what this points out generally is that we should be clear 
about the status of the configuration files and provide a mechanism for 
exporting relevant values for use by code such as pyDelphin (since it 
doesn't have the same direct access as the Lisp code etc).  So it would 
maybe make sense to export this sort of configuration as part of the SEM-I?

In terms of reliable signal for this specific case, yes, I would use 
"RSTR".  Because of the way the type system operates, I think it 
unlikely there will be a problem of grammar writers accidentally also 
using it for things other than quantifiers.  There's no real point 
trying to make _q_rel work as identification instead because the code 
anyway needs to know the quantifiers' feature names in some contexts.  
RSTR should be added to the mrsglobal file - I'll do that.

Ann

On 01/01/2016 01:56, Michael Wayne Goodman wrote:
> (This discussion was started on the "predicate naming in MRS" thread.)
>
> On Thu, Dec 31, 2015 at 11:39 AM Ann Copestake <aac10 at cl.cam.ac.uk 
> <mailto:aac10 at cl.cam.ac.uk>> wrote:
>
>     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.
>
>
> Checking for POS=="q" did seem fragile to me, especially because of 
> the gpreds-don't-officially-have-pos issue. But I'm not certain that 
> these solutions are much better, from my point of view; namely, 
> pyDelphin needs to be able to detect the quantifiers in a *MRS without 
> knowing anything about the grammar. Anyway, let's iterate some ways to 
> detect quantifiers:
>
> 1. Check for a POS of "q"
>
> This is merely conventional and not a formal part of *MRS, but seems 
> to be a well-respected convention.
>
> 2. Look for a scope feature (e.g. BODY)
>
> Treating BODY as the conventional scope feature is about the same as 
> (1), but to be accurate more generally it requires per-grammar 
> configuration (e.g., parsing grammar files like mrsglobals.lisp). 
> Also, DMRS doesn't use BODY, but instead RSTR, to indicate quantifier 
> relationships (is RSTR thus a better choice for the scope feature?).
>
> 3. Check a list of quantifiers (e.g. in a SEM-I file)
>
> This isn't so bad, but then there's a burden on the grammar developers 
> to keep their SEM-I files up-to-date. Also, those files would ideally 
> be distributed with, e.g., a deepbank, separate from the grammar.
>
> 4. Look at the structure: in MRS, a quantifier has an HCONS relation 
> that selects a label shared by EPs where the ARG0 of one EP from that 
> set is the bound variable of the quantifier. In DMRS, a quantifier has 
> a RSTR/H link to the quantifiee.
>
> This seems the most reliable in the absence of per-grammar 
> configurations, but is relatively expensive to compute.
>
> In general, I see the requirement for per-grammar configurations in 
> order to analyze the semantic output as a barrier-to-entry for 
> non-DELPH-INites (or for anyone, really, if they just want to do stuff 
> with the semantics). For this reason I somewhat disprefer (2) and (3), 
> even if they are better solutions.
>
> I guess my question is this: would checking for the RSTR feature be a 
> more reliable heuristic for detecting quantifiers? If grammars 
> consistently use it always and only for quantifiers, then it seems a 
> better choice than BODY.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160101/ce74ec8a/attachment.html>