ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wu, Stephen T., Ph.D." <Wu.Step...@mayo.edu>
Subject Re: markable types
Date Thu, 15 May 2014 14:17:16 GMT
I think we could put Markable as a different child of
IdentifiedAnnotation.
But don't make sweeping changes to the type system (like add all
project-specific types) -- the other downside is that it makes the type
system constantly in flux.

stephen



On 5/11/14 7:47 AM, "Anirban Chakraborti"
<chakraborti.anirban@googlemail.com> wrote:

>Steven,
>
>Would you have any example code of tree parser so the output can be
>arranged as per need. I mean, after successful annotation, I want to
>extract certain concepts like medication only and arrange them in a new
>tree so that all annotation in reference to medication concept and their
>sources are listed together.
>
>Anir
>
>
>On Sun, May 11, 2014 at 3:55 PM, Steven Bethard
><steven.bethard@gmail.com>wrote:
>
>> I don't think "not something anyone would want extracted" should be an
>> argument against anything. We already have constituent and dependency
>> parse trees in the type system, and those would fall under that
>> category.
>>
>> So +1 on markables in the type system. (In general, +1 on moving
>> module-specific types to the standard type system. I'm not sure what
>> the real benefit of splitting them out is...)
>>
>> Steve
>>
>> On Fri, May 9, 2014 at 11:53 AM, Miller, Timothy
>> <Timothy.Miller@childrens.harvard.edu> wrote:
>> > What do people think about taking the "markable" types out of the
>> > coreference project and adding them to the standard type system? This
>>is
>> > a pretty standard concept in coreference that doesn't really have a
>> > great natural representation in the current type system -- it
>> > encompasses IdentifiedAnnotations as well as pronouns ("It", "him",
>> > "her") and some determiners ("this").
>> >
>> > The drawback I can see is that it is probably not something anyone
>>would
>> > want extracted -- ultimately you want the actual coref pairs or
>>chains.
>> > But it is useful for things like representing gold standard input or
>> > splitting coreference resolution into separate markable recognition
>>and
>> > relation classification steps.
>> >
>> > Tim
>> >
>>


Mime
View raw message