[Bioc-devel] InteractionSet for structural variants

Aaron Lun |n||n|te@monkey@@w|th@keybo@rd@ @end|ng |rom gm@||@com
Sat May 18 04:47:06 CEST 2019

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.


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
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

More information about the Bioc-devel mailing list