[datenformate] Zum Aschermittwoch: Was wird aus MARC?

[Bernhard Eversberg]

Am 09.03.2011 10:17, schrieb Jakob Voss:
>
> Vielen Dank für ihre offenen Worte. Wir wissen es nicht. dies gilt für
> jede der genannten Alternativen (XML, MODS, RDA, RDF... - wobei hier
> Äpfel mit Birnen verglichen werden). Deshalb bleibt nichts anderes übrig
> als es auszuprobieren, ...
>
Aber was ist "es"?

> Ich möchte auf einen Aspekt hinweisen, der anscheinend immer wieder
> übersehen wird. Sie sprechen von "einem MARC-Nachfolger" und "voll
> ablösen", als sei das einzig denkbare, MARC durch ein ebenso
> monolithisches System zu ersetzen. Vielleicht deutet die Schwierigkeit,
> einen Nachfolger zu finden, darauf hin, dass es nicht den einen
> Nachfolger geben wird. Für die bibliothekarischen Anforderungen bis in
> die 1980er Jahre erfüllt MARC seinen Zweck doch auch nicht schlechter
> als andere denkbare Systeme, warum also nach einem Nachfolger suchen?
>
Also ich habe nur referiert, nicht selber nach einem Nachfolger gerufen!
Einige Nachteile von MARC hatte ich aber dennoch in meiner
Präsentation aufgelistet:

   http://www.biblio.tu-bs.de/db/a30/marc.htm
(Inhaltsübersicht, Punkt 5)


> Die Frage "Was kommt nach MARC?" ist eben falsch gestellt, denn es wird
> nicht die eine Lösung kommen. Stattdessen müssen wir uns damit abfinden,
> in einer Welt zurechtzukommen, wo viele verschiedene Techniken und
> Formate nebeneinander verwendent werden und lediglich über gemeinsame
> Basistechnologien wie Unicode, HTTP und URI miteinander verbunden sind.
> Die Alternativen zu MARC sind nämlich schon längst da, nur verstellt das
> Katalogkarten-zentrierte Paradigma die Sicht darauf.
Also welche sind sie, diese Alternativen, die schon das Potential haben
für alles, was wir brauchen, und wo man die konkreten Ansätze schon 
sehen kann, d.h. wo wir schon anfangen können, "es" auszuprobieren?

 > Die Verabschiedung vom
> Konzept "Datensatz", das letztendlich wieder auf die Katalogkarte
> zurückführt, ...
Das halte ich aber nicht so für zwangsläufig.

>  > Ein solches Konzept mag gut ins "Cloud"-Paradigma des globalen Netzes
>  > passen, es bräuchte aber noch weit mehr Speicher und
>  > Verarbeitungsleistung und noch dazu Bandbreite ohne Ende, weil ja
>  > dem Suchenden dann doch immer wieder Zusammenfassungen von Statements
>  > präsentiert werden müssen, und die wären dann jeweils blitzschnell
>  > von allen Kontinenten herbeizuholen.
>
> Das ist ein verbreiteter Irrtum. Best-Practice ist, die benötigten Daten
> durch Caching jeweils lokal vorzuhalten. Das ist bei "Lokalsystemen der
> alten Schule", die ihre Daten in regelmäßigen Updates von anderen
> Systemen beziehen, auch nicht anders.
Hier freilich wären der Umfang und die Komplexität weit höher. Mir
klingt das noch zu wolkig, auf jeden Fall momentan nicht praktikabel.
Hier haben Sie recht: Ausprobieren, demonstrieren, überzeugen mit einem
funktionierenden Modell. Wenn's aber nicht gelingt: dokumentieren und
begründen.

>
> Vielleicht sollten wir endlich aufhören uns auf die Schifffahrt zu
> beschränken, sondern lernen, je nach Ziel und Weg das jeweils passende
> Verkehrsmittel zu wählen. Wir werden nicht darum herumkommen, auch mal
> einen kaputten Motor reparieren zu müssen. Dafür bin ich mir sicher,
> dass uns auf der einen oder anderen Strecke jemand mitnimmt, wenn wir
> uns dazu bequemen, den den Daumen rauszuhalten.
>
Klingt alles gut, hilft aber konkret nun wirklich nicht weiter.
Was wären die *konkreten* Schritte, die zuerst und schon jetzt getan
werden könnten?

B.E.