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:R4.1

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.1 The user gets an error message, indicating type of error (time out during upload, invalid file, validation rules not met).

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

4.1.b. User cancels the upload procedure.

4.2 For BibTeX upload: the BibTeX record contains "URL". In this case the system creates a full text within the record. The user can specify the content type and change the MIME Type in the edit mask afterwards. If the system is unable to upload the file, the user gets an error message and continues with step 3.

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

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: implemented
• Schedule:R4?

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)

Publication Management

Quality Assurance

Graphical User Interface

Metadata

Use Case

Reference Management Software for Lists of References

Uniform Resource Locator

Multipurpose Internet Mail Extensions

Albert Einstein Institute

Curses-Based Editor for BibTeX Bibliography Files

Enhanced Scientific Documentation

Collaboration Laboratory

Central European Time