[developers] RESTful ERG parsing

[Ned Letcher]

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/20160423/b66935bb/attachment.html>