Ftr/dynamic annotation classification

[bwbohl]

Description, Context and related Issue

Add support for dynamic mei:taxonomy usage in mei annot

Refs #81

How Has This Been Tested?

• Klarinettenquintett dataset
• BAZ-GA dataset

Types of changes

• New feature (non-breaking change which adds functionality)
• Documentation Update
• Improvement
• Refactoring

Overview

• I have updated the inline documentation accordingly.
• I have performed a self-review of my code, according to the style guide
• I have read the CONTRIBUTING document.

[bwbohl]

Please be aware that this has to be tested in combination with: Edirom/Edirom-Online-Frontend#87

[daniel-jettka]

Hi @bwbohl Thanks. Can you give some more detail about the feature? Some description about changes in data and some screenshots would be great.

@Edirom/edirom-online-developer Is anyone able to review this in the next two days until the test phase begins? :-)

(PR Edirom/Edirom-Online-Frontend#87 is connected to this one)

[bwbohl]

Some background:

The BAZ-GA uses different classification systems than ediromCategory and ediromPriority, namely a bazga.category and a bazga.class, which are defined in two mei:taxonomies. This led to an empty "priority"-column in the annotation list or single views and an over-populated "category"-column. Moreover, we wanted our class and category in separate columns.

Instead of creating a hard-coded fork of the frontend just for the BAZ-GA, we decided to push the already data-driven (mei:taxonomies were already evaluated for the category and priority columns) processing of the Edirom even further by:

1. Not generally providing priority and category data fields from the backend, but get all the taxonomies used in a list of annotations and create a column for each taxonomy
2. In the frontend, by default, hide columns that are empty in all annotations

This, of course, results in an "unstable" annotation model – so the frontend annotation model had to be skipped and the store and table built according to the data returned.

For all editions that use EdiromCategory and EdiromPriority, everything should look as before, but for those using other custom taxonomies, these should have their own columns now.

[bwbohl]

[daniel-jettka]

@bwbohl Would you be okay if we move this feature to the next release? It seems really great but we can't test it at the moment because there is no test data directly available and maybe it would be nice to present the feature in the next community meeting (01.10.25).

The 1.2.0 release is planned for end of the year, we could also do an earlier one if we want to get this feature "online".

[bwbohl]

As stated yesterday at the Community Meeting, I realised that the single annotation view is still missing the new concept. I will make this pull request a draft until I’ve added the necessary changes.

[bwbohl]

I have updated the single view and, while doing so, reactivated the sourceLabels div in the metaBox because I don’t like commented out code ;-) If there is a need for individual fields being hidden, we would have to implement this in a different way.

Observation:
For the metaBox, the Backend returns HTML – I’m not totally against it, but I’d rather put something like that into the frontend. But there might be other places where the backend behaves similarly. I think this would need a more general discussion and conception.