thanks for sharing your RESTful client, ned; i am beginning to realize some of the appeal of 21st century technologies :-). and thanks too for the suggestions regarding additional information that would be useful to have in the derivations! i hope to implement all three (labels and types on all nodes, characterization on the leafs) very soon.<div><br></div><div>cheers, oe</div><div><span></span><br><br>On Saturday, April 23, 2016, Ned Letcher <<a href="mailto:ned@nedned.net">ned@nedned.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Hello again,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">our RESTful service at <a href="http://erg.delph-in.net/rest/0.9/" rel="noreferrer" target="_blank">http://erg.delph-in.net/rest/0.9/</a> now supports<br>
CORS (i.e. provides the ‘Access-Control-Allow-Origin: *’ header). i<br>
hope this much will be sufficient for you to escape the cross-domain<br>
limitations in your JavaScript client, ned?<br></blockquote><div><br></div><div><span style="line-height:1.5">Ah excellent! It is indeed. Proof of which can be found here: </span><a href="http://ned2.github.io/delphin-viz/demo/" style="line-height:1.5" target="_blank">http://ned2.github.io/delphin-viz/demo/</a><span style="line-height:1.5"> It's essentially a minimal clone of the LOGON demo. It only supports viewing derivations currently, which are SVGs generated using code taken and adapted from Woodley's full forest treebanker (which I also used for rendering trees in Typediff).</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">i am delighted you are developing this client already, but i need to<br>
caution that (a) mike and i are still discussing minor modificitions<br>
to the JSON serialization for MRS and that (b) there appears to be a<br>
bug in the JSON representation of multi-token leaf nodes in the<br>
derivation. i hope to have both resolved over the next few days!<br></blockquote><div><br></div><div>Understood, and this is only to be expected for an API under development.</div><div><br></div><div><div>As far as the API is concerned, I found it to be quite accessible and seems to cover the basics with respect to the needs of visualising the derivations -- with the obvious exception of the shorthand node labels still to come. </div><div><br></div><div>From my own perspective, there are two additional pieces of data that I made use of for the Typediff trees, which I believe could also add value to the ERG API. One is including the lexical type name for nodes corresponding to lexical entries. I personally prefer derivation trees rendered with lexical type names rather than lex entry identifiers -- and in the case of Typediff, this was an explicit design choice. Perhaps this could be a user configurable option in my demo. </div><div><br></div><div>The other is including TO and FROM values within derivation nodes to map sub-trees onto the corresponding character spans in the original string. While not as enlightening as in the case of doing this for predications---since the surface yield of a derivation is a little easier to see directly in the tree---I still feel like the input highlighting would be a useful feature. I guess I could manually extract them from the contents of the 'tokens' attribute, however this will make the client dependant on the ERG's token mapping setup and my understanding is that this can vary from grammar to grammar? Although, to be fair, this is only advertised as an 'ERG' API. That said, this still feels like lower level implementation logic that an API should smooth over.</div><div><br></div><div>Cheers,</div><div>Ned</div><div class="gmail_quote"></div></div></div></div>
</blockquote></div>