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