Difference between revisions of "Peer: Author Deposit"

Revision as of 12:50, 9 September 2009

This page contains the specification of author deposits in the PEER project.

---- Work in progress ----

The Author Deposit Scenario[edit]

Schema will follow

Submission of Publications[edit]

Authors are invited to self deposit publications to the PEER repositories.

Status/Schedule[edit]

Status: in design

Actors[edit]

Depositor

Flow of Events[edit]

1. A user chooses to deposit his publication to the PEER depot.
2. The user can enter basic metadata by using a webform
3. The user can upload a PDF file
- 3.1. The system checks the file mimetype and gives an error message when the file is not recognized as application/pdf.
4. The user selects a journal name from a provided list
5. The user finalizes the submission by submitting the filled form
- 5.1. The user needs to fill out a captcha to avoid spamming
6 The webform performs a simple validation
- 6.1. The webform content is validated successfully:
  - 6.1.1. The system shows a confirmation message stating that (in case the user provided his/her email) an email will follow containing the links to his article in participating repositories (Peer Depot Functionality starts here)
- 6.2. The webform content is validated unsuccessfully:
  - 6.1.2. The system informs the user on missing/not populated mandatory fields, asks the user to correct the entries and re-submit the form again.
7. The system packs the metadata and the PDF file into an archive and saves the content to a dedicated directory on the server (Additional Peer Help Desk functionality: scheduled task of sending the content daily)
8. The use case ends successfully.

Constraints[edit]

No deposits will be stored, if the PEER Depot is not available the author attempt will be unsuccessful.
The user can not decide to which repository his publication is deposited to, the publication will be deposited to all participating reps.

Open Questions[edit]

What are the minimal requirements of metadata (validation)?
- structural constraints see Metadata section below
In what format do we send the metadata to the PEER depot?
How do we talk to the FTP server? which host? which account credentials?

Additional Information[edit]

The basic deposit webform will be hosted at the MPDL (same server as track system).

Processing and Deposit of Publications[edit]

All further steps (including duplicate check) will be developed by INRIA.

Metadata[edit]

Authors need to provide the following metadata from the deposit form:


Label	Occurence {min, max}	Description	Comment
dc:title	{1,1}	Article title
dc:creator	{1,1}	Corresponding Author's name: Last Name, First Name	Should there be other authors as well?
foaf:mbox	{ 0,1}	Corresponding Author's email
dc:description	{0, 1}	Abstract
dc:date	{0,1}	Date of publication	Should not this be date of acceptance?
dc:type	{0,1}	Type of publication	Mapped to info:eu-repo/semantics/article, info:eu-repo/semantics/acceptedVersion
dc:source	{1,1}	Journal name	Selected from list of journals during depositing

In this case:

prefix dc: is used for Dublin Core Profile
prefix foaf: is used for FOAF Profile

@@ Line 21: / Line 21: @@
 *3.	The user can upload a PDF file
 **3.1.   The system checks the file mimetype and gives an error message when the file is not recognized as application/pdf.
-*4.	The user can select a journal name from a provided list
+*4.	The user selects a journal name from a provided list
-*5.     The user can send the metadata and the file to the Peer Depot.
+*5.     The user finalizes the submission by submitting the filled form
 **5.1.   The user needs to fill out a captcha to avoid spamming
 *6      The webform performs a simple validation
-**6.1.	The webform content is validated successfully
+**6.1.	The webform content is validated successfully:
-**6.2.   The webform content is validated unsuccessfully and the user gets a feedback that the content was not sent (he can change the content and try again).
+***6.1.1. The system shows a confirmation message stating that (in case the user provided his/her email) an email will follow containing the links to his article in participating repositories (Peer Depot Functionality starts here)
-*7.     The content is send to the PEER depot via FTP
+**6.2.   The webform content is validated unsuccessfully:
-**7.1.   The content can successfully be deposited to the Peer Depot. The user gets confirmation message, stating that an email will follow containing the links to his article in participating repositories. The use case ends successfully.
+***6.1.2. The system informs the user on missing/not populated mandatory fields, asks the user to correct the entries and re-submit the form again.
-**7.2.   The PEER depot is unavailable, the user gets a message, that the content could not be transferred to the PEER depot - the use case ends unsuccessful.
+*7.     The system packs the metadata and the PDF file into an archive and saves the content to a dedicated directory on the server (Additional Peer Help Desk functionality: scheduled task of sending the content daily)
+*8. The use case ends successfully.
 ===Constraints===