ctakes-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Wu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CTAKES-57) Type System updates for 3.x-incubating
Date Fri, 01 Mar 2013 21:43:12 GMT

    [ 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.


> 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

View raw message