Dear Henry

Thank you for your e-mail. You raise some really good points about the
dangers of re-calibrating the iRT which I hadn't fully considered.

My use case is that raw data was acquired at another lab using a set of
index peptides that we do not use. I believe the spectrast library was
compiled using this index, so all RTs from multiple runs should be mapped
to a single iRT space. That iRT space is not the one we use to collect our
SWATH data. So I want to apply a regression to move from one iRT to the
biognosis iRT space.

I have found peptides shared between the new library and the Aebersold
"pan-human" library which is in the biognosis iRT space. So although the
biognosis iRT peptides are not present in new library I do have a set of
marker peptides along with their iRT score in biognosis iRT space. So I
think it would be legitimate to use these as markers.

I agree with you that this should not be attempted in a library in which
multiple runs and multiple sources have been combined without standardising
to an iRT space because run-run comparison is not possible. However I think
if an iRT standardisation was used with the original import then this kind
of transposition should be legitimate.

Would it be possible to enable this tool but through up an error if the
original library was not scaled to an iRT?

Best wishes

Matt





On Fri, 17 May 2019 at 02:29, Henry Lam <[email protected]> wrote:

> Matt,
>
> As the Wiki stated, this option -c_IRT only works when you import a
> pep.xml file. It does not work on an existing library (.splib).
>
> The reason is because the iRT values are computed by linear regression
> from real retention times of peptides IN THE SAME MS RUN, and the
> information about which MS run the spectrum comes from is already lost if
> you do not have the .pep.xml file.
>
> Although you might have used the same chromatography for all the data you
> used to generate this library, SpectraST is designed for the general use
> case where a spectral library is built from data acquired on many different
> setups (and potentially from downloaded data). A spectral library also
> might not record the real retention times (again depending on where the
> data comes from), or the retention times might have been some aggregate
> value of many different replicates (in the case of consensus spectra).
> Because of this, doing an iRT normalization on a spectral library is
> problematic and could lead to meaningless results. From my point of view, I
> would rather limit the functionality than risk producing questionable
> results that a researcher might unwittingly rely on to perform future
> experiments.
>
> May I ask what you put into newiRTfile.txt? Are they a new set of spike-in
> iRT peptides with their iRT values? And your .splib file already has iRT
> values (but computed from another set of spike-in iRT peptides)? If so,
> what you are trying to do is quite different from the intended use of this
> option. I suppose it could be a new feature to enable this kind of update
> from one iRT normalization to another, but it needs some thoughts how to do
> it right.
>
> If you want to get around this hurdle and do not mind some scripting, you
> can consider parsing the .sptxt file to get the old iRT values, do your own
> regression to calculate the new iRT values, and then replace the iRT values
> in the .sptxt file.  After the edit, you can re-import the .sptxt into a
> spectral library.
>
> Hope it helps,
>
> Henry
>
>
>
> On Thursday, May 16, 2019 at 10:38:46 PM UTC+8, Matthew Russell wrote:
>>
>> I am trying to update the iRT index in a pre-existing .splib file.
>> Unfortunatly I do not have access to the .pep.xml files initially used to
>> create the library and cannot build from them as documented.
>>
>> Ideally I would do:
>>
>> spectrast.exe -cNnewiRT_lib -c_IRTnewiRTfile.txt -cM old_iRT.splib
>>
>> Except of course that doesn't work as is clearly documented on
>> http://tools.proteomecenter.org/wiki/index.php?title=Software:SpectraST.
>>
>> Is there any work around to make this possible? IF there isn't is there
>> any way this could be made a feature?
>>
>> Thanks
>>
>> Best wishes
>>
>> Matt
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "spctools-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/spctools-discuss.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/spctools-discuss/f2e8d111-c1a1-4ade-ba98-95616b44abb5%40googlegroups.com
> <https://groups.google.com/d/msgid/spctools-discuss/f2e8d111-c1a1-4ade-ba98-95616b44abb5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"spctools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/spctools-discuss.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/spctools-discuss/CADOFuMGhB6wp7kRezEX6iAgjWfXWT8PyZh7f%2BXupme7r5HgHAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to