[Allegro] MARC21-XML 700 als EST / bevorzugter Titel eines Werkes

[Thomas Berger]

Am 04.02.2016 um 17:04 schrieb Anando Eger:
> Hallo Herr Eversberg,
> 
> Sie schrieben u.a.:
>> Eine Befreiung aus diesem Schlamassel *könnte* wohl nur
>> gelingen mit einem ganz großen Wurf der BIBFRAME-Protagonisten,
>> einem Datenmodell von zwingender Eleganz und Effizienz und
>> Universalität, einer Glanztat, die den angesammelten,
>> alten Wissensqualm hinwegbläst mit neuer und endlich richtig
>> guter, überzeugender Funktionalität.
> 
> Das ist wohl so. Zumindest sieht es für mich aus, als ob dort die 
> Informationstechnologie etwas mehr zu sagen hätte.
> Den Kern des Datenmodells finde ich sehr überzeugend - es bleibt 
> abzuwarten, ob die Übersichtlichkeit nicht wieder die Beute sich 
> überentwickelnder Komplexität wird.
> 
> Ich könnte mich dafür erwärmen, die MARC/RDA-Stufe zu überspringen.

Wie sollte so etwas gehen. Bzw. warum wird hier vom sonst so
skeptischen Herrn Eversberg ein Heilsversprechen suggeriert?

BIBFrame ist ein RDF-Vokabular. Das ist kein Datenmodell, zumindest
nicht im klassischen Sinn wie ER oder OO.

BIBFrame ist ein RDF-Vokabular. Es ersetzt kein Regelwerk.

BIBFrame ist ein RDF-Vokabular. Naturgemaess ist es minimal und
nicht vollstaendig (der Clou ist ja gerade, moeglichst haeufig
andere Vokabulare einzusetzen, die sich "besser auskennen")

BIBFrame ist ein RDF-Vokabular. Tendenziell kann es mit "harten"
Daten am besten umgehen, auch mit "geschachtelten" (was in
Programmiersprachen ein "complex type" oder ein "record" ist)
und mit Binnenstruktur extrem schlecht.

BIBFrame ist ein RDF-Vokabular. Gibt es Mehrfacheintraege, bei
denen eine Reihenfolge zu beachten ist, wird es haarig.

In MARC hat jedes Datenfeld zwei Indikatoren, oft mit nichttrivialer
Bedeutung, die Control-Felder wuseln von positionellen Codes (die
fuer Ein- und Ausgabe in Labels der Katalogisierungssparche umzusetzen
waeren), es gibt "gewachsene" indirekte Strukturen ("7" als Indikator
in Feld x bedeutet dass der eigentliche Code sich im Unterfeld $2
findet), Unterfelder druecken Sachverhalte differenziert aus: Das ist
alles recht schematisch, und man muss nicht alles programmieren,
sondern kann viel in Datenbanktabellen hinterlegen, aber in der
Summe werden /tausende/ Facetten der Wirklichkeit abgebildet und
fuer jede einzelne wurde mindestens eine Festlegung getroffen.
Man denke etwa an das DNB-Fettnaepfchen von gestern, dass 240$a
im verknuepften Fall unter gewissen Umstaenden dem 100$t im
Normsatz entspricht (Oder 110$t, 111$t, 130$a !). Mit RDF
entfaellt die Trennung zwischen Objekt- und Hilfsdaten, zumindest
in dem Sinn, dass beides mit derselben Sprache beschrieben
wird. Und mit Mini-Thesauri anstelle von Codelisten bekommt
man auch Oberbegriff/Unterbegriff-Konstellationen besser in
den Griff (dem einen sein "Verfasser des Nachworts" ist dem
anderen sein "Beitraeger") [sofern es monohierarchisch bleibt,
"cmp" als Unter-Entitaet von sowohl "creator" als auch "contributor"
ist da ein Problem ;-)

Bibliothekarische Beschreibungen sind nach herrschender Lehre
"semistrukturierter Text", Aspekte der Reihenfolge sind wichtig
(wer ist der /erstgenannte/ Verfasser), es gibt trotz Tagging oder
Felderung haeufig Binnenstruktur (Name, *Komma*, Vorname), es gibt
scheinbare Redundanz (innerhalb der transkribierten Verfasserangabe
auf Manifestations-Ebene koennen wir eine Person identifizieren, die
als Link auf Werk-Ebene festgehalten werden sollte)

Um an die Beispiele von vor ein paar Tagen anzuknuepfen, hier ein
paar Beispiele aus den ISBD

. – London : Arts Council of Great Britain, 1976 (Twickenham : CTD
Printers, 1974)

Ist ein simpler Fall: sechs verschiedene bzw. zwei verschiedene
Gruppen von je drei verschiedenen Entitaeten, in RDF kann man
da nach Herzenslust verlinken. Und man kann das ISBD-Display daraus
ohne Probleme herstellen.

. - Zagreb : Stvarnost, [1977] (Zagreb : Vjesnik, 1976)

. - Budapest : Akadémiai K., 1977- (Debrecen : Alföldi Ny., 1978- )

sind schon komplizierter: Das "Jahr" hat zusaetzliche Attribute oder
ist doch eher ein String und keine verarbeitungsfreundliche Zeitangabe.
Das "Jahr" ist in Wirklichkeit ein "Startjahr": Entweder also mit
Strings und Binnenstruktur operieren oder das Vokabular
ausdifferenzieren...

, [1980], p 1973 (manufactured 1979)

(d.i. erschlossenes Erscheinungsjahr, Copyright bzw. P-Jahr,
Herstellungsjahr). Mitnahme von "(c)" bzw. "(P)" ist
zwingend, normalerweise vorlagegaemaess, die ISBD empfehlen
fuer das Herstellungsjahr die Uebernahme einer Wendung aus
der Vorlage, damit ist es normalerweise verstaendlicher als
ohne. RDF muss hier deutlich zweigleisig fahren und sowohl
den String als auch die darin enthaltene Zeitangabe in einem
kleinen Container sammeln, denn Operationen wie "extrahiere
die Zahl" gibt es nicht: Klar, es ist ein Format, das die
ueblichen Datentypen kennt, das ist dann implementierungs-
abhaengig. Aber man will ja gerade nicht dem Zufall ueberlassen,
dass eine Software mit "manufactured 1979" noch klar kommt,
mit "imprimé MCMLXXIX" aber nicht mehr. Datentypen spielen
ueberall, wo Computer eingesetzt werden, eine riesige Rolle -
ausser bislang in allem, was mit Cultural Heritage zu tun hat...


. – [S.l.] : [s.n.], [1869?] (México : Imp. de Juan Nepomuceno del Vaele
[i.e. Valle])

Kein Wert konnte ermittelt werden, ein Wert konnte erschlossen
werden, wobei eine gewisse Unsicherheit bleibt, ein transkribiertes
Wort wird erklaert oder korrigiert: Gerade letzteres ist ein
altbekanntes Problem: Wenn "Imp. de Juan Nepomuceno del Vaele"
ein Datenelement ist, das eine Transkription enthaelt, dann
zerstoere ich den transkriptiven Wert durch die Ergaenzung mit
eckig geklammerten (eckige Klammern haben traditionell eine
Vielzahl von Bedeutungen), bzw. muss das als Fussnote oder
Annotation auslagern - da bekomme ich aber Schwierigkeiten,
den Teilstring explizit anzugeben, den ich meine: "Letztes
Wort im Namen des Druckers ist eigentlich 'Valle'". Und das
maschinell verarbeitbar zu halten noch schwieriger (Eine
Aussage, die sich auf ein nur durch seine Art bestimmbares
Datenelement im aktuellen "Satz" bezieht, ist in RDF schon
schwer genug ("Reification"), fuer die Feinbestimmung, dass
zu den Zeichen auf Positionen 29-33 etwas ausgesagt werden
soll, muesste ein eigenes RDF-Vokabular eingesetzt werden.
In MARC und anderen Formaten kann man den gewuenschten Grad
von Maschinenlesbarkeit auch nicht herstellen, und RDA "loest"
das Problem, indem diese und andere Formen von Besserwisserei
eher komplett unterbunden werden.


. – Seattle, Wash. : Laser Learning Technologies, 1993 ; Hardwick,
Vt. : Optical Transfer [distributor], 1995

ein einfacher Fall


: printed by J. and H. Hughs ... and sold by T. Payne

gekuerzte Transkription eines zusammenhaengenden Satzes
der Vorlage gibt Aufschluesse ueber zwei Entitaeten mit
unterschiedlicher Funktion. D.h. wir brauchen nicht nur
auf der Ebene der individuellen Datenelemente fuer die
"Entitaeten" eine Moeglichkeit der vorlagengetreuen
Erfassung, sondern auch noch "uebergreifend". Weder
MARC noch RDF erlauben hier das individuelle taggen
von "J. and H. Hughs" einerseits und "T. Payne" andererseits.
Also alles doppeln? Software kann "J. and H. Hughs" dann
im Gesamt-String wiederfinden, in der Praxis wird es
allerdings auch noch eckig geklammerte Ergaenzungen in
den Transkriptionen geben, dann scheitert der Versuch.

. – Zippelzerbst gedruckt durch Flachslanden [i.e. Leipzig : Johann
Heinrich Ellinger]

Kommentar/Richtigstellung durch den Katalogisierer bezieht
sich simultan auf mehrere Datenelemente

. – Nueva York = New York

Wytisstené v Kryssstoffa Baumana, w Drazdanech = Gedruckt by
Christoph Baumann zu Dreßden

parallele Angaben eigentlich kein Problem, solange man
die Sprachen jeweils codiert *und* keine Erwartungen an
die Reihenfolge hat.

: printed for the editor, and sold by him

Hier haben Text und Informationsgehalt kaum maschinell
auswertbaren Bezug, Katalogisierung muss das zu "Daten"
machen, ohne dass wir das wie im vorigen Beispiel noch
fuer "redundant" halten wuerden.


. – New York : Columbia University ; Boston : Computer Research Institute

MARC und ISBD "regeln" das durch das Wechselspiel von $b zu $a
bzw. " : " zu " ; " und zurueck: alle Orte beziehen sich auf den
jeweils folgenden Namen (bzw. alle Namen beziehen sich auf die
unmittelbar vorangehenden Ort(e)). In RDF muesste man Container
bauen, die jeweils Verlagsnamen und zugehoerige(n) Ort(e) in
enger Verbindung halten. Die Reihenfolge geht dabei aber
standardmaessig floeten und muesste aufwendig codiert
werden.


. – Paris : le Centurion : Desclée De Brouwer : Éd. du Cerf

mehrere Verleger am gleichen Ort. Oder gemeinsames Handeln
an einem Ort? Klarstellung durch die Daten waere wuenschenswert,
aber die Vorlage wird uns haeufig keine Hinweise geben.
Es muss also vage gehalten werden...



– [México, D.F.] : Alfaomega ; León : Everest

bei Angaben mit gleicher Funktion muss gruppiert werden,
ein hier weggelassenes Erscheinungsjahr bezoege sich auf
beide.


. – Berlin ; Köln ; Frankfurt am Main

wieder so lange kein Problem, wie wir keinen Wert auf
die Reihenfolge legen.


Fazit: Bibframe bzw. alles RDF-basierende verschiebt den
Schwerpunkt auf das "Datenhafte" unserer Beschreibungen:
"Deskriptive" Katalogisierung steht damit wesentlich
deutlicher in Konflikt als in MARC-Bedingungen. Es kann
kein Ersatz sein fuer /alles/, was Katalogisierung bislang
ausmachte und m.W. behauptet das auch niemand.

Sinn bekommt die Angelegenheit womoeglich erst, wenn man
beim Katalogisieren nicht mehr an das Ausfuellen von
Feldern denkt sondern sich staerker an dem orientiert,
was wirklich ablaeuft: Man nehme eine geeignete Repraesentation
der Vorlage (Titelblatt- und Impressum-Scan, OCR-Ergebnis,
Transkript: Auslassungen dabei gemaess Regelwerk) plus dem,
was fehlt (Informationsquelle ist ja inzwischen weit
mehr als das). Die Erscheinungsangaben als Block kann man
mit der Maus markieren und als "Block der Erscheiungsangaben"
auszeichen. Und wenn man darin irgendwo "Imp. de Juan Nepomuceno
del Vaele" liest, dann muss man einerseits das "als
Drucker" markieren und andererseits hat man die Moeglichkeit,
das "Vaele" gesondert zu annotieren (oder das "Imp." aufzuloesen
und/oder "Juan Nepomuceno del Vaele" mit einem Personeneintrag
zu verlinken bzw. das Ganze mit einem Druckerei-Normsatz.
Markierungen innerhalb von Markierungen sind vom User Interface
natuerlich knifflig, das waere im Prinzip ein "Editionsprogramm
Light", aber auch das Genre der HTML-Editoren beherrschte das
meines Wissens durchaus, man darf aber auch gerne an Wiki-Text
denken.
Durch diesen Prozess hat man eine beliebig treue Wiedergabe
der Informationen (besser als jede Transkription bzw. auch
eine Transkription enthaltend) wobei ein Datenformat dafuer
noch nicht in Sicht ist, aber natuerlich ebenfalls wuenschenswert
waere.
*Zusaetzlich* haette der Katalogisisierungsprozess aber "harte"
Daten (Identifikation gewisser Wortgruppen als Einheit, Bestimmung
deren Funktion, Verlinkung, Umwandlung von Zahlen, ...) die sich
alle gut als RDF ausdruecken lassen (schachteln und klammern wie
gesagt kein Problem, Verlinkungsmoeglichkeiten superst) *und* mit
bestimmten Positionen in der Darstellung in exakter Verbindung
stehen (RDF laesst sich in XML-Serialisierung gut anderswo
/einbetten/ wenn ich die Annotation direkt neben das Transkript
des Wortes setze, das zu annotieren ist, dann bin ich nicht
wirklich darauf angewiesen, zu beruecksichtigen dass der Satz,
in dem das Wort vorkommt, fuer ein anderes RDF-Element noch
einmal als solcher herausgezogen wurde: Ich markiere, die
Maschine erstellt evtl. benoetigte Kopien).

Wenn ich diese Aussagen nun von ihrem Traeger loese und gewisse
davon weglasse (Aufloesung von Abkuerzungen etwa oder noch mehr
"Daten", die mir ein separater Prozess der automatischen Index-
ierung unsichtbar in den Text spuelt) und meine Anwendung ggfls.
noch mein Privatvokabular auf Bibframe umtrimmt, dann habe ich
eine "Bibframe-Beschreibung", die sich besonders gut als Linked
Data eignet und fuer Recherchen (z.B. Drill-Down-Komponenten und
Anreicherungen meiner Volltextindexierung um Ansetzungen oder
anderssprachige Labeels), und allgemein fuer den Austausch.

Und in Verbindung mit dem Kontext belassen bekomme ich eine
hochqualitative "Leseversion" des Katalogisats, in der ich
die Freiheit habe, die Daten in Form eckig geklammerter
Zusaetze "textlastig" zu montieren oder in fuer das jeweilige
Ausgabegeraet geeigneter Form latent zu lassen und erst
einzublenden, wenn der Benutzer durch Hover, Klick oder Touch
sein naeheres Interesse bekundet. (Auch die Anzeige von ineinander
geschachteltem Hypertext ist allerdings eine Herausforderung...)

Bzw. wenn das "Katalogisat" online steht, dann kann sich jeder
Interessent daraus selber die RDF-Statements herausgrabbeln, die
er versteht und adhoc interpretieren bzw. mit ihm, aber nicht mir
bekannten RDF-Statements zusammenbringen und Schluesse ziehen:
So laeuft das ja z.B. mit COinS ab oder - bereits in RDF
ausgedrueckt - mit schema.org: In eine "Seite" sind Metadaten
eingebettet (niemand schert sich da um Redundanz, es ist ein
/Extrakt/).

Bibframe ist also die Antwort auf die Frage, wie wir das
Resulat notieren, wenn wir aus unseren Beschreibungen die
"harten" Daten herausdestillieren, bzw. sogar nur den Kern
davon der bleibt, wenn wir moeglichst viel durch breiter
etablierte Teilvokabulare fuer spezielle Aspekte ausdruecken.

Bibframe ist aber nicht der Ersatz fuer Regelwerke und auch
keinesfalls das Universaldatenformat fuer alle Ergebnisse
biblothekarischer (oder auch nur katalogisierender) Taetigkeit.

viele Gruesse
Thomas Berger