Stabile Versionen und Workflows

[mirjan-hoffmann]

Derzeit scheint es keine Versionierung der hochschulfaechersystematik zu geben und ein Commit in den stable branch stellt Anwendungen, die immer den letzten Stand dieses Branches nutzen, vor eine Herausforderung, da plötzlich breaking changes im Produktivbetrieb auftauchen können.

Zuletzt wurden mit f49c651 zB einfach zwei Einträge als deprecated markiert und zusätzlich aus der Fächerhierarchie entfernt - was ein breaking change ist.

Ziel dieses Issues sollte es sein hier eine Möglichkeit zu schaffen stabile Versionen der hochschulfaechersystematik nutzen zu können. So dass nicht adhoc breaking changes eingeführt werden können, sondern etwa mit einem Major-Versionswechsel einhergehen.

[acka47]

Hallo @mirjan-hoffmann , danke, dass du das Ticket aufmachst. Wir hatten im letzten Treffen der OER-Metadatengruppe – und ich glaube auch im Treffen davor – bereits den Umgang auf Anwendungsebene mit deprecated concepts diskutiert, siehe https://metadaten.community/t/januar-treffen-der-oer-metadatengruppe-kim-2023/138/2#wie-geht-man-mit-deprecated-skos-konzepten-um-10

Damit wir das in Zukunft berücksichtigen können, ein paar Fragen:

• Was sind denn konkret die Probleme, die du jetzt hattest?
• Was stellst du dir unter einer "stabilen Version" vor? Sollen wir GitHub Releases machen? Soll jede Version ihren eigenen Namensraum haben (was glaube ich mehr Probleme aufmachen als lösen würde)? Oder meinst du etwas ganz anderes?

[mic-men]

Die Problematik ist anscheinend, dass die "deprecated"-Einträge aus der Hierarchie losgelöst wurden, d.h. n241 und n237 nicht mehr in den broader und narrower Kontext eingebettet sind.
Das scheint mir in der Tat kritisch und zu überdenken.
Im edu-sharing scheint es so zu sein, dass diese id's ignoriert werden. Das ist einerseits gut - es gibt keine Fehler und sie erscheinen nicht mehr in der Hierarchie-Liste. Andererseits ist es schlecht - die Labels erscheinen nicht mehr an den Objekten, wenn sie dort vergeben wurden. Das zumindest mein Stand der Untersuchung.
Momentan ist mein (derzeitiger) Vorschlag, dass die broader und narrower Kontexte erhalten bleiben - wir das also nochmal anpassen müssten. Damit haben Systeme, die "deprecated" ignorieren, zwar zuviele/doppelte Einträge, aber es ist vorwärts und rückwärts kompatibel. Systeme müssten dann den Umgang mt "deprecated" nach eigenem Ermessen umsetzen.

[acka47]

Ich gebe @mic-men Recht. Ehrlich gesagt war mir gar nicht klar, dass die Konzepte auch aus der Hierarchie entfernt wurden. Da habe ich wohl nicht gründlich genug gereviewt.

Für SkoHub Vocabs haben wir übrigens schon den zukünftigen Umgang mit deprecated concepts recht detailliert beschrieben, siehe skohub-io/skohub-vocabs#287

[lummerland]

317b9fb korrigiert erstmal den Fehler der entfernten Konzepte (auch wenn damit die Grundfrage noch nicht geklärt ist). Danke für den Hinweis und sorry für die Umstände!

[mic-men]

Ich meine, die broader-Einträge müssen auch wieder gesetzt werden - habe das mal gemacht: c331f97.
Bitte nochmal prüfen!

[acka47]

Das sieht gut aus. Ich habe mal einen PR (#36) aufgemacht. @mirjan-hoffmann, wäre das für dich ein gutes Umgehen mit deprecated concepts? Dann ist ja alles wie vorher, nur die deprecated: true-Aussage wird ergänzt und Anwendungen können für sich überlegen, wie sie damit umgehen.

[mirjan-hoffmann]

Moin @acka47,
ja, genau, die Deprecated Einträge können durch die Änderung nicht mehr in der Hierarchie dargestellt werden. PR #36 sollte die aktuellen Probleme erstmal lösen - thx all
Dann kann jede Anwendung in Ruhe Deprecated Werte ablösen und erstmal weitermachen wie bisher ohne Zeitdruck.

Trotzdem würde ich den Gedanken der Versionierung damit noch nicht begraben. Es wäre ja auch denkbar mit einem Major-Update dann breaking changes zuzulassen und zB diese Deprecated Einträge zu entfernen. Aus meiner Sicht könnte sowas auch sehr leichtgewichtig aussehen. Ein Tag im Repo wäre für mich zB schon ausreichend. Interessant ist auch meiner Sicht ja sowieso nur das ttl-File und das liegt ja vollständig im Repo ohne das noch irgendein Artefakt oä generiert werden müsste.

[acka47]

Ich meine, die broader-Einträge müssen auch wieder gesetzt werden

Noch ein Nachtrag zur Klarstellung: Bei skos:broader/skos:narrower reicht prinzipiell die Angabe einer Richtung, denn es handelt sich um inverse RDF Properties und die jeweils andere Richtung kann automatisch ergänzt werden. So macht es auch SkoHub Vocabs. Von daher ist es kein Fehler aber zumindest eine Inkonsistenz, weil wir ja ansonsten beides angeben. Wir könnten höchstens mal überlegen zur besseren Pflegbarkeit nur noch eine Relation in der Turtle-Datei zu haben.

[acka47]

Trotzdem würde ich den Gedanken der Versionierung damit noch nicht begraben.

Ich mache das Ticket nochmal auf und setze es auf die Agenda für das nächste Treffen.

[acka47]

Closing. Wir werden die Dokumetation des Vokabular-Aktualisierungsprozess mit dini-ag-kim/stoeberspecs#9 ergänzen.