Text annotation » History » Version 21
Alexander Watzinger, 2024-09-12 14:12
| 1 | 12 | h1. Text annotation |
|
|---|---|---|---|
| 2 | |||
| 3 | Issue #2079 |
||
| 4 | |||
| 5 | 13 | Alexander Watzinger | Text annotation will be about linking entities (actors, places, ...) to specific parts of a text, instead of just linking them to the whole text like it is possible currently. |
| 6 | 12 | ||
| 7 | h2. Scope (for the first version) |
||
| 8 | |||
| 9 | * It would be used at *Source* (E33) and their translations |
||
| 10 | * Only already linked entities are offered |
||
| 11 | * No overlapping annotations |
||
| 12 | |||
| 13 | 17 | Alexander Watzinger | h2. Topics to discuss |
| 14 | |||
| 15 | h3. User interface |
||
| 16 | |||
| 17 | * Do we try to solve it in on form element or split in separate steps/views for text editing and text annotation? |
||
| 18 | * How to remove text annotations (maybe showing a list with delete buttons)? |
||
| 19 | |||
| 20 | 12 | h2. User interface |
|
| 21 | |||
| 22 | 14 | Alexander Watzinger | We need a tool for users to annotate. Although difficult, ideally text changes and annotations can be done in one form element. |
| 23 | 12 | ||
| 24 | *Advantages* |
||
| 25 | * Easy to use |
||
| 26 | * It's not possible for users to "break" things |
||
| 27 | * Concurrent changes can be avoided with already implemented functionality |
||
| 28 | * Maybe take a look at APIS implementation: https://github.com/acdh-oeaw/apis-highlighter-ng |
||
| 29 | 14 | Alexander Watzinger | |
| 30 | Otherwise we will have to split: |
||
| 31 | * *Text editing* - leaving as is but would be problematic when annotations can't be seen |
||
| 32 | * *Text annotation* - most likely easier to implement if "stand alone" |
||
| 33 | 12 | ||
| 34 | 19 | Alexander Watzinger | h3. Meeting 2024-09-12 |
| 35 | |||
| 36 | Participants: Alex, Bernhard, Christoph, Olivia |
||
| 37 | 20 | Alexander Watzinger | We will try to go for the all in one UI element approach. It would be implemented using markup which the backend would provide to fill the element and process it again after submitting. |
| 38 | 19 | Alexander Watzinger | |
| 39 | 12 | h2. Information storing |
|
| 40 | |||
| 41 | 18 | Alexander Watzinger | We will save the information in an extra database table **web.annotation_text**, similar to web.annotation_image. Fields: |
| 42 | 12 | ||
| 43 | * *id* (int, required) generic internal database identifier |
||
| 44 | 15 | Alexander Watzinger | * *source_id* (int, required) |
| 45 | * *entity_id* - (int, required) the entity is linked in the annotation, e.g. actor, place, artifact, ... |
||
| 46 | 12 | * *link_start* (int, required) |
|
| 47 | * *link_end* - (int, required) or maybe the length? |
||
| 48 | * *user_id* - (int, not required) to track who added it |
||
| 49 | * *text* - (text, not required) a kind of description field for text information, maybe think about the name, e.g. annotation, description, text, ... |
||
| 50 | * *created* - timestamp of creation (set automatically at creation) |
||
| 51 | * *modified* - timestamp of modification (triggered automatically on change) |
||
| 52 | |||
| 53 | 16 | Alexander Watzinger | *Advantages* |
| 54 | 12 | * We can guarantee that there are no orphaned links |
|
| 55 | * It can than be used to e.g. be presented as HTML, TEI, "Web Annotation Data Model":https://www.w3.org/TR/annotation-model/, ... |
||
| 56 | |||
| 57 | h2. Time frame |
||
| 58 | |||
| 59 | Ideally we have a working basic version at the end of 2024 and can refine it in 2025. |
||
| 60 | |||
| 61 | h2. Ideas for future versions |
||
| 62 | |||
| 63 | * Offer links to external reference systems (e.g. GeoNames) which we would use to create new entities on the fly (using available meta information, creating links to reference system, ...). Interesting but a lot of work. |
||
| 64 | * A tool to find possible annotation candidates providing a result list to annotate multiple occurrences in one go |