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

Woodley Packard sweaglesw at sweaglesw.org
Fri Mar 24 07:05:24 CET 2017

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.


> On Mar 15, 2017, at 11:16 AM, Stephan Oepen <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/97f6c4a6/attachment.html>

More information about the developers mailing list