[developers] Comparison of REPP implementations

[Stephan Oepen]

hi mike,

> I ran a test to see how compatible our REPP implementations are. I tested
the following:
>
> * $LOGONROOT/bin/repp standalone tool
> * PyDelphin's `delphin repp`
> * ace -Ev (with some `sed` and `awk` to format it like the others)

i am excited you are doing this!  i have been meaning to look into degrees
of REPP compliance for years, and like you i expect it will be worthwhile
to iron out our shared understanding and implementation of this DELPH-IN
sub-formalism.

also, i am happy to confirm that leaving out the LKB from this comparison
is justified, as its implementation of recovering character ranges after
all rule applications are complete predates the work by bec (and myself)
and is known to give invalid results in some cases.

in sum, i would look to the REPP standalone tool as the closest we
currently have to a reference implementation.  it uses the approach of
explicitly keeping track of sub-string correspondences for each rule
application, as described here:

https://www.aclweb.org/anthology/P12-2074/

> The third one is more troubling, because it appears that ACE and REPP
both apply external group calls iteratively even though the ReppTop wiki is
clear that they are should not be iterative. If someone can confirm that
the wiki is incorrect, [...]

this observation is surprising and potentially troubling to me!  the wiki
page is in fact correct: unlike internal group calls, external calls should
not in and of themselves be iterative; that would unnecessarily lump
together two aspects of the REPP specification and potentially constrain
modularity, viz. in a scenario where one would like to split out a rule
group into an external module (e.g. to be able to parametrically turn it on
or off) but does not want iteration over these rules.  if one in fact wants
both, it is trivial to wrap an internal iterative group around the external
module.

i have made minor updates to the REPP code in the past few years, so will
try to synchronize with bec about confirming your observation and actually
making the tool compliant with the specification on the wiki.  if you act
fast about the other two issues you noticed in the PyDelphin implementation
of REPP, possibly you can recognition as the reference implementation then
:-)?

all best, oe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20191125/8bf77523/attachment.html>