[Allegro] Neues aus der allegroWerkstatt zum marcexport....

Mi Jan 27 13:08:16 CET 2021

[achtung: dieser Beitrag enthält viel Gedankenstränge, vielleicht viel zu viel für den einen oder anderen. aber versuche doch einer mal den gedankengängen zu folgen, vielleicht lohnt es sich ja?! kurz&schnellleser, die nur trumpsche tweets goutieren können oder mögen, werden hier mit diesem Beitrag keine Freude haben, sorry...]

Guten Tag allerseits,

Corona lässt einem viel Zeit! Mir zumindestens. Man kann sich "tiefliegenden" Projekten widmen. Immer tiefer nach Problemen und um deren Lösungsansätzen kümmern.
Nein, was die Bibliotheken angeht, sie haben (endlich?) Zeit, sich um ihre Bestände zu kümmern ;-)
Vor Corona wurde "reingekloppt", kostete es, was es wolle. Heute wird nachgedacht, und auch mal was geändert. Oder der Fachmann wird gerufen. 
Das mal nur so als flotte Vorrede....

Das Hauptthema (bei mir nur?) ist immer noch der marc-Export. seit 2015 arbeite ich daran.
============================================================
Und wer jetzt denkt, es sind die Abschiednehmer, die mich beauftragen, doch Ordnung in die Datenbank zu bringen, weil der empfangende Großkatalog (i.e. "Verbund") die Daten nicht annimmt [alles schon gehabt...], der irrt. 
Oder die andere Software: z.B.: koha. Ooooh das ist ein schlechtes Stichwort. Da muß ich gleich vom Leder ziehen.... auch die allegroWerkstatt geht mit der Zeit, obwohl sie sich heftig wert! ... koha.... versus VuFind. 
Ein "versus" ist OK. denn nur die OPAC-Funktion lässt sich vergleichen. koha bringt ja "alles" mit. 
trotzdem. allegronet.de betreibt inzwischen vufindnet.de und kohanet.de. 

meine server dafür sind schnell und können vieles gleichzeitig: 
-dutzende von allegro-kataloge anbieten

-5-7 vufind-discovery-kataloge auf vufindnet.de parallel zum laufen bringen. derzeit ist "nur" https://zfl.vufindnet.de/zfl aktuell. ein paar nicht öffentliche (besser !nicht! bekannte) vufinds laufen auch.

-aber koha? nee! das ist mehr oder weniger (erstmal) nicht akzeptabel. [achtung: ich sehe es von der serverbetreiberseite aus]. langsam! schwerfällig. gefällt mir gar nicht. die initialisierunsgroutine ist noch schlechter als die von vufind. trotzdem: eines ist sehr gut: die updatetechniken. z.b. "apt get update" ist ein execellenter vorgang! sehr sauber! sehr vorausschauend. auch was die abhängigkeiten angeht. execellent! vergleicht man dieses [bitte beachten: immer aus der sicht des serverbetreibers gesehen] mit vufind. uiiih. vufind ist eine "gemengelage" von dutzenden von kleinstprogrammen, die irgendwie zusammen [positiv zusehen!] passend gemacht wurden. aber wehe, demian (der chefentwickler) will auf eine neue php-version umsteigen. dann steigt alles um! dann geht gar nichts mehr. dann darf man wieder von neuem anfangen. wenn man mal ganz genau (sehr genau) hinschaut, bei den Deutschen... dann ist alles mehr oder weniger uralt! was die vufind-basisversion angeht. ich sach nur: neues php=neuer server, weil neuer kernel, weil neues clib. [über windowsserver kann und will ich nichts äußern]. und wer bei vufind stehenbleibt, viele kataloge existieren (ganz gut) mit der vufindversion2, sind aber definitiv nicht "updatebar". warum istz das thema "update" bei vufind so wichtig? ist gibt sehr oft neue entwicklungen, denen MUSS vufind folgen. unbedingt. auch wenn wir bibliothekare so "konservativ" sind (ja, ich liebe RAK mehr als errdeeaaah!)

weiter zu marc!
===============
auch nach 7 jahren entwicklung eines eigenen marcexportes ist einfach kein ende in sicht.
mittlerweile hat ein (weiterer) großverbund sich sehr positiv zu meinem exportverfahren geäußert.... es könnte sein, daß sich dieser endlich von seinem mab-gelöbnis verabschiedet und sich der "Annahme von Daten auf Basis von marc" zuwendet. mal sehen.
ich mache schon lange keine öffentlichen vergleiche mehr, nach dem motto "schickst du mir deinen allegro-katalog, und sage mir die größe deiner marc(mrk,mrc)export-datei, dann sage ich dir meine größe meines allegro-exportes auf basis meines exportverfahrens. der letzte vergleich war vor 1-2 jahren hier in dieser liste, und endete mit 5-10% zu ungunsten des originalallegro's. trotzdem: wer will, schicke mir seine allegro-ald's, nenne mir die größe seines marctxt.apr's Exportes, und wir diskutieren das nicht öffentlich weiter....
weiter:
was sind die stärken des allegronet-marc-exportes:
-ich mache die bibliotheken fit, um in den verbund mit marc zu kommen.

-es gibt kontrollmöglichkeiten auf einem eigenen nichtoffiziellen marc-katalog (nein, koha wird nicht genommen, ist viel zu viel murks, und NICHT WB basiert! ach, ist das niemandem aufgefallen? koha ist mehr für ÖB als für WB [ok: ich hoffe, ich irre mich...])

-es gibt testdatensätze, mit denen kann man ganz genau verfolgen, was kommt aus allegro in marc ganz genau wo an. es sind konkordanzdatensätze! auch für viele spezial "datensatz-arten": monographien, mehrbänder, reihen usw. natürlich sieht man auch, wo was in marc fehlt, obwohl es in allegro vorhanden ist! oooh, ich hoffe, daß die bibliotheken da einiges entdecken. niemand ist perfekt ;-)

-ich habe mal eine fussnoten-konkordanz erstellt.
    1. diese fussnoten werden in allegro angeboten, sind aber in marc NICHT unterbringbar
    2. lokale Eigenheiten: gilt nur für ZZZ. fussnoten sind korrekt besetzt, sind dann zu oben oder zu =59X zuordnen!
    3. diese fussnoten werden in marc angeboten! aber aus allegro NICHT beliefert
    4. Funktionierende Konkordanz! Diese Fussnoten werden 1:1 übersetzt und sind in marc untergekommen! Statistisch also nur jede DRITTE! ;-(

-was ich auch schmerzlich 2020 erleben musste: die variationen der (nicht die von Goldberg) "titel-arten". RAK hat sich da viel ausgedacht. marc auch. aber es wurde nicht zusammen gedacht. ich denke, mit meinen exportlösungen kommt fast alles(?) in die richtigen marc-felder...

-ein verbund kam pünktlich zum (sehr stillen) weihnachtsfeste mit der bitte, doch die mehrbänder besser zu beachten. genauer gesagt, die "unterbände". sie seien nicht genügend definiert, klassifiziert. ick guggte wie een karnikel aus dem ooofen? wat?
sie hatten recht. es hatte sich keiner 6 1/2 jahre lang beschwert: keiner der damaligen verbünde, keiner der vufind-online-kataloge. verflixt. da war ne bibliothek, die gestaltete ihre mehrbänder sehr großzügig und minimalistisch (ein widerspruch? ja, was aber so). (sehr) frei nach der allegro-devise: wir packen alles "nach oben", was allen gehört. "nach unten" kommt nur das, was den "unterband" betrifft.
tja, dann konnte "unterband sowieso" auch mal so aussehen:
#00 a01234+ 99 = Band 99
#99n20200231
das ist kein witz! aber ein konstruierter ;-)
ich übertreibe! ja.... aber sowas gibt es. und viel schlimmer: sowas kann ich auch nicht kontrollieren...(hat jemand evtl 1 idee?) seufz.
da hilft auch nichts, daß ich folgende zeile im orginalen export aus BS sehr gut und sinnvoll fand: 
marctxt.apr zeile 86
#u00 +- x"<3" e0    Saetze mit weniger als 3 Feldern ignorieren
autsch und schwupps ist der unterband weg! den jibbet nich mehr! hallo? 
wat tun? nach sehr langem überlegens und testens (1 woche) habe ich mir was ausgedacht. 
(wie sagte "alfred biolek: ich hab da mal vorbereitet") 
[wen das interessiert, also genauer das zitat! hier: https://www1.wdr.de/stichtag/stichtag6368.html )
dem leidenden leser sei versichert:  auch das bewältigt die allegroWerkstatt. allerdings nicht öffentlich.
das thema ist noch lange zu ende gedacht... da gibts noch mehr...

-eigentlich ein altes thema.. aber es macht immer wieder freude, darüber nachzudenken, wenn eine "neue" bibliothek kommt:
definieren sie mal ihre periodica! es bereite mir großes (!böses!) vergnügen, das mit den bibliotheken duchzudiskutieren. allegro hilft und da sehr wenig. will sagen: eine eindeutige aussage wie #40, das ist ein 1. verfasser [auch das ganze stimmt auch wieder nicht, wenn bedenkt, daß früher sowas erlaubt: #40 Mann, Thomas; Olsen, Egon; Lehmann, Icke (aaarggghh!) egal. kollateralschaden.
wer nennt mir das absolut eindeutige imemr zu vergebende kennzeichen(datenfeld) für ein periodica? ich gebe Ihnen, verehrter leser, gleich ein paar kennzeichEN(achtung: plural!)... [geduld]
vergessen wir nicht: in allegro konnten und können wir alles machen! allegro ist anarchistisch!
so, hier: [meine spitzzüngigen kommentare in []  ]

das folgende datenfeld betrachte ich als bestes kennzeichen: #00 z......
wir haben eine #00 mit "z" am anfang.
auch möglich: wir haben eine #00 mit "s" am anfang.
[autsch, ich kenne ne bibliothek, die holt sich was aus der zdb, da wird #00 zum inhalt "zdbn0000-x"]

die folgenden datenfelder sind auch nicht verkehrt, aber leider nicht immer zu 100% treffsicher!
der datensatz hat eine #88
[iss'n witz! ein sonderheft aus einer Zss als TA...]

der datensatz hat eine #76p
#76p    Erscheinungsverlauf, Angaben zur Erscheinungsweise (vor allem bei Zeitschriften, wie in ZDB)
hm. ja. bei mehrbändern wird da mal gerne geschrieben: 1977-1979

der datensatz hat eine #92
#92     Bestandsangabe
hm. ja. wird selten ausgefüllt. das verwechseln auch viele kollegen mit #93, #95, #96

der datensatz hat eine #98Z (mein lieblingsfeld!)
#89Z    ZDB-Nummer
hm. oh, wie oft habe ich eine korrekte ZDB-Nummer vorgefunden, wenn es eine monographie oder sonderheft war...

na, wem fällt noch was ein??? aufdiefolterspannend...
tätää
#8n bingo! (auf sächsisch: bingööchen; die betonung auf den beiden ö's ;-)
also wenn die #8n vorkommt, dann glaube ich das! -> "Das ist ein Periodicum!"
sie kommt aber eben ÖFTER weniger vor, als gedacht! merde!
[übrigens: ein verwandtes thema ist die "Loseblatt"...]
natürlich habe ich lösungen...

-Kopfzerbrechen schon in 2021
bibliotheken haben da auch schon mal ORDER oder ALF im einsatz.... wie ich kennenlerne musste
da gab es ne ganze menge datensätze mit "oberband-mehrband-infos" (ich nenne es mal so schwammig). aber es gab keine "echten" allegrounterbänder. ups?
aber es gab alf-oder-order-exemplardatensätze (auf dem bild rechts!)
das was auf dem links ist, ist nicht der originalzustand. der datensatz mit den "oberband-mehrband-infos" sah in allegro ganz passabel aus. in allegro wurde alles gefunden.
tscha. aber in marc NICHT!
ein bild sagt mehr als .... worte: http://allegronet.de/alf-order.jpg
mir ist es gelungen, für den export eine art "verbindenden" datensatz zu bauen, der EXTRA (also zusätzlich) in die datenbank eingefügt wird. damit er die korrekten (für marc) "zwischenbeziehungen" erzeugen kann.
der datensatz im bilde links zeigt, dass die exemplardatensätze der "alf-oder-order-exemplardatensätze" einen bezieung zu einander bekommen, und im marc zu sehen sind. als echte mehrbänder.
will sagen: in allegro fehlte etwas. es gab einen oberband und sagen wir mal einen exemplardatensatz (der aber nicht die inhaltliche qualität der unterband-TA hatte). es haben  unterbände gefehlt. also haben sie "im export-vorgang" nicht zueinander gefunden. mit dem trick, den ich versuche(!) hier zu präsentieren, ist die "familienzusammenführung" wieder geglückt.
will sagen numero2: ohne den neuen trick, hätten wir einen oberband, den jüdischen almanach, der einiges aussagt: z.b. die #00 mit z14493. aber keine infos über bände und deren sachtitel. und wir hätte jede(?) menge (fast!)leerer datensätze, die fast nix drin haben, außer den sachtitel (z.B. Sex & Crime) , der keine beziehung zu irgendwem hat. also einen elternlosen datensatz!
den trick zu erklären ist schwer. man muss mehrmals um die ecke denken. ich habe ne woche gebraucht! danke corona! ich hatte dafür zeit.
also, wenn SIE einen externen katalog haben, sie wissen, daß sie sogenannte "exemplardatensätze" haben (nach dem muster wie auf dem bild rechts!), dann haben sie wohl ein "familienzusammenführungsproblem". tja.
das problem ist prinzipiell gelöst. die querverrbindungen haben wir, man findet sich im marc-katalog. aber es wird noch hübscher aussehen !müssen! !
[nur zur verdeutlichung: die bibliothek hat !keinen! fehler gemacht! allegro hat ihr das erlaubt. aber wenn die datenbank auf die reise gehen muß: es kommt nicht sauber an. der export kann es definitiv nicht! aber ich habe ein verfahren entwickelt, das die so datensätze verbindet, daß marc damit was anfangen kann]

-das wo allegro immer mächtig drauf stolz ist, ist schon seit ca 6 1/2 jahren kein problem mehr:
Ihre (nichtimmereindeutigen) kürzel für reihen, ihre Stammdatensätze, ihre vielfältisten(sic) verknüpfungstechniken [um es mal ganz neutral auszudrücken], und all Ihre überlegungen, wie man sich in allegro das leben sehr leicht machen kann. es kommt alles brauchbar im export an! versprochen.

alles das frei nach dem motto: man kann in allegro alles machen. solange man in allegro bleibt. wer raus will/muss, bekommt probleme!
deshalb ist es so wichtig, daß ich mir lange, lange vor dem verbund, vor dem weggehenvonallegro die daten anschaue, daß wir zusammen(!) anfangen aufzuräumen, zu reparieren, zu korrigieren. also: intensivst zusammenarbeiten!

Was kann ich Ihnen anbieten?
============================
a. Schicken Sie mir bitte Ihre ald's (incl. api und cfg, letztere ist fast wichtiger als die api)

b. Ein erster Blick ist kostenlos mit Auskünften über die Exportmöglichkeiten

c. Ein zweiter Blick ist sehr aufwendig. Er ist nicht kostenlos. Sie bekommen einen externen nur für sie zugänglichen Internetkatalog (mit Passwort), wo sie sehen können, was los ist. Die einfachere Lösung wäre auch einen www-adresse, die nur für sie bekannt ist (Google wird sie nicht kennenlernen!) Es kann auch passieren, daß ich diesen externen Katalog gar nicht bauen kann, weil der export mit Ihren nicht manipulierten Daten nicht klappt. Das kenne ich leider nur zu gut.... dann müssen wir erstmal die Datenbank so "reparieren", daß sie exportfähig wird. achtung: "reparieren". ihr datenbank ist nicht kaputt. sie ist nur so, wie marc sie nicht gebrauchen kann.

d. Einen regelmäßigen Service: wöchentlich/monatlich bekomme ich die komplette Datenbank von Ihnen, schicke an genau definierte Verbünde einen marc-Export in 3 Varianten (mrk,mrc,xml).

e. wenn es sein muß, gestalte ich Ihre Datenbank für den letzten Export "lebensfähig", so daß nach menschlichem Ermessen alles ankommt, so daß Sie keine Verluste erleben, so daß Ihnen keine 5-10% der Inhalte fehlen.

f. die Frage "Warum bleiben sie nicht bei allegro?" sei mir gestattet! Die Konstruktion: allegro im Hause, draußen einen VuFind-Katalog. wat besseret jibbet nich!

viele 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-18: 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
* 2019: All for VuFind! The perfect export into marc21
* 2019: Neu: vufindnet.de. Ein großer Discovery-Katalog
* 2020: Neu: kohanet.de. Alternativen zu allegro-C und allegronet.de
* 2017-21: Exporte mit Marc. Es höret nimmer auf...