Talk:PubMan Submission

This page gathers feedback by the pilots and early adoptors, that was given so far and that will be given for future releases. Please feel free to add your own feedback here and sign your comments with a signature (see menu bar above).

Overall remarks

• Submission very important, decision-making criterion for/ against PubMan. (Submission sehr wichtig, Entscheidungskriterium für/gegen PubMan)

Easy submission

For ideas on easy submission, please visit the PubMan_Easy_Submission page.

Mandatory Fields/Validation (Pflichtfelder/Validierung)

• The limits for the submission criteria should not be set too low. Each institute should be able to define the mandatory fields of the input mask.

(Hürde für die Submissionkriterien sollten nicht zu tief angesetzt werden. Pflichtfelder für die Eingabemaske müssen vom Institut definiert werden können.)

• Mandatory fields of the input mask do make sense; only, however, if the user receives online help-texts and tips (context sensitive).

(Pflichtfelder für die Eingabe sind sinnvoll, allerdings unter der Bedingung, dass man Online Hilfetexte und Erläuterungen (kontextsensitiv) bekommt.)

• Mandatory metadata should not be specified only according to collection level, but also according to user roles and preferences.

(Obligatorische Metadaten sollten nicht nur auf Collection-Ebene festgelegt werden können, sondern auch für Nutzerrollen und auf Preferenzes-Ebene.)

• Publication workflow for Release I should be configurable in such a way, that „validate item version“ function could have restrictive as well as informative character.

( Publikationsworkflow für Release I muß so konfigurierbar sein, dass Funktion „validate item version“ sowohl restriktiv als auch informativ ausgeführt werden kann.)

• There should be different validation types with different validation rules. (e.g. for catalogs, BibTeX files, different Genre types, different users).

(Es muß versch. Validierungstypen mit versch. Validierungsregeln geben (z.B. für Catalogs, BibTeX files, versch. Genre types, versch. Nutzer).

• Min. data for Repository Managers should be configurable (mandatory fields, "warning fields", fields that can be hidden)

(Minimalangaben für Repository Manager konfigurierbar (Pflichtfelder, „Warnfelder“, Felder ausblendbar).)

• After the user has saved for the first time, he should be given system "warnings" as to which data are still missing. But it should also be possible to save without this check. The warnings should be graded according to their importance (example: traffic-lights-system)

(Nachdem man das erste Mal auf „save“ gedrückt hat, sollte das System dem Nutzer in Form von „warnings“ anzeigen, welche Datenangaben noch fehlen. Es sollte jedoch auch möglich sein ohne diese Überprüfung zu speichern. Die Warnungen sollten nach Wichtigkeit abgestuft sein. (Beispiel Ampelsystem))

Full texts/Files (Volltexte/Files)

• Files should be compressed automatically when uploaded. (Addition after checking with SMC: the zipping of files is a technical, not a functional requirement. Questions concerning the concrete functional requirements will be forwarded to the pilot list).

(Files sollten vom System beim Hochladen automatisch komprimiert werden (Nachtrag nach Validierung mit SMC: Das Zippen von Files ist keine funktionale Anforderung, sondern eine technische. Die Frage nach konkreten funktionaler Anforderung wird noch mal separat an Pilotliste gerichtet).)

• Content type „supplementary material“ will be used as it is for the moment and it will eventually be further modified after the system has been put to use.

( Content type „supplementary material“ wird vorerst so verwendet werden und erst nach einer ersten Nutzung des Systems eventuell weiter differenziert.)

Dateneingaben

• Basic submission sollte Mindestangaben für ein Genre abfragen. Aber Poweruser sollte in jedem Fall alle Felder aus dem Metadatenset zur Verfügung haben (expert view) bzw. konfigurieren können, welche Metadaten für ein bestimmtes Genre gefüllt werden können. Bei nachträglicher Änderung des Dokumenttyps dürfen keine Angaben wegfallen. (Problem eDoc: Bei nachträglicher Genretyp Änderung fallen Metadaten weg, die über die vorgesehenen Felder hinausgehen)
• Ein flexible Eingabemaske ist wichtig
• Auswahl „genre type“ fehlt im UC_PM_SM_01 create item. Edit view ist abhängig vom ausgewählten genre type (Nachtrag nach Validierung mit SMC: Ist abgedeckt durch Punkt 4 in Basic course of events).
• Verknüpfung von Personen und Affiliation wichtig. Idee: nach der Auswahl der Affiliation für den ersten Autor sollte diese defaultmäßig für alle weiteren Autoren voreingestellt sein (in UC_PM_CM_02 vermerkt).
• Möglichkeit für den Nutzer, eine checksum einzutragen, wird als nicht relevant für Release I gesehen
  • Nachtrag nach Validierung mit SMC: Das Angeben von checksums für Nutzer wurde komplett aus der Spezifikation genommen.).
• Unterstützung der Eingabe durch Klassifikationen /kontrolliertes Vokabular sowie durch Importschnittstellen aus Literaturverwaltungssysteme
• Die Daten sollten während der Eingabe temporär mitgespeichert werden, ohne dass der Depositor explizit/aktiv speichern muss.
• Logische Abhängigkeiten der Metadaten sollten sich in der Eingabemaske widerspiegeln. Z.B. wenn der external Publication Status "submitted" ist, sollte das Eingabefeld "Publikationsdatum" nicht angezeigt werden.
• Die kontextsensitiven Hilfetexte in der Eingabemaske sollten pro Institut konfigurierbar sein.
• Während der Eingabe sollten dem Benutzer auch nicht normierte Daten, die bereits im System enthalten sind, zugespielt werden, um die Eingabemasse zu verringern (Z.B. Aufbau eines lokalen Datenpools mit Konferenzdaten).
• Eingabe der Personenangaben nach Vorlage (Autopsie-Prinzip).
• Initialen sollten vom System automatisch generiert werden. Nach dem ersten Großbuchstaben im Vornamen sollte "abgeschnitten" werden.
• Angaben pro Person: Vorname, Nachname, Institution.
• Die Eingabe von Gruppen (als creator) sollte weiterhin angeboten werden. Als Angabe genügt der Gruppenname.
• Für die Eingabe von mehreren Autoren sollte es möglich sein, dass man selbige per copy and paste in ein Eingabefeld einfügen kann. Anhand bestimmter Trennzeichen sollte das System dann die Angaben strukturieren und in die Eingabemaske übersetzen.
• Einrichten von Benutzergruppen, durch die Eingabeformate bestimmt werden.
• changing the order of creators (Anforderungen?)

IP-Submission

Status: IP Submission is currently out of scope --Inga 16:40, 14 September 2007 (CEST)

• IP-Depositor muss folgende (zusätzliche) Angaben machen, wenn er eine Submission vornehmen möchte: Name, E-Mail, Telefon, Affiliation (Affiliation sollte keine Pflichtinformation sein.
• Eine sehr simple Eingabemaske ist nötig für den IP-Depositor; Eingabemaske sollte durch Institute anpassbar sein.
• Auch User außerhalb der IP-Range sollten Einträge vornehmen können.
• Bei der IP-basierten Eingabe sollte die Möglichkeit zum Datei-Upload konfiguriert werden können.
• Affiliation des IP-Depositors sollte bei IP-based submission kein Pflichtfeld sein.
• Prüfung/Restriktion auf IP- Prange sollte als Option gegeben sein, soll vom Institut mittels "access Liste" administriert werden.
• Komplementär zu IP-basierten Submission sollten Vorschläge per eMail zugelassen werden.
• Konfigurierbarkeit des Inputformulars des IP-depositor: von einem "Einfeld-Formular" bis zu komplexeren konfigurierbar.
• Wissenschaftler verwalten ihre eigenen Daten mit bibTex => Webform für "Vorschläge" sollte Mitschicken von bibTeX Dateien ermöglichen

Sonstiges

• automatische Wiedervorlage für den Prozess bis zur Veröffentlichung (submitted, accepted und published) für den Depositor. Depositor möchte einstellen, dass ihm der item in bestimmten zeitabständen noch mal vorgelegt wird, um zu prüfen, ob sich der Publikationsstatus beim Journal geändert hat.

Publication Management

Reference Management Software for Lists of References

System Management Controller

Electronic Documentation

Use Case

Internet Protocol

Central European Summer Time