Hilfe
FAQ
Erwartungen, Aufwand und Kosten
-
Nachdem Sie Ihre Institution registriert haben, wird für diese Einrichtung ein DeepGreen-Konto angelegt. Die Zugangsinformationen zu Ihrem Institutionskonto bekommen Sie anschließend umgehend zugeschickt. Um möglichst viele Zuordnungen durch die Datendrehscheibe zu bekommen, sollte Ihre Institution eine Affiliationsdatei konfigurieren, die möglichst viele Namensvariationen Ihrer Institution enthält. Technisch müsste sich Ihre Institution überlegen, welche der Schnittstellen Sie verwenden möchten. Falls Ihr Repositorium eine SWORD-Schnittstelle besitzt und Sie diese nutzen möchten, dann werden die zugeordneten Artikeldaten direkt in das Repositorium eingespeist und warten dann dort auf die Freischaltung. Die Abfrage der Artikeldaten über die Web-API oder über OAI-PMH kann Ihre Institution für sich einrichten. Als dritte Möglichkeit besteht noch die manuelle Abfrage der Artikeldaten. Wurden Ihrer Institution Artikeldaten zugestellt, muss vor der Veröffentlichung in Ihrem Repositorium geprüft werden, ob Ihre Institution auch wirklich berechtigt ist, diese Artikel zu veröffentlichen.
-
Während des Pilotbetriebs entstehen Ihrer Institution vorerst keine Kosten. Nach dem zweijährigen Pilotbetrieb ist geplant, die Institutionen finanziell an dem Betrieb von DeepGreen zu beteiligen.
Rechtliches und Lizenzen
-
DeepGreen verteilt Artikeldaten auf rechtlicher Grundlage verschiedener Lizenzen sowie Gold Open-Access-Artikel. Eine Teilnahme an DeepGreen ist auch ohne Beteiligung an einer Allianz-Lizenz möglich.
-
Das Einverständnis des Autors bzw. der Autorin wird nicht von DeepGreen eingeholt, sondern ist ggf. vor Ort zu klären.
Anmeldung
-
Den Haftungsausschluss finden Sie zum einen im Anhang des E-Mail-Anschreibens, das wir Ihrer Institution geschickt haben und zum anderen können Sie den Haftungsausschluss hier herunterladen. Für die Teilnahme an DeepGreen ist es Voraussetzung, dass Ihre Institution den Haftungsausschluss unterschrieben an uns zurücksendet. Bei der Verteilung der Artikeldaten kann nicht versichert werden, dass das Matching immer 100% klappt. Aus diesem Grund kann DeepGreen keine Verantwortung gegenüber den Verlagen dafür übernehmen, dass alle Artikel nur in berechtigten Repositorien veröffentlicht werden. Jede Institution ist selbst dafür verantwortlich zu prüfen, ob sie berechtigt ist, die zugeordnete Artikeldaten im Repositorium zu veröffentlichen
-
Der unterschriebene und gescannte Haftungsausschluss kann direkt per E-Mail an info-deepgreen@zib.de geschickt werden.
-
Nein, den Haftungsausschluss benötigen wir nicht im Original. Es reicht, wenn Sie uns einen Scan des unterschriebenen Haftungsausschlusses zusenden.
-
Mit der Teilnahme an der EZB bekommen Sie eine Kennung zur Verfügung gestellt. Diese finden Sie in Ihrem Admin-Bereich unter BibID.
DeepGreen-Kontozugänge
-
Sollten Sie sich mit Ihrem DeepGreen-Kontozugang nicht mehr einloggen können, dann schreiben Sie einfach eine Nachricht an info-deepgreen@zib.de. Wir kümmern uns schnellstmöglich darum.
-
Kein Problem. Wenden Sie sich einfach an die E-Mailadresse info-deepgreen@zib.de
-
Bitte tragen Sie keine personenbezogenen E-Mail-Adressen in dem DeepGreen-Konto Ihrer Institution ein, da wir keine personenbezogenen Daten in dem DeepGreen-Router speichern dürfen und wollen.
-
Sie können beide Sigel durch ein Komma separiert in dem entsprechenden Feld angeben.
-
Die E-Mail-Adresse wird nur für das Login genutzt. Für Nachrichten während des Pilotbetriebs werden die E-Mail-Adressen der organisatorischen und technischen Ansprechpartner:innen genutzt, die im Anmeldeformular angegeben wurden. Bitte geben Sie keine personenbezogenen E-Mail-Adressen für das Login an.
-
Das bleibt Ihnen überlassen. Eine Änderung der E-Mail-Adresse ist nicht notwendig. Wenn Sie möchten, können Sie eine neue E-Mail-Adresse vergeben. Wir bitten Sie allerdings, keine personenbezogenen Adressen zu verwenden.
Affiliationsdatei
-
Diese Fehlermeldung kann verschiedene Ursachen haben. Möglicherweise könnte es sein, dass Ihre Datei nicht in UTF-8 Codiert ist. Ein weiterer beliebter Fehler ist, dass möglicherweise nicht in jeder Zeile genau 5 Kommata vorhanden sind. Bitte beachten Sie außerdem, dass wenn Sie eine Namensvariation angeben wollen, die selbst ein Komma enthält (Bspw: Humboldt-Universität, Berlin), dann setzen Sie diese bitte in „“.
-
Das hängt davon ab, welches Programm Sie benutzen.
Libre Office: Bei Libre Office können Sie zum einen direkt beim Öffnen in dem Textimport festen den Zeichensatz „Unicode (UTF-8)“ auswählen. Beim Speichern haben Sie dann zusätzlich die Möglichkeit in UTF-8 abzuspeichern, indem Sie das Häckchen bei „Filtereinstellung bearbeiten“ anklicken bevor Sie auf „Speichern“ drücken. In dem separaten Fenster können Sie dann anschließend bei Zeichensatz „Unicode (UTF-8)“ auswählen.
MS Excel: Bei Excel können Sie in dem Speicherfenster unter „Tools“ neben dem „Speichern“-Button das Fenster „Weboptionen“ öffnen. Dort könne Sie anschließend unter dem Reiter „Codierung“ auswählen, dass Sie das Dokument als „Unicode (UTF-8)“ abspeichern wollen.
Editor: Wenn Sie einen Editor für die Bearbeitung nutzen, können Sie beim Abspeichern neben dem „Speichern“-Button die Codierung „UTF-8“ auswählen.
Bitte achten Sie darauf, bei allen Programmen UTF-8 ohne BOM auszuwählen!
-
Ja, diese Namensvaration müssten Sie allerdings in „“ setzen. Beispielsweise „Humboldt-Universität, Berlin“
-
Bitte nehmen Sie keine Änderungen an der ersten Zeile der Affiliationsdatei vor. Diese ist für die Einleseroutine wichtig.
-
Ja, Sie können gern die Namensansetzungen aus dem Web of Science für Ihre Affiliationsdatei nutzen.
-
Groß- und Kleinschreibung muss nicht beachtet werden.
-
Die Einträge müssen eindeutig zuzuordnen sein. Beispielsweise reicht es nicht aus, nur Philosophische Fakultät zu schreiben, da es diese an sehr vielen Einrichtungen gibt. In so einem Fall müsste entweder der Ort oder die Haupteinrichtung dazu.
-
Ja, die Spalten sind unabhängig voneinander. Es können also beispielsweise Namensvarianten und E-Mail-Domains nebeneinander stehen, ohne das diese zueinander in Verbindung gesetzt werden.
-
Für den Matching-Prozess ist es egal welche der beiden Varianten Sie wählen. Falls Sie beide nutzen ist wichtig, dass beide CSV-Dateien den gleichen Inhalt haben.
-
Die Affiliationsdatei enthält einige Spalten die für institutionelle Repositorien nicht relevant sind. Die Spalten „Dummy1“ und „Dummy2“ sind Platzhalten für den Fall das im späteren Betrieb Informationen hinzukommen die für das Matching relevant sein können, beispielsweise Institutionelle ID’s. Die Spalte „Keywords“ könnte ebenfalls später interessant sein.
-
Das funktioniert nicht, da die Keywords erst zu einem späteren Zeitpunkt mit Keywords in Artikelmetadaten verglichen werden. Mit Hinweis auf die DSGVO bitten wir Sie außerdem von dem Angeben personenbezogener Daten in der Affiliationsdatei abzusehen.
-
Informationen und Hilfestellung finden Sie zum einen in den Webinaraufzeichnungen, die Sie als teilnehmende Institution zur Verfügung gestellt bekommen haben. Außerdem finden Sie Informationen in dem Screencast „Benutzung aus Sicht der wissenschaftlichen Einrichtung“ auf unserer Webseite.
-
Die Verwendung von Platzhaltern, Wildcards oder Booleschen Operatoren generell, ist in der Affiliationsdatei leider nicht möglich.
-
Nein, das ist leider nicht möglich.
-
Die Affiliationsdatei, die sich bereits in Ihrem Konto befindet, stellt eine gute Vorlage dar. Für ein optimaleres Ergebnis empfehlen wir, diese Datei zu ergänzen.
-
Die Affiliationsangaben werden als ganzer String gematcht. Das bedeutet, dass jede Namensvariation im ganzen für den Abgleich genutzt wird und nicht nur Teile davon. Mittlerweile wurde der Matching-Mechanismus in DeepGreen so angepasst, dass die Namensvariationen in der Affiliationsdatei nicht mehr Teil eines Wortes in der Affiliationsangabe in den Artikelmetadaten sein dürfen.
-
Nein, das ist leider nicht möglich.
Technisches
-
Teilnehmende Repositorien haben mehrere Möglichkeiten die Artikeldaten zu bekommen.
Es besteht die Möglichkeit Artikeldaten über die Web-API zu beziehen. Diese Möglichkeit wird von unseren Anwender:innen gern genutzt, da die Institution die Kontrolle darüber behält, welche Daten abgerufen werden und wann. Eine Dokumentation dieser Schnittstelle finden Sie hier.
Des Weiteren kann OAI-PMH für die Artikelabholung genutzt werden. Bitte beachten Sie aber, dass über diese Schnittstelle ausschließlich Metadaten bezogen werden können. Eine Dokumentation dieser Schnittstelle finden Sie hier.
Es besteht außerdem die Möglichkeit die Artikeldaten automatisiert über SWORD zu beziehen. Für OPUS4-Repositorien ist die Anbindung über SWORD relativ simpel. Vor allem wenn Ihr Repositorium gehostet wird. Sowohl beim KOBV als auch beim BSZ gibt es bereits Erfahrung was die Anbindung über SWORD an DeepGreen angeht. Für DSpace-Repositorien finden Sie eine Dokumentation hier. Für MyCoRe und EPrints Repositorien gibt es Erfahrung in der DeepGreen-Anwender:innen-Community. Wenn Sie Fragen zu diesen Repositorientypen haben kontaktieren Sie uns gern.
Selbstverständlich besteht auch die Möglichkeit, die Artikeldaten manuell abzurufen. Für jeden Artikel in der Routing History kann ein ZIB-Paket mit dem Volltext und den Metadaten über die Eingabe der Notification-ID und des API-Key in die Browserzeile im folgenden Format heruntergeladen werden:
Kontaktieren Sie uns gern für eine ausführliche Anleitung.
-
Solange die Daten noch auf der DeepGreen-Datendrehscheibe gespeichert sind, können Sie die Daten so oft herunterladen wie Sie möchten. Nur die automatisierte Lieferung über SWORD kann nicht so einfach mehrfach gestartet werden.
-
Bei der automatisierten Lieferung über SWORD kann nicht so einfach mehrfach geliefert werden. Rückmeldungen über die SWORD-Schnittstelle sind nicht möglich.
Dokumentation
Handreichungen
Wichtige Informationen für institutionelle Repositorien können in der Handreichung DeepGreen – Open Access Transformation: Eine Handreichung für institutionelle Repositorien nachgelesen werden.
Einen umfassenden Überblick bietet außerdem die Handreichung DeepGreen: Open Access-Transformation in der Informationsinfrastruktur – Anforderungen und Empfehlungen
Technische Dokumentation
DeepGreen wird Open-Source entwickelt und der Code kann unter https://github.com/oa-deepgreen eingesehen werden.
Verfügbare Schnittstellen für Verlage
-
SFTP
Verlage senden ihre Daten über SFTP an den DeepGreen Router. Die Lieferungen bestehen aus ZIP-Files, die je eine xml-Datei mit Metadaten im Format NISO JATS sowie eine PDF-Datei mit dem Volltext des Artikels enthalten. Unsere technische Spezifikation beschreibt die Details.
Verfügbare Schnittstellen für Repositorien
-
Web-API (nativ)
DeepGreen bietet eine (rudimentäre) REST-Schnittstelle an. Die aktuelle Version der DeepGreen REST API ist
v1. Diese kann über die Web-Adressehttps://www.oa-deepgreen.de/api/v1angesprochen werden, z.B. mit dem Kommando curl in einer Shell (bash,tcsh, etc.):$ curl -s [-X GET|POST|PUT|HEADER] https://www.oa-deepgreen.de/api/v1/...
Dabei werden in den nun nachfolgende Beispielen die
...ersetzt durch die konkreten REST-Resourcenvalidate,notificationundroutedder Web-API-Schnittstelle. Eine weitere, für die GUI-lose Bedienung von Repositorienkonten gedachte REST-Resource ist durch den Endpunktconfiggegeben. Diese Resource ist insbesondere für Repositorienbetreiber, die eigene Skripte zur Verwaltung ihrer Konten entwickeln möchten. Sie ist hier der Vollständigkeit halber mit aufgeführt.Im Folgenden soll der Übersichtlichkeit halber
GET,POST, usw. für die gesamte, wie oben angegebenecurl-Zeile geschrieben werden. Hier ein kleiner Überblick der möglichen Aufrufe in dieser Kurzform:-
Aufruf :
POST /validateAngabe von Metadaten durch „Incoming Notification JSON“ (internes DeepGreen-Format)¶POST /validate?api_key=<api_key> Content-Type: application/json [Incoming Notification JSON]
-
Aufruf :
POST /notificationhttp-POST: Bündelung durch „Content-Type: multipart/form-data; ...“¶POST /notification?api_key=<api_key> Content-Type: multipart/form-data; boundary=FulltextBoundary --FulltextBoundary Content-Disposition: form-data; name="metadata" Content-Type: application/json [Incoming Notification JSON] --FulltextBoundary Content-Disposition: form-data; name="content" Content-Type: application/zip [Package] --FulltextBoundary--
-
Aufruf :
GET /routed -
Aufruf :
GET /notificationEine bestimmte Notification, geliefert im Format „Outgoing Notification JSON“ (internes DeepGreen-Format)¶GET /notification/<notification_id>
Daneben gibt es, wie eingangs schon erwähnt, einen weiteren Aufruf ausschließlich für Repositorienbetreiber gedacht:
-
Aufruf:
POST /configEine neue „match-config“-Datei für das eigene Konto installieren (JSON-Format)¶POST /config?api_key=<api_key> Content-Type: application/json; charset=utf-8 [New (overwriting!) match config settings JSON]
-
Aufruf:
GET /configDie aktuellen „match-config“-Setzungen des eigenen Kontos abfragen (JSON-Format)¶GET /config?api_key=<api_key>
All diese Aufrufmöglichkeiten der
Web-APIsollen nun im Folgenden näher erläutert werden.Artikeldaten an DeepGreen liefern¶
Vor der Übertragung eines Datenpakets einer Publikation zu DeepGreen kann das Paket von der Datendrehscheibe überprüft werden. Es sind also zwei REST-Resourcen des Web-APIs verfügbar,
-
Validierung eines Datenpakets (
validation), -
Übertragung eines Datenpakets (
notification).
Für ganz ungeduldige Leser hier zwei (funktionierende!)
bash-Beispielskripte, diezip-Pakete mit einemapi_keyan DeepGreen liefert bzw. validiert. Die Skripte analysieren zunächst jeweils die angegebenzip-Datei, welches Metadatenschema im Datenpaket vorliegt. Momentan werden von DeepGreen drei Schemata verarbeitet,DTD JATS,DTD Journal(dies ist eine Variante desDTD JATS-Schema) undDTD RSC.bash-Skript zur Validierung¶#! /usr/bin/env bash host_url="https://www.oa-deepgreen.de" if [ $# -ge 2 ]; then api_key=$1 zip_file=$2 else echo "usage: `basename $0` {api-key} {zip-file}" exit -1 fi curl=`which curl` zipgrep=`which zipgrep` wc=`which wc` pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" has_xml=`${zipgrep} "DOCTYPE article" ${zip_file} | ${wc} -l` if [ ${has_xml} -eq 1 ]; then is_jrnl=`${zipgrep} "//NLM//DTD Journal " ${zip_file} | ${wc} -l` is_jats=`${zipgrep} "//NLM//DTD JATS " ${zip_file} | ${wc} -l` is_rsc=`${zipgrep} "//RSC//DTD RSC " ${zip_file} | ${wc} -l` if [ ${is_jrnl} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" elif [ ${is_jats} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" elif [ ${is_rsc} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndRSC" else echo "error: no valid .xml (JATS or RSC) in zip archive found: stop." exit -2 fi else echo "error: no valid (or too many?!) .xml (JATS xor RSC) in zip archive found: stop." exit -3 fi echo "`basename $0`: packaging format in zip archive found:" echo "`basename $0`: ${pkg_fmt}" ${curl} -i -k -s -XPOST "${host_url}/api/v1/validate?api_key=${api_key}" -F "content=@${zip_file};type=application/zip" -F "metadata=@-;type=application/json" <<EOF { "content" : { "packaging_format" : "${pkg_fmt}" } } EOF echo
bash-Skript zur Datenpaketübertragung¶#! /usr/bin/env bash host_url="https://www.oa-deepgreen.de" if [ $# -ge 2 ]; then api_key=$1 zip_file=$2 else echo "usage: `basename $0` {api-key} {zip-file}" exit -1 fi curl=`which curl` zipgrep=`which zipgrep` wc=`which wc` pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" has_xml=`${zipgrep} "DOCTYPE article" ${zip_file} | ${wc} -l` if [ ${has_xml} -eq 1 ]; then is_jrnl=`${zipgrep} "//NLM//DTD Journal " ${zip_file} | ${wc} -l` is_jats=`${zipgrep} "//NLM//DTD JATS " ${zip_file} | ${wc} -l` is_rsc=`${zipgrep} "//RSC//DTD RSC " ${zip_file} | ${wc} -l` if [ ${is_jrnl} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" elif [ ${is_jats} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndJATS" elif [ ${is_rsc} -eq 1 ]; then pkg_fmt="https://datahub.deepgreen.org/FilesAndRSC" else echo "error: no valid .xml (JATS or RSC) in zip archive found: stop." exit -2 fi else echo "error: no valid (or too many?!) .xml (JATS xor RSC) in zip archive found: stop." exit -3 fi echo "`basename $0`: packaging format in zip archive found:" echo "`basename $0`: ${pkg_fmt}" ${curl} -i -k -s -XPOST "${host_url}/api/v1/notification?api_key=${api_key}" -F "content=@${zip_file};type=application/zip" -F "metadata=@-;type=application/json" <<EOF { "content" : { "packaging_format" : "${pkg_fmt}" } } EOF echo
Es können somit unterschiedliche Rückgabeantworten von DeepGreen erscheinen, je nachdem, ob eine Verifikation oder eine tatsächliche Datenablieferung vorgenommen wird. Der Einfachheit halber werden hier die beiden Funktionen auch nur mit den für sie typischen Anwendungsfälle dokumentiert. Selbstverständlich ist es auch möglich, ein komplettes Datenpaket mit Metadaten samt Volltext(e) validieren zu lassen, ebenso nur Metadaten abzuliefern. Zu beachten bleibt dabei, dass jeweils immer nur ein Artikel (!) pro Datenpaket verwendet wird. Nun die Erklärung der Rückgabewerte im Einzelnen:
Rückgabewerte bei
validation(hier am Beispiel: Nur Metadaten abliefern)¶Für die Verifikation einer Datenlieferung macht es durchaus Sinn, nur die Metadaten der Lieferung zu schicken. Dazu wird das
json-Format „Incoming Notification JSON“ zur Beschreibung der zu überprüfenden Metadaten verwendet. Mit Binärdaten gebündelte Lieferungen können natürlich ebenso geprüft werden. Dies funktioniert genau wie im Beispielnotificationunten angegeben.Angabe von Metadaten durch „Incoming Notification JSON“ (internes DeepGreen-Format)¶POST /validate?api_key=<api_key> Content-Type: application/json [Incoming Notification JSON]
-
http-Header Rückgabewerte
Code
Beschreibung
204 No Content
Datenpaket ok!
400 Bad Request
HTTP 1.1 400 Bad Request Content-Type: application/json { "error" : "<verständliche(!) Fehlermeldung (auf englisch)>" }401 Unauthorised
z.B. ungültiger
api_key, falsche Benutzertyp
Soweit die Dokumentation der http-Rückgabewerte der Funktion
validation. Nun folgt die Beschreibung der Rückgabewerte bei der Verwendung der Funktionnotification.Rückgabewerte bei
notification(am Beispiel: Metadaten samt Volltext(e) abliefern)¶Artikellieferungen, die binären Inhalt enthalten sollen (z.B. der Volltext als
pdf), werden durch die Kennzeichnung „multipart/form-data“ im http-Header gebündelt. Dabei muss imjsondes Metadatenteil („Incoming Notifikation JSON“) das Feld content.packaging_format zwingend vorhanden sein.http-POST: Bündelung durch „Content-Type: multipart/form-data; ...“¶POST /notification?api_key=<api_key> Content-Type: multipart/form-data; boundary=FulltextBoundary --FulltextBoundary Content-Disposition: form-data; name="metadata" Content-Type: application/json [Incoming Notification JSON] --FulltextBoundary Content-Disposition: form-data; name="content" Content-Type: application/zip [Package] --FulltextBoundary--
Minimale Angabe der Metadaten durch „packaging_format“¶POST /notification?api_key=<api_key> Content-Type: multipart/form-data; boundary=FulltextBoundary --FulltextBoundary Content-Disposition: form-data; name="metadata" Content-Type: application/json { "content" : { "packaging_format" : "https://datahub.deepgreen.org/FilesAndJATS" } } --FulltextBoundary Content-Disposition: form-data; name="content" Content-Type: application/zip [Package] --FulltextBoundary---
http-Header Rückgabewerte
Code
Beschreibung
202 Accepted
HTTP 1.1 202 Accepted Content-Type: application/json Location: <URL des api-Endpunkts der akzeptierten Lieferung> { "status" : "accepted", "id" : "<eindeutige ID dieser neuen Notifikation>", "location" : "<URL des api-Endpunkts dieser Notifikation>" }400 Bad Request
HTTP 1.1 400 Bad Request Content-Type: application/json { "error" : "<verständliche(!) Fehlermeldung (auf englisch)>" }401 Unauthorised
z.B. ungültiger
api_key, falscher Benutzertyp
Artikeldaten von DeepGreen erhalten¶
Naturgemäß gibt es mehrere Optionen, die Datensammlungen von DeepGreen abzufragen und zu listen. Diese verschiedenen Möglichkeiten werden durch unterschiedliche Aufrufe, aber auch durch bestimmte Parameter festgelegt und gesteuert. Als Parameter für die http-Adressen sind vorgesehen:
Mögliche Parameter bei GET-Funktionen von DeepGreen¶GET <http-Adresse/...>?since=<YYYY-MM-DD> # # Angabe erforderlich; bestimmt, von wann ab die Notifikationen gelistet werden # GET <http-Adresse/...>?pageSize=<number> # # Angabe optional, voreingestellt auf 25, maximal 100; bestimmt, wieviele Datensätze auf einmal ausgegeben werden # GET <http-Adresse/...>?page=<number> # # Angabe optional, voreingestellt auf 1; bestimmt, welche Seite der Resultate ausgegeben wird # GET <http-Adresse/...>?api_key=<api_key> # # Angabe optional; mit der Angabe wird die Anfrage authentifiziert (z.B. für den Bezug von Volltexten) #
Mehrere Parameterangaben hintereinander können mit dem
&-Zeichen verbunden werden.Die Notifikationlisten der zugestellten Artikel, die von DeepGreen innerhalb eines gewissen Zeitfensters (typischerweise drei Monate) bereitgestellt werden, sind JSON-Listen des DeepGreen-spezifischen Schemas „
Outgoing Notification“.Volles JSON-Schema für
Outgoing Notification(alphabetisch sortiert nach den Schlüsseln)¶{ "analysis_date": "2016-08-09T14:22:11Z", "content": { "packaging_format": "string" }, "created_date": "2016-08-09T14:22:11Z", "embargo": { "duration": 0 }, "id": "string", "issn_data": "string", "links": [ { "format": "string", "packaging": "string", "type": "string", "url": "string" } ], "metadata": { "author": [ { "affiliation": "string", "firstname": "string", "identifier": [ { "id": "string", "type": "string" } ], "lastname": "string", "name": "string" } ], "date_accepted": "2016-08-09T14:22:11Z", "date_submitted": "2016-08-09T14:22:11Z", "fpage", "string", "identifier": [ { "id": "string", "type": "string" } ], "issue", "string", "journal", "string", "license_ref": { "title": "string", "type": "string", "url": "string", "version": "string" }, "lpage", "string", "project": [ { "grant_number": "string", "identifier": [ { "id": "string", "type": "string" } ], "name": "string" } ], "publication_date": "2016-08-09T14:22:11Z", "publisher": "string", "source": { "identifier": [ { "id": "string", "type": "string" } ], "name": "string" }, "subject": [ "string" ], "title": "string", "volume": "string" } }
Die folgende Tabelle gibt eine prägnante Beschreibung für alle im Schema genannten Felder. Sämtliche Felder sind optional; und es sei der Hinweis gestattet, dass weder das Schema noch die Feldbeschreibungen in der Tabelle unter Umständen vollständig sind. Es können in einer weiteren Version von DeepGreen durchaus weitere Felder hinzutreten oder einzelne Felder gelöscht werden.
-
Feldbeschreibung für ausgehende Benachrichtungen (in alphabetischer Reihenfolge)
Feldbezeichner
Beschreibung
analysis_date
Zeitpunkt der Zustellanalyse
content.packaging_format
Format der zugehörigen Binärpakets (meist .zip)
created_date
Zeitpunkt, wann die Notifikation angelegt wurde
embargo.duration
Sperrzeit (Embargo; angegeben in Monaten)
id
Persistenter System-ID für diese Notifikation
links.format
MIME-Typ der Quelle
links.packaging
Paketformat der Quelle
links.type
Schlagwort für den Typ der Quelle (z.B. package)
links.url
URL für die Quelle (verlags- oder systemseitig)
metadata.author.affiliation
Affiliationsangabe, ermittelt aus den Metadaten
metadata.author.firstname
Vorname eines Autors/Urhebers
metadata.author.lastname
Nachname eines Autors/Urhebers
metadata.author.name
Zusammengesetzter Name eines Autors/Urhebers
metadata.date_accepted
Datum, wann die Publikation akzeptiert wurde
metadata.date_submitted
Datum, wann die Publikation eingereicht wurde
metadata.fpage
Erste Seitenzahl der Publikation
metadata.identifier.id
ID für die Publikation (z.B. DOI)
metadata.identifier.type
ID-Typ (z.B. „doi“; allerdings kein Vokabular)
metadata.issue
Heftzählung (Journalheft)
metadata.journal
Name des Journals der Publikation (Journaltitel)
metadata.license_ref.title
Name einer Lizenz (Freifeldtext)
metadata.license_ref.type
Lizenz-Typ (Freifeldtext)
metadata.license_ref.url
URL, die zu weiteren Lizenzinformationen führt
metadata.license_ref.version
Version einer Lizenz
metadata.lpage
Letzte Seitenzahl der Publikation
metadata.project.grant_number
Förderkürzel, sofern in den Metadaten angeführt
metadata.project.identifier.id
ID einer Förderung (z.B. Ringold)
metadata.project.identifier.type
ID-Typ in Bezug auf die Förder-ID
metadata.project.name
Name eines Förders / einer Förderinstitution
metadata.publication_date
Publikationsdatum
metadata.publisher
Verlagsname bzw. Verlag
metadata.source.identifier.id
ID der Veröffentlichungsquelle (z.B. ISSN)
metadata.source.identifier.type
ID-Typ der Veröffentlichungsquelle
metadata.source.name
Name der Veröffentlichungsquelle (Journaltitel)
metadata.subject
Schlagwort
metadata.title
Titel der Veröffentlichung
metadata.volume
Bandzählung (Journalband)
Liste aller erfolgreich zugestellten Artikel¶
Liste aller erfolgreich zugestellten Notifikationen¶GET /routed?since=<YYYY-MM-DD>[&<other params>]
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: application/json { "since" : "<Datumsangabe der Form YYYY-MM-DDThh:mm:ssZ>", "page" : "<Seitenzahl dieser Trefferausgabe>", "pageSize" : "<Anzahl der Trefferausgabe pro Seite>", "timestamp" : "<Zeitstempel der Anfrage>", "total" : "<Anzahl der Treffer zu dieser Zeit>", "notifications" : [ "<Liste der 'Outgoing Notification'-JSON-Objekte>" ] }400 Bad Request
HTTP 1.1 400 Bad Request Content-Type: application/json { "error" : "<verständliche(!) Fehlermeldung (auf englisch)>" }
Liste der einer Einrichtung zugestellten Artikel¶
Liste der zugestellten Notifikationen einer Einrichtung¶GET /routed/<repo_id>?since=<YYYY-MM-DD>[&<other params>]
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: application/json { "since" : "<Datumsangabe der Form YYYY-MM-DDThh:mm:ssZ>", "page" : "<Seitenzahl dieser Trefferausgabe>", "pageSize" : "<Anzahl der Trefferausgabe pro Seite>", "timestamp" : "<Zeitstempel der Anfrage>", "total" : "<Anzahl der Treffer zu dieser Zeit>", "notifications" : [ "<Liste der 'Outgoing Notification'-JSON-Objekte>" ] }400 Bad Request
HTTP 1.1 400 Bad Request Content-Type: application/json { "error" : "<verständliche(!) Fehlermeldung (auf englisch)>" }
Abfrage eines bestimmten Artikels¶
Jede Notifikation zu einem Artikel, der von DeepGreen erfolgreich zugestellt werden konnte, ist mit einer eindeutigen ID, der sogenannten Notifikations-ID, gekennzeichnet. Diese ID ist in den Ausgabelisten der vorherigen Abfragen zu finden. Mit der folgenden Anfarge erhält man den individuellen
JSONDatensatz einer bestimmten Notifikations-ID.Abfrage einer bestimmten Notifikation, geliefert im Format „Outgoing Notification JSON“ (internes DeepGreen-Format)¶GET /notification/<notification_id>
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: application/json [Outgoing Notification JSON]
404 Not Found
z.B. die
notification_idexistiert nicht, oder die Notifikation konnte (noch) nicht zugestellt werden und man ist nicht der Verfasser (d.h. Verlag) der Notifikation (authentifiziert viaapi_key)
Abruf der Binärdaten einer Notifikation¶
Über ein spezielles
links-Feld imOutgoing Notification JSON, wenn es gesetzt ist, kann dann der entsprechende Volltext bezogen werden, sofern man dazu berechtigt ist. Angenommen, die Notifikation enthielte den JSON-Abschnitt"links" : [ { "type" : "package", "format" : "application/zip", "url" : "https://www.oa-deepgreen.de/api/v1/notification/123456789/content", "packaging" : "https://datahub.deepgreen.org/FilesAndJATS" }, { "type" : "package", "format" : "application/zip", "url" : "https://www.oa-deepgreen.de/api/v1/notification/123456789/content/SimpleZip", "packaging" : "http://purl.org/net/sword/package/SimpleZip" } ]dann lautete der Abruf des Volltextes wie folgt:
Abfrage der Binärdaten eines Datenpakets, i.d.R. eine .zip-Datei mit dem/den Volltext(en)¶GET <links url>?api_key=<api_key>
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: application/zip [(binäres) Paket]
401 Unauthorised
z.B. ungültiger
api_key, falsche Benutzertyp oder die entsprechende Notifikation wurde (noch) nicht zugestellt404 Not Found
unter der angegebenen URL gibt es keinen Inhalt bzw. die URL ist schlicht nicht existent
Abfrage und Update der
match-config-Setzungen bei Repositorien¶Zur Abfrage der aktuellen Affiliations- und weiteren Treffer-Einstellungen eines Repositorienkontos benötigt man natürlich einen gültigen
api_key:Abfrage der aktuellen matching-Kriterien¶GET /config?api_key=<api_key>
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: application/json [matching Kriterien JSON]
401 Unauthorised
z.B. ungültiger
api_key404 Not Found
unter der angegebenen URL gibt es keinen Inhalt bzw. die URL ist schlicht nicht existent (z.B. durch
GET /config/)
Update der
matching-Kriterien eines Repositorienkontos¶Um neue Affiliations- und Treffer-Angaben für ein Repositorium in das zugehörige Konto laden zu können, benötigt man (wie gewohnt) einen gültigen
api_key:Überschreiben der matching-Kriterien mit neuen Werten¶POST /config?api_key=<api_key> Content-Type: application/json; charset=utf-8 [Overwriting new match config settings JSON]
-
http-Header Rückgabewerte
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Length: 0
401 Unauthorised
z.B. ungültiger
api_key400 Bad Request
Im JSON-Format, das hochgeladen wurde, ist ein Syntax-Fehler festgestellt worden (z.B. ein fehlendes Komma in Aufzählungen)
Beispielhafte, korrekte
match-config-Datei im internen JSON-Format¶{ "name_variants": [ "Academia Fridericiana Erlangensis", "Academia Friderico Alexandrina Erlangen-Nürnberg", "Academia Friderico-Alexandrina", "Academia Regia Bavarica Friderico-Alexandrina", "Academia Regia Friderico-Alexandrina", "Bayerische Friedrich-Alexanders-Universität", "F.A.U. Erlangen-Nürnberg", "University of Erlangen" ], "grants": [ "2491691", "2673762", "6273863" ], "domains": [ "fau.de", "uk-erlangen.de", "uni-erlangen.de" ], "keywords": [ "research", "bavarian", "erlangen" ] }
-
-
Eine weitere Schnittstelle, die insbesondere für metadata harvesting-Prozesse geeignet ist, stellt DeepGreen mit einer
OAI-PMH-konformen An-/Abfragemöglichkeit zur Verfügung (siehe Open Archives Initiative (dt.)). Diese Art der Metadaten-Abfrage kann über die Web-Adressehttps://www.oa-deepgreen.de/oaipmh/angesprochen werden, z.B. mit dem Kommando curl in einer Shell (bash,tcsh, etc.):$ curl -s https://www.oa-deepgreen.de/oaipmh/...
Dabei können (müssen!) die
...noch ersetzt werden durch die zwei möglichen Aufrufvariantenalloderrepoder DeepGreen-OAI-PMH-Schnittstelle. Wie üblich, seien im Folgenden mitGETstets die oben angegebene, komplettecurl-Zeile gemeint:-
Aufruf :
GET /allListe aller erfolgreich zugestellten NotifikationenGET /all[?<params (i.e. oai_verb + params)>]
-
Aufruf:
GET /repoListe der zugestellten Notifikationen einer EinrichtungGET /repo/<repo_id>[?<params (i.e. oai_verb + params)>]
Als illustratives Beispiel sei die Identifikation der DeepGreen-
OAI-PMH-Schnittstelle wiedergegeben:$ curl -k -s https://www.oa-deepgreen.de/oaipmh/all?verb=Identify | xml_pp <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2018-08-17T10:47:33Z</responseDate> <request verb="Identify">http://www.oa-deepgreen.de/oaipmh/all</request> <Identify> <repositoryName>DeepGreen Prototype OAI-PMH Endpoint</repositoryName> <baseURL>http://www.oa-deepgreen.de/oaipmh/all</baseURL> <protocolVersion>2.0</protocolVersion> <adminEmail>***</adminEmail> <earliestDatestamp>2018-05-19T08:47:33Z</earliestDatestamp> <deletedRecord>transient</deletedRecord> <granularity>YYYY-MM-DDThh:mm:ssZ</granularity> </Identify> </OAI-PMH>
Hierbei ist zu beachten, dass der frühstmögliche Zeitstempel (
earlierstDatestamp) immer in etwa „-3 Monate“ vom Aufrufdatum (responseDate) beträgt, da DeepGreen Artikeldaten stets nur solange aktuell und somit vorrätig hält (moving wall-Prinzip).Metadaten von DeepGreen erhalten
Es sei hier noch einmal ausdrücklich darauf hingewiesen, dass die
OAI-PMH-Schnittstelle von DeepGreen ausschließlich nur Metadaten anbietet. Die Auslieferung von Volltexten überOAI-PMHist (und wird auch zukünftig!) nicht vorgesehen.Der übersichlichkeithalber seien nun kurz die gebäuchlichsten OAI-Verben, die von DeepGreen unterstützt werden, gelistet:
Mögliche Parameter bei OAI-Verben von DeepGreenGET <hhtp-Adresse/...>?verb=Identify # # Dieses OAI-Verb hat keine weiteren Parameter # GET <http-Adresse/...>?verb=[ListIdentifiers|ListRecords]&from=<YYYY-MM-DD> # # Angabe optional; bestimmt, von wann ab die Notifikationen gelistet werden # GET <http-Adresse/...>?verb=[ListIdentifiers|ListRecords]&until=<YYYY-MM-DD> # # Angabe optional, gibt ein (maximales) Enddatum an, bis wohin die Notifikationen gelistet werden # GET <http-Adresse/...>?verb=GetRecord?identifier=<oai_id> # # Angabe erforderlich; gibt für dieses OAI-Verb den bestimmen Datensatz an, der geholt werden soll #
Bei allen OAI-Verben, die einen oder mehrere Datensätze zurückliefern, muss zusätzlich der Parameter
...&metadataPrefix=oai_dcangehängt werden. Sofern es also für ein OAI-Verb sinnvoll (oder vorgeschrieben) ist, werden mit dem&-Zeichen mehrere Parameter verbunden.Der
http-HeaderRückgabewert ist bei allen OAI-Anfragen (gemäß derOAI-PMH-Spezifikation) stets200 OK:-
http-Header Rückgabewert
Code
Beschreibung
200 OK
HTTP 1.1 200 OK Content-Type: text/xml; charset=utf-8 [XML response to OAI-PMH request; either content (e.g. list of records) or error message]
Beispiele für die Benutzung der OAI-PMH-Schnittstelle
Exemplarisches Ergebnis eines
OAI-PMH-Aufrufs (mit fiktiver Konto-Nummer 1234567890 ; die Notifikations-IDs sind ausgesternt):# # ListIdentifiers # $ curl -k -s "https://www.oa-deepgreen.de/oaipmh/repo/1234567890?verb=ListIdentifiers&metadataPrefix=oai_dc" | xml_pp <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2018-08-20T12:03:31Z</responseDate> <request metadataPrefix="oai_dc" verb="ListIdentifiers">http://www.oa-deepgreen.de/oaipmh/repo/1234567890</request> <ListIdentifiers> <header xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <identifier>oai:www.oa-deepgreen.de/notification:*****</identifier> <datestamp>2018-08-03T07:56:26Z</datestamp> </header> <header xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <identifier>oai:www.oa-deepgreen.de/notification:*****</identifier> <datestamp>2018-07-04T12:41:44Z</datestamp> </header> <header xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <identifier>oai:www.oa-deepgreen.de/notification:*****</identifier> <datestamp>2018-06-18T13:39:04Z</datestamp> </header> </ListIdentifiers> </OAI-PMH>
Ein weiteres Beispiel mit konkreten Datensätzen. Anhand der Notifikations-IDs (hier ausgesternt) könnten die berechtigten Repositorien die Artikel ggf. über die Web-API von DeepGreen beziehen:
# # ListRecords # $ curl -k -s "https://www.oa-deepgreen.de/oaipmh/repo/1234567890?verb=ListRecords&metadataPrefix=oai_dc" | xml_pp <?xml version="1.0" encoding="UTF-8"?> <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <responseDate>2018-08-20T12:24:10Z</responseDate> <request metadataPrefix="oai_dc" verb="ListRecords">http://www.oa-deepgreen.de/oaipmh/repo/1234567890</request> <ListRecords> <record> <header xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <identifier>oai:www.oa-deepgreen.de/notification:*****</identifier> <datestamp>2018-08-10T08:29:00Z</datestamp> </header> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <dc:title>Healthcare IT Utilization and Penetration among Physicians: Novel IT Solutions in Healthcare – Use and Acceptance in Hospitals</dc:title> <dc:publisher>S. Karger AG</dc:publisher> <dc:identifier>issn:0014-312X</dc:identifier> <dc:identifier>issn:1421-9921</dc:identifier> <dc:identifier>doi:10.1159/000490241</dc:identifier> <dc:creator>Ferdinand Vogt</dc:creator> <dc:creator>Fritz Seidl</dc:creator> <dc:creator>Giuseppe Santarpino</dc:creator> <dc:creator>Martijn van Griensven</dc:creator> <dc:creator>Martin Emmert</dc:creator> <dc:creator>Guenther Edenharter</dc:creator> <dc:creator>Dominik Pförringer</dc:creator> <dc:contributor>eDepartment of Anaesthesiology, Klinikum rechts der Isar, Technical University of Munich, Munich, Germany</dc:contributor> <dc:contributor>bDepartment of Trauma Surgery, Klinikum rechts der Isar, Technical University of Munich, Munich, Germany</dc:contributor> <dc:contributor>bDepartment of Trauma Surgery, Klinikum rechts der Isar, Technical University of Munich, Munich, Germany; cDepartment of Experimental Trauma Surgery, Klinikum rechts der Isar, Technical University of Munich, Munich, Germany</dc:contributor> <dc:contributor>aDepartment of Cardiac Surgery, Klinikum Nürnberg, Paracelsus Medical University, Nuremberg, Germany</dc:contributor> <dc:contributor>cDepartment of Experimental Trauma Surgery, Klinikum rechts der Isar, Technical University of Munich, Munich, Germany</dc:contributor> <dc:contributor>dInstitute of Management (IFM), School of Business and Economics, Friedrich Alexander University Erlangen-Nuremberg, Nuremberg, Germany</dc:contributor> <dc:date>2018-07-26T00:00:00Z</dc:date> <dc:rights>Alliance License DFG</dc:rights> <dc:subject>Original Paper</dc:subject> <dc:subject>Health monitoring</dc:subject> <dc:subject>Information technology</dc:subject> <dc:subject>Physicians</dc:subject> <dc:subject>Demand</dc:subject> <dc:subject>Outlook</dc:subject> <dc:subject>Expectations</dc:subject> <dc:subject>Data storage</dc:subject> <dc:subject>Healthcare IT</dc:subject> </oai_dc:dc> </metadata> </record> <record> <header xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <identifier>oai:www.oa-deepgreen.de/notification:*****</identifier> <datestamp>2018-08-10T08:34:06Z</datestamp> </header> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> <oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <dc:title>Gastrointestinal Stromal Tumors: Clinical Symptoms, Location, Metastasis Formation, and Associated Malignancies in a Single Center Retrospective Study</dc:title> <dc:publisher>S. Karger AG</dc:publisher> <dc:identifier>issn:0257-2753</dc:identifier> <dc:identifier>issn:1421-9875</dc:identifier> <dc:identifier>doi:10.1159/000489556</dc:identifier> <dc:creator>Ali Aghdassi</dc:creator> <dc:creator>Agnes Christoph</dc:creator> <dc:creator>Frank Dombrowski</dc:creator> <dc:creator>Paula Döring</dc:creator> <dc:creator>Christoph Barth</dc:creator> <dc:creator>Jan Christoph</dc:creator> <dc:creator>Markus M. Lerch</dc:creator> <dc:creator>Peter Simon</dc:creator> <dc:contributor>aDepartment of Medicine A, University Medicine Greifswald, Greifswald, Germany</dc:contributor> <dc:contributor>dChair of Medical Informatics, Friedrich-Alexander-University Erlangen-Nürnberg, Erlangen, Germany</dc:contributor> <dc:contributor>cGastroenterologische Praxis, Kempten, Germany</dc:contributor> <dc:contributor>bInstitute of Pathology, University Medicine Greifswald, Greifswald, Germany</dc:contributor> <dc:date>2018-06-05T00:00:00Z</dc:date> <dc:rights>Alliance License DFG</dc:rights> <dc:subject>Stomach and Duodenum: Original Paper</dc:subject> <dc:subject>Gastrointestinal stromal tumor</dc:subject> <dc:subject>Gastrointestinal oncology</dc:subject> <dc:subject>Gastrointestinal symptoms</dc:subject> <dc:subject>Gastrointestinal tract</dc:subject> <dc:subject>Metastasis</dc:subject> <dc:subject>Recurrence</dc:subject> </oai_dc:dc> </metadata> </record> </ListRecords> </OAI-PMH>
-
-
Die Standardinstallation einer SWORDv2-DSpace-Instanz versteht im Wesentlichen drei Formate laut den <acceptPackaging> tag vom Service Dokument: METSDSpaceSIP, Binary und SimpleZip. Je nach angegebenem Format (Packaging), muss dem hochzuladenden Paket entsprechend für einen erfolgreichen Deposit bereitgestellt werden.
DSpace Konfiguration, um die METSMODS Packages via SWORDv2 zu erhalten:
- Die SWORDV2 Schnittstelle muss freigeschaltet sein. Siehe https://wiki.duraspace.org/display/DSDOC5x/SWORDv2+Server.
- Um METSMODS Dateien einlesen zu können und so viele DeepGreen-Metadaten wie möglich zu erhalten, wurde eine XSLT-Datei implementiert, die das Mapping von METSMODS-Metadaten zu den DSpace-Metadaten durchführt. Die Datei finden Sie unter: https://github.com/OA-DeepGreen/DSpace/blob/depositonce-6.3x/dspace/config/crosswalks/sword-mods-ingest.xsl.
Dabei müssen Sie folgenden Konfigurationen in der „dspace.cfg“ bzw. „local.cfg“ setzen:
- mets.default.ingest.crosswalk.MODS = MODS
- crosswalk.submission.MODS.stylesheet= crosswalks/sword-mods-ingest.xsl
Wichtig: Für die SWORD-Konfiguration eines DeepGreen Repositorium-Kontos muss bei der SWORD-Konfiguration packaging preference, http://purl.org/net/sword/package/METSMODS eintragen werden.
Konkordanz NISO JATS zu METSMODS
NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) n/a //mods/typeOfResource text n/a //mods/genre journal article <article> //mods/language/languageTerm EN <article-title> //mods/titleInfo/title A Short Discussion on… //mods/relatedItem/[@type=“host“]/… NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) <journal-title> titleInfo/title Acta numerica <journal-id> identifier[@type=“publisher-id“] Act. Num. <issn> identifier[@type=“eIssn“] 1234-234X <issn> identifier[@type=“pIssn“] 5432-9634 <volume> part/detail[@type=“volume“]/number 7 <issue> part/detail[@type=“issue“]/number 10 <fpage> part/extent[@unit=“pages“]/start 521 <lpage> part/extent[@unit=“pages“]/end 534 //mods/relatedItem/[@type=“host“]/… NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) <surname> namePart[@type=“family“] Hoppenstadt <given-names> namePart[@type=“given“] Dickie M. <contrib> role/roleTerm[@type=“text“] author <contrib-id> nameIdentifier[@type=“orcid“] 1111-1010-1111-0101 <aff> affiliation Zuse Institut Berlin NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) <abstract> ///mods/abstract In this paper we will … <kwd> //mods/subject/topic viscoelasticity //mods/originInfo NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) <publisher-name> publisher MDPI <publisher-loc> place/placeTerm[@type=“text“] Basel <pub-date> dateIssued[@encoding=“iso8601″] 2015-02-23 <date> dateOther[@type=“accepted“] 2015-02-20 <date> dateOther[@type=“received“] 2015-12-24 NISO JATS (tag) METSMODS (xpath) Belegung in METSMODS (Beispiel) <article-id> //mods/identifier[@type=“doi“] 10.1212sjsdh45723dg <license> //mods/accessCondition[@description=“uri“] http:creativecomm.org
Das Repositorien-Konto
Zur Teilnahme an DeepGreen ist für institutionelle Repositorien notwendig, dass die Bibliothek, die das Repositorium Betreibt, bei der Elektronischen Zeitschriftenbibliothek (EZB) in Regensburg angemeldet ist.
Ist diese Voraussetzung erfüllt, kann ein Konto bei DeepGreen beantragt werden. Mit der Vergabe eines neuen Repositorium-Kontos werden eine (eindeutige) 32-stellige ID und ein sogenannter API-Schlüssel erzeugt, der für den Zugriff auf die zu erwartenden Volltexte benötigt wird.
Über dieses Konto wählt man sich als Repositorienbetreiber bei DeepGreen ein, um
- die eigene ID und den API-Schlüssel herauszufinden,
- die aktuellen Artikelzuordnungen einzusehen und herunterzuladen,
- die aktuellen Einstellung der match-config-Datei (Affiliationsdatei) zu überprüfen, herunterzuladen oder ggf. eine neue match-config-Datei hochzuladen,
- die Einstellungen des DeepGreen-Kontos allgemein zu überprüfen und anzupassen (Passwort, ggf. SWORD-Einstellungen für die automatisierte Artikeldaten-Zustellung).
Die Affiliationsdatei
Mit dieser besonderen Datei (einer .csv-Datei mit genau sechs Spalten: Name Variants, Domains, Grant Numbers, Dummy1, Dummy2 und Keywords) gibt eine Institution an, mit welchen (Namens-)Ansetzungen sie Publikationen zugeordnet bekommen möchte.
Bemerkungen:
- Die Spalten Dummy1 und Dummy2 haben bisher keinerlei Funktion in DeepGreen und sollte daher stets leer bleiben. Diese Spalten sind für zukünftige Erweiterungen frei gelassen.
- Pro Zeile müssen auf alle Fälle genau fünf Kommata gegeben sein.
- Alle Spalten werden als unicode-Zeichenketten eingelesen und interpretiert. Für die interne Verarbeitung innerhalb DeepGreens wird die nfd-Normalisierung von unicode verwendet (vgl. https://www.unicode.org/reports/tr15/)
Beispiel einer match-config-Datei
Die erste Zeile (header) ist unveränderlich und muss stets so lauten
Name Variants,Domains,Grant numbers,Dummy1,Dummy2,Keywords
Academia Friedericiana Erlangensis,,,,,
Academia Friderico-Alexandrina Erlangen-Nürnberg,,,,,
Academia Friderico-Alexandrina,,,,,
Academia Regia Bavarica Friderico-Alexandrina,,,,,
Academia Regia Friderico-Alexandrina,,,,,
Bayerische Friedrich-Alexanders-Universität,,,,,
F.A.U. Erlangen-Nürnberg,,,,,
FAU Erlangen-Nürnberg,,,,,
Friedrich Alexander University,,,,,
Friedrich-Alexander-Universität Erlangen,,,,,
Friedrich-Alexander-Universität Erlangen-Nürnberg,,,,,
Friedrich-Alexander-Universität zu Erlangen,,,,,
Friedrich-Alexander-University Erlangen,,,,,
Friedrich-Alexanders-Universität,,,,,
Friedrichs-Akademie,,,,,
Königlich-Bayerische Friedrich-Alexanders-Universität,,,,,
Univ. Erlangen-Nürnberg,,,,,
Universidad de Erlangen-Núremberg,,,,,
Universidad de Erlangen-Nürnberg,,,,,
Universitas Literarum Regia Friderico-Alexandrina,,,,,
Università di Erlangen-Nürnberg,,,,,
Universität Erlangen,,,,,
Universität Erlangen-Nürnberg,,,,,
University Erlangen-Nuremberg,,,,,
University of Erlangen-Nuremberg,,,,,
University of Erlangen-Nürnberg,,,,,
,fau.de,,,,
,uk-erlangen.de,,,,
,uni-erlangen.de,,,,
,,,123456-563/2,,
,,,99988/365-2,,
Je mehr, je umfassender und je genauer die Angaben in dieser Datei sind, desto treffsicherer kann DeepGreen anhand der Verlagsmetadaten eines Artikels herausfinden, ob die fragliche Publikationen einer Institution zuzuordnen ist oder nicht.
Forum
Bleiben Sie in Kontakt!
Nutzen Sie für den Austausch mit anderen DeepGreen-Anwender:innen gerne die Mailingliste „deepgreen-forum@zib.de“:
https://listserv.zib.de/mailman/listinfo/deepgreen-forum
Mit der Vergabe eines Passworts kann dann auch das bisherige Nachrichtenarchiv eingesehen und darin gesucht werden.
Screencasts
