allegro-Homepage http://www.allegro-b.de allegro-C
BlueChyp
V27.2
BlueChyp
Neuer- und Verbesserungen

7. Mai 2007







Mehr zu den Themen:


 

Import mit FLEX

 

Zwar bleiben die bekannten Importfunktionen mit dem DOS-Programm IMPORT.EXE voll erhalten, aber die FLEX-Sprache bietet ab V27.2 alle Möglichkeiten, die man für einfache Datenkonvertierungen braucht. Zwei Dinge sind es vor allem, die man können muß, um Fremddaten umzuwandeln
  • Daten einlesen aus einer Datei, und zwar immer einen Datensatz als Ganzes. Entscheidend ist dazu die Fähigkeit, in der Fremddatei fortlaufend zu lesen, bis eine charakteristische Zeichenkombination gefunden wird, die das Ende eines Satzes oder den Beginn des nächsten markiert. Das muß auch dann funktionieren, wenn es keine Zeilenstruktur gibt - typisch für manche Fremddatenquellen. 

        Der Befehl   fetch eN   kann dies.

         Beispiel: Die Sätze sind durch zwei Leerzeilen getrennt, das entspricht einer Zeichenkombination 13 10 13 10.

         Man schreibt dann:

         var 13 10 13 10

      fetch e4

      ins #uzy

        und es wird alles eingelesen bis zum nächsten Auftreten dieser Kombination aus 4 Zeichen. Der eingelesene Satz wird als Ganzes kopiert in #uzy zur weiteren Verwendung.

  

  • Datenfelder herausziehen aus dem Fremdsatz mit Hilfe der Manipulationsbefehle und in eigene Felder kopieren. Häufig braucht man dazu Ersetzungen von Zeichenfolgen durch andere sowie Umwandlung von Einzelzeichen über Tabellen. Die dazu nötigen Fähigkeiten sind jetzt alle vorhanden; neu hinzugekommen ist der Befehl   xcode , mit dem auch die früheren Import-Protypenersetzungen möglich sind. Mit den neuen Befehlen p und y (wie in den alten Importparametern) kann man die Zeichenumwandlungen definieren.

         Beispiel: Das Feld "Verlag" befindet sich in den Fremddaten im Feld 260 und beginnt mit $b, endet mit $c

Man schreibt dann, wenn man vorher den ganzen Fremddsatz wie oben eingelesen hat:

         var #uzy(b"260 " b"$b" e"$c")

      ins #75

         und es wird der Inhalt des Fremdfeldes isoliert und in #75 kopiert.

         In den Importparametern hätte man dasselbe so ausgedrückt:

      #75

      s "260 "

      b"$b"

      e"$c"

 

Hier werden nun zwei Fälle dargestellt, in denen die FLEX-Technik neue Leistungen erbringt, und das ganz ohne Importparameter. Der  Fall 2  ist noch schneller und direkter!

 

1. Der Fall OHIOLINK

Als Beispiel kann der Fall von MARC-Daten dienen, wie man sie aus dem System OHIOLINK, einem sehr großen Zentralkatalog, leicht kopieren kann. Sie können sofort per ISBN selber einen solchen Satz  original aus OHIO abrufen ! Es erscheint ein JanaS-Fenster, in dem der Datensatz mit MARC-Nummern zu sehen ist. Achtung: Wenn das System den richtigen Datensatz nicht hat, kommt ein anderer, in der Regel unpassender, bei dem ein Anfangsteil der ISBN übereinstimmt.)

Dann:

1. Mit der Maus den ganzen MARC-Satz markieren, mit Alt+c in die Zwischenablage kopieren

2. JanaS/Fenster verlassen, in dieses Anzeigefeld klicken, hintereinander Alt+a und Alt+v  

         Der MARC-Satz erscheint. Auf Wunsch kann man mehrere Datensätze untereinander einkopieren. Dann:

3. Im Schreibfeld  X ohio  eingeben. Anzeigefeld wird verarbeitet.

 

Anschließend hat man den umgewandelten Satz so vor sich, als hätte man ihn selber eingegeben.

Der Datensatz ist aber noch nicht gespeichert, d.h. man kann vorher noch ändern oder löschen.

Der FLEX ohio.flx liest in einer Schleife jeweils einen Abschnitt bis zum nächsten "LEADER" und macht aus den so eingelesenen Daten einen allegro-Datensatz. Diese Datensätze kommen in den Offline-Speicher und können dann mit Alt+q besichtigt werden.

Besonders attraktiv bei den Ohio-Daten ist, daß in vielen Sätzen die Inhaltsverzeichnisse der Bücher enthalten sind! Das gibt es bei keiner anderen Datenbank, und hier bekommt man sie nicht als PDF, sondern als strukturierte Texte in der wiederholbaren MARC-Kategorie 970.

 

So sehen diese Daten aus:

 

LEADER 00000pam  2200000 a 4500

001    30811572

003    OCoLC

005    19950423121748.0

008    940630s1995    nyu           000 1 eng  

010    94027510

020    0449225550

040    DLC|cDLC|dndc/sfd

043    e-uk-en

050 00 PR6058.O912|bA63 1996

100 1  Howatch, Susan.

245 10 Absolute truths /|cby Susan Howatch.

250    1st Ballantine Books domestic ed.

260    New York :|bFawcett Crest,|c1996.

300    624 p. ;|c18 cm.

610 20 Church of England|zEngland|xClergy|xFiction.

650  0 Cathedrals|zEngland|xFiction.

650  0 Bishops|zEngland|xFiction.

 

LEADER 00000pam  2200000 a 4500

001    9066419

008    821119s1982    caua     b    000 0 eng  

010    82022697

020    0913890545 (pbk.) :

020    |z093179045X (pbk.)

040    DLC|cDLC|dKSU

050 0  TJ163.2|b.T656 1982

082 0  333.79|219

245 00 Tools for the soft path /|cby the International Project

       for Soft Energy Paths ; Jim Harding ... [et al.]

260    San Francisco :|bFriends of the Earth,|cc1982

300    288 p. :|bill. ;|c28 cm

504    Includes bibliographical references

650  0 Power resources

650  0 Energy conservation

650  0 Energy policy

700 10 Harding, Jim

710 20 International Project for Soft Energy Paths

 

LEADER 00000pam  2200000 a 4500

001    40964731

003    OCoLC

005    19991025121013.0

008    990223s1999    gw a     b    101 0 eng  

010    99020159

020    3540657029 (acid-free paper)

040    DLC|cDLC|dOHX|dC#P|dCWR

050 00 QB843.E2|bI28 1998

072  7 QB|2lcco

082 00 523.8/8|221

111 2  IAU Colloquium|n(169th :|d1998 :|cHeidelberg, Germany)

245 10 Variable and non-spherical stellar winds in luminous hot

       stars :|bproceedings of the IAU Colloquium no. 169, held

       in Heidelberg, Germany, 15-19 June 1998 /|cB. Wolf, O.

       Stahl, A.W. Fullerton (Eds.)

260    Berlin ;|aNew York :|bSpringer,|cc1999

300    xx, 424 p. :|bill. ;|c24 cm

440  0 Lecture notes in physics,|x0075-8450 ;|v523

504    Includes bibliographical references and index

650  0 Early stars|vCongresses

650  0 Stellar winds|vCongresses

700 1  Wolf, B.|q(Bernhard),|d1935-

700 1  Stahl, O.|q(Otmar),|d1955-

700 1  Fullerton, Alexander W.,|d1959-

970 11 |tObject Index|p423

970 21 |tRotationally Modulated Winds of O Stars|cAlex W.

       Fullerton|fFullerton, Alexander W., 1959-|p3

970 21 |tRotationally Modulated Winds of BA-Type Supergiants

       |cAndreas Kaufer|fKaufer, Andreas|p11

970 21 |tUsing Spectropolarimetry to Determine Envelope Geometry

       and Test Variability Models for Hot Star Circumstellar

       Envelopes|cKaren S. Bjorkman|fBjorkman, Karen S.|p19

...  und noch viele weitere solche Felder

970 21 |tConference Summary: The Demise of Spherical and

       Stationary Winds|cImmo Appenzeller|fAppenzeller, I. (Immo),

       1940-|p416

971    |d19990923

 

 

Die Zeichenfolge am Satzanfang ist LEADER. Das Lesen bis zum nächsten LEADER sieht in FLEX so aus:

 

var "LEADER"   // damit fängt jeder Satz an!

fetch e6       // Daten lesen bis zu dieser Zeichenfolge

 

Danach steht der Datensatz in der iV bereit. Zweckmäßig ist, ihn zuerst in eine #u-Variable zu kopieren, z.B. #uzz.

Durch diese Syntax wird es auch ganz einfach, Steuerzeichenfolgen als Begrenzung vorzugeben. Wenn etwa das Satzende durch die Sequenz  13 10 13 10 (zwei Leerzeilen) gekennzeichnet ist, dann:

var 13 10 13 10

fetch e4

 

=======================================================

 

2. zDirect : Die Direktabfrage über Z39.50

Gut und schön, wird man sagen, aber muß das so umständlich sein? Es gibt Protokolle, mit denen man solche Sachen automatisieren können sollte, wie es ja auch EndNote u.a. tun. Das ist wahr, aber ausgerechnet OHIOLINK hat keinen Z39.50-Service, deshalb wurde die oben beschriebene Methode erdacht. Die Library of Congress dagegen und MELVYL (ebenfalls ein großer Zentralkatalog) haben einen, desgl. der GBV, der SWD, HEBIS und ein paar andere. Und dafür gibt es ab V27.2 eine noch schnellere Methodik. Mitgeliefert werden dafür zwei neue Module: zc.exe und z39.dll. Sie beruhen auf der YAZ-Softwarebibliothek (Open Source). Das Programm zc.exe kann in einem Zuge von mehreren Servern quasi gleichzeitig per ISBN Sätze abrufen und diese dann in eine Datei schreiben. Ein FLEX kann das Programm zc.exe starten und dann sofort die Ergebnisdatei einlesen und umwandeln. Meistens dauert das nur wenige Sekunden je Server.

 

Nutzung

·         Will man die Funktion routinemäßig sehr oft nutzen, legt man sie am besten auf einen Flip-Button und schreibt in die Datei _start.flx diese Zeile:

      flip 3&3: ZDirect=X zc

 

·         Zur gelegentlichen Nutzung gibt man ein:  X zc.  Der Aufruf des Programms  zc.exe  ist darin eingebaut.

 

·         Will man gelegentlich unterschiedliche Server einzeln nutzen, macht man sich Kopien von zc.flx und aktiviert darin die Zeilen für die betreffenden Server. Dann ruft man diese FLEXe selektiv auf, z.B. mit  X zc2 .

 

Was steckt dahinter?

Der FLEX für die Z39-Suche heißt   zc.flx  (Z-Client). Darin steht eine  Liste der Server , die abzufragen sind. Die Einträge dieser Liste haben eine festgelegte Form. In derselben Form kann man dort weitere Einträge für andere Server anlegen. Eine Serverzeile sieht so aus:

wri ' UBBS;usmarc ubsun02.biblio.etc.tu-bs.de:2020/opac'  // UB BS

Die Kommentare in zc.flx erklären alles weitere.

Eingebunden wird z39m.inc, darin werden die Suchergebnisse dann umgewandelt und in den Arbeitsspeicher geholt. Im Anzeigefeld erscheinen alle gefundenen Sätze schon gleich in der umgewandelten Form. Die Originalform kann man sich mit  h zilist  zeigen lassen.

In  z39m.inc  steckt das Unterprogramm :z39m, welches die eigentliche Arbeit macht. Wenn man die Umwandlung verbessern will, muß man nur in diese Datei eingreifen. Auch diese Umwandlung kommt ohne Importparameter aus, es wird alles mit FLEX gemacht.

 

Ablauf:

zc.flx: nimmt ISBN vom Nutzer entgegen, setzt damit einen Aufruf von zc.exe zusammen und startet diesen dann

==> zc.exe fragt die Server ab und schreibt die Ergebnisse in Datei zilist

         ==> zc.flx startet Unterprogramm :z39m (in z39m.inc)

                   ==> Unterprogramm liest zilist und holt die Daten in den Arbeitsspeicher

 

Was ist zu tun?

... wenn man zDirect für eine eigene, Nichtstandard-Datenbank nutzen will? Nur das Unterprogramm z39m.inc ist spezifisch für das Zielformat. Ausgeliefert werden zwei Versionen: eine für das A-Format (DOS-Code), die zweite für das N-Format (ANSI-Code). Man kopiert die passende z39m.inc am besten in das eigene Datenverzeichnis und kann es dort frei modifizieren. Dabei braucht man sich nur um die Datenfelder zu kümmern, also hauptsächlich die Feldnummern durch die eigenen zu ersetzen, alle anderen Probleme der Umwandlung sind in zc.flx erledigt.

Die größte Besonderheit ist: Es werden Daten aus unterschiedlichen Quellen umgewandelt, die sich im Format und sogar in der Zeichencodierung unterscheiden. Im Falle der DNB bekommt man keine MARC-Daten, sondern ISBD! Und im Falle der polnischen Nationalbibliothek sind es Unicode-Daten, beim GBV und DNB unterschiedliche ANSI-Codierungen. Wichtig sind dabei die neuen Möglichkeiten der  Umcodierung:

 

Zeichenumcodierung über Tabellen

Grundprinzip ist, daß der momentane Text in der internen Variablen mit Hilfe einer Tabelle umcodiert wird. Es gibt bei den classico-Programmen zwei Arten der tabellengesteuerten Umcodierung, die beim Export bzw. beim Import zum Einsatz kommen. Beide Arten können ab V27.2 auch in a99 verwendet werden.

 

A. Exporttabellen

 

xcode ab        avanti    (ab V27)

Codiere den in der iV stehenden Text um, und zwar mit der Tabelle p bzw. q

Das ist auch ein Testbefehl für Experten, zum Testen der diversen Umcodiertabellen!

Folgende Werte kann man setzen:

 

a = i d x         Index-, Display-, Exportparameter, und darin:

Hinweis: Für  avanti  gelten nur i und x

 

b = p q               p- bzw. q-Tabelle

Anschließend steht in der iV der entsprechend umcodierte Text.

 

 

B. Importtabellen

 

Ab V27.2 gibt es noch weitere Möglichkeiten, Umcodierungen vorzunehmen. Diese sind besonders hilfreich beim Einlesen von  Fremddaten , die ja nicht selten anders codiert sind, als man es braucht. Es wird keine Import-Parameterdatei herangezogen, aber deren Technik wird genau nachgebildet (siehe Handbuch Kap.11.2.2 ).

 

xcode y      [dahinter kommt weiter gar nichts!]

Zur Umcodierung wird eine Tabelle benutzt, die man vorher mit Hilfsbefehlen der Form 

y x ... und  p x ...  

anlegen kann.

 

Die Hilfsbefehle gelten alle für die gesamte Sitzung, müssen also nicht in jedem FLEX erneut gegeben werden. Sie sehen folgendermaßen aus:

 

y x u 

Ersetzt beim Befehl  xcode y  jedes x durch ein  u.

Beispiel:  y A a  : ersetzt das große A durch das kleine

 

y a/z A 

Ersetzt beim Befehl  xcode y  jedes a durch ein  A., jedes b durch ein B usw.

Damit kann man ganze Zeichenfolgen mit einem Befehl definieren, falls es sich um aufeinanderfolgende Zeichen handelt.

 

y a/z =A 

Ersetzt beim Befehl  xcode y  jedes a durch ein  A., jedes b  auch durch ein A usw.

Damit kann man ganze Zeichenfolgen in denselben Code umwandeln.

 

y .nnn mmm 

Diese Variante ersetzt beim Befehl  xcode y  jeden Dezimalcode nnn durch den Code mmm.

Sonderfall: 256 an der Stelle von mmm bedeutet: Code nnn ignorieren.

Beispiel:  y .13 32   bzw.  y .13 256  : ersetzt Code 13 durch das Leerzeichen bzw. beseitigt ihn ersatzlos.

 

p x abc ABC 

Sog. Protyp-Ersetzungen. Damit kann man Doppelcodes ersetzen: wenn xa auftritt, wird es durch A ersetzt, xa dagegen durch B usw. Solche Codierungen treten z.B. in MARC-Daten auf, auch wenn diese per Z39 zum Zweck des Imports gewonnen werden.

 

 

Hinweise:

1. Eine andere Art der Umcodierung macht man mit den Befehlen  asci/ansi . Dabei werden die umkehrbaren o-Tabellen benutzt, die in die Anzeige- oder Indexparameter eingebunden sind. Normalerweise ist dies die Tabelle o.apt.

2. Wenn man oft mit dem write-Befehl Daten ausgibt, ist es bequemer, die automatisch Umcodierung mit  exp wX  einzuschalten.  Vorher die geeigneten Exportparameter laden!

3. Für die Umwandlung von  Unicode-Daten  in den Standard-DOS-Code gibt es eine weitere Methodik: sie arbeitet mit einer Tabelle, die man mit u-Befehlen in die Indexparameter einbaut. Eine komplette Liste findet man in der Datei   ucodes.apt .

 

Beispiel:

In den Exportparametern sind p-Umcodierbefehle für ASCII -> UTF-8. Wenn nun ein Text in #uxy steht und in UTF-8 umzuwandeln ist, macht man das so:

var #uxy

xco xp

ins #uxy

 

 

 


http://www.allegro-c.de/bluechyp/



Bernhard Eversberg, UB Braunschweig 2007-05-03