On Tue, May 21, 2019 at 2:54 AM Aaron Lun < infinite.monkeys.with.keyboa...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel