Hard-coded basic categories

[marcverhagen]

Because

The train module defines the categories used:

app-swt-detection/modeling/train.py

Lines 35 to 37 in 710f527

	# full typology from https://github.com/clamsproject/app-swt-detection/issues/1
	FRAME_TYPES = ["B", "S", "S:H", "S:C", "S:D", "S:B", "S:G", "W", "L", "O",
	"M", "I", "N", "E", "P", "Y", "K", "G", "T", "F", "C", "R"]

This means that adding an additional category requires changing the app. Should looking into moving the definition into a configuration file or some other approach.

Done when

No response

Additional context

No response

[keighrim]

The basic labelset has been moved to the package init.py (72266e8), so no longer specifically a part of train scope only.

And that labelset was never part of "configuration" during training. It was given in the annotation. If we are adding an additional category, that means a new different annotation data and different rounds of training. I believe that should a new app. In other words, the fact that these labels are hard-coded in the modeling package doesn't seem to be an issue to me. In fact, I believe they have to be hard-coded, not "configurable".

[marcverhagen]

Having this in outside of train.py is much better.

And if we create a new app each time we have a different annotation then this is indeed not a configuration issue but a basic annotation data issue.

At some point we may need to think about the similarity between all kinds of SWT-like apps and if there is value in de-appifying some training-classification code (similar to what is being done with the stitcher).

But in general it is now fine to close this.