added alternateBasesInfo

[heinzstockinger]

Extends support for structural variants and simple range queries.

Follow up of issue 20: #20

[mbaudis]

I am generally +1 on this, but would also create a structured object to represent the data. With this, we can for now detail the supported elements (array<long> cipos = []; array<long> ciend = []; union {null, long} end = null ...

[mbaudis]

As per our face-to-face discussion, the strategy now is to express those attributes in the info map, in line with the current GA4GH schema. I think that a structured alternateBasesInfo or variantInfo object would be better; however, this should be implemented in line with GA4GH schemas.

I'm opening an issue ga4gh/ga4gh-schemas#752 for discussion.

[mbaudis]

... however, info or a VariantInfo object may not be the only choices; could be separate attributes in the variant message. An example would be the current ga4gh Variant.end, which is a parameter in VCF's "INFO",

[mbaudis]

In GA4GH master, there is now a representation of first structural variants using

• variant_type
• svlen
• cipos
• ciend

Changes are to be found here (merged) https://github.com/ga4gh/schemas/pull/827/files

For Beacon, this suggests that we should preferably move into the same direction, i.e. using specific attributes instead of sending & interpolating an INFO field representation.

[sdelatorrep]

+1 to add specific attributes

[mcupak]

Superseded by #94.