{"id":2477,"date":"2023-01-10T20:57:36","date_gmt":"2023-01-10T20:57:36","guid":{"rendered":"https:\/\/jan.schnasse.org\/blog\/?p=2477"},"modified":"2026-09-28T11:37:30","modified_gmt":"2026-09-28T09:37:30","slug":"harmonisiertes-metadatenschema-fur-die-dspace-repositorien-der-berliner-universitaten","status":"publish","type":"post","link":"https:\/\/jan.schnasse.org\/blog\/2023\/01\/10\/harmonisiertes-metadatenschema-fur-die-dspace-repositorien-der-berliner-universitaten\/","title":{"rendered":"Kommentar zu: Harmonisiertes Metadatenschema f\u00fcr die DSpace-Repositorien der Berliner Universit\u00e4ten"},"content":{"rendered":"

Im folgenden teile ich hier einige Gedanken zu dem Papier:<\/p>\n

„Harmonisiertes Metadatenschema f\u00fcr die DSpace-Repositorien der Berliner Universit\u00e4ten – Ergebnis der Arbeitsgruppe DSpace Metadaten bestehend aus Mitgliedern der Charit\u00e9 – Universit\u00e4tsmedizin Berlin, der Freien Universit\u00e4t Berlin, der Humboldt-Universit\u00e4t zu Berlin und der Technischen Universit\u00e4t Berlin“<\/p>\n

Zu finden hier: https:\/\/refubium.fu-berlin.de\/handle\/fub188\/37260<\/a><\/p>\n

Direktlink zum Datensatz hier:\u00a0 https:\/\/refubium.fu-berlin.de\/bitstream\/handle\/fub188\/37260\/Berlin_DSpace_MDS.xlsx?sequence=1&isAllowed=y&save=y<\/a><\/p>\n

Als Entwickler finde ich die im Abstract formulierten Zielsetzungen besonders wichtig und erfreulich:
\n<\/span><\/p>\n

„Ziel ist, innerhalb der Berliner Universit\u00e4ten einen einheitlichen
\nGebrauch der Metadaten zu gew\u00e4hrleisten. Gleichzeitig wird es bei
\nEinf\u00fchrung des neuen Modells m\u00f6glich sein, Mappingtabellen, Schnittstellen
\nund Programmierarbeiten zwischen den beteiligten Einrichtungen leichter
\nauszutauschen.“
\n<\/span><\/p>\n

Trigger<\/strong><\/p>\n

Das Arbeitsergebnis wurde als Excel-Datei ver\u00f6ffentlicht. Dies reicht als Grundlage f\u00fcr einen gelungenen Datenaustausch nat\u00fcrlich noch nicht aus. Typische Folgefragen von Softwareentwicklern sind:<\/p>\n

– Wo finde ich die konkreten Schemadateien?<\/p>\n

– Gibt es Testsysteme?<\/p>\n

– Welche Protokolle\/APIs sollen zum Austausch der Daten angeboten und genutzt werden?<\/p>\n

– Wie sieht es mit Mehrsprachigkeit in den Metadaten\u00a0aus?<\/p>\n

Aber zur\u00fcck zum vorliegenden Datensatz:<\/p>\n

Beobachtung<\/strong><\/p>\n

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\u00f6glicherweise durch „ein paar Handgriffe“ optimaler unterst\u00fctzt werden k\u00f6nnte.<\/p>\n

Beispiel aus Zeile 22-24:<\/p>\n\n\n\n\n\n\n
Feld<\/strong><\/td>\nBeispielwert<\/strong><\/td>\n<\/tr>\n
dc.subject<\/td>\nopen access<\/td>\n<\/tr>\n
dc.subject.ddc<\/td>\n300 Sozialwissenschaften<\/td>\n<\/tr>\n
dc.subject.rvk<\/td>\nAK 54355<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ein paar Dinge fallen hier auf:<\/p>\n

1. In den Freitextfeldern werden Notationen und Label gemischt<\/p>\n

2. F\u00fcr einzelne Notationssyteme existieren spezielle Unterfelder (ddc,rvk). Dies ist nicht gut erweiterbar. Besser w\u00e4re es zu jedem Subject das Notationssystem zu vermerken und f\u00fcr diesen Vermerk seinerseits ein kontrolliertes Vokabular (z.B. basierend auf Wikidata, s.u.) zu definieren.<\/p>\n

3. Es wird nicht ganz klar, wie Mehrsprachigkeit realisiert werden soll.<\/p>\n

4. Es gibt kein (Sub)Feld indem z.B. URIs auf SKOS-Vokabulare mitgef\u00fchrt werden k\u00f6nnten.<\/p>\n

These<\/strong><\/p>\n

Um den Bereich „subject“ besser maschinell nachnutzbar zu machen, sollten kontrollierte SKOS-Vokabulare die Regel sein. Wenn m\u00f6glich sollten URIs zur Identifikation von verwendeten Termen mit im Datensatz gespeichert werden.<\/p>\n

In jedem Fall sollten Notationen, Label und IDs im Datenmodell in getrennte Unterfelder laufen. Labels sollten mehrsprachig im Datensatz mitgef\u00fchrt werden k\u00f6nnen bzw. \u00fcber eine URI leicht nachgeladen werden k\u00f6nnen.<\/p>\n

Beispiel und Vorschlag
\n<\/strong><\/p>\n

Das Beispiel zeigt ein Schlagwort im Feld subject mit zus\u00e4tzlichen Informationen.<\/p>\n

\"subject\":[{\n   \"id\":\"http:\/\/dewey.info\/class\/300\",\n   \"notation\":\"300\",\n   \"prefLabel\": \"Sozialwissenschaften\",\n   \"label\":{\n      \"de\":\"Sozialwissenschaften\"\n      \"en\": \"Social Sciences\"\n      \"fr\":\"....\"\n    },\n   \"source\":{\n      \"id\":\"https:\/\/www.wikidata.org\/wiki\/Q15222117\",\n      \"label\":{\n        \"en\": \"Dewey Decimal Classification\"\n     }\n    \"similarTo\": \"https:\/\/www.wikidata.org\/wiki\/Q34749\"\n   }\n}]<\/pre>\n
Zus\u00e4tzlich zu dem Schlagwort werden Informationen zur Quelle und zum Notationssystem gegeben. Notation und Schlagwort werden getrennt. Es wird \u00fcber einen Link auf Wikidata eine Verlinkung in andere Schlagwortsysteme realisiert.<\/p>\n
Und was bringt das?<\/strong><\/p>\n
Dies hat vor allem Vorteile auf der maschinellen Konsumentenseite.<\/p>\n
    \n
  1. Alle subjects, egal aus welchem Vokabular, k\u00f6nnen zun\u00e4chst mal leicht verarbeitet werden. Folgendes geht z.B. immer: subject.0.prefLabel<\/span>, subject.0.label.de <\/span>. Hierbei ist es egal, aus welchem Notationssystem ein Schlagwort kommt. Dies stellt eine erhebliche Vereinfachung f\u00fcr Aggregatoren dar, die f\u00fcr einfache Anwendungsf\u00e4lle keine weiteren Informationen \u00fcber die angebotenen Subfelder eines Quellsystems haben m\u00fcssen. Siehe Punkt 4.<\/li>\n
  2. \u00dcber die „source“ und die „notation“ k\u00f6nnen einerseits in einer grafischen Oberfl\u00e4che zus\u00e4tzliche Hinweise gegegeben werden, andererseits k\u00f6nnen die nachnutzenden Systeme Verkn\u00fcpfungen zu anderen Datens\u00e4tzen herstellen und so sehr effektive Browsingoberfl\u00e4chen oder sonstige Bezugssysteme aufbauen.<\/li>\n
  3. Wikidata als ein m\u00f6gliches Werkzeug um Verkn\u00fcpfungen herzustellen. \u00dcber den Link unter „similarTo“ k\u00f6nnen weitere Vokabulare verkn\u00fcpft werden. Sehr praktisch wenn man z.B. die Inhalte unterschiedlicher Quellen mit unterschiedlicher Verschlagwortung\/Erschlie\u00dfung aggregieren m\u00f6chte.<\/li>\n
  4. Durch den Verzicht auf Unterfelder f\u00fcr spezifische Vokabulare, z.B. .ddc<\/span> oder .rvk , wird ein einheitlicher Zugriff auf Schlagworte aus unterschiedlichen Vokabularien unterst\u00fctzt. Dadurch k\u00f6nnen konsumierende Systeme auch Schlagwortsysteme, die sie nicht vollst\u00e4ndig unterst\u00fctzen einfach zur Anzeige bringen und indexieren, etc..
    \n<\/span><\/span><\/li>\n
  5. Anzeige und intellektuelle Erschlie\u00dfung werden separiert. Die Anzeige eines Schlagworts (das Label) wird von der verwendeten Notation getrennt. Dies er\u00f6ffnet nachnutzenden Systemen die M\u00f6glichkeit kontextspezifische Anzeigestrategien zu etablieren ohne die zugrundeliegende intellektuelle Erschlie\u00dfung (in Form der Notation) anpassen zu m\u00fcssen. Ersteres ist oft gew\u00fcnscht, letzteres ist oft nicht ohne weiteres m\u00f6glich.<\/li>\n<\/ol>\n
    <\/div>\n
    Das sieht aber total aufwendig aus.<\/strong><\/div>\n
    <\/div>\n
    Vielleicht ist es gar nicht so aufwendig. Gerade bei der Erstellung der Metadaten liegen die Infos zu einem Schlagwort oft alle im Erfassungssystem vor. Sie m\u00fcssten dann nur abgespeichert werden!<\/div>\n
    <\/div>\n
    Ist das alles?<\/strong><\/div>\n
    <\/div>\n
    Ich denke, nein. Die Design-Prinzipien, die ich hier f\u00fcr das Subject Feld beispielhaft ausgef\u00fchrt habe, k\u00f6nnen auch f\u00fcr andere Felder sinnvoll zur Anwendung gebracht werden. z.B. f\u00fcr Contributor, Insitutionen etc. Auch in diesen F\u00e4llen bietet eine hierarchisierte Form der Speicherung Vorteile gegen\u00fcber der Schaffung neuer Felder und vereinfacht die Konsumierbarkeit der Daten.<\/div>\n
    <\/div>\n
    <\/div>\n","protected":false},"excerpt":{"rendered":"
    Im folgenden teile ich hier einige Gedanken zu dem Papier: „Harmonisiertes Metadatenschema f\u00fcr die DSpace-Repositorien der Berliner Universit\u00e4ten – Ergebnis der Arbeitsgruppe DSpace Metadaten bestehend aus Mitgliedern der Charit\u00e9 – Universit\u00e4tsmedizin Berlin, der Freien Universit\u00e4t Berlin, der Humboldt-Universit\u00e4t zu Berlin und der Technischen Universit\u00e4t Berlin“ Zu finden hier: https:\/\/refubium.fu-berlin.de\/handle\/fub188\/37260 Direktlink zum Datensatz hier:\u00a0 https:\/\/refubium.fu-berlin.de\/bitstream\/handle\/fub188\/37260\/Berlin_DSpace_MDS.xlsx?sequence=1&isAllowed=y&save=y Als […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,15],"tags":[],"class_list":["post-2477","post","type-post","status-publish","format-standard","hentry","category-development","category-software"],"_links":{"self":[{"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/posts\/2477","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/comments?post=2477"}],"version-history":[{"count":1,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/posts\/2477\/revisions"}],"predecessor-version":[{"id":3815,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/posts\/2477\/revisions\/3815"}],"wp:attachment":[{"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/media?parent=2477"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/categories?post=2477"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jan.schnasse.org\/blog\/wp-json\/wp\/v2\/tags?post=2477"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}