Hi Gildas,

When datatypes were moved to the Tool Shed, I
think the idea was to eventually have only a core
set of topic-neutral datatypes (plain text, tabular,
etc) in Galaxy itself. That does seem sensible.

I'm not quite sure why policy has returned to a
larger centralised set - but limitations of the
ToolShed like dependencies (for Python code
imported directly into Galaxy), lack of versioning
of datatypes, and better control of namespaces
are likely part of this. I missed GCC2017 sadly.

Even with a large set of datatypes included with
Galaxy, it should be easy to hide/disable lots
(e.g. for an image analysis Galaxy you would
not want any of the sequence file formats).


P.S. Good point about EDAM, its been raised
on the BLAST datatypes pull request:

On Mon, Aug 1, 2016 at 9:27 PM, Gildas Le Corguillé
<lecorgui...@sb-roscoff.fr> wrote:
> Hi all,
> If indeed, datatypes return within the Galaxy distribution, can we imagine
> propose different datatypes_conf.xml?
> Galaxy isn’t anymore dedicated to NGS purpose. It is use also for
> metabolomics, proteomics, …
> So it could be great to propose 1 "common" list of datatypes (text, tabular,
> png, pdf, …) and n specific datatypes lists for the n scientific areas to
> reduce this huge list of datatypes proposed to the users.
> Maybe this selection should be based on edam ontology. As you know they are
> almost already annotated with edam_format and edam_data
> Gildas
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to