On 20.10.17 21:03, Andreas Tille wrote: > On Fri, Oct 20, 2017 at 06:13:10PM +0200, Steffen Möller wrote: > > ..... >>>> * 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. > I admit I did not expected that these registries are that much in flux > and I'm honestly wondering if we have **way** more software packaged > what is the real sense of those registries. I have no idea what amount > of work is needed to add a registry entry but I naively assume that in > most cases the work is less than creating a proper package. So what is > the sense of **several** registries that are very incomplete?
Er, they have more than we have packaged. Our referencing to those registries is yet incomplete. Here I would need the NAs to learn which I have visited and which not, but this is only a few clicks away in the source repository, obviously. About every 10th package of ours that is not a mere library I tend to think still lacks an entry in the registries. > >>>> 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. > You mean bio.tools should run the tasks pages query twice a day and > present that result? No. bio.tools is bio.tools and because it properly references the Debian packages we trust them enough not to look at our task pages when we look for a tool. > >> 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. > Why? If a regular (non-developer) Debian user prefers our task pages over the registries, then those registries are doing something wrong. When you want to solve a biological problem then you want to solve it. And if you are not merely reimplementing an already well-specified workflow with all tools named, then you look for the best tools out there and that includes tools that may not yet be packaged for Debian. Consequently, looking in a catalog that only features Debian-packaged tools is not sufficient. So I see a fruitful competition between: * workflow registries (with references to SciCrunch/OMICtools/bio.tools registries for tool specifications) * registries (with refeferences to Conda/Debian/BioContainers distributions for tool delivery) * distributions with readily installable software and their task pages Best, Steffen
