[jira] [Commented] (CTAKES-57) Type System updates for 3.x-incubating

["Stephen Wu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CTAKES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590965#comment-13590965 ] 

Stephen Wu commented on CTAKES-57:
----------------------------------

thanks steve and james, sorry for the radio silence. let's do (2) for where to store the normalized forms, as suggested.  so, to get information out of XXXModifier, we'll have to follow XXModifier:getNormalizedForm().getValue() -- right?

you had other issues, i'll try to answer them one by one.

* ElementRelation vs. BinaryTextRelation. All of the manual annotations describe spans of text, so they're read in as XXXMention or XXXModifier types. I think these should be BinaryTextRelations, since their arguments are Mentions/Modifiers, not Elements.
 - Ok, go ahead and change these.  The space of referential semantic relations is completely unpopulated right now, except perhaps by data that exists in UMLS or SNOMED-CT.

* Most of the MedicationEventMention features (medicationStatusChange, medicationDosage, medicationDuration, etc.) take Attribute values, not Mention values (e.g. medicationStatusChange takes a MedicationStatusChange value, but should take a MedicationStatusChangeModifier value).
 - MedicationEventMention needs to be deprecated in favor of MedicationMention.

* MedicationEventMention doesn't have any feature where I can put an associated MedicationAllergyModifier, or an associated start date.
 - Add any UIMA features that should be there.

* There's no DateMention (or DateModifier?) for start dates. There's a DateAnnotation, but it doesn't have the necessary "month" and "day" attributes.
 - Not too sure about this one.  I think someone closer to the temporal stuff needs to make that decision -- maybe you, steve b?  DateAnnotation still gets set by the context-dependent-tokenizer, i believe.

* ProcedureMention doesn't have anywhere I can put an associated ProcedureDeviceModifier
 - Add as necessary, but I think I see this one in there already.

* EventMention doesn't have anywhere I can put a HistoryOfModifier.
 - This is currently the same as how polarity/uncertainty/conditional/etc are stored.  Just put the value on IdentifiedAnnotation.  If someone wants to revise it so these attributes are not quite so close to 

* There's a "Status" attribute, which takes on the values "HistoryOf", "FamilyHistoryOf" and "Possible". I'm not sure where that's supposed to fit into the type system. (HistoryOfModifier only has a boolean "indicated" feature, so it can't go there right now.)
 - From SHARP annotations?  Status shouldn't be there.  Hmm... you would do:
   HistoryOf -> set historyOf
   FamilyHistoryOf -> set historyOf, subject=family_member
   Possible -> set uncertainty

* For THYME relations, we have TLINK relations (with categories like "OVERLAP") and ALINK relations (with categories like "CONTINUES")... I think the cleanest solution would probably be to create extra subclasses of BinaryTextRelation, TemporalTextRelation and AspectualTextRelation, and then the category would store OVERLAP/CONTINUES/etc. But I'm open to other solutions here as well.
 - In the spirit of the earlier answer where we're switching the other UMLS relations to be textual, let's also switch this one to be textual, and subclass BinaryTextRelation as suggested.

stephen


                
> Type System updates for 3.x-incubating
> --------------------------------------
>
>                 Key: CTAKES-57
>                 URL: https://issues.apache.org/jira/browse/CTAKES-57
>             Project: cTAKES
>          Issue Type: Improvement
>    Affects Versions: 3.0-incubating
>            Reporter: James Joseph Masanz
>            Assignee: James Joseph Masanz
>             Fix For: 3.1-incubating
>
>
> Opening 2 issues regarding the type system. This one is for changes that will require refactoring and may affect current users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira