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" <[email protected]> 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 ><[email protected]>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 >> <[email protected]> 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 >> > >>
