[developers] smallish native DMRS grammar

[Ann Copestake]

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/20160105/7446e596/attachment-0001.html>