Re: OMICtools of any use?
On Thu, 13 Dec 2018 at 08:11, Andreas Tille <andreas@fam-tille.de> wrote:
> [...]
> > Since the data is not freely available, I'm questioning if this is
> > even something time should be spent on.
>
> I noticed that you reverted a commit by Steffen Moeller in imagej adding
> an OMICtools identifyer. For the moment I do not think it is nice to
> simply remove the work of fellow DDs without a consensus how to deal
> with these data - thus I reverted that remove for the moment.
Please revert it again. I did not remove it because I'm disliking
omics. I reverted it because it's wrong. I did it the first time
during the summer:
https://salsa.debian.org/med-team/imagej/commit/415ff687c5
But it was added again. I removed it yesterday for the same reason:
https://salsa.debian.org/med-team/imagej/commit/a40be89995
In both cases I have explained on the commit message why it was wrong.
> In general I do not see any need to remove these data. We should try to
> find some consensus how to deal with this situation. Once we have this
> consensus we can simply switch of the display of the OMICtools links on
> our tasks pages (which is the only use I'm aware of) or even do not
> import it into UDD. This will effectively solve the problem you
> mentioned without wasting the work of some team mates who have spent
> hours to gather the data. Simply assume OMICtools might change their
> policy. Do you want to re-add all the data to the packaging
> information?
>
> My own position to the thing is:
>
> 1. We should talk to OMICtools people (a good chance might be the
> Debian Med sprint)
> 2. There are other kind of non-free data (we are linking to
> publications and some of these are hidden behind a pay-wall)
> However, all information we provide can be gathered without
> paying and I would consider the pure IDs as free data.
> 3. We try to build a system that is valuable for our users
> including users who are willing to pay for some service provided
> by third party.
>
Yeah, but there's still a cost of maintaining the metadata. And one
can't maintain it properly if one can't access the data to check. For
example, yesterday I couldn't check if the ID on omics was correct. I
knew it was incorrect because it was the same that I had removed
earlier in the year. But if this had happened a few months ago, when
I had to check it for the first time, the package would still be with
incorrect metadata.
Anyway, I found out that the data in the omics platform is not that
freely available. And takes time to gather that data and fill the
metadata files on debian packages. That's basically what I wanted to
pass on the first email. I'm not making a call to remove the data,
just passing on the message and people can decide if they want to
spend time on it.
David
Reply to: