SUBJECT: Re : &NAME Hi &NAME , continuing on from the last email I sent , sorry about the delay - my code is like a badly sown dress - I pull &NUM thread and spend the next few hours finding where I pulled it apart ! ! anyway here are the results , as in the last email tungsten example might not result in increase in &NAME , although better than before . question &NUM however does improve when using a partial &NAME here , ' her ' is resolved to ' actress ' , ' &NAME ' , and ' &NAME ' through &NAME her - &NAME resolution . As there are very few &NAME matches , the direct substitution results in improvement for these cases . Perhaps that is a further argument that combined with more complex system that incorporates NE - the system could prefer equal ranking sentences in which the required NE occurs etc ? anyway table &NUM again ! : &WEBSITE &CHAR &CHAR &CHAR &CHAR &NAME - the normal run &NAME baseline + antecedent - manual replacement of sentences + direct substitution - automatic substitution of the pronoun for the antecedent in the original submission sentences . &NAME - only related &NAME elements &NAME - all elements The only example where the inner improved using the partial &NAME was in the case of question &NUM where the context was : ' &NAME &NAME &NAME , mistress of &NAME &NAME &NAME , has been dead for almost &NUM years , but someone remembers . Earlier this week , a fan left a red rose on her mausoleum in &NAME Memorial Park . Dear &NAME , you are still loved and missed , read the accompanying note . ' The original submission sentence read : ' &NAME &NAME &NAME , mistress of &NAME &NAME &NAME , has been dead for almost &NUM years , but someone remembers . ' however , after pulling in ' actress ' , ' &NAME ' and ' &NAME ' ( as all &NUM had ' &NAME ' arg ) the &NAME selected the correct ( following ) sentence : Earlier this week , a fan left a red rose on her mausoleum in &NAME Memorial Park . Earlier this week , a fan left a red rose on actress &NAME &NAME mausoleum in &NAME Memorial Park . The real problem is that the shallow parsed &NAME structures result in very few &NAME elements - so the &NAME system is already based mainly upon &NAME and CARG matches . Therefore without &NAME &NAME representations to start with you are almost always only pulling in the antecedent itself . hope that 's ok - I 'll be home tomorrow morning if you need to call me ! &NAME : ) On &NAME &NUM &NUM , &NAME &NAME wrote : <QUOTE> Here is the almost final version . I am off home now , but will check my email later to include any further comments / results . I 've revised the script to deal with comments , the &NAME paper and your new results , there are a couple of ? ? &CHAR where I 'll put in results for an intermediate approach incorporating just predications with a direct link to the variable in the antecedent head . If thy do n't materialise by tomorrow evn I 'll just blather ... &NAME <END_QUOTE>