Problem Dublettenkontrolle

[Thomas Berger]

Allers,Heinrich wrote:
> 
> Monika Steffens (steffens at uni-oldenburg.de) schnitt
> heute das ewige und doch immer wieder aktuelle Thema
> der Dublettenkontrolle an:
> 
> > ...
> > "Fuer den Regionalkatalog Elbe-Weser sollen auf Basis von allegro-C
> > die Katalogdateien mehrerer Bibliotheken zusammengespielt werden,
> > ....  die ISBN fuer die Dublettenkontrolle als
> > Pruefschluessel nicht geeignet; die Datenmenge ist andererseits aber
> > zu gross, als dass man Dubletten per Hand bearbeiten koennte
> > (insgesamt 10 Bibliotheken mit zusammen ca. 40.000 Titeln).
> >
> > Frage: Wer hat Erfahrungen mit dieser Problemstellung und kann mir
> > sagen, wie man bei der Erstellung dieses Pruefschluessels am besten
> > vorgeht?"

Herrn Allers' Meinung moechte ich mich vollkommen anschliessen.

Die Problematik der Untersaetze, insbesondere der hierarchischen,
sollte nicht unterschaetzt werden. Technisch wird man vermutlich
in einem separaten Schritt vor der Dublettenkontrolle die 
hierarchischen erst einmal zu verknuepften umbasteln muessen
und diese dann nach Zusammenfuehrung von Dubletten evtl. wieder
zu hierarchischen zusammensaetzen. (Schliesslich koennte eine
Hauptaufnahme, die "verworfen" wird, eine Bandauffuehrung haben,
die die andere, "gueltige" nicht hat). Im Fall der verknuepften
Bandauffuehrungen braucht man aber einen zusaetzlichen Mechanismus
zum Erkennen dubletter Baende (eine Art Umlenkung).

Wird mit Stammsaetzen gearbeitet und oder liegen unselbstaendige
Werke vor, werden diese Umlenkungsaspekte natuerlich noch wichtiger.

Ueberhaupt sollte man zwei Szenarien unterscheiden:

1.) Alle Datenbanken arbeiten ohne Identnummern und Kuerzel (d.h. 
insbesondere nur hierarchische Untersaetze, keine unselbstaendigen
Werke, keine Personen-Koerperschaftsstammsaetze etc.)

Dann hat man tatsaechlich nur das Problem des Dublettenerkennens
und der effizienten Vernichtung von Dubletten. Als Spezialproblem
bei der Vernichtung der Dubletten ergibt sich dann nur das
Problem der vielleicht-doch-nicht-Vernichtung von Bandauffuehrungen.

2.) Es gibt Verknuepfungen:
Dann muessen schon beim Zusammenmischen _alle_ Identnummern
umgesetzt werden (damit keine doppelten entstehen, etwa
Identnummer 1234 in Datenbank 1 ist Titel A, in Datenbank 2 ist es
aber Titel B, das waere fatal fuer die Baende und unselbstaendige!)
und beim Vernichten von Dubletten muss Aufwand getrieben werden,
damit mit zu vernichtenden Aufnahmen verknuepfte Datensaetze auf 
die uebrigbleibenden umgehaengt bzw. umgelenkt werden.

2a.) Die ganzen Probleme bei 2.) gibt es nicht, wenn alle sowieso
mit ueberregionalen Identnummern gearbeitet haben, d.h. Personen
und Koerperschaften sind ueber die PND-, SWD-, und GKD-Nummern
verknuepft, Titel mit den DB-Nummern etc. (Schoener Nebeneffekt:
man hat auch keine Muehe mit der Dublettenerkennung :-). So
funktionieren im Endeffekt ja auch die Lokalsysteme innerhalb
von Bibliotheken in Verbuenden.

Praktikabel koennte sein, aus Zustand 2. mit Gewalt Zustand 1.
zu erzeugen, d.h. jede einzelne Datenbank so vorverarbeiten,
dass Identnummern mehr notwendig sind: 
- Keine unselbstaendigen 
- Alle Personen- und Koerperschaftsverknuepfungen aufloesen
- verknuepfte Bandauffuehrungen zu hierarchischen machen

Dann alle Teildatenbanken mit Update in die grosse Datenbank
mischen (dabei Identnummern vergeben lassen, die nur fuer
diese Generierung Bedeutung haben) und dabei schon moegliche
Dubletten aussen vor lassen (die Heuristik mit den Akronymen
sollte also u.U. etwas differenzierter sein)

Von den weggelassenen Saetzen einzelne Bandauffuehrungen doch 
noch in die Gesamtdatenbank schicken (als verknuepfte) und
dann entweder alle verknuepften in die hierarchischen einarbeiten
oder umgekehrt.

Dies ist ein Weg, der viel Rechenzeit, aber garkeine manuelle
Intervention erfordert.

Grundsaetzlich ware zu sagen, dass man die Wahl hat zwischen
groben Dublettenerkennungen (die evtl. eine Dublette erkennen,
wo zwei Titel doch verschieden sind) und feinen, die u.U.
Dubletten nicht erkennen, obwohl sie durch einen Bearbeiter
intellektuell als solche noch erkannt wuerden. Erstere eignen
sich dafuer, dass in einem bereits vorhandenen Pool der
Bearbeiter sich dann die indexierten Akronyme (Matchkeys)
mit einer Haeufigkeit von mehr als eins (=Dublettenverdacht)
anschaut und dann fallweise entscheidet, was zu loeschen ist,
eignen sich also gut in Faellen, wo (etwa wegen unterschiedlicher
Qualitaet der Daten) eine Bearbeiterkontrolle sowieso angebracht
ist. Die zweite Sorte eignet sich wie im oben skizzierten 
Ablauf dafuer, dass man Dubletten prinzipiell inkauf nimmt 
(zumindest eher als Massen faelschlicherweise weggelassener
Titel), dafuer aber tendenziell ohne manuelle Nachbearbeitung 
auskommt.

Viele Gruesse
Thomas Berger