It was an off-the-cuff suggestion. Devil is obviously in the details. On Fri, Oct 21, 2022 at 3:33 PM Peter Abramowitsch <pabramowit...@gmail.com> wrote:
> Interesting, but it would depend on how the docker is set up. Our docker > for instance, encapsulates all the code and imported jars, as you imply, > but the piper and other runtime configuration such as section regex, negex, > bsvs, etc are imported on a mounted FS during the container's runtime. > Having them frozen into the docker instances would proliferate vast numbers > of docker image-tars with 99% redundant data. Or do you have a cleverer > solution? > > Peter > > On Fri, Oct 21, 2022 at 10:18 PM Greg Silverman <g...@umn.edu.invalid> > wrote: > > > Why not use Docker and versioning by tags? See "C. Boettiger, An > > introduction to Docker for reproducible research, SIGOPS Oper. Syst. Rev. > > 49 > > (2015) 71–79. doi:10.1145/2723872.2723882. > > <https://www.zotero.org/google-docs/?Xd3H9e>" > > > > > > > > On Fri, Oct 21, 2022 at 3:15 PM Peter Abramowitsch < > > pabramowit...@gmail.com> > > wrote: > > > > > Well, obviously, the full range of permutations of all source files and > > all > > > annotators and pre and post ctakes code would require a huge amount of > > > commit information on thousands of files... and not only ctakes > > > files...recently I made some pretty significant changes to the > ZonerCli > > > library which is only a dependency of the ctakes distribution. How > would > > > all the commit info be used to tag the end results. I think the answer > > is > > > that it's simply not feasible or useful. So we haven't gone to > those > > > lengths. As far as we go at the UCs is to version the piper file and > > then > > > write the versioned_name of the piper back into the json object > returned > > > for each note... We have our own rest service and our own Java and > Python > > > clients, but they don't touch the internals of the message in a way > that > > > interferes with the clinical informatics. The note concept collection > > > object with its piper version is then persisted in our data store. > The > > > server jar also has a version which writes into a log and is updated > > > whenever any significant framework changes are implemented. But the > > > server version is not written into the data-store. > > > > > > Not sure if any of this was helpful > > > > > > On Fri, Oct 21, 2022 at 8:03 PM Miller, Timothy > > > <timothy.mil...@childrens.harvard.edu.invalid> wrote: > > > > > > > We’ve recently been using cTAKES for some internal projects where we > > make > > > > modifications, often using the REST server, combined with an > > open-source > > > > python client that makes the output of the REST server easy to > > > post-process: > > > > > > > > > > https://github.com/Machine-Learning-for-Medical-Language/ctakes-client-py > > > > written by my colleagues Andy McMurry and Mike Terry, and pip > > > installable. > > > > The output is then either converted to FHIR or written to whatever > > > > convenient format we need. > > > > > > > > But it’s useful to know for a given run on a given project, what was > > the > > > > NLP configuration that produced this output? Obviously, there are > > things > > > > like version numbers, but since cTAKES is highly configurable, and > our > > > > post-processing libraries have versions, and we may use trunk or a > > > previous > > > > commit instead of releases, things get complicated quickly. Does > anyone > > > > have an existing solution they are willing to share? Or does anyone > > have > > > > any thoughts on this topic? This question goes slightly beyond > cTAKES, > > > but > > > > cTAKES is responsible for a lot of the complexity in figuring this > out > > > > since it’s the most configurable component. > > > > > > > > Thanks > > > > Tim > > > > > > > > > > > > > > > > > -- > > Greg M. Silverman > > Senior Systems Developer > > NLP/IE <https://healthinformatics.umn.edu/research/nlpie-group> > > Department of Surgery > > University of Minnesota > > g...@umn.edu > > > -- Greg M. Silverman Senior Systems Developer NLP/IE <https://healthinformatics.umn.edu/research/nlpie-group> Department of Surgery University of Minnesota g...@umn.edu
