Menu
▾
▴
Re: [Samtools-help] stranded paired read standard
|
From: David J. <ja...@br...> - 2010-04-28 10:19:28
|
Gonçalo, Thank you. Your straw man seems sensible.... It might be better to create only a single mechanism for representing the transcription stand information, but there seem to be reasonable arguments for both mechanisms. Perhaps someone else who is involved with such data can comment (not me). Cheers, David ============================================================================================ On 4/27/10 12:40 PM, Goncalo Abecasis wrote: > Okay, here is a straw man: > > Tags to be added to read group in header: > > TP - Template RNA or DNA > TS - Transcription strand information available? Y/N > > Tags to be encoded in each read: > > TS:Z - Transcribed strand +/-/. > > If we are more ambitious, we could include logic in the header that allows a > program to use the alignment to deduce the per read TS tag using the > alignment. In principle this could be simple (there would be a map of 4 > values that translate strand from the two pairs into strand for the > transcript), but I am worried this map would only be valid for properly pair > reads after platform specific filtering or some such. > > In the interest of completing a strawman, this could be encoded as: > > TL - Transcription strand logic, 4 character string including only +, - > or . as valid characters. The four characters would correspond to the strand > that should be assigned to a proper pair that maps with +/+ (read 1 and 2 in > + strand), then +/- (read 2 in - strand), -/+ and -/-. If one or more of > these outcomes is not valid and does not provide valid strand information, > then a . should appear. > > Gonçalo > > > > > >> -----Original Message----- >> From: David Jaffe [mailto:ja...@br...] >> Sent: Tuesday, April 27, 2010 6:14 AM >> To: Brian Raney >> Cc: jro...@br...; sam...@li...; >> ASp...@il... >> Subject: Re: [Samtools-help] stranded paired read standard >> >> Brian, >> >> I don't think there's a problem with sorting and read groups. Perhaps >> someone who knows more about this could comment.... >> >> The BAM header should be able to capture the metadata. It is much >> better >> to have it in the header, in a standard form, rather than in a separate >> database. >> >> I strongly suspect that there are a bunch of groups that are generating >> transcriptional data just like you are generating. All that's needed >> are >> a tag or two in the readgroup header to appropriately represent the >> relevant metainfo. >> If someone were to provide a straw man, then folks could bounce it >> around >> and make sure it's right. >> >> Best, >> >> David >> >> ======================================================================= >> ============== >> >> On 4/25/10 3:31 PM, Brian Raney wrote: >>> Hey y'all, >>> >>> I'm a little concerned by the idea of using read-group to label both >>> transcription strand and expected insert size. Won't read groups get >>> busted up in a sorted BAM? >>> >>> I guess I'm with Richard Durbin when I plea to y'all to tell me how I >>> should label paired reads with transcription direction (as well as >>> expected insert size), rather than making me come up with ignorant >>> suggestions. At this point we have expected insert size as part of >>> the metadata for an experiment (i.e. recorded in a separate >> database), >>> and I'm starting to lean towards recording the innie/outie/collinear >>> status there as well since it seems like putting this in the BAM file >>> rocks more boats than it calms. >>> >>> brian >>> >>> On Sun, Apr 25, 2010 at 4:47 AM, David >> Jaffe<ja...@br...> wrote: >>>> This has to be the right way to do it. For paired reads, doesn't >> one also >>>> need to know which strand is read by the second read? There are >>>> technologies >>>> for which both reads in a pair are on the same strand. This >> additional >>>> information has nothing to do with transcription per se. >>>> >>>> David >>>> >>>> >> ======================================================================= >> =========== >>>> >>>> On 4/24/10 9:21 PM, Colin Hercus wrote: >>>>> >>>>> Hi Brian, >>>>> >>>>> Isn't the issue whether the sample prep preserved the direction of >>>>> transcription in the fragments, reversed it or maybe mixed it. And >> then >>>>> if the direction was preserved then alignment direction can tell >> you the >>>>> direction of transcription. So we just need to know at read group >>>>> whether transcription direction was preserved, inverted or mixed. >>>>> >>>>> Colin >>>>> >>>>> On Sun, Apr 25, 2010 at 1:59 AM, Brian Raney<br...@so... >>>>> <mailto:br...@so...>> wrote: >>>>> >>>>> Hey Keiran, >>>>> >>>>> I'm a little confused by this suggestion. In a sorted BAM, >> wouldn't >>>>> your suggestion require a new readgroup every time the next >> alignment >>>>> was for a fragment transcribed on a different strand than the >> previous >>>>> one? Or maybe you're suggesting that the readgroup header >> have >>>>> information about how analysis software should determine the >>>>> fragment's strand of transcription using the strand information >> from >>>>> the read mappings (i.e. the readgroup header would contain >> information >>>>> about whether the group used the innie or outie or colinear >>>>> standards)? >>>>> >>>>> brian >>>>> >>>>> On Sat, Apr 24, 2010 at 1:40 AM, Keiran Raine<kr...@sa... >>>>> <mailto:kr...@sa...>> wrote: >>>>> > This can already be encoded in the readgroup header. >>>>> > >>>>> > Regards, >>>>> > Keiran >>>>> > >>>>> > >>>>> > >>>>> >>>>> ----------------------------------------------------------------- >> ------------- >>>>> > >>>>> > _______________________________________________ >>>>> > Samtools-help mailing list >>>>> > Sam...@li... >>>>> <mailto:Sam...@li...> >>>>> > https://lists.sourceforge.net/lists/listinfo/samtools-help >>>>> > >>>>> > >>>>> >>>>> >>>>> ----------------------------------------------------------------- >> ------------- >>>>> _______________________________________________ >>>>> Samtools-help mailing list >>>>> Sam...@li... >>>>> <mailto:Sam...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/samtools-help >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >> ----------- >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Samtools-help mailing list >>>>> Sam...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/samtools-help >>>> >>>> >> >> >> ----------------------------------------------------------------------- >> ------- >> _______________________________________________ >> Samtools-help mailing list >> Sam...@li... >> https://lists.sourceforge.net/lists/listinfo/samtools-help >> > > |