|
|
|
Inhalt der Seite
allegro-C Neutralformat
allegro-C
Das Neutralformat
|
|
2007-01-16
Jede Datenbank braucht ein Datenmodell. Das ist eine
Beschreibung, wie
die Daten gestaltet sein sollen. Mit einem Textprogramm kann man viele
ganz verschieden gestaltete Texte erstellen und speichern, aber eine
Datenbank ist etwas
anderes: ihre Inhalte müssen einheitlich strukturiert sein. Eine
Bibliotheksdatenbank soll unter anderem Bücher auffindbar machen,
heute aber Dokumente im weitesten Sinne: Die "Bibliothek" ist jetzt
Metapher für jede denkbare Art von Dokumentensammlung, Bücher
stehen manchmal gleichberechtigt neben vielem anderen, aber manchmal
stehen völlig andersartige Dokumente im Vordergrund! Damit das
geht, ist zu jedem Dokument eine Beschreibung zu speichern. So
eine Beschreibung nennt man einen Datensatz. Jeder Datensatz hat eine
Anzahl von Datenelementen mit genau definierten Inhalten. So
könnte etwa in jedem Satz das erste Datenfeld den Titel des
Dokuments
enthalten, das zweite Feld den Namen seines Autors, usw. Die Art und
Bezeichnung
der Elemente darf aber nicht von Satz zu Satz verschieden sein, sonst
könnte die
Datenbank nicht sinnvoll funktionieren: Das Feld für den Autor
kann z.B. nicht mal "Autor" und mal "Verfasser" benannt sein. Der
Inhalt der Felder, und das wird leicht übersehen, braucht
ebenfalls genaue Regelungen, um zuverlässige Ergebnisse zu
ermöglichen: wenn man mal "Peter Tschaikowsky" ins Autorfeld
schreibt und bei einem anderen Werk "Cajkovskij, Pjotr", dann wird bei
einer konkreten Abfrage das eine oder das andere nicht mit
herauskommen. Überhaupt: ist "Autor" die richtige Bezeichnung
für einen Komponisten, oder braucht der sein eigenes Datenfeld?
Ach so, und manchmal gibt es ja zwei oder noch mehr Autoren - wie soll
man damit umgehen? Hm, und mehrteilige Dokumente, wie kriegt man die in
den Griff? Man merkt schnell: es tauchen viele verschiedenartige Fragen
auf, sobald man ernsthaft mit dem datenbanktechnischen Beschreiben von
Dokumenten beginnen will.
Die Meinungen gehen weit auseinander: die einen wollen bis in kleinste
Einzelheiten hinein alles regeln und genau darstellbar machen, die
anderen finden Strukturierungen weitgehend unnötig und setzen auf
reine Text-Indexierung à la Google. Wenn aber eine Datenbank
mehr leisten soll, als nur gespeicherte Beschreibungen per
Stichwortsuche auffindbar zu machen, dann sind Metadaten mit
durchdachter Struktur gefragt - jeder weiß das, der mit
Bibliotheksdaten schon einmal zu tun hatte: Da werden Listen gebraucht
und Tabellen, da müssen Geschäftsgänge abgewickelt
werden und Benutzungsoberflächen gestaltet, E-Mails und Briefe
geschrieben, man will statistische Auswertungen aller Daten oder
bestimmter Teilmengen ... Im Zentrum immer die Datenbank, und immer
soll sie
genau die richtigen Datenelemente - aber immer wieder andere - in der
richtigen Sortierung, Anordnung und Ausführlichkeit liefern!
Je mehr Aufgaben eine Datenbank
erledigen soll, umso mehr Datenfelder braucht man, und umso
größer wird die Mühe mit der sinnvollen Gestaltung,
zumal man dabei auch an die Datenerfassung zu denken hat: diese soll
natürlich leicht zu erlernen und schnell durchzuführen sein.
Die
gesamte Beschreibung aller Datenfelder, ihrer Reihenfolge und ihrer
Eigenschaften, das nennt man ein Datenmodell.
Das Neutralformat ist ein
Datenmodell, mit dem das allegro-System
eine Datenbank anlegen kann. Im allegro-System
wird die Beschreibung
des Modells einer Datenbank in einer sog. Konfigurationsdatei
niedergelegt.
Für das Neutralformat wurde eine Konfigurationsdatei mit dem
Namen N.CFG erstellt: darin steht, welche Datenfelder ein Satz haben
kann,
wenn man dieses Format anwendet. Das sind ziemlich
viele (weit über 100!), aber allegro-Datenbanken haben eine
angenehme Eigenschaft:
Felder, die man nicht belegt, stören nicht - sie sind in der
Anwendung automatisch nicht zu sehen und verbrauchen auch keinen
Speicherplatz! Ganz anders ist das z.B. bei relationalen Systemen, die
intern mit Tabellen arbeiten; allegro
ist kein solches System.
Was ist es nicht?
Es ist kein Minimalformat. So etwas, zum Lernen
und Ausbauen, gibt es schon lange: Geben Sie ein h mini , dann erfahren Sie alles weitere! Man
soll vielmehr von vornherein möglichst viel damit machen können, ohne sich mit den Konzepten der
Konfiguration und Parametrierung zeitraubend befassen zu müssen,
aber auch ohne den bibliothekarisch vorgeprägten Ballast der
historisch gewachsenen Standard-Konfiguration aus Braunschweig.
Etwas genauer:
Was soll
das
Normalformat?
Es soll die Arbeit
erleichtern, die
man damit hat, sich ein eigenes
Datenmodell zu zimmern. Denn dies kann tatsächlich in sehr
viel Arbeit ausarten, wenn man sehr viele Aufgaben mit der Datenbank
erledigen will. Das Neutralformat stellt eine Menge Datenfelder bereit,
aus denen man sich aussuchen kann, was man braucht. Ganz leicht kann
man noch, sofort oder später, weitere Felder einrichten.
Die schon vorhandenen Felder erlauben aber schon die Beschreibung sehr
vieler Einzelheiten von Objekten. Leicht erweitern und modifizieren
kann man ferner auch die Indexierung und die Anzeige der Daten, auch
die Präsentation im Web. Bereits unterstützt wird ferner die
Verwendung von Normdaten (sog. Stammsätzen) für Personen,
Körperschaften, Schlagwörter und Klassifikationen:
dafür kommen bewährte Methoden zum Einsatz. Auch
hierarchische und verknüpfte Datensätze sind schon im
Standard vorgesehen.
Das Format soll die
"Megatrends"
aufgreifen, die sich in den letzten 20 Jahren herausgebildet haben.
Dazu zählen diese zwei:
1.
Dublin
Core
(DC)
Unter
dem
Eindruck der schlechten Ergebnisse von Suchmaschinen im Netz (vor
Google!) wurde mit DC eine Liste von 15 Datenelementen aufgestellt, die
man für unbedingt wichtig hielt, um Web-Ressourcen zu beschreiben.
Ressourcen? Zunächst sprach man von "document-like objects",
meinte damit aber schlechterdings alles, was im Netz irgendwie
zugänglich gemacht werden kann. DC ist jedoch nur eine
Liste von Begriffsdefinitionen, kein Datenformat: es wird nichts
über die tatsächliche Gestaltung der Daten ausgesagt. Wie man
DC implementiert, das bleibt den Systementwicklern voll
überlassen. Meistens sieht man HTML oder XML-Strukturen, doch ist
dies keineswegs zwingend. Sinnvoll ist, XML-Daten mit DC-Inhalten
exportieren zu können - das kann allegro allerdings schon lange.
Das Neutralformat verwendet DC-Terminologie und weist den DC-Elementen
prominente Plätze zu. Ansonsten geht es weit darüber hinaus,
was niemanden wundern wird - DC ist ja nur ein Minimalkonsens. Es soll
jedoch im Prinzip leicht möglich sein, differenzierte Metadaten im
Bedarfsfall auf "DC Simple" abzubilden, auf die 15 Elemente also, was
z.B. im OAI-Kontext ausdrücklich erwünscht ist (sog. "dumbing
down").
Das Neutralformat bietet also mehr Datenelemente als DC! Im Vergleich
zur Strukturierung von DC-Daten, wie man sie in der Metadaten-Szene
antrifft, z.B. mit RDF-Notierungen, ist aber das Neutralformat sehr
einfach in der Anwendung. Das ganze Konzept "Metadaten", so muß
man erinnern, war entstanden, weil man die bibliothekarischen
Katalogdaten, MARC vor allem, als viel zu kompliziert empfand...
2.
Functional Requirements of Bibliographic Records (FRBR)
Dieses
in
der IFLA erarbeitete Konzept benennt "Entitäten", die
beschrieben werden können: Werke, Personen, Körperschaften,
Konzepte (Sachgegenstände), sowie Anforderungen, die man mit
Metadaten erfüllen will: Finden, Identifizieren, Lokalisieren,
Beschaffen, Navigieren. FRBR listet dann Datenelemente auf, die zur
Erfüllung der Funktionen gebraucht werden. Präzisiert wird
insbesondere, was man unter Werk
(engl. Work, in den AACR gar
nicht definiert) eigentlich
verstehen will. Wichtig: das Werk als geistige Schöpfung ist ein
Abstraktum. Als konkrete Objekte liegen immer nur bestimmte Fassungen von Werken
vor (Expressions:
inhaltlich
unterscheidbare Ausgaben), jede Fassung u.U. in
verschiedenen Versionen (Manifestations: das sind
inhaltsgleiche Ausgaben: Dateitypen, Druckvarianten, Hörbuch,
unterschiedliche
Datenträger). Von jeder Version kann es identische Exemplare (Copies) geben, die in Metadaten
evtl. ebenfalls beschrieben werden müssen. Auch FRBR ist kein
Datenformat und will es auch nicht sein, sondern es ist, wie gesagt,
ein Konzept. Seine Umsetzung in konkrete Strukturen bleibt gleichfalls
den
Systembetreibern überlassen.
Besonders die Hierarchie: Werk
>> Fassung >> Version >>
Exemplar gilt es in den Metadaten deutlich zu machen. In der
MARC-Umgebung, das hat man schon gemerkt, kann man wohl nicht für
jede dieser Entitäten einen jeweils eigenen Datensatz anlegen, das
würde sehr kompliziert,
sondern in existierenden MARC-Daten liegen alle vier Ebenen in
Titeldatensätzen vermischt vor - eine saubere Trennung per
Programm ist nicht möglich, man wird mit den vielen Millionen
Daten weiter leben müssen. Man versucht gleichwohl, ein paar
Grundideen zu realisieren. Genau betrachtet ist FRBR kein völlig
neues Konzept, sondern ein altes: schon die bekannten, historischen
Großkataloge versuchten immer, bei den sehr produktiven Autoren
die Titel in sinnvoller Weise zu ordnen: nach Genre, Originaltitel,
Sprache, Ausgabe, Erscheinungsform u.a. So etwas ist umso
nützlicher je größer der Katalog ist. Aber es ergibt
oder erledigt
sich in der Datenwelt nicht von selbst - und endlich hat man das
gemerkt ... Das neue, im Entstehen begriffene Regelwerk RDA ("Resource
Description and Access") soll sich auf das FRBR-Konzept stützen. RDA
liegt allerdings in wesentlichen Teilen noch nicht vor (Apr. 2006).
Zwar gibt es ein
langjährig bewährtes Datenformat in der allegro-Umgebung, das
sog. konsolidierte Format, auch A-Schema genannt. Dieses ist
jedoch einerseits von
der langen (Bücher-)Tradition belastet, andererseits aus der Sicht der
genannten
modernen Entwicklungen nicht gut verständlich und nicht
genügend ausdrucks- und leistungsfähig.
Modifikationen und
Erweiterungen am A-Schema sind zudem leider wegen der gewachsenen
Komplikationen
der
Standard-Parameter recht schwierig. Wer neue Projekte beginnt, wird
daher oftmals lieber einen eigenes Datenformat neu entwerfen. Das
Neutralformat soll in solchen Fällen bewährte Dinge fertig
und
mit wenig Ballast bereitstellen, neue Anforderungen aber leicht als
Erweiterung in sich aufnehmen können.
Das Ziel des Normalformates ist es nicht,
das bewährte A-Schema im Bereich der Katalogisierung
abzulösen, zufriedene Anwender können durchaus dabei bleiben!
Gleichwohl wurde darauf geachtet, A-Daten
später leicht in das N-Format konvertieren zu können, denn
sehr wahrscheinlich hat man das A-Schema hier und da als Default
für andersartige Anwendungen
genommen, fühlt sich aber nicht recht wohl damit, weil das
Ändern und
Erweitern zu aufwendig ist. In solchen Fällen sollte der Umstieg
möglichst leicht sein.
Ziel ist gleichfalls nicht, existierende andere Formate wie etwa MAB
oder MARC auszustechen. Sie haben und behalten (MAB langfristig wohl
nicht) ihren Platz als Austauschformate. Intern jedoch, im Innern einer
Datenbank, kann es durchaus ganz anders aussehen, und in sehr vielen
Fällen ist das ja auch so. MAB und MARC sind dafür nicht
geschaffen worden - es wäre deshalb erstaunlich, würden sie
sich optimal als Internformat eignen. Auch einige große
Verbünde sowie die Deutsche Bibliothek haben intern andere
Strukturen. Entscheidend ist, MAB- und MARC-Daten zwecks Austausch
importieren und exportieren zu können. Genau das ging schon bisher
mit dem A-Format, und es wird auch mit dem N-Format gehen.
Hinzuweisen ist auch auf HANS
für Handschriften, Autographen (insbes. Briefe) und
Nachlässe, ein sehr ausführliches Schema, das weite
Verbreitung gefunden hat. Dieses als Grundlage für neue
Anwendungen zu nehmen, empfiehlt sich nach wie vor für die
betreffenden Bereiche!
Wie
ist das
Neutralformat aufgebaut?
Leider
fehlen uns in der Umgangssprache die treffenden Begriffe. "Dokumente"
ist hier im weitesten Sinne zu verstehen! Im Englischen
wird, ausgelöst von der DC-Bewegung, heute immer von resources
gesprochen. Es ist aber nicht hilfreich, dafür nun im Deutschen
"Ressourcen" zu sagen - welcher Endnutzer würde sich dabei wohl
sofort das Richtige denken? Selbst das alte "Veröffentlichung"
wäre besser, wenn man es versteht als alles, was einer
Öffentlichkeit zugänglich gemacht wird.
Das Format hat folgende Gruppen von
Datenfeldern:
Bereiche
|
Sinn und Zweck der Angaben
|
#0 : Codes, Nummern, E-Adressen, Datumsangaben
#1 : Titelangaben
#2 : Personennamen
#3 : Körperschaftsnamen
#4 : Gesamtheits-Angaben
#5 : Themen :Schlagwörter (verbale Erschließung)
#6 : Themen :Klassifikationen
#7 : Quellenangaben
#8 : Physische Beschreibung
#9 : Lokaldaten, Exemplardaten
#9x : Anwenderspezifische Daten
#n : Normdaten
Ferner kann es noch Sonderfelder für interne Zwecke geben
|
Eindeutige Identifizierung und Typisierung
Sachliche Benennungen, wie direkt am Objekt zu finden
Beteiligte Personen
und verantwortliche Gruppierungen
(Formale) Zugehörigkeit zu anderen (größeren) Objekten
Themen, die das Dokument behandelt
Einordnung in sachliche Zusammenhänge
(Inhaltliche) Herkunft des Dokuments
Physische Eigenschaften
Wo befindet sich das Objekt? Wie erhält man es? etc.
Angaben für Verwaltungs- und andere lokale Zwecke
Normierung für bessere Zuverlässigkeit der Suche
|
Um einen ersten
Eindruck zu
vermitteln, hier eine Liste der 15 vermutlich wichtigsten Felder (es
sind nicht ganz genau die 15 DC-Elemente).
Dieses "Basismodell" könnte schon für sich allein verwendet
werden, wenn es um schlichte bibliothekarische Katalogisierung geht:
(an den
Nummern sieht man sofort, zu welchen Gruppen die Elemente gehören)
#000 IdNummer (des eigenen Systems)
#040 Jahr (der Freigabe/Veröffentlichung)
#070 URL
#080 FremdIdNr (z.B. ISBN)
#100 Titel
#200 Person
#300 Körperschaft
#400 Gesamttitel
#500 Schlagwort
#600 Notation (Klassifikation)
#750 Veranstaltung (z.B. Tagung)
#810 Umfang
#860 Impressum (konventionell) und/oder
#360 Verlag (normierter Name)
#900 Signatur
#950 Rechte
Die Felder sind alle
wiederholbar, d.h. mehrfach belegbar, indem man eine Ziffer an die
Nummer anhängt (z.B. #2000, #2001 für eine zweite und dritte
Person).
Wer mehr Differenzierung möchte, kann weitere Felder hinzunehmen:
#210 für Beteiligte Personen, #310 für Beteiligte
Körperschaften (#200 und #300 dann nur für die
hauptverantwortliche Person bzw. Körperschaft).
Die
vollständige Liste der definierten Felder entnimmt man aus der
kommentierten Konfigurationsdatei
N.CFG.
Stammsätze
haben eigene Feldnummern, die mit #n beginnen. Anders als beim
bekannten A-Format haben die unterschiedlichen Stammsatztypen alle
dieselben Kategorienummern, die Zuordnung wird nur durch die Angabe des
Satztyps in #n10 bewirkt, z.B. p für Person und t für
Thesaurus-Term.
Zu diesem Grundgerüst
werden
geeignete Parameterdateien für Anzeige und Index bereitgestellt.
Man findet also bereits einen Rahmen für den ersten Einstieg vor.
Die Parameter sind, wie die CFG-Datei, ausführlich kommentiert und
änderungsfreundlich gestaltet. Die bekanntesten Möglichkeiten
sind schon zur wahlweisen Nutzung eingebaut: Texel-Ersetzungen,
Linkstrunkierungsindex, Phrasenindexierung, V14-Ersetzungen.
Es gibt etliche Stellen, an denen Codierungen Verwendung finden können. Konkret muß der Anwender sich dies für jede Anwendung gut überlegen. Als Angebot gibt es 12 Listen von Codes, auf bekannten Standards beruhend, die man einsetzen kann.
Für einige Felder sind auch Unterfelder definiert. Diese sind zur
weiteren Strukturierung eines Feldinhalts gedacht. Stets wird ein
Grundinhalt ohne Unterfeldkennung eingegeben, die Unterfelder dann mit
$x angehängt, wobei $ der Code 31 ist und x ein Kennbuchstabe. Auf
diese Weise sind Anwender des Basismodells nicht gezwungen (wie bei
MARC), am
Feldanfang immer $a zu schreiben, auch wenn sie ansonsten gar keine
Strukturierung innerhalb der Felder vornehmen.
Wiederholbare Unterfelder soll es nicht geben: sie steigern
unverhältnismäßig die Komplexität einer
Verarbeitung. Innerhalb eines Teilfeldes können freilich mehrere
gleichartige Inhalte stehen, getrennt durch Semikolon.
Es gibt 13 Standard-Unterfelder, mit Großbuchstaben
gekennzeichnet, die man bei jedem Datenfeld anwenden kann:
| $A FldAbbr |
Kurzform des Inhalts |
| $D FldDate |
Jahr oder Datum, falls f. Feldinhalt wesentlich |
| $I FldID |
IdNr zum Feldinhalt, z.B. Normsatz-Nummer |
| $L FldLang |
Sprache des Feldinhalts |
| $N FldNum |
Nummer, falls eine Zählung wesentlich ist f. Feldinhalt |
| $P FldPre |
Vortext (Prefix): Anzeige VOR dem Feldinhalt |
| $R FldRule |
Regel oder Norm zu dem betr. Feld |
| $S FldSpell |
abweichende Schreibweise [für zusätzliche Indexierung] |
| $T FldType |
Wenn der Feldinhalt von unterschiedlichem Typ sein kann |
| $U FldURL |
URL zum Feldinhalt |
| $X FldNNote |
NonPublicNote: Zusatztext, nichtöffentl. |
| $Y FldText |
Text zu beliebiger Verwendung, z.B. anzuzeigender Text (Vorlageform)
[Hauptinhalt des Feldes ist immer die indexierfähige Ansetzungsform] |
| $Z FldPNote |
PublicNote: Zusatztext, öffentlich; "Fußnote" zum Feldinhalt |
An diesen
Eigenschaften
sieht man: das Konzept ist darauf ausgerichtet, für einfache
Anwendungsfälle und für den vermutlich häufigen Bedarf
auch einfach auszusehen und damit leicht erlernbar zu sein. Dadurch
unterscheidet sich das Neutralformat nicht zuletzt sehr von
hergebrachten Standards wie MAB oder MARC, auch UNIMARC. Zwar
ist es letztlich ganz egal, wie man intern die Felder numeriert und
anordnet - das System versteht sowieso nichts von Inhalt und Bedeutung
der Daten. Aber ständig müssen Menschen mit den
Feldbezeichnungen umgehen! Sie müssen Daten eingeben und
bearbeiten, müssen darüber leicht reden können (!), und
sie müssen Skripte und Programme schreiben, in denen auf die
Elemente Bezug
genommen wird! Das geht alles viel besser, wenn man sich die
häufig vorkommenden Nummern leicht merken kann.
Erfahrungsgemäß sind dabei Nummern
günstiger als verbale
Bezeichnungen! Die meisten Felder lassen sich nämlich gar nicht
mit einem simplen, intuitiv leicht zu erfassenden Namen benennen. Das
erkennen Sie schnell, wenn Sie sich die Liste anschauen. Verbale
Benennungen haben noch einen anderen, schwerwiegenden Nachteil: sie
sind
sprachabhängig, Nummern dagegen nicht.
Wie werden die Daten indexiert?
Das Indexieren ist keine Sache der Konfiguration! Anders gesagt: In
der Datendefinition steht nur, welche Felder es geben soll, darin
steht nichts über deren Indexierung. Dazu braucht man eine
Index-Parameterdatei. Eine solche wird mitgeliefert, ihr Name ist
bank.npi . Diese ist kommentiert und kann leicht ausgebaut,
modifiziert oder auch ganz umgestaltet werden, wie es dem Neutralkonzept entspricht. Vordefiniert
sind 10 Register:
1
Gesamt-Wortregister (Wörter aus Titeln, Namen u.a., auf Wunsch mit
Linkstrunkierung)
2 Titelwortphrasen
(jeweils 2 im Titel aufeinanderfolgende Wörter)
3 Titel-Anfang (die
ersten 80 Zeichen)
4 Personen
5 Körperschaften
incl. Verlage
6 Serientitel
(Gesamtwerk-Titel)
7 Klassifikation
8 Signaturen
9 Datums- und
Nummernregister
10 Interne Angaben,
Hilfsregister für versch. Zwecke
Lohnt sich das wirklich?
Man mag bei genauerer Betrachtung zu der Ansicht gelangen, das
Neutralformat sei nun auch nicht gerade eine revolutionäre
Umwälzung, sondern erscheine in vielen Punkten als eine
Umgruppierung der altbekannten A-Elemente. Das jedoch braucht
eigentlich niemanden zu verwundern, war doch das Konsolidierte Format
mit den Anforderungen gewachsen - und seine hohe Beliebtheit und
Verbreitung steht der Ansicht geradezu entgegen, man müsse es in
Bausch und Bogen verwerfen! Dennoch hat das A-Schema wegen seiner
zweistelligen Nummern hinsichtlich Erweiterungen unbequeme Grenzen, und
seine innere Struktur ist wegen der "historischen Gewachsenheit" in
vielen Punkten uneinheitlich oder erscheint gar unlogisch. Aus diesen
Erfahrungen zu lernen ist eine Chance, die dem gründlichen
Neuentwurf des Neutralformats sehr zugute gekommen ist.
Abschließend wagen wir eine Prognose:
Das Neutralformat wird unter dem Spitznamen Nikolausformat
in die
Formatgeschichte eingehen. Zum einen wegen des Freigabedatums (s.u.),
zum andern, weil man sich so den Namen N.CFG leichter merkt. Und zum
dritten, weil dieses Datum schon einmal im bibliothekarischen Raum eine
Umwälzung markierte.
Nachwort
Unter dem Eindruck des Google-Erfolgs bildet sich leicht die Ansicht,
(intellektuell erstellte) Metadaten seien ein überholtes Konzept,
Suchmaschinen seien weit überlegen und nicht mehr auf Metadaten
angewiesen.
Lesen wir aber, was Larry Page, Mitbegründer von
Google, über die weitere Zukunft des Suchens denkt:
| In short, the search
engine of
the future isn't
really a search engine as we know it. It's more like an intelligent
agent -- or, as [Google co-founder] Larry Page told me, a reference
librarian with complete mastery of the entire corpus of human
knowledge. |
Das schrieb John
Battelle in
seinem lesenswerten Buch "The Search : How Google and its rivals
rewrote the rules of business and transformed our culture" (ISBN
1-59184-088-0). Ob und wie diese ultimative Vision allein mit
künstlicher Intelligenz erreicht werden könnte, ist freilich
noch nicht zu erkennen. Aber "librarian" als Denkmodell in diesem
Zusammenhang, nebenbei bemerkt, würde man dergleichen in
Deutschland hören?
|
Wie starten?
Wer neu mit allegro beginnt, kann jetzt entscheiden:
* Soll es eine traditionelle Katalogdatenbank sein mit einem
bewährten Modell und der Möglichkeit, auch Ausleihe und Erwerbung machen zu können, dann wählt man das A-Format
.
* Wer im Umfeld von Handschriften, Autographen und Nachlässen tätig ist, wird zu HANS
greifen!
* Geht es dagegen um ein Metadatenprojekt ohne bibliothekarische
Funktionen, dann ist N das bessere Format.
Neue, eigene Datenbank
mit Neutralformat anlegen
Ganz am Ende: Hinweise zur Installation des
PHP-Pakets für den Web-Zugriff.
Die Grundidee beim Neutralmodell ist:
1. Man installiert das Neutralpaket und sonst nichts:
(d.h. es muß vorher noch keine allegro-Installation
da sein - aber wenn doch, ist es auch egal, null Risiko!)
Hier ist das Neutralpaket:
http://ftp.allegro-c.de/aktuelle-version/inst-neu.exe
oder zunächst nur das DemoPaket:
http://ftp.allegro-c.de/pub/DEMO-Version/neu-demo.exe
(Später dann Vollversion drüber und weiterarbeiten.)
2. Man öffnet mit dem neuen Icon die DemoBank
und beginnt, darin Daten zu erfassen. Sonderservice:
>>> Terminfunktion: Alt+8 oder Eingabe von h memo <<<
Schon vorhandene Daten einspeisen? Siehe dazu die
Beschreibung unter 6.-10. und den Text, den man mit
h fremd erhält.
3. GANZ wichtig:
Das Startmenü der DemoBank (erscheint bei Druck auf das
rote Fragezeichen) enthält auch Funktionen zum schnellen
Löschen aller Beispiel- und Hilfsdaten. Sobald diese
stören, kann man sie damit sofort loswerden und damit
die DemoBank vollends zur eigenen machen!
Wenn man eine weitere Datenbank eröffnen will:
4. Das Verzeichnis nbase, das beim Installieren entstanden
ist, auf ein anderes kopieren. Es enthält eine frische
Kopie der DemoBank mit allen nötigen Dateien.
(Die Kopie, mit der man anfangs arbeitet, liegt auf dem
Unterverz. nbank, das automatisch angelegt wird.)
5. Für die neue Kopie ein neues Icon anlegen nach dem Vorbild
desjenigen für die DemoBank. Weiter bei Punkt 2.
Tips
Die feldbezogenen Hilfetexte erhält man mit F1, während der
Cursor im Schreibfeld ein Datenfeld bearbeitet oder auch im
Formular. Es gibt einen Hilfetext zu jedem Datenfeld, z.B.
h810 zum Feld #810. Diese Texte kann man auch direkt mit dem
h-Befehl abrufen, z.B. h h100 eingeben.>
Umwandlung einer eigenen A-Datenbank ins N-Format:>
6. Neutralpaket installieren, z.B. nach c:\allegro\NTEST
dann liegen dort alle zugehörigen Dateien
7. In der neuen Datenbank, falls gewünscht, zuerst die Beispieldaten
und evtl. auch die Doku-Sätze alle löschen (s.o. 3.)
8. Parameter i-neut.apr nach c:\allegro, die Tabelle ASCIANSI.APT
wird dort schon vorhanden sein.
9. Batchdatei aton.bat mit folgendem Inhalt einrichten:
(für NTEST evtl. den selbstgewählten Verz.Namen einsetzen, und für
DEMO2 den Verzeichnisnamen Ihrer Datenbank)
srch -f4 -dDEMO2 -ei-neut/NTEST\neut.nlg -m0 -s0 -v0
index -@1 -f70 -kn -d*NTEST -ebank/NTEST -m0 -n1
index -@2 -fi1 -kn -d*NTEST -ebank/NTEST -m0
10. Starten: auf c:\allegro den Befehl
aton
geben
Es kommen zwei Dateiauswahl-Abfragen:
(Man setzt jeweils + vor alle gewünschten Dateien, dann Enter)
1. Auswahl der umzuwandelnden Dateien auf Ihrem Verz., hier demo2
Dann läuft die Umwandlung, danach:
2. Automatisch läuft die Indexierung der umgewandelten Daten
zusammen mit den in der DemoBank schon vorliegenden Daten.
Das Löschen nicht erwünschter Daten, z.B. der Demo-Datensätze
und oder der Format-Hilfssätze, kann auch später erfolgen,
siehe oben Pkt. 3.
Wer nicht A.CFG hat, muß sich erst eine Umwandlungsparameterdateii-neut.xpr
schaffen, um dies nachvollziehen zu können. Falls eine
Umwandlung vom eigenen X.CFG nach A.CFG existiert, kann man natürlich
zweistufig umwandeln, dann entfällt das Schreiben eigener Parameter.
Aber nochmals der Hinweis: Niemand muß von A auf N umstellen. N.CFG
ist primär für neue Projekte gedacht. Zum Lernen mag es gleichwohl
sehr nützlich sein, die Übung mal durchzuführen.
---------------------------------------------------------------------
Installation des PHP-Pakets
Das Unterverzeichnis PHP in ein Unterverzeichnis des Webservers kopieren, z.B. beim Apache-Server:
htdocs/katalog
Dann ist <Webserver-URL>/katalog/ die Startadresse, genau gesagt:
index.php
wird dann gezeigt. Diese Startseite
kann man nach Belieben modifizieren.
Unter den PHP-Dateien findet man auch eine Datei
files.txt
Sie enthält eine kommentierte Liste der Dateien mit
Hinweisen auf nötige Eingriffe. Alle Dateien enthalten Kommentare.
Die Demo-Installation ist hier: [was Sie da zuerst sehen, ist index.php]:
http://www.biblio.tu-bs.de/db/neutral/
|
|
Datum
Erstellung/Bearbeitung: 2005-12-06 / 2007-01-16
|
© 2005/07, UB
Braunschweig
Bernhard Eversberg
(b.eversberg@tu-bs.de)
|
[i] zuletzt aktualisiert:17.04.2008
|
|
|
|
