Hi Steffen, Thanks a lot for these points. A few answers below: On Sun, Jul 26, 2020 at 3:09 PM Steffen Möller <[email protected]> wrote:
> > a) complete the mapping from Debian to bio.tools for the bioinformatics > packages on that Excel sheet (state "n" that I mention below) > sure, this is definitely one of the next steps. b) add d/u/edam files for these packages, maybe autogenerate them from > bio.tools if not already existing? We need to mention that in d/copyright. > Yes, autogenerating them from bio.tools will probably save a lot of time, even if there is a manual check for each entry. > c) see how this can be fed back to bio.tools. > Yes, the idea is to consolidate through the github repository ( https://github.com/bio-tools/content). We can set up automated (or not) processes to "cross-consolidate" debian and bio.tools metadata. Would you be available in September to discuss/work on this? Cheers, Hervé > > > > Anyway, thanks a lot for your help, I am so very happy this is now up > > and running! We should set up a plan to continue this work! > > m) I first looked on bio.tools for "blast", was unhappy with the result, > then "ncbi blast", still unhappy. > > n) Ok, then "bowtie", which is what the debian/upstream/edam effort once > started with and found https://bio.tools/bowtie2 with a reference to the > Debian package on the lower-right. It is actually the first time I ever > saw that but you likely have that for a while already and I was just > unaware of it right?https://bio.tools/clustalo also worked. Nice. > > o) Infernal is a bit broken on the bio.tools side since it only refers > to one of its executables. > > p) hmmer3 (https://bio.tools/hmmer3) does not have a ref to Debian. > > q) I then searched for "Debian" on bio.tools and found four entries. > https://bio.tools/DNCON2 hat Debian in its description. The other three > have a "DebianMed" collection tag. I was not aware of that. > > My personal ambition for bio.tools is that it substitutes most of what > the Debian Med task pages are doing at the moment. But that is just what > keeps me going, let's ignore this for now, just for the back of our minds. > > Concerning m-q - I happen to have stumbled across 5 very different > problems/challenges. Only for packages that have reached the state "n" I > think we shall proceed with edam annotation in Debian so we have a > feedback loop. What would be the right thing to do for a Debian package > maintainer / user who encounters a package in state m, o, p or q? This > is an issue on github, I presume, but maybe you could come up with a bit > more of an explicit instruction for the Debian folks how to report and > where to make it all as easy as possible for bio.tools? > > Do you have opinions on a-c? > > Best, > > Steffen > > > > n Sat, Jul 25, 2020 at 5:15 PM Steffen Möller <[email protected] > > <mailto:[email protected]>> wrote: > > > > This is great news, thank you for this, Hervé. > > > > For now I think the most important bit is to have anything that is > > automated in some reasonable way. And then let's extend that over > > time. > > This should give edam annotation a particular boost, I tend to think. > > > > You may be aware of an earlier email in which I described the Google > > Spreadsheet > > > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?usp=sharing > > < > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?usp=sharing > > > > to provide an overview on what packages (rows) are important for > which > > workflows (columns). > > > > Now imagine what EDAM could do for us along those lines. @Jon,Matúš, > > should we possibly do some bulk EDAM annotation just for the > > packages on > > this "virus" tab? I suggest several iterations, like Topics first to > > provide the summary scope and I/O+File formats second for the > > individual > > executables once we know more about it all. > > > > Best, > > > > Steffen > > > > > > On 25.07.20 16:33, Andreas Tille wrote: > > > Hi Hervé > > > > > > On Sat, Jul 25, 2020 at 12:43:08AM +0200, Hervé Ménager wrote: > > >> Hello Steffen, everyone, > > >> This is to let you know I am currently attending the BCC > > virtual hackathon ( > > >> https://bcc2020.github.io/cofest/ > > <https://bcc2020.github.io/cofest/>). With a couple of other > > people, I have > > >> been working on the Tools Platform Ecosystem ( > > >> https://github.com/bio-tools/content/ > > <https://github.com/bio-tools/content/>), continuing among other > > things the > > >> work we have been doing with you and others over the years to > > integrate > > >> metadata from Debian Med packages and bio.tools (among others). > > >> I have finalized a first working version of this work, but I > > took the > > >> liberty to modify the biotoolsConnect repository, esp. the > > script you have > > >> created Steffen, to correct a few things. I did so on github ( > > >> https://github.com/bio-tools/biotoolsConnect > > <https://github.com/bio-tools/biotoolsConnect>) but I know this is > > a mirror > > >> to a repository on Salsa. > > > I do not think there is a mirror on Salsa. I've just developed > > edam.sh > > > there as a *simple example*. I admit I'm a bit astonished that > > > edamJson2biotools.py is parsing the output of this *example* script > > > instead of using the query directly inside the Python script. > > > > > >> If you need me to do something to synchronize > > >> with this other repository, please tell me (and tell me how). > > > I think there is no need to syncronise. Its not used there. > > > > > >> Thanks a lot for your hard work on this subject. > > > You are welcome and thanks for your support > > > > > > Andreas. > > > > > >
