Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Kasper Daniel Hansen 
This is confusing the SV calling with the issue of moving between
coordinate systems which exists even with great/perfect genomes. Good point
on deletions and the new system, but it is nevertheless important

People do this for example for some of the new mouse genomes using modmap.

On Tue, May 21, 2019 at 10:25 AM Daniel Cameron 
wrote:

> We're never going to have great support for genome coordinate systems for
> SV due to the intrinsic complexity involved. Even something as simple as a
> deletion is problematic if the coordinate system change results in
> additional sequence in the deleted region (is that also deleted or not?),
> or some of the spanned/end-point sequence gets moved to a different
> chromosome. Sure, you can make approximations but it's never going to be a
> good/great results. To get a good result you'd need to rerun your SV
> calling pipeline in your new coordinate system. A lot more effort, but I'd
> have at least some confidence in the results.
>
> On Wed, May 22, 2019 at 12:07 AM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
>> I know little about SV and the associated software, but it is clear to me
>> that we will see a lot of "personal" genomes in the future and having the
>> ability to move between different reference genomes (coordinate systems)
>> will be something I think we should think about having good/great support
>> for.
>>
>> On Tue, May 21, 2019 at 9:37 AM Michael Lawrence via Bioc-devel <
>> bioc-devel@r-project.org> wrote:
>>
>> > 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  wrote:
>> >
>> > > 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
>> > > > >>>

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Daniel Cameron 
We're never going to have great support for genome coordinate systems for
SV due to the intrinsic complexity involved. Even something as simple as a
deletion is problematic if the coordinate system change results in
additional sequence in the deleted region (is that also deleted or not?),
or some of the spanned/end-point sequence gets moved to a different
chromosome. Sure, you can make approximations but it's never going to be a
good/great results. To get a good result you'd need to rerun your SV
calling pipeline in your new coordinate system. A lot more effort, but I'd
have at least some confidence in the results.

On Wed, May 22, 2019 at 12:07 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> I know little about SV and the associated software, but it is clear to me
> that we will see a lot of "personal" genomes in the future and having the
> ability to move between different reference genomes (coordinate systems)
> will be something I think we should think about having good/great support
> for.
>
> On Tue, May 21, 2019 at 9:37 AM Michael Lawrence via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > 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  wrote:
> >
> > > 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
> > >
> >
> >
> > --
> >
> > Michael Lawrence
> >
> > Scientist, Bioinformatics and Computational Biology
> >
> > Genentech , A Member of the Roche

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Kasper Daniel Hansen 
I know little about SV and the associated software, but it is clear to me
that we will see a lot of "personal" genomes in the future and having the
ability to move between different reference genomes (coordinate systems)
will be something I think we should think about having good/great support
for.

On Tue, May 21, 2019 at 9:37 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> 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  wrote:
>
> > 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
> >
>
>
> --
>
> Michael Lawrence
>
> Scientist, Bioinformatics and Computational Biology
>
> Genentech , A Member of the Roche Group
>
> Office +1 (650) 225-7760
>
> micha...@gene.com 
>
>
> Join Genentech on LinkedIn  |
> Twitter
> <
> https://twitter.com/genentech?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
> >
> | Facebook  | Instagram
>  | YouTube
> 
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Single Package Builder Updates

2019-05-21 Thread Shepherd, Lori 
The single package builder should be back online and available utilizing Bioc 
3.10 devel builders.

Thank you for your patience.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Shepherd, Lori 

Sent: Tuesday, May 21, 2019 7:27:39 AM
To: bioc-devel
Subject: [Bioc-devel] Single Package Builder Updates

Hello maintainers,


Now that the devel builds have been stable for a few weeks we will transition 
the single package builder to also be building off Bioc 3.10.   The transition 
will begin this morning and hopefully only last a few hours. During this period 
the Single Package Builder will be offline.

Thank you for your patience.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Michael Lawrence via Bioc-devel 
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  wrote:

> 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
>


-- 

Michael Lawrence

Scientist, Bioinformatics and Computational Biology

Genentech , A Member of the Roche Group

Office +1 (650) 225-7760

micha...@gene.com 


Join Genentech on LinkedIn  |
Twitter

| Facebook  | Instagram
 | YouTube


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Daniel Cameron 
>And actually, is there any package that would load a SV VCF by lumpy or
delly and build that object?

It sounds like you're looking for my StructuralVariantAnnotation package.
It's designed to load SV calls in any of various representations supported
by VCF (direct REF/ALT sequence differences, symbolic alleles, breakend
notation, and single breakend notation) and convert to a standard format
usable for downstream analysis (the initial release uses a breakend-level
GRanges object but I plan to also support different representation in the
future). I've tested against gridss, manta, delly, lumpy, crest, tigra,
pindel, gasvpro, clever, (and breakdancer/socrates in conjunction with
companion scripts to convert to VCF) although I've just noticed that delly
has changed their output format from one VCF non-complaint format to a
different VCF non-compliant format (delly is only writing one of the two
required BND records) so the package won't load results from the latest
delly version.

What's your use case? I've found it useful for a wide range of downstream
analysis including sv benchmarking (matching SV calls between
callers/between truth sets), gene disruption/fusion detection, somatic
filtering, breakpoint graph traversal, consistency checking between
breakpoint and CNV calls, and others.

> 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.

I've gone with a breakend-level GRanges notation as all (non-CNV) SV events
can be converted to this notation. CNV are not supported as they make a
claim about DNA segments, whereas the other events are making claims about
DNA segment adjacency - something that unfortunately the VCF specifications
does not distinguish between.

Cheers
Daniel

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Documentation on Extending BioC Packages

2019-05-21 Thread Patrick Casimir 
Hi Steffen,

Thanks for your response. I want to do something useful by extending other BioC 
packages through S4 classes, essentially looking for documentation and 
mentoring. I will have more details next week.

Best,

Patrick Casimir, PhD
C: 954.614.1178


-Original Message-
From: Neumann, Steffen  
Sent: Tuesday, May 21, 2019 2:42 AM
To: Patrick Casimir ; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Documentation on Extending BioC Packages

NSU Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know that the content is safe.


Hi,

On Sun, 2019-05-19 at 21:37 +, Patrick Casimir wrote:
> Where can I locate the best resources about Extending Bioconductor 
> packages?

Can you be a bit more specific ? Do you want to extend your own package with 
new functionality ? Or do you have some cool stuff, that would fit well into 
somebody else's package ?

Or do you want to do something useful, and think that this would be done best 
by extending someone's package, essentially looking for documentation and 
mentoring ?

Yours,
Steffen

--

IPB HalleAG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann  
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.IPB-Halle.DEdata=02%7C01%7Cpatrcasi%40nova.edu%7C8b4e14d2294f4958c74308d6ddb77d1c%7C2c2b2d312e3e4df1b571fb37c042ff1b%7C0%7C1%7C636940177496667540sdata=z1vWoq633oanal0KB14ZhKjQhDi2ZOoK3y3VmiCPMxs%3Dreserved=0
Weinberg 3   Tel. +49 (0) 345 5582 - 1470
06120 Halle   +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Single Package Builder Updates

2019-05-21 Thread Shepherd, Lori 
Hello maintainers,


Now that the devel builds have been stable for a few weeks we will transition 
the single package builder to also be building off Bioc 3.10.   The transition 
will begin this morning and hopefully only last a few hours. During this period 
the Single Package Builder will be offline.

Thank you for your patience.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Sean Davis 
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

Re: [Bioc-devel] InteractionSet for structural variants

2019-05-21 Thread Aaron Lun 

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.


-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


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Documentation on Extending BioC Packages

2019-05-21 Thread Neumann, Steffen 
Hi,

On Sun, 2019-05-19 at 21:37 +, Patrick Casimir wrote:
> Where can I locate the best resources about Extending Bioconductor
> packages?

Can you be a bit more specific ? Do you want to extend your own package
with new functionality ? Or do you have some cool stuff, 
that would fit well into somebody else's package ? 

Or do you want to do something useful, and think that this 
would be done best by extending someone's package, 
essentially looking for documentation and mentoring ? 

Yours,
Steffen

-- 

IPB HalleAG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann  http://www.IPB-Halle.DE
Weinberg 3   Tel. +49 (0) 345 5582 - 1470
06120 Halle   +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel