Git Product home page Git Product logo

2022-2023's People

Contributors

essepuntato avatar ghasempouri1984 avatar maddagh avatar martasoricetti avatar olgagolgan avatar postitisnt avatar saravell1 avatar sebastiano-g avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

2022-2023's Issues

Updating the abstract - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, you have to update the abstract you wrote and uploaded in the GitHub repository of the course with more precise and additional information derived from the study you have conducted so far (which also includes the information collected in the DMP and the protocol).

Once finalised, the abstract must be included in the research article you have to prepare and submit it by the 28th of May, 23:59 Rome time. However, please update the abstract before writing the article and whenever you have either new or more precise information to share.

Do not hesitate to contact me in the Slack group for further doubts.

Revised version of DMP - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, you have to revise your Data Management Plan (DMP) published on Zenodo according to the reviews received by the members of the other team. The revision of the DMP must be done using an existing service, i.e. OpenAIRE Argos. Once your revision of the DMP is finalised, please deposit it in Zenodo (by adding appropriate metadata) in at least a machine-readable format (e.g. JSON) and PDF.

In addition, you must also write and publish a response letter to the reviewers, where you explain either how you have addressed their comments or the justification for not having addressed them (please remember that if the latter applies, then your justifications must be very robust). Once finalised, the response letter must be published in Zenodo, and it should explicitly link and mention (even in the metadata) the reviews received, the old version of the DMP and the revised one.

Then, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the revision of the DMP and of the response letter. The deadline to provide all this information is the 11th of May.

For further doubts, do not hesitate to contact me in the Slack group.

Creating first version of the abstract - team Playarists

Hi @open-sci/playarists,

As explained in the very first lecture, you have to provide a structured abstract presenting your work, that will be updated by you daily every time you need of course. The template to follow to prepare the abstract available from Emerald Publishing website. You have to upload the initial version of the abstract in your GitHub folder in a file named abstract.md that has been already added (empty) for your convenience.

Revised version of DMP - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, you have to revise your Data Management Plan (DMP) published on Zenodo according to the reviews received by the members of the other team. The revision of the DMP must be done using an existing service, i.e. OpenAIRE Argos. Once your revision of the DMP is finalised, please deposit it in Zenodo (by adding appropriate metadata) in at least a machine-readable format (e.g. JSON) and PDF.

In addition, you must also write and publish a response letter to the reviewers, where you explain either how you have addressed their comments or the justification for not having addressed them (please remember that if the latter applies, then your justifications must be very robust). Once finalised, the response letter must be published in Zenodo, and it should explicitly link and mention (even in the metadata) the reviews received, the old version of the DMP and the revised one.

Then, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the revision of the DMP and of the response letter. The deadline to provide all this information is the 11th of May.

For further doubts, do not hesitate to contact me in the Slack group.

Submitting the presentation - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, once finalised, the slides supporting your presentation must be uploaded on Zenodo, to get a DOI to refer to them, by the 09:00 of the 30th of May.

Once in Zenodo, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the slides. Please remind to specify, in the title slide (the very first one), all the members of the group and the related roles each member has had in the context of the project, using the CRediT – Contributor Roles Taxonomy, accompany each of the roles with a brief description of what has been done.

Do not hesitate to contact me in the Slack group for further doubts.

Revised version of the protocol - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures (practical part), you have to revise your protocol published on Protocols.io according to the reviews received by the members of the other team. Once your revision of the workflow is finalised, please publish it using the Protocols.io interface.

In addition, you must also write and publish a response letter to the reviewers, where you explain either how you have addressed their comments or the justification for not having addressed them (please remember that if the latter applies, then your justifications must be very robust). Once finalised, the response letter must be published in Zenodo, and it should explicitly link and mention (even in the metadata) the reviews received, the old version of the protocol and the revised one.

Then, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the revision of the protocol and of the response letter. The deadline to provide all this information is the 11th of May.

For further doubts, do not hesitate to contact me in the Slack group.

Reviewing the Playarists DMP - team Pika.py

Hi @open-sci/pika-py,

As anticipated in the lectures on Wednesday, two of you have to review the DMP developed by the team Playarists. The two people selected for addressing this task must work independently to write a review and publish it on Qeios to get a DOI for it. A reminder: once the review is published and a DOI is obtained, the review cannot be modified anymore.

Once both your reviews are published, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of both reviews.

If you have any more questions, please don't hesitate to contact me in the Slack group.

Adding personal notebooks - team Pika.py

Hi @open-sci/pika-py,

Please remind you (meaning: each of you) to upload the personal notebooks, as required in the previous lecture. Please remember that they should be organised like a diary, and each entry must be dated. For some suggestions about how to structure it, please refer to the following:

Schnell, S. (2015). Ten Simple Rules for a Computational Biologist’s Laboratory Notebook. PLOS Computational Biology, 11(9), e1004385. https://doi.org/10.1371/journal.pcbi.1004385

The notebooks should be made available in the directory of your group.

Creation of material.md - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, in the space dedicated to your group in the repository of the course, you have to create a material.md file where you list all the members of the group with all the roles they have had in the project (using the CRediT taxonomy as specified in the title page of your slides). The file must be prepared by the 28th of May.

In addition, in the material.md file, you also need to add a bibliographic reference in APA style for each of the items to submit. You can follow the template below to create the document (the words between angular brackets must be substituted with the correct value):

# Material - team <<name of the team>>

## Members
[<<Member 1 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 2 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 3 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 4 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...


## Material

### Data Management Plan
<<Bibliographic reference in APA style of the last version>>

Reviews of the [<<initial version of the DMP>>](<<DOI URL of the initial version of the DMP>>):
* <<Bibliographic reference in APA style of the first review>>
* <<Bibliographic reference in APA style of the second review>>

Authors' response to the reviews:
* <<Bibliographic reference in APA style of the authors' response to the reviews>>


### Protocol introducing the methodology
<<Bibliographic reference in APA style of the last version>>

Reviews of the [<<initial version of the protocol>>](<<DOI URL of the initial version of the protocol>>):
* <<Bibliographic reference in APA style of the first review>>
* <<Bibliographic reference in APA style of the second review>>

Authors' response to the reviews:
* <<Bibliographic reference in APA style of the authors' response to the reviews>>


### Software developed
<<Bibliographic reference in APA style of the last version>>


### The data gathered while running the methodology
<<Bibliographic reference in APA style of the last version>>


### Article presenting the research
<<Bibliographic reference in APA style of the last version>>


### Slides supporting the presentation
<<Bibliographic reference in APA style of the last version>>

Please remember that the last point (i.e. "Slides supporting the presentation") can be added after the workshop on the 30th of May.

If you have any more questions, please don't hesitate to contact me in the Slack group.

Adding personal notebooks - team Playarists

Hi @open-sci/playarists,

Please remind you (meaning: each of you) to upload the personal notebooks, as required in the previous lecture. Please remember that they should be organised like a diary, and each entry must be dated. For some suggestions about how to structure it, please refer to the following:

Schnell, S. (2015). Ten Simple Rules for a Computational Biologist’s Laboratory Notebook. PLOS Computational Biology, 11(9), e1004385. https://doi.org/10.1371/journal.pcbi.1004385

The notebooks should be made available in the directory of your group.

Revised version of the protocol - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures (practical part), you have to revise your protocol published on Protocols.io according to the reviews received by the members of the other team. Once your revision of the workflow is finalised, please publish it using the Protocols.io interface.

In addition, you must also write and publish a response letter to the reviewers, where you explain either how you have addressed their comments or the justification for not having addressed them (please remember that if the latter applies, then your justifications must be very robust). Once finalised, the response letter must be published in Zenodo, and it should explicitly link and mention (even in the metadata) the reviews received, the old version of the protocol and the revised one.

Then, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the revision of the protocol and of the response letter. The deadline to provide all this information is the 11th of May.

For further doubts, do not hesitate to contact me in the Slack group.

Revision of material - team Playarists

Dear @open-sci/playarists,

Please find here attached my comments on all your material. You have to address all of them and, once finalised, close this issue with a comment containing your reply to each of the points I have highlighted. There is no specific deadline to complete this task; thus, please take your time.

Please, be aware that some modifications in some documents may also affect modifications in other documents. As a final note, please remember to keep your notebooks up-to-date.

After closing this issue, please remember to update your material.md file by specifying the references to the new version of all your documents.

As usual, for further doubts, do not hesitate to contact me in the Slack channel or just comment on this issue here.

General comments from the presentation

The following comments and questions should be addressed and may also result in the modification of some of the material prepared for the project:

  • Did you have the chance to compare the US vs Europe, also in terms of the kinds of articles?

  • You said that, considering the countries of journals, the UK wins. How mega-journals (i.e. journals that handle a lot of different disciplines) may affect this result? Is that the case in your data?

  • It would be interesting to compare at least with Colavizza et al. (2022) to look at the coverage of digital humanities in OpenCitations Meta, mixing the data from that article with those you obtained.

  • How would you solve the lacking of information in ERIH-PLUS? Can you suggest a possible strategy to address it?

DMP

The document (PDF) of the DMP says "Version 0" but in the metadata, it is "Version 3". Please correct.

Why did you use the Horizon 2020 template instead of the Horizon Europe one?

Title: SSH_OA_Publications_in_OCMeta

  • 1.1.3 What are the formats of the described generated/collected data? Did you use any plain text (TXT), HTML, XML, PDF/A in your data? Did you also use JSON?

  • 2.1.1 Are you re-using the described data and how? I did not understand what you said here. Can you please rephrase?

  • 3.1.1.3 Will your metadata use standardised vocabularies? You answered yes, but before you replied, you did not use metadata. What is the true thing?

  • 3.1.1.5 Will you make the metadata available free-of-charge? Where? I did not see any RDF serialisation format anywhere, honestly.

  • 3.1.1.9 Will you provide clear version numbers for your data? You said so, but then you are not doing it (e.g. you used Version 1 etc. instead of Version 1.0.0).

  • 3.1.1.15 Will you use standardised formats for the described data? Did you also use JSON?

  • 3.1.2.3 How will the data be made available? What is the project website? Please specify it.

  • 3.1.4.4 What internationally recognised licence(s) will you use for the
    described data? But it seems that the data have been published with CC-BY...

  • 3.1.4.7 Describe the data quality assurance processes. Which formats? Which data models and standards?

Title: Data management software

Some of the points arisen below apply also here. In addition:

1.1.3 What are the formats of the described generated/collected data? "Software" is not a format.

3.1.1.22 Will you provide metadata describing the quality of the data? It is not clear how you have used it. Do you have a report about it somewhere? The link to the report should be added to the DMP.

3.1.2.3 How will the data be made available? What is "Repository of Archive"?

3.1.4.7 Describe the data quality assurance processes. You should be a bit more precise here. It is not clear how you will do it.

3.1.4.8 Will you provide any support for data reuse? Where is the link to the notebook?

# Protocol

There are a lot of references to classes and methods in Python that, while fine to use, do not help the understanding of the protocol. While excerpts of code can be used in the definition of the protocol, it is important to explain them and, in particular, all the passages. Please, update the protocol so that a reader reading it can understand how to run the experiment without looking necessarily to external material. Explain the procedures to follow, and limit the links to the code where necessary.

Software

The section "Naming convention of Datasets" in the README of the software seems lacking of some information. Can you please update it?

Data

The description of the data on Zenodo should also detail the format used for data (column names, their meaning, etc.).

Article

There are no authors specified! Please add all of them, with appropriate affiliations.

Abstract: please use the same structured abstract already developed in the paper. The Abstract section is usually not numbered.

Introduction: it should include at least the research questions, and it should also contain, at the very end, how the rest of the paper is actually structured (e.g. "The rest of the paper is structured as follows. In Section 2, ...").

Materials and Methods: Remove my name as an author of your software - you did it, not me. Cite properly the data you have reused (Meta, COCI, etc.) by creating appropriate bibliographic references for them (pointing to the right version, e.g., on Figshare). Saying "we downloaded Meta" and then adding the link to opencitations.net/meta is not correct.

Results: The figures should have a proper caption describing the graph. This should be true for all figures in the whole text.

Discussion: Please identify a subsection here where to list all the limitations properly.

Conclusions: they are missing and should also contain some sketches of future works.

References: if you use the references (I agree), please cite them properly in the text without using footnotes, but using APA style.

Revision of material - team Pika.py

Dear @open-sci/pika-py,

Please find here attached my comments on all your material. You have to address all of them and, once finalised, close this issue with a comment containing your reply to each of the points I have highlighted. There is no specific deadline to complete this task; thus, please take your time.

Please, be aware that some modifications in some documents may also affect modifications in other documents. As a final note, please remember to keep your notebooks up-to-date.

After closing this issue, please remember to update your material.md file by specifying the references to the new version of all your documents.

As usual, for further doubts, do not hesitate to contact me in the Slack channel or just comment on this issue here.

General comments from the presentation

The following comments and questions should be addressed and may also result in the modification of some of the material prepared for the project:

  • Even if ERIH-PLUS is European, is it containing also international journals? Do you think that this may have biased the results somehow? Please justify this claim.

  • Please provide a clear view of the approximate time to run the two methodologies.

  • Have you measured how many journals in Meta are not covered by ERIH and are, to some extent, described as SSH journals in some other index? Please quantify, at a general level, how many of these journals you have lost in your analysis. Please, add this aspect as a limitation of the work.

  • Why did you need two methodologies?

  • Did you observe any inconsistencies in the results returned by the methodologies?

DMP

The document (PDF) of the DMP says "Version 4" but, in the metadata, it is "Version 5". Please correct.

Why did you use the Horizon 2020 template instead of the Horizon Europe one?

## Title: Pika.py Dataset

  • Page 3: In the PDF, footnotes 1 and 2 do not point to anything (V3 and V19). A proper citation should be used. In addition, there is no citation of the ERIH-PLUS dataset.

  • 2.1.2 Where do the described data reside? Maybe, pointing to the original container of the data (Figshare DOI links, for Meta and COCI) would be more appropriate. The opencitations.net links refer just to a website.

  • 2.1.3 Which data will be re-used? It would be better here to describe which of the data you have will be reused. For instance, are you caring about the authors in Meta? Are you looking at the self-citation in COCI? What did you use really?

  • 3.1.1.2 Please provide URL/Location describing the used metadata schema. Meta is not a metadata schema. The OCDM is the data model of Meta. Are you using it? And in addition, are you using a metadata schema for your data?

  • 3.1.1.9 Will you provide clear version numbers for your data? You said so, but then you are not doing it (e.g. you used Version 1 etc. instead of Version 1.0.0).

  • 3.1.1.13 What services will you use to provide searchable metadata? And how? Can you elaborate a bit more?

  • 3.1.2.4 Please provide URL/Name of used data repositories. Isn't the repository Zenodo? Why you did specify the Pika.py Code?

  • 3.1.2.5 Is the storage sufficiently secure for the data and does the storage
    provide backup and recovery procedures? are you sure about what you specified here?

  • 3.1.4.4 What internationally recognised licence(s) will you use for the
    described data? The dataset is not released in ISC.

  • 3.1.4.5 Do you have documented procedures for quality assurance of the
    described data? Semantic versioning is not a process for keeping quality assurance.

Title: Pika.py software

Some of the points arisen below apply also here. In addition:

  • 3.1.1.16 Provide information about used standardised formats. Why is CSV mentioned even if it is software?

# Protocol

Nothing to add; well done.

Software

The README.md does not contain an appropriate introduction on how I can pass the input to the software itself. For instance, I want to run your software again with more updated sources. How can I do it? Where do I have to put them? This must be clear reading the README.

Finally, the item on Zenodo describing the software is not linked via GitHub. You did not use the GitHub+Zenodo approach for uploading it on GitHub, as introduced during the lectures. This would guarantee that a new version of the software will also be assigned with version DOIs and automatically linked with the GitHub repository and the previous versions uploaded on Zenodo. Please, use the appropriate method to upload the software.

Data

The description of the data on Zenodo should detail which data I do expect to see in the various directory and how these data are structured. I know that this information is probably present in the protocol, but the format used for data (column names, their meaning, etc.) should also be reported here.

Article

Abstract: please use the same structured abstract already developed in the paper.

Introduction: it should include at least the research questions, and it should also contain, at the very end, how the rest of the paper is actually structured (e.g. "The rest of the paper is structured as follows. In Section 2, ...").

Methodology: The citation to the software must be done appropriately, i.e. creating a bibliographic reference with authors, year, title, version, and then the ID. You did not cite (no bibliographic references have been specified) the actual datasets for Meta, COCI, and ERIH that you have used in your analysis.

Results: This section is pretty small and does not contain any information in tabular forms, something that is expected. Please extend its description a bit, adding more information. In addition, usually, the graphs are specified here and just briefly described. While you should discuss them (providing a possible explanation about the results) in the...

Discussion: ... that should contain a discussion of the results, not new ones. In addition, they should also contain possible limitations of your work – e.g. the fact that ERIH is not comprehensive of all the possible SSH journals, the fact that books have not been considered (and in the humanities, they may have an impact), etc.

Conclusions: they are missing and should also contain some sketches of future works.

References: if you use the references (I agree), please cite them properly in the text without using footnotes, but using APA style.

Updating the abstract - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, you have to update the abstract you wrote and uploaded in the GitHub repository of the course with more precise and additional information derived from the study you have conducted so far (which also includes the information collected in the DMP and the protocol).

Once finalised, the abstract must be included in the research article you have to prepare and submit it by the 28th of May, 23:59 Rome time. However, please update the abstract before writing the article and whenever you have either new or more precise information to share.

Do not hesitate to contact me in the Slack group for further doubts.

Creation of material.md - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, in the space dedicated to your group in the repository of the course, you have to create a material.md file where you list all the members of the group with all the roles they have had in the project (using the CRediT taxonomy as specified in the title page of your slides). The file must be prepared by the 28th of May.

In addition, in the material.md file, you also need to add a bibliographic reference in APA style for each of the items to submit. You can follow the template below to create the document (the words between angular brackets must be substituted with the correct value):

# Material - team <<name of the team>>

## Members
[<<Member 1 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 2 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 3 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...

[<<Member 4 full name>>](<<GitHub account URL>>), roles:
* <<role 1>>, <<description 1>>
* <<role 2>>, <<description 2>>
* ...


## Material

### Data Management Plan
<<Bibliographic reference in APA style of the last version>>

Reviews of the [<<initial version of the DMP>>](<<DOI URL of the initial version of the DMP>>):
* <<Bibliographic reference in APA style of the first review>>
* <<Bibliographic reference in APA style of the second review>>

Authors' response to the reviews:
* <<Bibliographic reference in APA style of the authors' response to the reviews>>


### Protocol introducing the methodology
<<Bibliographic reference in APA style of the last version>>

Reviews of the [<<initial version of the protocol>>](<<DOI URL of the initial version of the protocol>>):
* <<Bibliographic reference in APA style of the first review>>
* <<Bibliographic reference in APA style of the second review>>

Authors' response to the reviews:
* <<Bibliographic reference in APA style of the authors' response to the reviews>>


### Software developed
<<Bibliographic reference in APA style of the last version>>


### The data gathered while running the methodology
<<Bibliographic reference in APA style of the last version>>


### Article presenting the research
<<Bibliographic reference in APA style of the last version>>


### Slides supporting the presentation
<<Bibliographic reference in APA style of the last version>>

Please remember that the last point (i.e. "Slides supporting the presentation") can be added after the workshop on the 30th of May.

If you have any more questions, please don't hesitate to contact me in the Slack group.

Reviewing the Pika.py DMP - team Playarists

Hi @open-sci/playarists,

As anticipated in the lectures on Wednesday, one of you have to review the DMP developed by the team Pika.py. The person selected for addressing this task must work independently to write a review and publish it on Qeios to get a DOI for it. A reminder: once the review is published and a DOI is obtained, the review cannot be modified anymore.

Once both your reviews are published, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of both reviews.

If you have any more questions, please don't hesitate to contact me in the Slack group.

First version of the protocol - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, you have to create the first version of your workflow using Protocols.io.

The workflow should describe how you will address the research question related to your project. In particular, you
should focus on the steps to produce your output data (including explicit mentions of existing data and methods reused) and how these will be then analysed (e.g. by indicating which statistical tool or visualisation you will adopt) to answer your research question.

Once your first version of the workflow is finalised, please publish it using the Protocols.io interface. Then, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the first version of the workflow.

For further doubts, do not hesitate to contact me in the Slack group.

Reviewing the Pika.py protocol - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, two of you have to review the protocol developed by the team Pika.py. The people selected for addressing this task must work independently to write a review and must publish it on Qeios to get a DOI for it. A reminder: once the review is published and a DOI is obtained, the review cannot be modified anymore.

Once both your reviews are published, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the reviews.

If you have any more questions, please don't hesitate to contact me in the Slack group.

Writing and submitting a research article - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, you have to write a scientific article that presents your research. Please, follow the structure suggested in the slides linked above (i.e. Abstract, Introduction, Material and Methods, Result, Discussion and Conclusions, References).

Once finalised, the article should be submitted in Zenodo, adding appropriate metadata (the more, the better). The deadline for the submission is two days before the final workshop, i.e. by the 28th of May, 23:59 Rome time. Once in Zenodo, please close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the article.

Do not hesitate to contact me in the Slack group for further doubts.

First version of DMP - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, you have to create the first version of your Data Management Plan (DMP). The DMP should include at least the description of two datasets, i.e. one for the data you will gather and another for the software you will develop to analyse such data. Of course, if you think you need more than two datasets, please do not hesitate to add more.

The creation of the DMP must be done using an existing service, i.e. OpenAIRE Argos. You should use your ORCID credentials to access it. In case you do not have an ORCID, please visit the ORCID website and create a new account. In case you have some doubts about how to use the tool and what to fill in, please watch the recording of today's lecture (30 March 2022) available in Panopto.

Once your first version of the DMP is finalised, please deposit it in Zenodo (by adding appropriate metadata) in at least a machine-readable format (e.g. JSON) and PDF. Then, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the first version of the DMP.

For further doubts, do not hesitate to contact me in the Slack group.

First version of DMP - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, you have to create the first version of your Data Management Plan (DMP). The DMP should include at least the description of two datasets, i.e. one for the data you will gather and another for the software you will develop to analyse such data. Of course, if you think you need more than two datasets, please do not hesitate to add more.

The creation of the DMP must be done using an existing service, i.e. OpenAIRE Argos. You should use your ORCID credentials to access it. In case you do not have an ORCID, please visit the ORCID website and create a new account. In case you have some doubts about how to use the tool and what to fill in, please watch the recording of today's lecture (30 March 2022) available in Panopto.

Once your first version of the DMP is finalised, please deposit it in Zenodo (by adding appropriate metadata) in at least a machine-readable format (e.g. JSON) and PDF. Then, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the first version of the DMP.

For further doubts, do not hesitate to contact me in the Slack group.

First version of the protocol - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, you have to create the first version of your workflow using Protocols.io.

The workflow should describe how you will address the research question related to your project. In particular, you
should focus on the steps to produce your output data (including explicit mentions of existing data and methods reused) and how these will be then analysed (e.g. by indicating which statistical tool or visualisation you will adopt) to answer your research question.

Once your first version of the workflow is finalised, please publish it using the Protocols.io interface. Then, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the first version of the workflow.

For further doubts, do not hesitate to contact me in the Slack group.

Reviewing the Playarists protocol - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, two of you have to review the protocol developed by the team Playarists. The people selected for addressing this task must work independently to write a review and must publish it on Qeios to get a DOI for it. A reminder: once the review is published and a DOI is obtained, the review cannot be modified anymore.

Once both your reviews are published, close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the reviews.

If you have any more questions, please don't hesitate to contact me in the Slack group.

Submitting the presentation - team Playarists

Hi @open-sci/playarists,

As anticipated in one of the previous lectures, once finalised, the slides supporting your presentation must be uploaded on Zenodo, to get a DOI to refer to them, by the 09:00 of the 30th of May.

Once in Zenodo, close this issue by attaching in the comment the clickable DOI URL (https://doi.org/...) of the slides. Please remind to specify, in the title slide (the very first one), all the members of the group and the related roles each member has had in the context of the project, using the CRediT – Contributor Roles Taxonomy, accompany each of the roles with a brief description of what has been done.

Do not hesitate to contact me in the Slack group for further doubts.

Writing and submitting a research article - team Pika.py

Hi @open-sci/pika-py,

As anticipated in one of the previous lectures, you have to write a scientific article that presents your research. Please, follow the structure suggested in the slides linked above (i.e. Abstract, Introduction, Material and Methods, Result, Discussion and Conclusions, References).

Once finalised, the article should be submitted in Zenodo, adding appropriate metadata (the more, the better). The deadline for the submission is two days before the final workshop, i.e. by the 28th of May, 23:59 Rome time. Once in Zenodo, please close this issue by attaching in the comment the clickable DOI URLs (https://doi.org/...) of the article.

Do not hesitate to contact me in the Slack group for further doubts.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.