incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Masanz, James J." <Masanz.Ja...@mayo.edu>
Subject RE: cTAKES modules for temporal information extraction
Date Wed, 10 Oct 2012 16:26:49 GMT
Agree with Pei on all points.


> -----Original Message-----
> From: ctakes-dev-return-558-Masanz.James=mayo.edu@incubator.apache.org
> [mailto:ctakes-dev-return-558-
> Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> Sent: Wednesday, October 10, 2012 11:24 AM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: cTAKES modules for temporal information extraction
> 
> +1 for putting ctakes-temporal in trunk
> We should be able to have the ability to selective pick the
> modules/projects that goes into a particular release.
> 
> I think any projects that will eventually make it to a release, I would
> vote for putting it in trunk.
> For any questionable projects that we're just experimenting with, I
> would suggest the sandbox area.  On top of the cross-project
> dependencies you mentioned, another benefit is that we can really take
> advantage of the community vs a custom area that not everyone may be
> aware of.
> 
> --Pei
> 
> 
> > -----Original Message-----
> > From: Steven Bethard [mailto:steven.bethard@Colorado.EDU]
> > Sent: Wednesday, October 10, 2012 12:00 PM
> > To: ctakes-dev@incubator.apache.org
> > Subject: cTAKES modules for temporal information extraction
> >
> > As part of the THYME project [1], we're developing cTAKES modules for
> > identifying events, times and temporal relations. Where should these
> > go? I see a few possibilities:
> >
> > (1) We add a ctakes-temporal module to ctakes trunk. This is good
> > because it's where the final module will go, it makes it easy to
> > compile with any cross- project dependencies, and anyone makes any
> > changes that break the ctakes-temporal code, they'll be immediately
> obvious with compile errors.
> > The downside might be that if it's not 100% ready for release by the
> > time the 3.0.0-incubating release rolls around, we need to find a way
> > to exclude it from that release.
> >
> > (2) We host it somewhere else and move it into ctakes when it's 100%
> > ready for release. We're already doing this now, at
> > https://github.com/bethard/ctakes-temporal, but we could also put it
> > in the cTAKES sandbox. The downsides are that it's harder to get the
> > cross-project dependencies to work (especially on the command line
> > with Maven and SNAPSHOT versions), that breaking changes in cTAKES
> > will only be visible to people who have separately checked out ctakes-
> temporal, etc.
> >
> > What do people think?
> >
> > And in general, what should be the process for introducing new cTAKES
> > modules?
> >
> > Steve
> >
> > [1]
> > http://clear.colorado.edu/compsem/index.php?page=endendsystems&sub
> > =temporal

Mime
View raw message