Neue GOKb Felder für Titel bzw. TIPPs
Closed this issue · 32 comments
Durch unsere Pick-and-Choose Modelle mit den eRef Lehrbüchern von Thieme sowie den utb Studi-Ebooks ist bei uns der Bedarf nach zwei neuen Feldern in der GOKb aufgekommen:
- Reihe
- Listpreis
- Fachbereich
Eine KBART-Datei hänge ich als Beispiel an (Feld für Fachbereich ist hier nicht aufgeführt bei der Thieme Datei). Die Inhalte der Felder "Reihe" und "Fachbereich" sollten als Freitext vom Anbieter bzw. KBART-Hersteller verwendet werden können, d.h. alles was in den Feldern geliefert wird, sollte dann auch so angenommen werden.
Zum "Listpreis": die Angaben ergeben sich aus den beiden KBART-Feldern listprice_value und listprice_currency .
Das Ganze sollte dann auf Titel-Ebene implementiert werden. Ein Beispiel wie das aussehen sollte (mit den englischen Begriffen) habe ich hier angehangen, für die neue Oberfläche dann einfach die oben genannten deutschen Feldnamen nehmen.
Thieme_Ebooks_eRef_Lehrbuecher_aktuelle_Auflagen_hbz_Format_mitallenSpalten.txt
Zum Hintergrund: bisher brauchten wir bei den beiden Pick-and-Choose Abläufen mit Thieme und utb diese Angaben in LAS:eR (wobei die Angaben auch unabhängig von diesen Abläufen wichtige generelle Informationen sind) und hatten daher einen Workaround in LAS:eR aufgesetzt, um die in der GOKb eingespielte KBART-Datei in LAS:eR mit den genannten drei Feldern anreichern zu können. Vielleicht hilfreich: im Wiki https://dienst-wiki.hbz-nrw.de/display/KOE/KBART hatte Daniel auch schon die GOKb/LAS:eR spezifischen Felder festgehalten.
These new properties have to be processed in Ygor too to appear in GOKb.
Die Verarbeitung der Felder kann Ygor-seitig implementiert werden.
@MiriKon :
- Welche KBart-Spaltennamen sind für die Felder vorgesehen? (Bezüglich Listpreis gibt es ja bereits die optionalen Feldnamen
listprice_eur,listprice_gbpundlistprice_usd.) - Die Informationen Listenpreis und Fachbereich sind nach meinem Verständnis TIPP-unabhängig und sollten dementsprechend technisch an die Titel-Übertragung angeheftet werden. (Sie können in der GOKb aber trotzdem pro TIPP angezeigt werden.)
- Für die Information Reihe fehlt mir das Verständnis. Ich vermute aber, dabei handelt es sich auch um eine Titel-spezifische Information?
- Für einen Preis keine Formalprüfung vorzunehmen, ist nicht empfehlenswert. Es kann natürlich akzeptiert werden, wenn in dem Feld redundant eine (passende!) Währung spezifiziert wird. (Die Information ist ja bereits im Spaltennamen enthalten.) Demnach können folgende Varianten (Kombinationen aus Zahl und ggf. gängigem Währungskürzel) akzeptiert werden:
- 100,00 (formal richtig)
- 100,0 (? --> könnte auch ein Indikator für ein falsch gesetztes Komma sein)
- 100
- 100 €
- 100 Euro
- 100 Eur
- 100 EUR
- EUR 100
- ... sowie Kombinationen aus den genannten Beispielen. Es macht jedoch keinen Sinn, freien Text zu akzeptieren, also bspw. "100a EUR", "1oo EUR", "Einhundert Euro", "Das Wetter ist schön.".
Das Format für die Übermittlung an die GOKb würde ich (vermutlich Titel-gebunden) entsprechend folgendermaßen spezifizieren:
"listprice" : [
{
"currency" : "EUR",
"price" : "123,45"
},
{
"currency" : "GBP",
"price" : "135,79"
}
],
"classification" : "freier Text",
"<reihe>" : "freier Text"
@hornmo @VolkerHBZ : ist das in Ordnung?
In der GOKb gibt es den Datentyp ComponentPrice, der currency und price enthält und egalwo angehängt werden kann - also im Titel oder im TIPP. Nach Auskunft von Andreas kennt LAS:eR zwei Preise: einen Listenpreis und einen vehandelten Preis. Das Ziel dieses Tickets ist ja, dass LAS:eR seine Daten für die Pick&Choose Geschichten aus der GOKb zieht. Allerdings sind die Preise bei LAS:eR tatsächlich im TIPP verortet, weil beide im selben Datenobjekt stecken. Ich sehe den Listenpreis aber auch unabhängig vom Paket und darum bei der Titel Instanz. Wenn es abweichende Preise gibt, dann m.E. im Rahmen eines Pakets, sie sind also sinnvollerweise am TIPP zu speichern.
Für die Klassifikation hat die GOKb auch schon Datentypen vorbereitet: Classification und Subject. Auch die können beliebig verknüpft werden, da sie bislang keine Benutzung erfahren. Ich sehe das, genauso wie die Reihe eher als intrinsiche Eigenschaft des Titels, die sich nicht verändert, habe aber die unbestimmte Befürchtung, dass Verlage durch veränderte Lizensierung bei einem Titel Paket- und Reihenzugehörigkeit wechseln könnten, was man dann über den TIPP abbilden müsste. An dieser Stelle handelt es sich wohl um eine Abwägung, ob man den seltenen Sonderfall (Titel wechselt die Reihe) durch eine komplizierte Datenstruktur für alle Titel zum Standard macht, oder eine einfach verständliche Zuordnung benutzt und den Sonderfall gesondert abbildet - beispielsweise in der Titelhistorie.
Da die verhandelten Preise nicht Gegenstand dieses Tickets sind, geht Philipps Vorschlag von meiner Seite in Ordnung. Das vorgeschlagene Schema läßt sich unaufwendig in der GOKb nachbilden.
@philboeselager @VolkerHBZ Die Preise können sich in der Tat pro Paket unterscheiden. Da gibt es einleuchtende Gründe, die ich jedoch mangels Expertise nicht wiedergeben kann. Ich würde also @MiriKon hierzu um Stellungnahme bitten; ich würde aber tatsächlich sehr stark für die Verdrahtung am TIPP plädieren, da der Preis keineswegs am Titel allein hängt.
Kurzes Update: ich habe mir die Thematik auch nochmal anhand unseres Pick-and-Choose Durchlaufs angeschaut und das Ticket deshalb nochmals aktualisiert. Die 3 neuen Felder würden sich dann alle auf den Titel beziehen, da der Listpreis für den einzelnen Titel Paket-unabhängig ist. Ich hatte auch einmal den Link ins Wiki kopiert, wo die relevanten KBART-Felder für GOKb/LAS:eR festgehalten werden.
Listpreis: spaltet sich auf in listprice_value und listprice_currency . Hier sollte es wie von @philboeselager vorgschlagen dann keinen Freitext geben. listprice_currency würde dann die Währung (EUR, USD, GBP etc.) vorgeben und bei listprice_value dann z.B. die Angabe "100,00" erlaubt und abweichend z.B. noch "100".
... wenn es abweichende Preise im Paket geben sollte, dann können die ja immernoch (als verhandelter Preis) in den TIPP reingefriemelt werden.
Die Preise können sich in der Tat pro Paket unterscheiden. ... ich würde aber tatsächlich sehr stark für die Verdrahtung am TIPP plädieren, da der Preis keineswegs am Titel allein hängt.
@croqueGrec09 Hier geht es ja nur um Listenpreise, nicht um Preise allgemein. Die Behandlung von Preisen wäre ein ganz anderes Issue. (Verhandelte Preise sind natürlich auch nur dann in die GOKb aufzunehmen, wenn sie nicht Gegenstand einer Geheimhaltung sind. Wie oft das wiederum der Fall ist, weiß ich nicht.)
hihi... idealerweise sind alle verhandelten Preise geheim und damit dann nicht mehr das Problem der GOKb.
leider erkenne ich in https://dienst-wiki.hbz-nrw.de/display/KOE/KBART nur wenig, was den Nebel etwas lichtet:
am aufschlussreichsten ist wohl das kbart_template, was die Namen der Kbart-Tabellenspalten vorschreibt. Dort gibt es die relativ eindeutigen Felder listprice_eur | listprice_usd | listprice_gbp, die offenbar Listenpreise in drei verschiedenen Währungen darstellen sollen (also kann ein Titel maximal drei Listenpreise bekommen, sofern keine weiteren Währungen berücksichtigt werden), sowie auch parent_publication_title_id | preceding_publication_title_id was auf die Reihe hindeuten könnte, allerdings verwirrt mich an dieser Stelle der Zusatz _id, da @MiriKon bislang von einem Klartextnamen ausgegangen ist. Diese Annahme wird auch durch das Beispielfile unterstützt, in dem parent_publication_id konsequent leer ist und preceding_publication_id Strings nach dem Muster 10.1108/<wirre Buchstaben> enthält, die sich in gleichem Muster in der Spalte titel_id wiederfinden.
Zusammenfassend stelle ich fest, daß die Anforderung darin besteht, Listenpreise in drei verschiedenen Währungen aus dem KBART zu lesen (sofern die Anbieter sie reinschreiben) und zusätzlich unbekannte Daten unbekannten Formats aus unbekannter Quelle in die Datenbank zu schieben. Ist das korrekt oder gibt es Spezifizierungen der Anforderung, die ich bisher übersehen habe?
Die relativ eindeutigen Felder schließen sich gegenseitig aus. So zumindest ist es bei LAS:eR, nämlich dass nur einer der drei Felder listprice_eur | listprice_usd | listprice_gbp oder die Kombination listprice_currency und listprice_value belegt sein darf. LAS:eR lehnt eine uneindeutige Zuweisung ab.
Es gibt noch weitere Spezifizierungen, unten auf der Seite, die allerdings nicht konsistent sind, mit dem, was in den Beispieldateien steht.
listprice_value,listprice_currencysind noch relativ eindeutigprice_dateist zum Glück nicht verpflichtend, sonst müssten irgendwie tagesaktuell neue Preise eingepflegt werden. Hier erscheint es mir sinnvoll, anzunehmen, dass das Datum den ersten Geltungstag des Preises repräsentiert, bis ein neueres KBART einen neuen Preis liefert, ggf. mit einem Datum in der Zukunft, wenn der Preis nicht ab sofort geändert werden soll. Ob rückwirkende Preisanpassungen auch existieren und wie rechtsverbindlich sie wären, ist Sache der Vertragspartner.- für Monograph-Reihen gibt es - neben dem aus o.g. Gründen suboptimalen Kandidaten
parent_publication_id- das von Cambridge University Press benutztemonograph_parent_collection_titleganz unten auf der Seite. - die "subject group" kann ich aus einem KBART Record nicht herleiten. Auch ist unbekannt, ob ein Titel nur einer subject group zugeordnet ist, oder auch in mehreren drin sein kann.
Die localprice-Spalten sind nur für LAS:eR relevant. Zur Aufnahme lokal verhandelter Preise ist die Komponente Lizenz unverzichtbar, welche in der GOKb naturgemäß nicht vorhanden ist. (EDIT: und auch nicht vorhanden sein soll) Die Spalten sind deshalb im Template enthalten, da dieses als Vorlage zur Umsetzung einer LAS:eR-Komponente gedacht ist.
@croqueGrec09 Wir sollten hier nicht ausschließlich vom Daten-Konsumenten LAS:eR her denken und argumentieren. Denkansatz muss sein, wie die GOKb als Globale, Offene Knowledge Base Daten möglichst universell, flexibel und korrekt abbilden kann. Es gibt ja bereits Stand Jetzt einen weiteren Kosnumenten (FOLIO) und die GOKb muss so konzipiert sein, dass sie in der Lage ist, neben diesen beiden weitere Konsumenten zu bedienen.
@VolkerHBZ listprice_eur, ..._gbp und ..._usd sind die drei bisher vorgeschlagenen Währungen. Da sich das KBart-Format erweitert, ist davon auszugehen, dass sich auch die Liste der Listenpreise bzw. -währungen noch erweitern wird. Grundsätzlich ist das System so in der Lage, beliebig viele Währungen / Listenpreise abzubilden. (Allerdings nur einen Preis pro Währung, was z. B. auf Amazon anders gehandhabt werden kann.)
@MiriKon Volker's Hinweise auf preceding_publication_title_id und parent_publication_title_id machen für mich Sinn.
- Sollen wir diese Felder für die Darstellung der Reihe heranziehen? (Wenn ja, wäre Freitext hier nicht empfehlenswert.)
- Soll es zusätzliche Felder für Freitext-Titel geben? (Diese würde nicht verlässlich verknüpft werden können.)
- Handelt es sich bei den
..._title_id-Feldern um die gleiche Information wie im ZDB-Feld039E:0?
@philboeselager Die "Argumentation" (ich wollte ja gerade gegen die Verwendung von localprice in der GOKb plädieren!) kommt in diesem Falle hiervon - Zitat oben:
Zum Hintergrund: bisher brauchten wir bei den beiden Pick-and-Choose Abläufen mit Thieme und utb diese Angaben in LAS:eR (wobei die Angaben auch unabhängig von diesen Abläufen wichtige generelle Informationen sind) und hatten daher einen Workaround in LAS:eR aufgesetzt, um die in der GOKb eingespielte KBART-Datei in LAS:eR mit den genannten drei Feldern anreichern zu können. Vielleicht hilfreich: im Wiki https://dienst-wiki.hbz-nrw.de/display/KOE/KBART hatte Daniel auch schon die GOKb/LAS:eR spezifischen Felder festgehalten.
Das hier zugrunde liegende Template dient(e) für LAS:eR und ist Hintergrund für localprice. Sprich: um genau diese Flexibilität für die GOKb bereitzuhalten, müssen alle LAS:eR-spezifischen Komponenten aus der GOKb raus (darauf wollte ich hinaus sowie die Genese des Templates erläutern, das hier als Grundlage genommen wird). Und localprice sind spezifische Komponenten.
Den local_price habe ich schon aus meinem Kommentar herausgenommen gehabt. Wirklich unklar in diesem Ticket ist aktuell nur noch der Fachbereich, den ich mit Subject Group nur unvollkommen übersetzt finde. Ich würde Subject Area vorschlagen, was immernoch nicht klärt, wie der gesetzt werden soll. Findet die Zuordnung zu einem Fachbereich tatsächlich durch den Anbieter statt oder eher durch die Bibliothek?
@MiriKon die ...title_id-Felder beziehen sich auf das Feld title_id, die einen (optionalen) Identifier auf Anbieterseite repräsentiert und das vom KBART-Standard ausdrücklich für solche Referenzierungen vorgesehen ist. Der Standard schreibt nicht vor, dass diese ID über verschiedene KBART-Dateien hinweg fix sein soll.
Heute mit MiriKon besprochen:
- Verwendung der KBart-Felder
listprice_eur,listprice_gbp&listprice_usd: OK - Verwendung der KBart-Felder
parent_publication_title_idundpreceding_publication_title_id: OK
- Die GOKb gibt die Angaben dann als ein Array von Objekten, bestehend aus
listprice_currencyundlistprice_valueaus, richtig? Soll Ygor die Daten im selben Format an die GOKb liefern? (Ist noch nicht spezifiziert). - Die GOKb akzeptiert historyEvents ja nur mitsamt der Angabe eines Datums. Das wäre im Falle einer KBart-Angabe ja nicht gegeben. Ist es möglich, in diesem Fall Review Requests anzulegen, und, solange diese nicht bearbeitet werden, die Angabe einfach zu ignorieren und den Titel bzw. TIPP trotzdem zu generieren (ohne das Feld)?
@hornmo, @croqueGrec09, @VolkerHBZ
- Den von Volker vorgeschlagenen Begriff
subjectAreabefürworte ich auch. "Area" ist in diesem Zusammenhang gängig, und es gibt nach meiner Recherche keinen häufiger benutzten Begriff als diesen. - Wenn niemand einen Gegenvorschlag hat, würde ich diesen Term beim Ygor-Title-Export an die GOKb verwenden. Dabei würde ich die von einzelnen Anbietern verwendeten KBart-Spaltennamen
primary_subject(Gale) undsubject(OECD) auf diesen Term umleiten.
Keine Bedenken, einzig muss - für eine eventuelle Übernahme in nehmende Systeme - im Title-OAI-Endpunkt auch das Element auftauchen.
@philboeselager aktuell habe ich gokb/integration/crossReferenceTitle so erweitert, dass die neuen Daten (series, subjectArea, prices) einfach an den JSON-Record eines Title angehängt werden:
[ { ... "status": "Current", "series": "Mystery Cloud", "subjectArea": "Fringe", "prices": [ { "priceType": "list", "currency": "EUR", "price": 123.45 }, { "priceType": "topup", "currency": "USD", "price": 6.78, "startDate": "2021-01-01" } ] } ]
Also liest YGOR listprice_currency und listprice_value aus dem KBART und wandelt das dann um in priceType:"list", currency: "<EUR|USD|GBP|...>" und price:. Auf diese Weise bleibt die Schnittstelle flexibel und kann direkt auch andere Währungen und Preistypen (perpetual, topup, on-off, subscription), die bereits als refdata existieren, entgegennehmen.
@VolkerHBZ Danke Dir. Zwei Kleinigkeiten sind mir aufgefallen:
- Semantisch würde ich vorschlagen,
amountstattpricezu wählen. (Ein Preis setzt sich ja aus Währung und Betrag zusammen.) - Bislang wiederholen in der GOKb-API Unterbegriffe nicht den Oberbegriff. Demnach wäre
typedempriceTypevorzuziehen. Das ist eine Philosophie-Frage, sollte aber einheitlich gepflegt werden.
Wie wird entschieden, welcher type von Ygor gesetzt werden soll? Dieses Datum ist ja nicht in der KBart-Datei enthalten. Soll "list" als default gesetzt werden?
Die Doku sollte dann noch hier nachgezogen werden.
ChangeLog.txt
@philboeselager Die Bezeichnung der Datenfelder habe ich mir nicht ausgedacht, die sind als Propertynamen so in der GOKb vorhanden. Wenn die im Import-JSON anders heißen, dann ist das mehr aufwand, weil die Automatismen von Grails nicht benutzt werden können und an jeder Stelle, wo die Automatik benutzt wird, angepasst werden muß - auch an denen, die nicht offensichztlich sind und dann zu mysteriösen Fehlern führen. Bei priceType ist es der GOKb vollkommen egal, welcher String da drin steht, solange er in den Refdata's vorkommt. Ein Changelog-File (s.o.) vom 18.6.2018 sagt, dass list als Default angenommen wird. da steht auch was drin über Preise als URL-Parameter, aber der Endpunkt wird leider nicht erwähnt.
ich habe den aktuellen Entwicklungsstand auf dev ausgerollt.
@philboeselager die Feldnamen sind nun type, currency und amount. Start- und End-Date werden automatisch von der GOKb gesetzt (start auf den Tag des Imports, end auf den Tag des Imports eines neuen Preises)
@MiriKon: schau' mal, ob die GUI so okay bist (z.B. https://phaeton-dev.hbz-nrw.de/gokb/resource/show/org.gokb.cred.JournalInstance%3A64666)
@VolkerHBZ Die KBart-Spaltennamen parent_publication_title_id und preceding_publication_title_id zeigen ja an, dass es sich dabei um Identifier handelt, also nicht um Freitext oder einen Titelnamen.
preceding_publication_title_id ist nach meinem Verständnis semantisch das gleiche wie historyEvents.from.identifiers entsprechend der API-Dokumentation.
Ygor könnte den identifier.type dabei per Format-Check automatisch aus dem Feldinhalt ableiten. Der Inhalt von historyEvents.to könnte automatisch mit einem Identifier des vorliegenden Records ("this") befüllt werden.
Einzig das historyEvent.date kann von Ygor nicht sinnvoll befüllt werden, da keine Information darüber vorliegt. Als automatisch gesetztes Datum "today" zu nehmen, wäre in mehrfacher Hinsicht fehleranfällig:
- Die Kbart-Datei selbst kann älter sein als 0 Tage.
- Auch bei einer 0-Tage-alten Datei kann das tatsächlich Übergangsdatum bereits einen beliebigen Zeitraum zurückliegen.
- Der Einspielprozess kann verzögert stattfinden.
- Titel können mehrfach eingespielt werden.
Die Wahrscheinlichkeit, dass bei "today" das richtige Datum als Ergebnis erscheint, ist verschwindend gering. Deshalb wäre mein Vorschlag, GOKb-seitig das Einspielen von historyEvents ohne Datum zu erlauben (oder mit "date" : ""). In einem solchen Fall müsste dann ein Review Request erzeugt werden. Was meint Ihr, @VolkerHBZ @hornmo ? Soll Ygor ein solches Event lieber ohne Datum oder mit leerem Datum senden?
Entsprechend müsste für parent_publication_title_id eine neue Relation in historyEvents erschaffen werden. Z. B. parent und child. Analog könnte child von Ygor dann immer mit einer ID von "this" befüllt werden und date würde wiederum offen bleiben.
Bitte parent_publication_title_id nicht für die Reihe nutzen. Das sind definierte KBART-Felder, die anhand der title_id auf einen "serial"-Titel innerhalb derselben KBART-Datei verweist, der einen Reihentitel (kein Journal!) darstellt.
-
Schafft das einen Aufwand seitens des Anbieters der KBART-Datei, da sie eine Reihe als Record definieren müssen. Ich bezweifle, dass das ernsthaft ein Anbieter macht.
-
Werden die meines Wissens von der GOKb nicht richtig prozessiert und würden dort, wie @philboeselager richtig feststellt, Erweiterungen im Datenmodell (z.B. der HistoryEvents) nach sich ziehen.
Der pragmatische Ansatz ist ein neues Feld, in dem der Reihentitel als Textstring enthalten ist. Hierfür können wir sinnvoll den von @VolkerHBZ vorgeschlagenen monograph_parent_collection_title nutzen, den die CUP ohnehin als proprietäre Erweiterung nutzt. Alternativ ist in der verlinkten Tabelle series_name vorgeschlagen, das auch von LAS:eR genutzt wird. Ich schlage dennoch das erstere vor.
Kurz als Fazit: Einigung auf monograph_parent_collection_title zur Angabe der Reihe.
@MiriKon Ist Ygor-seitig recht einfach zu implementieren.
@VolkerHBZ @hornmo Bitte gebt mir Bescheid, wenn die von mir oben skizzierten Änderungen in der GOKb (oder entsprechende Alternativen) erfolgt sind, und die GOKb die Reihen-Identifier ohne Datumsangabe verarbeiten kann.
Die Ygor-seitige Implementierung könnte theoretisch auch vorgezogen werden. Das würde aber zu Fehlern beim GOKb-Upload führen. Deshalb würde ich von diesem Vorgehen absehen, es sei denn, es ist ausdrücklich gewünscht.
Die Implementierung dieses Tickets in der GOKb ist mit dem PR #297 abgeschlossen und kann seitdem getestet werden. Wenn in YGOR noch was zu bauen ist, damit Reihe, Listpreis und Fachbereich in die GOKB übertragen werden, wäre jetzt ein guter Zeitpunkt das zu tun
.
@VolkerHBZ Danke für die Information. Bitte sag mir noch:
- Sollen die IDs aus dem hinzuzufügenden Feld ohne Event-Datum übermittelt werden?
- An welcher Stelle finde ich die Schnittstellen-Spezifikation in der API-Dokumentation ?
Es werden keine ID's übermittelt, sondern Strings für Reihe und Fachbereich.
Die Schnittstelle hat sich nicht verändert, das JSON unter https://github.com/openlibraryenvironment/gokb/wiki/Integration-APIs:-Telling-GOKb-about-new-or-corresponding-resources-and-local-identifiers#title-cross-referencing-and-coreferencing ist bereits um die neuen Felder Series, SubjectArea und Prices ergänzt worden.
Nach Rücksprache mit der hbz-Konsortialstelle sollten alle drei Felder aus pragmatischen Gründen an das TIPP, nicht an den Titel gehängt werden. Das hat folgende Gründe:
- Preis: Der Listenpreis ist anbieterabhängig. D.h. zwei Anbieter können denselben Titel mit verschiedenen Preisen im Portfolio haben.
- Fachbereich: Der Fachbereich ist momentan ein Freitextfeld und daher ebenfalls anbieterabhängig. Anbieter könnten denselben Titel einmal in Wirtschaftswissenschaften, einmal in Soziologie/Wirtschaftswissenschaften und einmal in Ökonomie einordnen. Solange keine einheitliche Strukturierung, etwa mit DDC, existiert, muss er im TIPP stehen.
- Reihe: Hier ist es schwieriger, aber da häufig keine offizielle bibliografische Reihe wie Veröffentlichungen des Instituts X Bd. Y gemeint ist, sondern eine interne Reihung des Anbieters, ist dieses Feld auch nicht titelübergreifend.
Korrespondierendes YGOR-Ticket: hbz/laser-ygor#306
@philboeselager
Testdateien finden sich im korrespondierenden YGOR-Ticket: hbz/laser-ygor#306 (comment)