[developers] LKB vs. PET divergences

Melanie Siegel siegel at dfki.de
Mon Feb 14 15:40:04 CET 2005


Hi,
I've moved the definitions to the rule types (and let the instance 
inherit from one type only), and it looks right now. It's in CVS.

Melanie

Stephan Oepen wrote:

> hi again,
> 
> francis is still visiting, cracking the whip.  so we sat down to debug
> an unpleasant problem: the LKB and PET producing different results for
> some inputs.  after many hours staring at feature structures, it seems
> the problem originates in different `interpretations' of one rule from
> the grammar, viz. the `vstem-vstem-rule'.  i attach the AVMs for just
> the rule below (`dag.lkb' vs. `dag.pet'), so you will quickly see that
> the LKB has
> 
>   [ SYNSEM.LOCAL.CONT.HOOK #0, C-CONT.HOOK #0 ]
>   --> [ ], [ SYNSEM.LOCAL.CONT.HOOK #0 ]
> 
> whereas PET lacks the coreference with the HOOK of the second daughter.
> this would explain why PET sometimes finds additional derivations, i.e.
> ones that later fail to re-build in the LKB when treebanking.
> 
> looking at the definition of this rule in `japgram.tdl' and walking up
> the type hierarchy a little, we fail to see why the coreference should
> be there (the one to the second daughter, that is).  but given general
> exhaustion and the power of well-formed unification, we feel not quite
> certain of our analysis (having to assume that either the LKB or PET
> could be incorrect was hard enough :-).
> 
> hence, we are hoping experts in the grammar or formalism could give it
> a critical look over-night?  i attach the full grammar and the two DAG
> representations for the rule.  how many re-entrancies for HOOK should
> we expect to see in a fully expanded, well-formed `vstem-vstem-rule'?
> 
> looking at the definition of the rule, i also noticed it uses multiple
> supertypes in the instance definition.  this is generally illegal, but
> happens to succeed in this case, because for:
> 
>   vstem-vstem-rule := head-final-type & orth-princ & [...]
> 
> there appears to be a glb in the type hierarchy.  both systems seem to
> compile the above without complaint, but i believe the above situation
> should be flagged or outright rejected as syntactically ill-formed.
> 
>                                                        cheers  -  oe
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++ Universitetet i Oslo (ILF); 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 ---
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-- 
---------------------------- at -|- at --------------------
Dr. Melanie Siegel	siegel at dfki.de
DFKI GmbH		Tel: (+49 681) 302-5288
Stuhlsatzenhausweg 3	Fax: (+49 681) 302-5338
D-66123 Saarbruecken	http://www.dfki.de/~siegel/
-----------------------------------------------------





More information about the developers mailing list