Talk:JusCMS Architecture Options

JusCMS,MPDL

Unabhängigkeit der Systeme

 * Inwieweit können / sollen PubMan und CMS unabhängig voneinander arbeiten und selbständig zu bedienen sein?

Anforderung

 * auf aktueller Contens-Version (3.0+) entwickeln / testen
 * Vorschaufunktion soll auf PubMan-Seite verfügbar sein (Wie wird es im CMS aussehen?)
 * Flexible Rechtezuweisung für Volltexte: Vollzugriff, Teilzugriff, Vollzugriff ab Datum X, Zugriff nur im CMS
 * Anmeldung über LDAP, Single-sign-on PubMan/CMS

Diskussion

 * Modell Nijmegen: nächtliches Update - Für uns ausreichend? Voll automatisierbar?
 * On-demand-Publizieren (Modell Nijmegen)?
 * Wunsch: deutlich öfter, minütlich
 * Synchronisierung der Daten
 * wie häufig?
 * Ablauf? In beide Richtungen? Nur in eine Richtung?
 * Eigenes Repository innerhalb PubMan für JusCMS-Gruppe? Für jedes Institut?
 * Stimmungsbild der 5 beteiligten Institute gegenüber fortgesetztem Einsatz von Contens
 * Abschätzung der Kosten des Betriebsprojekts (in Abhängigkeit der Architektur)

Szenario 1: PubMan ersetzt eDoc, ansonsten Workflow entsprechend Hamburger Modell (Konzept II)
Eingabe:
 * 1) Eingabe wie bisher in Contens (3.0 oder 4.0) über Eingabemasken, inkl. Volltexte und Links zu Volltexten

Ausgabe: Mitarbeiterseiten: MPG-Jahrbuch: Tätigkeitsbericht:
 * Aufbereitung über Outputtypes innerhalb Contens
 * bleibt wie bisher
 * kompletter Datenbankabzug in XML
 * Aufbereitung mit neu zu erstellenden Skripten für PubMan
 * Upload in PubMan
 * kompletter Datenbankabzug in XML
 * Aufbereitung mit vorhandenen Skripten für Tätigkeitsbericht
 * bleibt wie bisher

Nachteile:
 * Eingabe bleibt benutzerunfreundlich wie bisher:
 * keine verbesserte Hilfe
 * optische Gestaltung bleibt wenig benutzerfreundlich
 * wenig selbsterklärend
 * keine Validierungsmechanismen
 * ressourcenbindend, da stets Hilfestellung nötig ist
 * ressourcenbindend, das stets Nachbesserungen an den Daten nötig sind

Vorteile:
 * 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

Frage:
 * Langzeitnachweisbarkeit und Langzeitarchivierung?
 * Genügen Metadatensätze und Volltexte auch nach einem Upload den Anforderungen an Langzeitnachweisbarkeit und Langzeitarchivierung?

Szenario 2: PubMan wird primäre Eingabequelle (Eingabe Wissenschaftler) (Konzept I)
Eingabe:
 * 1) Für jeden Wiss. Bentzerkonto in PubMan einrichten
 * 2) Eingabe in PubMan durch Wiss.

Ausgabe: Mitarbeiterseiten:
 * 1) Verwendung der Eingaben für CMS-Export
 * 2) Batch-Erstellung Export-Dateien für CMS unter Berücksichtigung Zitier- und Formatierungsvorgaben
 * 3) Einspielen der Seiten ins CMS

MPG-Jahrbuch:
 * Export im MPG-Jahrbuch-Format
 * bereits fertig

Tätigleitsbericht:
 * Export im Tätigkeitsberichtsformat (InDesign)

Vorteile:
 * stark verbesserte Benutzerführung wird möglich
 * Einbau von Validierungsmechanismen ist möglich
 * Eingabehilfen (Normdaten)
 * langfristig weniger Hilfestellung nötig
 * Nutzung voller PubMan-Funktion Langzeitarchivierung und PIDs

Nachteile:
 * Programmierung aufwändiger Validierunsmechanismen
 * großer Entwicklungsaufwand um den aktuellen Status Quo Hamburg zu halten
 * Ausgabe (Zitierstil) muss PubMan-konform spezifiziert werden
 * CMS-gerechte Ausgabe muss programmiert werden
 * Ausgabe für Tätigkeitsbericht muss neu programmiert werden (Programme für CMS können vermutlich aufgrund geänderter Datenstruktur nicht weiter verwendet werden)
 * Seiteninhalte müssen für CMS-Webserver-Suche verfügbar sein (Redaktionssystem-Suche nicht so wichtig)


 * Doppelte Benuterverwaltung in CMS und PubMan
 * Problem Bearbeitungsberechtigung für Datensätze muss gelöst werden (Dublettenvermeidung aber trotzdem Mehrfachverwendung eines Datensatzes, individuelle Mehrfachverwendung (wichtige Publikation, unwichtige Publikation))
 * Wartezeit, bis Eingabeergebnis auf Homepage sichtbar ist

Szenario 3: PubMan wird primäre Eingabequelle (Eingabe Zentrale Stelle) (Konzept I)
Workflow:
 * 1) rudimentäre Eingabe durch Wiss. in CMS
 * 2) Senden der rudimentären Eingabe an ZS
 * 3) Eingabe durch ZS in PubMan
 * 4) Verwendung der Eingaben für CMS-Export
 * 5) Batch-Erstellung Export-Dateien für CMS unter Berücksichtigung Zitier- und Formatierungsvorgaben
 * 6) Einspielen der Seiten auf CMS-Seite

Vorteile:
 * Look and Feel des CMS bleibt erhalten, aber Eingabe wird vereinfacht
 * nur einmalige Benutzerverwaltung in CMS
 * Vorteile PubMan werden genutzt
 * Problem Bearbeitungsberechtigung Datensatz nicht ganz so ausgeprägt, wie bei Eingabe durch Wissenschaftler (ABER: individuelle Einstufung Wichtigkeit muss gelöst werden)

Nachteile:
 * großer Entwicklungsaufwand um den aktuellen Status Quo Hamburg zu halten
 * Ausgabe (Zitierstil) muss PubMan-konform spezifiziert werden
 * CMS-gerechte Ausgabe muss programmiert werden
 * CMS-gerechter Import muss programmiert werden
 * Seiteninhalte müssen für CMS-Webserver-Suche verfügbar sein (Redaktionssystem-Suche nicht so wichtig)
 * Ausgabe für Tätigkeitsbericht muss neu programmiert werden (Programme für CMS können vermutlich aufgrund geänderter Datenstruktur nicht weiter verwendet werden)

Anforderungen MPI Heidelberg

 * eSciDoc-Server über den weltweiten Verbund von OAI-Servern sichtbar/vernetzt (möglichst mit allen Daten)
 * Zertifizierung nach DINI-Standards als Dokumenten- und Publikationsserver

Fragen von H.Leitl, MPI f. Geistiges Eigentum
Mir fehlen im Wesentlichen noch Vorgaben für die Eingabe der Metadaten, sowie deren Ausgabe auf dem Web- oder/und Intranetserver. Für diese grundsätzlichen Vorgaben ist kaum EDV Know How notwendig. Hierfür genügen Zeichnungsentwürfe und textliche Beschreibungen. Sie sind aber Voraussetzungen, um mit Programmierarbeit zu beginnen. Wie publiziert wird, ist Basis für Überlegungen, ob eine spezielle Datenbank erforderlich ist, und wenn ja, wie die DB designed wird und wie mit PubMan zusammengearbeitet wird. Das Designe muss natürlich etwas mehr können, als bereits in dieser Phase bekannt, denn es kann später kaum mehr geändert werden. Es sollte dennoch so einfach wie möglich gehalten werden - sonst könnte ja PubMan nachprogrammiert werden.

Erstellen der Metadaten auf dem Web-, Intranet- oder Redaktionsserver

 * Völkerrecht und Strafrecht forderten 2007 eine reduzierte Menge an Publikationskategorien und -felder für wissenschaftliche Mitarbeiter.
 * Ich halte dieses Ansinnen für sehr berechtigt, da falsche Zuordnungen oft schlimmer als fehlende sind.
 * 'Wie können wiss. Mitarbeiter, Sekretariate, Direktoren, Bibliothek zusammenarbeiten', um dennoch in der endgültigen Speicherung alle wichtigen Felder richtig belegt zu haben.
 * Gibt es Vorveröffentlichungen im Intranet, oder Mechanismen, die die Erfassung des Dokuments in der Bearbeitungsphase ermöglichen und einem eingeschränktem Benutzerkreis Metadaten oder auch das unfertige Dokument zur Verfügung stellen.
 * Wenn die Ersteingabe für Wissenschaftler von überall möglich sein soll, müßte nach unserem derzeitigen Sicherheitskonzept das Programm auf dem Webserver laufen..

Publikation der Metadaten auf dem Web- oder Intranetserver
Für die bisher bekannten Anforderungen (s.u.) ist meiner Ansicht nach keine eigene Datenbank notwendig. Meistens können ein Mal täglich (oder auch öfters) statische Seiten durch Abfrage von PubMan erstellt werden. In wenigen Fällen werden vielleicht dynamische Abfrage erforderlich, die aber wahrscheinlich auch keine eigene DB erfordern. Ich zitiere aus der Zusammenfassung der Anforderungen vom April 2004:
 * Liste Schriftenverzeichnis, Unterseite der eigenen Mitarbeiterseite:
 * Liste geordnet nach Publikationskategorien, automatische Generierungsmöglichkeiten (das kann aber auch eine statische Site im Hintergrund sein).
 * speziell: Name des Mitarbeiters nicht angezeigt, bei mehreren Autoren: gemeinsam mit...
 * Auswahl wichtiger Publikationen auf Mitarbeiterseite:
 * händische Auswahl/Referenzierung/flexible Darstellung (z.B. Sortierung nach Publikationsdatum oder Bedeutung der Publikation).
 * ansonsten s.o.
 * Liste Publikationen aller Institutsangehörigen:
 * automatische Generierung einer Internetseite pro Jahr.
 * Sortierung nach Institutsangehörigen alphabetisch, da andere Kriterien unpraktikabel bzw. willkürlich (ZB Veröffentlichungsdatum der Publikation willkürlich, Einstellungsdatum entspricht nicht der zeitlichen Reihenfolge der Veröffentlichung).
 * Liste der Publikationen, die zuletzt im CMS eingegeben worden sind –Whats New Applikation für Publikationen.
 * Liste bzw. Internetseite der Publikationen, deren Titel auf Englisch übersetzt wurden: Autor, Titel, Kurztext.

Über dieses Anforderungen hinaus kann ich mir vorstellen, dass es durchaus weitere gibt. Für neue grundsätzliche Überlegungen ist jedoch nicht die EDV der erste Ansprechpartner, müßte aber trotzdem frühzeitig eingebunden werden:
 * Als Beispiel fallen mir die vielen Projekte ein, denen bestimmte Publikationen zugeordnet werden könnten. Diese Zuordnung können vielleicht in PubMan durch Abteilungskennziffern erfasst werden. Vielleicht aber auch nicht (Projekt zu klein, Mehrdeutigkeit).
 * Ein anderes Beispiel könnten spezielle und Vor-Veröffentlichungen im Intranet sein (s. bei Eingaben).

Publikation der Dokumente

 * Wo liegen die entsprechenden Dokumente?
 * Werden zumindest die juristischen Fragestellungen EDV-technisch von der MPDL abgedeckt - wer darf wann zugreifen (beispielsweise wenn nach 2 Jahren frei publizierbar) ?
 * Wie können diese Zugriffsrechte auf unserer Website umgesetzt werden?