-
Notifications
You must be signed in to change notification settings - Fork 29
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
Relations #284
Comments
I'm working on the same subject, I'm sure you already know most of it, but if that can help the thinking, here's my two cents: Structure
To reflect the Microsoft approach, you could also opt for a structure like this:
And then a getter to build the list of relations such as: But it's very much like yours, except there is less relation specific attributes, which have potential overlap with the rest of span attributes in the context of a package, at the cost of a bit more complex way to fetch values. It then raises the question of the exact definition of each relation, their reciprocity or not etc... Basic Relationship ideas
For dates only, I use a scope based approach with a rule based construction (mixing sections, subsections, sentences as well as implicit context changes, contextual vs enunciation etc.. which is the reason I asked for #253) and already reach a decent F1, so I can back the short term approach. It can benefit from a wide variety of rules, and dates have the tendency to "cascade" in sections so to speak (such as in your example), which could be quite different from say, measurement or other relation scopes, so I had the feeling to work on those separately. I would love to see frames and ML based scope deduction approach at work though. Very interested to see how you approach this. |
It's time we tackled the task of predicting the relationships between entities. We first need to know how to represent them in our documents, and then which components (rb or ml) can solve this task.
Representations
Basic relationships
We could add a
rel
dictionary attribute to scopes such as :and have getters to look at this list and find entities of a given label or with a certain type of relationship:
Scopes
Another interesting approach is that of scopes and scope relationships. For example, in the following:
where we predict on which span of text (scope) a given cue/trigger entity convey its meaning. Scopes can overlap each other. For instance, a section title convey its meaning on its section, which itself can contain several entities with smaller scopes.
This is already indirectly done by the
eds.negation
,eds.hypothesis
,eds.history
etc qualification components (implementation of the Negex/Context algorithms).This could take the following form:
Frames
Frames, as described in https://aclanthology.org/2023.bionlp-1.13.pdf#page=2, could be an interesting end result, but I think it would be too restrictive to implement them only.
Dependency and constituency analysis
We could also exploit dependency and constituency parsing relationships to infer relationships between entities, but note that the example above would not be directly resolved since the scope of the first entity spans two sentences, which are not syntactically related.
Components
Machine learning
I'm currently reimplementing a generic version of the https://github.com/percevalw/breast-imaging-frame-extraction method (https://aclanthology.org/2023.bionlp-1.13/)
Rule-based
By mixing sections, subsections (e.g. enumerations and bullets), sentences and Context-like algorithms, we could probably already get good results on highly requested tasks such as detecting relationships between dates and surrounding entities.
The text was updated successfully, but these errors were encountered: