Nach fast 5 Jahren Entwicklung unter Feedback aus der Praxis und von verschiedener Entwickler*innen aus der Bibliotheks-IT möchte ich die Schema-Sprache Avram gerne bis zum Mai mit Version 1.0.0 zum Abschluss bringen. Mittlerweile gibt neben der Referenzimplementierung in NodeJS mit QA Catalogue, marctable und marc-schema auch mehrere Werkzeuge anderer, die Avram verwenden. Der aktuelle Standard (0.9.4) wird allerdings noch nicht überall zu 100% eingehalten.
Ich würde mich über praktisches Feedback in Form von Korrekturen und Fragen freuen:
Ist der Standard verständlich formuliert?
Lassen sich damit bei überschaubarem Aufwand eigene Schemas erstellen, um Daten in PICA, MARC, MAB und/oder CSV zu beschreiben und/oder zu validieren?
Mag jemand einen Validator in der Programmiersprache seiner/ihrer Wahl erstellen?
Was nutzt ihr zur Kontrolle der Datenqualität von MARC- und PICA-Daten?
Gibt es eigene Anwendungsfälle, die als Beispiele oder Anwendungstests herhalten könnten?
Könnte die Version 1.0.0 unter Herausgeberschaft weiterer Institutionen veröffentlicht werden um dem ganzen eine offiziellere Note zu geben und wer käme da in Frage (KIM?)
Offene Issues zu Version 1.0.0 finden sich hier und können gerne ergänzt werden. Neue Features sollten allerdings nicht mehr hinzukommen. Bislang nicht umgesetzte Features zur Kontrolle der Datenqualität (siehe FCV, shacl4bib, pica-lint…) können in Avram als externe Regeln (rules) eingebunden werden.
ich habe mal angefangen, die aktuelle Spezifikation auf unser CERL Thesaurus-Format anzuwenden (ein Unimarc-Abkömmling) und mir sind bis jetzt ein paar Dinge aufgefallen:
Beim Punkt „Format families“ werden die möglichen Indikatorwerte grundsätzlich definiert. ISO 2709 erlaubt außer den dort genannten auch ‚I‘ als möglichen Indikatorwert. Das kommt in Unimarc auch vor (wobei zugegebenermaßen Unimarc nicht mehr oft vorkommt…)
wofür sind die keys „records“ (with a non-negative integer to indicate a number of records) und „records“ und „total“ in der field definition gut? Das klingt erst mal so wie etwas was man eher in einem Validierungsreport erwarten würde?
Es kommt in Marc und verwandten Formate regelmäßig vor, dass Indikatorpositionen nicht definiert sind; dann müssen sie ein Blank enthalten. Das will ich natürlich auch validieren, denn wenn da was anderes steht, weiß ich, dass da möglicherweise was schief gelaufen ist und ich mir das genauer ansehen muss. Ich kann allerdings für eine nicht definierte Indikatorposition kein „label“ vergeben. Das wäre gut, das irgendwie auch zu adressieren.
Grundsätzlich fänd ich es hilfreich, wenn bei JSON Beispielen auch immer der entsprechend Marc bzw. Pica etc Datensatzschnipsel stehen würde, das macht es denke ich etwas einfacher zu erfassen, was genau gemeint ist.
Was ich nicht verstanden habe ist, wie sich bei der field definition der key mit dem field identifier zu dem Inhalt von „tag“ verhält. Ist das nicht das gleiche?
Wenn ein Feld-Definition im Schema kein indicator1 / indicator2 enthält, werden die Indikatoren nicht überprüft. Wenn die Felder den Wert null oder {"codes":{" ":{}}} haben, ist nur blank erlaubt. Sollte dieser Wert besser geändert werden auf folgendes, so dass das Label „blank“ vergeben wird?
Wie unter counting beschrieben kann bei der Validierung auch überprüft werden, ob ein Feld genau total mal und/oder in records Datensätzen vorkommt. Der Anwendungsfall ist aber eher das Reporting. Fändest du es sinnvoller/einfacher/ausreichend/übersichtlicher, wenn die Felder nicht zur Validierung verwendet werden, d.h. stattdessen nur als optionale reporting-Felder?
Das steht in Abschnitt 4.5 der Unimarc Specifikation:
Fill Character in Indicators
For indicators, the fill character is also used when the agency never assigns values to a particular type, e.g. field 710 (Corporate body name) indicator 1 (Meeting indicator). It is also used when situations arise that, for codes, would be dealt with using u, v, or z, i.e. unknown, combination or other. The fill character is also used when UNIMARC has a specific indicator which cannot be derived from any value in the source format.
Mir ist der logische Zusammenhang insbesondere bei ‚records‘ nicht ganz klar. Ich würde davon ausgehen, dass eine Formatbeschreibung immer unabhängig von konkreten Daten, bzw. Dateien ist. Wenn ich sage etwas kommt in soundsovielen Datensätzen vor, sage ich etwas über die konkrete Datei und nicht über das Format, oder?
‚total‘ meint die Anzahl des jew. Feldes in einem Datensatz?
Das Label „blank“ als Wort würde ich nicht verwenden, aber ein Blank als Code (oder alternativ auch #) - so dass man das als möglichen Wert definieren kann. Wenn das jetzt bereits vorgesehen ist, könntest du das in der Beschreibung vielleicht deutlicher sagen.