[developers] LKB vs. PET divergences

Ann Copestake Ann.Copestake at cl.cam.ac.uk
Mon Feb 14 15:41:10 CET 2005

I don't have PET here, but what seems to be going on is a discrepancy in the 
way that the glb is being computed or a discrepancy in the way that
the rule is being treated.  

vstem-vstem-rule is defined as 

vstem-vstem-rule := head-final-type & 
		    orth-princ &

the LKB gives glbtype71 as the glb of those two.  This is a subtype of 
argument-binding-princ which brings in the coindexation between the HOOK of 
the mother and the HOOK of the HEAD-DTR.  head-final-type sets the HEAD-DTR to 
the second DTR.  So the coindexation is as expected if glbtype71 is the type.

Should glbtype71 inherit from argument-binding-princ?  Well, I'd say it's 
plausible, given that the glbtypes are supposed to minimize the hierarchy.  
head-final-type has four immediate subtypes: head-specifier-rule-type, 
head-complement-hf-type and head-subject-rule.  These are all subtypes of 
orth-princ, but they are also all subtypes of argument-binding-princ.

Possibly, PET is creating a new `pure' glbtype at the point when the 
definition of vstem-vstem-rule is read in.  This would be incorrect - as 
stated in the previous message, the formalism says that this is just a 
description of a feature structure.  We don't allow the calculation of new 
glbs during unification in general and it shouldn't be allowed here.

Alternatively, we have a discrepancy in the glb calculation algorithm, which 
would also be possible, though horrible to fix.  If there's a formal 
definition of glbtype introduction which says whether it is or is not supposed 
to introduce pure types in this situation, then we can decide which behaviour 
is correct.


More information about the developers mailing list