Search
Question: Creating an OrganismDbi package with a few transcript annotations
0
gravatar for Michael Lawrence
4.5 years ago by
United States
Michael Lawrence9.8k wrote:
Hi, I'd like to create an OrganismDbi package so that I can put extra annotations on the transcripts/genes in a TxDb package. My understanding is that I need a separate database package that I can join with the TxDb package. Do I need to make an OrgDb package? I looked into this a bit and it seems that there is little support for making a non-NCBI-based org package. Maybe I could create a new type of package with a simple table with a row for each transcript, including the gene symbol and whether the transcript is "canonical" according to UCSC. It looks like this process is documented here: http://www.bioconductor.org/packages/2.12/bioc/vignettes/AnnotationFor ge/inst/doc/NewSchema.pdf. It also seems really involved. What's the path of least resistance here? Thanks, Michael [[alternative HTML version deleted]]
ADD COMMENTlink modified 4.5 years ago by Martin Morgan ♦♦ 20k • written 4.5 years ago by Michael Lawrence9.8k
0
gravatar for Martin Morgan
4.5 years ago by
Martin Morgan ♦♦ 20k
United States
Martin Morgan ♦♦ 20k wrote:
On 05/16/2013 01:50 PM, Michael Lawrence wrote: > Hi, > > I'd like to create an OrganismDbi package so that I can put extra > annotations on the transcripts/genes in a TxDb package. My understanding is > that I need a separate database package that I can join with the TxDb > package. Do I need to make an OrgDb package? I looked into this a bit and > it seems that there is little support for making a non-NCBI-based org > package. Maybe I could create a new type of package with a simple table > with a row for each transcript, including the gene symbol and whether the > transcript is "canonical" according to UCSC. It looks like this process is > documented here: > http://www.bioconductor.org/packages/2.12/bioc/vignettes/AnnotationF orge/inst/doc/NewSchema.pdf. > It also seems really involved. What's the path of least resistance here? Hi Michael -- Marc is away for a few days. I *think* the idea is that the details in NewSchema are no longer required, rather, implement your extra data in any fashion to provide a 'select' interface, i.e., keytypes keys cols select following the implied API of ?keytypes. Then create an OrgDb package with AnnotationDbi::makeOrganismPackage Sorry not to be more definitive in my help. Martin > > Thanks, > Michael > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793
ADD COMMENTlink written 4.5 years ago by Martin Morgan ♦♦ 20k
Cool, thanks Martin. I'll wait for Marc to get back. If what you say is correct, it would be nice to have a simple data frame implementation. I'm getting the annotations from a biomart, so a biomart implementation would be ideal, although that might be tricky semantically. Michael On Fri, May 17, 2013 at 5:43 PM, Martin Morgan <mtmorgan@fhcrc.org> wrote: > On 05/16/2013 01:50 PM, Michael Lawrence wrote: > >> Hi, >> >> I'd like to create an OrganismDbi package so that I can put extra >> annotations on the transcripts/genes in a TxDb package. My understanding >> is >> that I need a separate database package that I can join with the TxDb >> package. Do I need to make an OrgDb package? I looked into this a bit and >> it seems that there is little support for making a non-NCBI-based org >> package. Maybe I could create a new type of package with a simple table >> with a row for each transcript, including the gene symbol and whether the >> transcript is "canonical" according to UCSC. It looks like this process is >> documented here: >> http://www.bioconductor.org/**packages/2.12/bioc/vignettes/** >> AnnotationForge/inst/doc/**NewSchema.pdf<http: www.bioconductor.or="" g="" packages="" 2.12="" bioc="" vignettes="" annotationforge="" inst="" doc="" newschema.pdf=""> >> . >> It also seems really involved. What's the path of least resistance here? >> > > Hi Michael -- Marc is away for a few days. I *think* the idea is that the > details in NewSchema are no longer required, rather, implement your extra > data in any fashion to provide a 'select' interface, i.e., > > keytypes > keys > cols > select > > following the implied API of ?keytypes. Then create an OrgDb package with > > AnnotationDbi::**makeOrganismPackage > > Sorry not to be more definitive in my help. > > Martin > > >> Thanks, >> Michael >> >> [[alternative HTML version deleted]] >> >> ______________________________**_________________ >> Bioconductor mailing list >> Bioconductor@r-project.org >> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.e="" thz.ch="" mailman="" listinfo="" bioconductor=""> >> Search the archives: http://news.gmane.org/gmane.** >> science.biology.informatics.**conductor<http: news.gmane.org="" gmane="" .science.biology.informatics.conductor=""> >> >> > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 > [[alternative HTML version deleted]]
ADD REPLYlink written 4.5 years ago by Michael Lawrence9.8k
Hi Michael, As usual, Martin is on the right track. The new Schema .pdf stuff is only if you really need the old school bimaps, and bimaps are not actually needed for any of the OrganismDbi stuff. So the interface of keytypes, cols, keys and select really ought to be enough to allow integration into OrganismDbi... And, if you also followed the same org package DB schema that we use everywhere else that would be ideal since in that case, you could just recycle the methods we have already defined for OrgDb objects... So in order to do that, a biomart equivalent to AnntotationForge:::makeOrgDbFromNCBI() and AnntotationForge:::makeOrgPackageFromNCBI would be a nice addition. And I agree that a simple data.frame() based underlying implementation would make this easier to generalize. Right now things are a bit specialized for NCBI resources. Marc On 05/17/2013 09:56 PM, Michael Lawrence wrote: > Cool, thanks Martin. I'll wait for Marc to get back. If what you say is > correct, it would be nice to have a simple data frame implementation. I'm > getting the annotations from a biomart, so a biomart implementation would > be ideal, although that might be tricky semantically. > > Michael > > > > > On Fri, May 17, 2013 at 5:43 PM, Martin Morgan <mtmorgan at="" fhcrc.org=""> wrote: > >> On 05/16/2013 01:50 PM, Michael Lawrence wrote: >> >>> Hi, >>> >>> I'd like to create an OrganismDbi package so that I can put extra >>> annotations on the transcripts/genes in a TxDb package. My understanding >>> is >>> that I need a separate database package that I can join with the TxDb >>> package. Do I need to make an OrgDb package? I looked into this a bit and >>> it seems that there is little support for making a non-NCBI-based org >>> package. Maybe I could create a new type of package with a simple table >>> with a row for each transcript, including the gene symbol and whether the >>> transcript is "canonical" according to UCSC. It looks like this process is >>> documented here: >>> http://www.bioconductor.org/**packages/2.12/bioc/vignettes/** >>> AnnotationForge/inst/doc/**NewSchema.pdf<http: www.bioconductor.o="" rg="" packages="" 2.12="" bioc="" vignettes="" annotationforge="" inst="" doc="" newschema.pdf=""> >>> . >>> It also seems really involved. What's the path of least resistance here? >>> >> Hi Michael -- Marc is away for a few days. I *think* the idea is that the >> details in NewSchema are no longer required, rather, implement your extra >> data in any fashion to provide a 'select' interface, i.e., >> >> keytypes >> keys >> cols >> select >> >> following the implied API of ?keytypes. Then create an OrgDb package with >> >> AnnotationDbi::**makeOrganismPackage >> >> Sorry not to be more definitive in my help. >> >> Martin >> >> >>> Thanks, >>> Michael >>> >>> [[alternative HTML version deleted]] >>> >>> ______________________________**_________________ >>> Bioconductor mailing list >>> Bioconductor at r-project.org >>> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.="" ethz.ch="" mailman="" listinfo="" bioconductor=""> >>> Search the archives: http://news.gmane.org/gmane.** >>> science.biology.informatics.**conductor<http: news.gmane.org="" gman="" e.science.biology.informatics.conductor=""> >>> >>> >> -- >> Computational Biology / Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N. >> PO Box 19024 Seattle, WA 98109 >> >> Location: Arnold Building M1 B861 >> Phone: (206) 667-2793 >> > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor
ADD REPLYlink written 4.5 years ago by Marc Carlson7.2k
Thanks, Marc. So it sounds almost trivial? to implement the select API on top of a data.frame, where there is a single keytype corresponding to the row names. We could make select, etc, methods for data.frame and/or DataFrame and then my simple use case would be easy to achieve. Or am I missing something? Michael On Thu, May 23, 2013 at 5:51 PM, Marc Carlson <mcarlson@fhcrc.org> wrote: > Hi Michael, > > As usual, Martin is on the right track. The new Schema .pdf stuff is only > if you really need the old school bimaps, and bimaps are not actually > needed for any of the OrganismDbi stuff. So the interface of keytypes, > cols, keys and select really ought to be enough to allow integration into > OrganismDbi... > > And, if you also followed the same org package DB schema that we use > everywhere else that would be ideal since in that case, you could just > recycle the methods we have already defined for OrgDb objects... So in > order to do that, a biomart equivalent to AnntotationForge:::**makeOrgDbFromNCBI() > and AnntotationForge:::**makeOrgPackageFromNCBI would be a nice addition. > > And I agree that a simple data.frame() based underlying implementation > would make this easier to generalize. Right now things are a bit > specialized for NCBI resources. > > > Marc > > > > > On 05/17/2013 09:56 PM, Michael Lawrence wrote: > >> Cool, thanks Martin. I'll wait for Marc to get back. If what you say is >> correct, it would be nice to have a simple data frame implementation. I'm >> getting the annotations from a biomart, so a biomart implementation would >> be ideal, although that might be tricky semantically. >> >> Michael >> >> >> >> >> On Fri, May 17, 2013 at 5:43 PM, Martin Morgan <mtmorgan@fhcrc.org> >> wrote: >> >> On 05/16/2013 01:50 PM, Michael Lawrence wrote: >>> >>> Hi, >>>> >>>> I'd like to create an OrganismDbi package so that I can put extra >>>> annotations on the transcripts/genes in a TxDb package. My understanding >>>> is >>>> that I need a separate database package that I can join with the TxDb >>>> package. Do I need to make an OrgDb package? I looked into this a bit >>>> and >>>> it seems that there is little support for making a non-NCBI-based org >>>> package. Maybe I could create a new type of package with a simple table >>>> with a row for each transcript, including the gene symbol and whether >>>> the >>>> transcript is "canonical" according to UCSC. It looks like this process >>>> is >>>> documented here: >>>> http://www.bioconductor.org/****packages/2.12/bioc/vignettes/**** <http: www.bioconductor.org="" **packages="" 2.12="" bioc="" vignettes="" **=""> >>>> AnnotationForge/inst/doc/****NewSchema.pdf<http: www.**="">>>> bioconductor.org/packages/2.**12/bioc/vignettes/** >>>> AnnotationForge/inst/doc/**NewSchema.pdf<http: www.bioconductor.="" org="" packages="" 2.12="" bioc="" vignettes="" annotationforge="" inst="" doc="" newschema.pd="" f=""> >>>> > >>>> >>>> . >>>> It also seems really involved. What's the path of least resistance here? >>>> >>>> Hi Michael -- Marc is away for a few days. I *think* the idea is that >>> the >>> details in NewSchema are no longer required, rather, implement your extra >>> data in any fashion to provide a 'select' interface, i.e., >>> >>> keytypes >>> keys >>> cols >>> select >>> >>> following the implied API of ?keytypes. Then create an OrgDb package with >>> >>> AnnotationDbi::****makeOrganismPackage >>> >>> >>> Sorry not to be more definitive in my help. >>> >>> Martin >>> >>> >>> Thanks, >>>> Michael >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________****_________________ >>>> Bioconductor mailing list >>>> Bioconductor@r-project.org >>>> https://stat.ethz.ch/mailman/****listinfo/bioconductor<https: st="" at.ethz.ch="" mailman="" **listinfo="" bioconductor=""> >>>> <https: **="" stat.ethz.ch="" mailman="" **listinfo="" bioconductor<https:="" s="" tat.ethz.ch="" mailman="" listinfo="" bioconductor=""> >>>> > >>>> Search the archives: http://news.gmane.org/gmane.** >>>> science.biology.informatics.****conductor<http: news.gmane.**="">>>> org/gmane.science.biology.**informatics.conductor<http: news.gma="" ne.org="" gmane.science.biology.informatics.conductor=""> >>>> > >>>> >>>> >>>> -- >>> Computational Biology / Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N. >>> PO Box 19024 Seattle, WA 98109 >>> >>> Location: Arnold Building M1 B861 >>> Phone: (206) 667-2793 >>> >>> [[alternative HTML version deleted]] >> >> ______________________________**_________________ >> Bioconductor mailing list >> Bioconductor@r-project.org >> https://stat.ethz.ch/mailman/**listinfo/bioconductor<https: stat.e="" thz.ch="" mailman="" listinfo="" bioconductor=""> >> Search the archives: http://news.gmane.org/gmane.** >> science.biology.informatics.**conductor<http: news.gmane.org="" gmane="" .science.biology.informatics.conductor=""> >> > > [[alternative HTML version deleted]]
ADD REPLYlink written 4.5 years ago by Michael Lawrence9.8k
Hi Michael, You could do it that way. As long as you made a new object type and wrote supporting methods that would work. And we designed it so that this could work, but I would still actually recommend another slightly different approach. My preference would be to make 1) a function that takes a named list of data.frames and generates a simple org database. (This is actually a pretty straightforward function to write). And then 2) another function to call that and wrap that DB in an org package (also straightforward). The reason for this, is that by writing these two functions, you would 1) get all the OrgDb objects methods for free since you would have made a package that creates an existing OrgDb object. (so no need to implement select and it's friends, and no need to introduce any new object types) and 2) We would maintain a consistent database schema with existing org packages. This would help prevent the unnecessary proliferation of DB schemas and associated methods. Those methods may be simple enough to implement, but it's really much better to not have to have to maintain multiple variations of them if you don't need to. The current schema for org packages is actually very simple and pretty general so it is almost trivial to make a DB of this kind. Of course, for this strategy to make any sense whatsoever, you need to have data the needs to at least resemble what is normally found in an org package. If your data is really very different from that, then your initial approach (which involves another supporting another different kind of object) could be more appropriate. Marc On 05/23/2013 09:54 PM, Michael Lawrence wrote: > Thanks, Marc. > > So it sounds almost trivial? to implement the select API on top of a > data.frame, where there is a single keytype corresponding to the row > names. We could make select, etc, methods for data.frame and/or > DataFrame and then my simple use case would be easy to achieve. > Or am I missing something? > > Michael > > > > On Thu, May 23, 2013 at 5:51 PM, Marc Carlson <mcarlson@fhcrc.org> <mailto:mcarlson@fhcrc.org>> wrote: > > Hi Michael, > > As usual, Martin is on the right track. The new Schema .pdf stuff > is only if you really need the old school bimaps, and bimaps are > not actually needed for any of the OrganismDbi stuff. So the > interface of keytypes, cols, keys and select really ought to be > enough to allow integration into OrganismDbi... > > And, if you also followed the same org package DB schema that we > use everywhere else that would be ideal since in that case, you > could just recycle the methods we have already defined for OrgDb > objects... So in order to do that, a biomart equivalent to > AnntotationForge:::makeOrgDbFromNCBI() and > AnntotationForge:::makeOrgPackageFromNCBI would be a nice addition. > > And I agree that a simple data.frame() based underlying > implementation would make this easier to generalize. Right now > things are a bit specialized for NCBI resources. > > > Marc > > > > > On 05/17/2013 09:56 PM, Michael Lawrence wrote: > > Cool, thanks Martin. I'll wait for Marc to get back. If what > you say is > correct, it would be nice to have a simple data frame > implementation. I'm > getting the annotations from a biomart, so a biomart > implementation would > be ideal, although that might be tricky semantically. > > Michael > > > > > On Fri, May 17, 2013 at 5:43 PM, Martin Morgan > <mtmorgan@fhcrc.org <mailto:mtmorgan@fhcrc.org="">> wrote: > > On 05/16/2013 01:50 PM, Michael Lawrence wrote: > > Hi, > > I'd like to create an OrganismDbi package so that I > can put extra > annotations on the transcripts/genes in a TxDb > package. My understanding > is > that I need a separate database package that I can > join with the TxDb > package. Do I need to make an OrgDb package? I looked > into this a bit and > it seems that there is little support for making a > non-NCBI-based org > package. Maybe I could create a new type of package > with a simple table > with a row for each transcript, including the gene > symbol and whether the > transcript is "canonical" according to UCSC. It looks > like this process is > documented here: > http://www.bioconductor.org/**packages/2.12/bioc/vignettes/** > AnnotationForge/inst/doc/**NewSchema.pdf<http: www.="" bioconductor.org="" packages="" 2.12="" bioc="" vignettes="" annotationforge="" inst="" doc="" newschema.pdf=""> > > > . > It also seems really involved. What's the path of > least resistance here? > > Hi Michael -- Marc is away for a few days. I *think* the > idea is that the > details in NewSchema are no longer required, rather, > implement your extra > data in any fashion to provide a 'select' interface, i.e., > > keytypes > keys > cols > select > > following the implied API of ?keytypes. Then create an > OrgDb package with > > AnnotationDbi::**makeOrganismPackage > > > Sorry not to be more definitive in my help. > > Martin > > > Thanks, > Michael > > [[alternative HTML version deleted]] > > ______________________________**_________________ > Bioconductor mailing list > Bioconductor@r-project.org > <mailto:bioconductor@r-project.org> > https://stat.ethz.ch/mailman/**listinfo/bioconductor <https: stat.ethz.ch="" mailman="" listinfo="" bioconductor=""> > Search the archives: http://news.gmane.org/gmane.** > science.biology.informatics.**conductor<http: news.="" gmane.org="" gmane.science.biology.informatics.conductor=""> > > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 <tel:%28206%29%20667-2793> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor@r-project.org <mailto:bioconductor@r-project.org> > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > > > [[alternative HTML version deleted]]
ADD REPLYlink written 4.5 years ago by Marc Carlson7.2k
My data are simply transcript identifiers, with the corresponding gene symbol. I just want to merge gene symbol information into the result from transcripts(), using our internal TxDb package. It would fit into an OrgDb package, but the OrgDb package might not be useful by itself (but maybe it would be for others around here). If you think it's straightforward (to what degree?) to create one from a list of data frames, please add support for it to AnnotationDbi or something. The NCBI-based stuff looks pretty complex. Thanks, Michael On Fri, May 24, 2013 at 2:29 PM, Marc Carlson <mcarlson@fhcrc.org> wrote: > Hi Michael, > > You could do it that way. As long as you made a new object type and wrote > supporting methods that would work. And we designed it so that this could > work, but I would still actually recommend another slightly different > approach. > > My preference would be to make 1) a function that takes a named list of > data.frames and generates a simple org database. (This is actually a > pretty straightforward function to write). And then 2) another function to > call that and wrap that DB in an org package (also straightforward). The > reason for this, is that by writing these two functions, you would 1) get > all the OrgDb objects methods for free since you would have made a package > that creates an existing OrgDb object. (so no need to implement select and > it's friends, and no need to introduce any new object types) and 2) We > would maintain a consistent database schema with existing org packages. > This would help prevent the unnecessary proliferation of DB schemas and > associated methods. Those methods may be simple enough to implement, but > it's really much better to not have to have to maintain multiple variations > of them if you don't need to. The current schema for org packages is > actually very simple and pretty general so it is almost trivial to make a > DB of this kind. > > Of course, for this strategy to make any sense whatsoever, you need to > have data the needs to at least resemble what is normally found in an org > package. If your data is really very different from that, then your > initial approach (which involves another supporting another different kind > of object) could be more appropriate. > > > Marc > > > > > On 05/23/2013 09:54 PM, Michael Lawrence wrote: > > Thanks, Marc. > > So it sounds almost trivial? to implement the select API on top of a > data.frame, where there is a single keytype corresponding to the row names. > We could make select, etc, methods for data.frame and/or DataFrame and then > my simple use case would be easy to achieve. > Or am I missing something? > > Michael > > > > On Thu, May 23, 2013 at 5:51 PM, Marc Carlson <mcarlson@fhcrc.org> wrote: > >> Hi Michael, >> >> As usual, Martin is on the right track. The new Schema .pdf stuff is >> only if you really need the old school bimaps, and bimaps are not actually >> needed for any of the OrganismDbi stuff. So the interface of keytypes, >> cols, keys and select really ought to be enough to allow integration into >> OrganismDbi... >> >> And, if you also followed the same org package DB schema that we use >> everywhere else that would be ideal since in that case, you could just >> recycle the methods we have already defined for OrgDb objects... So in >> order to do that, a biomart equivalent to >> AnntotationForge:::makeOrgDbFromNCBI() and >> AnntotationForge:::makeOrgPackageFromNCBI would be a nice addition. >> >> And I agree that a simple data.frame() based underlying implementation >> would make this easier to generalize. Right now things are a bit >> specialized for NCBI resources. >> >> >> Marc >> >> >> >> >> On 05/17/2013 09:56 PM, Michael Lawrence wrote: >> >>> Cool, thanks Martin. I'll wait for Marc to get back. If what you say is >>> correct, it would be nice to have a simple data frame implementation. I'm >>> getting the annotations from a biomart, so a biomart implementation would >>> be ideal, although that might be tricky semantically. >>> >>> Michael >>> >>> >>> >>> >>> On Fri, May 17, 2013 at 5:43 PM, Martin Morgan <mtmorgan@fhcrc.org> >>> wrote: >>> >>> On 05/16/2013 01:50 PM, Michael Lawrence wrote: >>>> >>>> Hi, >>>>> >>>>> I'd like to create an OrganismDbi package so that I can put extra >>>>> annotations on the transcripts/genes in a TxDb package. My >>>>> understanding >>>>> is >>>>> that I need a separate database package that I can join with the TxDb >>>>> package. Do I need to make an OrgDb package? I looked into this a bit >>>>> and >>>>> it seems that there is little support for making a non-NCBI- based org >>>>> package. Maybe I could create a new type of package with a simple table >>>>> with a row for each transcript, including the gene symbol and whether >>>>> the >>>>> transcript is "canonical" according to UCSC. It looks like this >>>>> process is >>>>> documented here: >>>>> http://www.bioconductor.org/**packages/2.12/bioc/vignettes/** >>>>> AnnotationForge/inst/doc/**NewSchema.pdf< >>>>> http://www.bioconductor.org/packages/2.12/bioc/vignettes/Annotat ionForge/inst/doc/NewSchema.pdf> >>>>> >>>>> >>>>> . >>>>> It also seems really involved. What's the path of least resistance >>>>> here? >>>>> >>>>> Hi Michael -- Marc is away for a few days. I *think* the idea is >>>> that the >>>> details in NewSchema are no longer required, rather, implement your >>>> extra >>>> data in any fashion to provide a 'select' interface, i.e., >>>> >>>> keytypes >>>> keys >>>> cols >>>> select >>>> >>>> following the implied API of ?keytypes. Then create an OrgDb package >>>> with >>>> >>>> AnnotationDbi::**makeOrganismPackage >>>> >>>> >>>> Sorry not to be more definitive in my help. >>>> >>>> Martin >>>> >>>> >>>> Thanks, >>>>> Michael >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> ______________________________**_________________ >>>>> Bioconductor mailing list >>>>> Bioconductor@r-project.org >>>>> https://stat.ethz.ch/mailman/**listinfo/bioconductor< >>>>> https://stat.ethz.ch/mailman/listinfo/bioconductor> >>>>> Search the archives: http://news.gmane.org/gmane.** >>>>> science.biology.informatics.**conductor< >>>>> http://news.gmane.org/gmane.science.biology.informatics.conductor> >>>>> >>>>> >>>>> -- >>>> Computational Biology / Fred Hutchinson Cancer Research Center >>>> 1100 Fairview Ave. N. >>>> PO Box 19024 Seattle, WA 98109 >>>> >>>> Location: Arnold Building M1 B861 >>>> Phone: (206) 667-2793 >>>> >>>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> Bioconductor mailing list >>> Bioconductor@r-project.org >>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>> Search the archives: >>> http://news.gmane.org/gmane.science.biology.informatics.conductor >>> >> >> > > [[alternative HTML version deleted]]
ADD REPLYlink written 4.5 years ago by Michael Lawrence9.8k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.2.0
Traffic: 380 users visited in the last hour