| 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:
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:
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:
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/ |