Talk:PubMan Func Spec Easy Submission
UC_PM_EASM_01 upload file in structured format[edit]
Status/Schedule[edit]
- Status: in design
- Schedule:R3
Motivation[edit]
- The user wants to upload a locally created BibTeX file, containing one reference.
Expected outcome[edit]
Reference is uploaded to a collection on PubMan.
The item is created on PubMan and can be edited/modified afterwards.
Steps[edit]
- The user chooses a collection where he has depositor privileges
- The user chooses to upload a file in structured format.
- The user starts the upload.
- The system processes the uploaded file, checks for completeness, creates an item and releases them immediately. The use case ends successfully.
Alternatives[edit]
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[edit]
User with depositing rights for at least one collection
Data involved[edit]
BibTeX File, structured format. See example file by the AEI.
Constraints[edit]
- BibTeX files are idiosyncratically structured; BibTool may help with preprocessing/normalization.
Does this mean we need not to provide any mapping?--Ulla 11:03, 26 February 2008 (CET)
- 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
Future development[edit]
- Upload files in structured format containing more than one reference
see Ingestion
Functional Prototype[edit]
Please check the functional prototype for easy submission
Comments functional team:
1) Default Metadata for an item (proposal Natasa)
- 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. For R3, we should do this as system setting. Future development might include local definition 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.
- check dependencies in spec "use as 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)
2) Genre-specific Metadata
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)
TODO with Early Adopters - Feedback to Easy Submission / functional Prototype: Overall feedback based on Prototype (labels, help text, wizards etc.) Set their allowed (prefered) genres in their collections and explain feature Crosscheck the genre-specific Metadata Matrix Crosscheck the default Metadata for item Matrix Crosscheck acceptance of feature "create item from template" in a)fetch metadata (providing an eSciDOc ID) b) from full item view c) after a submission
3) External locator for content: As just learned in Nijmgen, user needs the option to provide an external locator for fulltext. I.e., in addition to upload binary content (= upload file), he needs the option to specify an locator/identifier for the binary content located externally, together with the respective content categorie. This is true for Easy as well as normal submission. This external locator will not be part of Metadata, but modeled in content model.(component?)
4) Fetch MD, Step 3: Typo on GUI, short short. In addition, would re-phrase to "...might not cover all fetched Metadata". --Ulla 12:35, 15 February 2008 (CET)
Franke Michael commented on AS-316:
Only some remarks:
- Abstract prototype
- Step 2 (Select collection): Shouldn't there be a note about having only one collection or more than one? - Typo: "Continuer and complete" - After finishing step 5 there is a decision diamond without a condition. I guess it is the validation, right? - After this decision one is led to step 1.4? I guess this is a typo, too. - Another typo: "sucess message" - Step 2.1: I do not understand it: Is the upload and the preview on the same page? I would also appreciate some more information on the preview. Or will this be part of the GUI design? - Yet another typo: "successfull"
- Page flow
- The texts next to "choose collection" are swapped. - From "view item version" there is no direct way to submit the item, only to the Edit item mask.
- Choose Collection
- Can this be linked to the according colab page?
- Choose submission method
- Where does "cancel" lead?
- Manual submission step 2
- "content-type" is now "content category" - The design of a file input cannot be influenced by CSS. It only depends on the locale set in the clients browser and on the OS (Windows, Linux, Mac). I will attach some examples. The GUI design has to take this into account. - I guess the red star at "genre" means that this field is mandatory. Why isn't there one at "title"?
- Manual submission step 3
- Creator names are split up into "Name" and "Family name". I expect this would cause faulty entries, because "Name" often is associated either with the surname or with the full name. IMO "Family name" and "Given name" would be better. - Why should the user enter the number of a author? - Once entered, an author cannot be edited anymore, can he? - If so, there should at least be the possibility to move creators up or down. Otherwise, the following can occur: The user enters 5 authors. Then she recognises that she produced at the first author. Now she has to delete all 5 authors to bring them back into the right order. - Is there a concept for entering authors in a predefined format yet? See http://colab.mpdl.mpg.de/mediawiki/Talk:Providing_Lists_of_Authors#Varieties_of_Lists
- Manual submission step 4
- As it is decided that ONLY the "date published in print" will be asked for, there is no need for a dropdown meny, is there? - Because "Language", "Subject" and "Abstract" follow "Title of source, I as a user would have difficulties to decide if these fields belong to my publication or to its source.
- Bibtex import step 2
- Same for file input as above - If the import was successful, the user is lead to "Bibtex import step 3". What happens, if the import fails?
- Bibtex import step 3
- Here and on "Choose submission method" radio buttons are used. The user could save one click if we would use direkt links ?!?