Hi again, On 11.11.20 17:39, Hervé Ménager wrote: > I can only agree with Matus, this is a very nice and super motivating > answer, thanks a lot! > We'll investigate how all of that can be delivered in a near future > hopefully :)
My personal ambition is a substitute for our task pages. But we need the EDAM annotation for that. Let us see where our ambitions to tackle the pandemic carries us. EDAM-annotating just these packages and then presenting the worksflows with it should be an interesting excercise. > On Wed, Nov 11, 2020 at 5:28 PM Matus Kalas <[email protected] > <mailto:[email protected]>> wrote: > > > Giant thanks for your quick and enthusiastic answer! > > On 2020-11-11 16:59, Steffen Möller wrote: > > Hello Hervé, hello Matúš, > > > > On 11.11.20 16:36, Hervé Ménager wrote: > >> Hello Debian-ers, > >> We (ELIXIR Tools Platform) have been working a lot on the Tools > >> Platform lately. One of the major contributors is Debian Med, and > >> collecting the package metadata from you will soon enable: > >> - cross-linking between e.g. bio.tools and Debian Med packages > >> - cross-validation and enrichment of metadata. > > > > How cool is that! > > > > I just checked https://bio.tools/clustalo > <https://bio.tools/clustalo> and found the "software > > package" link to Debian's tracker. Great! > > > >> Speaking of which, our current setup is very convenient for us: > we can > >> update Debian metadata at any time, and use it to produce > better tool > >> descriptions. *But*, one thing which is unclear is how we can > >> contribute back some metadata to your packages. Would there be any > >> kind of interest on your side in e.g. opening Merge Requests on > salsa > >> when some metadata can use some update? If so, should our > system open > >> these MRs automatically or semi-automatically (assuming we can > define > >> precisely when a metadata difference mandates a correction on the > >> Debian side)? > > > > You personally have access to salsa.debian.org/med-team > <http://salsa.debian.org/med-team> and can go for > > anything exceptional without further delay. > > > > You can also prepare and auto-prepare (!) pull requests of whatever > > nature these may be for all packages that are on salsa. > > > > For packages in Debian Med, fixing smallish bugs, like > > adding/correcting > > the bio.tools reference I think you can just do them. > > Great! > > We could correct the bio.tools reference for those tools|packages > that > have a link to Debian's tracker, but those would expectedly have a > valid > bio.tools ID in Debian already :) Or am I wrong? > If I recall correctly then there we are few packages were we had mismatches with the cardinality. The assignment is currently to source packages, but if a tool provides multiple binaries then we may be in trouble if there are multiple bio.tools entries for that. But - go ahead. Yes. Sounds like a good start and maybe you can check for multiple assignments to the same tracker URL, first. > > > A seed for the edam annotation would be good, which then the > individual > > maintainers > > extend, by chance. > > This is an excellent idea! > Right after getting the references synced, this is very much what I would like to see going. I manually went to a few packages of the "Virus" list on that spreadsheet. Invitation to edit just went out. Could you please investigate why there is no ref for https://bio.tools/edger ? The naming scheme is r-(cran|bioc|other)-lowercasepackagename. But URLs etc should be correctly set. I just checked https://salsa.debian.org/r-pkg-team/r-bioc-edger which has the right ref to bio.tools (without me now having edited it :o) ). Hm. Maybe that is not exported in the json file? But I checked https://salsa.debian.org/blends-team/med/-/blob/master/tasks/bio and it is listed there. Do you have statistics on the number of entries compared, %matched, %links to Debian added, or whatever seems appropriate? Also, the number of lines you add from bio.tools to Debian should somehow be metered, preferably over time. I know, just the typical bloat for whatever manuscript you likely plan to write, but nonetheless nice to read :) Best, Steffen > > > I do not think I would in an automated way update > > package descriptions. And the URLs should also be checked manually. > > Even > > if you have the correct newer one, the one that is listed is > likely the > > one where the software was downloaded from and it identifies the > > sources, too. > > Hmm, good points. > > Maybe we'll have to be a bit careful about the versions of the source > pkg in Debian and those that a particular bio.tools record is > valid for > (N.B. such annotation is optional in bio.tools). Such check, where > possible, may apply to generating the edam seed, too. > > > More important in that respect is that the debian/watch > > file is updated so the maintainer is informed about the updates. > > Ok, thanks for the reminder, I see this is crucial. > > > > > As a start, I think a mere web page with lists of changes that > you want > > to feed back would be nice so we can think along. > > Indeed, I think this is the way to start, before we dive into complex > functionality. > > > > > Thank you both! > > > > Steffen (has added/updated already three bio.tools references > today :o) > > ) > > So super cool, first place medal Steffen! > > Thanks so much, > Matus >
