[developers] smallish native DMRS grammar
Ann Copestake
aac10 at cl.cam.ac.uk
Wed Jan 6 11:45:06 CET 2016
Hi,
No, right now, I don't particularly want grammars with ICONS - I'm
looking for collaboration with developers of grammars with the
characteristic variable property. i.e., each variable is introduced by
a unique elementary predication and each EP (other than quantifiers)
introduces a variable. (Sorry, I know oe uses different terminology,
but I can't remember what it is at the moment.) Failing that, a grammar
where the developer would like to introduce that property. I would
like to try and add a parallel semantics to such grammars where we build
up DMRSs rather than MRSs or RMRSs to check that it can be done.
The point is that directly building DMRS is different from directly
building MRS (or RMRS). It's not the case that because one can make a
conversion from MRS<->DMRS with complete analyses, one can necessarily
build DMRSs directly (using the same syntax). I think it is actually
possible, but it needs to be demonstrated. So I want a grammar which
does more `messy' stuff than my *mrscomp grammars but which (preferably)
isn't huge. I would need to do this in tandem with the grammar
developer, because it's likely there will be questions of the form `why
are you doing X here?'
See earlier message for comments about the dmrscomp grammar.
All best,
Ann
On 05/01/2016 23:23, Michael Wayne Goodman wrote:
> Thanks. I'm looking forward to the treatment of ICONS so I can update
> my own MRS-to-DMRS converter.
>
> As for non-ERG grammar suggestions: if you're looking for non-trivial
> grammars with ICONS support, check out the Zhong grammars (namely
> Mandarin: https://github.com/delph-in/zhong/tree/master/cmn);
> otherwise, Jacy is my usual source of semantic surprises. Emily may
> have some suggestions of interesting specimens from her Matrix Grammarium.
>
> On Tue, Jan 5, 2016 at 2:58 PM Ann Copestake <aac10 at cl.cam.ac.uk
> <mailto:aac10 at cl.cam.ac.uk>> wrote:
>
> Hi Mike,
>
> I'm thinking about ICONS and DMRS since we anyway need that with
> the MRS->DMRS conversion. The coindexed dropped arguments seems
> to me fixable along the lines you suggest, but again, it's
> something we need to look at for the MRS->DMRS conversion. The
> comment about making sure we could express everything we needed to
> was more directed at the need to find out whether there's anything
> problematic when one is constructing DMRSs directly. So it would
> be great if someone would suggest a suitable grammar to experiment
> with, before I just decide to use the ERG ...
>
> All best,
>
> Ann
>
>
> On 05/01/2016 21:25, Michael Wayne Goodman wrote:
>> Hi Ann,
>>
>> Thanks for sharing. I couldn't find the grammar at first because
>> I was looking in the LOGON tree instead of the separate LKB
>> repository. If others are searching, it's here:
>> http://svn.delph-in.net/lkb/trunk/src/data/dmrscomp/.
>>
>> I find DMRS more intuitive and more manageable than other *MRS
>> representations, so it's exciting to imagine a world where that
>> is the primary representation output by our grammars. I'm curious
>> to see how this works out with some larger grammars, but I can
>> think of a couple of challenges (based on my discussion in
>> Singapore: http://moin.delph-in.net/SingaporeMrsWellformedness).
>>
>> 1. We don't yet have a way to represent ICONS in DMRS
>>
>> 2. DMRS currently can't express coindexed dropped arguments
>> (where in MRS the 'i' variable of two arguments is the same;
>> perhaps this can be represented using ICONS instead, or by
>> (re)introducing zero-pronouns)
>>
>> These are both difficulties with the resulting representation.
>> I'm not sure if there are other issues when implemented in the
>> grammar. Sometime soon it would be good to iron out these
>> representational wrinkles. Considering ICONS, I don't think we
>> can just put a post-post-slash label on a link (e.g.
>> ARG1/NEQ/topic) because I don't think ICONS follow normal
>> dependency relations (Sanghoun could confirm).
>>
>>
>> On Fri, Dec 18, 2015 at 9:46 AM Ann Copestake <aac10 at cl.cam.ac.uk
>> <mailto:aac10 at cl.cam.ac.uk>> wrote:
>>
>> I have just checked in to the LKB svn repo a small grammar -
>> dmrscomp -
>> and some code that extracts simple DMRSs directly from the
>> feature
>> structures produced by that grammar rather than going via MRS
>> and RMRS.
>> This is based on the mrscomp grammar (though with some clean
>> up and
>> minor extension) - there's a fairly detailed README file.
>> There are a
>> fair number of items on the TO-DO list - possibly the most
>> time-consuming one would be to make the generator code work
>> with this
>> grammar, not because there's any big problem (that I can
>> think of) but
>> because the generator is quite complicated. There is also a
>> promise of
>> more detailed notes, which I will supply relatively soon, I
>> hope - this
>> was an interesting exercise in thinking through semantic
>> composition.
>>
>> If someone would like to collaborate on trying a similar
>> exercise with a
>> larger grammar, I'd be very interested. It would help if it
>> were a
>> grammar which already had the characteristic variable
>> property, in which
>> case I think the main part of the conversion should be fairly
>> easy.
>>
>> There are a number of potential advantages in constructing DMRS
>> directly, including the ability to construct a DMRS forest
>> directly from
>> a parse forest. I would argue that it also enforces some
>> notions of
>> semantic well-formedness more directly than is possible with
>> MRS -
>> obviously including the (equivalent of) characteristic variable
>> property. The semantic `fingerprint' of constructions can be
>> expressed
>> more simply, because DMRS removes much of the redundancy of
>> MRS. But,
>> of course, this is only interesting if we really can express
>> everything
>> we want to with DMRS.
>>
>> All best,
>>
>> Ann
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160106/673d5d5d/attachment-0001.html>
More information about the developers
mailing list