Biology on Michael’s Domain

MDPI peer review reviewed

Wed, 24 Feb 2021 00:00:00 +0000

Finally, our most recent review got published in the journal Biology. For my taste, its title is too long: Proteolytic Cleavages in the VEGF Family: Generating Diversity Among Angiogenic VEGFs, Essential for the Activation of Lymphangiogenic VEGFs . On top of this, the title contains an abbreviation: VEGF.Most publishers are in for the moneyThis is the first time we published with MDPI . Although the criticism of MDPI has not entirely gone away after its 2015 vindication from Beall’s List , the critique is now mostly centered around the accusation that MDPI is after the money and not the quality. That said, most publishers are in it for the money. Especially the stock-market listed publishers are by law forced to be in it for the money: Elsevier, John Wiley & Sons, etc. And many others such as Springer Nature are desperately trying to become also a member of the stock-market listed club. We as scientists could probably use a little bit of this attitude because we are naturally bad at making money (we can generate knowledge, but not revenues).Concerns over review qualityAdditionally, MDPI’s review process has been criticized as being not very rigorous. What was our experience? Our paper was apparently scrutinized by four reviewers and you can read the reviewers’ comments here: https://www.mdpi.com/2079-7737/10/2/167/review_report .**How did we experience the reviewers’ quality of feedback?**Three out of the four reviewers gave real feedback. Reviewer 3 could be - for all what matters - replaced by Grammarly.com or the Microsoft Word spell checker. Reviewer 2 focuses also almost entirely on style and presentation. Don’t get me wrong: Good style and presentation are very important! But, first of all, let’s get the science right! The remaining two reviewers were apparently not extremely familiar with the research topic vascular biology. This agrees with my own experience, that I often get requests from MPDI journals to review papers outside or only tangential to my area of expertise (which I immediately reject since I anyway have too many papers to review).You could argue in favor of MDPI, that our manuscript was already quite good when we first submitted it. But please: we cobbled this together in a hurry during the month of December and I know that there are still quite a few errors (which we realized a few minutes after the paper was published).We wanted to try an Open Review, but failedIt strikes me that we had opted for open review (i.e. only to use reviewers that were agreeing to publish their identity together with their reviews). However, none of our reviewers revealed their identity. There is probably some fine print somewhere that says that the editor can override this choice when no reviewers are found that agree to give up their anonymity. To a certain extent, I can feel the editor’s pain. It is difficult enough to find good peer reviewers in the first place, because - despite many attempts for a change - reviewing manuscripts is not rewarded in the current scientific system. Is it fast? Imho, some of it was too fastThe review process was fast. The revisions were even faster. And the publishing was much too fast. I was terrified when I saw that we might not get a second set of proofs. The first proofs had to be modified extensively because the layout had changed the image placement. As a consequence, almost all the references needed renumbering. Moreover, during the proof generation, some parts of the figure legends got mistaken as body text. Therefore we had to shift large portions of text around during the proofing. And if you ever have used Word, you know that this is nothing to be excited about. At least, MS Word doesn’t crash anymore as it used to do in the old days. Back then, pushing the Crtl-S key combo after every minute of editing was outsourced from the brain to the spinal cord. But also this time, Word did not disappoint us by introducing unwanted formatting changes that were impossible to undo.None of us managed to have even a look at the second proofs this Monday before the paper went online, after which the link to the second proofs expired. We have lots of other things to do: prepare lectures, participate in faculty meetings, take care of students, and - last but not least - we occasionally also like to do some research. Fast publishing is not a virtue in itself. But it certainly helps to keep the expenses in check.**After the game is before the game.**And this time it’s not a review, but original research and we will choose another publisher. The experience was definitely not a catastrophe, but I can clearly see that such an over-streamlined process can go wrong once in while with less scrupulous authors. And there are many examples (see the Wikipedia entry ).For those interested, here is the link to the translation of the Norwegian article discussing the MDPI quality issue.**UPDATE (15.01.2022)*After this experience, a scientific analysis of MDPI journals was performed, looking at self-citations, citation cartels, special issues, APC charges, and review- and acceptance times: https://doi.org/10.1093/reseval/rvab020 . I only became aware of this article more than half a year after its publication. The take-home message of it is that MDPI , as well as the publisher OMICS Interntional , engage in editorial behaviours that fall under the umbrella of predatory practices. At the same time, their operation “has reached such a level of sophistication that they totally or partially comply with the formal criteria that serve to differentiate between predatory and legitimate journals”. The authors of this analysis use the term “non-evident/hidden predatory publisher”.At the same time, many legitimate and respected scientists are working on the Editorial Boards of MDPI journals. I personally know quite a few. As always, the truth is not black or white but some shade of grey. Besides, this article was published by the reputable publisher Oxford University Press , which could be interpreted as a conflict of interest. *

Preprint and Open Review

Mon, 18 Jan 2021 00:00:00 +0000

In February 2020, Henry Kwok from the University of Macau asked me whether I want to contribute to an upcoming special issue in the journal Biology*. He was guest editing this special issue on the topic of Proteases — From Basic Structure to Function to Drug Design as Targeted Therapy. The topic is exactly what we are researching at the moment: whether we can target the lymphangiogenic growth factor VEGF-C via its activating proteases. So I tentatively agreed to contribute a review on the activation of VEGFs. We decided for the first time to simultaneously make the manuscript available as a preprint AND to ask for open review. Open review means that the reviewers’ comments and our rebuttal will be published together with the article if the article is accepted.

OpenBIS for Dummies

Tue, 06 Sep 2016 00:00:00 +0000

If you have considered moving from paper to electronic lab notebooks as we are at the moment, you might have come across the OpenBIS solution. You want to install OpenBIS, but have not clue how to go about it? I didn’t have much of a clue either and therefore tried repeatedly until I succeeded. Luckily, I got some help from the ETHZ OpenBIS and our local computing support team, but obviously they cannot compensate for the lack of insight into Jetty and postgresql…If you just quickly want to try it, it might be easier to download the VirtualBox image, where everything is preinstalled and preconfigured ( https://wiki-bsse.ethz.ch/display/bis/openBIS+ELN-LIMS+Virtual+Machine ). However, I didn’t have any fast hardware to run the VirtualBox image and concluded that it would be fast enough on bare metal using an old computer.The notes below are written from memory and from the final configuration files that worked. However, I will still setup the server from scratch executing only what I have been writing down below in order to make sure I have not missed anything important. However, in the meantime I want to get this information out. I would have been happy if I had found some “OpenBIS installation for Dummies” instructions. In order to have a very long support, I chose for the installation Ubuntu 16.04 Server (the VirtualBox image uses Ubuntu 14.04 Desktop) and the latest version of OpenBIS 16.05.1 (you need to apply for an account to be able to download the software). The electronic lab notebook (ELN) plugin comes bundled with that release. Doing that, you have a problem with Java 7 support (it is not going to maintained for long and I will try to run OpenBIS ELN with Java 8 soon, but this walk-through uses a Java 7 PPA for Ubuntu 16.04).1. Do a fresh install of Ubuntu 16.04.1 Server. Create during the install the admin user “openbis”. When it asks for software selection, choose OpenSSH and Postgresql in addition to standard system utilities. Upon first login (as openbis user), update and upgrade all the software to the latest version and install emacs (or whatever text editor you prefer) and unzip:sudo apt install unzip emacs24-nox2. Install Java 7. Thi sis just one way how to do it:sudo add-apt-repository ppa:openjdk-r/ppa sudo apt-get updatesudo apt-get install openjdk-7-jre-headless3. To setup postgresql correctly, change the configuration file /etc/postgres/9.5/main/pg_hba.conf. All lines ending in peer, the peer should be changed into trust! After that, reload postrgresql:sudo systemctl reload postgreql4. If you are installing to a virtual machine like virtualbox, it would make sense to install the guest utilities as this will make you life easier (virtualbox-guest-utils). Make a shared (permanent, automout folder) and add openbis to the vboxsf group:sudo usermod -a -G vboxsf openbis4. Place the compressed openBIS installer file into the home directory of the openbis user.5. Untar/gzip the installer:tar -xvzf openBIS-installation-standard-technologies-S233.0-r36799.tar.gz6. Change into the uncompressed directory:cd openBIS-installation-standard-technologies-S233.0-r367997. Change the following things in the console.properties file:INSTALL_PATH=/home/openbis/DSS_ROOT_DIR=/home/openbis/dataELN-LIMS = truePATHINFO_DB_ENABLED = trueINSTALLATION_TYPE = serverFor this try I have not changed the password of the keystore, but you should do it for security reasons if you use the server for production!8. Run the installer (not as root, but as openbis user):./run-console.sh9. When the installer asks to enter the password for the openBIS ‘admin’ user, type in the password you want to use when logging in as admin into the web interface.10. When installation is done, go to ~/openbis/servers/openBIS-server/jetty/etc and edit the file service.properties. You actually have not to edit anything for the installation to work, but we needed to configure the system for login authentication via Ldap.authentication-service = file-authentication-service => authentication-service = file-ldap-authentication-serviceIf you use ldap alone (i.e. authentication-service = ldap-authentication-service), you need to have some special users in the ldap directory. We are authenticating via our university’s ldap serer only regular users of the system and hence, e.g. the admin user needs to be authenticated locally. This admin user is setup during the install, but you need to have both file and ldap authentication active for this to work. This is our ldap server address as specified in the service.properties file. It contains the authentication base, which you need to ask from your sysadmins:ldap.server.url = ldap://ldap2015.it.helsinki.fi/OU=people,DC=helsinki,DC=fiThis is the ldap user and his password on the ldap server (don’t ask me why the ldap people use such complicated word monster for such a simple concept):ldap.security.principal.distinguished.name = OU=openbis,OU=login,DC=helsinki,DC=fi``ldap.security.principal.password = PASSWORDThe following paramters are specific to our ldap server. We use OpenLDAP and since OpenBIS seems not to support TLS, we use ssl:ldap.security.protocol = ssl``ldap.security.authentication-method = simple``ldap.queryTemplate = (&(%s))OpenBIS requires https. You can either leave the self-signed certificate (provided by the ETHZ) or install an own certificate. If you keep the self-signed certificate, all users will get a warning when they try to log into the web service. There seems to be an additional problem as the uploading of files seems not to work with the self-signed certificate since the https request via port 8444 doesn’t result in an intercept that is presented in the browser window to users to override.Hence we had no choice but to get a real certificate, which is luckily easier today than still one year ago due to the letsencrypt folks. Nevertheless, getting the certificate stuff right took us some time. We are operating the OpenBIS server inside the University network and it is not visible from the outside. Users who want to access it from outside need to use a VPN.Therefore we had to install a temporary “fake” server with the same name on a publicly reachable IP and generate a letsencrypt certificate (letsencrypt is not yet automated for jetty). I used the automated method for apache2 on my own server at Digital Ocean and then retrieved the two important files (fullchain1.pem and privkey1.pem) from the /etc/letsencrypt/archive/eln.jeltsch.org directory and moved them over to our OpenBIS server. To convert them into the correct format for the java keystore, I used the following commands:openssl pkcs12 -export -out keystore.pkcs12 -in fullchain1.pem -inkey privkey1.pemkeytool -importkeystore -srckeystore keystore.pkcs12 -srcstoretype PKCS12 -destkeystore keystore.jksThe first command asks for an export password. It doesn’t matter what you use (I used 12345678). The second command asks for a destination keystore password. Enter here “changeit” if you have not changed the default keystore password (“changeit”) during the setup. Then it also asks you for the source keystore password (which is the 12345678 that I just used above).Then you still have to add the contents of this keystore to the already exisiting keystore. There are probably many ways to do this, but I used a graphical tool called Keystore Explorer . You simply open both keystores (you need the “changeit” password for this), you delete the existing entry for ETHZ and add the only (letsencrypt) entry from the newly generated keystore. Replace the files “keystore” and “openBIS.keystore” in the directory ~/openbis/servers/openBIS-server/jetty/etc/ with the modified keystore. Both files are identical, I don’t know atm the relevance of this duplication. You also have to replace ~/openbis/servers/datastore_server/etc/openBIS.keystore with the new version of the keystore. For some reason, uploading did not work and in order to enable uploading, the service.properties of the datastore server needs to specify the host-address of the datastore server:https://eln needs => https://eln.jeltsch.org. Since we used a different host for the certificate generation, there was a host name mismatch and we had to override manually the hostname settings:Change it in the files /etc/hostname and /etc/hosts, then reboot. However, the installer took only the first part of the full name for the service.properties files of the datastore server. Our server’s name is eln.jeltsch.org and it resulted in https://eln, which did not resolve in our network, since we got the letsencrypt certificate signed on another server. After we changed the service.properties files and after rebooting we were finally ready to test the server:11. Starting the server: Log into the server as openbis user.cd ~/openbis/bin/./allup.sh12. On another computer, navigate in your web browser to “ https://eln.jeltsch.org:8443/openbis/webapp/eln-lims" . If you have not installed a publicly trusted certificate, the browser will now warn you that the connection is not secure. Just click “Advanced” and confirm the security exception. You need to login as admin/PASSWORD (which you specified during the install).There are some tutorials on how to use the ELN. However, the people in my lab told me that the UI is not very intuitive and that I need to teach them the basics. I think it might make sense to describe in a tutorial the typical setup in a typical small life science lab: what work spaces with what access rights for whom and to describe common scenarios (e.g. if some reagent lists need to be accessible by outsiders, etc.). I also have many ideas for improvements. It would be e.g nice to get more “ELN previews” for uploaded documents. At the moment, images are previewable, but e.g. PDF files not (I have not tried SVG files yet, but we use them quite a lot for image annotation). This certainly is not my last post about OpenBIS and until we take it into production use (likely beginning of next year) I still have to learn much.