JusCMS Architecture Options

JusCMS,MPDL

Diese Seite beinhaltet Optionen für die Umsetzung einer Publikationsdatenverwaltung in das CMS der Juristischen Institute. Die hier beschriebenen Architektur-Optionen bilden den Ausgangspunkt des geplanten Architektur-Workshops. Auf der Diskussionsseite dürfen gern weitere Hinweise, Fragen, Ergänzungen etc. hinzugefügt werden.

=Grundsätzliche Anforderungen= Daten zu Publikationen der Mitarbeiter werden durch eine Maske, erreichbar über das im Rahmen der Kooperation der fünf juristischen Max-Planck-Institute benutzte Contens-CMS, erfasst und an entsprechenden Stellen abgebildet. Primäre Verwendung ist die den juristischen Standards genügende Anzeige von Publikationen auf Webseiten der Institute (z.B. Publikationslisten einzelner Mitarbeiter oder aller Mitarbeiter, einzelner Abteilungen und Projekte) sowie die Erfassung für den zentralen eDoc Server bzw. für den in Planung befindlichen Nachfolger eSciDoc/PubMan der MPG.

=Konzepte=

Konzept I: Primäre Datenhaltung in eDoc bzw. eSciDoc
Alle Publikationsdaten werden in eDoc bzw. eSciDoc/PubMan gehalten; die Anzeige der Daten auf den Webseiten der Institute (Contens-CMS) erfolgt mittels Referenzierung.

Primäre Datenhaltung in eDoc
a) Vorteile: b) Nachteile:
 * keine neuen Server nötig
 * definierte Felder bzw. Inhalte für Im-/Export vorhanden
 * geringerer Aufwand und niedrigere Kosten für Planung und Entwicklung als in allen anderen Konzepten
 * angelegte Publikationskategorien und Felder decken nicht den Bedarf der juristischen Institute ab
 * juristische Zitierweise kann aufgrund definierter Felder und Inhalte auf den Webseiten der Institute nicht eingehalten werden
 * eDoc befindet sich im Umbruch (siehe unten 1.2)
 * Abgleich mit Contens-CMS mittels Referenzierung ist technisch schwierig und ressourcenintensiv (Schätzung: 1 MannMonat)

Primäre Datenhaltung in eSciDoc/PubMan
Nach Gesprächen mit der MPDL (mit Herrn Romary, siehe Gesprächsnotiz Phillip Brunst vom Termin 25.07.07 und Herrn Dreyer, siehe Gesprächsnotiz Florian Bruder und Sylvia Kortüm vom Termin 04.09.07) zeichnen sich Möglichkeiten ab, auf die Entwicklung von eSciDoc/PubMan Einfluss zu nehmen. Denkbar wäre, eSciDoc/PubMan als Repository zu nutzen (Alternativen: „early adopter“ Prozess oder Entwicklung einer Speziallösung auf dem Hauptrepository, ausführlich dazu o.g. Gesprächsnotiz vom 04.09.07), sofern die Anforderungen der Institute erfüllt werden. a) Vorteile: b) Nachteile:
 * (siehe 1.1. Primäre Datenhaltung in eDoc)
 * eSciDoc noch in Entwicklungsphase: Realisierung und Zeitpunkt einer Nutzbarkeit ungewiss (aber: schriftliches Konzept vorhanden und „working prototype“ in der Testphase, so dass sich eine Konkretisierung abzeichnet)
 * bei „early adopter“ Prozess: aufgrund grundsätzlich unterschiedlicher Ansätze (CMS-Projektgruppe: Darstellung der Daten nach juristischer Zitierweise; eSciDoc/PubMan: Darstellung der Daten im Stil eines Bibliothekskatalogs) fraglich, ob konzeptionelle An-forderungen erfüllt werden können
 * bei „early adopter“ Prozess: Lösung technisch aufwendig und Umsetzung aufgrund Abhängigkeit externer Datenhaltung sowie Vorgaben für Datenstruktur und Inhalte als eige-ne Datenbank (siehe unten Konzept 3) problematischer
 * Einsatz eigener Mitarbeiter und Contens (und/oder andere Fremdfirma) für „Verbindungen“ zu den Verwendungen (z.B. Anzeige auf den Webseiten der Institute mittels Referenzierung) erforderlich: Kosten möglicherweise nicht geringer als bei Aufbau einer eigener Datenbank (siehe unten Konzept 3) – mit Prüfungsvorbehalt
 * eSciDoc/PubMan Grundkonzept angeblich mit Mängeln behaftet: Eindeutigkeit der Datensätze, Performanz und Konsistenz (informelle Hintergrundinformation über MPI Sozialrecht; siehe Gesprächnotiz Florian Bruder und Sylvia Kortüm vom Termin 11.09.07, Kritikpunkte MPI Sozialrecht, E-mail vom 02.10.07 sowie Bewertung durch Jochen Jähnke, E-mail vom 08.10.07); weitere technische Überprüfung wäre erforderlich und sinnvoll

Konzept II: Datenhaltung in Contens-CMS
Beauftragung von Contens zum Aufbau einer den Anforderungen der Institute genügenden und im CMS integrierten Datenbank a) Vorteil: b) Nachteile:
 * Erforderliche Eigenleistung der CMS-Projektgruppe voraussichtlich am geringsten
 * Ausweitung der „Monopolstellung“ von Contens bzgl. Entwicklung, Aufbau, Betrieb, Fehlerbehebung, Wartung, etc.
 * mögliche Probleme bei späterer Anschaffung neuer Systeme bzw. Migration
 * zusätzliche Kosten einer externen Firma (hier: Contens) für Entwicklung und Betrieb

Konzept III: Datenhaltung in eigenständiger SQL-Datenbank bzw. eigenständigem Repository
Beauftragung einer für eigene Zwecke angepassten Literaturdatenbank als eigenständige SQL-Datenbank bzw. als eigenständiges XML-Repository, die/das auf einem eigenen DBMS-System (z.B. dem Oracle-Server in Heidelberg) läuft. Die Daten werden von dieser Datenbank bzw. von diesem Repository zu eDoc bzw. eSci-Doc/PubMan transferiert.

Datenhaltung in eigenständiger SQL-Datenbank
a) Vorteile: b) Nachteile:
 * autonome Lösung, im Hinblick auf Betrieb und (Weiter-)entwicklung sowie Anschaffung neuer Systeme
 * Anforderungen der CMS-Projektgruppe können erfüllt und nachträglich verändert werden
 * Beauftragung einer Fremdfirma (neben Contens) für Entwicklung und Betrieb der Daten-bank möglich, auch Einschaltung konkurrierender Firmen zu einem späteren Zeitpunkt denkbar
 * Aufwand für Betreuung einer weiteren Datenbank, möglicherweise eines weiteren Systems
 * externe Kosten für Entwicklung (wie bei Konzept 2; aber: evtl. geringere Betriebskosten)
 * „Verbindungen“, d.h. Eingabemaske – Daten/Repository - Referenzierungen der Internetseiten (Abfrage einer SQL-Datenbank zum Zeitpunkt der Publikation der Seite) müssen durch Drittfirma (Problem der Rechte von Contens) bzw. Contens aufgebaut werden (jedoch: kein großer technischer Aufwand zu erwarten)

Datenhaltung in Speziallösung der MPDL mit eigenständigem eSciDoc-Repository
Mit Unterstützung der MPDL (siehe Gespräche mit Herrn Romary, siehe Gesprächsnotiz Phillip Brunst vom Termin 25.07.07 und Herrn Dreyer, siehe Gesprächsnotiz Florian Bruder und Sylvia Kortüm vom Termin 04.09.07) wäre auch denkbar, eine Speziallösung auf einem eigenständigen Repository (Alternativen: Kopie oder Weiterentwicklung des Hauptreposito-ries, ausführlich dazu Gesprächsnotiz vom 04.09.07) aufzubauen. a) Vorteile: b) Nachteile: Hinweis:updates/upgrades problematisch, wenn sich unser eigenständiges System bzw. Repository von dem der MPDL wegentwickelt.
 * (relativ) autonome Lösung
 * Anforderungen der CMS-Projektgrupe können erfüllt und nachträglich verändert werden
 * Nutzung der Ressourcen der MPDL für den Aufbau (siehe ausführlich dazu Gesprächsno-tiz vom 04.09.07)
 * Aufwand für Betreuung einer weiteren Datenbank, möglicherweise eines weiteren Sys-tems
 * „Verbindungen“, d.h. Eingabemaske – Daten/Repository - Referenzierungen der Internet-seiten (Abfrage einer SQL-Datenbank zum Zeitpunkt der Publikation der Seite) müssen durch Drittfirma (Problem der Rechte von Contens) bzw. Contens aufgebaut werden (je-doch: kein großer technischer Aufwand zu erwarten)
 * eDoc/PubMan Grundkonzept angeblich mit Mängeln behaftet: Eindeutigkeit der Daten-sätze, Performanz und Konsistenz (informelle Hintergrundinformation über MPI Sozial-recht; siehe Gesprächnotiz Florian Bruder und Sylvia Kortüm vom Termin 11.09.07)

=Empfehlung der CMS-Projektgruppe=

Anmerkungen zu den Konzepten

 * Konzept 1 wird wegen Abhängigkeit von eDoc / eSciDoc nicht empfohlen
 * Konzept 2 wird wegen Abhängigkeit von Contens nicht empfohlen, die Architektur des Contens-CMS eignet sich nicht für eine Literaturdatenbank.
 * Konzept 3 wird empfohlen (sofern keine Mängel des Grundkonzepts)

Empfehlungen innerhalb von Konzept 3 (nach derzeitigem Stand Informationen)

 * Variante 3.2. Umsetzung eines eigenständigen Repositories durch MPDL - wahrscheinlich kostengünstigstes Konzept (Klärung der angeblichen grundlegenden Mängel erforderlich)
 * Variante 3.1. Umsetzung einer eigenständigen Datenbank durch Contens (und/oder Dritt-firma)
 * sofern alles aus der Hand von Contens: voraussichtlich am wenigsten institutsres-sourcenintensiv; aber kostenintensivstes Konzept (Angebot von Contens angefor-dert: nach wie vor leider keine ausreichende Reaktion)
 * Bindung an Contens kann wegen Verwendung des Contens-CMS bzw. wegen der damit verbundenen „Schnittstellen“ sowieso kaum ausgeschlossen werden