Regelsatzeditor

[matthias-ronge]

Hin und wieder kommt der Gedanke auf, ein Regelsatz-Editor wäre eine nette Funktion. Aber wo anfangen? Ich denke, zunächst wäre es sinnvoll, sich eine Vorstellung davon zu machen, wie er aussehen könnte und wie alle relevanten Optionen übersichtlich dargestellt werden könnten. Das ist nur ein kleiner Entwurf, aber vielleicht ein Ausgangspunkt für eine Diskussion.

Auf der Registerkarte „Allgemein“ können Sie die Standardsprache festlegen (sofern Englisch nicht als Standard verwendet wird) und weitere Sprachen auswählen, für die der Editor dann auch Eingabefelder darstellt. Außerdem können Sie darin inkludierte Regelsätze hinzufügen.

Das Bearbeiten von Unterteilungen könnte so aussehen: Im oberen Teil der Seite wird die Unterteilung definiert, im unteren Teil die Einschränkungen und Erlaubnisse. Wenn die Unterteilung kein Dokumenttyp ist, sind einige irrelevante Steuerelemente ausgeblendet. Darunter können zulässige Unterteilungen und Metadaten ausgewählt werden. Die blaue Anzeige nennt eine Quantifizierung, und der rote Stern zeigt spezielle Einstellungen an. Man muss auf „Spezialeinstellungen“ klicken, um sie anzuzeigen.

Handelt es sich bei der Unterteilung um einen Dokumenttyp, verfügt die Eingabemaske über Eingaben für die Regel zur Prozesstitelgenerierung und die entsprechenden Attribute. Datum und Format sind nur verfügbar, wenn die Abteilung als Unterteilung nach Datum innerhalb einer anderen Unterteilung ausgewählt wurde.

Für eine Zeitungspublikation kann die Datumsunterteilung in Jahr, Monat und Tag konfiguriert werden. Es gibt ein Eingabefeld für den Jahresbeginn, und Pfeiltasten ermöglichen den Sprung zu den ausgewählten Unterteilungen (zur Bequemlichkeit).

Diese Eingabemaske ermöglicht die Bearbeitung von Metadatenschlüsseln. Unten links befinden sich die Einstellungen aus dem Bearbeitungsbereich.

So könnte eine Eingabemaske ist für Metadatengruppen aussehen. Sie ermöglicht die Definition darin enthaltener Metadatenschlüssel.

Dies spiegelt noch nicht alle Details wider und zeigt, wie anspruchsvoll diese Aufgabe sein würde. Aber ich lasse es hier einfach als Idee stehen.

[henning-gerhardt]

Die Idee ist sehr gut, aber sie müsste noch in einem größeren Rahmen ausdiskutiert werden, da sie auch diverse Fallstricke mit sich bringt aber auch automatisch weitere Anforderungen.

Dazu einmal meine Gedanken:

• Wenn die Speicherung der Regelsätze weiterhin in XML passieren sollte, sollte die dazugehörige Schema Datei der Schlüsselpunkt über die Funktionalität des Editors im speziellen und über den Zugriff auf den Regelsatz selbst im Allgemeinen sein, so wie es jetzt schon für das METS, MODS und Kitodo Format ist. D.h. aus der Schema Datei werden die entsprechenden Java Zugriffsklassen generisch erstellt. Der Editor könnte dann - eine entsprechende Technologie vorausgesetzt, dann ebenfalls generisch erstellt werden, so dass bei Erweiterung oder Reduzierung des Schemas Funktionen im Editor als auch im Zugriff automatisch vorhanden sind. Ggf. müssen die Editor-Funktionen noch an speziellen Stellen erweitert werden, aber das wäre machbar.
• Darüber hinaus müsste auch der Zugriff auf die parallele Bearbeitung im Editor, wie es jetzt schon beim Metadaten Editor der Fall ist, eingeschränkt werden, da ansonsten Änderungen verloren gehen.
• Der Import und Export der erstellten Regelsätze müsste ebenfalls im Editor realisiert werden, so dass ein Austausch der Regelsätze entweder innerhalb der Einrichtung zwischen Test- und Produktivsystemen oder zwischen Einrichtungen / Instanzen weiterhin möglich ist.
• An der SLUB setzen wir für das Verwalten, Bearbeiten, Revisionieren, Ausrollen und der Sicherung GIT und ein CI Deployment ein. Gerade die Sicherung und Rücksicherung und ggf. Revisionierung der Regelsätze müsste weiterhin möglich sein, so dass entweder die bearbeitenden Personen selbst auch auf ältere Stände zurück gehen können ohne dass technische Administratoren an der Stelle involviert sind.