# Endgültige Spezifikation der Schema-Sprache Avram **URL:** \ **Category:** Arbeitsgruppen\ **Tags:** avram\ **Created:** [2. Januar 2024 um 14:42 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164 "2024-01-02T14:42:34Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [2. Januar 2024 um 14:42 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/1 "2024-01-02T14:42:34Z")
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](https://format.gbv.de/schema/avram/specification)** gerne bis zum Mai mit Version 1.0.0 zum Abschluss bringen. Mittlerweile gibt neben [der Referenzimplementierung](https://github.com/gbv/avram-js) in NodeJS mit [QA Catalogue](https://github.com/pkiraly/qa-catalogue), [marctable](https://github.com/edsu/marctable) und [marc-schema](https://github.com/timathom/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](https://github.com/gbv/avram/issues?q=is%3Aissue+is%3Aopen+-milestone%3A1.1.0+) 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](https://github.com/pkiraly/qa-catalogue#shacl4bib), [pica-lint](https://github.com/deutsche-nationalbibliothek/pica-rs/tree/main/crates/pica-lint)…) können in Avram [als externe Regeln](https://format.gbv.de/schema/avram/specification#external-validation-rules) (`rules`) eingebunden werden. ---
**Author:** ![alex](https://metadaten.community/user_avatar/metadaten.community/alex/32/17_2.png) [@alex](https://metadaten.community/u/alex)\ **Post date:** [19. April 2024 um 13:05 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/2 "2024-04-19T13:05:29Z")
Hi Jakob, 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: 1. 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…) 2. 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? 3. 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. 4. 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. 5. 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? soweit erst mal für heute … HG Alex ---
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [22. April 2024 um 11:01 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/3 "2024-04-22T11:01:21Z")
> [@alex](#): > > 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. 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? ```json {"codes":{" ":{"label":"blank"}}} ``` ---
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [22. April 2024 um 11:05 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/4 "2024-04-22T11:05:53Z")
> [@alex](#): > > 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? Ok, das könnte in der Dokumentation verbessert werden: - `tag` with the [tag](https://format.gbv.de/schema/avram/specification#records) of the field. The tag is identical to the [field identifier](https://format.gbv.de/schema/avram/specification#field-identifier) unless the field identifier includes a [field occurrence and/or field counter](https://format.gbv.de/schema/avram/specification#field-identifier). ---
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [22. April 2024 um 11:10 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/5 "2024-04-22T11:10:26Z")
> [@alex](#): > > 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? Wie unter [counting](https://format.gbv.de/schema/avram/specification#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? ---
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [22. April 2024 um 11:34 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/6 "2024-04-22T11:34:21Z")
> [@alex](#): > > 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. In [https://archive.ifla.org/VI/8/unimarc-concise-bibliographic-format-2008.pdf](https://archive.ifla.org/VI/8/unimarc-concise-bibliographic-format-2008.pdf) finde ich keinen Indikator `|` - bist du sicher dass das kein weiterer Platzhalter für Blank ist? ---
**Author:** ![alex](https://metadaten.community/user_avatar/metadaten.community/alex/32/17_2.png) [@alex](https://metadaten.community/u/alex)\ **Post date:** [13. Mai 2024 um 11:20 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/7 "2024-05-13T11:20:24Z")
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. [https://repository.ifla.org/handle/123456789/2880](https://repository.ifla.org/handle/123456789/2880) ---
**Author:** ![alex](https://metadaten.community/user_avatar/metadaten.community/alex/32/17_2.png) [@alex](https://metadaten.community/u/alex)\ **Post date:** [13. Mai 2024 um 11:26 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/8 "2024-05-13T11:26:34Z")
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? ---
**Author:** ![alex](https://metadaten.community/user_avatar/metadaten.community/alex/32/17_2.png) [@alex](https://metadaten.community/u/alex)\ **Post date:** [13. Mai 2024 um 11:30 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/9 "2024-05-13T11:30:35Z")
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. ---
**Author:** ![nichtich](https://metadaten.community/user_avatar/metadaten.community/nichtich/32/67_2.png) [@nichtich](https://metadaten.community/u/nichtich)\ **Post date:** [20. Februar 2025 um 18:41 UTC](https://metadaten.community/t/endgueltige-spezifikation-der-schema-sprache-avram/164/10 "2025-02-20T18:41:04Z")
Bis auf den Indicator `|` sollten inzwischen alle Dinge geklärt sein. In QA Catalogue haben wir ein [Avram-Schema für UNIMARC](https://github.com/pkiraly/qa-catalogue/blob/main/avram-schemas/unimarc.json) (siehe [HTML-Version](https://pkiraly.github.io/qa-catalogue/avram-schemas/unimarc.html)), das auch kein `|` hat, also gehe ich davon aus, dass es nicht erlaubt ist bzw. auf der Syntax-Ebene für einen nicht vorhandenen Indikator steht. Die noch offenen Punkte bis zum Release 1.0.0 sind [hier gelistet](https://github.com/dini-ag-kim/avram/milestone/2).