[Allegro] Typisierung von Datensätzen

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Im Zusammenhang mit den Überlegungen zur
> Zeitschriftenheftzugangsverwaltung wird hier wieder mal erwogen, ob
> wir nicht einen Code bräuchten, der etwas über die Art des Datensatzes
> aussagt.

Hm. Erfahrungsgemaess gibt es nichts, was es nicht gibt. Die "Art"
des Datensatzes ist bei naeherer Betrachtung oft nicht klar, bzw.
jedenfalls nicht eindeutig:


> Das ist ein schwieriges Problem und in den verschiedensten Systemen
> auf unterschiedlichste Weise gelöst, oft nicht mit einem, sondern mit
> mehreren Codes, deren Bedeutungen dann teilweise unklar, uneindeutig
> oder nicht leicht verständlich sind und die u.U. auch in der Anwendung
> uneinheitlich und inkonsequent sind und untereinander nicht kompatibel.
> Im allegro-A-System haben wir solche Codes weitgehend vermieden und
> vielmehr darauf gesetzt, daß Art oder Zweck des Datensatzes aus dem
> Vorhanden- oder Nichtvorhandensein von Feldern oder Teilfeldern
> hervorgeht.

- - Personenstaemmsaetze tragen hinweise auf archivierte Kleinschriften
  (mit Signatur der Mappe im Magazin)
- - Personenstammsaetze sind auch Schlagwortsaetze
- - Ist ein als Monographie aufgestellter Sonderdruck "nur"
  unselbstaendig?
- - Sobald Stuecktitel katalogisiert sind, verschwimmt der Unterschied
  zwischen "Zeitschrift" und "zeitschriftenartiger Reihe"
- - Sobald Stuecktitel der Zeitschrift katalogisiert sind, ist ein
  Aufsatz daraus simultan ein Zeitschriftenaufsatz und einer im
  Stueck als Sammelwerk
- - Katalogisate von Print-Werken dienen oft als billiger Stellvertreter
  fuer eine parallele Online-Publikation (denn strenggenommen ist
  ja die elektronische Variante eines Aufsatzes in einer ganz anderen
  Zeitschrift als die Print-Variante erschienen...)
- - Aehnliches gilt fuer Sekundaerformen
- - Die alte Diskussion um Formcodes vs. Formschlagworte hat gezeigt,
  dass viele sinnvolle Typisierungen simultan vorkommen koennen,
  auch MAB sieht trotz unendlich vieler Einzelfelder fuer Codes
  manche auch noch als wiederholbar vor.

Mir scheint das Abheben auf den "Zweck" des Datensatzes eine
interessante Alternative zur "Art" (die ja gerne nicht als
"Art des Datensatzes" verstanden wird sondern als eine quasi
universelle und intrinsische "Art des abgebildeten Objekts").

Wenn ich also anhand von gewissen Schluesselkategorien erkenne,
dass sich eine Benutzung des Datensatzes als unselbstaendiges
aus einem Sammelband anbietet, ist das prima und ich kann
unterstellen, dass diese Nutzung "bezweckt" ist. Ist der Zweck
noch irgendwo hinterlegt, kann ich ggfls. einen Konsistenztest
durchfuehren, der mir sagen kann, ob eine wichtige Kategorie
fehlt. Zwecke abschliessend und umfassend festzulegen, halte ich
fuer bedenklich viel Arbeit, dann koennten mir die Konsistenztests
aber sogar sagen, dass eine Kategorie ueberfluessig ist...

Fuer Sonderdrucke etwa gibt es keine impliziten Kategorien, ihre
Behandlung hat oft auch mit der Makulationspolitik der speziellen
Bibliothek zu tun (nicht aufnehmen, falls Zs vorhanden. Immer
aufnehmen. Monographisch aufstellen. Aus Statistikgruenden ganz
anders behandeln), oft waere jeglicher Zusatzaufwand unangemessen
(etwa wenn ein einziges Schulbuch in den Bestand kommt)

In der Praxis habe ich oft eine Sammelkategorie fuer "Tokens",
das koennen einzelne Buchstaben oder normierte Worte sein, die
Reihenfolge ist egal, gegenseitiger Ausschluss ist bewusst nicht
vorgesehen.
Diese geben dann bei der Verarbeitung (und v.a. bei Statistik und
Konsistenztests) Hinweise darauf, was mit dem Satz (u.a.) gemeint ist
und wie er sich verarbeiten lassen sollte. Falls man in der
ungluecklichen Situation ist, gewisse MAB-Codes bedienen zu muessen,
kann so einen Mechanismus ebenfalls zuhilfe nehmen, wenn die Ermittlung
anhand von Schluesselkategorien einmal nicht ausreicht.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcR1mhKFJT0F1FsoRArImAJ94Ad0aWu+yjNCPVR4n2PmUGopq3ACfUV1I
fxseZkkrMddRCAUOuy4BS9s=
=knSb
-----END PGP SIGNATURE-----