How is open.med.harvard.edu better than the SourceForge project already hosting UMLS for cTAKES? If not a big difference, I'd say it should live on the institutionally neutral SourceForge.
Thanks Troy -----Original Message----- From: ctakes-dev-return-1117-Bleeker.Troy=mayo....@incubator.apache.org [mailto:ctakes-dev-return-1117-Bleeker.Troy=mayo....@incubator.apache.org] On Behalf Of Andy McMurry Sent: Friday, January 25, 2013 3:31 PM To: [email protected] Subject: Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release Hello ! I work with Geurgana and Pei and Britt on the de-identification software and papers using cTAKES. >>> We already have a maven repository and bamboo server for at least as >>> long as it takes to clear this ASF issue. << In my experience anytime "open source" and "legal doubts" are mixed the answer can drag on for unreasonably long. We can host binaries and continuous integration on open.med.harvard.edu without much effort. This is how how already host binary dists for Scrubber (de-id engine that depends on ctakes). We could easily do the same for cTAKES. BINARY DISTS (maven repo ) http://repo.open.med.harvard.edu/nexus/index.html#nexus-search;quick~scrubber CONTINUOUS BUILDS (bamboo) https://open.med.harvard.edu/bamboo/browse/SCRUBBER-DEF I offered Guergana the Maven repo and Bamboo builds last year. >From memory, I think she just wanted to use whatever things were the least >time consuming. If ASF is questionable about binary hosting, we can host on open.med (and build continuously). TL;DR: Maven Repo with continuous builds for cTAKES. Its a good thing. Yay, nay? Hooray? -- Andy McMurry On Jan 25, 2013, at 11:04 AM, "Mattmann, Chris A (388J)" <[email protected]> wrote: > Guys, FYI if you want to follow on general@ there is a question posed > for cTAKES community. Binary convenience bits aren't dead. Let's get a > resolution to the LEGAL issue again calling for outright objections or > otherwise lazy consensus (again) for another week and then just move on. > The binary convenience bits can come in this release, or in a future > one (as Pei suggested) but let's just move this on, it's a never > ending thread of potentially conflicting information that won't get a > resolution b/c it's up to the community to work within the confines of > the ASF (which are surprisingly not as black and white) to make it happen. > > Cheers, > Chris > > On 1/25/13 10:59 AM, "Mattmann, Chris A (388J)" > <[email protected]> wrote: > >> Hi Guys, >> >> >> On 1/25/13 10:29 AM, "Benson Margulies" <[email protected]> wrote: >> [...snip...] >>>>> >>>> Sorry, that's really what I meant: to think about that file as to >>>> whether it can do any harm and how to determine its safety. I >>>> haven't looked at the file, but it sounds like you know it can do >>>> harm. >>> >>> Depends on what you mean by 'harm'. A model could exhibit hostile >>> behavior, intentionally giving wrong or biased answers for certain >>> inputs. Some people would call that 'harm'. Others would focus on >>> malware, in which case having the model be a big file of numbers >>> that gets turned into a big array would indeed be defined as harmless. >> >> So, this is all conjecture. I don't think either of us are qualified >> Benson to comment or even remotely suggest the harmful nature, >> validity, etc., of a medical model, or set of them developed by >> institutions who have accepted the risk (well beyond the ASF's >> willing accepted risk, etc., for *software*) of leveraging the model >> for scientific study and prediction. Those institutions go as high up >> as the National Institutes of Health, the Department of Health and Human >> Services, etc., etc. >> >> Here's what it boils down to -- I get Roy's point, but does everyone >> else get Roy's point? Roy isn't going to *sanction* wearing big ASF >> hat the inclusion of things that the ASF isn't willing to accept risk >> on. The good news? The ASF is NOT a top down organization it's a >> bottom up one with minimal centralized oversight. That being said >> there's a subtle hint Roy's text on record that describes what >> *individuals* as part of a PMC (who are the ones that *release* the >> software) are, and are not able to do, and what risk they are and are >> not able to (implied) take on, and perform, within their community. >> This isn't the ASF coming top down with a policy (good luck every >> getting one) -- but it's something that has happened in the past with >> respect to binary "convenience" bits that even people like Roy say can go on >> the server. >> >> So, why don't we let this sit for a bit, and cTAKES community (and >> mentors, please speak up) if we are still wanting to proceed down >> this path, then let's do so, and I think we're going to be OK. >> >> See post from Jukka Zitting and I on cTAKES lists: >> >> http://s.apache.org/5aZ >> >> Cheers, >> Chris >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >
