|
|
@@ -0,0 +1,53 @@
|
|
|
+30.06.2020 Sdash Call with TL, JC and HS; Wrap up:
|
|
|
+
|
|
|
+Overall aim is getting the public gallery. This includes many smaller issues we discussed:
|
|
|
+
|
|
|
+- multiple authors (which is required for public page) leaves us with a few issues:
|
|
|
+
|
|
|
+Write access for all? Can we give all co-authors access to the figure details? Is there a somebody who is not an author who can also have write access? Is this a use case? What roles do we have?
|
|
|
+There must be at least one “admin” of sorts. With flexibility to share resposibilty of ‘admin’ duties if desired much like it the case with corresponding author and authors
|
|
|
+We defined the following roles:
|
|
|
+corresponding author (CA): The person who created a figure and has all ruling rights over it. Corresponding authors can select/name other authors. Corresponding authors can make other authors into corresponding authors so that there is more than one person the corresponding author. All corresponding authors have complete read/write/delete right.
|
|
|
+
|
|
|
+author: Is named by the CA and has only read rights.
|
|
|
+
|
|
|
+non- registered author: Does not have an SDash account and is a problem for us (see below)
|
|
|
+
|
|
|
+curator/contributor also all rights like CA but is not listed as an author
|
|
|
+
|
|
|
+Problematic with authors who are not in the platform but are CA on a ‘real’ paper. By defintion non-registered authors cannot become CA! Need to think of what happens if a non-registered author is becoming a registered user? How can the new user account be linked to the figure? Who could do that? Or should we not accept any non-registered authors? We have to decide what we want with those authors. Shall we just save them in the database? maybe even create silent background accounts for those imported author names without orcid…(-TBD
|
|
|
+Problematic: when a CA adds another author to a figure, how can the CA know, that the added authors account isnt faked? (Potentially a person could sign up with a fake account…?) Should ORCID be enforced??? -TBD
|
|
|
+To keep in mind for ‘public page’: when figures go public then ALL authors need to have an account or at least need to be notified
|
|
|
+
|
|
|
+Importable list (ORCID integration?): In case of adding multiple authors what sources of author lists exist and can we use, how compatible are they? (crossref, datacite, orcid) Can we combine different options to create author lists; manual/imported list/group members/copy+paste.
|
|
|
+Minimal solution: Allow manual typing of names with auto-fill with registered users. For automation using group members as ‘author list’ and have a copy+paste or even a ‘make a template from this figure” which makes an empty mask with same metadata that has to be filled with figure content.
|
|
|
+Other automation approaches: Allow import of metadata/ author metadata from preprints. (Slightly different use case) This would be a solution forsemi-automated import of authorlists. (Again problematic with non-registered authors.)
|
|
|
+using ORCID for this: Orcid IDs could be included in the imported jats file and only those authors with ORCID are kept, because they can be matched up with our user profiles. If you dont have a orcid...pech gehabt.
|
|
|
+openminds and or yml from gin for export to datacite, zenodo; json . We could directly ping the respective DOIs from the websites APIs.
|
|
|
+ Then when importing there should be a dialogue box where you manually ‘validate’ the imported authors, (crosscheck with ORCID IDs of registered users and mark them as validated automatically) lose the non-orcid authors. (Auto suggesting author names from the registered users.)If there are authors that do not have an account, they would stay floating (same problem as above).
|
|
|
+Integration with orcid: ORCID can be used for validation of identity of authors and for creating author lists (See above). Also ORCID integration was meant for using ORCID for the registration and login which is a target in any case.
|
|
|
+
|
|
|
+
|
|
|
+Versioning: Needs to be clarified what counts as a separate version and how it is accessed and who can access it? What are the use cases??
|
|
|
+Priority of versioning not necessary very high. Dependent on DOI/PMIDs and needs more thinking
|
|
|
+
|
|
|
+DOI and license is required for ‘public page’, PMID: Crossref path ??? Has to be prapared now for the future.
|
|
|
+We should ask the developers to have a simple unique identifier. DOI would be great! but a bit complicated.
|
|
|
+Schema.org to make it properly searchable (should be easy)!! and maybe link to sourcedata curated smartfigures.
|
|
|
+Can publishing a figure be reversible??? (Yes, as long as there is no DOI...versioning will then be important as well).
|
|
|
+
|
|
|
+Other topics:
|
|
|
+Public page face: What will the face of the public page be like? What is on the open page?
|
|
|
+A) see the same things as a logged in user but only ‘public content’. B) see public groups. Are these the same groups like the internal groups we already have? Can entire groups be made public at once? -TBD
|
|
|
+Write a paper: Shared first author JC and HS and shared last TL and ML? Orlin and Steve As Co-authors. Two topics: First is to describe the platform. Second: study on how it is used and evaluate the user experience, what worked; what didnt work. The lessons learned, ‘global stats’. Third paper; How to get the distributed Sdash. Or all in one paper.
|
|
|
+Invite people via email (in group, as author: not urgent but a nice to have and will be put forward to developers by HS)
|
|
|
+API: will be exposed with all the functions necessary to build the public face. Should be a read-only API. (Write API we have to see what the limitations are also regarding authentication etc.) Lets check what can be exposed now.
|
|
|
+Public page is the priority, but then the UI re-design should be really prioritised after that: Need really good mock-ups and involve more people in the development of this. Ideally someone with experience in design good UI. Potentially have slightly different UI for logged in and public user.
|
|
|
+SFB application: Grant application deadline in June 2021 (maybe 10 pages), Paper has to come out before. Grant application for internal selection deadline in November. (2 Page document. )
|
|
|
+Engagement of a second community to get more evaluation? – for HS
|
|
|
+
|
|
|
+
|
|
|
+ToDO: Think of use cases/user story Hannah and Julien!
|
|
|
+
|
|
|
+Schedule a call with Matthew once we have ‘public page’ milestone or when we want to design the public page face.
|
|
|
+
|
