Okay, some meat and bones are on GitHub now: https://github.com/LTLA/InteractionSet
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. - Aaron 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). Martin ________________________________________ From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Aaron Lun [a...@wehi.edu.au] Sent: Thursday, November 05, 2015 12:27 PM To: bioc-devel@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. Cheers, Aaron _______________________________________________ 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.
_______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel