You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OPUS bringt von Haus aus eine große Zahl an Feldern für Datums- und Jahresangaben mit. Die Benennungen der Felder lassen einen gewissen Interpretationsspielraum und bereits in der Standardauslieferung gibt es Ungenauigkeiten in den Übersetzungen (Textelementen). Vermutlich ist das (zumindest mit-) ursächlich daran, dass die Felder in den Instanzen sehr unterschiedlich belegt werden. An vielen Stellen werden Datums- und Jahresangaben weiterverarbeitet, z.B. in der Indexierung und ganz besonders in den Exportformaten (über die GUI, über die OAI-API, bei der Registrierung von DOIs in DataCite Fabrica etc.), aber auch bei Importen z.B. aus DeepGreen oder BibTeX.
Nutzt eine Einrichtung die Datums- und Jahresfelder anders als intendiert, sind Anpassungen an vielen Stellen nötig; mitunter werden manche Stellen auch übersehen und dann z.B. das Jahr bzw. Datum der Erstveröffentlichung fälschlicherweise als Erscheinungsjahr oder -datum der vorliegenden Publikation angezeigt und/oder an andere Dienste übermittelt. Deutlich erschwert wird auch die Weiterentwicklung, da Datums- und Jahresangaben hier ebenfalls oft eine wichtige Rolle spielen, z.B. bei einer Erweiterung der Exportformate oder der Realisierung neuer Funktionen (wie z.B. die DOI-Registrierung in DataCite Fabrica). Kurzum: das bestehende Modell führt immer wieder zu teils deutlichen Mehraufwänden und ist zudem fehleranfällig.
In dieser Diskussion soll zunächst überlegt werden, wie ein sauberes und konsistentes Modell für Datums- und Jahresangaben aussehen könnte. In einem zweiten Schritt kann dann über die technische Umsetzung und mögliche Migration bestehender Datums- und Jahresangaben nachgedacht werden
Konzeption eines neuen Modells
Aus bibliothekarischer Sicht sind insbesondere diese Angaben zentral:
Erscheinen
Erstveröffentlichung (nur bei Zweitveröffentlichungen)
Abschlussprüfung (nur bei Theses)
Traditionell werden in der bibliothekarischen Erfassungspraxis Jahresangaben verwendet (Erscheinungsjahr etc.). Auch heute wird in den Katalogen in der Regel eine Jahresangabe und kein Datum eingetragen. Dennoch kann es gerade im Online-Kontext sinnvoll sein, dass auch datumsgenaue Einträge möglich sind.
OPUS wollte dem begegnen, indem es jeweils ein Feld für die Datums- und die Jahresangabe gibt (PublishedDate, PublishedYear, CompletedDate, CompletedYear etc.). Nachteil dieser Lösung ist, dass stets zwei Felder für ein Merkmal (Erscheinen, Erstveröffentlichung etc.) vorhanden sind und diese, wie die langjährige Praxis zeigt, oft nicht alternativ belegt, sondern missinterpretiert und dann beide Felder im selben Datensatz ausgefüllt werden. Das führt dann zu Folgefehlern bei der Indexierung, den Exporten etc.
Um dem entgegenzuwirken, wäre es sinnvoll
nur noch ein Feld für ein Merkmal (Erscheinen, Erstveröffentlichung etc.) zu haben, in das sowohl komplette Datumsangaben als auch reine Jahreszahlen eingetragen werden können, je nach Vorliegen oder Bedarf.
die Felder und Hilfetext zumindest in der GUI entsprechend und konsistent zu benennen.
Darüber hinaus sind weitere Angaben als technische Metadaten bei jedem Datensatz vorhanden (server_date_created, server_date_published etc.) und können im Bedarfsfall ebenfalls nachgenutzt werden (z.B. Anzeige von server_date_published auf der Frontdoor als "Datum der Veröffentlichung (Online)").
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Einleitung
OPUS bringt von Haus aus eine große Zahl an Feldern für Datums- und Jahresangaben mit. Die Benennungen der Felder lassen einen gewissen Interpretationsspielraum und bereits in der Standardauslieferung gibt es Ungenauigkeiten in den Übersetzungen (Textelementen). Vermutlich ist das (zumindest mit-) ursächlich daran, dass die Felder in den Instanzen sehr unterschiedlich belegt werden. An vielen Stellen werden Datums- und Jahresangaben weiterverarbeitet, z.B. in der Indexierung und ganz besonders in den Exportformaten (über die GUI, über die OAI-API, bei der Registrierung von DOIs in DataCite Fabrica etc.), aber auch bei Importen z.B. aus DeepGreen oder BibTeX.
Nutzt eine Einrichtung die Datums- und Jahresfelder anders als intendiert, sind Anpassungen an vielen Stellen nötig; mitunter werden manche Stellen auch übersehen und dann z.B. das Jahr bzw. Datum der Erstveröffentlichung fälschlicherweise als Erscheinungsjahr oder -datum der vorliegenden Publikation angezeigt und/oder an andere Dienste übermittelt. Deutlich erschwert wird auch die Weiterentwicklung, da Datums- und Jahresangaben hier ebenfalls oft eine wichtige Rolle spielen, z.B. bei einer Erweiterung der Exportformate oder der Realisierung neuer Funktionen (wie z.B. die DOI-Registrierung in DataCite Fabrica). Kurzum: das bestehende Modell führt immer wieder zu teils deutlichen Mehraufwänden und ist zudem fehleranfällig.
In dieser Diskussion soll zunächst überlegt werden, wie ein sauberes und konsistentes Modell für Datums- und Jahresangaben aussehen könnte. In einem zweiten Schritt kann dann über die technische Umsetzung und mögliche Migration bestehender Datums- und Jahresangaben nachgedacht werden
Konzeption eines neuen Modells
Aus bibliothekarischer Sicht sind insbesondere diese Angaben zentral:
Traditionell werden in der bibliothekarischen Erfassungspraxis Jahresangaben verwendet (Erscheinungsjahr etc.). Auch heute wird in den Katalogen in der Regel eine Jahresangabe und kein Datum eingetragen. Dennoch kann es gerade im Online-Kontext sinnvoll sein, dass auch datumsgenaue Einträge möglich sind.
OPUS wollte dem begegnen, indem es jeweils ein Feld für die Datums- und die Jahresangabe gibt (PublishedDate, PublishedYear, CompletedDate, CompletedYear etc.). Nachteil dieser Lösung ist, dass stets zwei Felder für ein Merkmal (Erscheinen, Erstveröffentlichung etc.) vorhanden sind und diese, wie die langjährige Praxis zeigt, oft nicht alternativ belegt, sondern missinterpretiert und dann beide Felder im selben Datensatz ausgefüllt werden. Das führt dann zu Folgefehlern bei der Indexierung, den Exporten etc.
Um dem entgegenzuwirken, wäre es sinnvoll
Darüber hinaus sind weitere Angaben als technische Metadaten bei jedem Datensatz vorhanden (server_date_created, server_date_published etc.) und können im Bedarfsfall ebenfalls nachgenutzt werden (z.B. Anzeige von server_date_published auf der Frontdoor als "Datum der Veröffentlichung (Online)").
Beta Was this translation helpful? Give feedback.
All reactions