[Allegro] Was ist PROPY

Di Aug 25 14:01:04 CEST 2009

Lieber Herr Berger, liber Herr Eversberg,
die Ursprungsquelle ist für mich wirklich rätselhaft. Es sollte 
eigentlich eine BVB-Aufnahme sein, aber die sieht in Aleph ganz anders 
aus als in Zack. Aleph hat z.B. den Sammlungsvermerk überhaupt nicht, 
den muß Zack asu einer anderen Aufnahme heraus-"mergen". Hier das 
Aleph-Bild:

und so bei ZACK:

Man kann bei der Verfasserangabe sehen, wie aus < ...> die ärgerlichen 
typographischen Anführugnszeichen werden. Ich speichere tatsächlich in 
Latin1 ab, weil das für den Bearbeiter keine weiteren Klicks erfordert, 
es ist halt das, was Zack als Default anbietet. Dann wird mit einem 
Ableger der mab.aim zum Ostwestfond imporiert. In dieser Datei gibt es 
den Befehl "y .187 016   Pfeil nach rechts". Das muß ja dann wohl der 
Übeltäter sein. Da ich den bestimmt nicht erfunden habe: Welchen Zweck 
erfüllt der in den MAB-Parametern? Ich würde ihn natürlich am liebsten 
zu y .187 062  (d.h. >) ändern, mache ich da was kaputt?
Mit herzlichen Dank für die geduldigen Erklärungen,
Arno Mentzel-Reuters

Thomas Berger schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lieber Herr Mentzel-Reuters,
>
>   
>> 1) wie verhindert man, daß beim Einspielen aus ZACK die typographischen
>> Anführungszeichen (ANSI 171 « bzw. 187 » ) sich mit Codierungen aus dem
>> Ostwest-Font vermischen? Ich erhalte derzeit - möglicherweise wegen
>> einer veralteten Parameterdatei - Dinge wie
>> #21 Sammlung Êdt.►
>> Zumindest das Ê kann ich nicht einfach weg-ersetzen.
>>     
>
> da scheint einiges schief zu gehen, moeglicherweise schon in den
> Fremddaten. Leider verraten Sie nicht, die Daten welcher Quelle Sie
> in welchem Zeichensatz heruntergeladen haben:
>
> "<dt.>" waere korrekt / das erwartete, wie Sie ja auch schon bemerkt
> haben. "<<...>>" ist fuer einige eine Kruecke fuer die typographischen
> Steuerzeichen, fuer die Bibliotheksverbuende aber oft eine Eingabe-
> variante mit Steuerzeichenfunktion (Nichtsortierzeichen in Aleph?).
> Nicht auszuschliessen ist, dass irgendeine Datenbank zunaechst halben
> Unfug "<<dt.>>" liefert, der dann von ZACK beim Umwandlen eines
> Zeichensatzes in einen anderen zu "«dt.»" gemacht wird (ist serverseitig
> auch ein allegro-System beteiligt ;-)?
> Wie es der Zufall so will kennt der MAB2-Band-Zeichensatz ISO 5426
> die Quotierungszeichen ebenfalls und zwar an identischer Position:
> MAB-187 = Windows-187 ("»") und MAB-171 = Windows-171 ("«"). Am
> Beispiel ist also nicht entscheidbar, was Ihre Downloadcodierung in
> Zack gewesen ist.
>
> Die Tabelle o.apt mappt Windows-187 ("»") gegen DOS-16 ("►")
> und Windows-171 ("«") gegen DOS-210 ("Ê").
> (die Bedeutungen im Rahmen des Ostwest-Zeichensatzes sind natuerlich
> ganz andere als die hier sichtbaren Glyphen)
>
> Windows hingegen setzt Windows-187 ("»") mit DOS-175 ("»") gleich,
> und DOS-16 ist nicht abbildbar.
> Und Windows-171 ("«") wird identififziert mit DOS-174 ("«"), DOS-210
> hingegen entspricht Windows-202 ("Ê").
>
> Die Latin1->allegro-OSTWEST-Umsetzungen in z39.aim oder z39i.aim wuerden
> Windows-187 ("»") auf OSTWEST-220 abbilden ("▄"), das bedeutet Pfeil
> nach rechts, von o.apt gemappt auf Windows-129 ("", d.h. von Standard-
> Fonts nicht abbildbar)
> Und sie wuerden Windows-171 ("«") auf OSTWEST-174 ("«") abbilden,
> das bedeutet Z mit Hacek, das von o.apt auf Windows-219 ("Û") gebracht
> wird.
> [Die Umwandlung durch die Importschnittstellen ist also fragwuerdig
> bis falsch, hier scheint die Entwicklungsabteilung ueber ihren eigenen
> Zeichensatzwirrwar gestolpert zu sein. Die alternativen Exportparameter
> win-ad.apt hingegen wandeln die Zeichen in nette ASCII-Art "<<" und ">>" um,
> das scheint mir harmlos, ich persoenlich wuerde allerdings alle Arten
> doppelter Anfuehrungszeichen auf '"' abbilden und alle einfachen auf "'"]
>
> Also, plausibel scheint folgende Konstellation zu sein:
> A. Sie importieren sehr merkwuerdige Daten,
> B. und dies mit einer Schnittstelle, die eine Umwandlung allegro-Windows ->
>    allegro-Ostwest unternimmt (ggfls. ein Derivat von mab2cd.aim wo ich diese
>    Umsetzungen sehe), obwohl Windows-Latin -> allegro-Ostwest (wie in z39.aim)
>    angemessener waere, wenngleich auch fehlerbehaftet :-(
> [typographische Anfuehrungszeichen in MAB-Daten sind zwar nicht unbedingt
> verboten, aber extrem unueblich, und im (ebenfalls nicht sehr haeufigen)
> Sammlungsvermerk MAB 300 definitiv falsch, Spekulationen ueber die Mutation
> von "<...>" ueber "<<...>>" zu "«...»" habe ich ja oben bereits geaeussert.
> Ich glaube nicht, dass mab2cd.aim generell falsch umsetzt, die Schnittstelle
> ist fuer ein offizielles Produkt der DDB in einem inoffiziellen Zeichensatz
> gewesen, also an sich eine etwas fragwuerdige Konstruktion, leider ist sie
> dann wohl der unhinterfragte Ausgangspunkt fuer alle moeglichen Latin1-
> basierten MAB-Schnittstellen gewesen]
>
> Mein Rat ist ansonsten uebrigens, wenn man schon mit allegro-OSTWEST arbeitet,
> also einem "bibliothekarischen" Zeichensatz, dann sollte man ZACK-Daten
> nicht als Latin-1 importieren sondern im ebenfalls bibliothekarischen
> ISO 5426 (vulgo MAB- oder UNIMARC-Zeichensatz).
>
> viele Gruesse
> Thomas Berger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQCVAwUBSpO0NGITJZieluOzAQK5UAP9E358ZtFZDw/Rmpx3Nq5fUer7jqTk+T/S
> 4NcTsWoXqo+od7xMzpMhRXnle+HT1Xv1iSrt0iCw1fh997tX8/s6Q2K+Q104kaxj
> dwMrknLn6WmbZAbaSoawetf3jq86tQ0m8aJnGs/gLMUu5AYAOnGCTUr3M+W6emWn
> mJLkpGIikhg=
> =vuFo
> -----END PGP SIGNATURE-----
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20090825/8e516453/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : moz-screenshot.jpg
Dateityp    : image/jpeg
Dateigröße  : 116797 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20090825/8e516453/attachment.jpg>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : moz-screenshot-1.jpg
Dateityp    : image/jpeg
Dateigröße  : 108425 bytes
Beschreibung: nicht verfügbar
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20090825/8e516453/attachment-0001.jpg>