allegro N-Format
Codes
- Warum? Wofür? Welche?
1. Warum Codes?
Grundsätzlich kann man
alles, was ein Code ausdrückt, auch mit Worten
sagen. Warum also überhaupt ein Code und nicht einfach alles verbal
speichern -
kann man doch wunderbar in einem ALL-Index dann alles abfragen? Fünf Gründe können einem einfallen, vielleicht noch mehr:
1.1. Kürze:
Jedesmal "Elektronische
Ressource" zu speichern wäre Unsinn - 23 Zeichen, wo eines reichen
könnte!
Dieser Aspekt ist gar nicht neu: schon die Verwendung von Jahreszahlen
statt
der verbalen Nennung von mit einem Zeitraum verknüpften Gegebenheiten
ist eine
Codierung! Die Römer sprachen und schrieben zur Zeit der Republik gern
von dem
"Jahr der Konsuln X und Y", aber das wurde irgendwann unpraktisch und
man ging zur Zählung der Jahre über, mit der Gründung der Stadt Rom als
Anfangspunkt.
1.2. Fehlervermeidung:
Immer langsam! Das
wäre nur dann ein Grund, wenn man tatsächlich jedesmal "Elektronische
Ressource" eintippen müßte, statt es aus einer Liste auszuwählen.
Allerdings: 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
codiert hat, weil man Codes leichter in unterschiedliche Wörter
umwandeln kann
als Wörter in andere Wörter
1.4. Änderungskomfort:
Wenn es nicht mehr
"Elektronische Ressource" heißen soll, sondern z.B.
"E-Dokument": Der Code dafür könnte unverändert stehenbleiben (u.U.
in zigtausend Datensätzen!), nur an den richtigen Stellen in gewissen
Skripten
und Programmen muß der Code durch den neuen Begriff ersetzt werden.
Gelegentlich ist es gar die "political correctness", die zur Änderung
von Begriffen zwingt, etwa Sprachbezeichnungen oder Ländernamen. Da ist
es dann
gut, wenn man solche Eigenschaften codiert statt im Klartext
gespeichert hat.
1.5
Effizienz:
Ein Code kann als "sekundärer Suchaspekt" zur Eingrenzung von
Ergebnismengen dienen, in "allegro" auch "Restriktion"
genannt. Restriktionen können erheblich schneller sein als verbale
Elemente,
besonders dann, wenn die Mengen der zu einem Code gehörigen Datensätze
sehr
groß sind - Ergebnismengen größer als 256000 Sätze sind in allegro
derzeit
nicht möglich, aber schon bei 50000 arbeitet die Suche nicht mehr
rasant
schnell!
2. Wofür Codes?
Auch Identnummern sind Codes, und wenn man Namen mittels Normdaten verwaltet, kann man in
bibliographischen Daten die Ansetzungsformen der Namen einsparen und
die
Normsatznummern statt dessen verwenden. Man gewinnt denselben Vorteil
wie unter
1.4 genannt. Von solchen Codes ist hier aber nicht die Rede.
Auch von den Kategorienummern
sprechen wir hier nicht, obwohl gerade diese als Codes anzusehen sind.
Von solchen Codes wollen viele Metadatenleute nichts wissen! Die
XML-Freunde neigen zu Klartext-Namen für Datenelemente. Freilich
geraten diese dann oft schwerfällig, unpassend und natürlich
sprachabhängig, aus welchen Gründen sich Kategorienummern im
Bibliothekswesen schon früh eingebürgert haben und nirgends als
mysteriös oder altmodisch empfunden werden. Doch auch dies nur nebenbei
- mit allegro ist man auf Kategorienummern angewiesen,
Klartextbezeichnungen können nur sekundär diesen Nummern zugeordnet
werden.
Zur Codierung im engeren Sinne eignen
sich grundsätzlich solche Datenenelemente, für
die es nur eine relativ kurze Liste von möglichen Werten gibt, die als
Auswahlliste beim Erfassen präsentiert werden kann. Für die sog.
Allgemeine
Materialbenennung ist das z.B. der Fall.
3. Welche Codes brauchen
wir?
Ein Code macht eine
Aussage. Wenn dieselbe Aussage aus einem anderen
Faktum ebenfalls abgeleitet werden könnte, ist der Code redundant, d.h.
im
Prinzip überflüssig. Das "andere Faktum" kann der Inhalt eines
anderen Datenelements sein, aber es kann auch die An- oder Abwesenheit
eines
anderen Elements sein! Natürlich macht es dem Programmierer gewisse
Dinge
einfacher, wenn ein Datensatz stets den Code für "Kongreßbericht"
enthält, wenn ein solcher vorliegt. Wenn aber dann auch immer das Feld
#750
besetzt ist, könnte auf den Code verzichtet werden, der Programmierer
müßte nur
an den Stellen, wo es drauf ankommt, das Vorhandensein von #750
zusätzlich
testen. Oder man könnte beim Design des Ganzen gleich auf die
Definition eines
Codes für "Kongreßbericht" verzichten!
WENN man für einen
bestimmten Sachverhalt Codes definiert, dann ist es
günstig, wenn alle Codes einer Liste
3.1
zur
selben begrifflichen Kategorie gehören, d.h. sich auf dieselbe
Eigenschaft
beziehen: Auf einer Codeliste "Materialart" kann nicht ein Code für
"Dissertation" stehen, wenn mit "Materialart" das physische
Material gemeint ist, aus dem die Objekte bestehen, also "Papier"
oder "Mikrofilm" usw. Mit anderen Worten, man muß die Begriffe
präzise definieren, die als Überschriften über den Codelisten stehen.
3.2
sich
gegenseitig ausschließen. Es kann nicht "Noten" und
"Mikroform" auf einer Codeliste stehen, weil es Noten auf Mikrofiche
geben kann. Es kann auch nicht "Serienstück" und
"Kongreßbericht" auf einer Liste stehen, weil ein Kongreßbericht ja
auch als Serienstück daherkommen kann. Auch der übliche "Allgemeine
Materialbenennung" hat hier leider ihren größten Mangel! Gewiß, hier
könnte man auch sagen: ok, das Codefeld muß dann eben mehrfach
besetzbar sein!
Über den tatsächlichen Nutzwert solcher nicht eindeutiger Codes sollte
man aber
gründlich nachdenken. Zumindest für allegro-Restriktionen taugen solche
Codes
nicht.
3.3
eine
nützliche Aussage machen. Wozu z.B. immer einen Code für
"Aufsatzsammlung" eingeben, wenn damit nie etwas angestellt wird?
3.4 mnemonisch gestaltet sind. Zwar können Bearbeitungssysteme die intern gespeicherten Codes komplett verbergen und nur Klartext zeigen. Doch die Erfahrung hat gezeigt, daß der Umgang damit, wozu ja auch auch Programmierung und Parametrierung gehören, durch gute Merkfähigkeit erleichtert wird. Warum also darauf verzichten? Hinsichtlich des internationalen Austauschs freilich hält sich der Nutzen doch wieder in Grenzen, falls man nicht Abkürzungen englischer Grundbegriffe wählt.
Es
ist also, wie man
sieht, nicht einfach, ein System von sinnreichen
und nützlichen Codes zu entwerfen. Für das N-Format greifen wir aber,
statt
alles selber zu erfinden, zurück auf existierende Codelisten. Wir
überlegen
nur, wie sie anzuordnen und ins Format einzubauen sind, um die
genannten
Erfordernisse alle möglichst gut zu erfüllen. Und dabei kommen wir,
Punkt 3.1
bedenkend, auf nicht weniger als 12 Kategorien von Begriffen. Richtig
neu ist
nur der erste in der nachfolgenden Aufstellung. "Elektronische
Ressourcen" sind hier besser aufgehoben als in der "Allgemeinen
Materialbenennung", wo sie den Punkt 3.2 verletzen würden. Wie man die
Titelanzeige gestaltet, ist ein Thema für sich! Nichts verhindert,
hinter dem Titel [Elektronische Ressource] erscheinen zu lassen, egal
welchen Code man an welcher Stelle dafür gewählt hat!
Mit
h vlists erhält man die folgende
Übersicht, wobei man
die Namen jeweils anklicken und die Listen sofort sehen kann (in rot
jeweils
die Felder, wo die Codes zum Einsatz kommen können):
1.
charact Objektart hinsichtlich analog /
digital : #03c
z.B. a
= analog (Buch), b = Digital (e-Book)
2.
material Landläufig "Allgemeine Materialbenennung"
(engl. GMD)
Position 4 in #830 (mehrfach
anwendbar!)
z.B. #830s für Tonträger, #830g für Spiele
3.
pubtype Veröffentlichungsart : #031
z.B. m
= Mehrteilig, l = Loseblatt, a = Artikel (unselbst.)
4. dctype Dublin Core resource
types
: Medientyp von Objekten : #030
z.B.
X = Text, I = Bild, D
= Datenmaterial, S = Sound
5.
formcode Dokumenttyp, Genrecode (inhaltlich
definierter Typ) : #630
z.B. 015
Zeitschrift, 070 Adreßbuch, 200 Datenbank
6a.
sg Sachgruppen (Grobklassifikation) mit
Dewey-Konkordanz : #610
z.B. AR
= Architektur, BLK = Botanik, MK = Musik
6b.
aspect Sachliche Aspekte;
Ergänzung zur Sachgruppe : #610 / #611
z.B. -RE : Rechtlicher
Aspekt, -PL
Politischer Aspekt
7.
dewey 3stellige Dewey-Klassen
(Alternative zu den
"Sachgruppen") : #61d
z.B. 510
Mathematik, 330 Wirtschaft
8.
geo GeoCode (Geographic Area Code der
LC) : #060 / #560
z.B. e-gx
= Deutschland, n-mx = Mexiko
9.
spr Sprachcodes nach ISO639/2
: #050 / #620
z.B. ger
= Deutsch, ara = Arabisch
10.
script Schrift des Dokuments : #055
z.B. b
= Lateinisch, c = Kyrillisch, h = Hebräisch
11.
relat Relator Codes : Funktionsbezeichnungen
für Personen : #2XX $r
z.B.
edt = Editor, ill = Illustrator
12.
normtyp Normsatztyp : #n10
z.B. p
= Personenstammsatz., d = DDC-Zahl