Re: consequences of change to typesystem [EXTERNAL]
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 +, 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
Re: consequences of change to typesystem [EXTERNAL]
Yes, that's right. Especially for one-off contributions, it is really helpful to the project if you open up a jira issue and attach the patch to the issue, then one of the committers will check it and commit it. Let us know if you have any questions about that. For people interested in contributing more regularly (i.e., getting committing privileges), which we are more than happy to see, that is usually a good way to start as well. Tim On Tue, 2018-04-03 at 18:10 +, 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.devroom.io_2 > 009_10_26_how-2Dto-2Dcreate-2Dand-2Dapply-2Da-2Dpatch-2Dwith- > 2Dgit_=DwIFAg=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU=Heup- > IbsIg9Q1TPOylpP9FE4GTK- > OqdTDRRNQXipowRLRjx0ibQrHEo8uYx6674h=CrS3yfiJxacbnmFPA6qJIyrLpQCXyg > 3EOYDAahILynY=UNYDqzKKwNXwggNdpJ8XikpBGUktz3yadc0Mfyw1pjk= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.devroom.io_2 > 007_07_03_how-2Dto-2Dcreate-2Dand-2Dapply-2Da-2Dpatch-2Dwith- > 2Dsubversion_=DwIFAg=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU& > r=Heup-IbsIg9Q1TPOylpP9FE4GTK- > OqdTDRRNQXipowRLRjx0ibQrHEo8uYx6674h=CrS3yfiJxacbnmFPA6qJIyrLpQCXyg > 3EOYDAahILynY=lddQG2thUvB1znl1AGa_4uES_nFv_lGhNaOsj_xMd-Y= > > 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>; d...@ctakes.apac > he.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://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apach > e.org_jira_browse_CTAKES- > 2D503=DwIFAg=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU=Heup- > IbsIg9Q1TPOylpP9FE4GTK- > OqdTDRRNQXipowRLRjx0ibQrHEo8uYx6674h=CrS3yfiJxacbnmFPA6qJIyrLpQCXyg > 3EOYDAahILynY=RO1ApuEOrhaRTQ1RtZVRk8zyTdGOJe0EniNvV7aLmqs= > > 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
RE: consequences of change to typesystem [EXTERNAL]
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
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
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
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
