UB BRAUNSCHWEIG
Symbolfoto


allegro-C Das Neutralformat



Wie starten? Download



Was ist das Neutralformat? ...und so sieht es aus

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/

 



[i] zuletzt aktualisiert: 26.04.2011
Email: ub@tu-bs.de