-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Words like "expression" and "overexpression" shouldn't be flagged as entity modifications #606
Comments
Oh, we always thought these are important to capture... So, what would like done for these? Nothing? |
@enoriega, @maxaalexeeva: something for your attention. |
@MihaiSurdeanu One option is to do nothing, especially if it's just referring to "expression" in the context of natural variation. The other option is to flag it as a modification of type "overexpression" or "amount_increase" or something like that. Part of the problem is that these are included as modifications in the REACH output but have type "UNKNOWN". If they were typed we could give them special handling during assembly. More generally, as we start to think about extracting observations in the context of ASDF, it makes sense to think of these as experimental perturbations with certain downstream effects. |
@zhengzhongliang: can you please run the MALT1 example, and paste here what happens? I'd like to see what the output looks like, and what rule matched the "Expression of MALT1" part of the text. |
@enoriega agreed trying to understand why this happens. Then point @zhengzhongliang to actionable things. |
I'm running the following sentence, simplifies from the MALT1 example provided by @johnbachman :
And get four events: A phosphorylation, a transcription and two regulations. Both the phosphorylation and the transcription (which is triggered by They're almost identical, but differ on their I'm not clear on why the expression term is being flagged as an entity modification on the output, perhaps is a post processing step by the reach output code that flattens the complex event and encodes the expression event as a modification of its theme? @MihaiSurdeanu. In any case, maybe the regulation where the entity is the controller should be filtered out given that the controller is the expression of that entity. I think the correct place for this would be an action. Which is the specific output format being used by HMS? @johnbachman
|
This is the shell output for the same sentence, where the duplication of the regulation can be appreciated more detailedly:
|
Yeah... This happens because the controller of a regulation can be both an event and an entity. |
Frequently certain generic terms like "expression" and "overexpression" are getting flagged as entity modifications in the REACH output. This is tricky for us because this ends up getting treated as a refinement on the agent in our assembly process, even though these terms don't really reflect a meaningful difference in agent state. Here are some examples:
Ras:
MALT1:
WOX1 (also note that the polarity modifier "knock-down" appears to be missed here):
GDF15:
LCN2:
ADM:
G3BP1:
ATG9A:
More examples available if desired!
The text was updated successfully, but these errors were encountered: