Re: debian med packages in the ELIXIR registry
On Wed, Feb 04, 2015 at 02:22:42PM +0100, "Steffen Möller" wrote:
> > What continuosely remains unclear to me is for what purpose we gather
> > these data. The following random questions are popping up in my mind:
> > 0. Is it just fun to collect metadata?
> The EDAM to me is a simplistic language to describe what our packages
> are capable to help with. It is somewhat rewarding to prepare such a
> formal description ... but only for the first few packages. The larger
> motivation lies in using those terms to describe workflows and then
> find tools for the job - to actually chain those tools up with the
> correct command line options to process the data properly is yet another
Interesting. I added this question as "0." since I did not expected an
answer here but you gave the longest answer to this very question. :-)
> > 1. Do we just gather them to help the EDAM database get even more
> > metadata than we have (like descriptions, dependencies, etc.)?
> > That's fine but than we should provide them in the best possible
> > form *for* EDAM to be accessed (whatever this might be).
> Our subversion and git repositories, or the source packages, are
> perfectly acceptable.
I was not asking for the actual technical manifestation but for the
purpose of the data collection.
> > 2. Do we want to base installation methods on a certain set of
> > EDAM fields? (I remember times when it was possible to install
> > packages based on DebTags but I can't find this any more :-()
> Yes. That and I envision containers (VMs, Docker, Cloud instances)
> to exploit the annotation.
> > 3. Do we want to change our Debian Med task design on EDAM tags?
> The consistency across our blends is more important than any fancy
> gimmicks, I tend to think. But if it fits - I would not mind. But
> hoping for a suitable presentation of the availability of Debian packages
> for particular tasks/software at a central page like the ELIXIR catalog
> would help us more than any fiddling with our package presentation.
I actually was considering to split up the (IMHO currently way to
large) med-bio into say:
to match the "Operation" category of Edam or also possibly
the Edam topics (since tasks and topics might be the best match).
You might remember that I was seeking for a sensible split of the now
more than > 150 dependencies in med-bio for a long time and it might be
that Edam gives some good reason here.