[Bioc-devel] InteractionSet for structural variants

Michael Lawrence |@wrence@m|ch@e| @end|ng |rom gene@com
Tue May 21 15:36:42 CEST 2019


The new package StructuralVariantAnnotation is worth mentioning. It
operates on the general "breakend" notation so should be able to represent
any type of structural variant.

On Tue, May 21, 2019 at 3:22 AM Sean Davis <seandavi using gmail.com> wrote:

> On Tue, May 21, 2019 at 2:54 AM Aaron Lun <
> infinite.monkeys.with.keyboards using gmail.com> wrote:
>
> > > Thanks for your response. So far my intention is to to plot them and I
> > > do not intend on performing any other operation. The first step would
> be
> > > read in the VCF file and transform it into a meaningful object and I
> was
> > > hoping there was a core package already taking care of that, but I get
> > > from your answer that there's no such functionality implemented.
> >
> > Not to my knowledge... but if you're planning on writing some relevant
> > functions, I'm sure we could find a home for it somewhere.
> >
>
> I do have a couple of simple functions in VCFWrenchR (not in Bioc), but
> like much VCF code, it probably misses a bunch of edge cases. The functions
> target VRanges, not interactionsets.
>
> https://github.com/seandavi/VCFWrenchR
>
> Sean
>
>
> > -A
> >
> > > El 5/18/19 a las 4:47 AM, Aaron Lun escribió:
> > >> 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
> >
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 

Michael Lawrence

Scientist, Bioinformatics and Computational Biology

Genentech <https://www.gene.com/>, A Member of the Roche Group

Office +1 (650) 225-7760

michafla using gene.com <lastname.firstname-or-unix using gene.com>


Join Genentech on LinkedIn <https://www.linkedin.com/company/genentech> |
Twitter
<https://twitter.com/genentech?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor>
| Facebook <https://www.facebook.com/Genentech/> | Instagram
<https://www.instagram.com/genentech/?hl=en> | YouTube
<https://www.youtube.com/genentech>

	[[alternative HTML version deleted]]



More information about the Bioc-devel mailing list