ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Karl Thompson <...@northwestern.edu>
Subject RE: InputSteam instead of java.io.File
Date Tue, 11 Jun 2013 18:34:20 GMT
Hi Pei,

On another note, I've been working on a Groovy-based domain specific language (DSL) for UIMA/cTAKES
that I think has some nice features that would be of interest to the community. It allows
for quick development of compact and powerful rule-based annotators. As I'm working on this,
I'm integrating it with the cTAKES type system. Is there a cTAKES sandbox repository for such



-----Original Message-----
From: Chen, Pei [mailto:Pei.Chen@childrens.harvard.edu] 
Sent: Tuesday, June 11, 2013 12:50 PM
To: dev@ctakes.apache.org
Subject: InputSteam instead of java.io.File

While working on the test cases in cTAKES, I've encountered couple of issues and suggestions:

1)      File or Url.getRawPath() became problematic if they are read in from the jars from
the classpath and which couldn't resolve to a physical File.

a.       Suggestion: Wherever possible, replace loading of resouces via java.io.File with
InputStream instead.  . We can add a new method in the FileLocator util and deprecate the
old File method.

2)      Sentence Dectector is still using the OpenNLP 1.4 mechanism of loading it's model

a.       Suggestion: Let's update it to use the new 1.5 way similar to POSTagger.  (Remove
non longer required classes: SuffixMaxentModelResourceImpl, MaxentModelResource, SuffixSensitiveGISModelReader,
classes etc.)

Certain unit tests fail because they can't be resolved via jars from the classpath because
the code is explicitly looking for File on disk instead of input stream.  But in order to
solve it appropriately, it had a cascading effect and required a lot more changes, but it's
probably a good time to update those projects anyhow.


View raw message