incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Pei" <Pei.C...@childrens.harvard.edu>
Subject RE: ctakes-resources
Date Fri, 05 Oct 2012 16:34:45 GMT
> 1. If referencing UIMA descriptors via name, make sure the descriptor name
> attribute and the filename are the same (not including the .xml).
> 2.  In DictionaryLookupAnnotatorUMLS.xml there is a reference to the UMLS
> hsqldb via file path.  To change it to class path, see the changes below

Thanks Brandyn and Co. for that excellent suggestion! It worked like a charm...
Since the resources and type systems have been automagically added to the classpath/jars by
maven, we can reference them by name easily now without having to worry about those relative
../../.. locations.  We'll see if we could do the same for the AnalysisEngines in the future
as well.

        <import name="org.apache.ctakes.assertion.types.TypeSystem"/>
        <import name="org.apache.ctakes.typesystem.types.TypeSystem"/>


> -----Original Message-----
> From: Kusenda, Brandyn J [mailto:brandyn-kusenda@uiowa.edu]
> Sent: Wednesday, September 26, 2012 11:05 AM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: ctakes-resources
> 
> Hello,
> 
> I've have some of the classpath related changes working on my local copy of
> cTAKES.  Here are a couple of things I discovered, that might save you some
> time.
> 
> 1. If referencing UIMA descriptors via name, make sure the descriptor name
> attribute and the filename are the same (not including the .xml).
> 
> 2.  In DictionaryLookupAnnotatorUMLS.xml there is a reference to the UMLS
> hsqldb via file path.  To change it to class path, see the changes below
> 
> Original using file path:
> --SNIP--
> <nameValuePair>
>        <name>URL</name>
>        <value>
>               <string>jdbc:hsqldb:file:../dictionary
> lookup/resources/lookup/umls2011ab/umls</string>
>        </value>
> </nameValuePair>
> --SNIP--
> 
> Updated to use class path if the lookup directory is in the
> /src/main/resources/  (notice the use of 'res' as oppose to 'file' in the
> connection string)
> -SNIP-
>  <nameValuePair>
>         <name>URL</name>
>         <value>
>               <string>jdbc:hsqldb:res:lookup/umls2011ab/umls</string>
>        </value>
> </nameValuePair>
> --SNIP--
> 
> Thanks,
> Brandyn
> 
> ________________________________________
> From: Chen, Pei [Pei.Chen@childrens.harvard.edu]
> Sent: Tuesday, September 25, 2012 4:22 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: ctakes-resources
> 
> I think Brandyn and others had a reasonable suggestion to use the name
> instead of location paths in those pesky descriptor xml files- Assuming
> they're in the classpath (placed in src/main/resources).
> I'll take a stab at this later this week if I get a chance.  But trunk *should*
> compile now in case other want to start working on it.  Apologies in advanced
> if I broke someone's build at this point- it was a pretty large change...
> 
> Troy: If we do this correctly, this should be transparent (if not easier) to end-
> users.
> 
> > -----Original Message-----
> > From: Coarr, Matt [mailto:mcoarr@mitre.org]
> > Sent: Tuesday, September 25, 2012 11:16 AM
> > To: ctakes-dev@incubator.apache.org
> > Subject: Re: ctakes-resources
> >
> > Trying to distill some of the suggestions...
> >
> > Could we have two top level directories in svn -- main-modules and
> > resource-modules?  And then below resource-modules we could have
> > dictionary-lookup-resources, lvg-resources, etc.
> >
> > * (ctakes svn trunk)
> >   * main-modules
> >     * core
> >     * clinical-documents-pipeline
> >     * dictionary-lookup
> >     * lvg
> >   * resource-modules
> >     * dictionary-lookup-resources
> >     * lvg-resources
> >
> > This means you could just checkout main-modules and keep it pretty
> > small (mostly just code and descriptors).  Then you can checkout "main-
> modules"
> > a a few times to have different working directories without taking up
> > too much space (perhaps a working copy for trunk development, another
> > for clean copy of latest release, a third for an experimental branch,
> > and perhaps a fourth for a branch to patch the last release).  But
> > they could all use the same resources.
> >
> > And ideally, most users and developers could pull those resources from
> > the maven repository as an artifact, unless they were working on
> > packaging up a new version of those resources.
> >
> > Matt


Mime
View raw message