[Allegro] Das Wort zum Sonnabend: Wie steht's mit BIBFRAME?

[Bernhard Eversberg]

Wie steht's mit BIBFRAME? 

Zur Erinnerung: Vor 10 Jahren hat die Library of Congress ein
ambitioniertes Projekt gestartet: MARC21 sollte endlich in die Obsoleszenz
entlassen werden - Ein neues "Rahmenkonzept für das digitale Zeitalter" 
war die Vision, die man sich umzusetzen anschickte. Hier die Bekanntgabe
von damals, in deutscher Übersetzung:

  http://www.allegro-b.de/doku/regeln/rda/brk.htm

LC hat inzwischen ein "Conversion Tool" vorgestellt, mit dem man sich 
MARC und BIBFRAME nebeneinander anschauen kann. Es ist ganz ganz
einfach: Man braucht nur eine LC-IdNummer (MARC 010) in folgende URL einzufügen, 
z.B. hier 94234875:

  https://id.loc.gov/tools/bibframe/comparebf-lccn/94234875.xml

dann sieht man den Datensatz doppelt: links BIBFRAME, rechts MARC21

Tips: 
Im linken Fenster etwas nach unten scrollen, damit die eigentlichen
Daten sichtbar werden.
und ganz oben bei "Serialization": 'Text' einstellen statt 'XML'

Der MARC-Satz hat 1540 Bytes, BIBFRAME 9927 (gut das 6fache).
Woher diese Diskrepanz? Das liegt an XML. Dessen Vorzug ist es ja gerade,
was den Charme von Bibframe ausmacht: man muss nicht die MARC-Nummern
kennen, die für sich genommen keinerlei intuitiv sich erschließende
Bedeutung aufweisen. Unvorbereitete Lesende (Programmierende z.B.) 
sitzen völlig verblüfft davor, wenn sie erstmals MARC-Daten sehen. 

Bibliotheksdaten sollen, das war ein Hauptargument gegen MARC, intuitiv
verständlich sein UND mit modernen Werkzeugen (XML) auswert- und bearbeitbar.
Das hat halt auch einen Preis, es kostet mehr Speicherplatz, doch davon
hat man heute unbegrenzte Mengen, das ist kein Argument mehr.
Kurz: XML-Tags sind englischer Klartext in zeitgemäßer Formatierung, darum 
geht's, damit kann jeder Programmierer sofort loslegen. Statt zuerst ein
Semester lang die abschreckend dicke MARC-Doku studieren zu müssen.

Bevor Aufregung ausbricht: Man wird als Katalogisierer(in) bestimmt nicht
XML-Daten händisch eingeben oder auch nur lesen müssen! Man wird mit
den gewohnten MARC-Kategorien weiterarbeiten dürfen. Gespeichert werden
sie ebenfalls weiterhin in MARC - nicht wegen des Speicherplatzes, sondern
es hängt global irrsinnig viel Software dran, die man niemals alle auf XML
umstellen kann. Aber wo es um Kommunikation mit Endverbraucher*innen geht, 
kann man denen die Daten eben, flugs konvertiert, im BIBFRAME-Outfit überreichen.
Mit den vertrauten Werkzeugen, z.B. XSLT, können jene die jeweils gewünschten
Angaben im Nu rausfischen - unsere Daten werden endlich salonfähig!

Dennoch hat aber die LC einen BIBFRAME-Editor geschaffen, hier downzuloaden:
   https://bibframe.org/
und eine Hundertschaft in der Katalogabteilung trainiert schon eine Weile
versuchsweise damit. Man will rausfinden, ob sie es schaffen, statt
in MARC-Nummern am Ende in BIBFRAME-Tags zu denken und zu reden. Ein
Ergebnisbericht liegt noch nicht vor. Aber genug des Schwafelns jetzt:

Gleich mal ein Beispiel anschauen, es lohnt sich:
   https://bibframe.org/bfe/index.html#e3261222
dann rechts auf das Icon mit dem Schreibstift klicken - der Editor erscheint.

Tip: Wenn man da auf "Load MARC" klickt und eine LC-Nummer eingibt, kriegt man
den Datensatz direkt aus LC sofort in BIBFRAME zum Editieren serviert.
Aber bei "Identifier" zuerst "LCCN" einstellen, statt "Bib ID"

B.E.

Nachwort
Jeder übt gern Gerechtigkeit gegen jedermann/frau. Die Genderisierung jedoch macht daher 
zwar dem/der Schreiber*in Spaß - aber den Lesenden auch?
Bis das letztinstanzlich geklärt ist, tritt in diesem Forum noch keine Genderpflicht in Kraft.
(Nebenher: Das Verb "to gender" gibt's nicht im Englischen, d.h. "gendern" ist ein rein
 deutsches Verb. Soll man*? es trotzdem auf englische Weise aussprechen?)
Zum Kuckuck, wie gendert man "man"? (Laut Grimm hat es dieselbe Wurzel wie "Mann")