JusCMS Videoconference 2009-05-19

JusCMS

Termin und Teilnehmer Videokonferenz
Datum: '''19. April 2009''' Ort: MaxPlanck Digital Library, München + MPI für ausländisches und internationales Privatrecht, Hamburg + MPI für Geistiges Eigentum Zeit: 10:00 Uhr bis 12:00 Uhr Teilnehmer: Sylvia Kortüm (MPI GE, M) Gergana Stoyanova (MPI GE, M) Heiner Leitl (MPI GE, M) Irina Arndt (MPI Privatrecht, HH) Nicola Wesselburg (MPI Privatrecht, HH) Malte Dreyer (MPDL, M) Natasa Bulatovic (MPDL, M) Ulla Tschida (MPDL, M) Dietmar Bussmann (MPI Völkerrecht, Heidelberg)

Codenachnutzung

 * Neuer Code muss im PubMan verfügbar sein, Code wird nach Release für MPDL nutzbar (Bussmann).
 * Wichitge Voraussetzung für die AG-Technik: Der neue Code ist Bestandteil des Core-Services und muss in allen Realeses von PubMan nachgezogen bzw. verfügbar sein.

Backup-Datenbank für CMS
Folgende Punkte zum möglichen Auslesen der Daten werden diskutiert:

Über die drei Back-up Datenbankvarianten kann hier nachgelesen werden: 
 * (DB1) Einfache Kopie der Cache-Datenbank
 * (DB3) Extra-Datenbank muss man aus dem Projekt rauskoppeln. Es bleibt nur Aufgabe der Institute.


 * Bei den Ansätzen (DB1 oder Schnittstelle) kümmert sich jedes Institut um die Weiterverwendung der Daten. (Gefahr: Bei einem doppelten Export (Backup-Datenbank + CMS) werden die Daten doppelt gespeichert. Es entstehen Probleme bei der Synchronisation der drei Datenbestände (MPDL Bulatovic)).

Datenübertragung PubMan -> CMS

 * Administrator-View: Admin holt alle Daten vom PubMan und legt die auf dem Server (Busmann).
 * Modell Nijmengen: Daten werden 2 Mal am Tag zum Institut-Server übertragen. Daten stehen lokal verfügbar und können vom Wissenschaftler publiziert werden.
 * Gesamtabzug 2 Mal pro Tag, Institute entscheiden selber, was die mit den Daten machen. Beispiel für 10 000 Items bruacht man ca. 50 Sekunden beim Auslesen der gesamten Daten und überschreiben der lokal verfügbaren Daten. Grösse der Daten aber ca. 500MB. Besser ist inkrementieller Export nur der "neuen" Einträge. (MPDL Dreyer).

Schnittstelle

 * REST-Schnittstelle (weiter)entwickelt und betreut von MPDL (Nachfolger CQL?). Es wird eine URI abgefragt mittels GET und XML übertragen.
 * Interface ist standartarisiert und wird auch für die neuen Versionen funktionieren
 * Eine REST-Schnittstelle von PubMan steht im Prinzip allen Instituten zur Verfügung, jedes Institut zieht aus der Datebank von PubMan die Daten mit bestimmten Abfragen. XML ist das Austauschformat für die Institute.
 * Bedarfsorientierter Export der Daten möglich (MPDL Dreyer)
 * Das gleiche Interface kann für die Übertragung für CMS und die Backup-Datenbank benutzt werden.

Stand der Technik-AG

 * Ein Bericht wird bis Ende der 21. Kalenderwoche erstellt.

Contents

 * Wie genau werden die Daten in Contents gehalten? In separeter DB oder in jetztiger DB von Contents (Leitl)?
 * Nicht Bestandteil dieser Besprechung, evtl. ein Angebot von Contents (Bussmann)
 * Nijmengen: 1 PubMan-Object entspricht 1 CMS-Object

Zitierweise

 * Zitierstile werden auf Seite von CMS dargestellt und nicht in PubMan (Wunsch von Hamburg.
 * 1.6.1 wäre trotzdem für alle Institute die Lösung sein, da die Zitierstile auch auf Seite von PubMan generiert werden.
 * 1.6.1 Variante 1 - wie bei Nijmengen (1 Hauptzitierstil für die Publikationsseiten der Wissenschaftler).
 * 1.6.2 Varinate 2 - von Hamburg für die eigenen Seiten bevorzugt, eigene Zitierstile bereits verfügbar und auf CMS-Objekte anwendbar.
 * Vorschlag Busmann: Ein Stil für alle Publikationen, die im PubMan verfügbar sind.

Projekt Nijmengen

 * Administrator fragt die Daten für das ganze System ab.
 * User hat lokale Tags und dementsprechend werden die Daten auf der Seite der Wissenschftler angezeigt.
 * Es steht die Frage wie das CMS-Systems mit den von PubMan empfangenen Daten arbeitet (es wird bei den WorkPackages entschieden).

Anzeigen der Daten im CMS

 * Push-(SWORD) oder Pull-Mechanismus(REST) von Variante 1.6 wurden besprochen.
 * Voteil von Push - Daten können theoretisch sofort im CMS zu Verfügung stehen. SWORD wird von Contents derzeit nicht unterstützt.
 * Akzeptabel wäre auch Update der Liste per Button-Click (Refresh My Page).
 * RSS-Ansatz ist auch möglich.
 * siehe auch Datenübertragung PubMan -> CMS

Änderung der Daten im CMS

 * Projektgruppe verständigt sich auf einer einseitigen Synchronisation, keine beidseitigen, nur PubMan -> CMS (d.h. keine Änderung der Daten im CMS).

CoNe-Service für Personennamen

 * CoNe ist nicht für die Authentifizierung gedacht.
 * Es ist eine Vorschlagsliste für Autorennamen bei Eingabe.
 * Das Fortschreiben ist das Problem.
 * Lokale IDs des Instituts werden in CoNe mitgeführt (Beipsiel Institut für MPI für ICE).
 * CoNe bietet viele Schnittstellen für automatisches Befüllen der Daten.

Single-Sign-On

 * Identity-Provider wird von MPDL entwicklet.
 * Authentifizierung in PubMan und CMS, wie wird das funktionieren?
 * Verteilte LDAP-Authentifizierung geht nur über Shibboleth, aber wird nicht von Contents unterstützt.
 * Es ist nur eine Nice-to-have-Option (Bussmann).
 * Authentifizierung über einem LDAP-Server oder Shibboleth (mehrere LDAP-Server) wird jetzt vom MPDL unterstützt.
 * Meta-Directory muss mit einer zentralen LDAP-Instanz synchronisiert werden.
 * OAuth ist auch eine Option, die von Contents unterstützt wird, auf Seite von PubMan muss es jedoch noch implementiert werden.

Fazit (AG-Technik)

 * Kristalisiert sich die Variante 1.6.1 als präferierte Lösung heraus.
 * Unter der Voraussetzung, dass eine zusätzliche gesonderte Datensicherung stattfindet.
 * Herr Jähnke (MPI Strafrecht, Freiburg) vertraut seinen Partnern der Tehnik AG bezüglich der Datenbank-Lösung.
 * Entwicklung des neuen Codes wird Bestandteil der Core-Services von PubMan.

Weiteres Vorgehen

 * Am Montag, der 25.05., wird ein Papier von der Technik-AG vorbereitet. Koordination Herr Leitl(MPI IP M)
 * Anfang KW 22 Abstimmung im Board.
 * Als Ergebnis wird bis Ende KW 22 Fertigstellung der Entscheidungsvorlage fuer den LA. Maximal 1 Seite Zusammenfassung und 3 Seiten Anhang (Kortüm und Stoyanova).