[developers] Whoa, missed someting, sorry

Bernd Kiefer kiefer at dfki.de
Tue Mar 25 16:48:38 CET 2008

Hi Ann, Yi,

i have some questions concerning your replies.

Ann Copestake wrote:
> I wasn't aware of this - does it allow the same options as the Lisp code does?
> (Unfortunately, as I recently became aware, the existing Lisp code no longer 
> has the desired behaviour for some of the teaching grammars when used `out of 
> the box'.)

What exactly are "the same options"?

> kiefer at dfki.de said:
>> Could the producers of MRS maybe  test this code by comparing the new outputs
>> against their tree banks? I understood that there is some code out there to
>> check the equality of  two MRSs.
> you mean the grammar writers whose grammars produce MRSs?  I don't think that 
> using the MRS equality checking code is the right thing in this context - I'd 
> suggest looking for equivalence of the XML (modulo whitespace, but XML 
> comparisons should ignore whitespace anyway).  The MRS comparison code that I 
> know about is designed to check for various degrees of semantic equivalence, 
> but to ignore difference such as order of EPs - however these matter for human 
> readability.

Well, that should make the check easier. Are we then aiming for a 
one-to-one correspondence?

Yi wrote:
 > Just a few more words on the C++ MRS code. For the moment, the new 
C++ > codes only extract MRS from FS, and pretty print them into XML 
format > (which in principle should be identical to the old -mrs=mrx 
option). > > There is no implementation of MRS->RMRS conversion yet. VPM 
mapping is > supported though.

So what exactly is necessary for the MRS->RMRS conversion? Which one 
contains more information, or are they not comparable?

> kiefer at dfki.de said:
>> My hope behind this is that we can remove all ecl/lisp stuff from pet in  the
>> (hopefully not so) long run because of all the problems that it  generates.
> of course someone will then have to keep the C++ version of the MRS code in 
> synch with the Lisp version

At the moment, we have to keep in synch with the changing versions of 
ecl and the numerous problems that must be circumvented. And as long as 
we have only one (or maybe two) formats to support, this should be 
doable. The rest would (hopefully) just be converters from this format, 
which could be shared?

Bernd Kiefer       DFKI GmbH, Stuhlsatzenhausweg, D-66123 Saarbruecken
kiefer at dfki.de     +49-681/302-5301 (phone)     +49-681/3025338  (fax)
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vor-
                     sitzender), Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313

More information about the developers mailing list