Aufgabenliste Normdatenverwaltung (ALNV)

Allgemeines

Die Aufgabenliste Normdaten-Verwaltung (kurz: ALNV) ist ein permanentes(!) 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 Alma-Jobs (beispielsweise "Preferred term correction") 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"; dies zeigt Ihnen die AC-Datensätze auf Verbundebene, die mit Ihrer Institution verknüpft sind.
  • Wenn in Ihren rein lokalen Datensätzen (IZ-Ebene!) GND-Verlinkungen vorhanden sind, die auch korrigiert werden sollen, machen Sie gegebenenfalls einen 2. Durchgang, indem Sie auf "Verknüpft mit: Nicht verknüpft" einschränken.
• 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.

Bitte beachten:

• Der möglich Datenbereich, der mit einer Suche durchsucht werden kann, beträgt immer maximal 1 Monat!
• 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 $$1 https://orcid.org/0000-0003-1380-8415

Anmerkung:
In solchen Fällen überprüfen, ob eine GND-Verlinkung möglich ist.
Aber Achtung: Bei Verwendung von $$0 für die ORCID würde beim Verlinken mit der GND über F3 die ORCID in $$0 entfernt und mit der GND-Nummer überschrieben werden.
Die ORCID sollte daher vor eine GND-Suche in $$1 in Form einer URL eingetragen werden. Wird in Folge über F3 mit der GND verlinkt, bleibt die ORCID in $$1 bestehen. Ist die ORCID im GND-Datensatz bereits vorhanden oder wird sie nachgetragen, dann sollte das $$1 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.

Anmerkung:
Irrtümlich wurde das Gebäude, in dem eine Ausstellung stattfand, als Körperschaft angesetzt. Daher wurde der Datensatz nachträglich wieder aus der GND gelöscht.

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.

---

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. Gelöscht werden beispielsweise GND-Datensätze die gemäß RDA eigentlich keine Entitäten darstellen (Einzelausstellungen etc.), die als Datensätze des falschen Satztyps angelegt wurden (oftmals "Altlasten" aus Vor-GND-Zeiten) oder solche die nicht (mehr) in das Begriffsnetz der GND passen. Zu löschende GND-Datensätze tragen einerseits in Feld 682 eine Löschmarkierung und werden andererseits (zumeist) mit "!!!GESPERRT!!!" als Präfix des bevorzugten Namens bzw. der bevorzugten Benennung versehen.

Beispiel:

VORHER:	111 2#	$$a !!!GESPERRT!!!Ausstellung zum Wettbewerb für Handwerk und Design $$n 9. $$d 2021 $$c Online $$0 (DE-588)1236598504
NACHHER: Es handelt sich um eine Einzelausstellung, welche gemäß RDA-DACH in der FE nicht als GND-Entität erfasst wird.		In diesem Fall wird das Feld 111 einfach gelöscht.

VORHER:	689 00	$$a !!!GESPERRT!!!Fünf Zivilisierte Nationen$$D g $$0 (DE-588)4236963-0
NACHHER: Es wurde entschieden, dass der Datensatz gelöscht wird und stattdessen die spezifischen Datensätze für die betroffenen Nationen zu verwenden sind.	689 00 689 01 689 02 689 03 689 04	$$a Cherokee $$D s $$0 (DE-588)4069949-3 $$a Chickasaw $$D s $$0 (DE-588)4353201-9 $$a Choctaw $$D s $$0 (DE-588)4085262-3 $$a Creek $$D s $$0 (DE-588)1036621200 $$a Seminolen $$D s $$0 (DE-588)4306669-0

VORHER:	710 2#	$$a !!!GESPERRT!!!Flores & Santana $$0 (DE-588)1330966384
NACHHER: Es handelte sich um einen Körperschaftsdatensatz für ein Künstlerkollektiv. Im Nachhinein hat sich herausgestellt, dass es sich nicht um eine Gruppe sondern um zwei Individuelle Künster*innen handelte. Eine Umlenkung zwischen den involvierten Satztypen ist nicht möglich, weshalb der Körperschaftsdatensatz gelöscht und zwei Personendatensätze angelegt wurden.	700 0# 700 0#	$$a Flores $$0 (DE-588)137709829X $$a Santana $$0 (DE-588)1377099415

---

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! Im Nachhinein lässt sich dies nicht mehr eruieren, aber vermutlich wurde der ursprünglich verlinkte GND-Datensatz gelöscht, weil es sich um einen mit sehr niedrigem GND-Level gehandelt hat. Dieser Datensatz hätte demnach eigentlich gar nicht in den OBV-Titeldaten verlinkt werden sollen. Die Markierung von zu löschenden GND-Datensätzen mit "!!!GESPERRT!!!" ist erst seit kurzem verpflichtend.	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

Anmerkung:

• Aufgrund eines Fehlers in der Umsetzung von Ex Libris finden sich in diesem Report Type mitunter auch bei Filterung auf "Verknüpft mit: Netzwerkzone" Eintragungen, die in der Spalte "Ursprung" ein IZ-Symbol () tragen, ggf. sind diese Eintragungen auch "Dubletten" von gleichlautenden Eintragungen mit dem NZ-Symbol ().
  • Diese Zeilen sollten genau so behandelt werden, wie jene mit dem korrekten Ursprungs-Symbol.
  • Manchmal wurde die in diesen Fällen nötige Korrektur auch bereits vorgenommen, der Eintrag findet sich aber immer noch in der ALNV. In diesen Fällen können Sie - nach Überprüfung des Sachverhaltes - den Listeneintrag einfach "entfernen".
• Darüber hinaus kann es, ebenfalls aufgrund eines Implementierungsfehlers, in diesem Report Type auch vorkommen, dass Eintragungen vorhanden sind, denen gar keine Löschung, sondern eine Umlenkung zugrundeliegt und der Heading demnach bereits mit dem Sieger-Datensatz der Zusammenführung verlinkt ist.
  • Bestätigen lässt sich dies ggf. durch eine Überprüfung, ob die genannte MMS auch im Report Type "Verknüpfung - der Link zum BIB-Indexeintrag wurde aufgrund er Umlenkung des Normdatensatzes geändert" vorkommt.
  • Letztlich ist dies aber nicht nötig. Wenn ein korrekter Link vorhanden ist, können Sie die Eintragung ebenfalls einfach aus der "ALNV entfernen.