[Bioc-devel] Base class for interaction data - expressions of interest
alun at wehi.edu.au
Sun Nov 8 20:31:41 CET 2015
Okay, some meat and bones are on GitHub now:
The idea is to represent genomic interactions as pairs of genomic
regions, using indices to point to a common GRanges object (a la Hits,
though I haven't used that explicitly due to the presence of additional
constraints on the indices). Data for each interaction is stored using a
SummarizedExperiment framework (one row per interaction).
With regards to the methods, most of the low-hanging fruit has been
implemented, courtesy of inheriting from SummarizedExperiment0. I'll add
proper unit tests over the coming week. It currently passes through R
CMD check okay, except for a warning about ":::" in the cbind/rbind
definitions (callNextMethod() didn't seem to work inside those methods,
and I didn't want to rewrite the SE0 'binding methods).
Any thoughts appreciated.
On 07/11/15 19:33, Morgan, Martin wrote:
> Just to say that this is a great idea. If this starts as a github package (or in svn, we can create a location for you if you'd like) I and others would I am sure be happy to try to provide any guidance / insight. The main design principles are probably to reuse as much as possible from existing classes, especially the S4Vectors / GRanges world, and to integrate metadata as appropriate (like SummarizedExepriment, for instance).
> From: Bioc-devel [bioc-devel-bounces at r-project.org] on behalf of Aaron Lun [alun at wehi.edu.au]
> Sent: Thursday, November 05, 2015 12:27 PM
> To: bioc-devel at r-project.org
> Subject: Re: [Bioc-devel] Base class for interaction data - expressions of interest
> There's a growing number of Bioconductor packages dealing with
> interaction data; diffHic, GenomicInteractions, HiTC, to name a few (and
> probably more in the future). Each of these packages defines its own
> class to store interaction data - DIList for diffHic,
> GenomicInteractions for GenomicInteractions, and HTClist for HiTC.
> These classes seem to share a lot of features, which suggests that they
> can be (easily?) replaced with a common class. This would have two
> advantages - one, developers of new and existing packages don't have to
> continually write and maintain new classes; and two, it provides users
> with a consistent user experience across the relevant packages.
> My question is, does anybody have anything in the pipeline with respect
> to a base package for an interaction class? If not, I'm planning to put
> something together for the next BioC release. To this end, I'd welcome
> any ideas/input/code; the aim is to make a drop-in replacement (insofar
> as that's possible) for the existing classes in each package.
> Bioc-devel at r-project.org mailing list
> 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.
More information about the Bioc-devel