JusCMS WF Meeting 2009-09-16

JusCMS,JusCMS_2,MPDL

Termin und Teilnehmer des Treffens
Datum: '''16. September 2009''' Ort: Max Planck Institut für Geistiges Eigentum, Wettbewerbs- und Steuerrecht, Raum 225a Zeit: 11:00 Uhr bis 16:15 Uhr Teilnehmer: Sylvia Kortüm (MPI IP, M) Gergana Stoyanova (MPI IP, M) Juliane Müller (MPDL, M) Irina Arndt (MPI PL, HH)

Agenda

 * Einleitung
 * 1. Kurze Zusammenfassung der Videokonferenz- und der Technik-Workshop-Ergebnisse


 * Workflows
 * 2. Vortstellung des neuen PubMan Releases 5
 * 3. Erläuterung der Abbildung der drei benötigten Workflows in PubMan
 * 4. Klärung von Fragen zu den Workflows


 * Sonstiges
 * 5. Informationen zum Massenimport
 * 6. Informationen zu CONE
 * 7. TODOs
 * 8. Nächste Termine

Einleitung

 * auf dem Technik-Workshop am 7. und 8. September in Heidelberg wurde festgelegt, das Projekt auf der zentralen PubMan-Installation (gehostet bei der GWDG) zu beginnen.
 * es ist ein Workshop mit der Firma Contens voraussichtlich am 19. oder 21. Oktober geplant. Es sollen Vertreter des JusCMS-Projektteams, der MPDL und natürlich von Contens teilnehmen. Inhalt wird die detaillierte Besprechung der Anforderungen an das CMS sein.
 * Juliane Müller wird für beide Tage einen passenden Raum in der MPDL reservieren.
 * Juliane Müller legt zur Festlegung des konkreten Workshop-Termins eine Doodle-Umfrage an.

PubMan Release 5

 * Ein neues Release wird in folgender Reihenfolge auf den verschiedenen PubMan-Servern eingespielt:
 * Development Server -> Testen der Funktionalitäten durch Development Team der MPDL
 * QA Server -> Testen aller Funktionalitäten durch Service Management Team der MPDL
 * PubMan Testserver
 * PubMan Live


 * Release 5 ist soeben auf dem Produktivsystem eingespielt worden
 * Bug Fix Release KW39/40

Allgemeine Features

 * Anmeldung in PubMan:
 * Alle Nutzer werden in der Produktiv-Umgebung ein persönliches Benutzer-Account erhalten
 * Die Nutzer können ihre Benutzernamen frei wählen (in kleinschreibung, ohne Lehrzeichen, stattdessen mit Unterstrich)
 * PubMan-Nutzer werden getrennt von Personen in CONE (s.u.) verwaltet
 * weiterführende Erklärung: PubMan-Nutzer sind nicht zwingend die Autoren der eingegebenen Datensätze, deshalb Unterscheidung zwischen Pubman User (Depositor, Moderator, Metadata Editor, Authority etc.) und CoNE Persons (Autoren der wissenschaftlichen Arbeiten, welche in Pubman archiviert werden)
 * Auf der PubMan-Startseite steht als erste Hilfe für den Anwender der Link zu einem Sreencast zur Verfügung
 * komplette Sammlung aller PubMan Screencasts im PubMan Blog


 * RSS-Feeds:
 * RSS-Feed-Funktion ist nur auf dem Live-Server aktiviert, da von einer Verbreitung der auf dem Test-Servern angelegten Datensätze vermieden werden sollte
 * Ein Test der RSS-Funktion ist entsprechend nur auf dem Prouduktivsystem (z.B. mit Daten vom MPI PL in Nijmegen) möglich. Es ist angedacht, aber noch nicht entschieden, dass die RSS-Funktion für die Benachrichtigungen zwischen Wissenschaftler (Depositor) und Zentraler Stelle (Moderator) eingesetzt wird.
 * Ist der Nutzer aktiv oder passiv? Ruft er die Information ab (Notification Messages in PubMan) oder möchte er informiert werden (RSS; Mail)?


 * Volltexte:
 * über die Checkbox "Volltexte einbinden" kann eine Suche auf Volltexte ausgedehnt werden (Voraussetzung: bei der Erstellung eines PDFs muss darauf geachtet werden, dass der Text erkennt werden kann!)
 * Indexierte PubMan-Volltexte sind auch in Google auffindbar
 * In der Ergebnisliste werden die in den Volltexten gefundenen Suchbegriffe hervorgehoben. Hierzu muss die Anzeige der Ergebnisliste von "Kurzansicht" auf "Mittlere Ansicht" umgestellt werden.
 * In der Eingabemaske in der Rubrik "File" können Dateien physisch in eSciDoc abgelegt werden (durch Upload vom lokalen Rechner oder über eine URL). In der Rubrik "Locator" kann auf den Volltext auf einem externen Server verlinkt werden (durch Angabe der URL).
 * Beim Upload einer Datei ist die Eingabe der "Category" (Art des Inhalts) Pflicht
 * Der Name der hochgeladenen Datei ist veränderbar
 * die Angabe des mimetype ist Pflicht, wird aber von PubMan automatisch vorausgefüllt
 * Im Feld "Description" (Beschreibung) kann eine Beschreibung der Datei eingetragen werden
 * Der Upload einer Datei/eines Locators kann nur durch Klick auf das Minus-Symbol in der Eingabmaske rückgängig gemacht werden
 * selbiges gilt für andere Felder, die durch ein "+"-Symbol verfielfältigt werden können
 * Es können verschiedene Copyright Informationen zu einer hochgeladenen datei hinterlegt werden:
 * Copyright Statement ist ein optionales Freitextfeld, in dem das Copyright beschrieben werden kann
 * Im Feld "Copyright Date" kann angegeben werden, wann das Copyright Agreement geschlossen wurde
 * die Vergabe einer Creative Commons Lizenz ist möglich


 * Zugriffsrechte für Volltexte:
 * Texte, die einen anderen Sichtbarkeit als "public" (Öffentlich) haben, werden NICHT indexiert
 * Volltexte können in ihrer Sichtbarkeit "eingeschränkt" (restricted) sein; d.h. sobald ein Item released ist, kann der Volltext von einer vorher definierten Nutzergruppe eingesehen werden
 * bei eingeschränkter/privater Sichtbarkeit, besteht die Möglichkeit ein Embargo Date anzugeben
 * die Sichtbarkeit des Volltextes ändert sich nicht automatisch auf "public" sobald ein Embargo Date abgelaufen ist; der Datensatz muss von einem Depositor/QA Role händisch freigegeben werden
 * Diese Informatione wird auch bei einem XML-Export übergeben.
 * Audience Groups für Volltexte mit eingeschränkter Sichtbarkeit sind momentan anghand von OUs definierbar -> Improvement: einzelne Nutzer können als eine Pubman Audience Group definiert werden
 * ein eingeschränkter Volltext ist nur für eingeloogte Nutzer der entsprechend definierten und zugewiesenen Audience Group sichtbar.
 * Nur der Moderator (sowohl im Simple als auch im standard Workflow) ist berechtigt die angeforderten Audience Groups einem Volltext zuzuweisen. Dies tut er nach dem "Akzeptieren" des Datensatzes (Freigeben des Datensatzes im Repository) über den Reiter "Sharing". Entsprechende Notification Messages weisen beim "Save", "Submit" und "Release" eines Items auf diesen Workflow hin.
 * Improvement: Für Beginn des Jahres 2010 ist geplant, dass auch der Depositor Audience Groups für Volltext in einem von ihm selbst eigegebenen Datensatz zuweisen kann. Eine Zuweisung soll dann auch bereits im Status "submitted" möglich sein.


 * Hilfetexte pro Feld (z.B. über ToolTip) sind noch nicht eingebunden (Rücksprache von juliane mit MPDL GUI Division)

Organizational Units / Contexts / Collections

 * zur Nutzung von PubMan muss pro Institut mindestens eine Organizational Unit (OU) eingerichtet werden.
 * es können beliebig viele OUs angelegt werden
 * es können Hierarchien abgebildet werden, z.B. Abteilungen -> Arbeitsgruppen -> Projekte (Beispiel: AEI Golm arbeitet mit einer stark gegliederten Struktur)
 * es können aber auch sämtliche OUs ohne Hierarchien erfasst werden (Beispiel: MPI PL in Nijmegen arbeitet mit einer sehr flachen Struktur)
 * die grundätzliche OU-Struktur lässt sich nur noch sehr schwer verändern
 * OUs können umbenannt oder auch deaktiviert (geschlossen), aber nicht gelöscht werden
 * neue OUs können problemlos hinzugefügt werden
 * -> OU-Struktur ist erweiterbar, aber nur bedingt ersetzbar
 * Funktionalität der OU-Struktur:
 * jede OU ist mit einem Context verknüpft
 * Der Context legt den Workflow fest (Standard Workflow (=Depositor und Moderator) oder Simple Workflow (=nur Depositor))
 * Im Context wird das Validierungsschema festgelegt
 * Hinweis- und Fehlertexte, die nach der Validierung angezeigt werden, sind mit dem Validierungsschema verknüpft. Entsprechend könnten bei Bedarf pro Institut unterschiedliche Validierungsschemas mit abweichenden Texten angelegt werden.
 * Ein Item wird vor jedem Status ("saves", submitted", "released") validiert; die Validierungsregeln für "save item" in PubMan sind nicht veränderbar; für "submit" und "release" könnte jedes Institut eigene Validierungsregeln festlegen.
 * Die Hinweis- und Fehlertext lassen sich jedoch nicht über das PubMan-Admin-Web-Interface erfassen, sondern müssen im Code hinterlegt werden.
 * Der User, mit dem man sich in PubMan anmeldet, ist einem oder mehreren Contexten zugeordnet. Je nach Context ändern sich die angebotenen Optionen in der Auswahlliste "Dateneingabe" (Submission) sowie die jeweiligen Funktionalitäten während der Submission (nur "submit" -> Standard Workflow; "submit & release" -> Simple Workflow)
 * bei der Erfassung von Datensätzen werden die OUs einer Person zugewiesen (bzw. sind bereits im CONE-Datensatz der Person mit dieser verknüpft).
 * nur wenn OUs zugewiesen wurden, kann nach Ihnen gesucht werden (z.B. Liste aller Publikationen einen Abteilung)
 * nach den datensätzen eines bestimmten Autors kann natürlich auch unabhängig der OUs gesucht werden


 * ein Context ist identisch mit einer Collection -> siehe Functional Specification for the Administration of Collections
 * pro Collection/Context kann eingestellt werden, welche Publikationstypen zur Auswahl bei der Submission in PubMan angezeigt werden sollen
 * beim Erfassen eines Datensatzes muss mindestens eine Person einer OU zugeordnet sein
 * wird eine Person (z.B. Autor über einen CoNe-Eintrag aus der Autosuggest-Liste übernommen, wird die ihm zugeordnete OU automatisch ergänzt
 * beim Import eines Datensatzes kann PubMan einer eigentlich im CoNE "bekannten" Person noch keine automatische Verbindung zwischen den Einträgen herstellen - dies ist jedoch in Planung
 * in einem der nächsten Release wird es eine Verbesserung im GUI geben, was die Auswahl und Zuweisung der OUs zu den Autoren angeht
 * es können einer Person / Publikationen beliebig viele OUs zugeordnet werden (z.B. eine Abteilung und ein Projekt)
 * Man kann bessere Suche starten, wenn diese Struktur fein granular ist.
 * Reihenfolge des Erstellens:
 * OUs
 * Context(e) (Validierungsschema, Art der Workflows, bei der Submission angezeigte Publikationstypen)
 * User


 * Fazit für das Projekt:München und Hamburg werden mit einer minimalen Struktur beginnen, hiermit die Workflows weiter im Projektverlauf testen und die OU-Struktur dann bei Bedarf ergänzen

Workflows

 * in PubMan gibt es zwei (bisher implementierte) Workflow-Typen:
 * Simple Workflow (nur eine Person involviert: Depositor durchläuft gesamten Publikations-Workflow (create, save, release Item)
 * Standard Workflow (zwei Personen involviert: Depositor (erfasst rudimentär -> create & save item), Moderator (ergänzt und gibt frei -> accept item))


 * die JusCMS-Workflows haben folgende Entsprechungen:
 * Wissenschaftler gibt alles selbstständig ein = Simple Workflow
 * Wissenschaftler gibt rudimentär ein und Zentrale Stelle ergänzt = Standard Workflow
 * Zentrale Stelle gibt alles ein = Simple Workflow

Simple Workflow
 * der maximal in PubMan abbildbare Workflow ist hier grafisch dargestellt
 * der Depositor speichert den Datensatz in verschiedenen Stufen:
 * SAVE = Speichern (Datensatz ist in diesem Stadium noch löschbar, nach außen nicht sichtbar, sondern nur unter My Items)
 * RELEASE = Freigeben (nach außen sichtbar, Statuswechsel zu "Released / Freigegeben"; Kann nicht gelöscht werden, nur noch zurückgezogen (WITHDRAW). Der datensatz behält seine Zitierbarkeit (persistent identifier), wird in einer Suche jedoch nicht mehr indexiert

Standard Workflow
 * Der Moderator kann KEINE eigenen Datensätze anlegen, sondern kann nur die Datensätze des Despositors kontrollieren und überarbeiten
 * auch in diesem Workflow gibt es verschiedene Speicherungsstufen:
 * SAVE = Speichern (Zwischenspeicherung, nur für Depositor sichtbar), wird vom Depositor durchgeführt
 * SUBMIT = Einstellen (für Moderator sichtbar, in Repository eingestellt, aber noch nicht nach außen sichtbar), wird vom Depositor durchgeführt
 * ACCEPT = Akzeptieren (nach außen sichtbar, Statuswechsel zu "Released / Freigegeben"), wird vom Moderator durchgeführt


 * Für die Speicherstufen SUBMIT, ACCEPT und RELEASE können individuell Validierungsregeln festgelegt werden
 * Für verlinkte Volltexte kann derzeit erst nach dem ACCEPT durch den moderator festgelegt werden, wer diese sehen darf. Anfang 2010 wird die "Audience" auch nach dem SUBMIT gegeben werden können. Auch Colaboration für submitted Items ist ab nächstes Jahr möglich.
 * Ab 2010 können Moderator und Depositor für verlinkte Volltexte angeben, wer diese sehen darf.
 * Als PowerUser und Depositor kann eine Revision erstellt werden (Verlinkung von Publikationen).

Kommentare Wissenschaftler Hamburg / Projektgruppe zu den Workflows- insbesondere zur Sacherschließung
-
 * eine Vergabe der groben Dewey-Klassen wird von den Hamburger Wissenschaftler als wenig sinnvoll eingestuft
 * die freie Vergabe von Schlagwörtern im Feld "Free Keywords" wird von Hamburger Wissenschaftler jedoch sehr begrüßt. Die Hinterlegung eine kontrollierten Vokabulars an dieser Stelle halten sie jedoch für wenig sinnvoll, da die Inhalte der Publikationen für allgemeine Schlagwortlisten häufig zu speziell sind
 * eine Autosuggest-Funktion zur Vermeidung von Tippfehlern wird jedoch für die freie Schlagwortvergabe als sehr sinnvoll erachtet. Juliane prüft, inwieweit dies umgesetzt werden könnte.
 * ein Mapping der Dewey-Klassen auf SSRN-Schlagwörter halten die Münchener Wissenschaftler für unmöglich
 * In SSRN werden neue Artikel auch vom Betreiber klassifiziert bzw. verschlagwortet. Eine Mitgabe dieser Informationen beim Upload ist daher nicht zwingend erforderlich.
 * Eine Hinterlegung von Wörterbüchern in anderen Sprachen und eine damit verknüpfte automatische Übersetzung freier Schlagwörter wird als wenig sinnvoll eingestuft, da eine eindeutige Übersetzung häufig nicht möglich ist und das korrekte Schlagwort in der anderen Sprache doch meist intellektuell vom Wissenschaftler vergeben werden muss
 * Link zur vollständigen Protokollierung der Wissenschaftler-Aussagen

Informationen zum Massenimport

 * Massenimport kann alternativ mit dem User demo / demo durchgeführt werden
 * eDoc-Format für Massenimport -> in eDoc neu implementiertes Export-Format "eDoc2PubMan"; damit kann nun jetzter Nutzer (ohne administratives Eingreifen der MPDL) eDoc-Daten exportieren und in Pubman importieren
 * Gergana wird ein Schema für die Validierung von eSciDoc_XML vorbereiten. So kann versucht werden eSCiDoc_XML hochzuladen. Bzw. ist für die spätere Migration dieses Format sinnvoller, da die juristisch-spezifischen Publikationen als Typen nur in diesem Format verfügbar sein werden.
 * Auf Test-PubMan werden Daten häufiger gelöscht- dies sollte bei Tests/Importen berücksichtigt werden. Ggf. sind hier Absprachen mit der MPDL notwendig.

Informationen zu CONE

 * CONE (Controlled Name Entities) verfügbar für:
 * Personen
 * Zeitschriften
 * mimeteypes
 * Lizenzen
 * Languages
 * DDC


 * Neue CONE-Datensätze müssen (momentan noch) von der MPDL erfasst werden
 * Änderungen müssen derzeit ebenfalls von der MPDL vorgenommen werden
 * Die Antwortzeit liegt bei etwa 1-2 Arbeitstagen (je nach Produktiv-Nutzern)
 * es ist geplant, dass pro Institut ein User das Recht erhalten soll, CONE-Datensätze anzulegen oder zu verändern (genauer Zeitpunkt noch unklar, vorauss. Mitte 2010)
 * Für Personensätze in CONE sind derzeit nur Vorname und Nachname sowie kompletter Name Pflicht
 * Es wäre sinnvoll, die üblichen Kurztitel einer Zeitschrift ebenfalls im CONE-Datensatz zu speichern und diese nach Auswahl einer Zeitschrift in der Eingabemaske in einem Zusatzfeld "Kurztitel" anzeigen zu lassen. Gergana wird mit den PubMan-Entwicklern besprechen, inwieweit dies umsetzbar ist.

ToDos

 * MPDL: Juliane prüft, wie die Inhalte der RSS-Feeds genau aussehen könnten (Link zum eSciDoc-Datensatz und Informationen zur ausgeführten Aktion / zum Status wären nützlich)
 * MPDL: Juliane klärt, ob "local tags" für best. Contexte vordefiniert werden könnten (z.B. "Tätigkeitsbericht", "no display" etc.)
 * MPDL: Juliane klärt, welches Format Daten haben müssen, die in CONE importiert werden (für Personen und Zeitschriften)
 * MPDL: Juliane klärt, ob Vollexte, die über "Locator" (Externe Referenz ) eingebunden sind, indexiert werden
 * MPDL: Juliane klärt, ob geschlossene OUs bei der Datensatzerfassung aus der OU-Gesamtliste herausgefiltert werden können, um diese nicht unnötig aufzublähen
 * MPDL: Juliane prüft die verschiedenen Möglichkeiten, feldspezifische Hilfetexte einzubinden
 * MPDL: Gergana klärt mit MPDL-Entwicklern, wie Kurztitel einer Zeitschrift am sinnvollsten erfasst / gespeichert werden können
 * MPDL / MUC : ggf. können obige Punkte bei einem Treffen der MPDL-Technik am 21.9. angesprochen werden
 * MUC: Workflows mit Wissenschaftlern besprechen (Juliane, Frau Kortüm)
 * HH: Workflow mit 3. (neuem) Wissenschaftler besprechen (Irina)
 * HH / MUC: Workflows mit Assistants durchsprechen (Frau Kortüm, Juliane, Irina)
 * Ergebnisse der Gespräche sollten auf der Talk-Seite dokumentiert werden


 * HH / MUC : Zeitnahe Definition von OUs, die dann im Projektverläuf noch verändert / erweitert werden können (Frau Kortüm, Irina)

Termine

 * Klärung per Doodle-Umfrage, ob am 19. oder 21. Oktober das Contens-Treffen stattfindet
 * Mitte Oktober TelKo zur Besprechung der Workflow-Befragungsergebnisse
 * Treffen am Rande des Contens-Termins am 20. Oktober von Juliane, (Gergana) und Irina zur Besprechung der Umsetzung Zitierstile
 * Videokonferenz 1 bis 2 Wochen vor Contens-Termin, um zu klären ob sich MUC, HH und MPDL bzgl. der Grundanforderungen an Contens einig sind