Re: [Psidev-ms-dev] What to do about <RetentionTimeList>?

[Fredrik L. <fre...@im...>]

I tend to agree with C too (even if is the least pretty solution). For 
inclusion lists and exclusion lists, there are several examples when the 
compund is not known, and in those cases it makes more sense to specify 
local retention time under <target>. For example Hoopmann et al 2009 in JPR.
I cannot make the call today either.

cheers

Fredrik

Andreas Bertsch skrev:
> Hi all,
>
>   
>> one TraML issue that really does need to be solved is what to do about retention time.
>>  
>> Currently, we have a <RetentionTimeList> structure that I think is quite nice, but it can only live under <Peptide> or <Compound>. The thinking was that the retention time is really an attribute of a peptide or compound rather than a transition, and should therefore ride with those. We also felt good about this because if there are multiple transitions per peptide (a common occurrence I would say), we only need to specify the information once. The tricky use case is a simple transition list that has just Q1, Q3, RT and nothing else. Maybe we don’t even know what the peptide or compound is. One could encode that now by setting up fake peptides as containers of the RT information. The sequence is a required attribute, so one would need to assign a sequence (like “UNKNOWN” perhaps). One could also imagine some diabolical case where one would want to specify a longer retention time window for 1 transition than another, both from the same peptide. If we wanted to support this kind of a list, we could fix this by allowing <RetentionTimeList> under <Transition> as well or instead.
>>  
>> What do you think?
>> A) Keep as is and insist that if RT is specified, one must specify the peptide or compound (might require data generators to insert false <Peptide> placeholders when the true peptide/compound is not known or should not be divulged; one might argue that if this strange case applies, the list will likely be useless to anyone else, so why bother with TraML)
>> B) Move <RetentionTimeList> to <Transition> (increases flexibility for a few cases, but also increases redundancy in most cases)
>> C) Also allow <RetentionTimeList> under <Transition> (allows flexibility for the few cases, and does not increase redundancy, but requires more complex software logic to allow a <Transition> <RetentionTimeList> to override its possible associated <Peptide> <RetentionTimeList>)
>> And as touched on before, this same exact issue applies to the <Target> as well. It is even perhaps more problematic, because I would imagine that an inclusion list is even more likely to not have a known associated peptide than a transition. 
>> Comments?
>>     
> Even though, it complicates the software processing of the files, I would prefer C), because it truly allows the specification of own retention times (and also windows) for each of the entries (transitions or inclusions/exclusions). I can think of several cases where this might be useful. This solution also would allow "unknown" compounds to be encoded in TraML. (Even conversion from tsv/csv file formats to TraML would be possible!).
>
> Cheers,
> A.
>
>
>
>
> --
> Div. for Simulation of Biological Systems, WSI, University of Tuebingen
> Room C322, Sand 14, 72076 Tuebingen, Germany
> phone: +49-7071-29-70461 fax: +49-7071-29-5152
> http://www-bs.informatik.uni-tuebingen.de
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>