I would say that it depends on what operations you intend to perform
on them. You can _store_ things any way you like, but the trick is to
ensure that operations and manipulations on those things are
consistent and meaningful. It is not obvious that there are meaningful
common operations that one might want to apply to all structural
variants.
For example, translocations involve two genomic regions (i.e., the two
bits that get stuck together) and so are inherently two-dimensional. A
lot of useful operations will be truly translocation-specific, e.g.,
calculation of distances between anchor regions, identification of
bounding boxes in two-dimensional space. These operations will be
meaningless to 1-dimensional variants on the linear genome, e.g.,
CNVs, inversions. The converse also applies where operations on the
linear genome have no single equivalent in the two-dimensional case.
So, I would be inclined to store them separately. If you must keep
them in one object, just lump them into a List with "translocation"
(GInteractions), "cnv" (GRanges) and "inversion" (another GRanges)
elements, and people/programs can pull out bits and pieces as needed.
-A
On 5/17/19 4:38 AM, Bernat Gel Moreno wrote:
Hi all,
Is there any standard recommended container for genomic structural
variants? I think InteractionSet would work fine for translocation and
GRanges for inversions and copy number changes, but I don't know what
would be the recommended way to store them all together using standard
Bioconductor objects.
And actually, is there any package that would load a SV VCF by lumpy or
delly and build that object?
Thanks!
Bernat