<div dir="ltr">Hi Stephan,<br><br><div class="gmail_quote"></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Mar 28, 2016 at 1:53 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dear colleagues,<br> <br> i used part of the easter break to teach myself about modern<br> technologies and are currently in the process of providing a RESTful<br> (programmatic) interface to the on-line ERG demonstrator. i know of<br> at least one colleague who has been waiting impatiently for this<br> functionality :-).<br> <br> in a nutshell, client software can now obtain parses using the HTTP<br> protocol and URIs providing the input string (and a handful of<br> optional parameters). for example:<br> <br> <a href="http://erg.delph-in.net/rest/0.9/parse?input=Abrams%20arrived" rel="noreferrer" target="_blank">http://erg.delph-in.net/rest/0.9/parse?input=Abrams%20arrived</a>.<br> <br> parsing results will be returned in machine-readable format,<br> serialized as a JSON document. for a little more background on how to<br> use this new service (including an example client in Python, believe<br> it or not), please see:<br> <br> <a href="http://moin.delph-in.net/ErgApi" rel="noreferrer" target="_blank">http://moin.delph-in.net/ErgApi</a></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>What a beautiful bike shed :)</div><div><br></div><div>BTW, Demophin has an undocumented HTTP API, but it's not RESTful:</div><div><br></div><div>$ curl -F 'sentence=Abrams arrived.' <a href="http://chimpanzee.ling.washington.edu/demophin/erg/parse" target="_blank">http://chimpanzee.ling.washington.edu/demophin/erg/parse</a><br></div><div><br></div><div>I had hoped to change it to follow the REST principles more closely and document the API, but I'm happy to know that you've already started that effort.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> there is some more work to be done on the interface (see the page<br> above), but i would like to ask for help already at this point:<br> <br> (0) in case you notice anything surprising in the interactive ERG<br> demonstrator, please do not hesitate to let me know!<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>If you're defining a new JSON schema for EDS, then maybe we can do something more convenient for, e.g., lnk values. Currently the indices are encoded in a string:</div><div><br></div><div> <span style="line-height:normal;white-space:pre-wrap">"lnk": "<0:6>"</span></div><div><span style="line-height:normal;white-space:pre-wrap"><br></span></div><div><span style="line-height:normal;white-space:pre-wrap">If we make it a JSON object, then users of the results wouldn't have to parse the string later:</span></div><div><span style="line-height:normal;white-space:pre-wrap"><br></span></div><div><span style="line-height:normal;white-space:pre-wrap"> "lnk": {"type": "charspan", "cfrom": 0, "cto": 6}</span></div><div><span style="line-height:normal;white-space:pre-wrap"><br></span></div><div><span style="line-height:normal;white-space:pre-wrap">(The "type" could be optional if we define "charspan" as the default, or if we pretend that the other types don't exist)</span></div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (1) i still need to provide a serialization of MRSs in JSON; in case<br> anyone has previously tackled this (design) problem, please do get in<br> touch!<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Not yet, sorry. One thing that comes to mind is that JSON doesn't have an unordered collection aside from objects (hashes), which require keys. So we could treat the RELS, HCONS, and ICONS bags as arrays (lists) (but we often do this anyway, so I think it's fine to use arrays). Here's a rather direct conversion:</div><div><br></div><div>{ "top": "h0", "index": "e2", "rels": [ {"pred": "proper_q", "lbl": "h3", "arg0": "x4"...}...]...}</div><div><br></div><div>One thing that isn't obvious is variable properties. They could follow the EDS example and put them in the EP object (and similarly be controlled by the "properties" parameter in the URL):</div><div><br></div><div>{ ..., "rels": [ { "pred": "named", ..., "properties": { "PERS": "3"}}, ... ], ...}</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (2) i think it might be nice to incorporate RESTful parsing as an<br> option in pyDelphin; mike, could you be interested in collaborating on<br> this?<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Yes. Whatever API we settle on, I'd like to incorporate that into pyDelphin and use it as the basis for Demophin as well.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> finally, i would be curious to hear comments or suggestions for how to<br> use and extend this service (though cannot promise i will have a lot<br> of time to develop this further until another holiday break); please<br> see towards the bottom of the above wiki page for some candidate<br> directions.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I've done a couple of REST APIs so far, so I have some suggestions (some are rather technical so I'm happy to save those for an off-list discussion).</div><div><br></div><div>One thing that might be relevant to others is how we can request other formats. I see you have parameters "eds=...", "derivation=...", "mrs=...", so presumably we could expand it with others ("rmrs=...", "dmrs=...", etc.)?</div><div><br></div><div>Other ideas:</div><div>* what about generation?</div><div>* can set a request header for preprocessing? (e.g. morphological segmentation for Jacy or Zhong)</div><div>* If we have already preprocessed, can we specify the Content-Type (e.g. Content-Type: application/yy)</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> best wishes; god påske! oe<br> <br> </blockquote></div></div></div>