Nach und nach werden alle derzeitig in eDoc oder alternativen Systemen/Programmen archivierten MPG-Publikationen in das mit der PubMan-Software betriebene Publikations-Repositorium MPG.PuRe migriert.
Diese Seite dient als Informationsplattform zum genauen Ablauf einer Migration sowie über die dafür notwendigen Vorbereitungen.

Wir empfehlen allen Interessenten, bei Gelegenheit schon einmal einen Blick auf das System zu werfen, um die grundlegenden Funktionalitäten und Abläufe kennen zu lernen. Dies wird Ihnen mit Sicherheit dabei helfen, viele Fragen, die sich im Zuge der Migration ergeben werden, besser einschätzen zu können:
Allgemeine Funktionen können auf dem Produktivsystem selbst ausprobiert werden.
Daneben haben wir einen PubMan Testserver. Da es sich hier um eine "Sandkasten-Umgebung" handelt, können Sie nach Belieben testen und sämtliche Arbeitsschritte nachvollziehen.

Login: demo

Passwort: demo

Ihr Institut möchte migrieren? Bevor es losgeht sollten folgende Fragen geklärt werden.[edit]

In welcher Weise möchten das Institut die PubMan-Daten nachnutzen? (Instituts-Homepage, Wissenschaftler-Homepages, Blogs, MPG Jahrbuch)

Welche für das Institut wichtigen Funktionalitäten bietet PubMan evtl. derzeit noch nicht? (Schnittstellen, Export-/Import-Formate, Zitierstile, Genretypen, etc.)
Aus welcher Quelle sollen die Daten migriert werden? Aus eDoc oder einem alternativen Literaturverwaltungsprogramm, wie z.B. EndNote, Reference Manager, WoS etc.? Ausschlaggebend ist hier die beste Datenqualität.
Welcher Zeitpunkt ist der Richtige für eine Migration?
- Der Zeitpunkt ist abhängig von:
  - ... der Frage, ob vor einer Migration neue Funktionalitäten implementiert werden müssen.
  - ... in naher Zukunft anstehenden Terminen am Institut; z.B. Fachbeirat, Jahrbuch oder Arbeiten an der IT Infrastruktur etc. Wir empfehlen eine Migration mindestens etwa 9 Monate vor Beginn der Vorbereitungen zum nächsten Fachbeirat zu beginnen.
  - ... dem Zeitplan der MPDL (fest terminierte Migrations-Slots).
Welchen Zeitraum muss das Institut für eine Migration ihrer Daten einplanen?
- Der Zeitraum ist abhängig von:
  - ... der Qualität der zu migrierenden Daten (wieviele Test-Migrationen und Anpassungen im Mapping werden benötigt etc.).
  - ... den am Institut für die Durchführung einer Migration zur Verfügung stehenden Ressourcen.
  - ... den Kapazitäten in der MPDL.

Die zentralen Konzepte der Migration[edit]

Der eDoc Datenreport[edit]

Die MPDL fertigt einen eDoc Datenreport an. Dieser informiert über die Inhalte aller eDoc-Felder, die in PubMan nicht vorhanden sind und deshalb ein instituts-spezifisches Mapping verlangen.
Dies betrifft derzeit die Felder:

Author Comment
Research Context
Copyright Info
File Comment

Außerdem wird der Status aller Volltexte aufgelistet, die eine andere Sichtbarkeit haben, als "public".

Die ebenfalls aufgelisteten Referenzfelder (Is Version of, Has Source, Is Referenced by,...) können in PubMan so nicht abgebildet werden. Bitte beachten Sie, dass alle hier eventuell aufgeführten Identifier (URL, arXiv, Doi, etc.) sich auf externe Datensätze beziehen.

Das Institut prüft, ob die Inhalte übernommen, verworfen oder abgeändert werden müssen, bzw. in welche PubMan-Felder die eDoc-Informationen ggf. übernommen werden sollen. Die MPDL bestätigt oder modifiziert die Vorschläge des Instituts.

Die Organizational Units (OUs)[edit]

Die Organizational Units sind eines der zentralen Konzepte, die PubMan zugrunde liegen. Sie bilden einen wichtigen Einstiegspunkt in PubMan und ermöglichen die unkomplizierte Generierung von Publikationslisten zur weiteren Verarbeitung. Das Institut elaboriert eine für seine Ansprüche geeignete OU-Struktur. Diese kann flach oder auch hierarchisch gestaltet werden. Hilfreich ist möglicherweise ein Blick auf die vorhandenen Strukturen der bereits migrierten Institute.

Flache Strukur:

Leichter zu handhaben
Flexibel (bei dynamischen Strukturen am MPI)
Unübersichtlich – nicht selbsterklärend
Zentraler Einstieg soll die eigene (Instituts-) Homepage sein?

Hierarchische Struktur:

Übersichtlich – Selbsterklärend
Frage der Außendarstellung: Die Binnenstruktur des MPI kann abgelesen werden (inkl. Über-, Unterordnung einzelner Teil-OUs)
Zentraler Einstieg
Unflexibel – Die Struktur sollte sorgfältig durchdacht werden

Die CoNE Persons[edit]

Das Institut erstellt eine Auflistung aller am Institut tätigen WissenschaftlerInnen inklusive Angabe der zugehörigen Affiliation (OU) sowie unterschiedlichen Namens-Ansetzungsformen. Jede Person wird unter einer bestimmten ID im System hinterlegt. Eine detaillierte und korrekte Ausarbeitung dieser Personen-Liste ist sehr wichtig. Sie bedeutet, je nach Größe des Instituts, einen hohen Arbeitsaufwand auf Seiten des Instituts, der sich jedoch durchaus lohnt: Zu jeder im System hinterlegten Person kann „auf Knopfdruck“ eine vollständige Liste aller in PubMan hinterlegten Publikationen generiert werden. Eine Beispieldatei (Excel), die bei der Erstellung der Personen-Liste für CoNE als Orientierungsvorlage behilflich sein kann, befindet sich hier.

Für jeden Autoren muss mindestens eine Namensform angegeben werden, beim Vornamen kann dies auch nur die Initiale sein. Es ist wichtig, für die Migration mindestens alle in den zu importierenden Datensätzen vorkommenden Ansetzungsformen eines Namens zu erfassen. Nur dann ist gewährleistet, dass ein Datensatz beim Import nach PubMan erfolgreich dem korrekten CoNE-Autoren zugeordnet werden kann. Darüber hinaus ist es nicht notwendig, alle theoretisch denkbaren Varianten eines Namens vollständig zu erfassen!

Außerdem benötigt jeder Autor mindestens eine Organisationseinheit als Affiliation. Dabei ist darauf zu achten, dass die hier eingetragenen Affiliations wortwörtlich mit den Bezeichungen der OUs übereinstimmen, die für das betreffende Institut in PubMan angelegt werden sollen. Die Affiliations müssen stets in der obersten Zeile eines Personeneintrags eingetragen werden. Es ist möglich, einem Autor mehrere Organisationen zuzuordnen: Die Affiliations müssen in diesem Fall einfach untereinander eingetragen werden.
Eine zeitliche Zuordnung der Affiliations über Datumsangaben kann im Rahmen der Excel-Tabelle nicht vorgenommen werden. Dies ist nur in begrenztem Maße durch händische Ergänzung möglich.

Schließlich muss bei jedem Autoren noch eine Namensform als "Haupteintrag" festgelegt werden, der dann später im Kopf des Researcher Portfolio angezeigt wird.
Die Angabe zum Abschluss/Titel ist optional.

Als Grundlage zur Erstellung einer solchen CoNE-Personen-Datei kann auf Instituts-Wunsch hin von der MPDL ein Abzug aller Autoren der entsprechenden Collection(s) auf eDoc (bei Bedarf auch ausgewertet nach MPG-Autoren) erstellt werden.

Beim Import in PubMan erfolgt die standardmäßige Zuordnung von Affiliations dann so:

Wenn ein Autor von CoNE erkannt wird, bekommt er die dort hinterlegte(n) Affiliation(s). Sind in CoNE Datumsangaben hinterlegt, wird die Affiliation nur vergeben, wenn das Datum der jeweiligen Publikation innerhalb des in CoNE festgelegten Zeitraumes liegt.
Wird ein Autor nicht von CoNE erkannt, hat aber in eDoc die Markierung "MPG" bekommen (Häkchen in der Eingabemaske), dann wird ihm manuell die Affiliation "Max Planck Society" zugewiesen.
Alle anderen Autoren bekommen gar keine Affiliation

Die Handhabung von Volltexten[edit]

Sichtbarkeit (Zugriffskontrolle): Welchen Status sollen die migrierten Volltexte auf PubMan bekommen? eDoc "kennt" in dieser Hinsicht fünf verschiedene Stufen, während es in PubMan lediglich drei sind (public, private, restricted). Unter "restricted" ist die Beschränkung des Zugriffs auf eine bestimmte, jeweils zu definierende Nutzergruppe zu verstehen.
Die Institute müssen also klären, nach welchen Kriterien die Sichtbarkeit der einzelnen Volltexte im Zuge der Migration eingestuft werden soll. Dafür kann der eDoc Datenbericht eine erste Übersicht liefern (s.o.).

Inhaltskategorie: Diese Kategorie wir in PubMan angegeben, um die Art des betreffenden Volltextes näher zu bestimmen. Es gibt derzeit die Kategorien: Any Fulltext, Preprint, Postprint, Publisher Version, Abstract, Table of Contents, Supplementary Material, Correspondence und Copyright Transfer Agreement. Die Institute sollten sich nun eine Logik überlegen, nach der diese Kategorie bei der Migration vergeben wird. Eine einfache, aber nicht sehr genaue Lösung bestünde darin, alle Volltexte generell als Any Fulltext zu kennzeichnen. Gegebenenfalls können auch hier Metadaten-Einträge von eDoc als Unterscheidungsgrundlage hinzugezogen werden. Dabei bietet der Datenbericht eine gute Übersicht über die vorhandenen Möglichkeiten. Es ist zum Beispiel denkbar, alle Volltexte, die einen arXiv-Identifier in den Metadaten aufweisen, als Preprint zu kennzeichnen.

Visualisierung der einzelnen Migrations-Phasen[edit]

Vorgehen in den einzelnen Migrations-Phasen[edit]

PHASE 1: VORBEREITUNGEN[edit]

PHASE 1.1[edit]

die MPDL stellt entsprechende Informationen zum Ablauf und zum Vorgehen bei der Migration zur Verfügung (via Mailkontakt, Telefonaten oder gegebenfalls bei einem Institutsbesuch)
die Migrations-Kandidaten erhalten detaillierte Erklärungen zu den drei zentralen Konzepten eDoc Datenreport, OU-Struktur und CoNE Personen
instituts-spezifische Fragen werden geklärt
auf dem Migrations-Server wird ein Test-Account angelegt und ein erster Test-Import von eDoc-Daten eines bestimmten Jahres eingespielt
die MPDL erstellt den eDoc-Datenreport als Grundlage zur weiteren Erarbeitung eines instituts-spezifischen Mappings am Institut
bei Bedarf erstellt die MPDL eine Autorenliste aller in eDoc für das entsprechende Institut eingegebener Autoren als Unterstützung zur Erstellung der CoNE Personen-Liste

PHASE 1.2[edit]

Das Institut hat den ersten Test-Import ihrer Daten auf dem Migrations-Server erhalten und überprüft welche Datenqualität durch das generische eDoc2PubMan-Mapping erreicht werden kann.
- Das Institut notiert sich basierend auf dieser Überprüfung die im Mapping zu beachtenden instituts-spezifischen Besonderheiten.
Das Institut hat den eDoc Datenbericht erhalten und bearbeitet die zusandte Excel-Datei dahingehend, dass gekennzeichnet wird:
- wohin die einzelnen Felder in PubMan übernommen werden sollen.
- welche Felder bei der Migration gegebenenfalls wegfallen können.
Das Institut bereinigt seine eDoc-Daten:
- Beseitigen von Dubletten
- Auswahl der zu migrierenden Daten
- Anpassungen an einzelnen Datensätzen
Das Institut erarbeitet eine OU-Struktur.
Das Institut erstellt eine CoNE Personen-Liste.
- Voraussetzung dafür ist eine finale OU-Struktur, da die angegebenen Affiliations mit den Organisationseinheiten (wortwörtlich) übereinstimmen müssen!
Das Institut trifft weitere Vorbereitungen für die Arbeit mit PubMan :
- Wie ist der Publikations-Workflow am Institut gestaltet? (Simple oder Standard Workflow)
- Wieviele und welche Contexte werden benötigt?
- Wieviele und welche Nutzeraccounts werden benötigt?

Lieferfrist zur Abgabe der Vorbereitungen aus Phase 1.2[edit]

Die MPDL kommuniziert ein festes Datum als Lieferfrist für folgende Ausarbeitungen:
- finale OU-Struktur
- finale CoNE Personen-Liste
- überarbeiteter eDoc Datenreport
- Notizen/Überlegungen zu instituts-spezifischen Anpassungen im Mapping (basierend auf der Überprüfung des ersten Test-Imports)
- Einstellungen auf dem Live-Server (Workflows, Contexte, Nutzeraccounts)
- gewünschtes Datenset für die Testmigrationen
Außerdem müssen bis zu diesem Datum die datenbereinigenden Maßnahmen auf eDoc abgeschlossen sein.

PHASE 2: TESTMIGRATIONEN[edit]

Es folgt ein Zeitraum von mehreren Wochen, der sich an den Termin der Lieferfrist anschließt.

PHASE 2.1[edit]

Das Service Management-Team in der MPDL bereitet die Dokumentation des instituts-spezifischen Mappings auf, legt die finale OU-Struktur auf dem Migrations-Server an und bereitet (falls notwendig) die gelieferte CoNE Personen-Datei auf.
Die Zeit während der Vorbereitungen für den ersten Testimport (die einige Wochen andauern können), sollten die Institute nutzen, um sich durch intensives Ausprobieren (auf dem Test- oder Migrationserver) mit dem System vertraut machen. Für das spätere Testing und natürlich auch die Arbeit mit PubMan ist es enorm hilfreich, wenn man sich bereits einen gewissen Überblick verschafft hat und mit den wichtigsten Funktionen und Abläufen einigermaßen vertraut ist.

PHASE 2.2[edit]

Das Entwickler-Team der MPDL spielt die CoNE Personen-Datei ein und implementiert entsprechende Anpassungen im instituts-spezifischen Mapping.
Es erfolgt eine erste Testmigration unter der Berücksichtigung der finalen OU-Struktur, des instituts-spezifischen Mappings und der CoNE Personen-Zuweisung.
Das Institut überprüft die importierten Daten auf Vollständigkeit und Korrektheit. Gewünschte Änderungen teilt es dem Service Management-Team der MPDL gesammelt per Mail mit.
Die gewünschten Änderungen werden implementiert und ein erneuter Test-Import wird eingespielt.
Daran schließt sich ein erneutes Testing von Seiten des Institutes an.
Die Phase der Testmigration ist überlicherweise charakterisiert durch mehrere Iterationen.
Um einen zügigen Ablauf dennoch garantieren zu können, sollte jedoch darauf geachtet werden, dass die zu Testzwecken migrierten Daten detailliert und umfassend vom Institut getestet werden, so dass Änderungswünsche mit Abschluss der Testing-Phase gesammelt an die MPDL geschickt und dort weiter verarbeitet werden können.

PHASE 3: FINALE MIGRATION[edit]

Nachdem die Phase der Test-Migrationen abgeschlossen ist, erfolgt die finale Migration der Publikations-Daten des Instituts.
Das Service Management-Team der MPDL nimmt die gewünschten Einstellungen auf dem Live-Server vor (OU-Struktur, Nutzeraccounts, Contexte, Workflows etc.)
Das Entwickler-Team der MPDL migriert die Daten auf den Live-Server.

Migrierte Institute[edit]

Institute in Vorbereitung[edit]

Weiterführende Links[edit]

XSLT Transformation von eDoc nach eSciDoc (MPDL-intern)

EDoc to PubMan migration

Contents