Users that have the permission to ADD content to at least one collection will have an easy to use and intuitive user interface (this is related to the use case: End User - Easy and Intuitive Deposit Interface)
three options to start a submission
(priority 1) Drag & drop area to supply a file with bibliographic references or the fulltext. Depending on the recognized file format a pluggable process will be triggered on the server to initialize one or more items
(priority 1) support for RIS, EndNote, BibTeX
(priority 1) support for CSV, TSV
(priority 1) support for PDF file with metadata extraction using fulltext parsing (Grobid library) with fallback to the pdf metadata
(priority 2) the system will assign the submission automatically to one of collection available to the user depending on some pluggable logic based on the extracted metadata (out-of-box a mapping between dc.type and collections will be supported)
(priority 3) ... extends to other (?) common file formats
(priority 1) Create a new item specifying an identifier. Depending on the recognised identifier type one or more pluggable providers will be queried to retrieve the actual metadata and maybe the fulltext. The submitter can force the use of a specific collection or rely on the automatic guess described above
(priority 1) retrieve the metadata from Crossref, PubMed, PubMed Europe, arXiv, Cinii, Scopus and Web of Science
(priority 2) retrieve the fulltext from PubMed Europe, arXiv
(priority 3) ... extends to other (?) providers (ADS, DBLP, ...)
(priority 1) Create a new item from scratch. Depending on the number of collections where the submission can be done a dropdown to select the target collection will be shown or not. A default could be set to streamline the process.
(priority 1) The submitter or the responsible of the workflow should be able to change the collection at any time - this is related to the use case: Admin UI - Reviewers can move a submission to a different collection
once the submission is started a single form page is presented
(priority 1) options to enrich the record using identifiers or supplying file are still available
(priority 1) all the steps are presented as "accordion" in the same page giving immediate access to all the functionalities without the need to follow a single predefined linear process
(priority 1) the requested metadata are configured in an extended input-form configuration file with the following features
(priority 1) all the current options available in the input-form
(priority 1) additional input types: calendar, number
(priority 1) validation support: regex and ranges
(priority 1) size of the input box
(priority 1) put multiple metadata on the same row to save space
(priority 1) require or not to specify the language for a metadata, supporting mandatory of one or more values in specific languages and/or avoid input of multiple values for the same language
(priority 2) group some metadata together to be able to collect and keep in sync linked information such as the author name and the affiliation, the journal title and the ISSN, etc.
(priority 1) upload files
(priority 1) additional technical metadata will be automatically recorded with a pluggable framework (out-of-box JHove will be integrated) - this is related to the use case: Admin UI - Advanced Preservation - Format characterization
(priority 2) Sherpa/Romeo integration
(priority 3) ability to configure descriptive metadata requested for each file
(priority 1) deposit license. A must to agree license is presented before to send the submission to the workflow
(priority 1) creative commons license integration
(priority 1) access condition for the item metadata and each single files can be easily set:
inheriting collection policies
setting or adding custom policies for specific groups with/without a date validity
the system should detect near duplicates allowing the submitter to suspend or proceed the submission. See the existent feature in DSpace-CRIS
(priority 1) the transition between the current linear steps based submission wizard to the "single page" model should be clarified:
when temporary data are saved?
how item aware services like the sherpa/romeo integration or the detect duplicate are invoked? is it required a stored incomplete workspaceitem or should be based on an item mock?
(priority 1) the interaction with the BTE framework need to be revised to allow storing of the original PDF file or linked files in the generated item
(priority 1) support the definition of custom accordion like the current visibile custom steps
(priority 2) the inheritance of collection policies should be optional in the item creation
(priority 3) a validation framework to allow pluggable complex rules to be checked against the whole item before the submission should be introduced
(priority 4) it could be convenient to split the inputform in multiple files, one for each template definition
(priority 1) a REST endpoint need to be created to support item(s) creation from a file containing bibliographic references (RIS, Endnote, BibTeX, etc.) or PDF with metadata extraction
(priority 1) a REST endpoint need to be created to list the queued processes for an user
(priority 1) define REST endpoints for the detect duplicate features and the sherpa/romeo integration
(priority 1) define REST endpoint for the creative commons integration
