[developers] RESTful ERG parsing

Stephan Oepen oe at ifi.uio.no
Mon Apr 4 00:49:11 CEST 2016

hi again, mike,

> With the separate properties list, you can do:
>     mrs.properties[mrs.index]
> or:
>     mrs.properties[mrs.rels[2].roles.ARG0]
> and get the same object back.

thanks for your thought regarding object references and the suggestion of
separating the full object representation of variables from their
occurrences throughout the MRS.  i adapted your proposal (and like this
version much better), though ended up with a full ‘variables’ property,
containing one entry for all MRS variable (including handles).  for one,
even though arguably redundant, i like making the variable type explicit
(rather than carving into stone our assumptions about variable naming
conventions); but more importantly, this way the distinction between
variable vs. constant values is explicit in the MRS, i.e. one need not
specify the inventory of constant-valued roles (e.g. CARG in the ERG) to
programmatically tell the difference between, say, "Abrams" and "h42".

i have added experimental MRS serialization to the RESTful interface:


> What I was withholding was that I tried requesting XML
> and got JSON instead of an error 406:

true, i am not currently interpreting incoming HTTP headers, hence arguably
ended up overly robust to the above request :-).  if i understand you
correctly, you would vote for an HTTP error code in the above scenario?
for actual errors during parsing, i have in principle opted for option 4
from the o'reilly post you pointed to (which is their recommendation for
anything but genuine HTTP errors), though i have yet to provide distinct
error codes and human-readable error messages (at present, i merely return
{\"readings\": -1}, as is the [incr tsdb()] convention).

—as regards interfacing through pyDelphin, for example, i have started to
play with a simple batch parsing client (attached below), but feel i am
running up against my pythonic inexperience already.  for example, i have a
hard time deciding which python version one should support: seeing as we
need to be able to include non-ascii characters in the URL submitted for
parsing, the urllib implementation in 2.7 is known to be inadequate.  how
would you approach this task?

alas, unicode limitations notwithstanding, the following appears to work at

$ tsdb -home $LOGONROOT/lingo/erg/tsdb/gold/csli \
  -query 'select i-input' | ./restful.py

bedtime now; more soon!  oe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160404/8b3a62c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: restful.py
Type: text/x-python
Size: 480 bytes
Desc: not available
URL: <http://lists.delph-in.net/archives/developers/attachments/20160404/8b3a62c1/attachment.py>

More information about the developers mailing list