[Allegro] allegro's exporte in die ganze welt: z.b. marcxml

[Thomas Berger]

Am 20.08.2015 um 09:17 schrieb Bernhard Eversberg:

> Datenvolumen ist heute kein Kriterium mehr, das irgendwer noch
> ernstnähme. Nun, da LC das betagte MARC-Format hochoffiziell als
> Auslaufmodell deklariert hat und BIBFRAME als den Weg des Lichts,
> ist um XML endgültig kein Herumkommen mehr. Niemand entwickelt

Bibframe ist in RDF formuliert. RDF/XML ist eine (und eher
unhandliche) der moeglichen Serialisierungen von RDF.

Etwa unter
<
http://datendienst.dnb.de/cgi-bin/mabit.pl?userID=opendata&pass=opendata&cmd=login
>

werden die (RDF-) "Linked Data-Dumps" der DNB (DNB Titel, GND, ZDB
Titel) gleichberechtigt in den Formaten RDF/XML und RDF/Turtle
angeboten.


> noch neue Software mit irgendwas anderem als XML als Fundament.

s/XML/JSON/

(XML ist ziemlich out, je nachdem wohin man schaut:
Im allgemeinen Web-Kontext geht alles definiv Richtung JSON,
im Semantic-Web-Kontext war es stets RDF, Formate wie JSON-LD
versuchen da eine Bruecke zu schlagen).

Das ist alles kein vollstaendiger Ersatz fuer XML (oder HTML),
wenn Baumstrukturen wie in Dokumenten vorliegen: RDF und JSON
sind viel zu daten-zentrisch, um damit vernuenftig umgehen
zu koennen (bzw. RDF erlaubt als Datentyp von /Werten/ nicht
nur URIs und Strings, sondern z.B. auch XML-Fragmente: Das
habe ich in freier Wildbahn allerdings noch nie gesehen).

Was Bibliothekarische Daten wirklich sind (etwa in MARC21)
ist nicht wirklich verstanden, historisch sind es irgendwelche
Texte mit eingefuegten Markern. Dass dies eine Baumstruktur
impliziert, also jeder Marker eine Art Start-Marker ist und
ein impliziter zugehoeriger Ende-Marker unmittelbar vor dem
naechsten Marker unterstellt wird, ist eine neuere Sicht, die
eher auf dem Beduerfnis beruht, Bibliothekarische Beschreibungen
als Daten aufzufassen, als auf tieferen Einsichten. Traditionell
haben wir aber mit ISBD-Interpunktion ein paralleles Auszeichnungs-
system mitlaufen und dazu noch Mikro-Auszeichnungssysteme, etwa
", " in invertierten und nichtinvertierten Personennamen,
Nichtsortierzeichen "vorne" fuer Titel, Nichtsortierzeichen "hinten"
fuer Praefixe von Personennamen, runde und spitze Klammern fuer
Sortierhilfen, eckige Klammern fuer alle moeglichen Zwecke etc.

Wenn wir (etwa mit TEI) eine wissenschaftlichen Standards genuegende
Edition einer einzelnen Karteikarte (oder eines [ausgedruckten]
MARC21-Records) unternehmen wuerden, gaebe uns XML das Werkzeug,
den Text in seine verschiedenen Ebenen aufzuspalten und jedes
Element anhand seiner Funktion auszuzeichnen und zu annotieren
(etwa die Sprache fuer eine griechische Phrase in einem lateinischem
Sachtitel explizit zu machen oder Namensbestandteile als "Vorname"
und "Nachname" innerhalb eines Personennamens zu kennzeichnen und
diesen wiederum mit einem Normsatz in Verbindung zu bringen).
Linguistische Methoden (etwa bei der Volltextindexierung) wuerden
das u.U. durch noch viel feineres XML-Markup bis hinein in
Wortbestandteile anreichern...

RDF/XML laesst sich prima in XML-Dokumente einbetten, das ist etwa
der Ansatz von schema.org (in Web-/Dokumente/ eingebettete
Linked-Data-Elemente). Dem Ansatz, dass RDF-Daten aber ein
vollstaendiger Ersatz sein koennen, entspricht das aber nicht
unbedingt: Wenn man traditionelle Beschreibungen als Text auffasst,
wird eine Repraesentation als "Daten" ihm nicht gerecht bzw.
extrem umstaendlich: Es geht dann nur, indem man grosse
Redundanzen schafft (Name als ganzes und parallel dazu Name
unterteilt in Nachnamen und Vornamen, Titel transkribiert plus
eine Form nach Wegschneiden von Nichtsortierbestandteilen, ...)
und weder RDF noch JSON stellen einfache Methoden bereit, den
Zusammenhang zwischen den verschiedenen Aufbereitungen eigentlich
desselben Datums aufrechtzuerhalten (das ist natuerlich eine
Stelle, wo bereits die traditionellen bibliothekarischen Daten-
formate versagen).

Es ist aber durchaus legitim sich von der Karteikarte als Text
zu loesen und nach Daten zu suchen: Schliesslich geht es darum,
Informationen ueber die Ressourcen zu transportieren, und die
komplexen Auszeichnungsstrukturen der traditionellen
Beschreibungen sind nur ein Vehikel dafuer. Andererseits ist
es allerdings so, dass etwa die Dichotomie von "angesetzten" und
"transkribierten" Elementen (dazwischen ein breites Spektrum
von sowohl-als-auch das sich fuer Verarbeitungszwecke meist
als weder-noch entpuppt - DA sitzen die Probleme!) nicht
spezifisch fuer das obsolete Medium Karteikarte ist, sondern
sich aus fundamentalen Anforderungen ableiten laesst.

Man koennte nun ueberlegen, was das "Wesen" der Beschreibungen
ist (m.W. ist das im Kontext von Regelwerken und Datenformaten
noch nicht wirklich erfolgt): Meiner Meinung nach werden
bei der (Original-)katalogisierung die Indizien oder Fakten
zum vom Regelwerk geforderten Sachverhalten ermittelt (wird ein
Autor genannt?) und als Text uebertragen (wie heisst er), dann
durch einen aufwendigen Prozess zu Daten veredelt (wer ist
er?). Bei der (Copy-)Katalogisierung hingegen koennte man auch
sagen, dass die am besten passenden Daten zur Vorlage
ausgewaehlt werden, dazu wird "abweichendes" von der Vorlage
transkribiert. Definitiv sind die "Daten" das Ergebnis mit
dem hoeheren Mehrwert (im Sinne des Zusatzaufwands, der in
ihre Erzeugung eingeflossen ist), und fuer Linked-Data benoetigt
man sie auch mehr noch als frueher. Aber gerade weil der
Mehrwert u.U. sehr hoch ist benoetigen wir die transkribierten
Elemente um die Bruecke zwischen unseren Daten und den
Vorlagen zu schlagen (also die Tatsache, dass unsere Daten diese
Vorlage betreffen nachvollziehbar zu machen) bzw. die Grundlage
der Datengewinnung zu zeigen und nachvollziehbar zu machen.

Ein Bestell- und Liefersystem fuer den Buchhandel kann absolut
datenzentrisch sein, das sehe ich sofort ein. Die Beschreibung
einer mittelalterlichen Handschrift oder die museale Beschreibung
eines Buchs als kulturelles Objekt (jeweils also einen mittellangen
wissenschaftlichen Aufsatz) so aufziehen zu wollen, waere absurd.
Bibliotheken wollen da einen mittleren Standpunkt einnehmen,
bzw. - die in den FRBR formulierte Bescheidenheit schlaegt
sich in den RDA nicht wirklich nieder - alles koennen. Je nachdem
sind Formate wie Bibframe dazu erste Wahl oder fast voellig
unbrauchbar. Dummerweise ist das, was Bibliotheken realistischerweise
zukuenftig an Erschliessung (zumindest punktuell) leisten werden,
m.E. genau an eine Stelle angesiedelt, fuer die entsprechende
Einschaetzung von Bibframe nicht klar ist. Bzw. - da ja noch
alles im Fluss ist - niemand weiss momentan, wie unappetitlich komplex
eine Bibframe-Darstellung unserer traditionell besonders sorgfaeltig
und ausfuehrlich angelegten Katalogisate (ZDB, VD-17, ...) wird,
um funktional zumindest nicht hinter das Gewohnte zurueckzufallen
(d.h. etwa eine Anzeige mit Hyperlinks zu produzieren, die ein
menschlicher Benutzer verstehen kann, ohne vorher von Redundanzen
ins Koma versetzt zu werden).

viele Gruesse
Thomas Berger