[developers] EDM implementations

[goodman.m.w at gmail.com]

Thanks, Bec!

I manually put in the :ltriples in the parse script and was able to produce
some output that edm_eval.pl could read.

Regarding the CARG being combined with the predicate name, that was what I
guessed by looking at the Lisp code. Thanks for correcting my mistake.

One more detail is what to do when the two sides (gold and test) have
different numbers of items. Currently my code stops as soon as either a
gold or test item is missing, which is what smatch (the similar metric made
for AMR) does, but I think that may be wrong because parsing profiles are
likely to have missing or extra (overgeneration) items in the middle. So
the question is whether we ignore it or count it as a full mismatch.


On Thu, Jan 16, 2020 at 6:33 PM Bec Dridan <bec.dridan at gmail.com> wrote:

> Wow, that is some old code... From memory, export was a wrapper around
> `parse --export`, where I could add :ltriples to the tsdb::*redwoods-export-values*
> set.
>
> I don't know the mtool code at all, but re-reading the paper and looking
> at the perl code, I don't think the original implementation evaluated CARG
> at all. We only checked that the correct character span had a pred name
> of`named`.
>
> I think you are right that the triple export at the time did not produce a
> triple for TOP and it hence would not have been counted.
>
> That match your memory Stephan?
>
> Bec
>
>
> On Thu, Jan 16, 2020 at 8:34 PM goodman.m.w at gmail.com <
> goodman.m.w at gmail.com> wrote:
>
>> Hello developers,
>>
>> Recently I wanted to try out Elementary Dependency Match (EDM) but I did
>> not find an easy way to do it. I saw lisp code in the LKB's repository and
>> Bec's Perl code, but I'm not sure how to call the former from the command
>> line and the latter seems outdated (I don't see the "export" command
>> required by its instructions).
>>
>> The Dridan & Oepen, 2011 algorithm was simple enough so I though I'd
>> implement it on top of PyDelphin. The result is here:
>> https://github.com/delph-in/delphin.edm. It requires the latest version
>> of PyDelphin (v1.2.0). It works with MRS, EDS, and DMRS, and it reads text
>> files or [incr tsdb()] profiles.
>>
>> When I nearly had my version working I found that Stephan et al.'s mtool (
>> https://github.com/cfmrp <https://github.com/cfmrp/mtool>The paper
>> example
>> /mtool <https://github.com/cfmrp/mtool>) also had an implementation of
>> EDM, so I used that to compare with my outputs (as I couldn't get the
>> previous implementations to work). In this process I think I found some
>> differences from Dridan & Oepen, 2011's description, and this email is to
>> confirm those findings. Namely, that mtool's (and now my) implementation do
>> the following:
>>
>> * CARGs are treated as property triples ("class 3 information").
>> Previously they were combined with the predicate name. This change means
>> that predicates like 'named' will match even if their CARGs don't and the
>> CARGs are a separate thing that needs to be matched.
>>
>> * The identification of the graph's TOP counts as a triple.
>>
>> One difference between mtool and delphin.edm is that mtool does not count
>> "variable" properties from EDS, but that's just because its EDS parser does
>> not yet handle them while PyDelphin's does.
>>
>> Can anyone familiar with EDM confirm the above? Or can anyone explain how
>> to call the Perl or LKB code so I can compare?
>>
>> --
>> -Michael Wayne Goodman
>>
>

-- 
-Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20200117/10ced8c0/attachment.html>