[Allegro] In the dawn's early light

Fr Nov 29 11:27:15 CET 2013

Hallo Herr Berger, Liebe Listenleserinnen und -leser,

schöner Beitrag.

Ich verstehe das so:

Solange Referenzdaten und DV-Ressourcen frei verfügbar bleiben, habe 
ich die Möglichkeit mich den Zwängen, die mir die hinter den 
Monopolisierungsbestrebungen stehenden Kräfte auferlegen wollen, zu 
entziehen.

Viele Grüße
Anando Eger

On 29 Nov 2013 at 9:56, Thomas Berger wrote:

> Lieber Herr Eversberg, liebe Liste,
> 
> > neue, ganz andersartige Datendarstellungen. Die taugen dann
> > viel besser zum Verlinken quer durch's Netz und rund um den Globus,
> > und es sollen sich damit die zu einer Anfrage passenden Aussagen
> > über "Ressourcen" eigendynamisch zu einem jeweils passenden Gesamtbild fügen,
> > statt wie bisher den Nutzer mit einheitlichen, festgefügten
> > Textblöcken abzuspeisen, wie es Datensätze nun mal sind. Anders
> > gesagt, nicht den MARC-Nummern ist der Garaus angesagt, sondern
> > dem altvertrauten Konzept des bibliographischen Datensatzes als Surrogat
> > für die Ressource, sozusagen eines elektrifizierten Katalogzettels,
> > der ja noch kaum aus dem Schatten des langen 19. Jahrhunderts
> > heraustritt.
> 
> So wie ich das mitbekommen habe, gilt die "Kampfansage" weder
> dem einen noch dem anderen. Nur gibt es halt viele Probleme
> mit MARC21 (einfach nach "MARC must die" googlen) und die
> koennen eher nicht durch eine "Verbesserung" des Formats
> geloest werden.
> 
> Das Konzept des "Datensatzes" steht insofern auf dem Pruefstand,
> als dass durch FRBR und RDA mittlerweile geklaert ist, dass
> der ohnehin aus verschiedenen logischen Schichten oder Ebenen
> besteht, die man sauberer als frueher voneinander trennen
> sollte, damit Records zu verschiedenen Ressourcen, die aber
> (in einem durchaus spezifizierten Sinn) ~irgendwie~ miteinander
> zu tun haben, einerseits sauber auseinander gehalten werden
> koennen, andererseits aber zueinander finden koennen.
> 
> Man muss auch immer wieder darauf hinweisen, dass alle diese
> Unternehmungen von der Situation in MARC21/AACR2-Land ausgehen,
> insbesondere von der Praxis der MARC21-Anwendung und nicht
> dem Potential. D.h. /Verknuepfungen/ gibt es nur in seltenen
> Faellen, z.B. von Aufsaetzen zum enthaltenden Werk oder
> u.U. von Stuecken zum Reihentitel. Bandauffuehrungen gibt
> es nicht (nur Fussnoten mit den Bandbenennungen in der
> Hauptaufnahme). Umgekehrt - und das geht weit ueber unseren
> Erfahrungshintergrund hinaus - ist das Format so flexibel,
> dass in einem Record Erschliessungen nach unbeschraenkt
> vielen offiziellen oder lokalen Regelwerken hinterlegt werden
> koennen, ohne sich in die Quere zu kommen. Das heisst fuer
> den Anwender einerseits, dass er - anders als hierzulande -
> seine Privaterschliessungen im Verbund hinterlegen kann,
> andererseits aber auch, dass normalerweise nicht "der"
> Datensatz genutzt (indexiert, angezeigt, ...) wird, sondern
> eine fuer das Zielsystem gefilterte Sicht.
> 
> Abgesehen von der Beschraenkung auf 99999 Bytes pro Datensatz
> laesst sich damit bequemer leben als mit MAB2 (und alle
> "unsere" Internformate haben MAB2 und seine Vorgaenger als
> geistige Eltern, d.h. wenn ich "MAB2" sage, dann meine ich
> alle allegro-Formate und auch PICA und was auch immer: Alle
> sind urspruenglich unter der Annahme entstanden, dass ein
> "Datensatz" eine - mehr oder weniger kohaerente - Sicht
> auf das aussagbare zur Ressource enthaelt, Pluralismus kommt
> eher ueber damit verknuepfte Lokalsaetze etc. ins Spiel,
> fuer Normsaetze aber haben wir so ein Konzept gar nicht).
> 
> Dies stoesst aber /organisatorisch/ an seine Grenzen, wenn
> es nicht um die klassischen Top-Down-Modelle des "Datentauschs"
> geht (aktuelle "Vision": Alles ist in der OCLC-Cloud oder
> der Exlibris-Cloud als "Master record" und diffundiert von
> dort aus "nach unten"), sondern um das, was derzeit durch
> das Wort "Anreicherungen" etwas diffamiert wird: Wenn ich
> /regelmaessige/ Aktualisierungen erhalte und die nicht
> aus /exakt einer Quelle/ stammen (etwa weil ich lokale
> Aenderungen vornehme, die nicht im "Verbund" hinterlegt
> sind), dann muss ich nach jedem Update alles kontrollieren
> und im Zweifelsfall neu machen. Eine Strategie dafuer ist
> wie gesagt, "eigene" Aenderungen immer nur "moeglichst weit
> oben" vorzunehmen und dann das Top-Down-Update abzuwarten.
> Abgesehen von der dadurch entstehenden Bremse im
> Geschaeftsgang ist das aber ein ungut biblothekarischer
> Ansatz, denn er funktioniert nur, wenn alles, was ich
> fuer erwaehnenswert halte, "in der Cloud" bereits mit
> den entsprechenden Datenfeldern und -strukturen vorbereitet
> ist und auf meine Eingaben harrt.
> 
> Wenn man andererseits akzeptiert, dass meine Verzeichnungswuensche
> von morgen eventuell nicht rein bibliothekarisch motiviert
> sind, sondern die Beduerfnisse der speziellen Nutzerschaft
> der konkreten Bibliothek realisieren (Verlinkung auf andere -
> nichtbibliothekarische Bestaende - im Haus, Verlinkung
> auf eine Fachdatenbank oder selbst erstellte / digtialisierte
> und erschlossene historische Fachinformation, ...), dann
> ist es a) so, dass das heute u.U. noch nicht bekannt ist
> und b) die Top-Down-Speicherung an ihre Grenzen stoesst (ich
> muss es dort manuell eintragen, ich muss evtl. Codes registrieren,
> ich kann nur Text eintragen und nicht andere Datentypen, kann
> also die Eingaben nicht validieren etc. pp. Kurz: Ohne den
> Anbietern der grossen Bibliothekssysteme auf den Schlips treten
> zu wollen glaube ich einfach nicht, dass diese Systeme auf
> absehbare Zeit eine Loesung fuer allgemeine Datenverarbeitungs-
> oder auch nur Datenbankaufgaben darstellen werden - sonst
> waeren die Aktienkurse von Microsoft und Oracle und anderen schon
> laengst abgestuerzt...). Wenn ich nun aber weiss, dass Quelle X
> einen fuer mich interessanten Datenbestand bereits erschlossen
> hat, aber nicht in der Cloud hinterlegt hat, dann habe ich
> u.U. das Beduerfnis, diesen Bestand bei mir ebenfalls nutzbar
> zu machen: Schwupps habe ich /regelmaessigen/ Datenimport aus
> mehr als einer Quelle und das funktioniert nur (in heutiger
> Sprache), wenn ich Aenderungen auf "Feldebene" nachvollziehen
> kann, was ganz schwierig wird, wenn manche Eintraege entfallen
> (man denke an die URL von Projekt X im "Record": Dort ist es nur
> eine unter vielen, bei einem Update muesste sie gezielt veraendert
> oder sogar "auf einen anderen Record uebertragen", d.h. hier
> geloescht werden). In aktuellen Diskussionen wird dieser Aspekt
> meist "metadata provenance" genannt.
> 
> In solchen Szenarien ist es immer noch so, dass ich den "Datensatz"
> als Container fuer alle Aussagen zu einer Ressource kenne, aber
> im Prinzip jede Einzelaussage zwar nicht unbedingt individuell
> adressieren koennen will, jedoch anhand gewisser, "feldspezifischer"
> Verwaltungsdaten einen Zugriff vorbehalten moechte. RDF gibt da
> einen Ansatz (Einzelaussagen werden als abstrakte Graphen
> aufgefasst) und nach meinem Verstaendnis versucht Bibframe,
> solche Ansaetze auf die bibliothekarisch-bibliographische
> Situation umzusetzen: D.h. Es gibt Entitaeten, die den von
> FRBR/RDA modellierten entsprechen, beschrieben werden diese
> aber durch Einzelaussagen a la RDF und die Hoffnung ist, dass
> so etwas dann einerseits quasi adhoc von jedermann lokal
> um beliebige nichtbibliothekarische Aussagen angereichert werden
> kann und andererseits alles so auf die Reise geschickt werden
> kann, dass das Aufeinanderprallen von Beschreibungen aus
> verschiedenen Quellen in meinem Lokalsystem eben nicht mehr
> die Entscheidung zwischen Verlust, unbrauchbarem Mischmasch
> und/oder extensiver Nachbearbeitung erfordert.
> 
> 
> viele Gruesse
> Thomas Berger
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro