<div dir="ltr">hi again, mike,<br>
<br>
> With the separate properties list, you can do:<br>
> mrs.properties[mrs.index]<br>
> or:<br>
> mrs.properties[mrs.rels[2].roles.ARG0]<br>
> and get the same object back.<br>
<br>
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".<br>
<br>
i have added experimental MRS serialization to the RESTful interface:<br>
<br>
<a href="http://erg.delph-in.net/rest/0.9/parse?mrs=json&input=Abrams+arrived" target="_blank">http://erg.delph-in.net/rest/0.9/parse?mrs=json&input=Abrams+arrived</a>.<br>
<br>
> What I was withholding was that I tried requesting XML<br>
> and got JSON instead of an error 406:<br>
<br>
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).<br>
<br>
—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?<div><br></div><div>alas, unicode limitations notwithstanding, the following appears to work at least:<br><br>$ tsdb -home $LOGONROOT/lingo/erg/tsdb/gold/csli \<br> -query 'select i-input' | ./restful.py<br></div><div>
<br></div><div>bedtime now; more soon! oe<br><br>
</div>
</div>