Mailing-List: contact dev-help@ctakes.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ctakes.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Wu, Stephen T., Ph.D." <Wu.Stephen@mayo.edu>
To: "dev@ctakes.apache.org" <dev@ctakes.apache.org>
Subject: Re: CEM Template Question
Thread-Topic: CEM Template Question
Thread-Index: AQHOmulPx/QsHE2eH0SG1tPZp+Yxq5mZFrWAgASDC4CAA8HwgA==
Date: Thu, 22 Aug 2013 15:03:31 +0000
Message-ID: <CE3B8F93.7398%wu.stephen@mayo.edu>
In-Reply-To: <924DE05C19409B438EB81DE683A942D910588E15@CHEXMBX1A.CHBOSTON.ORG>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.1.130117
Old-x-esetresult: clean, is OK
Old-x-esetid: 4CBF7B3EAE8F333416FC26
Content-Type: text/plain; charset="us-ascii"
Content-ID: <564715B21756CB4B94631853D7248F12@exchange.mayo.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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" <Pei.Chen@childrens.harvard.edu> 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 [steven.bethard@gmail.com]
>Sent: Monday, August 19, 2013 2:12 PM
>To: dev@ctakes.apache.org
>Subject: Re: CEM Template Question
>
>On Fri, Aug 16, 2013 at 8:29 PM, Pei Chen <chenpei@apache.org> 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 <chenpei@apache.org> 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