introduce consistent notion of text annotations in the store and how widgets interact with them #48
Description
Some text services (e.g. MorphGNT) already have annotation on words. Some widgets add extra annotations (e.g. frequency) by calling an API. While we don't have any examples yet, some widgets could add annotations via internal processing (e.g. syllabification).
These annotations are either used for display in the main panel with the text (colour, or interlinear info) or information shown in a widget when a word is selected.
We need to make sure all this works in a consistent way. This may involve considerable changes to some of the widgets. For example, frequency might (as previously discussed) be split into one that makes the API call and does the annotation in the store and one (that is perhaps more generic) that just does heatmaps on words based on a particular annotation already there (regardless of where it comes from).
I wonder if it also affects things like the Morpheus widget. When you click on a word, does it just make an API call and display the result or does it make an annotation in the store and then the display part of the widget draws from the annotation. Latter allows for more widget code re-use I suspect and is a form of caching.
This also means that a widget similar to the "word info" widget might actually just display all word-level annotations regardless of where they came from, without prior knowledge of what they are.
One thing that we might need to support all this is flags on the store as to what annotations are on the words (without having to check them all). For example, we may have a flag that says that words are annotated with frequency. Or perhaps a flag that says words are annotated with some number that could be used for a word heat map.
There's so much I've said here, we might need to break it apart into smaller steps.