[developers] Export generated trees
oe at csli.Stanford.EDU
Thu Sep 15 12:28:37 CEST 2005
> > Do you or does anybody else know whether and how it is possible to
> > record the results of generation in [incr tsdb()]. Currently, I get
> > only the usual statistics, but no generated strings, derivations, or
> > trees.
> I've now figured out how to do it. For some reason or other the
> generator did not like the (Pet-supplied) input MRSes, so did not
> generate anything. With MRSes from LKB, I get all I need, trees, are
> there, once I treebank and normalise the output.
the [incr tsdb()] result processing in generation is pretty much the
same as for parsing. derivations should always be recorded. to get
labeled trees, set *tsdb-trees-hook* to something that, given an edge,
will extract the tree representation you want. e.g.
(setf *tsdb-trees-hook* "lkb::parse-tree-structure")
likewise, to record MRSs, say while parsing:
(setf *tsdb-semantix-hook* "mrs::get-mrs-string")
note, however, that these will blow up profile size and slow down batch
processing noticeably. hence, they are off by default. also, remember
that these LKB hooks will be invoked too when parsing with PET. given
the default value for
(defparameter *tsdb-result-hook* "tsdb::result-hook")
[incr tsdb()] will attempt to reconstruct derivations obtained from the
current processing client (e.g. PET) and invoke the trees or semantix
hooks if either have non-nil values. hence, what you may want during
generation, in turn, you may not want during parsing :-).
there is another way of getting these hooks called, viz. when operating
on a treebank, i.e. during a normalize or export. in this mode, there
are two parameters that mirror the above, viz.
(defparameter *redwoods-semantix-hook* nil)
(defparameter *redwoods-trees-hook* nil)
as, it seems, you get the labeled trees once you normalize, i suspect
that *redwoods-trees-hook* has a non-nil value.
finally, i find it more than a bit curious that MRSs generated from a
PET batch run should fail to generate, while LKB-produced ones work; it
is the same code, after all, that gets invoked here. i think it would
be good to find out what went wrong (probably something silly :-). if
you copied one of the PET MRSs into a file of its own, you could do:
the generator should run into an error() then, and you could use :zoom
et al. to work out what is going wrong. feel free to email the output,
should it be opaque!
best - oe
+++ Universitetet i Oslo (ILN); Boks 1102 Blindern; 0317 Oslo; (+47) 2285 7989
+++ CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++ --- oe at csli.stanford.edu; oe at hf.uio.no; stephan at oepen.net ---
More information about the developers