[developers] RESTful ERG parsing

[Stephan Oepen]

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.

cheers, oe


On Saturday, April 23, 2016, Ned Letcher <ned at nedned.net> wrote:

> Hello again,
>
>
>> our RESTful service at http://erg.delph-in.net/rest/0.9/ now supports
>> CORS (i.e. provides the ‘Access-Control-Allow-Origin: *’ header).  i
>> hope this much will be sufficient for you to escape the cross-domain
>> limitations in your JavaScript client, ned?
>>
>
> Ah excellent! It is indeed. Proof of which can be found here:
> http://ned2.github.io/delphin-viz/demo/ 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).
>
> i am delighted you are developing this client already, but i need to
>> caution that (a) mike and i are still discussing minor modificitions
>> to the JSON serialization for MRS and that (b) there appears to be a
>> bug in the JSON representation of multi-token leaf nodes in the
>> derivation.  i hope to have both resolved over the next few days!
>>
>
> Understood, and this is only to be expected for an API under development.
>
> 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.
>
> 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.
>
> 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.
>
> Cheers,
> Ned
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160424/baa42d59/attachment.html>