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: domain of
 chakraborti.anirban@googlemail.com designates 209.85.216.51 as permitted
 sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANuf76N_fDPa78OxnR9MAOgX8jp8AvKPR7hUOWJzyB0fSacO5Q@mail.gmail.com>
References: <E084D8EFE2B03A408B324458C5212E942449E7EC@CHEXMBX3A.CHBOSTON.ORG>
	<CANuf76N_fDPa78OxnR9MAOgX8jp8AvKPR7hUOWJzyB0fSacO5Q@mail.gmail.com>
Date: Sun, 11 May 2014 18:17:53 +0530
Message-ID: 
 <CAD_Tc=nGFHpeUv_dJwfjr+K0vQMGMqiCL_hq5Wcu3YbkPtRv+Q@mail.gmail.com>
Subject: Re: markable types
From: Anirban Chakraborti <chakraborti.anirban@googlemail.com>
To: dev@ctakes.apache.org
Content-Type: multipart/alternative; boundary=001a11c1641e4173ec04f91f3d03

--001a11c1641e4173ec04f91f3d03
Content-Type: text/plain; charset=UTF-8

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
> >
>

--001a11c1641e4173ec04f91f3d03--