<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for the clarification, Stephan. I've noted the suggestion for backing off on TOP to INDEX and for allowing no top. This makes sense.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm completely unable to make sense of the lisp format call, so I'm not sure what you mean regarding conclusion (b), but I'll wait for your post to the other thread.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 2:45 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">g'day:<br>
<br>
> I think the LKB's EDS code will more aggressively search for a top for the EDS graph during conversion, perhaps looking to the INDEX. If anyone (Stephan?) cares to explain the procedure for selecting tops in less-than-perfect MRSs, I'd be happy to try and implement it in PyDelphin.<br>
<br>
yes, robustness to unusual or illformed (as in this case) MRSs has<br>
long been a key goal in the EDS conversion (in the LKB); MRS<br>
infelicities (in ERG parses) were probably more common in 2002 than<br>
today, but still i think that conversion should preferably never fail,<br>
i.e. possibly rather drop information from an illformed MRS than not<br>
yield an EDS at all.<br>
<br>
regarding the top node, i do indeed fall back to the INDEX, if need be:<br>
<br>
(let* ((ltop (ed-find-representative eds (psoa-top-h psoa)))<br>
(index (ed-find-representative eds (psoa-index psoa))))<br>
(setf (eds-top eds)<br>
(or (and (ed-p ltop) (ed-id ltop))<br>
(and (ed-p index) (ed-id index))<br>
(and (var-p (psoa-index psoa))<br>
(var-string (psoa-index psoa))))))<br>
<br>
the third clause in the or() appears intended to deal with an MRS<br>
whose INDEX is not the intrinsic variable of any EP. in that case,<br>
the EDS will end up with a top that is not the identifier of any of<br>
its nodes, so effectively no top.<br>
<br>
thinking about such corner cases just now, i am tempted to drop that<br>
third fall-back clause and leave the top empty (which would be<br>
formally equivalent, seeing as the top property is interpreted as an<br>
annotation on one of the actual graph nodes). it appears native<br>
serialization allows for empty top nodes already, in which case there<br>
will be nothing following the opening brace on the first line:<br>
<br>
(format<br>
stream<br>
"{~@[~(~a~):~]~<br>
~:[~3*~; (~@[cyclic~*~]~@[ ~*~]~@[fragmented~*~])~]~@[~%~]"<br>
(eds-top object)<br>
(and *eds-show-status-p* (or cyclicp fragmentedp) )<br>
cyclicp (and cyclicp fragmentedp) fragmentedp<br>
(eds-relations object))<br>
<br>
while i am sure we have never hit empty tops while working with MRSs<br>
produced by the ERG, the above suggests that (a) identification of the<br>
top node is optional in EDS and (b) native serialization was intended<br>
as a line-oriented format.<br>
<br>
mike, may i suggest you add the fall-back, looking for the INDEX, and<br>
otherwise allow EDSs whose top is empty. regarding the exact<br>
definition of the native EDS serialization, i shall return to that<br>
question in the original thread we had on the topic (one might<br>
disallow whitespace between the opening brace and the optional top, to<br>
try and evade conclusion (b) above).<br>
<br>
cheers, oe<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">-Michael Wayne Goodman</div>