PubMan Func Spec Easy Submission

PubMan Functional Specification View · Browse Full Submission · Easy Submission Import · Export Quality Assurance · Search Collaboration · Copyright Collection Administration Organizational Unit Management User Management Feeding local webpages History of affiliations edit

Scenario

• Easy submission (short mask, fetch metadata, upload bibtex)is a feature available for any user with depositing rights, ie. available for any collection. easy submission does not have to be defined as submission method in the collection configuration. although, the publication workflows are defined on collection level. The workflows defined are independent from offering easy submission on gui.
• Agreed on different easy submission workflow that will consist of:
  • simple publication workflow (Depositor only, create->release, vP:very basic rules)
  • simple modification workflow (Depositor only, modify->release, vP: very basic rules)
  • QA workflow (previous standard modification workflow, but depositor is not allowed), modify&enrich->accept->(optionally)authorize->release, vP:strict rules defined by QA for each action
• If the collection has selected the standard publication workflow that does not mean that the "easy submission" features (GUI) will not be available to the user, the difference is only that the item is not immediately released after submit, but must undergo the QA workflow (as mentioned above).

• GUI issues: user has as a first starting point the possibility to select how she wants to provide her input to the system: fetching MD, uploading e.g. bibTex file, using the "short entry" mask or using the "standard entry mask". After that she is offered the possibility to further specify collection etc.

• Easy Submission mask is divided into the following steps:
  • Genre, Title, Files
  • Authors and Affiliations
  • Language, Source Title and Date
  • subject and abstract

Functional Specification

UC_PM_EASM_01 upload file in structured format

Status/Schedule

• Status: implemented
• Schedule:R3

Motivation

• The user wants to upload a locally created BibTeX file, containing one reference.

Expected outcome

Reference is uploaded to a collection on PubMan.

The item is created on PubMan and can be edited/modified afterwards.

Steps

1. The user chooses a collection where he has depositor privileges
2. The user chooses to upload a file in structured format.
3. The user starts the upload.
4. The system processes the uploaded file, checks for completeness, creates an item and releases them immediately. The use case ends successfully.

Alternatives

4. The user gets an error message, indicating type of error (time out during upload, invalid file, validation rules not met).

4a. User tries the upload again. continue with step 3.

4b. User cancels the upload procedure.

Actors involved

User with depositing rights for at least one collection

Data involved

BibTeX File, structured format. See example file by the AEI.

Constraints

• BibTeX files are idiosyncratically structured; BibTool may help with preprocessing/normalization.
  • e.g. upper and lower case corrections, resolving macros, unicode encodings vs. (la)tex encoding, etc.
• Basic TeX Parsing is needed to interpret non-ascii characters etc., see for example https://dev.livingreviews.org/projects/epubtk/browser/trunk/ePubTk/lib/bibtexlib.py .
• In BibTeX fields are not repeatable; thus multiple authors need to be parsed from the author field.
• BibTeX allows for different formats of representing an author's name; thus the parser needs to be smart enough to recognize them all. See for example http://search.cpan.org/~gward/Text-BibTeX-0.34/BibTeX/Name.pm

Suggested steps to prepare BibTeX files for import

• Normalize BibTeX with BibTool (resolves macros, may be used to map field names, unifies the syntax).
• Parse the - now normalized - records.
• Allow for/provide a mapping for non-standard fields (and possibly genres).
• Handle substructure of fields
  • Multiple entries in author and keyword fields. (see also http://nwalsh.com/tex/texhelp/bibtx-23.html)
  • (La)TeX encoding for special characters/formulae. (see for example https://dev.livingreviews.org/projects/epubtk/browser/trunk/ePubTk/lib/charmaps/tex2unicode.py)
• Map BibTeX fields/genres (including non-standard ones) to eSciDoc PubItem application profile. Mapping can be found here.
• Java Tools to check
  • http://jabref.sourceforge.net/
  • http://www-plan.cs.colorado.edu/henkel/stuff/javabib/

Future development

• Upload files in structured format containing more than one reference

see Ingestion

UC_PM_EASM_02 fetch fulltext by identifier

Status/Schedule

• Status: in design
• Schedule: R3.5

Motivation

• The User wants to create an item from an external system

Precondition

UC_PM_SM_04

Flow of Events

1-4: UC_PM_SM_04

5a: The system could retrieve a full text version. The file box is filled with the retrieved Info.

As default the system restrieves the pdf version if provided.

• The User can choose to see a preview of the uploaded file
• The User can choose to upload 'all available' files from the external system
• The User can delete the uploaded file and upload a different file from his own Directory

5b: The system couldn’t retrieve a full text version, no entries in the file box:

• The User gets a message why the upload failed
  • Failure1: There is no fulltext version in the external system
  • Failure2: Technical problems when communicating with the external system (Probably try later or something)
• The User can choose to upload a file from his own Directory

6: Continue with use case UC_PM_SM_02 edit item

The user should not be able to change the name of an uploaded file (uploaded automatically or manually)

Expected outcome

• Easy and fast submission of an item, the full text version is attached

Fetching Data from arXiv

The Full Text Version can be retrieved with:

• http://arxiv.org/pdf/ +arXiv ID (pdf)
• http://arxiv.org/ps/ +arXiv ID (ps)
• http://arxiv.org/src/ +arXiv ID (tex)
• http://arxiv.org/html/ +arXiv ID (html) Found one example with html (http://arxiv.org/html/cs/9811020)

We don't try to retrieve a fulltext version in html because it is very rare

Actors involved

• Depositor

Alternatives

• We don`t upload the file, we only link to the external server (e.g.: http://arxiv.org/pdf/astro-ph/0701495 this url always links to the current version).

This alternativ was discussed and rejected.

General Thoughts

• Should we enhance the (technical) metadata of an item with the information where the item originally was created?

• We should add something like a progress bar when importing data from another system

• The system must take precautions not to get blocked from arxiv for indiscriminate automated download (see http://arxiv.org/RobotsBeware.html).

Future developments

Default Metadata for an item

Status/Schedule

• Status: in specification
• Schedule:to be defined

• • default content category per genre (specified default MD)
  • default creator roles per genre (specified default MD)
  • default source genre per item genre (specified default MD)
  • default creator role if creator is of type organisation (specified default MD)
  • default affiliation (same as previous)(specified as default on GUI)

Default Metadata for an item means, that in the system a default item template is created, with defaulted metadata. As a start, we should do this as system setting. Future development might include some local definitions of item templates on collection level.

Default Metadata means, that they are pre-populated on the GUI, as a kind of proposal, but can be changed by the user.

Context to collection settings: On collection, the allowed genres are defined. In the default MD setting, the default MD for a certain genre or certain creator role are defined.

TODO:

• define sensible defaults in matrix - where to document the matrix in CoLab
• check dependencies in spec "create item from template", "create new revision"=> we have collection settings (limitation of allowed genres), we have default Metadata. In case an item is used as template, the templated item should "overwrite" the default Metadata, but cannot overwrite the collection setting. (?) --Ulla 13:26, 27 February 2008 (CET)

Genre-specific Metadata

Status/Schedule

• Status: in specification
• Schedule:to be defined

Genre-specific Metadata are bound to a certain application profile and are defined as system setting.

This matrix describes the Metadata elements, which are always OR never OR optionally displayed on the edit mask (in easy submission, in normal submission), dependent on a certain genre type. Optional displayed means, that the user has the option to fill them , if needed, but they are somehow "hidden", as less used. This matrix is needed for GUI design. Genre-specific Metadata are not related to validation rules!

TODO:

• define matrix of genre-specific Metadata (Dimensions: Genre, Metadata or Metadata group. Values: always on Easy Submission, always on Normal Submission, optional on ESM, always on NSM). Documentation in CoLab.
• crosscheck assumptions on genre-specific MD with Early Adopter (using functional prototype)

Discussion

Please comment on functional specification under Discussion page

Functional Prototype

Please check the functional prototype for easy submission

Check here Lists of Authors for R3.8 Providing Lists of Authors

Publication Management

Quality Assurance

Graphical User Interface

Metadata

Use Case

Reference Management Software for Lists of References

Albert Einstein Institute

Curses-Based Editor for BibTeX Bibliography Files

Enhanced Scientific Documentation

Portable Document Format

Identifier

Collaboration Laboratory

Central European Time