search

OPUS4 / application

OPUS 4 application.
Other
15 stars 21 forks source link

Erweiterung datacite.xslt (zur DOI-Registrierung) analog zu oai_datacite #857

Open j3nsch opened 2 years ago

j3nsch commented 2 years ago

Bei der Umsetzung des neuen Metadata Formats oai_datacite soll auch das datacite.xslt zur DOI-Registrierung entsprechend erweitert werden, damit beide Formate identisch bleiben.

Im Wiki DataCite Metadata Format in OAI (oai_datacite) haben BSZ und KOBV das Mapping für OPUS 4 beschrieben. Für einige Fälle besteht derzeit noch Abstimmungsbedarf mit der Entwicklung.

  1. Creator nameType (2.1.a): Mapping (Personal: PersonAuthor PersonEditor | Organizational: CreatingCorporation) nameIdentifier (2.4): Erweiterung um IdentifierGnd

  2. Title (3.): Erweiterung um TitleAdditional titleType (3.1): Mapping (Subtitle: TitleSub | TranslatedTitle: TitleAdditional)

  3. Subject (6.): Erweiterung um SubjectCCS, SubjectMSC, SubjectPACS, SubjectSwd, SubjectUncontrolled

  4. Contributor (7.): Erweiterung um PersonContributor, PersonAdvisor, PersonReferee, ContributingCorporation nameIdentifier (7.4): Erweiterung um IdentifierGnd nameIdentifierScheme (7.4a): Erweiterung um GND

  5. Date (8.): Erweiterung um EmbargoDate; Änderung: ServerDatePublished nur wenn Embargo besteht dateType (8.a): Mapping (Accepted: ServerDatePublished nur wenn Embargo besteht | Available: EmbargoDate)

  6. ResourceType (10.): TODO noch endgültig zu klären resourceTypeGeneral (10.a) Mapping (Audiovisual: movingimage | Image: image | Sound: sound | Text: article, bachelorthesis, book, bookpart, conferenceobject, contributiontoperiodical, coursematerial, diplom, doctoralthesis, examen, habilitation, lecture, magister, masterthesis, other, periodicalpart, periodical, preprint, report, review, studythesis, workingpaper)

  7. AlternateIdentifier (11.): Erweiterung um IdentifierUrl und IdentifierUrn Problem: Unterscheidung, ob sich der Identifier auf das vorliegende Objekt bezieht oder es sich um eine Relation handelt, vgl. z.B. https://tickets.zib.de/jira/browse/OPUSVIER-4179

  8. RelatedIdentifier (12.): selbes Problem wie bei AlternateIdentifier (11.): Unterscheidung, ob sich der Identifier auf das vorliegende Objekt bezieht oder es sich um eine Relation handelt, s.a. https://tickets.zib.de/jira/browse/OPUSVIER-4183

  9. Rights (16.) mit rightsIdentifier (16.b): Ergänzung mit Licence/@Name

  10. Description (17.): TODO Klärung ob Erweiterung um TitleParent, Volume, Issue

  11. GeoLocation (18.): Festlegung zwischen BSZ und KOBV, das zu entfernen, da für Publikationen nicht relevant

  12. FundingReference (19.): Erweiterung, siehe Diskussion zur Funding Reference in OpenAIRE 4.0 https://tickets.zib.de/jira/browse/OPUSVIER-4182

Intern: https://tickets.zib.de/jira/browse/OPUSVIER-4236

j3nsch commented 2 years ago

Ich finde es nicht gut von vornherein einige DataCite-Felder auszuschließen, nur weil man den Focus auf klassische elektronische Publikationsformate hat und deswegen z.B. geoLocation für unwichtig hält. Mal abgesehen davon, dass die DINI-Liste durchaus hinterfragenswert ist, ebenso wie DataCite resourceTypeGeneral. Man beraubt meines Erachtens OPUS um seine Möglichkeiten, wenn man an die Verwendung und Nutzung von Enrichment-Feldern denkt. Auch wenn Forschungsdaten nicht explizit unter DataCite ResourceType stehen und hier dann meistens "collection" oder "dataset" genutzt wird, gehören sie aus meiner Sicht zu den wichtigen elektronischen Publikationsformaten der kommenden Jahre. Eine Orientierung am z.B. LMU Datacite Best Practice Guide bzgl. der wichtigen Felder fände ich daher wichtig. Eine Fokussierung auf die GND bei Personen und Institutionen finde ich nicht zielführend. Crossref, ROR und ORCID sind in vielen Fällen hilfreicher. Die Affiliation wie auch der ContributorType sind im Zusammenhang mit Personen und Institutionen und der Verwaltung (in OPUS) ebenfalls wichtig. Nicht jeder FD-Satz ist so groß, dass er OPUS-Fähigkeiten sprengt und man deswegen zu Schwergewichten wie DSpace etc. umsteigen muss. Unser OPUS 6.3 läuft zurzeit mit einigen Forschungsdaten im Testbetrieb. Der eigene OAI- und Datacite-Export Version 4.4 laufen, soweit ich zurzeit beurteilen kann, problemlos, nur der DOI-Registrierungsprozeß von OPUS zickt teilweise noch rum. Interessanterweise sind die unter ../logs/doi/ abgelegten xml-Dateien aber laut xmllint und Datacite Fabrica valide, aber die Registierung scheitert. Muss wohl etwas mit den Dateien oder DataCite-Schema im Ordner "framework/library/Opus/Doi/" zu tun haben? Womit ich bitte auch eine Frage anschließend möchte: Wieso ist das DataCite Schema dort abgelegt? Wird es für die lokale Validierung verwendet oder ist es ein Fallback, falls die Internetverbindung mal fällt? Kann ich es gegen das aktuelle Schema 4.4. einfach austauschen?

j3nsch commented 2 years ago

Vielen Dank! Inhaltlich kann ich dazu im Augenblick nichts sagen. Prinzipiell werden die XSLT Dateien ja häufig angepasst. Man kann also zusätzliche Mappings, Felder, hinzufügen. In wie weit wir das noch einfacher machen können bzw. mehr Felder im Standard (auf Vorrat) berücksichtigen können, kann ich im Augenblick nicht sagen.

Das Schema ist Teil des Frameworks für eine lokale Validierung, bei der Entwicklung und im Betrieb. Es sollte nicht einfach ausgetauscht werden. Ob die Implementation mit dem neuen Schema noch funktioniert, kann ich nicht sagen.

Generell sollte die DOI bzw. DataCite Implementation nicht Teil des Frameworks sein und im Zusammenhang mit dem Umstieg auf Laminas werden wir das auch bereinigen. Die Notwendigkeit den Code dort abzulegen stammt aus den Design-Problemen die OPUS 4 im Framework hat. Der DataCite-Support wird später in einem eigenen Modul liegen. Die aktuelle Version wird einen bestimmten Versionsstand des DataCite Schemas unterstützen. Für neue Schema-Versionen wird das Modul dann angepasst bzw. erweitert werden müssen.