Herve,
This is probably a naive question, but what usecases are there for
creating an object with the wrong seqinfo for its genome?
~G
On Fri, Jun 5, 2015 at 11:43 AM, Michael Lawrence
<lawrence.mich...@gene.com <mailto:lawrence.mich...@gene.com>> wrote:
On Thu, Jun 4, 2015 at 11:48 PM, Hervé Pagès <hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>> wrote:
> I also think that we're heading towards something like that.
>
> So genome(gr) <- "hg19" would:
>
> (a) Add any missing information to the seqinfo.
> (b) Sort the seqlevels in "canonical" order.
> (c) Change the seqlevels style to UCSC style if they are not.
>
> The 3 tasks are orthogonal. I guess most of the times people want
> an easy way to perform them all at once.
>
> We could easily support (a) and (b). This assumes that the current
> seqlevels are already valid hg19 seqlevels:
>
> si1 <- Seqinfo(c("chrX", "chrUn_gl000249", "chr2",
"chr6_cox_hap2"))
> gr1 <- GRanges(seqinfo=si1)
> hg19_si <- Seqinfo(genome="hg19")
>
> ## (a):
> seqinfo(gr1) <- merge(seqinfo(gr1), hg19_si)[seqlevels(gr1)]
> seqinfo(gr1)
> # Seqinfo object with 4 sequences (1 circular) from hg19 genome:
> # seqnames seqlengths isCircular genome
> # chrX 155270560 FALSE hg19
> # chrUn_gl000249 38502 FALSE hg19
> # chr2 243199373 FALSE hg19
> # chr6_cox_hap2 4795371 FALSE hg19
>
> ## (b):
> seqlevels(gr1) <- intersect(seqlevels(hg19_si), seqlevels(gr1))
> seqinfo(gr1)
> # Seqinfo object with 4 sequences (1 circular) from hg19 genome:
> # seqnames seqlengths isCircular genome
> # chr2 243199373 FALSE hg19
> # chrX 155270560 FALSE hg19
> # chr6_cox_hap2 4795371 FALSE hg19
> # chrUn_gl000249 38502 FALSE hg19
>
> (c) is harder because seqlevelsStyle() doesn't know how to rename
> scaffolds yet:
>
> si2 <- Seqinfo(c("X", "HSCHRUN_RANDOM_CTG42", "2",
"HSCHR6_MHC_COX_CTG1"))
> gr2 <- GRanges(seqinfo=si2)
>
> seqlevelsStyle(gr2)
> # [1] "NCBI"
>
> seqlevelsStyle(gr2) <- "UCSC"
> seqlevels(gr2)
> # [1] "chrX" "HSCHRUN_RANDOM_CTG42" "chr2"
> # [4] "HSCHR6_MHC_COX_CTG1"
>
> So we need to work on this.
>
> I'm not sure about using genome(gr) <- "hg19" for this. Right now
> it sets the genome column of the seqinfo with the supplied string
> and nothing else. Aren't there valid use cases for this?
Not sure. People would almost always want the seqname style and order
to be consistent with the given genome.
> What about
> using seqinfo(gr) <- "hg19" instead? It kind of suggests that the
> whole seqinfo component actually gets filled.
>
Yea, but "genome" is so intuitive compared to "seqinfo".
> H.
>
> On 06/04/2015 06:30 PM, Tim Triche, Jr. wrote:
>>
>> that's kind of always been my goal...
>>
>>
>> Statistics is the grammar of science.
>> Karl Pearson <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>>
>> On Thu, Jun 4, 2015 at 6:29 PM, Michael Lawrence
>> <lawrence.mich...@gene.com <mailto:lawrence.mich...@gene.com>
<mailto:lawrence.mich...@gene.com
<mailto:lawrence.mich...@gene.com>>> wrote:
>>
>> Maybe this could eventually support setting the seqinfo with:
>>
>> genome(gr) <- "hg19"
>>
>> Or is that being too clever?
>>
>> On Thu, Jun 4, 2015 at 4:28 PM, Hervé Pagès
<hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>
>> <mailto:hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>>>
wrote:
>> > Hi,
>> >
>> > FWIW I started to work on supporting quick generation of a
>> standalone
>> > Seqinfo object via Seqinfo(genome="hg38") in GenomeInfoDb.
>> >
>> > It already supports hg38, hg19, hg18, panTro4, panTro3,
panTro2,
>> > bosTau8, bosTau7, bosTau6, canFam3, canFam2, canFam1,
musFur1,
>> mm10,
>> > mm9, mm8, susScr3, susScr2, rn6, rheMac3, rheMac2, galGal4,
>> galGal3,
>> > gasAcu1, danRer7, apiMel2, dm6, dm3, ce10, ce6, ce4, ce2,
sacCer3,
>> > and sacCer2. I'll add more.
>> >
>> > See ?Seqinfo for some examples.
>> >
>> > Right now it fetches the information from internet every
time you
>> > call it but maybe we should just store that information
in the
>> > GenomeInfoDb package as Tim suggested?
>> >
>> > H.
>> >
>> >
>> > On 06/03/2015 12:54 PM, Tim Triche, Jr. wrote:
>> >>
>> >> That would be perfect actually. And it would radically
reduce &
>> >> modularize maintenance. Maybe that's the best way to go
after
>> all. Quite
>> >> sensible.
>> >>
>> >> --t
>> >>
>> >>> On Jun 3, 2015, at 12:46 PM, Vincent Carey
>> <st...@channing.harvard.edu
<mailto:st...@channing.harvard.edu>
<mailto:st...@channing.harvard.edu <mailto:st...@channing.harvard.edu>>>
>> >>> wrote:
>> >>>
>> >>> It really isn't hard to have multiple OrganismDb
packages in
>> place -- the
>> >>> process of making new ones is documented and was given
as an
>> exercise in
>> >>> the EdX course. I don't know if we want to
institutionalize it
>> and
>> >>> distribute such -- I think we might, so that there would be
>> Hs19, Hs38,
>> >>> mm9, etc. packages. They have very little content,
they just
>> coordinate
>> >>> interactions with packages that you'll already have.
>> >>>
>> >>> On Wed, Jun 3, 2015 at 3:26 PM, Tim Triche, Jr.
>> <tim.tri...@gmail.com <mailto:tim.tri...@gmail.com>
<mailto:tim.tri...@gmail.com <mailto:tim.tri...@gmail.com>>>
>>
>> >>> wrote:
>> >>>
>> >>>> Right, I typically do that too, and if you're working
on human
>> data it
>> >>>> isn't a big deal. What makes things a lot more of a
drag is
>> when you
>> >>>> work
>> >>>> on e.g. mouse data (mm9 vs mm10, aka GRCm37 vs GRCm38)
where
>> >>>> Mus.musculus
>> >>>> is essentially a "build ahead" of Homo.sapiens.
>> >>>>
>> >>>> R> seqinfo(Homo.sapiens)
>> >>>> Seqinfo object with 93 sequences (1 circular) from
hg19 genome
>> >>>>
>> >>>> R> seqinfo(Mus.musculus)
>> >>>> Seqinfo object with 66 sequences (1 circular) from
mm10 genome:
>> >>>>
>> >>>> It's not as explicit as directly assigning the seqinfo
from a
>> genome
>> >>>> that
>> >>>> corresponds to that of your
annotations/results/whatever. I
>> know we
>> >>>> could
>> >>>> all use crossmap or liftOver or whatever, but that's not
>> really the
>> >>>> same,
>> >>>> and it takes time, whereas assigning the proper
seqinfo for
>> >>>> relationships
>> >>>> is very fast.
>> >>>>
>> >>>> That's all I was getting at...
>> >>>>
>> >>>>
>> >>>> Statistics is the grammar of science.
>> >>>> Karl Pearson
>> <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>> >>>>
>> >>>> On Wed, Jun 3, 2015 at 12:17 PM, Vincent Carey
>> >>>> <st...@channing.harvard.edu
<mailto:st...@channing.harvard.edu>
<mailto:st...@channing.harvard.edu <mailto:st...@channing.harvard.edu>>
>> >>>>>
>> >>>>> wrote:
>> >>>>
>> >>>>
>> >>>>> I typically get this info from Homo.sapiens. The
result is
>> parasitic
>> >>>>> on
>> >>>>> the TxDb that is in there. I don't know how easy it
is to swap
>> >>>>> alternate
>> >>>>> TxDb in to get a different build. I think it would
make sense
>> to
>> >>>>> regard
>> >>>>> the OrganismDb instances as foundational for this sort of
>> structural
>> >>>>> data.
>> >>>>>
>> >>>>> On Wed, Jun 3, 2015 at 3:12 PM, Kasper Daniel Hansen <
>> >>>>> kasperdanielhan...@gmail.com
<mailto:kasperdanielhan...@gmail.com>
>> <mailto:kasperdanielhan...@gmail.com
<mailto:kasperdanielhan...@gmail.com>>> wrote:
>> >>>>>
>> >>>>>> Let me rephrase this slightly. From one POV the
purpose of
>> >>>>>> GenomeInfoDb
>> >>>>>> is
>> >>>>>> clean up the seqinfo slot. Currently it does most
of the
>> cleaning,
>> >>>>>> but
>> >>>>>> it
>> >>>>>> does not add seqlengths.
>> >>>>>>
>> >>>>>> It is clear that seqlengths depends on the version
of the
>> genome, but
>> >>>>>> I
>> >>>>>> will argue so does the seqnames. Of course, for human,
>> chr22 will not
>> >>>>>> change. But what about the names of all the random
>> contigs? Or for
>> >>>>>> other
>> >>>>>> organisms, what about going from a draft genome with 10k
>> contigs to a
>> >>>>>> more
>> >>>>>> completely genome assembled into fewer, larger
chromosomes.
>> >>>>>>
>> >>>>>> I acknowledge that this information is present in
the BSgenome
>> >>>>>> packages,
>> >>>>>> but it seems (to me) to be very appropriate to have them
>> around for
>> >>>>>> cleaning up the seqinfo slot. For some situations
it is not
>> great to
>> >>>>>> depend on 1 GB> download for something that is a few
bytes.
>> >>>>>>
>> >>>>>> Best,
>> >>>>>> Kasper
>> >>>>>>
>> >>>>>> On Wed, Jun 3, 2015 at 3:00 PM, Tim Triche, Jr.
>> <tim.tri...@gmail.com <mailto:tim.tri...@gmail.com>
<mailto:tim.tri...@gmail.com <mailto:tim.tri...@gmail.com>>>
>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> It would be nice (for a number of reasons) to have
>> chromosome lengths
>> >>>>>>> readily available in a foundational package like
>> GenomeInfoDb, so
>> >>>>>>> that,
>> >>>>>>> say,
>> >>>>>>>
>> >>>>>>> data(seqinfo.hg19)
>> >>>>>>> seqinfo(myResults) <- seqinfo.hg19[
seqlevels(myResults) ]
>> >>>>>>>
>> >>>>>>> would work without issues. Is there any particular
reason
>> this
>> >>>>>>
>> >>>>>> couldn't
>> >>>>>>>
>> >>>>>>> happen for the supported/available BSgenomes? It would
>> seem like a
>> >>>>>>
>> >>>>>> simple
>> >>>>>>>
>> >>>>>>> matter to do
>> >>>>>>>
>> >>>>>>> R> library(BSgenome.Hsapiens.UCSC.hg19)
>> >>>>>>> R> seqinfo.hg19 <- seqinfo(Hsapiens)
>> >>>>>>> R> save(seqinfo.hg19,
>> >>>>>>> file="~/bioc-devel/GenomeInfoDb/data/seqinfo.hg19.rda")
>> >>>>>>>
>> >>>>>>> and be done with it until (say) the next release or
next
>> released
>> >>>>>>> BSgenome. I considered looping through the following
>> BSgenomes
>> >>>>>>
>> >>>>>> myself...
>> >>>>>>>
>> >>>>>>> and if it isn't strongly opposed by (everyone) I
may still
>> do exactly
>> >>>>>>> that. Seems useful, no?
>> >>>>>>>
>> >>>>>>> e.g. for the following 42 builds,
>> >>>>>>>
>> >>>>>>> grep("(UCSC|NCBI)", unique(gsub(".masked", "",
>> available.genomes())),
>> >>>>>>> value=TRUE)
>> >>>>>>> [1] "BSgenome.Amellifera.UCSC.apiMel2"
>> >>>>>>
>> >>>>>> "BSgenome.Btaurus.UCSC.bosTau3"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [3] "BSgenome.Btaurus.UCSC.bosTau4"
>> >>>>>>
>> >>>>>> "BSgenome.Btaurus.UCSC.bosTau6"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [5] "BSgenome.Btaurus.UCSC.bosTau8"
>> >>>>>>> "BSgenome.Celegans.UCSC.ce10"
>> >>>>>>>
>> >>>>>>> [7] "BSgenome.Celegans.UCSC.ce2"
>> "BSgenome.Celegans.UCSC.ce6"
>> >>>>>>>
>> >>>>>>> [9] "BSgenome.Cfamiliaris.UCSC.canFam2"
>> >>>>>>> "BSgenome.Cfamiliaris.UCSC.canFam3"
>> >>>>>>> [11] "BSgenome.Dmelanogaster.UCSC.dm2"
>> >>>>>>> "BSgenome.Dmelanogaster.UCSC.dm3"
>> >>>>>>> [13] "BSgenome.Dmelanogaster.UCSC.dm6"
>> >>>>>>
>> >>>>>> "BSgenome.Drerio.UCSC.danRer5"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [15] "BSgenome.Drerio.UCSC.danRer6"
>> >>>>>>
>> >>>>>> "BSgenome.Drerio.UCSC.danRer7"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [17] "BSgenome.Ecoli.NCBI.20080805"
>> >>>>>>> "BSgenome.Gaculeatus.UCSC.gasAcu1"
>> >>>>>>> [19] "BSgenome.Ggallus.UCSC.galGal3"
>> >>>>>>
>> >>>>>> "BSgenome.Ggallus.UCSC.galGal4"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [21] "BSgenome.Hsapiens.NCBI.GRCh38"
>> >>>>>>> "BSgenome.Hsapiens.UCSC.hg17"
>> >>>>>>>
>> >>>>>>> [23] "BSgenome.Hsapiens.UCSC.hg18"
>> >>>>>>> "BSgenome.Hsapiens.UCSC.hg19"
>> >>>>>>>
>> >>>>>>> [25] "BSgenome.Hsapiens.UCSC.hg38"
>> >>>>>>> "BSgenome.Mfascicularis.NCBI.5.0"
>> >>>>>>> [27] "BSgenome.Mfuro.UCSC.musFur1"
>> >>>>>>
>> >>>>>> "BSgenome.Mmulatta.UCSC.rheMac2"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [29] "BSgenome.Mmulatta.UCSC.rheMac3"
>> >>>>>>
>> >>>>>> "BSgenome.Mmusculus.UCSC.mm10"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [31] "BSgenome.Mmusculus.UCSC.mm8"
>> >>>>>>> "BSgenome.Mmusculus.UCSC.mm9"
>> >>>>>>>
>> >>>>>>> [33] "BSgenome.Ptroglodytes.UCSC.panTro2"
>> >>>>>>> "BSgenome.Ptroglodytes.UCSC.panTro3"
>> >>>>>>> [35] "BSgenome.Rnorvegicus.UCSC.rn4"
>> >>>>>>
>> >>>>>> "BSgenome.Rnorvegicus.UCSC.rn5"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [37] "BSgenome.Rnorvegicus.UCSC.rn6"
>> >>>>>>> "BSgenome.Scerevisiae.UCSC.sacCer1"
>> >>>>>>> [39] "BSgenome.Scerevisiae.UCSC.sacCer2"
>> >>>>>>> "BSgenome.Scerevisiae.UCSC.sacCer3"
>> >>>>>>> [41] "BSgenome.Sscrofa.UCSC.susScr3"
>> >>>>>>
>> >>>>>> "BSgenome.Tguttata.UCSC.taeGut1"
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Am I insane for suggesting this? It would make
things a
>> little
>> >>>>>>> easier
>> >>>>>>
>> >>>>>> for
>> >>>>>>>
>> >>>>>>> rtracklayer, most SummarizedExperiment and SE-derived
>> objects, blah,
>> >>>>>>
>> >>>>>> blah,
>> >>>>>>>
>> >>>>>>> blah...
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Best,
>> >>>>>>>
>> >>>>>>> --t
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Statistics is the grammar of science.
>> >>>>>>> Karl Pearson
>> <http://en.wikipedia.org/wiki/The_Grammar_of_Science>
>> >>>>>>
>> >>>>>>
>> >>>>>> [[alternative HTML version deleted]]
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org> <mailto:Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org>>
>> mailing list
>> >>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>>
>> >>>
>> >>> [[alternative HTML version deleted]]
>> >>>
>> >>> _______________________________________________
>> >>> Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org> <mailto:Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org>>
>> mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >>
>> >> _______________________________________________
>> >> Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org> <mailto:Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org>>
>> mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >
>> > --
>> > Hervé Pagès
>> >
>> > Program in Computational Biology
>> > Division of Public Health Sciences
>> > Fred Hutchinson Cancer Research Center
>> > 1100 Fairview Ave. N, M1-B514
>> > P.O. Box 19024
>> > Seattle, WA 98109-1024
>> >
>> > E-mail: hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org> <mailto:hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>>
>> > Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
<tel:%28206%29%20667-5791>
>> > Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
<tel:%28206%29%20667-1319>
>> >
>> >
>> > _______________________________________________
>> > Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org> <mailto:Bioc-devel@r-project.org
<mailto:Bioc-devel@r-project.org>>
>> mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>
> Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
> Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
_______________________________________________
Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Gabriel Becker, Ph.D
Computational Biologist
Genentech Research
