[developers] enhanced SEM-I support in the forthcoming 1214 release of the ERG

[Stephan Oepen]

> Is there a specification of the semantics of the hierarchy anywhere?

not yet, i am afraid.  our current focus has been to get the grammar
and software ready for the LREC tutorial.  but once that is all
packaged up, i will write up more notes on the new SEM-I ‘embedding’
procedure (which involves a ‘patching’ mechanism on top of the
grammar-internal hierarchy; see ‘etc/patches.lisp’ in the 1214 ERG)!

even though (predicate) unification has a less prominent role in MRS
manipulation, from the processing side i see no alternative but to
assume glb uniqueness.  currently, in the LKB implementation at least,
i do not invoke the BCPO embedding, though: as our predicate hierarchy
to date is small and hardly uses multiple inheritance, the problem has
yet to arise.  but when thinking about it earlier, my inclination has
been be to actually require glb uniqueness at the specification layer,
i.e. flag ‘ambiguous’ cases (and make the SEM-I creator insert
additional nodes) rather than introduce missing glbs automatically.

i am planning to offer an update on SEM-I construction and possible
use at the summit and suggest we discuss jointly how much we want to
tie the arms of SEM-I creators then.  i expect the question will be
more relevant once someone like francis might want to use this new
facility for ‘upwards extension’ of the ERG SEM-I, i.e. adding
additional abstractions based on some external ontology.
technologically, i believe we are finally making that possible now!

—however, your query reminded me to apply my semi-automated
consistency checking to the latest revision of ‘hierarchy.smi’, where
i had added two more abstractions last night that we felt not quite so
sure of: ‘dir’ and ‘state_loc’.  as it turns out, in doing so i had
inadvertently added a parent link (‘unspec_loc’ does not subsume
‘state_loc’ grammar-internally, as i had assumed) and had caused some
hierarchy disorder.  i just checked in an update (removing these two
dubious abstractions) and encourage everyone looking at the emerging
ERG SEM-I to ‘svn up’ quickly.

dan, in case you read this far: i believe you were skeptical of
exposing ‘dir’ and ‘state_loc’ yesterday already, so would like to
assume that you are okay with my removing them again?

> [...] at least very basic information about all the abstract predicates now.

thanks for the heads-up.  how did you interpret ‘all’ in the above?
does what we currently expose in ‘abstract.smi’ cover everything on
your list?  for our next ESD discussion, dan, emily, and i plan to
discuss the question of how to best document predicate hierarchies
(beyond what is in the SEM-I).  so, if you had anything emerging for
us to look at by may 9, that would be much appreciated!

cheers, oe