[developers] Sweaglesw ERG binaries don't include SEM-I?

[Glenn Slayden]

Can we also document any decisions about the optimal implementation behavior somewhere on the DELPH-IN wiki, for such a time as I address SEM-I issues in ‘agree’ ?

 

Thanks,

 

Glenn

 

From: developers-bounces at emmtee.net [mailto:developers-bounces at emmtee.net] On Behalf Of Woodley Packard
Sent: Thursday, March 23, 2017 11:05 PM
To: Stephan Oepen <oe at ifi.uio.no>
Cc: Michael Wayne Goodman <goodmami at uw.edu>; developers at delph-in.net
Subject: Re: [developers] Sweaglesw ERG binaries don't include SEM-I?

 

Interested parties,

 

I’ve now found time to impement behavior (c) from this thread, and tested Stephan's jaen.smi and example MRS with and without the change, and can report that various denominations of dog can be observed to bark once the change (now committed to svn trunk) is applied.

 

$ ./ace -g erg-1214.dat -e ~/transfer.debug.oe 

The dog barks.

A dog barks.

The dogs bark.

Dogs bark.





 

-Woodley

 

On Mar 15, 2017, at 11:16 AM, Stephan Oepen <oe at ifi.uio.no <mailto:oe at ifi.uio.no> > wrote:

 

hiya,




Those warnings perhaps merit some investigation, but I don't think they are
fatal are they?  Did you try the resulting grammar to no avail?


i suspect you might be ignoring declarations for which that warning is
output?  which would explain why the hierarchy extensions currently
have no effect in ACE.

how to interpret repeated subsumption declarations for the same
predicate is one of the fine points of the SEM-I Definition Language
(SDL) that we have yet to specify.

one could (a) ignore declarations for predicates that have been seen
to the left of ‘<’ before; (b) merge the right-hand side of all such
declarations into the union of parents; or (c) treat them as
re-definitions, i.e. let the chronologically last such declaration
take effect.

i believe the LKB currently applies strategy (b), which in this case
leads to the same effect as (c) because i also apply transitive
reduction to the parent declarations.

but to fully enable users to configure custom predicate hierarchies
without changing core ERG files, my current sense is that we should
opt for (c)—which presumably would not be harder to implement than
(a).

woodley, could you agree to this point of view (and if so, make it so
in ACE :-)?

it would really feel like a break-through if we ended up solving the
current JaEn issue by empowering francis and colleagues to augment the
ERG predicate hierarchy non-intrusively.  making that possible (and
practical) was among my key reasons for pushing foward the use of the
SEM-I for all processing that has at its core MRS manipulation.

cheers, oe

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20170323/f338db42/attachment.html>