Page History

...

(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

(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 - this is related to the use case: Structure - Format checking of data entry in input forms
(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) 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 - this is related to the use case: Structure - Describe Individual Bitstream within an Item

(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 This is related to the use case: Detect potential duplicates see also the existent feature in DSpace-CRIS

...

Page tree