And if someone with access rights wants to put that on takes.apache.org, there's a ticket for it:
https://issues.apache.org/jira/browse/CTAKES-499 Ewan. On Tue, Apr 03, 2018 at 06:10:46PM +0000, Gandhi Rajan Natarajan wrote: > Hi Sean, > > Please find the response from Sean Finan for the similar question I asked him > earlier: > > "Ctakes doesn't really have a steadfast process for making upgrades. > > You should create a jira item or use an existing one. Any commits should > have a comment/message starting with the jira item. For instance > "CTAKES-441: Add LabValueFinder". > > You can use patch files, attaching them to a jira item and requesting that > somebody test them before the changes are committed. You may want to create > the patch using your git version and then commit it to ctakes using svn. > https://www.devroom.io/2009/10/26/how-to-create-and-apply-a-patch-with-git/ > https://www.devroom.io/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/ > > If the change is significant then you could create an svn branch of ctakes > and then commit your changes to that branch. Ask for assistance testing the > branch and then merge the branch into trunk." > > Hope it makes sense. > > Regards, > Gandhi > > -----Original Message----- > From: Mullane, Sean *HS [mailto:sp...@hscmail.mcc.virginia.edu] > Sent: Tuesday, April 03, 2018 11:28 PM > To: 'Finan, Sean' <sean.fi...@childrens.harvard.edu>; dev@ctakes.apache.org > Subject: RE: consequences of change to typesystem [EXTERNAL] > > I have made some minor changes to DocumentMapperServiceImpl.java to fix this. > The bodyLocation attributes now get added via the anno_link table in the > database. I created JIRA issue 503 [0] for this issue, per the cTAKES wiki. > > Since this is my first time committing a change to the project I'm not sure > how to go about it. Is there a tutorial on how to file a pull request I can > reference? > > [0] https://issues.apache.org/jira/browse/CTAKES-503 > > Thanks, > Sean > > -----Original Message----- > From: Mullane, Sean *HS [mailto:sp...@hscmail.mcc.virginia.edu] > Sent: Wednesday, March 28, 2018 6:54 PM > To: 'Finan, Sean'; dev@ctakes.apache.org > Subject: RE: consequences of change to typesystem [EXTERNAL] > > Sean, > > Glad I asked. I will try either what you suggested or the similar approach of > adding some code to handle the bare-annotation-as-feature case similarly to > how annotations inside FSArrays are handled. > > Thanks, > Sean > > -----Original Message----- > From: Finan, Sean [mailto:sean.fi...@childrens.harvard.edu] > Sent: Wednesday, March 28, 2018 8:40 AM > To: dev@ctakes.apache.org > Subject: Re: consequences of change to typesystem [EXTERNAL] > > Hi Sean, > > In case nobody else has replied, > Yes, this would definitely break a whole lot of things. I am not saying that > it is a bad idea, just that the current BinaryTextRelation interface is used > as-is in probably a thousand places, and while some refactoring might be > trivial I wouldn't bet that it all would be as easy as one would like. > > I haven't looked at the ytex DBConsumer, but could it possibly be easier to > add some code there that would check BinaryTextRelations and create a new > FSArray for each? Stick those arrays in the cas immediately before and db > write() and you should be able to do what you want without impacting the rest > of ctakes. > > Sean > ________________________________________ > From: Mullane, Sean *HS <sp...@hscmail.mcc.virginia.edu> > Sent: Tuesday, March 27, 2018 6:05 PM > To: dev@ctakes.apache.org > Subject: consequences of change to typesystem [EXTERNAL] > > I am trying out a change to the typesystem (explained below). If it works as > I hope, I would want to contribute this back to the trunk. Before I invest > too much time into this, can anyone tell me if this is likely to break things > for other users? I am thinking of this causing problems reading existing > annotated corpora, like SHARP. > > Problem I'm trying to fix: > The DBConsumer database writer from YTEX seems to ignore > BinaryTextRelation types (e.g. LocationOfTextRelation, used for the > bodyLocation feature on annotations like DiseaseDisorderMention). This is > because they are not added to the default AnnotationIndex index and are not > contained in FSArrays or FSLists inside other annotation types, like the > UmlsConcept annotations inside the ontologyConceptArr feature are. > > It seems that if I were to change the bodyLocation feature to be a FSArray of > annotations instead of a bare annotation, the DBConsumer should write it to > the output table and add an entry in the anno_link table. > > Would changing the type of the bodyLocation feature in certain > IdentifiedAnnotations break things for others? > > Thanks, > Sean > > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you are not the named addressee you should not disseminate, distribute or > copy this e-mail. Please notify the sender or system manager by email > immediately if you have received this e-mail by mistake and delete this > e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited and > against the law.