You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by "Miller, Timothy" <Ti...@childrens.harvard.edu> on 2013/06/01 13:53:18 UTC

Re: upgrade ClearTK dependency to 1.4.0?

Maybe a good way to do this is to create a big jira and break it up into
module-level jira's, then assign a person to each, and for each module:
1) Upgrade pom to latest release for modules being used
2) Recompile/retrain/retest and check in
3) Close jira for that module

Then have one last issue that is to
1) upgrade project-level pom managed versions to latest release
2) revert module-level poms to use managed versions
3) run tests and checkin

How does that plan sound?
Tim

On 05/30/2013 11:06 PM, Steven Bethard wrote:
> On May 30, 2013, at 8:38 PM, "Masanz, James J." <Ma...@mayo.edu> wrote:
>> As a first pass, can we update the dependency to ClearTK 1.4.0 without retraining the models --  would retraining be necessary even if we didn't switch to LIBLINEAR.
> Retraining might still be necessary for anything that uses CleartkExtractor, since generation of out-of-bounds features has improved:
>
> https://groups.google.com/forum/#!topic/cleartk-users/KS2BLQcT-ds
>
> But anything not using CleartkExtractor should be safe. And even the things that are using CleartkExtractor may not degrade much if the out-of-bounds features aren't very important. But we'd need to test it a bit to see.
>
> Steve
>
>
>> Just wonder if we have an option for staging this, in case we can't tackle it all now.
>>
>> -----Original Message-----
>> From: dev-return-1646-Masanz.James=mayo.edu@ctakes.apache.org [mailto:dev-return-1646-Masanz.James=mayo.edu@ctakes.apache.org] On Behalf Of Steven Bethard
>> Sent: Thursday, May 30, 2013 5:45 PM
>> To: ctakes-dev@incubator.apache.org
>> Subject: upgrade ClearTK dependency to 1.4.0?
>>
>> I just released ClearTK 1.4.0 and there are a couple of reasons we should probably consider updating the cTAKES dependency:
>>
>> (1) ClearTK 1.4.0 can now load trained models from the classpath, so we could get rid of the workaround org.apache.ctakes.relationextractor.ae.RelationExtractorAnnotator.allowClassifierModelOnClasspath.
>>
>> (2) ClearTK 1.4.0 has wrappers for multi-class classification with LIBLINEAR which is orders of magnitude faster than LIBSVM.
>>
>> The main downside is that models will have to be re-trained. (It's not necessarily the case that all models would need to be retrained, depending on exactly which classes they were using, but it's probably safer to do so.)
>>
>> I believe this would mostly affect ctakes-temporal, ctakes-relation-extractor and ctakes-assertion.
>>
>> Thoughts?
>>
>> Steve
>>
>> P.S. I noticed that ctakes-assertion declares a dependency on cleartk-examples. The cleartk-examples module was never intended for release, and has not been released as part of ClearTK 1.4.0. Looking at the code, it seems like the dependency in cleartk-examples is not needed, but perhaps a ctakes-assertion person could weigh in on why this dependency was there?
>


Re: upgrade ClearTK dependency to 1.4.0?

Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
+1
Sounds like a good plan. 

On Jun 1, 2013, at 7:54 AM, "Miller, Timothy" <Ti...@childrens.harvard.edu> wrote:

> Maybe a good way to do this is to create a big jira and break it up into
> module-level jira's, then assign a person to each, and for each module:
> 1) Upgrade pom to latest release for modules being used
> 2) Recompile/retrain/retest and check in
> 3) Close jira for that module
> 
> Then have one last issue that is to
> 1) upgrade project-level pom managed versions to latest release
> 2) revert module-level poms to use managed versions
> 3) run tests and checkin
> 
> How does that plan sound?
> Tim
> 
> On 05/30/2013 11:06 PM, Steven Bethard wrote:
>> On May 30, 2013, at 8:38 PM, "Masanz, James J." <Ma...@mayo.edu> wrote:
>>> As a first pass, can we update the dependency to ClearTK 1.4.0 without retraining the models --  would retraining be necessary even if we didn't switch to LIBLINEAR.
>> Retraining might still be necessary for anything that uses CleartkExtractor, since generation of out-of-bounds features has improved:
>> 
>> https://groups.google.com/forum/#!topic/cleartk-users/KS2BLQcT-ds
>> 
>> But anything not using CleartkExtractor should be safe. And even the things that are using CleartkExtractor may not degrade much if the out-of-bounds features aren't very important. But we'd need to test it a bit to see.
>> 
>> Steve
>> 
>> 
>>> Just wonder if we have an option for staging this, in case we can't tackle it all now.
>>> 
>>> -----Original Message-----
>>> From: dev-return-1646-Masanz.James=mayo.edu@ctakes.apache.org [mailto:dev-return-1646-Masanz.James=mayo.edu@ctakes.apache.org] On Behalf Of Steven Bethard
>>> Sent: Thursday, May 30, 2013 5:45 PM
>>> To: ctakes-dev@incubator.apache.org
>>> Subject: upgrade ClearTK dependency to 1.4.0?
>>> 
>>> I just released ClearTK 1.4.0 and there are a couple of reasons we should probably consider updating the cTAKES dependency:
>>> 
>>> (1) ClearTK 1.4.0 can now load trained models from the classpath, so we could get rid of the workaround org.apache.ctakes.relationextractor.ae.RelationExtractorAnnotator.allowClassifierModelOnClasspath.
>>> 
>>> (2) ClearTK 1.4.0 has wrappers for multi-class classification with LIBLINEAR which is orders of magnitude faster than LIBSVM.
>>> 
>>> The main downside is that models will have to be re-trained. (It's not necessarily the case that all models would need to be retrained, depending on exactly which classes they were using, but it's probably safer to do so.)
>>> 
>>> I believe this would mostly affect ctakes-temporal, ctakes-relation-extractor and ctakes-assertion.
>>> 
>>> Thoughts?
>>> 
>>> Steve
>>> 
>>> P.S. I noticed that ctakes-assertion declares a dependency on cleartk-examples. The cleartk-examples module was never intended for release, and has not been released as part of ClearTK 1.4.0. Looking at the code, it seems like the dependency in cleartk-examples is not needed, but perhaps a ctakes-assertion person could weigh in on why this dependency was there?
>