Aufgabenliste Normdatenverwaltung (ALNV)

Allgemeines

Die Aufgabenliste Normdaten-Verwaltung (kurz: ALNV) ist ein Werkzeug

• um in definierten Fällen von Änderungen in der GND
• die jeweils in der eigenen Datenbank betroffenen Titeldatensätze zu finden,
• sie zu überprüfen und gegebenenfalls Korrekturen vorzunehmen.

Die nötigen Änderungen haben zwar in der GND ihren Ursprung, durchgeführt müssen die Korrekturen jedoch in den bibliographischen Daten werden!
Ein Unterbleiben dieser Korrekturen hat keine Auswirkung auf die GND, hat aber falsche oder ins Leere zeigende Verlinkungen in den Titeldaten zur Folge.
Die ALNV ist also ein wichtiges Instrument für die Qualitätssicherung der bibliographischen Daten.

Die ALNV selbst führt keine Änderungen in den Titeldaten durch, sie ist nur ein Werkzeug, um die Reports unterschiedlicher Alma-Jobs in strukturierter Form anzuzeigen.
Diese Jobs übertragen nicht nur GND-Änderungen in die Titeldaten, sondern generell alles, was durch irgendeine der Normdatenbanken ausgelöst wird (BK, RVK, DDC, LCNames, LCSH etc.)

Gegliedert ist die ALNV in Report Types, die über unterschiedliche zugrundeliegende Sachverhalte Auskunft geben. Unter diesen Report Types finden sich

• solche, die ignoriert werden können.
  (Diese sind nur relevant für Normdatenbanken, die über Textstrings verlinken, nicht jedoch für die GND, wo dies mittels ID-Nummer geschieht.)
• solche, die über automatisch ablaufende Änderungen Auskunft geben und rein informativen Charakter haben.
  (Z. B.: der bevorzugte Name eines verlinkten Normdatensatzes hat sich geändert, es wurde eine Änderung an einem verlinkten Normdatensatz vorgenommen etc.)
• solche, die tatsächlich einer Nachbearbeitung bedürfen.

---

Vorgangsweise

• Die ALNV findet sich in Alma im Bereich "Ressourcen".
• Alle Report Types, die tatsächlich einer Nachbearbeitung bedürfen, befinden sich im Tab „Zur Prüfung“.

Da Alma während der Suche immer wieder auf die schon ausgewählten Filter vergisst, empfiehlt sich folgende Vorgangsweise:

• Zuerst: Auswahl des gewünschten Report Types
• Dann Einschränkung auf "Verknüpft mit: Netzwerkzone"; damit entfallen die CZ-Datensätze, die nicht bearbeitet werden können/sollen.
• Und erst zuletzt im Wortschatz auf GND filtern
  Da die ALNV nicht nur Vorgänge dokumentiert, die ihren Ursprung in der GND haben, sondern von allen in Anwendung stehenden Normdatenbanken, muss der Wortschatz auf GND eingeschränkt werden.
  (GND-CARRIER und GND-CONTENT bleiben unberücksichtigt. Hierbei findet keine richtige GND-Verlinkung statt.)

Unter "Datenbereich senden" kann man die Trefferliste auf ein spezifisches Datum eingrenzen.
Aber Achtung: Einträge, die älter als 6 Monate sind, werden vom System aus der Liste entfernt! Es empfiehlt sich daher, die Liste regelmäßig abzuarbeiten!

Über die drei Punkte ("Weitere Aktionen) kann man über "Bearbeiten" den Datensatz in den Metadaten-Editor pushen. Nach der Korrektur muss der Datensatz mittels "Für das Netzwerk entfernen" aus der Trefferliste entfernt werden. Mit dieser Funktion wird der Datensatz für ALLE Bibliotheken aus der ALNV entfernt. Würde man stattdessen die Funktion "Lokal entfernen" verwenden, würde der Datensatz nur aus der ALNV der eigenen Institution verschwinden, in der ALNV anderer Institutionen aber noch immer aufscheinen.

Im Metadaten-Editor bildet sich mit den Datensätzen aus der ALNV ein eigenes Set:

---

Folgende Report Types bedürfen tatsächlich einer Nachbearbeitung:

1. Verknüpfung - BIB-Indexeintrag hat keine übereinstimmenden AUT-Indexeinträge gefunden

Im bibliographischen Datensatz findet sich hierbei als GND-Verlinkung eine ID-Nummer, die keine Entsprechung in der GND hat. Oftmals liegt dem ein Tippfehler zugrunde. Teilweise tauchen hier derzeit leider aber auch "umgelenkte" Titeldatensätze auf, bei denen manuell nichts gemacht werden muss! (Dieser Fehler wurde bereits gemeldet.)

Beispiele:

GND-Nummer zu kurz:

Falsch:	700 1#	$$a Ozu, Yasujirō $$d 1903-1963 $$0 (DE-588)11859105 $$4 fmd $$4 aus
Richtig:	700 1#	$$a Ozu, Yasujirō $$d 1903-1963 $$0 (DE-588)118591053 $$4 fmd $$4 aus

GND-Nummer falsch (letzte Ziffer unterschiedlich):

Falsch:	700 1#	$$a Pfisterer, Matthias $$d 1971- $$0 (DE-588)1049612667 $$4 aut
Richtig:	700 1#	$$a Pfisterer, Matthias $$d 1971- $$0 (DE-588)1049612663 $$4 aut

GND-Nummer zu lang:

Falsch:	689 03	$$a Rechtsradikalismus $$d s $$0 (DE-588)4048829-9930
Richtig:	689 03	$$a Rechtsradikalismus $$d s $$0 (DE-588)4048829-9

Bevorzugter Sucheinstieg enthält Beistrich zuviel:

Falsch:	700 1#	$$a Celestini, Federico, $$d 1964- $$0 (DE-588)128474432 $$4 edt
Richtig:	700 1#	$$a Celestini, Federico $$d 1964- $$0 (DE-588)128474432 $$4 edt

$$0 enthält keine GND-Nummer, sondern eine Nummer einer anderen Datenbank:

Falsch:	751	$$a Lyon (Rhône) $$0 (IDREF)027262782 $$4 pup
Richtig:	751	$$a Lyon $$0 (DE-588)4036770-8 $$4 pup

Falsch:	700 1#	$$a Villiers du Terrage, Édouard <<de>> $$d 1780-1855 $$0 http://viaf.org/viaf/31990978 $$2 viaf $$4 aut
Richtig:		Im Idealfall neuen GND-Datensatz erstellen.

Falsch:	689 00	$$a Österreich $$x Gewerbeordnung $$d b $$0 GP0006872
Richtig:	689 00	$$a Österreich $$t Gewerbeordnung $$f 1859 $$x Gewerbeordnung $$d b $$0 (DE-588)1112484086

Falsch:	700 1#	$$a Martínez-Roldán, Alfredo de Jesús $$0 (orcid)0000-0003-1380-8415
Richtig:	700 1#	$$a Martínez-Roldán, Alfredo de Jesús $$9 (orcid)0000-0003-1380-8415

Anmerkung: In solchen Fällen überprüfen, ob eine GND-Verlinkung möglich ist. Ist nur eine ORCID vorhanden, wird diese in $$9 angegeben. Wird später über F3 mit der GND verlinkt, bleibt die ORCID in $$9 bestehen. Wird die ORCID in Folge im GND-Datensatz eingetragen, dann sollte das $$9 im bibliographischen Datensatz entfernt werden.

Es handelt sich um einen PN-Satz (Nicht individualisierter Personenname):

Falsch:	100 1#	$$a Reetz, Gaby $$0 (DE-588)1076142044 $$4 aut
Richtig:		Kein Eintrag über F3 gefunden. GND-Nummer entfernen bzw. - falls vorhanden - mit richtigem GND-Datensatz verlinken.

Tipp: Überprüfung mittels GND-Nummer im DNB-Katalog:

Falscher Entitätentyp:

Falsch:	700 12	$$a Mozart, Wolfgang Amadeus $$d 1756-1791 $$t Sonaten $$m Klavier $$n KV 284 $$r D-Dur $$d p $$0 (DE-588)3001112662
Richtig:	700 12	$$a Mozart, Wolfgang Amadeus $$d 1756-1791 $$t Sonaten $$m Klavier $$n KV 284 $$r D-Dur $$0 (DE-588)300111266

GND-Datensatz, der in der Zwischenzeit gelöscht wurde:

Falsch:	710 2#	$$a !!!GESPERRT!!!Palacio Episcopal $$g Málaga $$0 (DE-588)6071678-2 $$4 ctb
Richtig:		Kategorie löschen.

Zu schnell getippt:

Falsch:	689 03	$$a Religion $$g Motiv $$d s $$0 (DE-588)4207560-9spirita
	689 04	$$a Spiritualität $$g Motiv $$d s $$0 (DE-588)4547675-5
Richtig:	689 03	$$a Religion $$g Motiv $$d s $$0 (DE-588)4207560-9
	689 04	$$a Spiritualität $$g Motiv $$d s $$0 (DE-588)4547675-5

"Lokale" Normdatenverlinkung der Vorarlberger Landesbibliothek (VLB):

Falsch:	700 1#	$$a Stecher-Konsalik, Dagmar $$g Autorin $$0 (AT-VLB)LA00174213 $$e edt
Richtig:		Bitte NICHT löschen, sondern die Lokalredaktion der VLB verständigen! Diese Verlinkung darf nur in lokalen Datensätzen der VLB vorhanden sein, ist aber irrtümlich auf die NZ-Ebene gelangt. Die VLB wird stattdessen eine GND-Verlinkung herstellen oder die Person neu in der GND ansetzen.

---

2. GND – Teilumlenkung

Dieser Report Type kommt vor, wenn bei Geografika Namensänderungen auftreten und "eine chronologische Leiter" aufgebaut wird. → Für die Sacherschließung wird bei Splits nur die neueste/jüngste Namensform verwendet. → In der Formalerschließung kommt immer die zeitlich gültige Namensform zur Anwendung.

Beispiel:

Eine Publikation aus dem Jahre 1997 ist von und über die Gemeinde Kainbach.
Seit Juni 2000 ist diese Gemeinde unter dem Namen Kainbach bei Graz im Österreichischen Amtskalender zu finden:

Namensform der Gemeinde bis Mai 2000:	110 1#	$$a Kainbach $$0 (DE-588)4490833-7 $$4 aut
	689 XX	$$a Kainbach $$D g $$0 (DE-588)4490833-7
Namensform der Gemeinde ab Juni 2000. In der SE in Folge Änderung auf (Teilumlenkung)*:	689 XX	$$a Kainbach bei Graz $$D g $$0 (DE-588)1379959667

*Anmerkung:
In der SE wird bei Namenssplits also auf die neueste/jüngste Namensform geändert.

In der FE ist im konkreten Fall (1997) bei diesem Report Type kein Handlungsbedarf.
ABER: Wäre die Publikation nach Juni 2000 erschienen, müsste die Eintragung in 110 auch in der FE auf die zeitlich gültige Namensform angepasst werden.

---

3. GND – Aufspaltung mit Umlenkung

Siehe unter 4. GND – Aufspaltung ohne Umlenkung

---

4. GND – Aufspaltung ohne Umlenkung

Der Report Type "GND – Aufspaltung mit Umlenkung" bzw. "GND – Aufspaltung ohne Umlenkung" weist auf einen Normdatensatz hin, in dem bisher fälschlich Angaben zu verschiedenen Entitäten vermischt waren, für die nunmehr getrennte Normdatensätze existieren. (Der Unterschied zwischen Aufspaltungen mit bzw. ohne Umlenkung betrifft ausschließlich Prozesse im Bestand der DNB, die für die Behandlung im OBV nicht weiter relevant sind.) Meist handelt es sich dabei um Personen mit gleichem oder sehr ähnlichem Namen. Es gibt aber auch Fälle, in denen z.B. ein Pseudonym von einem Datensatz für den wirklichen Namen abgespalten wird oder umgekehrt. Im betroffenen Normdatensatz wird dabei eine Kennzeichnung in Feld 682 eingefügt, mit der auf den anderen (bereits bestehenden oder neu angelegten) Datensatz hingewiesen wird. Bei den verknüpften bibliografischen Datensätzen ist daher zu überprüfen, ob die bestehende GND-Verlinkung (weiterhin) korrekt ist oder ob auf den anderen Normdatensatz umverlinkt werden muss.

Details:

• Die Kennzeichnung im bestehenden Normdatensatz hat die Form

682 ##

$$i Aufspaltung-ohne-Umlenkung $$0 (DE-588)... $$a Vorname, Nachname [sic!]

bzw.

682 ##

$$i Aufspaltung-mit-Umlenkung $$0 (DE-588)... $$a Vorname, Nachname [sic!]

• Immer wenn in der GND-Quelldatei ein Normdatensatz mit Aufspaltungshinweis gespeichert wird, entsteht (i.d.R. einen Tag später) bei allen betroffenen BIB-Sätzen für jedes damit verlinkte Feld jeweils ein separater Eintrag in der ALNV.
• Dadurch kann es - bei mehreren Speichervorgängen im Zeitraum, während der Datensatz den Hinweis trägt - manchmal zu Redundanzen kommen.
  Von völlig identen Einträgen in der ALNV (MMS-ID und Feld gleich) muss daher nur jeweils einer überprüft werden, die weiteren können gleich gelöscht werden.
• Hingegen müssen verschiedene Manifestationen desselben Werkes - die sich in der ALNV meist nur durch die MMS-ID unterscheiden - natürlich getrennt überprüft und ggf. bearbeitet werden.
• Vorsicht ist weiters geboten, wenn in einem BIB-Satz verschiedene Felder mit dem gleichen Normdatensatz verlinkt sind und daher separat in der ALNV aufscheinen. Meistens werden alle gleich zu behandeln sein (z.B. Verlinkung in 100 und 689 bei Autobiografien: entweder beide oder keines umverlinken), es kann aber in seltenen Fällen auch nötig sein, diese unterschiedlich zu handhaben (z.B. 100 und 700 bei gleichnamigen Familienmitgliedern, die beide an einer Ressource beteiligt sind, oder 100 und 689, wenn eines ein Werk über das andere verfasst hat).
• Der Aufspaltungshinweis in Feld 682 verbleibt maximal eine Woche im Normdatensatz. Danach wird er im Zuge der Auslieferung über den wöchentlichen GND-Änderungsdienst in der Nacht von Dienstag auf Mittwoch gelöscht.
• Wenn der ALNV-Eintrag erst nach dieser Zeit bearbeitet wird, lässt sich der Hinweis bei Bedarf in der Versionsgeschichte des Normdatensatzes nachsehen. In der Regel sollte er (erstmals) in der Version vom Tag vor dem Datum des ALNV-Eintrags zu finden sein.

---

Folgende 2 Report Types noch unter Beobachtung:

5. GND - Zu löschender Datensatz

Löschungen sind in der GND sehr selten, meistens wird gemergt. Soll ein GND-Eintrag wirklich gelöscht werden, so erfolgt die Löschankündigung eine Woche im Vorhinein. In der verbleibenden Woche befindet sich der DS noch im Alma-GND-Spiegel und es gibt die Möglichkeit, entweder auf einen korrekten GND-Datensatz "umzuverlinken" oder gegebenenfalls andere nötige Schritte zu setzen.

Beispiel:

Falsch:	689 ##	$$a !!!GESPERRT!!!Ekklesia $$0 (DE-588)4151661-8 $$4 ctb
Richtig:

---

6. Normdatensatz gelöscht – Verknüpfung des BIB-Indexeintrags gelöscht

Wurde die Löschankündigung (--> siehe vorigen Punkt!) nicht rechtzeitig bearbeitet, zeigt die Verlinkung in den Titeldaten ins Leere. In Folge muss man sich selbstständig aufgrund des Eintrages im Titeldatensatz einen Reim auf den Fall machen und die weiteren nötigen Schritte setzen.

Beispiel:

VORHER: Person ist trotz $$0 unverlinkt!	100 1#	$$a Jones, James M. $$0 (DE-588)4151661-8 $$4 aut
NACHHER: Im konkreten Fall konnte mit einer vorhandenen Neuansetzung neu verlinkt werden	100 1#	$$a Jones, James McCoy $$d 1941- $$0 (DE-588)140138145 $$4 aut