PubMan Func Spec Submission

From MPDLMediaWiki
Jump to navigation Jump to search
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

UC_PM_SM_01 create item[edit]

The user selects a collection where she wants to create a new item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to create a new item.
  • this use case may additionally be invoked by the following use cases:
    • create item from template
    • create new revision of an item
    • fetch metadata from external system

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • None.

Flow of Events[edit]

  • 1. The user chooses to create an item.
  • 2. The system displays a list of all collections in state "opened" for which the user has the privileges as Depositor.
  • 3. (Optionally) The user chooses to view the collection description.
    • 3.1. The system displays the collection description.
  • 4. The user selects a collection of her choice.
  • 5. continue with use case UC_PM_SM_02 edit item

Alternatives[edit]

  • 2a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
    • 2a.1. Continue with Flow of Events step 5.
  • 2b If the user has in his/her private preferences a target collection defined and the user has depositor privileges for that collection, the system automatically selects the collection.
    • 2b.1. Continue with Flow of Events step 5.
  • 2c The system may offer to the user the collection to where she last created the item successfully.
    • 2c.1 Continue with Flow of Events step 5.

Post-Conditions / Results[edit]

  • None

Future development[edit]

  • when creating new item default values for attributes and metadata values are inherited from the metadata set and the collection settings. Collection settings overwrite values inherited from the metadata set.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item

UC_PM_SM_02 edit item[edit]

The user edits the last version of an item while executing a task in the publication or in the modification workflow defined for the collection of the item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to change or provide data for an item.

Actors[edit]

  • Depositor
  • Moderator
  • Metadata Editor

Pre-Conditions[edit]

  • Last item version is selected or this use case was invoked from UC_PM_SM_01 create item
  • One validation point is selected.

Flow of Events[edit]

  • 3. The system displays an edit view with the metadata from the last version of the item or pre-filled metadata.
  • 7. (Optionally) Include use case UC_PM_SM_16 file upload
  • 5. (Optionally) The user edits the item attributes, adds new metadata values or modifies existing metadata values. This includes the selection of an entry from an authority file which is linked to a metadata element. For dealing with organizations when creating the metadata element "Organisation" see 11.2.
  • 6. (Optionally) The user chooses to view the collection description.
    • 6.1. The system displays the collection description.
  • 10. (Optionally) The user removes one or more uploaded files.
  • 11. Extension point: validate data.
    • 11.1. If the user wants to validate the data of the item include use case UC_PM_SM_09 validate item for the selected validation point.
  • 12.a. The user decides to finalize the editing of an item by submitting the item.
    • 12.a.1. The system creates a new version of an item. Continue with use case UC_PM_SM_03 submit item
    • 12.a.2. If the item version can not be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.

Alternatives[edit]

  • 12.b. The user decides to finalize the editing of an item by saving the item without submitting.
    • 12.b.1. The system creates a new version of an item. The use case ends successfully.
    • 12.b.2. If the item version can not be created the system displays an appropriate error message or a validation report. The use case ends unsuccessfully.

Post-Conditions / Results[edit]

  • A new item version is created and validated in accordance with selected validation point.

Future development[edit]

  • possible use case for look-up of metadata triggered during edit item to serve for fetching specific set of metadata e.g. source metadata(book, conference paper, event)
  • file locator - possible use case to specify a file locator for a fulltext such as:
  • 8. (Optionally) The user adds one or more file locators to the item.
    • 8.1. The system sets default values for file attributes from the collection settings and displays an edit view for the file.
    • 8.2. The user enters a locator for the file, selects the visibility if not already set and the content type.
    • 8.3. (Optionally) The user changes the visibility, the content type, the mime type or enters a description.
    • 8.4. The user confirms the entries.
    • 8.5. The system links the file to the item.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_02_edit_item

UC_PM_SM_03 submit item[edit]

The user submits the last version of the item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to submit an item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state "pending" or "in rework".

Flow of Events[edit]

  • 1. The user chooses to submit the selected item or the item was selected by a previous use case.
  • 2. The system checks if the collection of the item is in state "opened" and if the user has the privilege as Depositor.
    • a. The collection is in state "opened" and the user has the privilege as Depositor.
    • b. The collection is not in state "opened". The systems displays an error message (MSG_PM_SM_02_A). The use case ends without success.
    • b. The user has not the privilege as Depositor. The systems displays an error message (MSG_PM_SM_02_B). The use case ends without success.
  • 3. Include use case UC_PM_SM_09 validate item for validation point "submit".
  • 4. The system checks the validation report status.
    • a. The validation report status is valid.
    • b. The validation report status is invalid. The selected item is unaffected. The system displays an error message (MSG_PM_SM_03). The use case ends without success.
  • 5. The system prompts for a confirmation of the submission.
  • 6. (Optionally) The user enters a comment for the submission.
  • 7. The user confirms the submission.
  • 8. The system sets the status of the item version to "submitted".
  • 9. The system displays a success message (MSG_PM_SM_04). The use case ends successfully.

Alternatives[edit]

  • 7a. The user does not confirm to submit the item.
    • 1. The selected item is unaffected. The use case ends without success.

Post-Conditions / Results[edit]

  • The item version is in state "submitted".

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_03_submit_item

UC_PM_SM_04 fetch metadata from external system[edit]

The system fetches metadata from an external system providing an external identifier. These metadata are used to populate metadata for a new item.

[Start-Dev-QA]

Proposal: The "fetch" metadata is actually a single item ingestion. Should be excluded from UC_PM_SM_02_edit_item and included as separate start use-case (such as create item, create item from template) because it raises a lot of complexity in edit item.--Natasa 13:52, 21 December 2007 (CET)

This idea was discussed in a meeting of the functional team and at that time, we explicitely decided against a separate start use-case for "create-item-via-metadata-fetch" because we wanted to provide the user with this possibility on the edit interface. I guess it's a question of personal preference... --Inga 20:53, 1 January 2008 (CET)

[Comment Nicole:] Natasa, Ulla, please decide. I would agree to Inga and leave it as it is, unless it is too hard to understand the UC. --Nicole 11:25, 8 January 2008 (CET)

From the usability point of view it would be ok to have the 'fetch metadata' at the time, the user has to provide it (in the edit mask). Otherwise the user is confronted with a new question before he can enter the edit item mask. Rupert 13:53, 8 January 2008 (CET)
[Comment Natasa:] To my understanding, we can even have the following flow of events: user selects item as a template to create a new item, goes to the edit mask, and there fetches the metadata from another source, because it is offered on the edit mask as well. In this case, technically we need to know from where we came into the edit mask, and disable/enable some features e.g. if user came from create from template -> do not allow fetch metadata; if user created an item with the default metadata of the collection inherited -> allow fetch metadata --Natasa 17:40, 16 January 2008 (CET)

[End-Dev-QA]

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to fetch the metadata of an item from an external system.
  • This use case is included by the use case UC_PM_SM_02 edit item.
Proposal: remove the inclusion in edit item use case, but do it vice-versa. --Natasa 15:16, 21 December 2007 (CET)
See comment above. --Inga 20:54, 1 January 2008 (CET)

[Comment Nicole:] See comment above. Should be decided by Ulla and Natasa. --Nicole 11:25, 8 January 2008 (CET)

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The item is not persistent.
  • The user is the owner of the item version.

Flow of Events[edit]

  • 1. The user chooses to harvest metadata from an external service.
  • 2. The system displays a list of all available ingestion sources which provide an ID fetch method.
  • 3. The user selects one ingestion source and specifies an external ID appropriate to the selected ingestion source. The user confirms the input.
  • 4. The system queries for item metadata with the specified ID.
    • 4.a. The system receives item metadata for the specified ID and transforms the received metadata to metadata values of the internal metadata set. These metadata values overwrite the existing metadata values of the item. The use case ends successfully.

[QA-Dev-Start]

Proposal: Instead "use case ends successfully" use "Continue with use case UC_PM_SM_02 edit item " --Natasa 15:31, 21 December 2007 (CET)

See comment above --Inga 20:56, 1 January 2008 (CET)

[QA-Dev-End]

    • b. The query fails. The system does not receive item metadata for the specified ID. The system displays an error message. Continue with step 2.

Post-Conditions / Results[edit]

  • Fetched metadata are transferred to the item version.


Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_04_fetch_metadata_from_external_system


UC_PM_SM_05 create item from template[edit]

The user creates a new item by using another item as a template and provides item data.

Status/Schedule[edit]

  • Status: not implemented
  • Schedule:to be defined

Triggers[edit]

  • The user wants to create a new item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.

Flow of Events[edit]

  • 1. The user chooses to create a new item from the selected item. The metadata values are taken from the selected item.
  • 2. Continue with use case UC_PM_SM_01 create item


Post-Conditions / Results[edit]

  • none

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_05_create_item_from_template

UC_PM_SM_06 delete item[edit]

The user deletes an item which is not released.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R1

Triggers[edit]

  • The user wants to delete an item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state "pending" or "in rework".
  • No item version in state "released" exists.
  • The user is the owner of the last version of the item.

Flow of Events[edit]

  • 1. The user chooses to delete the selected item or the item was selected by a previous use case.
  • 2. The system prompts the user to confirm the item deletion.
  • 3. The user confirms to delete the item.
  • 4. The system deletes the item, all existing relations where this item is a source item and displays a success message (MSG_PM_SM_05). The use case ends successfully.

Post-Conditions / Results[edit]

  • The selected item is deleted.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_06_delete_item

UC_PM_SM_07 change collection of item[edit]

The user moves the item from one collection to another.

Status/Schedule[edit]

  • Status: not implemented
  • Schedule:to be defined

Triggers[edit]

  • The user wants to move the item from one collection to another.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
  • The last item version is in state "pending" or "in rework".
  • The user is the owner of the item.
  • The user is in role "Depositor" for more than one collection.

Flow of Events[edit]

  • 1. The user chooses to change the collection.
  • 2. The system displays a list of all collections in state "opened" for which the user has the privileges as Depositor.
  • 3. (optionally) The user chooses to view the collection description.
    • 3.1. The system displays the collection description.
  • 4. The user selects a collection and confirms the choice.
  • 5. The system checks the item data against values and functionality allowed by the collection.
    • a. The item data is in accordance with the allowed values and functionality of the collection.
    • b. The item data is not in accordance with the allowed values and functionality of the collection. The system displays an error message (MSG_PM_SM_06). The use case ends unsuccessfully.
  • 6. The system checks the item data against the default values of attributes and metadata definitions of the collection.
    • a. The item data is in accordance with the default values of the collection.
    • b. The item data is not in accordance with the default values of the collection. The system prompts the user to confirm that the item data is not overwritten.
      • 6.1. The user confirms not to overwrite the item data.
  • 7. The system changes the collection of the item and displays a success message (MSG_PM_SM_07). The use case ends successfully.

Alternatives[edit]

  • 6.b.1.a. The user confirms to overwrite the item data.
    • 1. The system overwrites the existing attribute values of the item with the collection’s settings for attribute values.
    • 2. The system overwrites the existing metadata values of the item with the collection settings for metadata values.
    • 3. The system creates a new item version, stores it and displays a success message (MSG_PM_SM_08) Continue with flow of events step 7.

Post-Conditions / Results[edit]

  • The item has been moved to another collection.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_07_change_collection_of_item

UC_PM_SM_09 validate item[edit]

The last version of an item has to be validated.

Status/Schedule[edit]

  • Status: implemented
  • Schedule:R1

Triggers[edit]

  • The item has to be validated.
  • This use case is included by the use cases UC_PM_QA_01 confirm pre-check item, UC_PM_QA_03 accept item, UC_PM_QA_10 accept and authorize item, UC_PM_QA_11 modify item, UC_PM_SM_02 edit item, UC_PM_SM_03 submit item.

Actors[edit]

  • System

Pre-Conditions[edit]

  • One item is selected.
  • One validation point is selected.

Flow of Events[edit]

  • 1. [Not R3] The system identifies possible duplicate items.
  • 2. The system checks the data of the last version of the item for missing values for obligatory metadata and further constraints defined for the selected validation point.
  • 3. The system generates an overview of the data of the last version of the item, the possible duplicate items and the check results.
  • 4. [Not R3] Include use case UC_PM_SM_10 handle duplicate items.
  • 5. Use case ends successfully.

Post-Conditions / Results[edit]

  • None

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_09_validate_item

UC_PM_SM_11 create new revision of item[edit]

The user creates a new revision of the item. This action creates a new item and a relation of type "IsRevisionOf" from the new item to the selected item.

Status/Schedule[edit]

  • Status: in specification
  • Schedule:R3

Triggers[edit]

  • The user wants to create an intellectually revised item.

Actors[edit]

  • Depositor

Pre-Conditions[edit]

  • One item is selected.
One item version is selected?--Natasa 15:50, 21 December 2007 (CET)
See comment above --Inga 21:05, 1 January 2008 (CET)
  • At least one item version is in state "released".

Flow of Events[edit]

  • 1. The user chooses to create a new revision for the selected item.
  • 2. The systems checks for existing items with a relation of type "isRevisionOf" to the selected item.
    • a. At least one item with relation of type "isRevisionOf" to the selected item exists. The system displays the list of these item(s).
    • b. No item with relation of type "isRevisionOf" to the selected item exists.
  • 3. The system prompts for a description of the relation and confirmation of the new revision.
  • 4. (optionally) The user enters a description for the relation.
  • 5. The user confirms the new revision.
  • 6. The system displays a list of all collections for which the user has the privileges as Depositor.
  • 7. (optionally) The user chooses to view the collection description.
    • 7.1. The system displays the collection description.
  • 8. The user selects a collection as target collection and confirms the choice.
  • 9. The system checks if the genre of the selected item is an allowed genre in the target collection.
    • a. The genre is an allowed genre in the target collcetion. Procceed with step 10.
    • b. The genre is not an allowed genre in the taget collection. The system displays a warning message saying, that the genre is not an allowed genre in the target collection and that if he does not change the genre, he will not be able to submit.
My proposal and the most straightforward solution imho would be: do not inherit the genre in this case at all, do not do anything else i.e. no system message displayed and no automated addition of new genre--Natasa 11:15, 21 December 2007 (CET)

[Comment Nicole:] This is dependant on if we will have genre specific MD or not in the future. If we have genre specific MD the step should stay as it is now. Ulla, Inga, what do you think? --Nicole 11:31, 8 January 2008 (CET)

  • 10. The system creates a new item with the user as the owner in the target collection. The item version is in state "pending" and has a relation of type "isRevisionOf" to the selected item. The default values for attributes and metadata values are inherited from the metadata set and the target collection settings. Collection settings overwrite values inherited from the metadata set. Following metadata values are prefilled from the selected item:
  • Genre
  • Creator
  • Title
  • Language
  • AlternativeTitle
  • Subject
  • 11. Continue with use case UC_PM_SM_02 edit item with the new item as selected item and the validation point "submit" as selected validation point. The use case ends successfully.

[Start-GUI-QA]

A message would be good: You have successfully created a new revision in state pending. Rupert 08:29, 30 December 2007 (CET)

Please note that the new revision is not permanently stored before the user saves it at the end of the edit UC.
Until now, we haven't considered many intermediate information in the UCs, e.g. information like "You have successfully created a new item" or "You have successfully executed a search
are missing. Anyway, it is fine for me if additional instructions are considered while GUI design. --Inga 21:14, 1 January 2008 (CET)

[Comment Nicole:] Rupert, please check Inga's comment and remove the GUI-QA comments if you agree with Inga. --Nicole 11:31, 8 January 2008 (CET)

[End-GUI-QA]

Alternative[edit]

  • 6a If the user has Depositor rights for only one collection, the collection selection is automatically performed by the system.
    • 1. Continue with Flow of Events step 9.
  • 6b If the user has in his/her private preferences defined a target collection the system automatically selects the collection.
    • 1. Continue with Flow of Events step 9.

Post-Conditions / Results[edit]

  • A new item with the user as owner and a relation of type "isRevisionOf" to the selected item have been created.

Discussion[edit]

Talk:PubMan_Func_Spec_Submission#UC_PM_SM_11_create_new_revision_of_item

Additional Information[edit]

Submission activities[edit]

https://zim01.gwdg.de/repos/smc/tags/public/PubMan/Submission_activities.gif

Figure: Graphical representation of the submission activities in PubMan

Creating organizations in Metadata[edit]

To provide information for the metadata element "Organization" the user has to select an organizational unit from the organizational unit structure. In this case for every path of the selected organizational unit in the organizational unit structure (an organizational unit can have more than one parent organizational unit) a metadata value "Organization" is created by the system. If only one "Organization" is allowed, only one metadata value "Organization" is created for the path taken by the user to select the organizational unit. The "Name" value is derived from the organizational unit path, the "Address" value is copied from the selected organizational unit. Additionally a link to the selected organizational unit is created by copying the organizational unit id. Afterwards the user can edit the name and the address of the organization or delete a complete organization. The modified values are stored in the metadata set, the data in the organizational unit structure is unaffected.

File attributes[edit]

  • Id: A unique identifier of the file within the system. Has to be given at creation time.
  • Name: The name of the file including the extension.
  • Visibility: The visibility of the file for users of the system.
    • Valid values:
      • Public
      • Organizational unit
      • Private
  • Description: A short description of the file.
  • PID: The persistent identifier of the file if the item is released.
    • Handle Prefix + Item Id + File Id
  • Content: The data of the file.
  • Type: The type of the file.
    • Valid values:
      • any full text
      • pre-print
      • post-print
      • publisher version
      • abstract
      • table of contents
      • supplementary material
      • copyright transfer agreement
      • correspondence
  • Size: The size of the file in Bytes.
    • Has to be zero if no content is given.
  • Locator: The location from which the data of the file has to be fetched.
    • If the data could not be fetched it has to be retried in reasonable intervals.
  • MIME-Type: The MIME-type of this format.
  • usage statement: copyright license/statement

HTML Prototype[edit]

Prototype for Submission