AEP05-Erweiterung-Datenmodell.md

@@ -12,12 +12,13 @@
 | 2022-09-01 | Aktueller Stand bestätigt und ergänzt: o94, Freirad, FRF, FRO, Helsinki | David | Approved |
 | 2022-09-05 | Vorschlag für Bildlizenz und Playlist | Ernesto | Draft |
 | 2022-09-13 | Vorschlag für Link Types und License Types | Ernesto | Draft |
+| 2022-11-07 | Abschnitt zu Tank, Ergebnisse aus der Besprechung Ole, Ernesto, David am 30.08. Lizenztyp & -halter per Audiodatei | David | Draft |
 
 ## EPIC
 
 [\[EPIC\] \[AEP05\] Extend data model and API](https://gitlab.servus.at/aura/meta/-/issues/96)
 
-## Use Cases
+## Zielsetzung und Use Cases
 
 - Abbildung des aktuellen o94 Datenmodells, plus Erweiterungen nach der Programmreform 2022
 - Abbildung der Anforderungen an die Datenhaltung aller beteiligten Radios
@@ -30,13 +31,33 @@ Ausgangspunkt sind folgende UIs für Infos Kategorisierungen: meta#27+ sowie das
 
 ## Offen
 
-- david: Radio FRO hat bei Bildangaben nicht nur ein Freitext Feld für Copyright-Ownership, aber auch ein Dropdown für die jeweilige Lizenz. Das soll beibehalten werden.
-- david: wie werden Link Typen hinterlegt/erlaubt. Vorschlag: Eine [Settings Entität](https://gitlab.servus.at/aura/steering/-/issues/121)
-- david: o94 hat pro Episode auch ein Feld für Lizenz + Rechterinhaber*in. Das fehlt im Vorschlag noch. Bei o94 liegt bei der Note, in Aura ist das eher eine Sache des Playlisten Eintrages => bzw. des Files. Gleichzeitig sind Files nicht persistent. Christian überlegt sich hier Implementierungsvorschläge
-- david: o94 hat pro Episode auch ein Feld für Playlisten Infos (Freitext). Im Tank müsste das wiederum auf File Ebene sein. Gleichzeitig wäre es hier praktisch wenn wir das Feld für maschinenlesbare Playlistdaten verwenden können (vgl. `CUE` files im Recorder). Christian überlegt sich hier einen Vorschlag.
+- ~~david: o94 hat pro Episode auch ein Feld für Lizenz + Rechterinhaber*in. Das fehlt im Vorschlag noch. Bei o94 liegt bei der Note, in Aura ist das eher eine Sache des Playlisten Eintrages => bzw. des Files.~~ 
+- ~~david: o94 hat pro Episode auch ein Feld für Playlisten Infos (Freitext). Im Tank müsste das wiederum auf File Ebene sein. Gleichzeitig wäre es hier sinnvoll wenn wir das Feld für maschinenlesbare Playlistdaten verwenden können (vgl. `CUE` files im Recorder).~~ 
+- Unklar, wie wir wohldefinierte (CUE) Playlisten vs. Userfreitext in Steering mergen. Womöglich macht es Sinn hier eine strukturierte und freitext Variante im Steering DM anzubieten.
+- Unklar wie wir mit Metadaten/Playlisten für Live/Line/Streamingquellen umgehen. Diese können nicht in Tank hinterlegt werden, weil Playlisten hier mehr als "Templates" dienen und somit nicht persistent sind. Solche Daten können nur/erst in Steering gespeichert werden.
+- Vorschläge/Feedback von Christian
 
 ## Erweiterung in Tank
 
+Neben Lizenzinformationen (Art und Rechteinhaber), sollen auch Playlist Informationen pro File gespeichert werden. Diese Playlisten enthalten Metadaten von Aufnahmen oder vorproduzierten Sendungen. In Kombination mit bestehenden Tank Playlisten ergibt sich eine verschachtelte Playlistenstruktur:
+
+```yaml
+Tank Playlist
+  L live
+  L stream
+  L audio file 1
+  L audio file 2
+      L CUE sheet data holding another playlist
+  L audio file 3
+      L CUE sheet data holding another playlist
+```
+
+### Datenmodell für Audio Files
+
+- Neues Feld `license_type` (`TextField`), beeinhaltet Schlüssel der verfügbaren Lizenztypen in Steering
+- Neues Feld `license_owner` (`TextField`), Freitext
+- Neues Feld `playlist` (`TextField`), Freitext entweder als validiertes JSON ([JSON Schema](https://json-schema.org/)) oder [CUE Sheet Format](https://wiki.hydrogenaud.io/index.php?title=Cue_sheet)
+
 ## Erweiterung in Steering
 
 ### `Category`