[lkb] Getting Parse results from LKB

[Bernhard Fisseni]

Dear Stephan,

thanks for your quick and patient reply!

However, it seems that LKB and I have problems communicating to each 
other...

Scripsit Stephan Oepen diē 16.10.2006 13:58:
> if what you are primarily interested in are labeled parse trees, e.g.
> 
>   (S (NP "kim") (VP (V "arrived")))
> 
> then you will need to involve the LKB, as PET (for now) has no option
> to do the label assignment (which is done post-parsing, and entirely a
> display convenience).  the ERG and GG on-line web interfaces are a tad
> more complex: they run PET behind [incr tsdb()] for improved effiency;
> but to get the labeled parse trees, after parsing, the derivation tree
> returned by PET is re-built in the LKB (like deterministic parsing), so
> as to then read off the tree node labels.

This sounds indeed a lot more complex than what we need.  In fact, I'd 
be happy to "just" have a feature structure showing at least the 
functional relationships and syntactic dependencies.  This information 
must be used during the parsing process, and from Berthold's post I 
gather that some access to this information is possible.

> unless efficiency becomes a concern, i would suggest just running the
> LKB in tty mode and talking to it through standard in- and output.  the
> Linux run-time binaries should be feasible, just unset DISPLAY so as to
> suppress the GUI.  then, writing a command like
> 
>   (do-parse-tty "Kim arrived")
> 
> to the stdin of the LKB process should return one or more trees, which
> you should be able to read off its stdout.

Unsetting DISPLAY does not work for me — LKB generates an error message 
saying that the display cannot be accessed; with DISPLAY set, a graphic 
tree is shown, even for "do-parse-tty".

> regarding CLISP or SBCL, have you tried?  in theory, the source should
> compile okay in either one, although then functionality will be limited
> to tty mode.  also, CLISP would not be your most efficient choice, and
> rumour has that it the default memory layout in SBCL is insufficient
> for large grammars (like the ERG or GG).

Yes, I tried, and both of them failed during compilation – that's why I 
asked.  It seemed to me that CLISP was not ignoring some Allegro-related 
  code as it should have, and sbcl at least had problems discovering an 
Intel Mac; yet, on Linux (Kubuntu), it fails, too, with the error message:

   debugger invoked on a COMMON-LISP:TYPE-ERROR in thread #<THREAD 
"initial thread" {A62F569}>:
     The value EXTRA is not of type COMMON-LISP:LIST.

If you're interested in the log, I'll gladly send it to you, but 
according to Ann Copestake's Mail <E1GKGWs-00013I-00 at mta1.cl.cam.ac.uk>, 
LKB doesn't compile with SBCL yet.  As we don't use LISP very much, we 
don't have any Allegrom license, which seems to be necessary if we want 
to do painless modifications to LKB, it seems.  I was just hoping you'd 
already have found the right LISP voodoo for parasites like us to get 
away taking advantage of your work using cheap LISPs. ;-)


Thanks again for your suggestions,
Bernhard