3.2.1 Grundstruktur
Der Grundstein war mit der Konstruktion eines geeigneten XML-Datenschemas gelegt. Nun musste ein Programm implementiert werden, das die Daten von MAB2 nach XML konvertiert und die Richtigkeit der Datens¨atze garantiert.
Die Implementierung dieses Programms wurde inC++gel ¨ost, da es eine ob-jektorientierte Programmiersprache ist und auf vielen Rechnerarchitekturen ver-breitet ist. Ein weiterer wichtiger Punkt war das Vorhandensein einer String-Klasse, die die textuelle Verarbeitung der ganzen Textzeilen vereinfacht.
Der Einsatz einer objektorientierten Sprache erm ¨oglicht die Erstellung des nachfolgenden Klassenmodells. Die Tatsache, dass die MAB2-Dateien den glei-chen Aufbau und gemeinsame Datenfelder besitzen, verdeutlicht das folgende Klassenmodell. Zuallererst musste eine Klasse erzeugt werden, die die Gemein-samkeiten kapselt und gleichzeitig flexibel genug ist, weitere MAB2-Dateien zu unterst ¨utzen. Dies f ¨uhrt zu einer besseren ¨Ubersichtlichkeit des Codes. Zu diesen Gemeinsamkeiten z¨ahlen Datenfelder, die mindestens zwei der MAB2-Dateien gemeinsam haben. Dazu geh¨oren Datenfelder wie z. B. die SWB-spezifischen, die Datensatz- und die L¨andercode-Daten. F ¨ur diese Klasse wurde die Bezeichnung CMAB2Parsergew¨ahlt. Die Eigenheiten der einzelnen MAB2-Dateien wurden je-weils in eine eigene Klasse gepackt, wobei diese als Unterklassen der Klasse CMAB2Parserabgebildet wurden. Jede Unterklasse ist f ¨ur das Parsen ihrer Datei verantwortlich. So parst die KlasseCMAB2TitleParserdie Titeldatei. Die Namen der anderen drei Klassen lauten CMAB2PersonParser, CMAB2CorporationParser undCMAB2BuzzWordParser. Der vollst¨andige Quellcode befindet sich auf der bei-liegenden CD.
Das nachfolgende Klassendiagramm veranschaulicht die wichtigsten Details noch etwas besser. Auf der beigelegten CD befinden sich alle ausf ¨uhrlichen Klas-sendiagramme.
CMAB2Parser
# m strBuffer :CString
+ ParseFile(ofstream* pFile, const string& strFileName) :bool
# hlpParseFieldNumber(CString& rstrLine) :bool
# hlpCloseDataRecord() :void
CMAB2TitleParser
# m mMediumtype :MediumType CMAB2PersonParser
CMAB2CorporationParser CMAB2BuzzWordParser
Abbildung 3.2: Klassendiagramm des Konvertierungsprogramms
Die ¨offentlich zug¨angliche MethodeParseFile, die in der Basisklasse imple-mentiert ist, regelt den Ablauf bei der Abarbeitung der einzelnen MAB2-Dateien.
Zuerst werden nacheinander die einzelnen Datens¨atze eingelesen, indem alle Zeilen in einer doppelt verketteten linearen Liste von Strings gespeichert werden.
Dies geschieht mit Hilfe der MethodehlpReadDataRecord, die als Argumente ei-ne Datei, aus der sie lesen soll, und eiei-ne Liste, in die sie die Zeilen speichern soll,
¨ubergeben bekommt. Somit ist in der Liste ein ganzer Datensatz gespeichert, der dann weiterverarbeitet werden kann. Diese Liste enth¨alt immer nur einen Da-tensatz, womit der Speicherverbrauch in einem akzeptablen Rahmen bleibt und nicht von der Gr¨oße der Eingabedatei abh¨angig ist. Weiter ist eine Verarbeitung eines ganzen Datensatzes nachvollziehbarer.
Jede enthaltene Zeile eines eingelesenen Datensatzes wird an die Methode hlpParseFieldNumberweitergegeben. Diese Methode ist in der Basisklasse CMAB2-Parser als abstrakt deklariert, womit jede von ihr abgeleiteten Klasse eine sol-che Methode implementieren muss. Mit dieser Klassenmodellierung k ¨onnen nun auch sehr leicht die noch nicht unterst ¨utzten MAB2-Formate, wie MAB-LOKAL und MAB-NOTAT, hinzugef ¨ugt werden, ohne eine Reimplementierung des Klas-senmodells notwendig zu machen. Beim Hinzuf ¨ugen eines dieser Formate muss
nur eine Unterklasse von CMAB2Parser erzeugt werden, die dann die Methode hlpParseFieldNumberimplementiert.
Dieses Konvertierungsprogramm tr¨agt den Namen mab2toxmlund wird wie folgt aus einem Linux-System aufgerufen:
./mab2toxml -o <Datei> <MAB2-Pr¨afix>
Beim Aufruf dieses Programms m ¨ussen nicht alle MAB2-Dateien einzeln an-gegeben werden, da sich diese bei einem Datenbankabzug nur an der Datei-endung unterscheiden, muss nur einmal der Dateiname, der die Bezeichnung
’MAB2-Pr¨afix’ tr¨agt, angegeben werden. Die bei der Konvertierung erzeugte XML-Datei erh¨alt den NamenDatei.
3.2.2 Funktionsweise
Die MethodehlpParseFieldNumberverarbeitet jede Zeile eines eingelesenen Da-tensatzes, indem sie die Feldnummer und einen m ¨oglichen Indikator auswertet und dann das Datenfeld in einen XML-Tag schreibt. Diese Tags werden mit der HilfsfunktionhlpBuildElementTagaus der DateiTools.ccbewerkstelligt, wobei ihr der Name des Tags, der Inhalt und die Anzahl der Einr ¨uckungen (Tabula-toren) am Anfang der Zeile ¨ubergeben werden. Diese Methode erleichtert den Umgang mit dem Erzeugen der XML-Tags, da sie die Start- und Endtags erzeugt.
Weiter besteht die M¨oglichkeit ihr bis zu zwei Attribute zu ¨ubergeben, da es sich um eine ¨uberladene Methode handelt.
Allerdings wird der so erzeugte XML-Tag nicht direkt in die Ausgabedatei geschrieben, da dies die Anordnung innerhalb der XML-Struktur nicht gew¨ahr-leisten k¨onnte. Die einzelnen Gruppierungen werden tempor¨ar in Variablen ge-speichert, um dann am Ende eines Datensatzes alle Variablen in einer vorgege-benen Reihenfolge in den Pufferm strBufferzu schreiben. Die einzelnen Varia-blen werden danach wieder geleert. All das geschieht in der abstrakten Methode hlpCloseDataRecord, die von den Unterklassen ¨uberschrieben werden muss. Da-mit ist gew¨ahrleistet, dass jede Unterklasse die Reihenfolge festlegt, in der sie ihre Tags in die Ausgabedatei schreibt.
Es gibt Attribute, die nicht jedem Medientyp zugeordnet werden d ¨urfen, so kann z. B. nur der Medientyp Mikrofiche das Attribut mathematische angaben aufweisen. Dieses Feld gibt den Maßstab an und ist somit nicht bei anderen Me-dientypen notwendig bzw. anwendbar. Diese ¨Uberpr ¨ufung soll auf Eingabefehler hinweisen und kann somit der Ausbesserung von Fehlern dienen, die beim alten Datenformat nicht aufgefallen sind. Um dies zu erkennen wird in der Variablen
m MediumType der Medientyp gespeichert. Um nun Attribute in einem Medien-typ auszuschließen, wird bei jedem Datenfeld auf diesen MedienMedien-typ gepr ¨uft. Tritt dieser auf, so gibt die MethodehlpParseFieldNumberfalsch zur ¨uck.
Die MethodeParseFilebricht in einem solchen Fehlerfall die Weiterverarbei-tung des aktuellen Datensatzes ab und f¨ahrt mit dem n¨achsten Datensatz fort.
Damit der Benutzer den fehlerhaften Datensatz korrigieren kann, wird eine ent-sprechende Fehlermeldung auf der Standardausgabe ausgegeben. Diese Fehler-meldung enth¨alt neben der Identifikationsnummer des entsprechenden Daten-satzes auch noch die Angabe in welcher der MAB2-Dateien dieser Fehler auftrat.
Die Fehlerkorrektur kann nicht programmtechnisch durchgef ¨uhrt werden, da es sich bei dem Fehler um einen Eingabefehler (Tippfehler) oder der falschen Zu-weisung eines Mediumtyps handeln kann. Erfolgte diese Pr ¨ufung ohne Fehler, weist dies noch nicht auf einen fehlerfreien Datensatz hin, da es Datens ¨atze geben kann, die bei der Feldnummer 076 aufh¨oren. Diese sind somit nicht g ¨ultig, da die Informationen ¨uber einen Datensatz erst bei Feldnummer 100 beginnen. Darauf wird vor dem Schreiben, in der MethodehlpWriteDataRecord, gepr ¨uft. Verl¨auft diese Pr ¨ufung positiv, ist der vorliegende Datensatz g ¨ultig und kann schließlich in die Ausgabedatei geschrieben werden. Die Variablem strBuffer, die zu die-sem Zeitpunkt den kompletten Datensatz im XML-Format enth¨alt, wird in die Datei geschrieben und dann anschließend geleert. Schl¨agt diese ¨Uberpr ¨ufung fehl, wird eine Fehlermeldung mit der Identifikationsnummer ausgegeben und der Aussage, dass dieser Datensatz zu kurz ist.
3.2.3 Einsatz einer Stoppwortliste
In einem Titelfeld, k¨onnen W¨orter auftauchen, wie z. B. der, die, das, und, etc.
Diese W¨orter tragen nichts zum Titel bei, womit sie nicht beachtet werden sol-len. Dazu werden diese W¨orter im MAB2-Format in Nichtsortierzeichen (¬) ge-setzt und beim Sortieren somit ausgeschlossen. Meist sind dies Stoppw ¨orter, die entfernt werden k¨onnen, da sie sehr h¨aufig vorkommen oder keine Relevanz auf-weisen. In einer Stoppwortliste werden diese Stoppw ¨orter meist alphabetisch an-gegeben.
Diese Stoppw¨orter tauchen nicht nur im Titelfeld auf, sondern auch bei Per-sonennamen, wie z. B. ’Otto von Essen’, somit war dies Motivation genug, diese W¨orter innerhalb des Konvertierungsprogramms herauszufiltern. Da der gesam-te Feldinhalt vorhanden bleiben muss, wird ein weigesam-terer XML-Tag angelegt. Die-ser Tag beginnt mit Tagnamen des zu reinigenden Feldes und erh¨alt weiter den
Suffix normiert’ angeh¨angt. So w ¨urde z. B. aus dem Taggesamttitelnach Ent-fernen von Stoppw¨orterngesamttitel normiertwerden.
Auf den ersten Blick erscheint diese Abspeicherung redundant zu sein, al-lerdings spart sie kostbare Rechenzeit, da sie im Konvertierungsprogramm nur einmal durchlaufen werden muss. Eine Suchanfrage in diesen Feldern k ¨onnte die Bearbeitungszeit beschleunigen, da nur die relevanten W ¨orter in diesem Tag enthalten sind. W ¨urden diese Tags nicht redundant gespeichert, m ¨usste bei jeder Suche die Stoppwortentfernung bei jedem Tag durchgef ¨uhrt werden. Bei einer Suchanfrage muss die Stoppwortentfernung immer durchgef ¨uhrt werden, aber diese ist nicht allzu lang und kostet nicht viel Rechenzeit.
Die Stoppwortentfernung ist in der MethodehlpRemoveStopWordsder Basis-klasse implementiert. Damit diese Methode funktionieren kann, m ¨ussen zuerst einmal Stoppw¨orter bekannt sein. Diese werden aus einer Datei gelesen, deren Dateiname dem Konstruktor der Unterklassen ¨ubergeben werden kann. Das Ein-lesen der Stoppwortliste erfolgt in der MethodehlpCreateStopWordList, wobei dieser einen Dateinamen als Parameter ¨ubergeben wird. Diese Datei enth¨alt in jeder Zeile ein Stoppwort. Es ist sogar m ¨oglich, f ¨ur jede der vier MAB2-Dateien eine eigene Stoppwortliste zu verwenden.
Diese Liste wird in dem STL-Container Setgespeichert mit der Bezeichnung m setStopWordList. Dieser Container garantiert, dass jedes Element nur einmal enthalten ist. Bei einer Stoppwortliste ist es nicht maßgebend, wie oft ein Stopp-wort vorkommt, sondern nur dass es enthalten ist. Allerdings ist es sehr unwahr-scheinlich, dass ein Stoppwort mehrmals in einer solchen Liste vorkommt, trotz-dem ist es besser diesen Container als zus¨atzlichen Schutz zu benutzen. Da bei einem String-Vergleich zwischen Groß-und Kleinschreibung unterschieden wird, werden die eingelesenen Stoppw¨orter komplett in Großbuchstaben gespeichert.
Die Felder, auf die diese Stoppwortentfernung angewendet wird, werden eben-falls zum Vergleich in Großbuchstaben umgewandelt.
Beim Aufruf der MethodehlpRemoveStopWordswird als Argument ein String
¨ubergeben, aus dem dann die Stoppw¨orter entfernt werden sollen. Der R ¨uckga-bewert ist der bereinigte String, der nun keine Stoppw ¨orter mehr enth¨alt, falls dies vorher der Fall war. Enthielt der ¨ubergebene String keine Stoppw¨orter, so sind beide Strings identisch.
Diese Methode kann ¨uberall dort im Konvertierungsprogramm benutzt wer-den, an denen Stoppw¨orter entfernt werden m ¨ussen. Beim jetzigen Stand der Im-plementierung werden nur die Felder Gesamttitel und Personennamen auf diese Art bereinigt. Allerdings ist f ¨ur die Zukunft der Einsatz bei weiteren Feldern ge-plant.