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[edit]

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[edit]

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

Mandatory Fields/Validation[edit]

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.

Comment Nicole: For my unerstanding, this can be done via the validation rules for the validation point submit item. --Nicole 09:29, 10 January 2008 (CET)

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

Comment Nicole: already considered in the specificaiton/implementation.--Nicole 09:29, 10 January 2008 (CET)

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[edit]

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:

Change the genre (just to be able to submit?)
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[edit]

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[edit]

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 generated automatically by the system. Letters following the first capital letter should be "cut".

Data on creator should be: Name, Surname, Institution.

Comment Nicole: already implemented.

The input of groups (as a creator) should be offered further on. The group name is sufficient information.

Comment Nicole: already implemented.

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.

Comment Nicole: Will be considered.

Setup of user groups, should be specified by the input formats.

Comment Nicole: Should be re-checked with the pilots. Don't understand the requirement.

It should be possible to change the order of creators

Comment Nicole: Will be considered.

IP-Submission[edit]

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 (provision of affiliation information should not be mandatory.)

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

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

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

Checking / restriction on IP- Range should be given as an option, and should be administrated by the institute via "access list".

In addition to the IP-based submission it should also be possible to send suggestions via E-Mail.

As a lot of scientists manage their publications in BibTeX, the web form for suggesting entries for the IR should allow to attach BibTeX files.

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

Miscellaneous[edit]

Automatism for publications that are not yet published: the automatism should put the item on a regular basis into the workspace of the depositor or should send reminders, that the depositor should check the publication status (submitted, accepted and published). It should be possible to switch on /of this automatism.