JusCMS Architecture Options 1

JusCMS,MPDL

=Konzepte= Nachstehend eine kommentierte Kopie der Archtekturoptionen aus dem Projektantrag. rot = Kommentare Hamburg

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.

Nachteile der Referenzierung:
 * 100%ige Abhängigkeit CMS/PubMan
 * Performanz wird in Frage gestellt
 * hohe Fehleranfälligkeit
 * globale Suche bedeutet aufwändige Programmierung über zwei Systeme

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 Ist in Frage gestellt.
 * 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) s. Nachteile "Referenzierung allgemein"
 * keine Weiterentwicklung für Datenexport und Schnittstellen

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)
 * individuelle Anpassung von PubMan entsprechend unserer Anforderungen voraussichtlich möglich
 * 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) Zeitpunkt der Nutzbarkeit ist erreicht
 * 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 Anforderungen erfüllt werden können nach Aussage MPDL jetzt machbar
 * bei „early adopter“ Prozess: Lösung technisch aufwendig und Umsetzung aufgrund Abhängigkeit externer Datenhaltung sowie Vorgaben für Datenstruktur und Inhalte als eigene 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


 * Details Kritikpunkte / Erfahrungsbericht
 * Zusammentragung von Gesprächsnotizen aus 2007 von Mitarbeitern und Ehemaligen (aus Diskretionsgründen keine Namensnennung; Kritikpunkte wurden versachlicht):
 * Datenmigration eDoc/PubMan problematisch (Kommentar 2009: Migration für MPI PLI hat bereits stattgefunden. Probleme??)
 * Tabelle mit Kritikpunkten erstellt, spezifisch zu eDoc, aber evtl. auch relevant für eSciDoc (Kommentar Hamburg 2009: Tabelle liegt leider nicht vor)
 * Kritik an Grundkonzeption eSciDoc (Probleme der Eindeutigkeit, Performanz, Konsistenz): XML-setup birgt Probleme der Eindeutigkeit und Klarheit in sich; fehlt und muss mit erheblichem Programmieraufwand hergestellt werden (eDoc als relationale Datenbank würde bei Anpassungen funktionieren)
 * Probleme: eindeutige Definition von Daten
 * eSciDoc wird ein großer Container; es wird schwierig sein, Daten wieder zu finden und konsistent zu halten
 * in der Vorversion angeblich schon Performanceprobleme – JAVA.
 * Jahrbuchdaten aus eDoc/PubMan: wie wird das laufen?
 * Grundproblem der Eindeutigkeit der Datensätze kann durch riesige Maschinerie kaschiert werden, aber Grundprobleme bleiben und kommen wieder hoch
 * Performanz und Konsistenz: kann nicht ordentlich erreicht werden
 * Risiko, dass eSciDoc nicht läuft
 * es bestehen Zweifel am Projekt "Fedora" (Kommentar Hamburg: Worum geht's?)
 * Updates / Upgrades: Das Hauptrepository ist ständiges Entwicklungssystem

Kommtar zu den Kritikpunkten durch MPDL erbeten.

Konzept II: Datenhaltung in Contens-CMS (Prototyp Hamburg?)
Beauftragung von Contens zum Aufbau einer den Anforderungen der Institute genügenden und im CMS integrierten Datenbank a) Vorteil: Warum? Aufwand für Konzeptentwicklung gleich hoch
 * Erforderliche Eigenleistung der CMS-Projektgruppe voraussichtlich am geringsten
 * Darstellung auf Mitarbeiterseiten ist erprobt, abgestimmt und funktional
 * Benutzerverwaltung nur 1x im CMS notwendig
 * "Nur" das Mapping müsste von eDoc auf PubMan umgestellt werden
 * "Nur" Skripte für Upload müssten angepasst werden

b) Nachteile:
 * Contens Datenbank nicht für Publikationsverwaltung ausgelegt. Anforderungen an Langzeitnachweisbarkeit und Langzeitarchivierung können erst nach PubMan-Upload erfüllt werden
 * Eingabe bleibt benutzerunfreundlich wie bisher:
 * keine verbesserte Hilfe
 * optische Gestaltung bleibt wenig benutzerfreundlich
 * wenig selbsterklärend
 * keine Validierungsmechanismen
 * langfristig ressourcenbindend, da stets Hilfestellung nötig ist
 * langfristig ressourcenbindend, das stets Nachbesserungen an den Daten nötig sind
 * keine externen Schnittstellen der Contens-DB, nur rudimentärer XML-Export möglich
 * 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: Konzept III.1 hat sich seit Projektantrag unter Berücksichtigung der Weiterentwicklung von PubMan überholt. Konzept III.1 ist die teuerste, aufwändigste und fehleranfälligste Lösung: 3 Systeme statt 2, Anbindung in 2 Richtungen, "Neuerfindung des Rades".
 * 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:
 * (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ächsnotiz vom 04.09.07)
 * Aufwand für Betreuung einer weiteren Datenbank, möglicherweise eines weiteren Systems
 * „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)
 * Abhängigkeit der Systeme (Publikationen nicht mehr darstellbar, wenn PubMan-DB nicht erreichbar)
 * eDoc/PubMan Grundkonzept angeblich mit Mängeln behaftet: Eindeutigkeit der Datensätze, Performanz und Konsistenz (informelle Hintergrundinformation über MPI Sozial-recht; siehe Gesprächnotiz Florian Bruder und Sylvia Kortüm vom Termin 11.09.07)

Hinweis:updates/upgrades problematisch, wenn sich unser eigenständiges System bzw. Repository von dem der MPDL wegentwickelt.

=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 Drittfirma)
 * sofern alles aus der Hand von Contens: voraussichtlich am wenigsten institutsres-sourcenintensiv; aber kostenintensivstes Konzept (Angebot von Contens angefordert: nach wie vor leider keine ausreichende Reaktion) doch: kostenpflichtiger Workshop wurde angeboten
 * Bindung an Contens kann wegen Verwendung des Contens-CMS bzw. wegen der damit verbundenen „Schnittstellen“ sowieso kaum ausgeschlossen werden