On 20.10.17 15:12, Andreas Tille wrote: > Hi, > > On Fri, Oct 20, 2017 at 02:18:13PM +0200, Matus Kalas wrote: >> This is super awesome to see Andreas & Steffen, you really made my day! > You could make my day in turn to add more of the data we need for the > packages not yet tagged. :-P
@Matúš, you may rest assured that any task entry that has any registry reference also had bio.tools checked. >> A few notes: >> >> * Would you please add a dot to Bio.Tools? Or Bio.tools, whichever you like >> more. > Fixed in Git - will need the next cron run to update the pages. I think it is all lowercase bio.tools in debian/upstream/metadata. >> * The coloured backgrounds don't work in Firefox, but that's no problem at >> all. > Strange. I'm using firefox and it works. Pretty simple CSS ... Also works over here with FireFox on MacOS. > >> * I really like the coloured backgrounds otherwise (yeah!), but even more >> transparency would look much better to me. > Just send me the html color codes you would prefer to see. Sigh. I wished we would find a solution with fewer colours, but ... fine for now. >> * The texts "Registry entries:" | "Biotools" | "RRID" | "OMICtools" are in >> italics in some browsers and regular in others. To me, the "Registry >> entries:" looks better in italics (to distinguish from the rest), and the >> registry links look much better in regular (especially when with the >> coloured backgrounds because those are rectangular). > Nice hints. The best will be probably if somebody would send me a patch > for sentinel.css. The task pages have an enormous wealth. Would be another MoM or outreachy project to find the most suitable layout for them. >> * RRID|SciCrunch: identifiers.org don't guarantee anything. If there's no >> cool permanent URL, identifiers.org don't have it either. That's exactly the >> case here. Is it? SciCrunch RRIDs and identifiers.org should be well synced. >> Unless they really have some temporary server-side problems >> exactly now. DuckDuckGo doesn't help either. (Unlike with OMICtools, there >> it works awesomely!!) The only usable link I found for RRID|SciCrunch is >> https://scicrunch.org/scicrunch/data/source/nlx_144509-1/search?q=SCR_010709 >> i.e. prefix >> "https://scicrunch.org/scicrunch/data/source/nlx_144509-1/search?q=";. >> Unfortunately I haven't found a way to get the first hit directly. And the >> RRID link is dead just like the identifiers.org link. And sorry for a dumb >> question, are there any non-SciCrunch RRIDs, or should they all have a >> record in the SciCrunch registry? The OMICtools folks refer to their IDs as RRIDs as well. https://arxiv.org/ftp/arxiv/papers/1707/1707.03659.pdf This has not yet made it into our community's biotech sprech, but, well, just by browsing through the tasks list you may get an idea why I like to avoid any confusion on that end. Anyway, I think you agree that the surfacing of those references on our task pages is a fruit of something that was seeded by bio.tools' participation in Debian Med's 2015 St Malo Sprint and has since been with us throughout all other Sprints and your Hackathons. Kind of funny that OMICtools seems to benefit the most at this stage, and they even link back to Debian, too. I rest assured that you happily compete on those two fronts. The interesting bit is now about how to continue the development. We could argue that if bio.tools and friends do it right, there is no real need for Debian to have any task page orchestrated by themselves. This will not happen since we would then not have something to experiment with under our control and these task pages are autogenerated as part of the Debian Blends concept. But at least our users should prefer the software registries over what the Debian community autogenerates. And this brings me to another issue. The categories. OMICtools does it quite right. But they also say that this is theirs. I do not know about how much you perceive your EDAM ontology to act as a catalogue, but it obviously comes to mind. Now, my personal motivation to invest into EDAM annotation is for preselecting tools for their assembly to larger workflows or to autogenerate tools that substitute others in existing workflows. That has nothing much to do with catalogues, though. It is far deeper and would take too long to complete to be any useful as a catalogue. I hence see something like an iterative approach to cover most of Debian Med with a bit of EDAM like the topic and then level down to the individual binaries that are shipping with it. @all: Hervé, Matúš and I have something like that already prepared for Bowtie https://anonscm.debian.org/cgit/debian-med/bowtie2.git/tree/debian/upstream/edam Best, Steffen
