[Bioc-devel] RFC: Naming scheme for organism level annotation data packages
Seth Falcon wrote:
Wolfgang Huber <huber at ebi.ac.uk> writes:
Hi Seth,
sounds good to me.
One possible option I wanted to throw into the ring to solve the
identifier system problem and at the same be at least conceptually
prepared for annotations of multi-species systems (e.g. host-pathogen,
say, man/anopheles/plasmodium) would be to use name of the name of
identifier system (EG) as the prefix rather than "org".
That was something we discussed. The down sides of that are:
- What would you put for an updated version of the YEAST package?
- How would you indentify organism-level packages? [Perhaps your
point is that this may not really be all that useful so isn't
worth considering].
Since Seth et al. have produced a wonderfully useful db-based system, it
seems that these data packages could be much more flexible from an ID
point of view. One has a primary ID associated with the data package,
but mappings, to the extent that they are available, could also be
included. Then, you could have something like:
primaryKey(org.Hs.mappings)
[1] "EntrezGene"
availableKeys(org.Hs.mappings)
KeyType ExampleValue
[1] "EntrezGene" 9923
[2] "EnsemblGene" ENSG00000273213
[3] "HUGOSymbol" BRCA1
And tools for getting data:
mget(mykeys, org.Hs.mappingsSYMBOL) #expects mykeys to be EntrezGene
mget(mykeys, org.Hs.mappingsSYMBOL,keytype="EnsemblGene") #does lookup
of EnsemblGene to EntrezGene and then does the mget
# under the hood, this is a simple join in sql
Software using such annotation packages automatically becomes hugely
more powerful. Alternatively, a MAPPINGENVIRONMENT could be included
that could do the up-front mapping from one ID type to the primary key
(and back again) and then software could remain largely unchanged from
the current situation (assuming there is a single primary key).
The reasons that I like this approach are:
1) Each organism package then need be created only once and the
expectation would be that most of the appropriate mappings would be
included.
2) Standardizes mappings between ID types--individual users can rely on
a standard mapping with version information (Nothing worse than an
external mapping source "updating" halfway through a project)
3) Allows one "pipeline" for the production of the annotation and
primary keys, while allowing flexibility in the production of secondary
mappings (an arbitrary number of mappings can be added; one could even
imagine allowing users to add their own mappings quite easily to the
database with a single function)
4) Software immediately becomes more useful without much increased
complexity
5) Could be extended to have multiple primary keytypes in the same data
package with automatic key conversions.
Of course, some attention would need to be paid to documenting the
source of the alternative mappings, but the alternative mappings are
readily available. With the adoption of a sql backend for these
packages, all of this becomes doable with the adoption of a single table
(or two, if one includes the "availableKey" information in a separate
table--a good idea, in my opinion) and some infrastructure for doing the
lookups (API level infrastructure, since the backend is a simple join).
All of this said, I am not so intimately involved to know how much work
this would actually entail, but I think since we are talking about
making changes, it is worthwhile entertaining various options.
Sean