Closed arademaker closed 3 years ago
I have also reported in https://github.com/delph-in/erg/issues/25. It looks like bug in the ERG.
I see the MRS and the traceback, but no code. Is this just using the delphin convert
command?
Also note that conversion from EDS to MRS is not supported as the conversion from MRS to EDS is lossy.
edit: Sorry I must have misread the title.
The error was using EDM
(venv-dev) ar@leme wn % delphin edm -vvv ../terg/tsdb/gold/omw omw-parsed
and I replicated with the code:
from delphin import ace
from delphin import itsdb
from delphin import tsql
from delphin import dmrs, eds
from delphin.codecs import eds as edsnative
from delphin.codecs import simplemrs
from delphin.codecs import dmrx
ts = itsdb.TestSuite('omw-parsed')
for row in tsql.select('i-id mrs', ts):
m = simplemrs.decode(row[1])
print("Sentence MRS %s\n" % row[0])
print(simplemrs.encode(m, indent=True))
d = dmrs.from_mrs(m)
print("Sentence DMRS %s\n" % row[0])
print(dmrx.encode(d, indent=True))
e = eds.from_mrs(m)
print("Sentence EDS %s\n" % row[0])
print(edsnative.encode(e, indent=True))
What is, or should be, the expected behavior when a qeq selects a label is not the label of any EP, or when half the EPS are disconnected from the top?
I don’t know... maybe at least a proper error handling? A test of consistency before attempting the conversion? Btw, the doc string says the EDSError may be fired, but it is not true. The function does not have any raise command.
I think I'd prefer to keep the behavior that an error is raised on ill-formed MRSs but, you're right, it should be raising more descriptive EDSErrors from the underlying errors. Any kind of robustness to ill-formed inputs should be optional. Also my general strategy here is to not do the costly consistency checks before conversion, and instead just fail during conversion (ideally with descriptive errors).
To clarify, based on discussions from the mailing list. We should strive for converting as much info as possible, issuing warnings when MRSs are ill-formed but when we can still proceed, and raise more appropriate errors when conversion cannot recover from a problem (e.g., a generic try-catch around conversion that reraises a wrapped exception).
This is related to #316. The origin of both errors is a broken MRS with h?
that occurs only as arguments of EP, mentioned in the HCONS but not labeling any EP. I pushed one more commit in the https://github.com/delph-in/pydelphin/pull/318 solving this error. I followed your approach in the _mrs_args_to_basic_deps
function to just continue
in the case of a missing key in the representatives map.
This was resolved in d3c95817557caf3619a72d3b643a7aef310e18f4 and 31ca20968379058e75eb517afecb0b0bb34ee25b.