[Allegro] Zum Thema GND, 2+3: Wesen und Struktur

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,


>> Naja, es gibt Gruende, fuer die Normdaten mit der MARC-Einfuehrung
>> vorzupreschen. Bzw. da ist der Leidensdruck besonders gross gewesen.

> Na schön. Und viele Ihrer Aussagen entbehren ja nicht jeden Nährwerts,
> nur, was machen wir jetzt damit?
> Schlagen Sie konkret vor, was wir mit GND nun anstellen sollen! Oder
> *machen* Sie es vor.

Im HANS-Kontext sind wir zu einem aehnlichen Schluss gekommen wie
es auch fuer die (Normdatenhaltigen, das sind ja laengst nicht alle)
Lokalsysteme in einigen Verbuenden geplant ist, allerdings ist die
Situation im Nachlassbereich komplex, weil auch Normdatenexporte
bedacht werden muessen und die spezielle Situation von Kalliope:

Eher Kurzfristig sollte versucht werden, die vorhandenen Internstrukturen
mit einer neu zu schaffenden GND-MARC21-Importschnittstelle halbwegs zu
bedienen (Vorteil: MAB-Exporte bleiben moeglich)

Mittelfristig soll dann parallel eine neue, analog PICA und MAB-Aleph-
Systemen an GND-MARC angelehnte, Internstruktur fuer Normdaten
implementiert werden. (Vorteile: GND-MARC Im- und Exporte werden
recht einfach, vorhandene Redaktionsanleitungen zur GND werden
nutzbar, der groessere Reichtum der GND-Daten kann ausgenutzt
werden, es koennen intern GND-kompatible Daten neu angesetzt werden).

Sicher ist, dass man das Gros der in den alten Internstrukturen
vorliegenden Daten, das bereits PND- etc. Nummern hat, durch Reimport
aus der GND im neuen Format bekommen kann (die SRU-Schnittstelle ist ja
kostenfrei, erfordert nur Anmeldung) und daher dann recht elegant
auf die neue Internstruktur umsteigen kann (So machen es die Verbuende
im April: Es wird ja nirgendwo konvertiert, sondern nur ausgetauscht).

Sicher ist auch, dass eine universelle Umsetzung der Internstrukturen
nicht gut moeglich ist: Das wuerde ja oft sogar ueber eine
universelle Umsetzung der Formate hinausgehen, weil lokal entstandene
oder lokal angereicherte Daten sich nur an den Moeglichkeiten der
Internstruktur orientieren und daher z.B. auch nicht PND-kompatibel
gewesen sind (Berufe sind nicht SWD-verknuepft, Wirkungsdaten nach
anderem Standard erfasst, es gibt Zeittafeln etc.). Es handelt sich
dabei aber um ein altes Dilemma, das durch die GND-Einfuehrung nicht
wirklich verschaertf wird: Die /Hoffnung/ ist, dass Neuansetzungen
i.d.R. keine besonders komplexen Saetze sind, die entweder als
MAB-Export an Kalliope oder als recht einfach gehaltener MARC-Export
irgendwann irgendwohin abgefuehrt werden koennen, und durch MARC-
Reimport oder mit einem gewissen Verlust behaftete(!) interne
Umsetzung "geregelt" werden koennen: Es sollte da einen Anlass
geben, an eine (verlustlos und auf Verdacht) Umsetzung der nicht wirklich
PND-kompatiblen Daten aus der alten Internstruktur in die neue,
wobei dann nicht wirklich GND-Kompatible Daten entstehen, ist nicht
gedacht.
Bei den Anreicherungen vorhandener Saetze ist es aehnlich: Auch hier
gab es keine Ablaeufe, die regelmaessig kontrolliert haetten, ob
neuere Versionen desselben Normsatzes die zusaetzlichen Inhalte
inzwischen ebenfalls kennen. Anreicherungen, die dieselben Felder
benutzen wie auch importierte Normdaten, waren also schon immer
problematisch. Eine Internstruktur, die alle Felder doppelt, so dass
ein Reimport jederzeit moeglich ist, habe ich auch schon einmal
implementieren muessen, den Nutzen halte ich fuer fragwuerdig: Niemand
hat die Kapazitaet, das alles nachzukontrollieren, denn so eine
Dopplung laeuft ja darauf hinaus, dass man Datenfeld fuer Datenfeld
alles (und zumindest im Fall von Aenderungen: intellektuell !)
nachkontrolliert, was sich in der Normdatei gaendert hat.

[Zum *machen*: Ich bin von Beruf Softwareentwickler, der seine Sachen
unter Open Source stellt, d.h. jeder kann alles nachnutzen, was
es gibt. Wenn ich nun auch noch ohne konkrete Auftraege aus eigener
Initiative alles programmiere, was nuetzlich ist oder gebraucht wird,
bricht das Geschaeftsmodell sofort zusammen. Und bei der GND-Einfuehrung,
und der generellen MARC21- und RDA-Einfuehrung naechstes Jahr ist
es nie zu solchen Auftraegen gekommen, nicht einmal zu Anfragen:
Anscheinend erwarten gerade bei gefuehlt "grossen" Sachen die
Anwender, dass alles schon nicht so schlimm sein wird (also Normdaten-
Downloads auf altbekannte Weise weiter funktionieren), oder dass
die "Firma allegro" das schon richten wird]


>> http://d-nb.info/gnd/121145344
> 
>> ist von den Traegern der PND und der GND als "Persistenter Identifier"
>> deklariert. Dahinter steckt natuerlich das Versprechen der
>> Institution, diese HTTP-URIs in Zukunft operabel (im URL-Sinn) zu
>> halten. Das ist just gestern ja auf Inetbib noch einmal bekraeftigt
>> worden.
> Da lese ich nicht mit. Trotzdem ist es betulich, die URI im Normsatz
> zu transportieren, wenn das einzig Eindeutige daran die Nummer ist und
> die schon woanders steht. Wenn die Nummer nicht stabil ist, nützt die
> URI auch nichts, aber eine URI birgt noch zusätzliche Schwachpunkte
> und wird irgendwann Eingriffe erfordern, so blauäugig können Sie doch
> nicht sein. Außerdem ist ja das, was bei just dieser URI rauskommt,
> nicht eben für einen automatisierten Service optimal, sondern nur
> für das Hervorrufen einer dann unautomatisiert visuell auszuwertenden
> Anzeige. Es wird andere geben, es werden andere entstehen, man wird
> also eh per Software sich die jeweils passende richten müssen und
> können, immer auf Basis derselben Nummer.

In MARC 024 steht als URI:

http://d-nb.info/gnd/121145344/about

das ist z.B. der Datensatz repraesentiert als RDF XML. Das hat zwar
zu tun mit, ist aber nicht dasselbe wie (588a)121145344, (588)121145344
oder < http://d-nb.info/gnd/121145344 >, was /Identifier/ fuer einen
"Datensatz" sind.

Im RDF-Kontext benoetigt man aber URIs (oder IRIs), und da ist es
hoechst angemessen, dass der Normsatz eine vorgibt und man nicht
externes Geheimwissen im Sinne einer Bildungsvorschrift benoetigt
(es geht ja gerade darum, dass nicht jeder fuer dieselbe Ressource
eine eigene URI ableitet oder ausdenkt).

Dass man URIs in MARC allerdings nicht direkt als Identifier
benutzen kann, sondern an die MARC-Syntax fuer Identifier gebunden
ist ( < http://www.loc.gov/marc/authority/ecadcntf.html > ), kann man
nicht unbedingt der GND vorwerfen: Immerhin sind die Unterfelder $0
fuer Identifier ueberhaupt erst vor ein paar Jahren im Zuge der
Vorbereitung der MARC-Umstellung in D/A/CH im MARC21 eingefuehrt worden.

viele Gruesse
Thomas Berger