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

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

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

Metadata

Graphical User Interface

Collaboration Laboratory

Central European Time