• Wiki page for design: 
• Michael's Flow diagram: 

Definitions
Live Objects: Dataset and Collections in a Space. Anybody can change/add/modify.

Curation Object: Object being modified for publication by the curators.

Publication Object:  Curation Object + DOI (Digital Object Identifier). The returned object from the repository. 

Process
1.  Curation Area - Curator Picks some of the Live Objects and start the process of submitting that dataset or collection. 

Design Specification:

• The user should be able to identify the datasets and collections that they want to publish and create a curation object.
• There is a curation Area specific for each space. Anyone in the space can see the curation area and objects in it. 
  
  

Design Question: What is four us a curation object? 

Design Answer: It is a copy of the live object, and the updates are kept separate. The curation object is what was selected from the live object and put into the curation area as an object that the user will be working on. There is an entry in the staging area with all the information that was available when the user added it to the staging area. 

Design Question: What happens if the original dataset/collection is updated?  Do we keep track in the curation dataset to the live object? 

Design Answer: The curation Dataset/Collection has a link to the original dataset/collection. They will have the same Id, but stored in different places. 

Design Question: There will be a staging area per space. Is there also a staging area that is private?  

Design Answer: Pending

2.  Matchmaker - The user 'asks' the program what repositories will accept the curation object. 

Design Specification

• Identify what repositories are compatible with what the users wants to do. (I am interested in these things for my publication. What repositories are compatible with this requirements? )
• Clowder should save the preferences for the repositories the user wants to publish to. 
  Note
• It is unclear what the matchmaker accepts as input.
• Input to matchmaker: User Preferences + attributes of the data.

3. C3PO

Design Specification. 

• Find a way for helping the user refine what the repository needs for allowing a submission. Example: If the repository requires an abstract. Provide a way for the user to add an abstract to the dataset. Or other kind of metadata/requirements for the dataset/collections in order for the curation object to be accepted for publication. 

TO BUILD:

Sprint 1 - Curation Projects. 

• Create a staging area per space
• Create a curation object: creator, date, title, description, curator, dataset, collections, list of copies, blob, metadata, object
• Store users preferences for publication

Optional: 

• Edit Curation Object

Sprint 2 - Matchmaker Calls 

• Store user preferences for publication. (Preferences for calling the matchmaker)
• Add rules to the matchmaker that are attributes of the data. 
• Wizard Flow 
• Call Matchmaker with user preferences + attributes of the data

Sprint 3 - C3PR Calls. 

• Refine Metadata - Show suggestions to the user. About missing information that the repository needs/wants. 
  Optional 
• Create multiple plugins for submitting the code a C3PR plugin, Ideals plugin fedora plugin. 

 ------------------------------------------------------------------------------------------------------------------------------------------------------------

Sprint tasks:

1. Staging area per space [Indira]
   1. standalone plugin
2. Create curation object [Yan]
   1. Select  dataset and collections from space [Luigi]
3. Submit for publication (separate plugins?) [Rob]

1. Call matchmaker and pick repository (separate plugins?)
2. Refine metadata
3. Store user preferences for publication in profile
4. Store published object (everyone in space can see them)

1. Edit curation object
2. List curation objects and published objects that a dataset/collection are part of

1. Create curation object
2. Matchmaker query and selection
3. Editing of metadata and submission to repository

1. Who can see the curation objects?

1. curation object -> publication object
2. repositories preferences
   1. a repository says what options it provides
   2. user might have preferences set in their profiles in the spaces
      1. generally speaking I want things free
      2. but in one instance I might be willing to pay
3. attributes of the content vs attributes of the repositories
   1. "I would like"
   2. "I have images"
4. "if my dataset doesn't have license, assign creative common"
5. preference / requirements