suggestion: aliases in @SQ section

[lindenb]

A suggestion for the Sam Sequence dictionary: would it be possible to add an optional list of aliases in the @sq header ? softwares would use those aliases to fix the various nomenclatures (UCSC, ENSEMBL )

Something like:

@SQ SN:MT LN:12345 AL:chrMT|chrM
@SQ SN:X LN:1234567 AL:chrX|chr0X|0X

then

samtools view my.bam MT:1-100

would return the same ouput than

samtools view my.bam chrM:1-100

[atks]

I think we should have this for the contigs in VCF too.

[jmarshall]

This is IMHO a rather good idea, although we'd have to come up with a different separator as e.g. NCBI likes to use | characters within sequence names. I might prefer AN: or so ("alternative/alias names") to parallel SN:.

We'd also have to think about what rules are necessary around distinctness, and to be explicit whether alignment records in SAM files would be allowed to use these aliases in RNAME/RNEXT (surely not!).

[jmarshall]

It seems NCBI will be phasing out their | characters in sequence names, though we probably still can't use | here as people will still have older NCBI files lying around.

[vadimzalunin]

are aliases known at write time? seems like aliases are read time decision to me.

[dpryan79]

Most programs don't currently know about them when they make BAM files, but that could be changed.

I have to mention that dealing with different naming schemes is a huge annoyance, particularly on things like Galaxy where you have novice users who are often not aware of this issue and inevitably need to be walked through properly munging things.

[jmarshall]

We discussed this at some length back at our September meeting (and I'm finally writing up my notes from then). We continue to mostly like the idea in principle, but need to spell out rules around uniqueness and so on.

We noted that we can use this as an opportunity to define the alias regexp to be the excellently tight regexp (disallowing especially : and perhaps other punctuation too; cf #167) that we wish we'd always had for SN. Doing so will solve the what-separator-to-use problem, and provide a path towards restricting SN to the same regexp — at which point chr:beg-end notation would finally be unambiguous.

There was concern expressed that adding this reduces pressure on GRC to agree on a “chr” vs “” prefix. The opposing view to that is to admit that the world has not yet agreed on which end of the prefix to crack open and providing tools to reduce the ensuing pain is useful, as espoused by others on this thread.

In PR #103, @lindenb proposes the following text (thanks!):

AN Reference sequence Alternative Names. A semicolon separated list of alternative names for this sequence e.g: 1;01;CM000663;NC_000001.10. Tools are free to use this information to decode the users' positions but the name displayed in the output is always SN.

I've taken this on, and will propose additions to this that spells out distinctness requirements etc.