[Allegro] marctxt.apr (neue lesbare Version) -ergänzungen&fragen&korrekturen

Mo Feb 26 16:35:30 CET 2018

Guten Tag Herr Eversberg,
danke für Ihre Nachricht.
Am Montag, 26. Februar 2018 um 08:45 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

>> Gesendet: Donnerstag, 22. Februar 2018 um 11:59 Uhr
>> Von: "Klaus Lehmann" <lehmann_klaus at t-online.de>
>> ich stifte an allegro-C diese neue fassung der marctxt.apr.
>> sie soll bitte die alte version von dez2017 ersetzen.
>> 
> Es handelt sich zuerst einmal um eine Überarbeitung im Sinne einer
> Vereinfachung und mehr Transparenz - wie es schon vorab diskutiert wurde.
> (Das Attribut "lesbar" kann irreführen - tiefgehende Kenntnisse
> sind allemal unverzichtbar. Warum die Verständlichkeit zu wünschen übrig
> ließ, wurde mehrfach begründet. Der Grund ist entfallen, nur deshalb
> *konnte* man jetzt vereinfachen.)

> Funktionale Verbesserungen bietet Lehmanns neue Variante (!) noch nicht, das
> wird weiteren Schritten vorbehalten bleiben. (Daher ist die Bezeichnung "neue
> Version" unzutreffend - nach Fehlerbereinigung leistet sie dasselbe wie die alte)

> Verdienstvoll wie man es denn doch nennen muß, so einen ersten Schritt zu tun,
> denn das ist wirklich Arbeit, ist dieser gleichwohl nicht fehlerfrei gelungen:

> 1. In diesem Abschnitt:
> ...
>   control nr
> #t{ "=001  " }
> #00 +#990 e"=" ,"_x_X_" P12
> ...

> stand P11 statt P12, was dazu führte, daß Feld 008
> ohne neue Zeile auf Feld 001 folgte. Andere Vorkommnisse
> des Zwischenteils 11 waren mit #t11 angegeben gewesen, und
> Lehmann hatte #t12 draus gemacht. Dieses Vorkommnis von P11 
> war wohl einfach übersehen worden.
je weniger Ersetzer vorhanden sind, desto weniger Missverständnisse
(meinerseits). ich danke sehr!

> 2. Ferner entstanden zwischen zwei Sätzen immer zwei Leerzeilen,
> was vielleicht mal problematisch sein könnte. Behoben.
ja, marc oder wer auch immer, können da extremst zickig sein! ;-(

> 3. An vielen Stellen stand jetzt so etwas wie P{ t12 } oder #t{ t12 }.
> Das kann mal im Zusammenhang mit Zeilenvorschueben problematisch sein
> (s. 2.) und es ist auch nicht gut "lesbar", besser ist P12 bzw. #t12. 
> Alle Vorkommnisse sind begradigt.
wirklich?

ich habe ihnen geliefert:
#t{ "=090  \\$a[mehrbändig! Sign. s. bei den Bänden]" t12 }     HIER fehlte t12 }   2018/02
vorne mit { und hinten mit }

sie schreiben wie in der alten version:
#t{ "=090  \\$a[mehrbändig! Sign. s. bei den Bänden]" t12
vorne ist ein {  , aber hinten nicht!
hinten ist t12, was sie wohl als problemtsisch ansehen, und eigentlich
müsste nach ihrer aussage es so aussehen:
#t{ "=090  \\$a[mehrbändig! Sign. s. bei den Bänden]" } P12

können sie mir bitte das bestätigen?
das wäre nett.
weil ich verstehe es einfach nicht!

und was ist falsch (es ist einfach NUR meine denke!) an der benutzung
von: P{ t12 } oder #t{ t12 }
warum habe ich zuschreiben P12 bzw. #t12 ????

frage: benutzt man nicht die geschweiften klammern, wenn man mehr als
einen ausdruck hinten oder vorne anbringen will?
und wenn es nur ERIN ausdruck ist, tut doch die gescxhweifte klammer
nicht weh? ODER: WANN tut sie nun weh? weil: sie schreiben oben: "Das
kann mal im Zusammenhang" .....

mir ging es hauptsächlich um eine vereinheitlichte schreibweise!
übersehen habe ich in den zeilen 512-5145:
#91 y1 p"$i"
#92 y1 p"$h" 
#96 y1 p"$e"
#97 y1 p"$e"

wiso taucht hier p"$i" auf????
ich denke wie haben die (fürchterlichen ersetzer?)
also für p"$i" wird t/p/P73 genommen.
himmel, es sollte docjh einheitlich sein!
???

[meine denke]
MEIN kopf MUSS in einer tabelle nachschauen, was das bescheuerte 73
soll. dann bekommt mein kopf so" a la meng" gesagt: es das subfeld $i.
ja, krutzi&türkistan, warum kann ich es nicht GLEICH so schreiben?
warum BEMECKERE ich das so streng? ein beispiel: suche ich "73", darf
ich "$i" nicht vergessen auch zu suchen, wenn ich herausbekommen will, wieviele
subfelder auf "i" hören!
ich das wirklich so schwer zu verstehen?
[meine denke-ende]

> 4. Kein Fehler, aber untunlich: Saloppe Schreib- und Ausdrucksweisen

es stand deutlichst in meiner email, daß dieses "weg könne".
z.b. auch der immer noch vorhandene kommentar (es war ein denksanstoß)
auf den zeilen 28-30.
das denken wurde angestossen. ich bin erleichtert: 13 und 19 sind
perdue. danke. ganz. große klasse

> Vorerst also bringt die Umstellung noch keine Veränder- oder -besserung
> der Ergebnisse, d.h. wer sich für den Text der Datei sowieso nicht
> interessiert, braucht sie noch nicht. Wer aber mitmachen will bei
> weiteren, nunmehr echten Verbesserungen, ist willkommen, und sei
ja. ich werde auch dabei sein! aber alles zu seiner zeit.

> es auch nur mit Anregungen, die sich aus konkreter Erfahrung ergeben und
> die man für die Allgemeinheit umsetzen sollte. Wenn jemand selber
> echte Verbesserungen einbringen könnte, wär das natürlich super.

nunja. echte verbesserungen sind eben nicht drin!
das wird hoffentlich später kommen ;-)

danke und grüße,
ihr klaus lehmann

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011-12:  Sponsor: Peter-Sodann-Bibliothek+IFLA:allegro-utf8
* 2013-14: Bolero 64bit.+allegro-zdb: endlich. + eBooks
* 2015-16: allegro-vufind.+ allegro-imd.Die weltgrößte(?) Filmdatenbank
* 2017-18: Exporte. Marc und Co.  Marc ist sehr different
Lesen Sie auf http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene Meinung! Lesen Sie!

Am Montag, 26. Februar 2018 um 08:45 schrieben Sie:
>> Gesendet: Donnerstag, 22. Februar 2018 um 11:59 Uhr
>> Von: "Klaus Lehmann" <lehmann_klaus at t-online.de>
>> 
>> ich stifte an allegro-C diese neue fassung der marctxt.apr.
>> sie soll bitte die alte version von dez2017 ersetzen.
>> 

> Kurzurlaubsbedingt ergibt sich erst heute Gelegenheit zu Würdigung und
> Stellungnahme.

> Es handelt sich zuerst einmal um eine Überarbeitung im Sinne einer
> Vereinfachung und mehr Transparenz - wie es schon vorab diskutiert wurde.
> (Das Attribut "lesbar" kann irreführen - tiefgehende Kenntnisse
> sind allemal unverzichtbar. Warum die Verständlichkeit zu wünschen übrig
> ließ, wurde mehrfach begründet. Der Grund ist entfallen, nur deshalb
> *konnte* man jetzt vereinfachen.)

> Funktionale Verbesserungen bietet Lehmanns neue Variante (!) noch nicht, das
> wird weiteren Schritten vorbehalten bleiben. (Daher ist die Bezeichnung "neue
> Version" unzutreffend - nach Fehlerbereinigung leistet sie dasselbe wie die alte)

> Verdienstvoll wie man es denn doch nennen muß, so einen ersten Schritt zu tun,
> denn das ist wirklich Arbeit, ist dieser gleichwohl nicht fehlerfrei gelungen:

> 1. In diesem Abschnitt:
> ...
>   control nr
> #t{ "=001  " }
> #00 +#990 e"=" ,"_x_X_" P12
> ...

> stand P11 statt P12, was dazu führte, daß Feld 008
> ohne neue Zeile auf Feld 001 folgte. Andere Vorkommnisse
> des Zwischenteils 11 waren mit #t11 angegeben gewesen, und
> Lehmann hatte #t12 draus gemacht. Dieses Vorkommnis von P11 
> war wohl einfach übersehen worden.

> 2. Ferner entstanden zwischen zwei Sätzen immer zwei Leerzeilen,
> was vielleicht mal problematisch sein könnte. Behoben.

> 3. An vielen Stellen stand jetzt so etwas wie P{ t12 } oder #t{ t12 }.
> Das kann mal im Zusammenhang mit Zeilenvorschueben problematisch sein
> (s. 2.) und es ist auch nicht gut "lesbar", besser ist P12 bzw. #t12. 
> Alle Vorkommnisse sind begradigt.

> 4. Kein Fehler, aber untunlich: Saloppe Schreib- und Ausdrucksweisen
> in einigen Kommentaren. Unter uns Insidern läßt sich damit leben,
> aber diese Art von Dateien könnte auch mal von kritischen Geistern
> gesichtet werden, die uns nicht kennen. Da machen solche Dinge sich
> nicht gut. Es handelte sich jedoch nur um Kommentare, die nicht
> auf Dauer drin zu bleiben brauchen, daher habe ich einige ausradiert.
> Worum's geht, ist ja ein durchaus ernstes Ziel: Weitere Annäherung
> an den offiziellen Globalisierungsstandard MARC21, der aus dieser
> seiner Rolle wohl auch nicht sehr bald entlassen oder verdrängt werden wird.

> Vorerst also bringt die Umstellung noch keine Veränder- oder -besserung
> der Ergebnisse, d.h. wer sich für den Text der Datei sowieso nicht
> interessiert, braucht sie noch nicht. Wer aber mitmachen will bei
> weiteren, nunmehr echten Verbesserungen, ist willkommen, und sei
> es auch nur mit Anregungen, die sich aus konkreter Erfahrung ergeben und
> die man für die Allgemeinheit umsetzen sollte. Wenn jemand selber
> echte Verbesserungen einbringen könnte, wär das natürlich super.

> Für Interessenten ist der bereinigte Text verfügbar:  X gf marctxt.apr

> Zum Schluß nochmal der Tip:
> Geben Sie in a99 ein:  x dis p marctxt
> dann sehen Sie danach die Datensätze im .mrk-Format, so wie sie mit den
> Parametern marctxt.apr exportiert werden.
> Dasselbe kann man mit allen Exportparametern machen, wodurch das Testen
> sehr erleichtert wird - man muß nicht jedesmal zuerst echt was exportieren und
> dann die Datei inspizieren.

> B.E.

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro