AWOB Task 038

MPDL,GAVO

General Information
Grouping: AWOB project ePublication

Short description:

Links

 * mockup in ppt: https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/update_epublication_r09.pptx

Discussion from the f2f meeting on Jun 14, 2013
A. Need an informal way of sharing information among consortium/WG members B. Similarly, on project C. For project's ePublication D. Project's overview E. Change the label of what's new to 'Progress'. F. Other possible features: G. TODOs
 * Add WIKI in addition to Overview
 * option to add child pages.
 * make option for draft available
 * generate table of content
 * Roles vs Privileges
 * View page: lead, manager, project manager, member
 * Add page: lead, manager, project manager
 * Edit page: lead, manager, project manager
 * Delete page: lead, manager
 * In Overview
 * Make 'Announcement' or 'News' available.
 * change current ePublication to WIKI.
 * option to add child pages.
 * draft available
 * generate table of content
 * Roles vs Privileges
 * View page: lead, manager, member
 * Add page: lead, manager, member
 * Edit page: lead, manager, member
 * Delete page: lead, Manager
 * Each project may have 0...N ePublication(s)
 * Each ePublication consists of
 * WIKI, eResources, Tables, Figures with Annotations, Publication,
 * eResources: somehow move or link project resources to ePub
 * Use 'Category' to specify visibility of ePublication.
 * Project, WG, Consortium, AWOB users, World
 * In the future, possibly to become public(to world)
 * Announcement
 * Whiteboard(brainstorming anyone can contribute),
 * ONline meeting
 * some designated area for consortium guideline(or policy)-disclaimer: link to guideline
 * some designated area for consortium guideline(or policy)-disclaimer: link to guideline
 * JK:Contact Andrea (show ax4 for his feedback good enough to use for eRosita): Inform NB to go ahead and update site template in prod
 * JK: Ask AWOB users : anyone uses ePublication? Its label will change to 'WIKI', new ePub with better feature available soon.
 * JK: With Rob create a test project in qa so that NB can try it out ePublication
 * NB: Sandbox: Read only example consortia. While approving account, add new user to sandbox consortia
 * GL: Will organize a meeting with researchers on GUI topics ; Rupert would present the GUI methods and clarify with researchers how to send us feedback and what is important in order to improve AWOB user interface

Discussion from the f2f meeting on Apr 29, 2013
A. What is ePublication('ePub ')
 * Online presentation of the outcome of a project. In general the outcome is mostly a paper or papers(published in a journal). But it is not necessary for the project outcome to be paper(s) in order to present in ePub.
 * Assume that there may or may not be a underlying paper for all ePubs. There could be only ePub.
 * Gather all materials to share with selected group of people.
 * if members of a consortium created a project to producte a publication, ePub of the project will be linked from the publication once listed in consortium publication archive
 * publishing the outcome in ePub is NOT the same as publishing a paper in online journal.
 * No obligation from the editors of the ePub to maintain the ePub site rigorously.
 * Per project there could be more than one ePub.

B. ePub components
 * Metadata: ePub has the same metadata as a publication in publication archive model.
 * WIKI
 * NO attachment supported
 * Designated folders: Decide which designated folders are to be supported in the initial implementation.([JK] talk to scientists)
 * References: May not be necessary in particular in the initial release
 * Useful if automatically extract references from the uploaded paper in the long run.
 * Data
 * Proxy kind of link to data: in order to make selected data available in ePub, instead of making copies of those from the awob resources or an external system(later releases) to the ePub data folder, use links to the underlying data files (eg., like bookmark, proxy)
 * Permission: the data of a project are usually available to the project members only. In order for people who is not a member of the project to be able to access the data published in ePub, give them a read only access to the bookmarks/proxies to the selected data
 * Single type of permission: Read-only for all resources in ePub to everyone except the editors of ePub
 * Active vs Passive ?
 * Authentication protocol: public user uses owner's authentication
 * If for some reason the published files need to be withdrawn, the editors or whoever can always remove the bookmarks to them.
 * For R0.9 consider the files uploaded in the awob only
 * Figures: see ppt
 * Tables: see ppt
 * Editors
 * [JK] who can assign editors? assume that Project lead.
 * Need to identify chief editor
 * all project members other than the editors of an ePub have only read access to the ePub
 * Internal

C. Versioning of ePub
 * From user's perspective there is no need for versioning of bookmarks or ePub.
 * The system may or may not keep versions as needed under the cover.

D. Visibility
 * options
 * members of project
 * (working) group if relevant
 * consortium if relevant
 * AWOB registered users
 * world
 * who can change visibility? chief editor or project lead?

Publishing results of Simulations working group to consortium members

 * 1) There are several simulations done by the "Simulations" working group of eROSITA, and the main results should be available to all consortium members.
 * 2) In general no separate publication is written, but there is a wiki page with a table summarising the results. For each simulation the table contains a row containing a link to a separate wiki page, short description of content, known caveats, last update, and contacts. The wiki page corresponding to an individual simulation contains free text, some tables, figures, links to data files,  links to other pages.
 * 3) In AWOB, a Project is created in the Simulations Working Group for each simulation. This is similar to table of simulations. Each project invites contacts.
 * 4) In order to share results from Project do following:
 * 5) To write and share summary and manual either:
 * 6) Use ePublication's "web content editor" to enter free text, tables, images. Add child pages as desired. Make these pages visible to all consortium members.
 * 7) Have web content pages under working group and consortium where this kind of general content can go.
 * 8) To share files, similarly either
 * 9) Create a folder in the Project which can be made visible (together with its contents) to all consortium members and can be linked to from the ePublication text, put content here.
 * 10) upload files in consortium resources and provide shortcuts to the resources from project ePublication
 * 11) case 4-1-1 and 4-2-1  are  likely most flexible.

Making extra figures public which are not included in a paper accepted in a journal

 * 1) 	A paper is submitted to a journal. The paper includes a number of figures. But there are more figures that the author wishes to publish together with the paper.
 * 2) 	The author uploads the figure files and paper in project ePublication.
 * 3) 	The author waits for his/her paper being accepted by the journal.
 * 4) 	Once the paper is accepted the author makes ePublication public.

Implementation
Here a proposal on redesign of the ePublication in AWOB, along with some implementation proposals.


 * Original scenarios
 * https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/pm17_make_epublication.docx
 * https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/update_epublication_r09.pptx


 * Simplified scenarios
 * https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/pm17_make_epublication_(simplified)r09.docx
 * https://subversion.mpdl.mpg.de/repos/awob/documentation/colab/usecases/update_epublication_(simplified)r09.pptx


 * Short description of current scenarios:
 * The ePublication is considered as a sub-component of a project (similar like Task is a sub-component of a project).
 * The ePublication can be "managed" or "accessed" by members in various roles on project level
 * The ePublication has its own "members" i.e. Editors and Authors (which must be at least members of the project where ePublication is created)
 * if the project where ePublication is created is a consortium or a group project (whereas a group belongs to a consortium) some group/consortium roles can also access/do something with the ePublication

Change proposal
Current scenarios can be implemented within current AWOB with high efforts. The ePublication is currently designed as a "component member" within a hierarchy of at least one level (Project). The number of parent levels in the Project (i.e. group, consortium) depends on the project. However, depending on this, the publication has to respect some privileges and access rights throughout a hierarchy. This will produce high efforts in initial implementation, however as well in further maintenance and change-requests.

The proposal below starts from the following basics:
 * an ePublication is a standalone concept (just like a Project)
 * an ePublication can be "related" to any "project", "group", "consortium" or if needed "task" but not in a hierarchical manner.
 * the role which a user has on the project or on a group or on a consortium - does not affect the rights which this user will have on the ePublication
 * the rules about which consortium/group/project roles will be granted with some rights on the ePublication via special ePublication roles can be implemented
 * notifications, rights to modify, rights to add new authors etc. on an ePublication can only be sent/assigned/applied to/by the ePublication members (with particular roles).
 * to illustrate: AWOB will not read if a notification needs to be sent to a consortium manager in case when an ePublication belongs to a consortium Project, rather it will send notifications to the ePublication role named e.g. "ePublication_Informed". Principally, any user can be associated with this role. The ePublication administrators(leads) will thus have full control over ePublication visibility and access.
 * An ePublication usually makes no sense if it is not self-contained. Therefore, this implementation proposal suggests to have a "self" contained concept, which can be related to other concepts such as project, task, group or consortia in AWOB, but is not dependent on these concepts and their implementation.