AW: [Allegro] Unterdrücken der Anzeige von Feld 39

Di Feb 26 16:02:30 CET 2008

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

Lieber Herr Eversberg, liebe Liste,

|> *Doppel*arbeit der Erfassung der angesetzten Form der (persoenlichen
|> oder koerperschaftlichen) Urheber sowie der Vorlageform nimmt einem
|> strenggenommen niemand ab:
|>
|> In der Situation ohne Koerperschaften gibt es oft verbalen Ballast
|> in der Verfasserangabe, der transkribiert werden muss (und sei es
|> nur ein simples "von" zwischen " / " und "Peter Mueller", dass es
|> eher einfach ist, #39 staendig zu erfassen, als die wenigen Faelle
|> zu bemerken, wo die Vorlageform der Verfasserangabe zufaellig durch
|> die Software "errechnet" werden kann. Soweit zur strengen Lehre. In
|> der Praxis halte ich es fuer legitim (und so machen es die meisten)
|> nur in den wenigen Situationen #39 zu erfassen, wo Transkription der
|> Vorlage zur Erhellung der besonderen Umstaende beitraegt.
|>
| Genau das führte seinerzeit beim NMN zur Schaffung der #39 und ihrer
| besonderen Funktionsweise.

naja, in MAB ist es 359 mit einem klitzekleinen Hinweis auf eine
moegliche Abkuerzung(?):
"Stimmt die vorliegende Namensform des 1. Verfassers mit der
Ansetzungsform ... ueberein, so kann fakultativ das Teilfeldtrennzeichen
nach dem Namen des 1. Verfassers gesetzt werden."

(mir ist nicht ganz klar, wofuer das nuetzlich sein koennte, in
der freien Wildbahn habe ich das auch noch nie gesehen).

| Das A-Format hat, die NMN-Denkweise fortführend, schon die Ansetzungs-
| form höher bewertet als die Vorlageform. Im RAK-Denken und in MAB ist
| die Ansetzungform eine Zutat, die man wo notwendig beifügt, im
| konsolidierten A-Format-Denken ist es aber die Vorlageform, die im
| Bedarfsfall beigefügt wird, bei Identität mit der Ansetzung jedoch
| nicht. Ein Vorteil ist, daß eben #20 stets die Form ist, die ins
| Titelregister muß und die zum Sortieren von Listen heranzuziehen ist,
| d.h. bei solchen wichtigen Tätigkeiten ist keine Fallunterscheidung
| nötig.

Nun, "Identifikation" ist eine Taetigkeit, die an zwei Stellen
durchgefuehrt wird: Beim Katalogisieren werden vorhandene Urheber,
Werke, Ausgaben etc. identifiziert, als Folge wird durch die
Katalogisierer "angesigelt" bzw. Teile werden "angesetzt" (bzw.
mit bereits vorgefundenen Ansetzungen "verknuepft").

| Ganz entscheidend also: Retrieval (Auffindbarkeit, Navigieren, Zusammen-
| führen) wird heute als wichtiger angesehen als die Beschreibung oder
| Darstellung eines Satzes an der Oberfläche (also Anzeige oder Druck).

Jedoch, ist (moeglicherweise sogar nur) ~ein~ Katalogisat vom Benutzer
gefunden, so muss sie/er verifizieren, dass es auch wirklich ~das~
gewuenschte ist (oder etwas vergleichbares), d.h. seine vorhandenen
Informationen oder auch nur Vorstellungen mit dem gefundenen
identifizieren (oder umgekehrt). Und hier kommt die moeglichst reiche
Transkription der Vorlage zum tragen (sowie der Zoo bibliographischer
Fussnoten zur Verfasserangabe, Titelangabe, Ausgabebezeichnung, und
moeglichst noch die verweisenden Fussnoten auf andere Ausgaben, falsche
Zuschreibungen etc.: Das dient der Abgrenzung oder dem Aufzeigen
aehnlichen Materials und nicht zuletzt als Bruecke in Situationen,
wo ein Benutzer mit einem falschen Zitat dank Ansetzungen das richtige
gefunden hat; zu entscheiden, ob bestehende Unterschiede in einer
konkreten Recherchesituation belanglos oder extrem wichtig sind,
muss aber stets dem Benutzer ueberlassen bleiben).

Je nach Background der Benutzer sollte die Transkription der
Vorlage vielleicht nicht transliteriert, sondern sogar
originalschriftlich sein, oder keine Transkription, sondern ein Scan.
Aber eben nicht nur, denn selbst geuebte Benutzer wollen nicht
unbedingt immer ein vorlagegetreues Chronogramm aufloesen sondern
sind ganz dankbar fuer eine bereits im Katalogsiat verankerte
numerische Erscheinungsangabe...

| Die ISBD, das klassische Grundmodell einer Titelanzeige, wird ja
| nun auch bei Web-Katalogen (und andere wird ein Nutzer zunehmend
| gar nicht mehr kennenlernen) kaum noch umgesetzt, d.h. große
| Teile der ehemals so wichtig genommenen Beschreibungsregeln sind
| damit nutzlos. Für die FRBR-Kernaufgaben des Identifizierens und
| Auswählens zwischen mehreren "Ressourcen" behalten Vorlageformen
| dennoch eine gewisse Wichtigkeit, nicht jedoch ihre Anordnung und
| Interpunktion in einem Display.

Nun, ISBD-Darstellungen sind eigentlich hervorragend strukturierte,
lesbare ~Texte~. Liest man sie als solche, geht es ganz zwanglos
vom Werk zur Ausgabe und weiter evtl. zum Exemplar. Und anschliessend
folgt der Apparat zur Aufnahme mit Fussnoten in analoger Reihenfolge.
Zum Schluss dann modernes Abakadabra mit Identifikationsnummern,
Preisen, Hyperlinks etc.

Habe ich so eine Darstellung nicht, dann muss ich in einem
tabellarischen Display entweder jedes einzelne Datenfeld individuell
labeln (und bekomme eine Monstertabelle mit oft laengeren Labeln
als die hinterlegten Inhalte, wobei ausserdem der Benutzer den
Inhalt "faelschlich als 1. Auflage bezeichnet" u.U. wesentlich besser
versteht als das Label) oder muss mir Gedanken machen, wie ich
verschiedene Datenfelder fuers Display zusammenfassen kann: kein
Problem, geeignete Delimiter zu finden, aber ein bereits bekanntes
Problem, eine guenstige Reihenfolge zu finden...

| Solches Denken kennt MARC bis heute nicht, sondern MARC bildet
| im Gegenteil noch immer genau die Reihenfolge incl. Interpunktion (!)
| der Titelaufnahme ab, wie sie auf dem gedruckten Katalogzettel erschei-
| nen soll(te). Dies nun mit dem FRBR/RDA-Denkmodell zu verschwistern
| kann nicht zu einer leicht verständlichen Metadatenstruktur führen,
| d.h. das Katalogisieren, das ja ein Ausfüllen von Formularen ist, die
| mit dem Format direkt zusammenhängen, KANN nicht einfacher werden als
| zuvor. MARC mit seiner engen Bindung an eine ganz bestimmte
| Darstellungsform ist aus Sicht des modernen Datenbankparadigmas ein
| grauenvoller Anachronismus, denn man strebt ja heute eine völlige
| Unabhängigkeit von Datenstruktur und -Darstellung an. Dies hat allegro

Nun, ich halte auch Datenbankparadigmen u.U. fuer anachronistisch...
In den Regelwerken sind es ja gar nicht soo viele Konzepte oder
Beschreibungskategorien, der (mal unterstellte) Anachronismus beginnt
da, wo jede Einzelaussage in ein eigenes (Teil-, Unter-, Wiederhol-,...)
Datenfeld gesetzt werden muss und jede kleine Bedeutungsnuance die
Definition eines gleichberechtigten neuen Datenfelds erfordert.

Katalogisieren ist als analytische Taetigkeit das Aufbrechen eines
vorgefundenen Puzzles und Einordnen der Teile in verschiedene
Schubladen. Eine Benutzeroberflaeche (oder ein an dieser Oberflaeche
sichtbares Datenformat), die das stupide nachbaut (womoeglich mit
der zusaetzlichen Schwierigkeit, das Puzzle genau in der Reihenfolge
der Schubladen auseinanderzunehmen, und/oder alles mithilfe einer
komplizierten Spiegelkonstruktion einusortieren) ist zwar schoen
barock, aber eigentlich auch recht phantasielos.

Man koennte sich eigentlich auch ein Benutzerinterface vorstellen,
wo der Katalogisierer mit der Maus Bereiche auf einem Titelblatt-
Scan markiert (OCR laeuft dann im Hintergrund ab), mit der rechten
Maustaste nur festlegt, *was* das markierte ist (und wenn es
eine Person etc. ist, wird *anschliessend* sofort eine Recherche
nach geeigneten Stammsaeztzen ausgeloest) und die Software
hinterlegt die OCR-Ergebnisse mit (u.U. tief geschachteltem)
"Markup": Damit koennte man z.B. furchtbar komplexe und abgekuerzte
Verfasserangaben in Vorlageform einerseits furchtbar schnell und
andererseits unglaublich differenziert strukturieren um dann im
Display wunderbar spezifische Hyperlinks anbieten zu koennen.

Ein Katalogisat saehe dann (tief unten in der Maschine) allerdings eher
wie eine TEI-codierte Inkunabel aus, Personenindizes und was man
sonst so fuers Retrieval benoetigt, waeren aber mindestens ebensogut
wie mit den heutigen Mammut-Formaten generierbar. Fuer ISBD-artige
Displays sehe ich keine grosse Schwierigkeit, nur dass u.u. die
Reihenfolge der dargestellten Information im Zweifelsfall tendenziell
der konkreten Vorlage entspricht (waehrend sie bei RAK und ISBD m.E.
derjenigen einer stark idealisierten Vorlage entsprechen will)

| mit seinem exzessiven Parametriersystem seit je ermöglicht wenn auch
| mit dem konsolidierten Format noch nicht voll konsequent umgesetzt.

| Ungut am A-Format ist, daß #20 eine Sonderrolle hat gegenüber anderen
| Titeln (Neben-, Parallel-, Gesamttitel). Für deren Vorlageform gibt es
| keine eigene Kategorie. Der Kern des Unguten ist die Tatsache, daß
| #19 und #20 getrennte Felder sind, aber in ihrer Bedeutung
| zusammengehören. Dieses Dilemma wurde beim Neutralformat überwunden:
|    http://www.allegro-c.de/doku/neutral/
| Hier gibt es zu jedem Titelfeld die Möglichkeit, eine Vorlageform ins
| Unterfeld $Y einzugeben, wobei $Y für ALLE Felder, nicht nur Titel,
| nutzbar ist.

Erinnert mich ein bisschen an die "Linkage" in MARC 21 bzw. die
Totgeburt MAB 671 (da geht es um hauptsaechlich um Originalschrift,
nicht um Vorlageformen, jedenfalls aber sind das Mechanismen, um
kompliziert aber frei ganze Felder in Konkordanz zu setzen)

| #39 und #18 sind anders zu sehen als die #19: sie gehören zum ganzen
| Datensatz (heutige Denkweise: zur "Manifestation"), nicht zu bestimmten
| Datenfelder. Daher müssen sie eigene Datenfelder sein, im N-Format gibt
| es dafür die #185 bzw #850. Noch besser wäre für die #39 vielleicht die
| #852 statt #185 im Block "Inhaltsbeschreibung", das ist nochmal
| zu überlegen. Man sollte womöglich diesen Block dann "Beschreibende
| Angaben" nennen, wenn man nicht "Manifestation" als Neologismus
| reinbringen will.

#18 hat eigentlich nirgendwo eine Entsprechung (ausser im N-Format),
das macht sie wenig nuetzlich.

"Beschreibung" ist doppeldeutig, einen Aspekt habe ich oben
"Transkription" genannt, den anderen "Apparat" (Aussagen ueber).
Will man das zusammenwerfen, faengt man sich [K[l[a[mmer]ge]bir]ge]
ein.

...

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

iQCVAwUBR8QqBmITJZieluOzAQL0CgQAhsFS6Pw/96y3txB2w9JGcbG0uCpx1By9
MRxhb9S5vNsL5kZ0apAc4nxxeGLUyc4t0T4b9oYOhTSfnxjdftUBulfqVG+xWsng
BYH+BnPXjCX4rzWATJyXrunepRs4lcezsIa2LGdNGr29dddcuSFi6QZlRvgR/g5i
a8jRkPsSeyI=
=0q5E
-----END PGP SIGNATURE-----