Im folgenden teile ich hier einige Gedanken zu dem Papier:

„Harmonisiertes Metadatenschema für die DSpace-Repositorien der Berliner Universitäten – Ergebnis der Arbeitsgruppe DSpace Metadaten bestehend aus Mitgliedern der Charité – Universitätsmedizin Berlin, der Freien Universität Berlin, der Humboldt-Universität zu Berlin und der Technischen Universität Berlin“

Zu finden hier: https://refubium.fu-berlin.de/handle/fub188/37260

Direktlink zum Datensatz hier:  https://refubium.fu-berlin.de/bitstream/handle/fub188/37260/Berlin_DSpace_MDS.xlsx?sequence=1&isAllowed=y&save=y

Als Entwickler finde ich die im Abstract formulierten Zielsetzungen besonders wichtig und erfreulich:

„Ziel ist, innerhalb der Berliner Universitäten einen einheitlichen
Gebrauch der Metadaten zu gewährleisten. Gleichzeitig wird es bei
Einführung des neuen Modells möglich sein, Mappingtabellen, Schnittstellen
und Programmierarbeiten zwischen den beteiligten Einrichtungen leichter
auszutauschen.“

Trigger

Das Arbeitsergebnis wurde als Excel-Datei veröffentlicht. Dies reicht als Grundlage für einen gelungenen Datenaustausch natürlich noch nicht aus. Typische Folgefragen von Softwareentwicklern sind:

– Wo finde ich die konkreten Schemadateien?

– Gibt es Testsysteme?

– Welche Protokolle/APIs sollen zum Austausch der Daten angeboten und genutzt werden?

– Wie sieht es mit Mehrsprachigkeit in den Metadaten aus?

Aber zurück zum vorliegenden Datensatz:

Beobachtung

An vielen Stellen in der Excel-Datei steht als Datentyp Freitext. Es gibt kaum MetaMetadaten. An einigen Stellen erscheint das Modell zu flach und zu spezifisch. Dies ist in gewisser Weise Schade, da hier die zitierte. Zielsetzung möglicherweise durch „ein paar Handgriffe“ optimaler unterstützt werden könnte.

Beispiel aus Zeile 22-24:

Ein paar Dinge fallen hier auf:

1. In den Freitextfeldern werden Notationen und Label gemischt

2. Für einzelne Notationssyteme existieren spezielle Unterfelder (ddc,rvk). Dies ist nicht gut erweiterbar. Besser wäre es zu jedem Subject das Notationssystem zu vermerken und für diesen Vermerk seinerseits ein kontrolliertes Vokabular (z.B. basierend auf Wikidata, s.u.) zu definieren.

3. Es wird nicht ganz klar, wie Mehrsprachigkeit realisiert werden soll.

4. Es gibt kein (Sub)Feld indem z.B. URIs auf SKOS-Vokabulare mitgeführt werden könnten.

These

Um den Bereich „subject“ besser maschinell nachnutzbar zu machen, sollten kontrollierte SKOS-Vokabulare die Regel sein. Wenn möglich sollten URIs zur Identifikation von verwendeten Termen mit im Datensatz gespeichert werden.

In jedem Fall sollten Notationen, Label und IDs im Datenmodell in getrennte Unterfelder laufen. Labels sollten mehrsprachig im Datensatz mitgeführt werden können bzw. über eine URI leicht nachgeladen werden können.

Beispiel und Vorschlag

Das Beispiel zeigt ein Schlagwort im Feld subject mit zusätzlichen Informationen.

"subject":[{
   "id":"http://dewey.info/class/300",
   "notation":"300",
   "prefLabel": "Sozialwissenschaften",
   "label":{
      "de":"Sozialwissenschaften"
      "en": "Social Sciences"
      "fr":"...."
    },
   "source":{
      "id":"https://www.wikidata.org/wiki/Q15222117",
      "label":{
        "en": "Dewey Decimal Classification"
     }
    "similarTo": "https://www.wikidata.org/wiki/Q34749"
   }
}]

Zusätzlich zu dem Schlagwort werden Informationen zur Quelle und zum Notationssystem gegeben. Notation und Schlagwort werden getrennt. Es wird über einen Link auf Wikidata eine Verlinkung in andere Schlagwortsysteme realisiert.

Und was bringt das?

Dies hat vor allem Vorteile auf der maschinellen Konsumentenseite.

1. Alle subjects, egal aus welchem Vokabular, können zunächst mal leicht verarbeitet werden. Folgendes geht z.B. immer: subject.0.prefLabel, subject.0.label.de . Hierbei ist es egal, aus welchem Notationssystem ein Schlagwort kommt. Dies stellt eine erhebliche Vereinfachung für Aggregatoren dar, die für einfache Anwendungsfälle keine weiteren Informationen über die angebotenen Subfelder eines Quellsystems haben müssen. Siehe Punkt 4.
2. Über die „source“ und die „notation“ können einerseits in einer grafischen Oberfläche zusätzliche Hinweise gegegeben werden, andererseits können die nachnutzenden Systeme Verknüpfungen zu anderen Datensätzen herstellen und so sehr effektive Browsingoberflächen oder sonstige Bezugssysteme aufbauen.
3. Wikidata als ein mögliches Werkzeug um Verknüpfungen herzustellen. Über den Link unter „similarTo“ können weitere Vokabulare verknüpft werden. Sehr praktisch wenn man z.B. die Inhalte unterschiedlicher Quellen mit unterschiedlicher Verschlagwortung/Erschließung aggregieren möchte.
4. Durch den Verzicht auf Unterfelder für spezifische Vokabulare, z.B. .ddc oder .rvk , wird ein einheitlicher Zugriff auf Schlagworte aus unterschiedlichen Vokabularien unterstützt. Dadurch können konsumierende Systeme auch Schlagwortsysteme, die sie nicht vollständig unterstützen einfach zur Anzeige bringen und indexieren, etc..
   
5. Anzeige und intellektuelle Erschließung werden separiert. Die Anzeige eines Schlagworts (das Label) wird von der verwendeten Notation getrennt. Dies eröffnet nachnutzenden Systemen die Möglichkeit kontextspezifische Anzeigestrategien zu etablieren ohne die zugrundeliegende intellektuelle Erschließung (in Form der Notation) anpassen zu müssen. Ersteres ist oft gewünscht, letzteres ist oft nicht ohne weiteres möglich.