On Thu, Dec 1, 2011 at 1:35 PM, Michael Lawrence
<lawrence.michael@gene.com>wrote:

>    There seems to be a need for more complex ways to detect/filter
>    overlaps of RNA read alignments with transcript annotations. These
>    could be implemented as new overlap types and/or as ways of
>    filtering RangesMatching objects.
>
>    Different types of filters:
>    * Compatible splicing, i.e., equal gaps
>    * Compatible on both ends, for paired end data
>    * Incompatible (inverse of above)
>    * Retained introns (read covers an intron, without a splice (gap) in the
>      same intron, i.e., read completely covers intron or a read end
>      starts/ends in the intron)
>
>
+1 for this clearly-stated idea.  When thinking about this, keep in mind
that chimeric (mapping to different chromosomes) reads and read pairs are
part of the mix.

Sean


>    It would seem the above would benefit somehow from a way of
>    representing paired end, spliced reads. GRangesList is close, but
>    there is no way to distinguish the insert gaps from the
>    others. Maybe the gap could be stored in an IRanges column in the
>    element metadata?
>
>    While things like countOverlaps and summarizeGenomicOverlaps
>    support a number of useful counting methods, it would be useful to
>    have some of those on RangesMatching, for the sake of efficiency.
>    Possible counting methods on RangesMatching:
>    * Counting number of hits for each query/subject (query count is
>      already available via as.table)
>    * Counting number of hits for each uniquely mapping query
>
>    At a slightly higher level, aggregating these (per transcript)
>    counts to the gene level (this is not a simple table(), because a
>    read should only be counted once for each gene, even if it hits
>    multiple transcripts).
>
>    Also, it would be useful to have set-style (union, intersect,
>    setdiff) operations on RangesMatching.
>
> Just putting this out here for discussion and maybe we (Herve?) can start
> working on at least the first suggestion, checking for splicing
> compatibility.
>
> Thanks,
> Michael
>
>        [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]

