I agree with about (b)
> -----Original Message----- > From: [email protected] [mailto:dev- > [email protected]] On Behalf Of Steven > Bethard > Sent: Friday, March 29, 2013 8:27 AM > To: [email protected] > Subject: Re: [DISCUSS] Where should cTAKES models live? > > On Mar 29, 2013, at 7:09 AM, "Chen, Pei" <[email protected]> > wrote: > > It looks like the general consensus is for # 2) Leave them in the ASF > repo, but as separate modules/project(s). > > Which means we (the community) will take on the risk (security, ip, > license, etc.) and responsibility for the models that we commit. > > I'll take a stab at this today... > > Does anyone think it's worthwhile to (a) lump them all together and call > it a ctakes-resources project/model for pragmatic reasons? Otherwise (b), > we'll have a resource module for each such as ctakes-core-res, ctakes-pos- > tagger-res, etc.? > > I prefer (b). I know that means a lot more projects, but if I only want > to, say, run the ctakes-temporal models, it would be a pity if I had to > pull in the whole UMLS distribution at the same time. > > Steve > > > > > --Pei > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of Karthik > >> Sarma > >> Sent: Tuesday, March 19, 2013 1:35 PM > >> To: cTAKES Developer List > >> Subject: Re: [DISCUSS] Where should cTAKES models live? > >> > >> I concur. +1 for option 2 -- I do not really see any advantages that > >> option > >> 3 could have over option 2, as the difference should be largely > >> transparent to users (and even developers) > >> > >> > >> > >> > >> > >> -- > >> Karthik Sarma > >> UCLA Medical Scientist Training Program Class of 20?? > >> Member, UCLA Medical Imaging & Informatics Lab Member, CA Delegation > >> to the House of Delegates of the American Medical Association > >> [email protected] > >> gchat: [email protected] > >> linkedin: www.linkedin.com/in/ksarma > >> > >> > >> On Tue, Mar 19, 2013 at 9:49 AM, Masanz, James J. > >> <[email protected]>wrote: > >> > >>> I also am +1 for option 2. > >>> > >>> #3 is my least favorite, because of the download time for some of > >>> the models, both for cases like Steve mentioned but also for cases > >>> of wanting to check out a fresh copy of the code and not wanting to > >>> wait to check out the models again > >>> > >>> -- James > >>> > >>> > >>>> -----Original Message----- > >>>> From: > >>>> ctakes-dev-return-1378- > >> [email protected] > >>>> [mailto:ctakes-dev-return-1378-Masanz.James= > >>> [email protected]] > >>>> On Behalf Of Steven Bethard > >>>> Sent: Friday, March 15, 2013 1:06 PM > >>>> To: [email protected] > >>>> Subject: Re: [DISCUSS] Where should cTAKES models live? > >>>> > >>>> On Mar 15, 2013, at 4:39 PM, "Chen, Pei" > >>>> <[email protected] > >>>> > >>>> wrote: > >>>>> So the question is: What should we do with the model files? Some > >>>> options include: > >>>>> > >>>>> 1) Leave them in SourceForge/Maven Central. Maven can download > >>> and > >>>> include them in the convenience binaries in the ctakes-distribution > >>>> project. Something we did quickly for 3.0, but needs to be improved > >>>> if we go with this approach. For example: [2] > >>>>> > >>>>> 2) Leave them in the ASF repo, but separate modules/projects. > >>>>> > >>>>> 3) Keep them in the same respective ASF modules under > >>>> /src/main/resources > >>>>> > >>>>> I think it's nice to keep these fairly large (~1GB) and static > >>>>> resource > >>>> files separate from the source code (Either option 1 or 2). Also, > >>>> option > >>>> 1 will require a little more work by the committers/release > >>>> managers but will definitely avoid any licensing issues/concerns. > >>>> > >>>> I'd definitely vote for (2). That makes releases much easier than > >>>> if you have to coordinate between the ASF and Sourceforge > >>>> repositories, but also allows people to depend on the code in a > >>>> module without also pulling in all the models as well. (This would > >>>> make a lot of sense even now, for example, in ctakes-temporal which > >>>> depends on ctakes-relation-extractor only for the relation > >>>> extraction framework and not for the location_of > >>> and > >>>> degree_of models.) > >>>> > >>>> Steve > >>>
