Re: What's next. Re: Please check implementation
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
Reply to: