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
