[Allegro] Quellensituation und Zukunftsfähigkeit -> bibframe

Mo Jan 12 13:09:32 CET 2015

zu bibframe gibt es eine relative aktuelle info (nov.2014)
quelle: 
http://www.dnb.de/DE/Wir/Kooperation/AGVerbundsysteme/berichtSitzung67Frankfurt.html
bitte klicken auf Kurzbericht aus der 67. Sitzung der AG Verbund

BIBFRAME
Die Bibliographic Framework Initiative hat bei der Annual Conference der American Library
Association
einen spürbaren Schub erfahren
.
Neben Skepsis und Bedenken waren dort aber auch
die Offenheit und die Bereitschaft zu spüren, bei der Erschließung und Bereitstellung von
Informationen die neuen Gegebenheiten des Internets
zu berücksichtigen und an derWeiter
entwicklung von BIBFRAME mitzuwirken. So hat das "Program for Cooperative Cataloging"
bereits für dieses frühe Stadium angekündigt, sich gemeinsam mit der Library of Congress aktiv
und prominent an BIBFRAME und dessen Einführung zu beteiligen, eine erste testweise
Katalogisierung in BIBFRAME ist für 2015 vorgesehen. Das Verhältnis zwischen RDA und BIBFRAME
bleibt dabei ein interessantes und wichtiges Thema.

> 3. Wird allegro Schritt halten mit dem neuen Umfeld RDA+BIBFRAME?
>     (Betrifft nur die normale Anwendung "Katalogisierung", und auch
>     diese nur, soweit RDA-Konformität gewünscht ist.)
>     RDA ist kein wirkliches Problem! Man kriegt nur hier und da neue
>     Uneinheitlichkeiten in den Fremddaten, aber davon gibt's ja immer
>     schon eine Menge.
>     BIBFRAME? Experten reden jetzt von 10 Jahren, bevor es ernsthaft,
>     also auf breiter Basis, MARC ablösen kann.
>     Das würde zu A.2. passen! Denn zwar nicht BIBFRAME selbst, aber die
>     damit verbundenen Erwartungen und Ansprüche werden ganz andersartige
>     Systeme fordern und diese werden entstehen. *Vorher* schon allegro
>     abzulösen durch etwas anderes, was *jetzt* schon existiert, das
>     ergibt deshalb wenig Sinn - es sei denn, andere Gründe als einfach
>     nur Zweifel an allegro sprechen für eine vorzeitige Ablösung, etwa
>     ein Verbundbeitritt. Denn man würde sich sonst nur auf eine anders-
>     artige Zwischenlösung einlassen, deren Tage gleichfalls schon
>     gezählt sind.

gruß k.l.

-- 
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: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Montag, 12. Januar 2015 um 09:03 schrieben Sie:

> Neben der Vorbereitung einer V35.1 kuemmern wir uns momentan um eine
> weitere und sehr notwendige Verbesserung der Quellensituation, d.h.
> der C++-Programme.

> Dazu und zur Frage der Zukunftsfähigkeit von allegro ein paar plakative
> Anmerkungen. Zeit für eine längere Abhandlung ist gerade nicht, aber
> zum Lesen einer solchen vielleicht auch nicht.

> Jede Software, die nicht sofort perfekt ist, also jede, wird
> irgendwann revisionsbedürftig. Das haben wir 1985 erlebt, als wir
> auf eine ganz andere Programmierplattform wechseln mußten (von
> Basic + Assembler auf C), und dann haben wir es 1995 erlebt, als
> es nötig wurde, nach langer Zeit der Unklarheiten ein Windows-Programm
> auf die Beine zu stellen, weil DOS unbeliebt wurde.
> 1985 mußte notgedrungen alles neu programmiert werden, aber der Umfang
> war noch nicht gewaltig groß. Außerdem: 1985 gab es noch nicht viele
> Anwender. Wir konnten deren Daten von der obsoleten Plattform auf die
> neue überführen und die Weiterarbeit ermöglichen.
> 1995 fand zwar intern eine erhebliche Umstrukturierung statt
> (Objektorientierung, Klassenbibliothek!), aber im Ergebnis mußten
> keine Nutzerdaten umstrukturiert werden, d.h. der Umstieg war
> in der Hinsicht schmerzlos. Das ist nicht normal, sondern bei einem
> größeren Versionswechsel ist oft eine Umwandlung der Nutzdaten in
> eine neue Struktur fällig. Es führt dann leicht dazu, daß Anwender
> den Wechsel scheuen und lange hinausschieben oder im Extremfall
> gar nicht mitvollziehen können, weil es als zu aufwendig empfunden
> wird und damit auch zu kostspielig. Wir sehen es z.B. bei MyCore und
> bei VuFind, daß eine deutlich bessere Neuversion sehr lange braucht,
> bis sie an der Basis "angekommen" ist. Seit 1985 haben wir keinen
> solchen Bruch riskiert. Gleichwohl gibt es immer noch Anwender,
> die mit 10 Jahre alten Versionen leben, obwohl sie ihre Daten mit
> der aktuellsten Version unverändert weiterbenutzen könnten, und nicht
> nur die Daten, auch alle Parameter etc. Aber irgendeinen Zwang zum
> Wechsel können und wollen wir schließlich auch nicht ausüben.
> Auch in diesem Jahr, mit V35, wird es so etwas nicht geben.

> Nun kommt aber auf der Welt weniges ohne Nachteile daher, und über
> die ist zu reden:

> A.
> Anwender fragen: Ist eine in der Kernstruktur so alte Software noch
> zukunftsfähig?
> Da gibt es drei wichtige Aspekte:
> 1. Entspricht sie noch heutigen und künftigen Nutzererwartungen?
>     Zu unterscheiden ist natürlich zwischen den Erwartungen der
>     Bibliothekare und der Endnutzer. Letztere sind geprägt von Google-
>     Erfahrungen, also von Suchmaschinentechniken. Diesen Erwartungen
>     kann man entsprechen durch Auslagerung der OPAC-Funktion in eine
>     angekoppelte VuFind-Umgebung. Was aber nicht heißt, daß man die
>     alcarta-, PHPAC- oder a35-Oberfläche dann aufgeben müßte, obwohl
>     vom Blättern in alphabetisch sortierten Listen ganz allgemein nichts
>     mehr gehalten wird.
> 2. Wie lange bleiben die Programme überhaupt noch funktionsfähig?
>     Windows 8 wird von Microsoft bis zum 1.4.2023 garantiert (s.u.).
>     Windows 10 wird evtl. etwas länger "leben", aber das weiß noch
>     keiner - 2025 ist aber wohl nicht zu hoch gegriffen.
>     Für Linux deutet sich kein solcher Meilenstein an; die GNU-Compiler
>     jedenfalls werden ganz sicher kompatibel bleiben.
> 3. Wird allegro Schritt halten mit dem neuen Umfeld RDA+BIBFRAME?
>     (Betrifft nur die normale Anwendung "Katalogisierung", und auch
>     diese nur, soweit RDA-Konformität gewünscht ist.)
>     RDA ist kein wirkliches Problem! Man kriegt nur hier und da neue
>     Uneinheitlichkeiten in den Fremddaten, aber davon gibt's ja immer
>     schon eine Menge.
>     BIBFRAME? Experten reden jetzt von 10 Jahren, bevor es ernsthaft,
>     also auf breiter Basis, MARC ablösen kann.
>     Das würde zu A.2. passen! Denn zwar nicht BIBFRAME selbst, aber die
>     damit verbundenen Erwartungen und Ansprüche werden ganz andersartige
>     Systeme fordern und diese werden entstehen. *Vorher* schon allegro
>     abzulösen durch etwas anderes, was *jetzt* schon existiert, das
>     ergibt deshalb wenig Sinn - es sei denn, andere Gründe als einfach
>     nur Zweifel an allegro sprechen für eine vorzeitige Ablösung, etwa
>     ein Verbundbeitritt. Denn man würde sich sonst nur auf eine anders-
>     artige Zwischenlösung einlassen, deren Tage gleichfalls schon
>     gezählt sind.

> B.
> Entwickler fragen: Ist eine so alte Software nicht im Kern auch
> softwaretechnisch veraltet?
> Klar ist sie das. Die wichtige Frage ist: Macht das was aus?
> Da gibt es ebenfalls zwei Aspekte:
> 1. Bleibt das Kompilieren auf neuen Windows- und Linux-Plattformen
>     noch möglich?
>     Nach allen bisherigen Erfahrungen: ja.
> 2. Werden unabhängige Entwickler die Programme noch genügend weit
>     durchschauen können, um Änderungen ausführen zu können?
>     Da liegt das größte Problem, denn die formale Struktur entspricht
>     ganz und gar nicht den heute gängigen Standards und Konventionen.

> Die Problematik B.2. ergibt sich aus der langen Vorgeschichte:
> Der Einstieg 1995 in die objektorientierte Programmierung war ein
> Kraftakt, aber es ging dann nicht auf gleichem Niveau weiter: die C++-
> Klassen hätten konsequent weiterentwickelt werden müssen und ihre
> Anwendung in a99 und acon ebenfalls konsequent klassentechnisch
> durchgeführt.
> Dazu fehlte definitiv die Zeit. Sowohl a99 wie avanti+acon entstanden
> zunächst als hastig zusammengebastelte prozedurale Programme unter
> Nutzung der Klassen, auch um deren Funktion gründlicher auszutesten.
> Aber dann verselbständigten sie sich, weil ihre Leistungen dringend
> gebraucht wurden, und ein fast grotesker Wildwuchs nahm seinen Lauf...
> Gleichwohl ist es bis heute ja gelungen, die Programme mehrfach um
> substantielle Leistungen (zuletzt HFM) zu erweitern, und zwar auch
> die strukturell noch älteren und viel schlimmeren Hilfsprogramme (srch,
> index, import, qrix).

> Fazit: Zwar bleiben die Programme, so wie sie jetzt sind bzw. Ende 2015
> sein werden, noch mindestens 10 Jahre lauffähig, auch wenn gar keine
> Änderungen mehr gemacht werden. Wenn aber aus irgendwelchen Gründen
> welche gemacht werden müssen, *könnte* es wegen B.2. schwierig werden.
> Daher werden wir in diesem Jahr einige Bemühungen auf Punkt B.2.
> konzentrieren. Das ist bereits angelaufen und erste Ergebnisse werden
> in Kürze vorgestellt. Desgleichen eine weiter verbesserte Dokumentation
> zur VuFind.Implementierung incl. Einbindung externer Ressourcen.

> Ausführliche Hinweise zu den Microsoft-Plänen:
> http://www.focus.de/digital/computer/windows/noch-zwei-wochen-support-ende-fuer-windows-7-das-muessen-sie-jetzt-tun_id_4382819.html

> B.Eversberg

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