{"action":"closed","issue":{"url":"https://api.github.com/repos/samtools/hts-specs/issues/204","repository_url":"https://api.github.com/repos/samtools/hts-specs","labels_url":"https://api.github.com/repos/samtools/hts-specs/issues/204/labels{/name}","comments_url":"https://api.github.com/repos/samtools/hts-specs/issues/204/comments","events_url":"https://api.github.com/repos/samtools/hts-specs/issues/204/events","html_url":"https://github.com/samtools/hts-specs/issues/204","id":226272055,"node_id":"MDU6SXNzdWUyMjYyNzIwNTU=","number":204,"title":"Representing custom sort and group orderings in SAM/BAM","user":{"login":"tfenne","id":1609210,"node_id":"MDQ6VXNlcjE2MDkyMTA=","avatar_url":"https://avatars3.githubusercontent.com/u/1609210?v=4","gravatar_id":"","url":"https://api.github.com/users/tfenne","html_url":"https://github.com/tfenne","followers_url":"https://api.github.com/users/tfenne/followers","following_url":"https://api.github.com/users/tfenne/following{/other_user}","gists_url":"https://api.github.com/users/tfenne/gists{/gist_id}","starred_url":"https://api.github.com/users/tfenne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tfenne/subscriptions","organizations_url":"https://api.github.com/users/tfenne/orgs","repos_url":"https://api.github.com/users/tfenne/repos","events_url":"https://api.github.com/users/tfenne/events{/privacy}","received_events_url":"https://api.github.com/users/tfenne/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2017-05-04T12:56:55Z","updated_at":"2018-10-18T19:13:45Z","closed_at":"2018-10-18T19:13:45Z","author_association":"MEMBER","body":"I would really like a way to represent custom orderings in SAM/BAM/etc.  There are a number of tools, across multiple organizations and code bases that emit BAM files that have been sorted into specific orderings that are not representable in a standard way in the current header.\r\n\r\nThe only solution(s) currently are to add additional tags to the header to represent things, e.g.:\r\n`@HD  SO=unsorted so=duplicate-ordered`.  I think this is a general enough issue that it would be worthwhile standardizing how to represent this information.  Though the orderings themselves are often esoteric enough that standardizing those would likely be a bad idea.  For example, I have one custom ordering I use that sorts all records by \"the 5' unclipped position of the primary record for the read within the pair that is earlier on the genome\"!\r\n\r\nI can think of a few ways of specifying this, that range from total backwards compatible, to ones that are not backwards compatible (though would be easy to adjust to).  I'd like to gather feedback here, and if there is support, I will create a PR.\r\n\r\nI'll also note, that the solutions I'm proposing could also be used to provide a nice solution to the samtools vs. Picard queryname sorting issue that has existed forever.\r\n\r\n### Option 1: Totally Backwards Compatible\r\nAdd a new standard tag to the header that specifies \"sub-sort-order\", where the tag is standard but the values are unconstrained.  This would allow things like (using `SS` as the new tag for the examples):\r\n\r\n```\r\n@HD  SO:queryname  SS:lexical\r\n@HD  SO:queryname  SS:numeric-lexical\r\n@HD  SO:unsorted   SS:duplicate-order\r\n```\r\n\r\nExisting tools could largely ignore the `SS` tag in the header, and custom orderings could be defined with SO:unsorted and custom values for `SS`.  This could give rise to odd situations though when an existing tool resorts a BAM and doesn't know to remove/update the `SS` tag, giving rise to incorrectly labeling.\r\n\r\nI'm also not super-keen on breaking the information across two fields personally.\r\n\r\n### Option 2: Semi-backwards compatible\r\nAllow \"sub-typing\" of sort orders.  Pick a delimiter character and then a sort order may be composed of a \"major\" and _optionally_ \"minor\" ordering, e.g.:\r\n\r\n```\r\n@HD  SO:queryname:lexical\r\n@HD  SO:queryname:numeric-lexical\r\n@HD  SO:unsorted:duplicate-order\r\n```\r\n\r\nUnder this model `SO:queryname` would still be totally valid, so all existing files would be forward-compatible.  But tools would need to be updated to parse the slightly more complicated SO format.  The upside is that tools that resort BAMs, even before being updated, would not generate incorrect information.\r\n\r\n### Option 3: Only fowards-compatible\r\n\r\nAs option 1 or option 2, but introduce a new sort order `custom`, instead of using sub-orderings on `unsorted`.  This would obviously be much clearer moving forward, but would introduce a new sort order that older tools might not be able to handle."}}
{"actor":{"display_login":"jmarshall"}}