Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOIs #16

Closed
alexgarciac opened this issue May 20, 2018 · 5 comments
Closed

DOIs #16

alexgarciac opened this issue May 20, 2018 · 5 comments

Comments

@alexgarciac
Copy link

Please add DOIs to the references where applicable. For instance,
https://doi.org/10.1186/s12859-015-0456-9 for https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-015-0456-9 in your bib file this is with no DOI, see below.

@Article{hoehndorf2015aber,
title={Aber-OWL: a framework for ontology-based data access in biology},
author={Hoehndorf, Robert and Slater, Luke and Schofield, Paul N and Gkoutos, Georgios V},
journal={BMC bioinformatics},
volume={16},
number={1},
pages={26},
year={2015},
publisher={BioMed Central}
}

Same is true for other references.

@alexgarciac
Copy link
Author

There are issues with the language. Please have this paper proof read by a native speaker. there are parts in the manuscript that requiere some attention. For instance

To facilitate these suggestions, the EDAM Browser lets users access a form letting them propose changes at any point of their exploration.

You could say something like: In order to make it easy for the community to submit comments to the ontology editors, we have implemented a form that facilitates this communication.

the section "easy of community..." should be just "Facilitating community feedback" The five lines in this section need some work -less is more here.

At:
Labelling, indexing and describing a Bioinformatics resource, whether it is a software, a database, or a service is of a great help when it comes to promoting it to various user communities. As an example, the ELIXIR bio.tools (Ison et al. 2015) registry contains more than ten thousands software and service entries. In this context, the use of controlled vocabularies to describe the resources is of a paramount importance. In bio.tools, this need is addressed by the EDAM Ontology (Ison et al. 2013), which proposes a controlled vocabulary hierarchically organized around four axes which describe types of data, formats, operations and topics.

Please be more concise, remove unnecessary adjectives such as "paramount". Focus on what this onto is for and how your software is addressing some issue wrt the development process. In this case, you are i) facilitating the navigation and ii) making is easy for the community to communicate issues to the ontology developers via a simple form.

@alexgarciac
Copy link
Author

Ok. the abstract should simply present what you did. Please reorganize as problem statement, proposed solution and availability. then there should be the "A short summary describing the high-level functionality of the software". this is somewhat in your sections "availability", "info display", "performance and flexibility" and "easy....". So, the paper is disorganized. You only need to state the problem you are solving, describe the overall solution, present an example that illustrates how your solution is addressing or solving the problem that you have stated (here you present the functionality of the software, what does the software do so that it solves the problem). Just this simple.

In order to present the functionality of the software consider building a user story that brings together the problem from the perspective of the user; your software is in your own words "This browser is tailored to the needs of EDAM users that might not be ontology experts" so just build the user story from this perspective. there is also another perspective; that somewhat solved by the communication channel you are bridging between the community and the ontology developers via a form. This should also be part of the user story. Then simply state how your software is solving these stories. Use this part in order to present most, if not all, the functionalities of your software.

@alexgarciac
Copy link
Author

Please look at

Its interface is not designed to be a generic ontology navigation and edition platform, a goal already achieved by many other systems (AberOWL(Hoehndorf et al. 2015), BioPortal(Whetzel et al. 2011), OLS - Ontology Lookup Service(Jupp et al. 2015), Ontobee(Xiang et al. 2011), WebProtégé(Tudorache et al. 2013)).

I presume the "its" refers to the EDAM interface. Just use the form "the edam interface....." Please be mindful here because BioPortal is not an ontology editor, it is an ontology publication platform. You could edit the ontology by hand if you want to. By the same token, Ontobee is not an ontology editor. Just organize this part of your paper making sure that you are distinguishing a publication platform/ontology repository vs an ontology editor.

Also, WebProtégé(Tudorache et al. 2013)), why do u have )) ?

One more, leave a space between the name of the software and the parenthesis indicating the reference -please check this everywhere in the manuscript.

@alexgarciac
Copy link
Author

Please in the manuscript, as well as in the readme for the git make sure that u clearly address the following issues:

1- This one requires attention more in the manuscript than in the readme. As you state that your form is meant to support the evolution of the ontology then there is a community component. are comments going to be visible for everyone to see and keep commenting on? is this commenting feature just a form by means of which issues go straight into a git issue tracker? Below some more specifics on this point.

Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

2- This one is specific for the manuscript and also requieres that you update your bib file.

References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

3- this one is more related to the manuscript because IMHO your software development is easy to follow. However, a visit to the documentation in the actual code and overall project would not harm. In the manuscript you need to better describe the functionality of the software. the software is very simple, this is good, but it is poorly described in the paper. You may want to relate the description of the functionality to specific use cases.

Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).

4- Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution. I could not find the list of dependencies.

hmenager added a commit that referenced this issue Jun 14, 2018
hmenager added a commit that referenced this issue Jun 15, 2018
hmenager added a commit that referenced this issue Jun 18, 2018
last edits to the paper, based on the suggestions from @alexgarciac in #16
@bryan-brancotte
Copy link
Member

Closing as followed in openjournals/joss-reviews#698

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants