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)

The edit mask should be more aligned to the 'item version view', to make the user more familiar with the order of the metadata (Basic, Persons/org., ...) Rupert 12:03, 21 December 2007 (CET)

Easy submission

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

Mandatory Fields/Validation (Pflichtfelder/Validierung)

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

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

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

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

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

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

• 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)

If the validation failed and the user has to change/add something it would make sense to show the relevant fields below the message for fast entry. Rupert 12:09, 21 December 2007 (CET)

Allowed Genre as collection setting

Discussion on genres transfered from Jira AS-269

Kiefl Rupert - [12/Dec/07 11:53 PM]

The collection defines genres available for submission. Is this done to block explicitly all other genres?

Lets walk through the case: The user wants to create a new revision. He chooses a different collection and wants to submit. The system states he has a wrong genre and can not submit.

The user has the following options:

1. Change the genre (just to be able to submit?)
2. Contact the administrator to add a new genre to the collection?

Both ways seem to be not satisfying. Can we add a genre to the collection automatically if an item was added with an unknown/not allowed genre?

Tschida, Ulla - [13/Dec/07 09:47 AM ]

see my answers to your questions below:

The collection defines genres available for submission. Is this done to block explicitly all other genres? => It is due to the reason, that some institutes are not at all interested in our 15(?) genres, but just in some of them. By defining allowed genres for a collection, they have a "customized" drop down list, for their mostly relevant publication types.

use case create new revision: indeed a critical point...background is, we have the feature that genres are "allowed" for a collection (see comment above). but when creating revisions, you might want to change the genre, and you might want to create the revision in a new collection, and then the collection and the genre are not compatible.

I know that proposed solution is not optimal. Alternatively, we could say: when creating a revision, the item data are pre-filled (from source item), except genre. Therefore, user would have to state the genre again, when creating a revision. Not sure what is "muehsamer".

The option 2 you mention, is of course not possible. Option 1 neither, he would have to change the collection (collection policies...rules are always mühsam)

We identified when creating a new revision that there may be problems with the genre and in this case we have the following options having in mind genre is "inherited" as a default metadata of the revision.

Reference to use case step 9, options a and b. Option a: if genre is allowed in the collection, genre is inherited Option b: (in my opinion should be): if genre is not allowed in the collection, genre is not inherited Would doubt that creation of a new revision is always a same genre as the previous revision, but may be :) --Natasa 11:11, 21 December 2007 (CET)

OK, agreed Rupert 11:58, 21 December 2007 (CET)

Full texts/Files (Volltexte/Files)

• Files should be compressed automatically when uploaded. (Addition after validation 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).

• Content type "supplementary material" can be used for the moment, but will potentially be revised after the system has been put to production.

Data input

• Basic submission should check the minimum input for a genre. But power users should in any case be able to use all metadata fields (expert view), as well as to configure which metadata can be filled in for a specific genre. If the document type is changed at a later point, no data should be lost. (Problem eDoc: When a Genre type is later changed, metadata belonging to fields that are no longer provided get lost.)

• A flexible submission mask is very important.

• The connection between persons and affiliations is important. Idea: after an affiliation has been chosen for the first author, it should be used as default for all additional authors (noted in UC_PM_CM_02).

• The option to enter a checksum is not relevant for Release I.

Addition after checking with SMC: All references to user-run checksums were completely removed from the specification.

• Input should be supported by classifications/controlled vocabulary, as well as import interfaces from reference management programs.

• Data should be temporarily saved during input, without the need for the depositor to save them explicitly / actively.

This would not be very nice as the user will after finalization have many versions and system does not know when to triger certain actions after saving the item. Clarify please what is meant with temporary? --Natasa 16:51, 21 December 2007 (CET)

• Logical constraitns between metadata should be reflected on the input mask. E.g: if the external publication status is "submitted", the field "Publication Date" should not be displayed.

Comment Nicole: This Feedback was also given by Wolfang during the interview on easy submission. Problem: we don't have publication status in our MD set.

• The context-sensitive help texts of the input mask should be configurable by the institute.

• During the input, the user should also be given not standardized data, that are already in the system, so that the input mass will be reduced (e.g. set up of a local data pool with conference dates).

• It sould be possible to enter persons via using the autopsi principle.

• Initials should be automatically system-generated. Letters following the first capital letter should be "cut".
  (Initialen sollten vom System automatisch generiert werden. Nach dem ersten Großbuchstaben im Vornamen sollte "abgeschnitten" werden.)

• Personal Data: Name, Surname, Institution.
  (Angaben pro Person: Vorname, Nachname, Institution.)

• The input of groups (as a creator) should be offered further on. The group name is sufficient information.
  ( Die Eingabe von Gruppen (als creator) sollte weiterhin angeboten werden. Als Angabe genügt der Gruppenname.)

• It should be possible to copy and paste multiple author names into an input field. The system should be able to structure and translate this information into the input mask by means of specific separators.
  (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.)

• Setup of user groups, (should be?) specified by the input formats.
  (Einrichten von Benutzergruppen, durch die Eingabeformate bestimmt werden.)

• changing the order of creators - Requirements? (Anforderungen?)

IP-Submission

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

• IP- Depositor should provide following additional data, when he wants to make a submission: Name, e-mail, telephone, affiliation (providing of affiliation information should not be obligatory.)

(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. )

• A very simple input mask is needed for the IP-Depositors; the input mask should be customized by the institutes.

(Eine sehr simple Eingabemaske ist nötig für den IP-Depositor; Eingabemaske sollte durch Institute anpassbar sein. )

• Users outside the IP-Range should be able to make submissions as well.

(Auch User außerhalb der IP-Range sollten Einträge vornehmen können.)

• The option to upload files should be configurated for the IP-based submission.

(Bei der IP-basierten Eingabe sollte die Möglichkeit zum Datei-Upload konfiguriert werden können. )

• Affiliation of the IP-Depositor should not be a mandatory field in the IP-based submission.

(Affiliation des IP-Depositors sollte bei IP-based submission kein Pflichtfeld sein.)

• Crosschecking / restriction of the IP- Range should be given as an option, and should be administrated by the institute with the help of an "access list".

(Prüfung/Restriktion auf IP- Prange sollte als Option gegeben sein, soll vom Institut mittels "access Liste" administriert werden.)

• Suggestions per e-mail should be allowed, as a supplement to IP-based submission.

(Komplementär zu IP-basierten Submission sollten Vorschläge per eMail zugelassen werden.)

• Configurability of the IP-Depositor input form: should be configurable from a "single-field" form to more complex forms.

(Konfigurierbarkeit des Inputformulars des IP-depositor: von einem "Einfeld-Formular" bis zu komplexeren konfigurierbar.)

• Scientists manage their own data with bibTex => the webform for "suggestions" should make it possible to send bibTex files along.

(Wissenschaftler verwalten ihre eigenen Daten mit bibTex => Webform für "Vorschläge" sollte Mitschicken von bibTeX Dateien ermöglichen)

Miscellaneous/Sonstiges

• Automated follow-up of the process up until publication (submitted, accepted and published) for the depositor. The depositor should be able to determine that the item be resubmitted to him after certain intervals, so that he may check if the publication status in the Journal has been changed.

(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

Central European Time

Reference Management Software for Lists of References

System Management Controller

Electronic Documentation

Use Case

Metadata

Internet Protocol

Central European Summer Time