search

rism-international / tasks

A summary of tasks
1 stars 1 forks source link

Check PIKaDo 824 for values #966

Closed HirschSt closed 2 years ago

HirschSt commented 2 years ago
BaMikusi commented 2 years ago

Vielen Dank im Voraus, und bitte womöglich aufklären wo diese 824 values heute in Muscat stecken.

HirschSt commented 2 years ago

see https://raw.githubusercontent.com/rism-international/muscat-maintenance/master/report/2022-05-06_pikado-824.csv

HirschSt commented 2 years ago

Ergänzend hier noch einige Regeln für die Migration von PIKaDo zu Kallisto 2006 (Zitat):

BaMikusi commented 2 years ago

Danke, das ist alles sehr hilfreich. Ich versuche die Neuigkeiten etwas zu "verdauen", und am Montag in der Sitzung greifen wir das Thema wieder auf.

BaMikusi commented 2 years ago

(NB: Was mir momentan unklar ist, ob bei der Migration Kallisto --> Muscat eine ähnliche Ausfilterung stattgefunden hat.)

HirschSt commented 2 years ago

Das ist alles schon einige Zeit her und auch schwierig. Soweit ich recherchieren konnte gab es für die Taktart in Muscat nur 031$o, und das Feld hspr01.takta, welches die Taktart enthielt, wurde 1:1 hier reingespielt, eine Weiterverarbeitung im Sinne einer Ausfilterung fand nicht statt. Das liegt auch daran, dass es in PIKaDo zwei Felder für die Taktart gab, wobei auch noch ein Feld verdoppelt werden konnte, und in Kallisto eben nur ein Feld - wie in Muscat auch. Ich muss hier aber noch weiter in den vergangenen Materialien forschen...

BaMikusi commented 2 years ago

Ich muss sagen, dass ich immerhin verwirrt bin. Ich habe die CSV-Tabelle etwas genauer angeschaut, und bei 100143 scheint es, als ob man Einträge aus 823 und 824 am Ende doch in ein einziges Feld, mit Semikolon abgesondert, eingespielt hätte, vergleiche 100143,8001.1.1,823c,8243/2 und https://muscat.rism.info/admin/sources/100143 wo im Feld "Metrum" c; 3/2 steht.

Aber bei 100139 anders: 100139,8001.1.1,8232/4,8243/4 Hier hätte (soweit ich den Erklärungstext verstehe) der Eintrag in Feld 824 den früheren im Feld 823 eigentlich überschreiben sollen, aber in Muscat steht heute nur der 823-value (2/4): https://muscat.rism.info/admin/sources/100139

Ähnlich bei 101942,8001.1.1,8233,8243/4 https://muscat.rism.info/admin/sources/101942

Und bei den meisten anderen Beispiele finde ich auch nur 823 in Muscat wieder (was ja eigentlich logisch ist, wenn man das Hauptprinzip, dass die Quelle womöglich treu beschrieben werden soll, vor Augen hat). Obige Erklärungen hat man dann aber offenbar nicht konsequent umgesetzt, und die 824-Einträge wurden vielleicht einfach gelöscht?

BaMikusi commented 2 years ago

Noch eine Frage: es ist mir nicht gelungen, verdoppelte 823-Einträge zu finden. Gab es tatsächlich keine, oder werden diese in dieser CSV-Tabelle nicht angezeigt? (Es wöre ja gut zu sehen, was mit diesen am Ende passierte.)

HirschSt commented 2 years ago

In der Tabelle wurde tatsächlich nur die erste 823-Angabe berücksichtigt, weil in PIKaDO verdoppelte Felder in einer neuen Zeile (und unter Umständen auch an ganz anderer Stelle) stehen. Ich werde das Skript anpassen und erneut durchlaufen lassen

BaMikusi commented 2 years ago

Danke, das wäre sehr hilfreich wenn wir aufklären wollen, woher die Semikolons stammen -- es fällt mir nämlich ein, dass aich mein erstes Beispiel vielleicht nur eine Scheinausnahme sein dürfte, wenn das Semikolon dort eventuell nicht wegen 824, eher aber wegen einer Verdopplung von 823 erscheint... Wenn es eindeutig wäre, dass verdoppelte 823-Einträge heute im Feld 031 $o (durch Semikolon geteilt) nebeneinander stehen, 824-Einträge aber bei der Migration rausgeschmissen wurden, wäre es schon relativ einfach alle Semikolons als "weitere Metrum-Angaben im Stück" (oder ähnliches) in 031 $q zu unterbringen.

HirschSt commented 2 years ago

Ich habe die Tabelle jetzt aktualisiert, s. https://github.com/rism-international/muscat-maintenance/blob/master/report/2022-05-06_pikado-824.csv

Mir scheint die Aussage "dass verdoppelte 823-Einträge heute im Feld 031 $o (durch Semikolon geteilt) nebeneinander stehen, 824-Einträge aber bei der Migration rausgeschmissen wurden" eigentlich bestätigt, vielleicht können Sie noch stichprobenartig gegenprüfen.

done with https://github.com/rism-international/muscat-maintenance/commit/788677a6c3fdfc382b5e26043d6b540e84deea22

BaMikusi commented 2 years ago

Danke für die erweiterte Tabelle, ich habe noch mehrere Dutzende Fälle genauer angeschaut, und von den 824-Angaben ist heute in Muscat tatsächlich keine Spur, sie wurden bei der Migration offenbar ignoriert. Dabei scheint es leider, dass in einigen wenigen Fällen auch im Feld 823 Korrektur/Zählzeit-artige Einträge gemacht wurden (teilweise dupliziert in 824), wenn wir also die Semikolon-Angaben aus 031$o nach 0314q bringen wollen, muss der einleitende Phrase ganz neutral sein, etwa einfach "further time signatures:"

NB: Als Vergleich habe ich inzwischen von Herrn Licciulli eine Tabelle mit den heute in Muscat stehenden Metrumangaben mit Semikolon erhalten, und da gibt es um etwa 4.500 Datensätze mehr, diese Praxis wurde also nach PIKaDo offenbar weitergeführt. Auch von diesen neueren Einträgen habe ich eine Reihe angeschaut; sie stammen alle von der deutschen Arbeitsgruppe, und nutzen das Semikolon eindeutig in Fällen wo der Satz mehrere Formteile mit unterschiedlichen Metra (und oft auch Tonarten) hat -- auch für diese kann also obige einfache Einleitungssatz gut gelten.

Vielen Dank, nun ist die Lage klar, das Ticket kann m.E. geschlossen werden.

HirschSt commented 2 years ago

Vielen Dank, falls wir also diese Werte in Muscat später wie vorgeschlagen unterbringen möchten, eröffnen wir ein neues Ticket für das entsprechende Wartungsskript