[developers] Structured output from ACE

[Michael Wayne Goodman]

The restful interface currently embeds additional information in the
derivation tree when 'derivation=json' is requested. Here is an example
(also with 'tokens=json', which appears to produce the contents of :p-input
and :p-tokens):
http://erg.delph-in.net/rest/0.9/parse?derivation=json&tokens=json&input=Abrams%20arrived
.

The additional data in the derivation tree include, on each node:
 - "type" : the lexical or rule type
 - "label" : the short label

There's also a little bit of restructuring for preterminal nodes (compared
to the UDF tree). I can manage this transformation (although I don't yet
extract the "from" and "to" fields from the token TFS).

As long as the labeled :tree and :derivation trees are isomorphic, I can
embed "label" myself. "type" is not available, so I'm stuck there. If
something like an isomorphic :type-tree is made available, I could do the
same merger as with the labels.

On Thu, Jun 23, 2016 at 5:38 PM Woodley Packard <sweaglesw at sweaglesw.org>
wrote:

> Thanks, this is the type of feedback I was looking for.  Does the lexical
> type info fit into the restful interface, or is it something you'd like for
> other purposes?  There is of course all manner of information contained in
> the grammar that is not exposed by normal interfaces.
> -Woodley
>
>
>
> On Jun 23, 2016, at 5:30 PM, Michael Wayne Goodman <goodmami at uw.edu>
> wrote:
>
> Thanks, Woodley,
>
> I was able to compile ACE (with a change to Makefile to dynamically link
> libutil instead of statically; if anyone wants my notes for compiling just
> ask).
>
> The data now output by ACE will make things much easier, so thanks for
> that! I compared the output to what Stephan offers from his RESTful server,
> and note a couple of differences:
>
> 1. tcpu
> 2. rule and lexical types in the derivation (e.g. the "arrive_v1" in the
> derivation for "Abrams arrived." would have type "v_-_le")
>
> I can get (1) with --tsdb-notes, but when combined with --tsdb-stdout it
> is concatenated to the stdout line instead of appearing on its own. E.g.:
>     [...] (:aedges . 23) NOTE: tsdb parse:  (:total . 9) [...]
> Since the syntax is the same, maybe they can be concatenated without the
> "NOTE: tsdb parse: " string?
>
> As for (2), it's not part of UDF derivation trees, nor is it stored in
> [incr tsdb()] profiles as far as I know, so I don't think I can reasonably
> ask for this. It's not necessary, but it would be nice, if it is something
> ACE can easily provide. But I'm not sure where to put it (maybe in the
> :flags of a result?).
>
> Also, it seems the --tsdb-stdout is not working fully with generation. The
> surface string is being printed in the middle of the s-expression:
>
> $ echo "Abrams arrived." | ./ace -g ~/erg-1214-x86-64-0.9.23.dat | ./ace
> -g ~/erg-1214-x86-64-0.9.23.dat -e --tsdb-stdout --report-labels
> [...]
> (:results . (Abrams arrived.
> ((:result-id . 0)(:surface . "Abrams arrived.") [...]
>
> I assume you just got it working in ACE's SVN as a preview for parsing and
> not generation, so this is fine for now.
>
> Thanks again!
>
> On Thu, Jun 23, 2016 at 4:48 PM Stephan Oepen <oe at ifi.uio.no> wrote:
>
>> > The output is formatted as (a list of) s-expressions, and is identical
>> to
>> > the data sent to [incr tsdb()] [...]
>>
>> thanks, woodley.  that was in fact a thought i too had entertained
>> during the API discussion: my RESTful server actually works off [incr
>> tsdb()] item structures, so ACE communicating with different callers
>> in the outside world using that same format seems utterly plausible to
>> me :-).
>>
>> cheers, oe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160624/2cdf11b6/attachment-0001.html>