Projektspezifische Auswahlfelder im Regelsatz

[Westedt]

Intention: Am Beispiel von singleDigCollections haben wir gemerkt, dass uns projektbasierte Auswahlfelder aus Kitodo 2 fehlen. Durch die Vielzahl an verschiedenen Digitalisierungsprojekten haben wir zahlreiche digitale Kollektionen (ca. 80 Stück). Pro Projekt benötigen wir diverse Auswahlen an Kollektionen, welche in der Anzahl stark schwanken können.

Mögliche Lösungen:

1. Projektspezifische Regelsätze (mit <include>) nach Issue Add project-specific metadata restriction #4233

Diese Möglichkeit haben wir untersucht. Durch das Kopieren des gesamten <restriction>-Abschnitts pro Projekt entsteht für uns keine Erleichterung im Workflow. Nur der <declaration>-Teil kann per <include> eingefügt werden. Bei Hinzufügen eines neuen Keys müssten alle Regelsätze manuell bearbeitet werden.

2. Projektspezifische Regelsätze per Skript

Ein Skript erzeugt aus einem Standardregelsatz durch Erweiterung der <restrictions> in dem Auswahlfeld die Projektspezifika. Die Export-xslt’s müssten in diesem Fall auch mitkopiert (verlinkt) werden. Dies hat den Nachteil, dass bei Änderungen des Regelsatzes stets daran gedacht werden muss, das Skript auszuführen.

<permit key="singleDigCollection" minOccurs="1">
<permit value="Karten"/>
<permit value="Kinder- und Jugendbücher"/>
<permit value="POP Musik"/>
<permit value="Nachlässe und Autographe"/>
<permit value="Außereuropäische Handschriften"/>
</permit>

3. Erweiterung des Regelsatzes

Wenn wir den Regelsatz erweitern, ist alles in Kitodo sichtbar und wir brauchen keine nebenläufigen Prozesse. Bisher wurden die Regelsätze immer durch neue Attribute erweitert. In den folgenden Beispielen wird derselbe Fall beschrieben. Wir schlagen zwei Alternativen vor:

a) Einführung einer Projekt-Node innerhalb einer Key-Node, um <option> zu filtern

<key id="singleDigCollection">
<label lang="de">Digitale Kollektion</label>
<label lang="en">Digital collection</label>
<projekt list=“VD17 VD18“>
<option value="Musik"/>
<option value="Nachlässe und Autographe"/>
<option value="Außereuropäische Handschriften"/>
<option value="Islamische Handschriften"/>
<option value="Christlich-orientalische Handschriften"/>
</projekt>
<option value="Handschriften"/>
</key>

b) Einführung eines neuen Attributs in <option>-node

<key id="singleDigCollection">
<label lang="de">Digitale Kollektion</label>
<label lang="en">Digital collection</label>
<option projekt="VD17 VD18" value="Musik"/>
<option projekt="VD17 VD18" value="Nachlässe und Autographe"/>
<option projekt="VD17 VD18" value="Außereuropäische Handschriften"/>
<option projekt="VD17 VD18" value="Islamische Handschriften"/>
<option projekt="VD17 VD18" value="Christlich-orientalische Handschriften"/>
<option value="Handschriften"/>
</key>

Semantik:
Für ein Projekt gelten dann sowohl die Kollektionen, die unterhalb der Project-List stehen, als auch diejenigen, die keinem spezifischen Projekt zugewiesen sind. In diesem Beispiel stünden für das Projekt „VD17“ alle benannten Kollektionen, inklusive „Handschriften“, zur Auswahl. Für das Projekt „VD16“ würde lediglich „Handschriften“ zur Wahl stehen.

Schlussfolgerung:
Bei Alternative a) kommt der Projektname nur 1-mal vor, was die zukünftige Bearbeitung und Lesbarkeit deutlich vereinfacht, aber es muss eine neue node <projekt> und Attribut @list in die Definition (http://names.kitodo.org/ruleset/v2 ../../../../../Kitodo-DataEditor/src/main/resources/ruleset.xsd)
hinzugefügt werden.
In Alternative b) kommt der Projektname in jede einzelne <option>. Dadurch sind die Lesbarkeit und die zukünftige Bearbeitung deutlich komplizierter. Die Definition muss nur um ein Attribut @projekt erweitert werden

Wir wünschen uns Alternative a)

[matthias-ronge]

Hierzu drei Anmerkungen:

1. Hinter den Regelsätzen steht ein semantisches Datenmodell, das heißt, die Schlüssel und Werte stehen zunächst einmal mit einer Bedeutung außerhalb des Systems, in der realen Welt in Zusammenhang. Eine Person ist kein Textfeld, sondern eine Person ist ein Mensch, der irgendwann irgendwo einmal geboren wurde und eine Lebensgeschichte hat. Es ist mit Absicht gewollt, dass ein <key> in seiner Definition alle gültigen Werte enthält. „Außereuropäische Handschriften“ ist in diesem semantischen Sinne − das heißt von seinem „Wesen“ her − eine Kollektion (und kein Adelstitel, kein Thermometer und keine Kuchensorte), und es ist immer eine Kollektion, unabhängig von der Tatsache, ob es in einem Projekt angezeigt oder benutzt wird oder nicht. Der Aussage „‘Außereuropäische Handschriften’ sind nur dann eine Kollektion, wenn sie im Projekt ‚VD17‘ oder ‚VD18‘ erwähnt werden, außerhalb der Projekte sind ‘Außereuropäische Handschriften’ gar keine Kollektion“ würden Sie wahrscheinlich auch nicht zustimmen. Daher lehne ich eine Bedingung innerhalb von <key>-Elementen kategorisch ab. Sie läuft dem Grundprinzip des semantischen Datenmodells zuwider.
2. Werden Regelsätze mittels <include> zusammengefügt, ist es nicht notwendig, den kompletten <correlation>-Teil zu duplizieren. Sie müssen nur diejenigen <restriction>-Elemente redefinieren, die sich im Vergleich zum inkludierten Regelsatz ändern. (So ist die Funktion jedenfalls konzipiert. Wenn es anders sein sollte, ist das ein Bug, der zu beheben wäre.)
3. Mit der Möglichkeit, voneinander abhängig erlaubte Metadatenwerte zu nutzen, sollte es meiner Einschätzung nach bereits möglich sein, die gewünschte Funktionalität zu erreichen. Definieren Sie dazu ein internes Metadatenfeld „Projekt“ mit dem Projektnamen.