Prevent API update senses interference with Gloss Edit, Batch Edit, Keyword Mapping

[susanodd]

Prevent database inconsistency of senses due to "package senses retrieval" and "API gloss update" while the user is actively updating senses on Signbank.

Scenario of the problem:

1. SignCollect retrieves the Package for the Gloss (done every 5 minutes)
2. Signbank User updates the Gloss Senses using Batch Edit or Keywords Mapping during the next five minutes
3. API requests to Update Gloss using Package retrieved Gloss fields (1)
4. Signbank processes (3) and since (3, 1) differ from (2), the changes in (2) are overwritten by the API

Workflow on Signbank:

a. Using Batch Edit, the users input sense translations into the second language field (single form field, keyword phrases separated by returns).
b. Then using Keyword Mapping, the user splits and moves around the keywords into new senses for the gloss.

Editing senses can take a while: before (1) the user can be partially done with Batch Edit (a), and in (3) is busy with Keyword Mapping (b). In the scenario above, the API (3) would undo (b).

(This Signbank workflow is being used by UvA colleagues working together on search results for different letters of the alphabet. Described by @uklomp in Team meeting with @susanodd. The implementation of Batch Edit and Keyword Mapping are to support this form of collaboration.)

[Woseseltops]

Perhaps I misunderstand what you're trying to say, but isn't this unrelated to senses and a more generic problem? So

1. A client (like SignCollect) requests field A for sign x, and gets value 1.
2. Signbank users on signbank.cls.ru.nl change field A to value 2. The client is unaware of this update.
3. The client makes an update, and sets field A to 3, overwriting the previous step.

I would say it is up to the client to make sure the send us data that is up to date, as we only build the tools. We could make mistakes like this less painful by keeping track of who changed what, which we do.

If this is not what you're trying to say, perhaps you could show me in the form of a small demo next Thursday

[susanodd]

Nope, I mean specifically the senses.

Did you ever try out the tools?

I takes a long time to work on them. Some glosses have many senses. When there were only keywords, they were all in a single row. When these were migrated to the senses model, they were all put into one sense. These need to be split up into separate senses when appropriate.
For NGT, the original glosses did not have English. These need to be translated. This is a lot of editing. Each of the changes can be saved at the user discretion. The keywords can be reordered at the user discretion. The keywords can be moved to a different sense at the user discretion. Each of these operations is saved when the user saves and consistency is maintained. The underlying objects are updated at all levels and the glosses can be worked on without reloading the page.

The other fields are just one value. People aren't changing the handshape 15 times.

[susanodd]

Originally, @rem0g asked us to implement a signal for gloss update and send this to SignCollect every time a gloss was updated on Signbank.

That would solve the intererence problem, to use a signal instead of keep retrieving the package (generation of zipped json files) every five minutes.