[Allegro] Fortbildung: Thema "Codes"

[Thomas Berger]

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

Lieber Herr Eversberg, liebe Liste,

Warum keine Codes?

1.1. Kürze: Jedesmal "Elektronische Ressource" zu speichern macht Sinn -
23 Zeichen, die sich selbst erklaeren! Ansonsten muss man zu den Daten
noch umfangreiche Listen liefern, damit sie korrekt interpretierbar
sind, diese existieren unguenstigstenfalls nur auf Schmierzetteln,
in guenstigeren Faellen (View-Listen, Word-Dokumente) in nicht ohne noch
weitergehende Zusatzinformation interpretierbaren Computerdateien.

1.2. Hat man aus Versehen "Elektronsiche" geschrieben, ist das vom
menschlichen Leser immer noch korrekt interpretierbar, hat man den Code
x statt u geschrieben und x hat eine andere Bedeutung als u, ist das
nicht der Fall!

1.3. Sprachunabhängigkeit: In mehrsprachigen Umgebungen ist es von
Vorteil, wenn man bestimmte Aussagen nicht codiert hat, weil man
"elektronische Resource" und aehnliche Phrasen unabhaengig vom Kontext
uebersetzen kann, einzelne Zeichen aber nur dort (und wo ist das?),
wo sie einen ganz bestimmten Code repraesentieren

1.4. Änderungskomfort: Wenn es nicht mehr "Elektronische Ressource"
heißen soll, sondern z.B. "E-Dokument": Der Text in den Datensaetzen
kann einfach global ersetzt werden, es ist nicht erforderlich, die
Anwendung an den richtigen Stellen (welche sind diese? typischerweise
wird eine uebersehen, gerade bei Allegro ist es nicht ohne weiteres
moeglich, die benoetigtet Konkordanz nur an einer Stelle zu hinterlegen
und alles andere ist toedlich!) umzuprogrammieren.

1.5  Effizienz: Ein vergebener Code insinuiert staerker als eine
Verbalaussage, dass die Vergabe anderer Codes ausgeschlossen ist und
er als "sekundärer Suchaspekt" zur Eingrenzung von Ergebnismengen dienen
koennte, in "allegro" auch "Restriktion" genannt. In der Praxis gibt
es aber bei jedem Codesystem (etwa Geocodes, Formcodes) fast sofort
den Bedarf, manche Dokumente mit mehreren Codes zu versehen, so
dass wie bei der verbalen Belegung Trennzeichen definiert werden
muessen und der Einsatz von Restriktionen nicht mehr ohne weiteres
moeglich ist.


Fazit: Vokabularkontrolle ist gut (in gewisse Felder duerfen nur
Eintraege aus vorab bereitgestellten Listen eingetragen werden),
Codes als kontextabhaengige Phrasen (Eintrag von "el" im Feld fuer
die allgemeine Materialbenennung liefert mir den heutigen Text
fuer "Elektronische Resource", den ich kontrolliere, denn vielleicht
hatte ich ja ErgaenzungsLieferung im Kopf gehabt) waeren ein nuetzliches
Konzept, das Speichern von Codes in Datensaetzen hingegen ist nach
Moeglichkeit zu vermeiden, ausser es handelt sich um aeusserst
weit verbreitete Listen mit entsprechender Infrastruktur (ISO-Sprach-
und Laendercodes fallen mir da ein, wobei es aber auch hier von
schlecht dokumentierten Privatverabredungen des Dt. Bibliothekwesens
wimmelt). Oder es handelt sich (Klassifikation anhand des lokalen
Signaturensystems) um Codes, mit denen auch ausserhalb der
Kataloganwendung (etwa am Regal) operiert wird.

viele Gruesse
Thomas Berger




Bernhard Eversberg wrote:
> 
> Im Verlauf der Ausgestaltung des N-Formats haben wir uns auch mit dem
> Thema "Codes" mal wieder befaßt. Welche Codes soll man, könnte
> man, müßte man in welchen Datenfeldern einsetzen? Da gehts ja in den
> verschiedenen Systemen ganz schön durcheinander...
> Hier ist eine Lektion, die sich daraus ergeben hat:
> 
>    http://www.allegro-c.de/doku/neutral/whycodes.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFEUezyhKFJT0F1FsoRAnO5AJURSctgpKRaftoHZy3LExNqpQ8vAJsFl/WY
1fiec2zXYTQF9NqwvGzMLQ==
=/NW7
-----END PGP SIGNATURE-----