[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Thomas Berger]

Liebe Frau Koczian, liebe Liste,

> Am 03.07.2013 12:23, schrieb Bernhard Eversberg:
>> Am 02.07.2013 16:55, schrieb Sibylle Koczian:
>>> Ich bin verwirrt. Ist denn nicht das von H. Berger als nützlich in die
>>> Debatte geworfene Konstrukt "nächstes Mehrfachfeld"
>>
>> Wozu eigentlich wäre das nützlich?
>>
> 
> Um genau das einfacher zu tun, was sich jetzt mittels Trick 46 machen lässt:
> iterieren durch Mehrfachfelder. Das kann schließlich schon bei vier oder fünf
> Mehrfachfeldern zu einer Kategorie gebraucht werden, nicht erst in Extremfällen.
> Also längst bevor man mit den Wiederholungszeichen in Schwierigkeiten kommt.
> Aber tatsächlich eher dann, wenn es echte Mehrfachfelder mit gleicher Bedeutung
> sind.

Nett, und unten drunter auch eine Variante von Heinrich Allers,
die das Gesammelte in die iV schreibt, das war ja auch mein
alternativer Ansatz mit dem "Filter-Kommando" anstelle der
Iteration. Was nuetzlicher sein koennte, ist schwierig zu
beurteilen: /Eine/ Schleife wird man in jedem Fall benoetigen,
und ob man nur Einzeloperationen (wie etwa Loeschungen)
durchfuehrt oder das gesammelte als Gesamtheit untersuchen
kann, ist vorher nicht klar.

Apropos Loeschungen: Hier benoetigt man mehr als eine Schleife:
Waehrend ich mittels des Iterators (derzeit also der Cstring k_2,
spaeter vielleicht etwas anderes) durch aktuelle Kategorien
des Datensatzes haspele, kann ich die nicht gleichzeitig
durch Loeschungen oder Ergaenzungen stoeren: Das bringt
Erfahrungsgemaess den Interator zum Entgleisen (mit Kenntnis
der Implementierungsdetails koennte man allerdings versuchen,
ob man /rueckwaerts/ dann doch zum Ziel kommt...).

In der Praxis also sammele ich erst mit k_1 und einer Schleife
mit k_2 die fraglichen Kaegorienummern in einer ($-)Variablen, die
ich dann in einer weiteren Schleife sukzessive aufesse und
als Kategorieloeschungen abarbeite...


> Beispiel: eine Kategorie tritt jetzt sechsmal auf, ich will das alles löschen
> und durch vier Exemplare mit neuem Inhalt ersetzen. Kommt bei mir ziemlich
> regelmäßig vor (natürlich nicht immer von sechs auf vier).

Das moechte ich unterstreichen: Es gibt immer mehr Importe, die
mit Anreicherungen zu tun haben: Entweder ich habe ein Importat
im Laufe der Zeit angereichert und will, dass das bei einem
Reimport nicht zerstoert wird. Oder mein Katalogisat ist irgendwann
irgendwohin exportiert worden, eine andere Anwendung hat das
"bibliographisch" evtl. nivelliert, aber mit Mehrwert versehen
(etwa URN-Vergabe) und ich will das gezielt Reimportieren.
In beiden Faellen komme ich mit den klassischen Update-Modi
(Datensatz oder jedes Feld, austauschen oder schueztzen) oft
nicht zum Ziel, sondern muss Gruppen von Feldern als jeweils
eine Einheit betrachten, die als ganzes ausgetauscht wird oder
erhalten bleiben soll.

Solche Szenarien sind einer der Gruende, warum das "Record"-Konzept
der Bibliotheksdaten an Grenzen gestossen ist: Ich habe nicht
mehr den perfekten Datensatz, den ich jahrzehntelang nicht mehr
anfassen brauche. Ich habe auch nicht den einmalig importierten
Datensatz, an dem ich jahrzehntelang verbessernd herumschraube.
Es gibt aber auch nicht den Super-Datensatz, den ich regelmaessig
neu importiere um immer die bestmoegliche Beschreibung zu haben.
Sondern es gibt Quellen, aus denen ich meine Datensaetze anreichern
kann. Und moeglicherwiese habe ich mehrere Quellen zur Auswahl,
die mir denselben Aspekt meiner Daten anreichern koennen. Bzw.
nach einiger Zeit wird mir eine bestimmte Quelle eine bessere
Anreicherung als beim letzten Mal liefern koennen (manche Daten
veralten ja auch recht schnell), wobei dann auch Dinge entfallen
sein koennten: Ich bekomme das mit selektivem Verarbeiten von
Feldern nur umstaendlich in den Griff, angemessener waere eine
Vielzahl mit der "Hauptdarstellung" verknuepfter Mini-"Records",
die im Extremfall nur eine einzelne Zusatzinformation tragen.
Aber dann auch Metainformation, also eigene Identifier und
Angaben zur "Provenance" (genau wie "file" und "record" eine
Metapher aus der Aktenerwaltung bzw. dem Archiv), damit ich
effektiv und gezielt alle Anreicherung aus einer Quelle durch
den aktuellen Stand austauschen kann. Nach meinem Verstaendnis
ist das genau die Stossrichtung der Bibframe-Entwicklung.

viele Gruesse
Thomas Berger