Yeah, Steve is right -- we did this to mirror the Knowtator annotation schema. Removing the relation between them would make it difficult to find and account for relation attributes.
I think there's a pretty convincing argument for relations being somewhat "supporting" annotations. Coreference and all other relations would essentially help you fill in your attribute values (e.g., mention.setbodyLocation()). I think this ends up being cleaner overall, since an end user of the CAS then has the ability to look at Mentions without looking at Relations. So I think I'm a +1. There are only a few relation-valued attributes for each mention, so I expect changes would be fairly local within the relation-extractor project. What do you think about the refsem types -- e.g., should the attributes within DiseaseDisorder changed, similar to how we plan to change DiseaseDisorderMention? stephen On 8/19/13 7:40 PM, "Chen, Pei" <[email protected]> wrote: >That's a good point. >From a pragmatic perspective, my vote would be to have the >XMention.getBodyLocation() return a AnatomicalSiteMention and similar for >Severity etc. >If the relation was negated (there was no relation), then I think the CEM >template filler can just not create the relation. >For the extremely rare cases where they need to differentiate the null vs >explicit negated case, they can still iterate though the >BinaryTextRelations because we didn't lose the data. > >--Pei >________________________________________ >From: Steven Bethard [[email protected]] >Sent: Monday, August 19, 2013 2:12 PM >To: [email protected] >Subject: Re: CEM Template Question > >On Fri, Aug 16, 2013 at 8:29 PM, Pei Chen <[email protected]> wrote: >> Hi James/Steven, >> In the common type system/template fillers, do you recall why we stored >>the >> TextRelation instead of the resolved annotation? >> >> For example, in SignSymptomMention, getBodyLocation() returns >> LocationOfTextRelation. >> So in order to actually get the AnatomicalSiteMention, you would have to >> look inside LocationOfTextRelation arg1 or arg2. > >Yeah, I really didn't like this either, but this is what's in the >actual Knowtator data. The one argument I've heard for it is that the >LocationOfTextRelation could be negated, even when the >AnatomicalSiteMention was not. I believe the idea would be to >distinguish between: > >* The lesion was not on the left lung >* There was no lesion on the left lung > >where the former asserts that there was a lesion but negates the >location, and the latter asserts the lack of a lesion. To support this >kind of thing, either getBodyLocation() has to return a >LocationOfTextRelation with an appropriate polarity attribute, of >there has to be some other mechanism for specifying the polarity, etc. >of the body location relation. > >All that said, this was just got said to me once or twice. I have no >idea if the annotators even annotated this way or not. If they didn't, >I agree that the LocationOfTextRelation as the bodyLocation feels >super clunky and it would be great to fix that. > >Steve > >On Fri, Aug 16, 2013 at 8:29 PM, Pei Chen <[email protected]> wrote: >> Hi James/Steven, >> In the common type system/template fillers, do you recall why we stored >>the >> TextRelation instead of the resolved annotation? >> >> For example, in SignSymptomMention, getBodyLocation() returns >> LocationOfTextRelation. >> So in order to actually get the AnatomicalSiteMention, you would have to >> look inside LocationOfTextRelation arg1 or arg2. >> >> I think it be more intuitive and simpler for consumers of the CEM's to >>just >> store the AnatomicalSiteMention? Is there a use case I am missing where >> someone would want something different than the >> SignSymptomMention.getBodyLocation() other than the actual >> AnatomicalSiteMention? >> >> --Pei
