Aw: 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
> > task.
>
> 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. :-)
And somehow have added answers to all your other questions into this one :)
> > > 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.
You mean why a (working) catalog is needed? It provides an overview on
what is available vs what needs to be implemented to match ones own needs.
Our task pages address the very same thing. And we should indeed compete
with our Copenhagen colleages are coming up with. The ELIXIR effort however
is also references web services, so there are differences beyond the ontology.
Frankly speaking - once Google learns about the ontology and how to integrate
it in their search logics, I presume to become very competitive with
the task pages once these show the EDAM IDs in some reasonable way.
> > > 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:
>
> bio-alignment
> bio-analysis
> bio-annotation
> bio-classification
> ...
> to match the "Operation" category of Edam[1] or also possibly
>
> bio-data-resources
> bio-nucleic
> bio-protein
> bio-sequencing
> bio-structure
> bio-phylogenetics
> ...
>
> the Edam topics[2] (since tasks and topics might be the best match).
Very reasonable. I cannot tell which would be more appropiate.
> 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.
Liking it.
The assignment for the blend metapackages is a static one, but would
you fancy task pages that allow for two different views on the same
packages - one for topics and (upon press of some magic button) the
switch to an operation-based view?
@Kristoffer,Jon,Hervé,Matus et al. - our website adopting your ontology
based approach please consider to interpret as an early success for
your dissemination work.
Best,
Steffen
> [1] http://edamontology.org/page#Operation
> [2] http://edamontology.org/page#Topic
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20150204202417.GA22377@an3as.eu">https://lists.debian.org/[🔎] 20150204202417.GA22377@an3as.eu
>
>
Reply to: