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)