Re: OMICtools of any use?
Hi David,
On Thu, Dec 13, 2018 at 12:15:11PM +0000, Carnë Draug wrote:
> On Thu, 13 Dec 2018 at 08:11, Andreas Tille <andreas@fam-tille.de> wrote:
> >
> > 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.
Uhmmm, sorry. I should have read the full commit message. I just have
read your e-mail here and have seen your last commit. Sorry for the
noise. I've now droped a Comment inside the YAML file (and I cross
fingers that my importer code is robust enough to not stumble about it
;-) ).
> > 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.
I agree that the maintenance burden should not be put on you and this
kind of ping-pong was definitely a nuisance. My guess why the date
re-appeared is that the workflow of Steffen was: Hmmm, there is no
OMICtools entry inside the packaging but I've found one and simply added
it without checking the history. I hope the current entry will prevent
this in future.
Thanks for your patience and your explanation
Andreas.
--
http://fam-tille.de
Reply to: