Re: Lets talk about debian/upstream/edam (Was: r18733 - in trunk/packages/bowtie/tags: . 1.1.1-2/debian 1.1.1-2/debian/upstream)
Hi,
On Wed, Feb 04, 2015 at 10:23:06AM +0100, "Steffen Möller" wrote:
> > Either this or discussing it right on the mailing list. IMHO it is the
> > right forum.
>
> That is much appreciated. It is not that the Debian Med community was
> left uninformed before, e.g. there was a report of Tim and mine while
> still in Copenhagen, and we had a report from the 2014 Stonehaven Sprint
> on it, if I am not erroneous. We just did not yet initiate any joint
> annotation spree that would yield many debian/upstream/edam files,
> yet.
To make it clear: In principle I really like the effort and also the
place where to put the edam files. It just should be documented at some
place - most preferably before those files are showing up. ;-)
> It is just all still work in progress and the EDAM ontology will need
> to develop along our annotations and, which makes the involvement of
> Debian so tantalising, to match all our diverse domain knowledge.
> Those emerging EDAM annotations in my mind pave an acceptance of a
> community-run Linux distribution as a regular means to share scientific
> infrastructure, so I am really excited about this development.
Same for me and I'd happily support this.
> > The different sources of information are just parsed and assembled in
> > UDD. Any additional parsing is IMHO duplicated work and error prone.
>
> You have more of an overview on what the UDD can do, so just guide us,
> please.
Before I can sensibly guide you I need the information what exactly you
are seeking for. From my perspective all information that is displayed
at the tasks pages (or at least a subset of it) is relevant
metainformation. Can you please confirm this. Can you make a list of
what fields you need? If so I'd be happy to create a simple table
valued function that throwas out all you need.
> From what I have grasped so far, we should not attempt to bring
> the EDAM annotation into the UDD since any ontological description of
> Debian packages should be agnostic to the ontology used.
Well, you can bring into UDD whatever metainformation about packages
might exist - so there is no rule that says: No EDAM information in UDD.
However, before I really know where such information can be gathered it
is hard to tell whether it can be reaslised nor whether it is sensible.
> I am exceptionally
> happy about the debian/upstream/[packagename.]edam solution so far and
> would leave any integration of that information in a database to the
> ELIXIR effort. That said, I am also completely for a normalised effort
> and there should be no redundancy between debian/upstream/metadata and
> debian/upstream/edam. Any parsing code for debian/upstream/metadata that
> was created for the UDD
I'm not sure whether I'm misinterpreting your statement but to prevent
some misunderstandig: debian/upstream/metadata was *not* created to
feed UDD with data. Its rather the other way around:
debian/upstream/metadata contained some data which were useful in some
UDD applications and this a (incomplete since not all information is
read until now) gatherer was written.
BTW, I'd be fine to put also EDAM information rith into
debian/upstream/metadata. The question is simply: How do you want to
actually *use* the information in those files. How should an
application that makes use of debian/upstream/edam look like?
> may possibly be shared with the code needed to
> fill the ELIXIR catalog - I would just prefer working with the files in
> the repository more. The parsing of the edam YAML file is, thanks to
> Hervé, a non-issue.
Well, parsing YAML is surely no issue. Are you talking about
trunk/community/edam/registry-tool.py ? I understand the README.txt
there as if it reads debian/upstream/edam YAML files and pushes its
content into the ELIXIR registry[1]. But how are debian/upstream/edam
files in Debian maintained. Is this something the maintainer of the
package should care about or is this some information you can fetch from
somewhere?
BTW, Regarding our internal DebTags onthology: I would *really*
appreciate if there would be an highly as possible match between EDAM
and DebTags. The DebTags inside Debian are as good as the team that is
using tham cares about. I need to admit that we did not cared about it
for years. The rudimentary set of existing tags does not really fit the
needs and the tags for the packages are basically not maintained. IMHO
it is an *urgent* need that somebody will care and defines a proper set
of Tags. This would enable us to to debtags (and thus edam if debtags
are compliant with edam) based installs. Please always remember Debian
is as good as *we* make it. Do not assume that the set of DebTags is
given and can not be changed. Its simply not (properly) maintained and
to make real use of the edam effort we should definitely also touch this
field.
Kind regards
Andreas.
[1] https://elixir-registry.cbs.dtu.dk
--
http://fam-tille.de
Reply to: