JusCMS Meeting 2010-01-26

JusCMS,MPDL

Datum: '''26. Januar 2010''' Ort: MPDL, München Zeit: 14:00 Uhr bis 17:00 Uhr Teilnehmer: Gergana Stoyanova (MPI GE) Irina Arndt (MPI Priv) Juliane Müller (MPDL) Sylvia Kortüm (MPI GE)

=Ergebnisse des Projektplanungstreffen am 22.01.2010=


 * Anpassung des Projektplans
 * Anmerkungen Gergana:
 * Arbeit an Pflichtfeldern/freiwilligen Feldern noch nicht abgeschlossen
 * Differenz zu PubMan Core bezüglich Genre Types (welche jus-spezifischen Publikationstypen werden wirklich genutzt)
 * PubMan SetUp noch nicht abgeschlossen -> es fehlen OUs, User, Contexte, CoNE Autoren
 * Überhänge aus WPs sollten notiert und gemerkt werden -> wenn Kapazitäten und Ressourcen vorhanden sollten diese Sachen bei Bug Fix Releases im zuge der PubMan Core Entwicklung angegangen werden
 * für Contens sind zwei Blöcke geplant (April und August 2010) -> genaues Vorgehen muss noch geklärt werden
 * WP Citation Lists werden hauptsächlich durch Contens-Auftrag abgedeckt
 * Anforderungen für WP Reports müssen noch genauer geklärt werden
 * WP Migration der Altdaten
 * München wird Daten vermutlich selbst erneut eingeben
 * Hamburg wird eSciDoc XML ihrer Daten erstellen
 * Voraussetzung ist, dass PubMan SetUp steht und das WP 2 und WP3 (alle Genretypes außer Journal können bereits vor Abschluss WP und Implementierung Citation Styles eingegeben werden) abgeschlossen ist (geplant für Mai/Juni)
 * PubMan Testsystem - Vorabklärungen zwischen Herrn Dreyer und Herrn Leitl in Arbeit - soll so bald wie möglich nutzbar sein
 * WP Interoperability/SSRN -> bildet Abschluss des Projekts -> Architektur soll ab November 2010 engedacht werden
 * Anmerkung Irina:
 * SSRN hat Zusammenhang mit Gestaltung der Validierungsregeln - SSRN früher angehen?
 * Anmerkung Frau Kortüm:
 * Workpackages werden nicht aufgebrochen / zeitlicher Rahmen bleibt bestehen
 * Anmerkung Gergana:
 * Validierungsregeln können zu gegebener Zeit angepasst werden

=Allgemeines/Abstimmungsfragen – Einbeziehung der Bibliothek MPI GE (Fr. Schmotz) – Turnus der Besprechung=


 * regelmäßige Telkos Irina, Gergana und Juliane zur Klärung aufkommender Fragen der aktuellen WPs -> bei Aufkommen von Fragen Weiterleitung an Frau Kortüm
 * neue Ansprechpartnerin in der Bib München Frau Schmotz
 * Irina stellt PubMan vor / zeigt Informationen zum Projekt in CoLab
 * Frau Schmotz würde auch an den Telkos teilnehmen, wenn gewünscht
 * genaues Vorgehen zum Bearbeiten der WPs noch festzulegen:
 * Mit welcher "Perfektion" wird spezifiziert?
 * Wie gestaltet sich interativer Prozess genau?
 * Anforderungen oder auch Verbesserungen/Änderungen in der Spezifizierung müssen mit MPDL und PubMan Community abgestimmt werden -> absolute Zusagen oder Absagen können im Vorfeld nicht gemacht werden -> kooperativer Prozess muss respektiert werden

=Validierungsregeln und Hilfetexte pro Publikationstyp:=

Hilfetexte
Beispiele aus eDoc (so wäre es perfekt...):

thumb|none|Hilfebuttons in eDoc

thumb|none|Hilfetextbeispiel für "article"


 * Kann man hier Synergieeffekte nutzen? Gibt es Pläne, die eDoc-Hilfetexte nach PubMan zu übernehmen (etliche Felder scheinen gleich oder ähnlich)?
 * Hilfetexte sind für alle PubMan User gleich
 * freier ist Jus CMS bei der Gestaltung der Hilfetexte ihrer "speziellen" Publikationstypen
 * nur solang bis ein weiteres Institut jenen Publikationstyp nutzen möchte
 * TODO MPDL: Übernehmen von kontext-sensitiver Hilfe aus eDoc muss intern geklärt werden (evtl. problematisch aufgrund genre specific submission mask)
 * Schreiben der Hilfetexte für jus-spezifische Dokumenttypen sollte aber von juristischen Instituten übernommen werden

Validierungsregeln

 * Aufwandsabschätzung und Priorisierung notwendig, damit Phase der Spezifikation nicht zu langwierig wird
 * Gergana gibt Beispiel, damit für Spezifizierende klar wird wieviel Aufwand dahinter steckt
 * weißt darauf hin, dass lange "Fehlermeldungen" zu Frustration führen könnten
 * in Hamburg geben Wissenschaftler Daten ein -> möglichst viele Hilfestellungen/Wegweisungen um korrekte Daten zu erhalten
 * München könnte Hamburger Validierungsregeln übernehmen; bräuchte auf keinen Fall retsriktivere Validierungsregeln als Hamburg
 * erfahrungsgemäße Empfehlung der MPDL:
 * nicht zu restriktive Validierungsregeln -> könnten zur Frustration der Eingebenden führen
 * Vorschlag nur die wichtigsten Validierungen implementieren (ob das wirklich alle Felder sein müssen, die für Zitierstile benötigt werden, ist fraglich)
 * TODO: Irina lässt Hamburger Wissenschaftler Standard-Validierungsregeln der MPDL (validation schema "publication") testen -> von diesem Ergebnis ist abhängig, ob Validierungsregeln restriktiver gestaltet werden sollten -> falls stärkere Validierungen notwendig sind -> Spezifikation genereller Validierungsregeln (ohne zu sehr ins Detail zu gehen oder zu restriktiv zu werden) -> falls auch diese nicht ausreichen, mit Projektleitung abstimmen, ob die Spezifikation und Implementierung restriktiverer Validierungsregeln möglich ist (mit Hinblick auf Ressourcen und Kapazitäten)

=vorselektierte Werte=
 * vorselektierte Werte nur für Source
 * bevor PubMan Administration Tool nicht in eSciDoc eingegliedert ist (bislang ist dies ein extriges Tool), macht die Implementierung vorselektiver Werte nur begrenzt Sinn
 * Voraussichtlich mit R 6.1 (Frühjahr 2010) soll Admin Tool in eSciDoc-Umgebung eingegliedert werden.
 * Nachfolgend könnte man vorselektierte Werte am Context festmachen.
 * Es muss dann innerhalb der Projektgruppe geklärt werden, wie hoch die Priorität für diese Anforderung wirklich ist.
 * Feature ist kein Blocker, sondern eher ein Nice-to-have.
 * weiteres Nice-to-have: bei PubType Legal Case im Titel "Anmerkung zu ..." vorausgefüllt -> TODO Gergana klärt das ab

=Migration der Altdaten=
 * Hamburg möchte spätesten Zeitpunkt für Live Migration wissen (vorauss. Mai/Juni 2010
 * nach Live Release 6.0 können Test-Importe starten (können von Hamburg selbstständig auf Test- oder Migrationsserver durchgeführt werden)
 * Datensätze der Test-Importe sollten so variationsreich wie möglich sein
 * Live Migration ist abhängig von PubMan Set-Up (CoNE, OUs etc.) sowie Abschluss WP2 sowie WP3 (TODO MPDL: es muss noch geklärt werden wie Zuweisung des Zitierstils für Zeitschriften designed wird)

=Sonstige Fragen und Themen=
 * Welche in CONE hinterlegten Zeitschriften werden mit den beiden priorisierten Varianten zitiert?
 * ToDo HH + Muc: Liste mit Zuweisung des Zitierstils zu bestimmten Journals notwendig von beiden Instituten (möglichst bald)


 * Wisschaftler Namen + SSRN ID (E-mail GS – Bearbeitung am MPI GE)
 * München arbeitet daran
 * wird auch von Hamburg benötigt (TODO)


 * 4 Zitierstile Heft – MPI GE – evtl. Reduzierung
 * wird gerade in München geklärt


 * Umbennung von existierenden Labels - Ergebnis der Diskussion mit der PubMan-Community
 * Wissenschafltiche Qualifikationsarbeit statt Hochschulfschrift - nein, bleibt Hochschulschrift
 * Special Journal Issue statt Special Issue - ja
 * Conference Paper statt Proceedings Paper - ja


 * Welche Publikationen werden tatsächlich benutzt? Gibt es z.B. Handbuch als Genre oder nur als Quelle von einem Beitrag in Handbuch? Z.B. gibt es Enzyklopedie nicht als eigener Genre Type, sondern nur als Quelle.
 * Handbuch bleibt wie es ist
 * Enzyklopedie kommt nicht hinzu


 * Frage zur Nutzung des Publikationstyps Review -> siehe auch Fragenkatalog 20.01. (http://colab.mpdl.mpg.de/mediawiki/JusCMS_Telephone_Conference_2010-01-20)
 * Publikationstyp "Review" bleibt bestehen und wird genutzt
 * bei einer Rezension über eine Publikation eines MPI-Wissenschaftler wird Originalwerk in PubMan erfasst sowie die Revision der Publikation -> über die Möglichkeit der PubMan Revision -> Information an Contens "is revision of"/"has revision" -> entsprechende Umsetzung bei Zitierung auf der Homepage (eingerückte Darstellung auf publikationsliste der Autoren)
 * wenn Wissenschaftler eigene Revisionen schreiben, geben sie diese als "Review" ein ohne dass das Originalwerk in PubMan eingegeben wird -> zitiert werden von MPI-Wissenschaftlern geschriebene Revisionen ähnlich wie Zeitschriftenartikel (ohne besondere Darstellung auf Publikationsliste der Autoren)
 * technische Umsetzung von "is revision of"/"has revision" muss MPDL-intern geklärt werden

=Vorbereitung Auftrag Contens=

Allgemeine Überlegungen

 * Wie sieht ein Publikationsobjekt von Contens aus? Welche Felder hat dieses? Werden Hamburg und München die gleichen Objekte/Felder haben? Sonst ist die Aufwand für Contens höher. Wer entscheidet die Struktur?
 * Ergebnis 26.01.:
 * Vorschlag Contens überlassen; vorauss. eine Objektklasse, die intern differenziert wird
 * HH und MUC werden die gleichen Felder haben
 * Vorschlag von Contens von Herrn Leitl und Herrn Martens absegnen lassen


 * Wer entscheidet die Struktur von dem Objekt Person? Dort brauchen wir auch eine Person-ID auf Seite von Contens. Das kann eine interne ID wie z.B. von einem LDAP-Server sein. (siehe dazu JusCMS_Import_PersonData)
 * Ergebnis 26.01.:
 * Fragen an Contens:
 * Können nicht die vorhandenen Personenobjekte nach der Migration übernommen werden?
 * Wo wird die SSRN-ID hinterlegt? Brauchen wir eine Contens-Spezifische ID?
 * Oder nehmen wir die CONE-ID?
 * Vermutlich brauchen wir eine eigene ID in Contens zusätzlich zur Objekt-ID


 * Aktueller Stand Rezension, Übersetzung: Wie trägt man die Publikationen ein? Werden die Datensätze verlinkt?
 * Ergebnis 26.01.:
 * s.o. Diskussion - Überlegungen von Frau Arndt noch Contens vorlegen
 * evtl. erst im zweiten Block beantragen, damit wir es im System testen können (Punkt 2.1.2 vom Angebot).

Zusätzlich müssen Seiten erstellt werden, über die Punkt 2.7.1 getestet werden kann (Datenaustausch 1x täglich, Publizieren: automatisch; Datenaustausch 1x täglich, Publizieren: manuell)
 * Wann ist Projektstart?
 * Ergebnis 26.01.:
 * ursprünglich geplant - April 2010 (1. Block)
 * Vorschlag - Testsystem Contens wird vorher zur Verfügung gestellt
 * TODO Fr. Arndt: mit Contens klären
 * Start: abhängig auch davon, wann die verbindlichen Daten zur Verfügung stehen (seitens MPDL) und wann wir die Zitierstile korrekt herausbekommen
 * TODO Fr. Stoyanova: versucht baldmöglichst einen Export zu erstellen, um ein Bild zu bekommen
 * TODO Fr. Stoyanova: klärt mit Contens, in welcher Form die Daten geliefert werden sollten (siehe Tabelle)
 * zeitliche Grobplanung:
 * Datenlieferung 2 Wochen vor Workshop (d.h. Ende März 2010, Ende KW 11)
 * Workshop (Feinkonzept) ca. 1 Woche vor Projektstart
 * Kann Contens einen Projektplan erstellen?
 * Ergebnis 26.01.:
 * Vorteil: aus Projektplan ergeben sich die Zeitpunkte, wann Contens was in der endgüligen Fassung braucht
 * TODO Fr.Arndt: klärt, ob Contens einen solchen erstellen kann
 * Inst. müssen in einer Testumgebung Seiten bauen, die denen entsprechen, auf denen sie Publikationen künftig anzeigen lassen wollen. An dieser Stelle können dann die von Contens erstellten Objektklassen/Outputtypes getestet werden.
 * Ergebnis 26.01.:
 * Zeitpunkt für die Seitenerstellung hängt vom Projektstart/Projektplan ab (s.o.)
 * Aufwand muss dann in den Instituten rechtzeitig eingeplant werden
 * Abhängigkeit zum Migrationsprojekt: Zeitpunkt sollte erst nach den Schulungsterminen liegen (ggf. können die Seiten sogar im Rahmen der Schulung erstellt werden)

Angebot

 * Punkt 2.1: Beispieldaten für Publikationen werden im Projektverlauf geschickt.
 * Reichen die Beispiele, die Irina schon vorliegen hat oder werden noch zusätzliche Datensätze erfasst? Struktur von Item ist immer gleich.
 * Iarndt 10:18, 24 January 2010 (UTC) Es macht vermutlich Sinn, dass sich sämtliche Anforgerungen unter 2.1 in mindestens einem Beispieldatensatz widerspiegeln. Da sich etliche Anforderungen auf die Weiterverarbeitung des augegebenen Zitierstils beziehen, sollte dieser in den Beispielen vorhanden sein (ggf. Mock-Daten zur Verfügung stellen).
 * Ergebnis 26.01.:
 * Beispieldaten werden aus Sicht der Institute vor Projektstart (vorauss. März) geliefert (s.o. inkl. Klärung, in welcher Form Daten ausreichen)

Contens fertigt lt. Angebot nur die Objektklasse(n) und zugehörigen Outputtypes. Die Anfertigung der passenden Seitentemplates liegt bei den Instituten (hier ev. Überschneidung mit Migrationsprojekt). Man könnte also trotz abweichender Schriftenverzeichnis-Struktur mit einem Set Objektklasse(n)/Outputtypes auskommen. Frage: wird die "Anzeigemodifikation Zitierstil" auch von M verwendent?
 * Punkt 2.1.3: Felder Autoren/Herausgeber von einer Publikation im Projektverlauf mitgeteilt.
 * Spielt die Reihenfolge der Eingabe sonst eine Rolle (ausser für den Zitierstil)?
 * Ergebnis 26.01.:
 * Nein!
 * Punkt 2.4: Schriftenverzeichnis Struktur liegt vor Projektstart vor.
 * Haben H und M die gleichen Struktur? Eigentlich wird nur ein Beispiel als Vorlage gefertigt.
 * Iarndt 10:18, 24 January 2010 (UTC) Struktur von H ist die aktuelle. Wie sieht es mit M aus?
 * MUC: im Prinzip ja; Institut müsste ein eigenes Template erstellen zum Testen im Projektverlauf
 * MUC: Ja!


 * Punkt 2.7.1 Button für Import der PubMan-Daten auf Content-Seite (Position, Beschriftung) wird im Rahmen des technischen Feinkonzeptes besprochen.
 * wird mit Contens auf Workshop besprochen
 * Iarndt 10:18, 24 January 2010 (UTC) Ev. Rückfragen an Contens sinnvoll: Wird es einen Projektplan geben (hieraus sollte sich der Zeitpunkt für das Feinkonzept ergeben)? Was genau ist mit "technischem Feinkonzept" gemeint?
 * s.o.
 * Punkt 4.1.Installation Contens 3.x
 * Iarndt 17:34, 25 January 2010 (UTC) Ab wann kann das Testsystem zur Verfügung stehen?
 * s.o. Klärung durch Fr. Arndt
 * Punkt 5.2 Alle noch nicht zur Verfügung stehenden Inhalte sind vom Auftraggeber zu festgelegten Terminen beizusteuern.
 * Welche?
 * Iarndt 10:18, 24 January 2010 (UTC) Auch hier: Frage nach Projektplan (s.o.)

(Schätzung: September 2010)
 * Vorsicht: zeitliche Verschiebung des 2. Blocks wg. Änderungen im Zeitplan Migration Gesamtbetriebsprojekt