Hinter Libcoll steckt Zope (“Z Object Publishing Environment”), ein objektorientierter Webanwendungs-Manager. Die gesamte Struktur und die Prozesse zur Generierung von Libcoll werden hier definiert und verwaltet. Nur kurz: Zope verwaltet (über ein Web-basiertes Objekt-Management-System) eine Hierarchie von Objekten, dynamisch und jederzeit erweiterbar. Das sind Instanzen von speziellen Klassen, die wiederum in den sogenannten Produkten definiert sind. Diese Produkte sind einfach Anwendungen (in der Programmiersprache Python geschrieben), die von Zope selber oder von der ITgroup stammen. In der folgenden Dokumentation sollte klar werden, was damit gemeint ist. Wer näheres über Zope erfahren möchte, schaue bitte hier oder hier nach.

Folgender Libcoll-Flow-Chart gibt einen Überblick über die Elemente, die beim online_stellen von Dokumenten verwendet werden.

Zur Erklärung:

• Jedes Dokument in libcoll wird durch ein index.meta ausgewiesen, in welchem alle relevanten Metadaten stehen.
• Diese Metadaten werden in einem jeweiligen Zope-Objekt (‘Resource‘) eingespeist. Im einzelnen Fall geschieht das über 'Sync Metadata', bei mehreren über 'Reload Metadata'.
• Für die Darstellung in Libcoll (Autor, Titel, Jahr) werden die Ressourcen noch gerendert. Wiederum im Einzelfall durch 'generate_title/label' und bei vielen Ressourcen durch 'Rerender all Labels and Titles'
• Gleichzeitig werden alle Ressourcen im sogenannten ‘Resource Catalog‘ noch einmal mit ihren wichtigsten Daten (Autor, Titel, Jahr) indiziert, um für die Suche und die Autorenliste einen schnelleren Zugriff zu liefern.

Man gelangt in das Zope-Management, indem man an die URL einfach ein /manage hängt. Den Einstieg in Zope kann man an jedem Unterpunkt vollziehen, also bspw. auch in libcoll/elib/all_documents. Je nachdem an welchem Unterpunkt (Collection) man eingestiegen ist, sieht man nun die versammelten Zope-Objekte, die in dem jeweiligen Verzeichnis angelegt sind.

Ganz in bekannter Dateimanager-Manier navigiert man innerhalb dieses hierarchischen Verzeichnisses von Objekten, die alle einer bestimmten Klasse zugewiesen sind (das Icon zeigt jeweils die Klasse an). Auf der Root-Ebene liegen hier bspw. die User-Verwaltung, das html-file und die Images zum Aufbau der Seite, und für uns wohl am wichtigsten der elib-Ordner, über welchen man zu den einzelnen Kollektionen gelangt. Prinzipiell können jedoch viele verschiedene Objekte unterschiedlicher Klassen abgelegt sein. Im weiteren tauchen so z. B. Python-Scripte oder externe Links auf.

Um solche Objekte anzulegen, wählt man aus der Pop-Up-Liste auf der rechten Seite eine Klasse aus und füllt das angezeigte Formular zur Definition und Beschreibung des Objektes aus. 'ID', 'Title', und 'Label' sind Pflichangaben.

Die Reiter am oberen Rand sind Funktionen, die für das momentan aufgerufene Objekt verfügbar sind. 'View' bspw. zeigt einfach den Inhalt in der html-Umgebung an und mit 'undo' kann man die letzten Änderungen rückgängig machen. Einige Funktionen vererben sich, d. h. sie werden auf alle Inhalte in den Unterordnern angewendet. Bei dem nun folgenden Durchnavigieren durch die Struktur werden die jeweilig relevanten Funktionen aufgeführt.

Im obigen “Root-Verzeichnis” von libcoll ist nur ein einziger Reiter von Interesse:

• Update Resource Catalog: Hier aktualisiert man den Katalog, aus welchem die Libcoll-Suche und die Autorenliste ihre Daten beziehen. Da beide Funktionen sämtliche Ressourcen in Libcoll umfassen, steht diese Funktion an dieser Stelle in der Hierarchie.

In aller Regel möchte man in der electronic library ('elib') arbeiten. In diesem Objekt erhält man eine Liste der Collections, wie sie in der Label-Leiste von libcoll auftauchen.

• Main Config: ist generell immer eine Eingabemaske zum Konfigurieren des jeweiligen Objektes, in diesem Fall also der collection elib.
• Rerender Lables and Titles: damit wird die Darstellung sämtlicher Ressourcen (Autor, Titel, Jahr) in elib neu generiert
• Reload Metadata: hier werden von allen aktuell aufgerufenen Ressourcen die zugehörigen index.metas erneut ausgelesen
• Copy MD for Indexing and Search: alle Metadaten werden mit einem Klick in einen Katalog eingespielt, welcher Suchabfragen behandelt und die Autorenliste erstellt

Geht man in eine der Collections, erhält man eine Liste der Ressourcen, im Falle von all_documents sollten diese also sämtliche Werke in libcoll beinhalten.

• create resources from xml: damit können eine größere Anzahl von Ressourcen mittels eines vorher erstellten xml-files angelegt werden
• auch hier kann man alle Funktionen wie Rerender, Reload oder Copy MD ausführen, sie gelten wie gesagt jedoch nur für die Collection, in der man sich momentan befindet

Klickt man eine individuelle Ressource an, stehen einem noch weitere Funktionen zur Verfügung:

• Change Metadata: hier kann man die Metadaten im jeweiligen index.meta direkt ändern.
• Sync Metadata: die Ressource (Zope) wird mit dem jeweiligen index.meta (Storage) abgeglichen. Durch einen Klick auf ('copy to ECHO! NO UNDO!!!') werden die Daten aus dem index.meta in die Ressource eingespielt. Man kann hier auch das index.meta und die Ressource editieren
• auch hier steht die Funktion Copy MD for Indexing and Search zur Verfügung. Für eine einzelne Resource ist dies recht ineffizient, man sollte dies deshalb besser eine Ebene höher machen.

Das sind alles viele, verwirrende Funktionen, deren Sinn sich erst mit etwas Erfahrung erschließt. Ebenso deren Bugs. Im Folgenden werden ein paar typische Verfahren aufgelistet und gleichzeitig Probleme angedeutet:

• Oft will man einzelne oder gleich mehrere index.metas nachträglich ändern, z.B. um Tippfehler, die in der libcoll-Darstellung deutlich wurden, zu bereinigen. Das erfordert natürlich ein anschließendes Update der Ressource(n). Bei einer einzelnen Ressource läuft dies über Sync-Metadata, bei mehreren über Reload Metadata. Anschließend müssen die erneuerten Ressourcen noch in das ganze libcoll-Zope-System eingepflegt (Copy MD + Update Catalog) und die Darstellung in libcoll neu gerendert werden (Rerender Label and Title). Dies sollte möglichst lokal, d. h. in der jeweiligen Collection geschehen, da ein Reload auf der elib-Ebene nicht nur ewig dauert, sondern zudem auch gern mal verkrüppelte Ressourcen produziert.
• Will man eine Ressource verschieben, löschen, umbenennen oder kopieren macht man das nach guter alter Art durch die Management-Buttons unter der Ressourcen-Liste. So kann man bspw. auch den Inhalt einer ganzen Collection kopieren (Select All → Copy →[Verzeichniswechsel]→ Paste). Bei sehr vielen Ressourcen (ca. >300) funktioniert dies allerdings nicht, und man muss sich durchklicken. Paradoxerweise…

Man hat noch weitere Eingriffsmöglichkeiten, insbesondere auf die Darstellung von libcoll, wenn man eine Ebene über den der Bibliothek zugewiesenen root-Ordner in das Management einsteigt. Dies sollten nur erfahrene libcoll-Administratoren machen und dann auch nur in Absprache mit der ITgroup.

Zope läuft auf xserve02, der port auf welchem libcoll liegt ist 28880. Mit unserem digigroup-passwort gelangt man in den lib-Ordner:

Hier sind mehrere Objekte und Produkte abgelegt, die für das Funktionieren von libcoll relevant sind.

• label_templates: hier kann man die Darstellung der einzelnen Bib-Typen editieren. Wie und ob Autor, Titel, Volume, Pages etc. angezeigt werden wird hier in einem script festgelegt.
• standardMD: hierüber werden die Bib-Typen selbst generiert und verwaltet. Mittels Main Config kann man die Datenfelder festlegen, die jedem einzelnen Typ zugeordnet sind (“Metadata-Mapping”).
• resourceCatalog: gewährt einen kleinen Einblick in den Katalog
• storage: das alte Ablagesystem
• storage2: das neue Ablagesystem, bisher nur für Videodaten
• Weitere Formatierungs-Templates für Libcoll: css, collection, links etc.

— Christoph Rosol 2006/08/01 17:38