psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] CV param readability

[Kessner, D. E. <Dar...@cs...>]

I wasn't thinking about validation, since I'm ignoring the 'name'
attribute.  

This is solely a readability issue, for the mzML and for MSData client
code.


Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Joshua
Tasman
Sent: Wednesday, February 06, 2008 12:00 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] CV param readability

Hi Darren,

Speaking only for myself, I think that the "name" attribute should be
optional in the file and not interfere with validation.  I've never
understood why the text string needs to exactly match the CV for
validation; someone one the list had brought up other languages, etc.
But I think it came up on the list before, and requiring strict mapping
between accession numbers and text string seemed to be important for the
format.  

At the least, acronyms would require additional 'mapping files' or
something similar to be added to the specification, and the validator to
be updated.  Maybe someone more familiar with these tasks could step in.
Maybe the CV could be expanded so that every entry had an additional
"acronym" field.  This brings up other questions, like would uniqueness
be enforced, etc?

Josh


Kessner, Darren E. wrote:
> I would like to propose using standard acronyms in the CV term names 
> when it is clear what they mean.
> 
>  
> 
> We currently have:
> 
> <cvParam cvLabel="MS" accession="MS:1000075" name="matrix assisted
laser 
> desorption ionization" value=""/>
> 
> <cvParam cvLabel="MS" accession="MS:1000079" name="fourier transform
ion 
> cyclotron resonance mass spectrometer" value=""/>
> 
>  
> 
> I think this is more readable:
> 
> <cvParam cvLabel="MS" accession="MS:1000075" name="MALDI" value=""/>
> 
> <cvParam cvLabel="MS" accession="MS:1000079" name="FT-ICR MS"
value=""/>
> 
>  
> 
> The full name can still be available in the term description field.
> 
>  
> 
> I have an ulterior motive for this -- in the code generation of the 
> MSData library, the above terms become constants:
> 
>     MS_matrix_assisted_laser_desorption_ionization = 1000075,
> 
>     MS_fourier_transform_ion_cyclotron_resonance_mass_spectrometer = 
> 1000079,
> 
>  
> 
> But I think the following is more programmer-friendly:
> 
>     MS_MALDI = 1000075,
> 
>     MS_FT_ICR_MS = 1000079,
> 
>  
> 
>  
> 
>  
> 
> Darren
> 
>  
> 
>  
> 
>  
> 
> Darren Kessner
> 
> Scientific Programmer
> 
> Dar...@cs... <mailto:Dar...@cs...>
> 
> 310-423-9538
> 
>  
> 
> Spielberg Family Center for Applied Proteomics
> 
> Cedars-Sinai Medical Center
> 
> http://www.sfcap.cshs.org/
> 
>  
> 
>  
> 
> IMPORTANT WARNING: This message is intended for the use of the person
or 
> entity to which it is addressed and may contain information that is 
> privileged and confidential, the disclosure of which is governed by
> applicable law. If the reader of this message is not the intended 
> recipient, or the employee or agent responsible for delivering it to
the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this information is STRICTLY PROHIBITED.
> 
> If you have received this message in error, please notify us
immediately
> by calling (310) 423-6428 and destroy the related message. Thank You
for 
> your cooperation.
> 
> 
>
------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] CV param readability

[Matthew C. <mat...@va...>]

The OBO has "exact_synonyms" like this:

[Term]
id: MS:1000079
name: fourier transform ion cyclotron resonance mass spectrometer
def: "A mass spectrometer based on the principle of ion cyclotron resonance in which an ion in a magnetic field moves in a circular orbit at a frequency characteristic of its m/z value. Ions are coherently excited to a larger radius orbit using a pulse of radio frequency energy and their image charge is detected on receiver plates as a time domain signal. Fourier transformation of the time domain signal results in a frequency domain signal which is converted to a mass spectrum based in the inverse relationship between frequency and m/z." [PSI:MS]
exact_synonym: "FT_ICR" []
is_a: MS:1000443 ! mass analyzer type

Darren, I suggest you parse both the term name and its synonyms into a set for that term, and choose from it the shortest string to put in the enum. :)

-Matt


Joshua Tasman wrote:
> Hi Darren,
>
> Speaking only for myself, I think that the "name" attribute should be optional in the file and not interfere with validation.  I've never understood why the text string needs to exactly match the CV for validation; someone one the list had brought up other languages, etc.  But I think it came up on the list before, and requiring strict mapping between accession numbers and text string seemed to be important for the format.  
>
> At the least, acronyms would require additional 'mapping files' or something similar to be added to the specification, and the validator to be updated.  Maybe someone more familiar with these tasks could step in.  Maybe the CV could be expanded so that every entry had an additional "acronym" field.  This brings up other questions, like would uniqueness be enforced, etc?
>
> Josh
>
>
> Kessner, Darren E. wrote:
>   
>> I would like to propose using standard acronyms in the CV term names 
>> when it is clear what they mean.
>>
>>  
>>
>> We currently have:
>>
>> <cvParam cvLabel="MS" accession="MS:1000075" name="matrix assisted laser 
>> desorption ionization" value=""/>
>>
>> <cvParam cvLabel="MS" accession="MS:1000079" name="fourier transform ion 
>> cyclotron resonance mass spectrometer" value=""/>
>>
>>  
>>
>> I think this is more readable:
>>
>> <cvParam cvLabel="MS" accession="MS:1000075" name="MALDI" value=""/>
>>
>> <cvParam cvLabel="MS" accession="MS:1000079" name="FT-ICR MS" value=""/>
>>
>>  
>>
>> The full name can still be available in the term description field.
>>
>>  
>>
>> I have an ulterior motive for this -- in the code generation of the 
>> MSData library, the above terms become constants:
>>
>>     MS_matrix_assisted_laser_desorption_ionization = 1000075,
>>
>>     MS_fourier_transform_ion_cyclotron_resonance_mass_spectrometer = 
>> 1000079,
>>
>>  
>>
>> But I think the following is more programmer-friendly:
>>
>>     MS_MALDI = 1000075,
>>
>>     MS_FT_ICR_MS = 1000079,
>>
>>  
>>
>>  
>>
>>  
>>
>> Darren
>>
>>  
>>
>>  
>>
>>  
>>
>> Darren Kessner
>>
>> Scientific Programmer
>>
>> Dar...@cs... <mailto:Dar...@cs...>
>>
>> 310-423-9538
>>
>>  
>>
>> Spielberg Family Center for Applied Proteomics
>>
>> Cedars-Sinai Medical Center
>>
>> http://www.sfcap.cshs.org/
>>
>>  
>>
>>  
>>
>> IMPORTANT WARNING: This message is intended for the use of the person or 
>> entity to which it is addressed and may contain information that is 
>> privileged and confidential, the disclosure of which is governed by
>> applicable law. If the reader of this message is not the intended 
>> recipient, or the employee or agent responsible for delivering it to the 
>> intended recipient, you are hereby notified that any dissemination, 
>> distribution or copying of this information is STRICTLY PROHIBITED.
>>
>> If you have received this message in error, please notify us immediately
>> by calling (310) 423-6428 and destroy the related message. Thank You for 
>> your cooperation.
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
>   

Re: [Psidev-ms-dev] CV param readability

[Rune S. P. <mai...@ph...>]

Kessner, Darren E. skrev:
>
> I would like to propose using standard acronyms in the CV term names 
> when it is clear what they mean.
>

Aren't there already support for synonyms in the CV.
So shouldn't this already be allowed?

--
Regards
Rune

Re: [Psidev-ms-dev] CV param readability

[Joshua T. <jt...@sy...>]

Hi Darren,

Speaking only for myself, I think that the "name" attribute should be optional in the file and not interfere with validation.  I've never understood why the text string needs to exactly match the CV for validation; someone one the list had brought up other languages, etc.  But I think it came up on the list before, and requiring strict mapping between accession numbers and text string seemed to be important for the format.  

At the least, acronyms would require additional 'mapping files' or something similar to be added to the specification, and the validator to be updated.  Maybe someone more familiar with these tasks could step in.  Maybe the CV could be expanded so that every entry had an additional "acronym" field.  This brings up other questions, like would uniqueness be enforced, etc?

Josh


Kessner, Darren E. wrote:
> I would like to propose using standard acronyms in the CV term names 
> when it is clear what they mean.
> 
>  
> 
> We currently have:
> 
> <cvParam cvLabel="MS" accession="MS:1000075" name="matrix assisted laser 
> desorption ionization" value=""/>
> 
> <cvParam cvLabel="MS" accession="MS:1000079" name="fourier transform ion 
> cyclotron resonance mass spectrometer" value=""/>
> 
>  
> 
> I think this is more readable:
> 
> <cvParam cvLabel="MS" accession="MS:1000075" name="MALDI" value=""/>
> 
> <cvParam cvLabel="MS" accession="MS:1000079" name="FT-ICR MS" value=""/>
> 
>  
> 
> The full name can still be available in the term description field.
> 
>  
> 
> I have an ulterior motive for this -- in the code generation of the 
> MSData library, the above terms become constants:
> 
>     MS_matrix_assisted_laser_desorption_ionization = 1000075,
> 
>     MS_fourier_transform_ion_cyclotron_resonance_mass_spectrometer = 
> 1000079,
> 
>  
> 
> But I think the following is more programmer-friendly:
> 
>     MS_MALDI = 1000075,
> 
>     MS_FT_ICR_MS = 1000079,
> 
>  
> 
>  
> 
>  
> 
> Darren
> 
>  
> 
>  
> 
>  
> 
> Darren Kessner
> 
> Scientific Programmer
> 
> Dar...@cs... <mailto:Dar...@cs...>
> 
> 310-423-9538
> 
>  
> 
> Spielberg Family Center for Applied Proteomics
> 
> Cedars-Sinai Medical Center
> 
> http://www.sfcap.cshs.org/
> 
>  
> 
>  
> 
> IMPORTANT WARNING: This message is intended for the use of the person or 
> entity to which it is addressed and may contain information that is 
> privileged and confidential, the disclosure of which is governed by
> applicable law. If the reader of this message is not the intended 
> recipient, or the employee or agent responsible for delivering it to the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this information is STRICTLY PROHIBITED.
> 
> If you have received this message in error, please notify us immediately
> by calling (310) 423-6428 and destroy the related message. Thank You for 
> your cooperation.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Joshua T. <jt...@sy...>]

I'm with Matt on this one, and like his solution.  There are unfortunately lots of real use cases (combining dta, mgfs) where the information will really be unknown, and we should accurately represent the lack of information.  If it's not too much effort to add a little more code to the validator, I would much prefer the accurate addition of an "unknown" term.  There has been so much effort getting the CV and document to line up with reality, it looks very strange to me to force this ontological 'hack' by allowing the category to appear as a value, as Matt has said.

Josh


Matthew Chambers wrote:
> Lennart Martens wrote:
>> Hi Matt, and Colleagues,
>>
>>
>>   
>>> I don't really prefer one to the other very much, but I don't see how 
>>> the parent term would be easier to validate ("all but X children of a 
>>> term" doesn't make sense to me, do you mean "all children of a term 
>>> except X"?)
>>>     
>> You are right; I provided bad shorthand for: 'all children of a term, 
>> except X (and Y, and Z, ... -- potentially).
>>
>> The reason why it it is easier to validate is due to the way the 
>> validator mapping file is designed, e.g. (example verbatim from current 
>> 0.99.1 mapping file):
>>
>> 	    <CvTerm termAccession="MS:1000031" useTerm="false" 
>> termName="instrument model" isRepeatable="false" 
>> scope="/mzML/instrumentList/instrument" allowChildren="true" 
>> cvIdentifier="MS"></CvTerm>
>>
>> this means that although all children of term 'MS:1000031 -- instrument 
>> model' are allowed (allowChildren="true"), the term itself is not 
>> allowed (useTerm="false"). By flipping this latter boolean, we can allow 
>> the parent term, thus separating between MIAPE requirements (current 
>> configuration) and the 'usable mzML requirements' (flipped boolean as 
>> explained above) -- for the instrument model at least.
>>   
> OK, so it's an implementation thing. That's fine.
> 
>>> What about data converted from DTAs or MGFs 
>>> where the user doesn't even remember (or never knew) what kind of 
>>> instrument it came from?
>>>     
>> When the instrument is really unknown (which is unfortunate and 
>> constitutes dramatic metadata loss whichever way you look at it), the 
>> proposed scenario (usage of toplevel term) provides solace. For all 
>> other scenarios (where an incentive to adapt convertor software or 
>> report the development of a new instrument is concerned), the relative 
>> obscurity of the 'fix' might contribute to 'going the extra mile' 
>> (upgrading the convertor, mailing in the new instrument name).
>>   
> While the toplevel term does provide some solace, it is obscure enough 
> that a casual user might look at it and think that something was wrong 
> because it does not intuitively make sense for the category to appear as 
> a value. What about this alternative: provide an "unknown instrument" 
> term with a unique accession #, but make the term name something like 
> "unknown (instrument type not specified or not in CV)". That would be 
> intuitive but still eye-catching (and it would be the eye-catching part 
> that implementors would want to minimize, because it makes them look 
> bad). ;)
> 
> -Matt
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] CV param readability

[Kessner, D. E. <Dar...@cs...>]

I would like to propose using standard acronyms in the CV term names
when it is clear what they mean.

 

We currently have:

<cvParam cvLabel="MS" accession="MS:1000075" name="matrix assisted laser
desorption ionization" value=""/>

<cvParam cvLabel="MS" accession="MS:1000079" name="fourier transform ion
cyclotron resonance mass spectrometer" value=""/>

 

I think this is more readable:

<cvParam cvLabel="MS" accession="MS:1000075" name="MALDI" value=""/>

<cvParam cvLabel="MS" accession="MS:1000079" name="FT-ICR MS" value=""/>

 

The full name can still be available in the term description field.

 

I have an ulterior motive for this -- in the code generation of the
MSData library, the above terms become constants:

    MS_matrix_assisted_laser_desorption_ionization = 1000075,

    MS_fourier_transform_ion_cyclotron_resonance_mass_spectrometer =
1000079,

 

But I think the following is more programmer-friendly:

    MS_MALDI = 1000075,

    MS_FT_ICR_MS = 1000079,

 

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] binaryArrayData lengths

[Angel P. <an...@ma...>]

On Feb 6, 2008 1:49 PM, Matthew Chambers <mat...@va...>
wrote:

> I agree that the primary data arrays should probably be treated as
> special in the schema so it's clear that they are paired values and thus
> peak count could move into the spectrum element or spectrumDescription.
> There should still be options to have additional arrays that aren't the
> same as the main arrays (for example, an additional set of arrays, one
> for a subset of the m/zs and the other for peak charge information).
>

Hi Matt and Darren,

First thanks for all the feedback over the last year.  I don't think I have
ever expressed my gratitude.

As for this issue of length of binary arrays, again I ask that the hardware
vendors speak on this. Your example of a subset of peaks and charge states
seems to me like the raw data went through some process to get that subset
or to determine charge, hence this should be a new mzML file. Just my 2¢

-angel

Re: [Psidev-ms-dev] binaryArrayData lengths

[Matthew C. <mat...@va...>]

I agree that the primary data arrays should probably be treated as 
special in the schema so it's clear that they are paired values and thus 
peak count could move into the spectrum element or spectrumDescription. 
There should still be options to have additional arrays that aren't the 
same as the main arrays (for example, an additional set of arrays, one 
for a subset of the m/zs and the other for peak charge information).

-Matt


Kessner, Darren E. wrote:
> Any other comments regarding <binaryArrayData> lengths?
>
>   
>> (from Rune)
>> If they have to be equal size, then 
>> that size ought to be specified in the spectrumDescription.
>>     
>
> I agree -- I would like to encode the length in <spectrum> somewhere
> (either attribute or cvParam) so that:
> 1) it's clear that the arrays are of equal size
> 2) Readers don't have to peek into the attributes of the first
> <binaryArrayData> to get the info
>
> I need this right now for the MSData RAMP adapter code, so I'll encode
> it as a <userParam> until a decision has been made on the specification.
>
>
> Darren

Re: [Psidev-ms-dev] binaryArrayData lengths

[Kessner, D. E. <Dar...@cs...>]

Any other comments regarding <binaryArrayData> lengths?

> (from Rune)
> If they have to be equal size, then 
> that size ought to be specified in the spectrumDescription.

I agree -- I would like to encode the length in <spectrum> somewhere
(either attribute or cvParam) so that:
1) it's clear that the arrays are of equal size
2) Readers don't have to peek into the attributes of the first
<binaryArrayData> to get the info

I need this right now for the MSData RAMP adapter code, so I'll encode
it as a <userParam> until a decision has been made on the specification.


Darren



IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Matthew C. <mat...@va...>]

Lennart Martens wrote:
> Hi Matt, and Colleagues,
>
>
>   
>> I don't really prefer one to the other very much, but I don't see how 
>> the parent term would be easier to validate ("all but X children of a 
>> term" doesn't make sense to me, do you mean "all children of a term 
>> except X"?)
>>     
>
> You are right; I provided bad shorthand for: 'all children of a term, 
> except X (and Y, and Z, ... -- potentially).
>
> The reason why it it is easier to validate is due to the way the 
> validator mapping file is designed, e.g. (example verbatim from current 
> 0.99.1 mapping file):
>
> 	    <CvTerm termAccession="MS:1000031" useTerm="false" 
> termName="instrument model" isRepeatable="false" 
> scope="/mzML/instrumentList/instrument" allowChildren="true" 
> cvIdentifier="MS"></CvTerm>
>
> this means that although all children of term 'MS:1000031 -- instrument 
> model' are allowed (allowChildren="true"), the term itself is not 
> allowed (useTerm="false"). By flipping this latter boolean, we can allow 
> the parent term, thus separating between MIAPE requirements (current 
> configuration) and the 'usable mzML requirements' (flipped boolean as 
> explained above) -- for the instrument model at least.
>   
OK, so it's an implementation thing. That's fine.

>> What about data converted from DTAs or MGFs 
>> where the user doesn't even remember (or never knew) what kind of 
>> instrument it came from?
>>     
>
> When the instrument is really unknown (which is unfortunate and 
> constitutes dramatic metadata loss whichever way you look at it), the 
> proposed scenario (usage of toplevel term) provides solace. For all 
> other scenarios (where an incentive to adapt convertor software or 
> report the development of a new instrument is concerned), the relative 
> obscurity of the 'fix' might contribute to 'going the extra mile' 
> (upgrading the convertor, mailing in the new instrument name).
>   
While the toplevel term does provide some solace, it is obscure enough 
that a casual user might look at it and think that something was wrong 
because it does not intuitively make sense for the category to appear as 
a value. What about this alternative: provide an "unknown instrument" 
term with a unique accession #, but make the term name something like 
"unknown (instrument type not specified or not in CV)". That would be 
intuitive but still eye-catching (and it would be the eye-catching part 
that implementors would want to minimize, because it makes them look 
bad). ;)

-Matt

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Lennart M. <len...@eb...>]

Hi Matt, and Colleagues,


> I don't really prefer one to the other very much, but I don't see how 
> the parent term would be easier to validate ("all but X children of a 
> term" doesn't make sense to me, do you mean "all children of a term 
> except X"?)

You are right; I provided bad shorthand for: 'all children of a term, 
except X (and Y, and Z, ... -- potentially).

The reason why it it is easier to validate is due to the way the 
validator mapping file is designed, e.g. (example verbatim from current 
0.99.1 mapping file):

	    <CvTerm termAccession="MS:1000031" useTerm="false" 
termName="instrument model" isRepeatable="false" 
scope="/mzML/instrumentList/instrument" allowChildren="true" 
cvIdentifier="MS"></CvTerm>

this means that although all children of term 'MS:1000031 -- instrument 
model' are allowed (allowChildren="true"), the term itself is not 
allowed (useTerm="false"). By flipping this latter boolean, we can allow 
the parent term, thus separating between MIAPE requirements (current 
configuration) and the 'usable mzML requirements' (flipped boolean as 
explained above) -- for the instrument model at least.

> and I don't see it so much as an "expert feature" as a 
> (slightly) obfuscated one.

You have seen straight through my euphemism :). But it is important to 
note that this is not intentionally obfuscated -- it will be in the spec 
doc after all.

> What about data converted from DTAs or MGFs 
> where the user doesn't even remember (or never knew) what kind of 
> instrument it came from?

When the instrument is really unknown (which is unfortunate and 
constitutes dramatic metadata loss whichever way you look at it), the 
proposed scenario (usage of toplevel term) provides solace. For all 
other scenarios (where an incentive to adapt convertor software or 
report the development of a new instrument is concerned), the relative 
obscurity of the 'fix' might contribute to 'going the extra mile' 
(upgrading the convertor, mailing in the new instrument name).

Hope this further clarifies my thoughts,


Cheers,

lnnrt.

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Matthew C. <mat...@va...>]

I don't really prefer one to the other very much, but I don't see how 
the parent term would be easier to validate ("all but X children of a 
term" doesn't make sense to me, do you mean "all children of a term 
except X"?) and I don't see it so much as an "expert feature" as a 
(slightly) obfuscated one. What about data converted from DTAs or MGFs 
where the user doesn't even remember (or never knew) what kind of 
instrument it came from?

-Matt


Lennart Martens wrote:
> Dear PSI-MS Enthousiasts,
>
>
> After Tuesdays (5 Feb 2008) phone conference, I've given the addition of 
> an 'unknown instrument' term some further thought, since it made me feel 
> ever so slightly uncomfortable to add this 'escape hatch' to the CV.
>
> Upon consulting with Luisa Montecchi about this, she suggested a 
> potentially viable alternative: why not simply use the top-level CV term 
> instead? So whenever the actual instrument model is not known, we would 
> annotate as 'MS:1000031 -- instrument model'.
>
> I see two benefits in this approach:
>
>   1) no need to include a term called 'unknown instrument' in the CV, 
> which to me at least feels a bit awkward;
>   2) the validator can cope easily with allowing/disallowing this parent 
> term while allowing all children regardless, whereas allowing all but X 
> children of a term (as we would have to do in the case of adding an 
> 'unknown instrument' child term to 'instrument model') is possible, but 
> ugly.
>
>
> There is also a downside to this approach -- which I will also try to 
> subvert into an upside :)
>
>   the knowledge that the top-level term is to be used for 'unknown 
> instrument' will be documented in the spec doc, but it is likely that 
> few people will read this document in earnest. So the ability to flag an 
> instrument as 'unknown' will be an 'expert feature' only. The upside of 
> this is that it provides a ready incentive to convertor implementers and 
>   instrument manufacturers to go the very short extra distance to 
> accommodate (interactive) user input of the instrument, or addition of 
> the new instrument model to the CV, respectively. Interestingly, 
> enabling/encouraging both of these solutions were actually raised as 
> important points during the phone conference.
>
>
> What are your opinions on this proposal?
>
>
> Cheers,
>
> lnnrt.
>
>
>   

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Mike C. <tu...@gm...>]

On Feb 6, 2008 9:48 AM, Lennart Martens <len...@eb...> wrote:
>   the knowledge that the top-level term is to be used for 'unknown
> instrument' will be documented in the spec doc, but it is likely that
> few people will read this document in earnest.

Indeed.  I suspect that a significant number of users will be reading
mzML without carefully studying the spec, and without bothering with
the CV (or having an up-to-date CV), with the simple goal of
extracting the basic spectra (parent mass, charge, peaks).  I hope
that this will basically work.  If there are any potential problems
with this, it might be worth considering whether they can be
mitigated.

As for your question, I don't really have an opinion--I'm afraid I
don't have time at the moment to study the spec...  :-)

Mike

Re: [Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Angel P. <an...@ma...>]

On Feb 6, 2008 10:48 AM, Lennart Martens <len...@eb...> wrote:

> potentially viable alternative: why not simply use the top-level CV term
> instead? So whenever the actual instrument model is not known, we would
> annotate as 'MS:1000031 -- instrument model'.
>

I like it. -angel

[Psidev-ms-dev] Some additional 'Unknown instrument' CV parameter thoughts

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


After Tuesdays (5 Feb 2008) phone conference, I've given the addition of 
an 'unknown instrument' term some further thought, since it made me feel 
ever so slightly uncomfortable to add this 'escape hatch' to the CV.

Upon consulting with Luisa Montecchi about this, she suggested a 
potentially viable alternative: why not simply use the top-level CV term 
instead? So whenever the actual instrument model is not known, we would 
annotate as 'MS:1000031 -- instrument model'.

I see two benefits in this approach:

  1) no need to include a term called 'unknown instrument' in the CV, 
which to me at least feels a bit awkward;
  2) the validator can cope easily with allowing/disallowing this parent 
term while allowing all children regardless, whereas allowing all but X 
children of a term (as we would have to do in the case of adding an 
'unknown instrument' child term to 'instrument model') is possible, but 
ugly.


There is also a downside to this approach -- which I will also try to 
subvert into an upside :)

  the knowledge that the top-level term is to be used for 'unknown 
instrument' will be documented in the spec doc, but it is likely that 
few people will read this document in earnest. So the ability to flag an 
instrument as 'unknown' will be an 'expert feature' only. The upside of 
this is that it provides a ready incentive to convertor implementers and 
  instrument manufacturers to go the very short extra distance to 
accommodate (interactive) user input of the instrument, or addition of 
the new instrument model to the CV, respectively. Interestingly, 
enabling/encouraging both of these solutions were actually raised as 
important points during the phone conference.


What are your opinions on this proposal?


Cheers,

lnnrt.

[Psidev-ms-dev] Some comments on the mzML schema from today's call

[Randy J. <rkj...@in...>]

There are a couple of questions regarding the schema following today's
teleconference:

 

1.	spectrumDescription is currently marked as a required element,
but it has no required attributes, or sub-elements.  This should
probably be made optional if we keep the current optional status on all
the elements below it.
2.	The required attribute 'scanNumber' within <spectrum> seems
redundant with <scan> under spectrumDescription (maybe not - see my
comment below).
3.	Both scanNumber and msLevel have been moved far up in the
hierarchy and are required - they should be lower and msLevel should be
optional.

 

If we make a change to the <spectrum> element and remove scanNumber (and
use the element <scan> instead), and make msLevel either optional, or an
attribute or a cvParam somewhere, then we could use cvParams to name the
data vectors and allow for analog channels, UV channels and even PDA
data (I know, I sound like a broken record here).

 

Maybe I just missed something, but the original purpose of the
acquisitionList was to allow for a spectrum to be the sum or average of
a collection (list, ranges, etc) of individual spectra, each of which
has some of the attributes of the current <scan> element.  What is the
value in having both the <acquisition> element and the <scan> element?
Can they be combined?

 

Thanks,

Randy 

 

Randall K Julian, Jr. Ph.D.
President
Indigo BioSystems,  Inc.
(317) 536-2736 x101
(317) 306-5447 mobile

www.indigobio.com <http://www.indigobio.com/> 

NOTICE: This message may contain confidential or privileged information
that is for the sole use of the intended recipient. Any unauthorized
review, use, disclosure, copying or distribution is strictly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.

 

Re: [Psidev-ms-dev] PSI-MS WG phone conference, Tues, Feb 5 2008

[Eric D. <ede...@sy...>]

Reminder, conf call in 1 hr:

phone numbers are:
+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)
access code: 297427

09:00 San Francisco
12:00 New York
17:00 London (GMT)
18:00 Europe


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Lennart Martens
> Sent: Friday, February 01, 2008 2:23 AM
> To: Mass spectrometry standard development
> Subject: [Psidev-ms-dev] PSI-MS WG phone conference, Tues, Feb 5 2008
> 
> Dear PSI-MS enthousiasts,
> 
> The details for the PSI-MS phone conference are given below:
> 
> The phone conference will take place at the time indicated below
(please
> find a location near you ):
> 
>
http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=2&year=
20
> 08&hour=17&min=0&sec=0&p1=136
> 
> phone numbers are:
> + Germany: 08001012079
> + Switzerland: 0800000860
> + UK: 08081095644
> + USA: 1-866-314-3683
> + Generic international: +44 2083222500 (UK number)
> access code: 297427
> 
> Cheers,
> 
> lnnrt.
> 
> 
> Eric Deutsch wrote:
> > Hi everyone, the mzML reviews are back. Thank you to Norman Paton
and
> > the anonymous reviewers. I have pasted the reviews below for your
> > perusal if you are interested. I hope everyone can devote a little
time
> > in the next month to making another (and hopefully final) push to
get
> > mzML finished. I would like to propose a telephone conference in a
week:
> >
> >
> > Tuesday February 5:
> >
> > 09:00 San Francisco
> > 12:00 New York
> > 17:00 London (GMT)
> > 18:00 Europe
> 
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] binaryArrayData lengths

[Rune S. P. <mai...@ph...>]

Kessner, Darren E. wrote:
>
> So the question is, can there be <binaryDataArray> elements with 
> different arrayLengths in the same <spectrum>?  If not, this should be 
> in the specification. 
>

It easily makes sense how the different arrays works together if they 
are equal length.
Without a specified way to interpret different sized arrays, they have 
to be equal size.
If they have to be equal size, then that size ought to be specified in 
the spectrumDescription.

I can see why some of the arrays might not have to be the same size.
For instance, often you don't know the charges of all the peaks.
However, it is impossible to interpret such an array, without a clearly 
specified way of encoding which charges belong to which m/z values.

By the way, what data is the time array supposed to be used for?


--
With regards
Rune

[Psidev-ms-dev] Latest MSData package

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

We have a new MSData package available for your perusal.  Basic mzXML
reading/writing has been added -- all the scan handling works, but some
of the meta-data translation has not been implemented.

 

There are a few sample programs using the MSData library, in
pwiz/pwiz/msdata_tools:

 

hello_msdata:  writes an MSData object from memory to mzML and mzXML

hello_ramp:  example of the RAMPAdapter interface

msdiff:  comparison of two files (either file can be mzML or mzXML, '-i'
ignores meta-data and just compares scan data)

msconvert:  general conversion utility (mzML <-> mzXML at the moment)

 

http://www.sfcap.cshs.org/private/pwiz_src_msdata_080204.zip

 

login: psidev

password: pwiz

 

Latest legal update from Parag:

"We have approval to release this under the apache license pending
approval from our risk management division which has to add it to some
list in case someone decides to sue us for using it..."

 

Comments and suggestions, and especially bug reports, are welcome.

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] binaryArrayData lengths

[Angel P. <an...@ma...>]

On Feb 4, 2008 7:08 PM, Kessner, Darren E. <Dar...@cs...> wrote:

>
> So the question is, can there be <binaryDataArray> elements with different
> arrayLengths in the same <spectrum>?  If not, this should be in the
> specification.
>
> I would punt this question to the hardware guys. Anyone? -angel

>
>

[Psidev-ms-dev] binaryArrayData lengths

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

Brian Pratt and I are working together on plugging the MSData library
into RAMP, to allow the TPP tools to handle mzML.  We came across
something that should probably be mentioned in the specification.

 

There can be (and usually are) multiple <binaryDataArray> elements in a
<spectrum> (e.g. one for m/z values, one for intensity values):

 

<spectrum>

  <spectrumDescription>

    ...

  </spectrumDescription>

  <binaryDataArray arrayLength="1000" ...>

    <cvParam cvLabel="MS" accession="MS:1000514" name="m/z array"
value=""/>

    <binary> ... </binary>

  </binaryDataArray>

  <binaryDataArray arrayLength="1000" ...>

    <cvParam cvLabel="MS" accession="MS:1000515" name="intensity array"
value=""/>

    <binary> ... </binary>

  </binaryDataArray>

</spectrum>

 

Readers (like MSData) want to be able to read the scan meta-data (i.e.
<spectrum> up to the first <binaryDataArray> tag) without having to read
and decode the binary data.  Part of this scan meta-data is the size of
the binaryDataArray (arrayLength attribute in mzML, peaksCount in
mzXML).  We can obtain this size by reading the first <binaryDataArray>
tag attributes, but we have to take it on faith that the other
binaryDataArrays are the same size.

 

So the question is, can there be <binaryDataArray> elements with
different arrayLengths in the same <spectrum>?  If not, this should be
in the specification.  

 

If there can be different sized arrays, can we assume that at least the
m/z array size == intensity array size?  In this case, we still need one
of the following for efficient retrieval of the number of m/z-intensity
pairs:

1) Either the m/z or intensity array must occur first in the list of all
the <binaryDataArray> elements.

2) The number of m/z-intensity pairs is encoded in the
<spectrumDescription>, either as a cvParam or an attribute.

 

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

Re: [Psidev-ms-dev] mzML notes

[Eric D. <ede...@sy...>]

Hi everyone, we are now at the point where we begin the final push to =
complete mzML. I have cobbled together a calendar and assembled the list =
of to do items that I can think of. I hope we can have a well-attended =
call on Tuesday to review these items and hopefully get some volunteers =
to help with certain tasks. I then propose we continue to have calls =
every other week to keep the momentum going as best we can.


Feb 5 Agenda:
-----------------------
- Review current state of mzML
- Review/revise below schedule
- Review/revise below to do list and take on tasks


mzML Aims:
-----------------------
- Have all format changes complete by the Toledo meeting (hopefully =
sooner)
- Mop up documentation and loose threads at the meeting.
- 100.00% done by ASMS


Schedule:
-----------------------
Jan 25: mzML reviews returned. Official community review complete.
Feb=A0 1: ASMS abstracts due!
Feb=A0 5: mzML telecon 9:00am PST
Feb 19: mzML telecon 9:00am PST
Mar=A0 4: mzML telecon 9:00am PST
Mar 17: US HUPO meeting=20
Mar 25: mzML telecon 9:00am PST
Apr=A0 8: mzML telecon 9:00am PST
Apr 23: PSI meeting in Toledo
May
Jun 1-5: ASMS - Must be done and advertising it here!


News items:
-----------------------
- Official community reviews are in and sent around
- Abstract was submitted for ASMS. May be selected as a week-long =
display


To do list:
-----------------------

Schema changes:
---------------
- Incorporate Phil's suggested schema typing changes of 1/24
- Figure out how to implement datatype validation in cvParams
- For consistency binaryDataArray should be in List????
- Address suggestions from Darren 1/22
  - Fix instances in spec doc of instrumentType instead of instrument, =
etc.
  - Fix spectrumRef to point to id instead of scanNumber in example docs
  - Get full name "Proteomics Standards Initiative Mass Spectrometry =
Ontology" in obo file
  - Replace <referenceableParamGroup> with <paramGroup>
  - Remove <instrumentSoftwareRef> and use <softwareRef>
  - Change to: <cv id=3D"MS" ... >   ...    <cvParam cvRef=3D"MS" ...>
  - <sourceFile id=3D"1" sourceFileName=3D"tiny1.RAW"
        sourceFileLocation=3D"file://F:/data/Exp01" >
    should be shortened to:
    <sourceFile id=3D"1" name=3D"tiny1.RAW" =
location=3D"file://F:/data/Exp01" >
- Address the Mallick lab need for multiple precursors
  Allow multiple ionSelection elements
  allow terms for precursorIntensity
  score confidence
  see snippet on email thread 11/26
- Rune suggests allowing a range for the precursor like for MS^E
  (or technically there's always a window) See 12/7
- There was a discussion on 11/22 - 11/24 that essentially boils down =
to:
  Can we encode the MS inclusion list in an mzML file?
- Ask Randy how his "engineers are currently encoding chromatograms into
  mzData 1.05 using supplemental data vectors (not pretty)"
- Invite Mike MacCoss to help with chromatograms (via Parag)


Example files:
---------------
- Fix spectrumRef in examples
- mzML <--> MIAPE-MS mapping assessment. Build on work by Pierre-Alain & =
Frederik
- Get some of JimS's example files into a public area if he's willing
- Work with Waters to get MS^E examples made
- We need to develop a good MALDI example file with spot ids
- We need to develop a good example of a file created from individual =
dtas


Address reviewer comments:
---------------
- Address reviewer points in a document
- Angel's comments to the reviews
- Address the blunt criticisms summarized by Angel on 1/14


Validator:
---------------
- Make validator enforce this ascending scanNumber rule
- Update validator to check datatypes
- Update validator to 0.99.2


CV work:
---------------
- Figure out where we left off on CV
- Add "scan event" or similar to CV
- Need to get the relevant CV part into all vendors hands to update
- Various other CV open items to address
- Can we make the CV have the distinction between categories and terms?
- What do we do in a case like with MassWolf where it cannot know the
  instrument model?
- Coordinate submission of PSI-MS to OBO Foundry via Chris Mungall


Documentation:
---------------
- Clarify in spec doc that the binary data arrays are base64 encoded
- Should we get the indexing documented as an appendix?
- Include checksum definition
- Improve scanNumber ascending requirement in documentation
- Address locale issues in spec doc (offending example from mzData)
      <spectrumInstrument msLevel=3D"1" mzRangeStart=3D"75,00" =
mzRangeStop=3D"1000,00">
      <cvParam cvLabel=3D"psi" accession=3D"PSI:1000038" =
name=3D"TimeInMinutes" value=3D"0,033" />


Related software:
---------------
- Update ReAdW and Wolf for mzML 0.99.2
- Add support for mzML 0.99.2 to mzWiff and Hunter
- Finish off other converter loose ends
- Fix current indexing and binary encoding bugs reported by Darren 1/28
- Darren Kessner's msData C++ library reads/will read mzML
- Implement RAMP parser for mzML
- Get TPP / ISB workflow working with mzML
- Brian suggests a single C/C++ codebase with SWIG bindings to minimize =
implementation differences
- Other software?

[Psidev-ms-dev] PSI-MS WG phone conference, Tues, Feb 5 2008

[Lennart M. <len...@eb...>]

Dear PSI-MS enthousiasts,


The details for the PSI-MS phone conference are given below:


The phone conference will take place at the time indicated below (please 
find a location near you ):

http://www.timeanddate.com/worldclock/fixedtime.html?day=5&month=2&year=2008&hour=17&min=0&sec=0&p1=136

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427



Cheers,

lnnrt.


Eric Deutsch wrote:
> Hi everyone, the mzML reviews are back. Thank you to Norman Paton and 
> the anonymous reviewers. I have pasted the reviews below for your 
> perusal if you are interested. I hope everyone can devote a little time 
> in the next month to making another (and hopefully final) push to get 
> mzML finished. I would like to propose a telephone conference in a week:
> 
> 
> Tuesday February 5:
> 
> 09:00 San Francisco
> 12:00 New York
> 17:00 London (GMT)
> 18:00 Europe

Re: [Psidev-ms-dev] mzML indexing

[Eric D. <ede...@sy...>]

Hi everyone, thank you for the discussion on this thread. I summarize
what I read the general consensus opinion to be (acknowledged not to be
unanimous) as follows. If you think I have not understood the consensus
properly, please let me know.


> From: Eric Deutsch
>=20
> Hi Darren et al. for this discussion. A few points from me:
>=20
> 1) It was decided (although not set in stone) that we would like to
have a
> unique id per spectrum per file for two reasons:

Yes.

> a) At some point in the future if we have multiple runs per file (not
> supported in this first release) it will continue to be true that a
> spectrum id must be unique within a file. We decided that external
> references from analysisXML, for example, should be to a unique id
rather
> than a scan number.
>=20
> b) We also left the door open to use LSIDs for the id. It can be any
> unique string, and thus if someone wants to use LSIDs for this, the
door
> is open.
>=20
> 2) Also, according to the docs, the precursor scan references are by
id
> rather than by scan number (although this appears to be incorrectly
> represented in tiny1.mzML: FIXME). I think the spectrumRef should be
to an
> id and thus it needs to be in the index for things to work nicely. I
see
> that Matt disagrees that spectrumRef should be to an id.

Yes, use id instead of scanNumber

> 3) It is true that the current examples only have scanNumber in the
index
> and not id. This should also be fixed before release.

Yes, fix.

> 4) The spec document indeed currently says that scanNumbers in the
file
> must be in ascending order, but not necessarily sequential. The
comment
> could perhaps be a little more clearly written.

Confirmed. Improve documentation.

> 5) I also do not see the need for the index attribute. I think it
should
> be left out, but if there is still a clear need, we could add.

No index attribute.

> 6) Regarding the length attribute in offset, I am neutral on this.
This
> makes it a little harder for the writers. I can see that it would be
> easier for random access readers. Darren says he's not interested in
it.
> Anyone else out there want to lobby for it?

No length attribute. This can be easily inferred from the data. There
will be no other polluting elements intermingled with <spectrum>.

> 7) Regarding going fully attribute: the intent was to preserve the
format
> of the mzXML index as closely as possible to reduce coding work, but a
> better syntax could be entertained. I wouldn't object to:
>=20
> <offset scanNumber=3D"19" id=3D"S19" byteOffset=3D"3512"/>

No obvious support for this, so retain current syntax:
<offset scanNumber=3D"19" id=3D"S19">3512</offset>

> 8) Regarding enforcing some of these index rules, we should add them
to
> the validator so that validator will do that.

Yes.

> Comments on these items?
>=20
> Thanks,
> Eric
>=20
>=20
>=20
>=20
> > From: psi...@li...
[mailto:psidev-ms-dev-
> > bo...@li...] On Behalf Of Kessner, Darren E.
> > Sent: Wednesday, January 23, 2008 11:19 AM
> > To: Mass spectrometry standard development
> > Subject: Re: [Psidev-ms-dev] mzML indexing
> >
> > Right -- that's why I included the alternative, though I could have
been
> > less terse:
> >
> >
> >
> > "The alternative is to require that the <index> entries are written
in
> the
> > same order as the <spectrumList> entries."
> >
> >
> >
> > I don't know if there is a way to enforce this...
> >
> >
> >
> >
> >
> > Darren
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: psi...@li...
[mailto:psidev-ms-dev-
> > bo...@li...] On Behalf Of Brian Pratt
> > Sent: Wednesday, January 23, 2008 11:08 AM
> > To: 'Mass spectrometry standard development'
> > Subject: Re: [Psidev-ms-dev] mzML indexing
> >
> >
> >
> > Hi Darren,
> >
> >
> >
> > I wonder about this possibility:
> >
> >
> >
> > <index name=3D"spectrum" >
> >
> >     <offset index=3D"0" scanNumber=3D"19" id=3D"S19">3512</offset>
> >
> >     <offset index=3D"2" scanNumber=3D"23" id=3D"S23">16217</offset>
> >
> >     <offset index=3D"4" scanNumber=3D"25" id=3D"S25">17258</offset>
> >
> >      ...
> >
> >   </index>
> >
> >
> >
> > If the response is "well, that's not legal, the index values must
> increase
> > in increments of 1 starting from 0" then I don't see why it's needed
in
> > the first place - I'd expect that the index would just get snarfed
up
> into
> > an array and you'd access the nth element to get info on the nth
scan
> > appearing in the file.  And if it is legal then I don't see what
it's
> for...
> >
> >
> >
> > Brian
> >
> >
> >
> > ________________________________
> >
> > From: psi...@li...
[mailto:psidev-ms-dev-
> > bo...@li...] On Behalf Of Kessner, Darren E.
> > Sent: Wednesday, January 23, 2008 10:33 AM
> > To: Mass spectrometry standard development
> > Subject: [Psidev-ms-dev] mzML indexing
> >
> >
> >
> > Hi all,
> >
> >
> >
> > There are three ways to refer to a <spectrum> element -- by
zero-based
> > index into the <spectrumList>, by 'scanNumber', and by 'id'.
However,
> the
> > <index> currently only contains scanNumber.  I would like to encode
the
> > zero-based index and the id as well in the <index> as follows:
> >
> >
> >
> >   <index name=3D"spectrum" >
> >
> >     <offset index=3D"0" scanNumber=3D"19" id=3D"S19">3512</offset>
> >
> >     <offset index=3D"1" scanNumber=3D"20" id=3D"S20">16217</offset>
> >
> >      ...
> >
> >   </index>
> >
> >
> >
> > Including the zero-based index is important to enable random access
to
> the
> > mzML file when you don't know what scan numbers are contained in the
> file.
> > The alternative is to require that the <index> entries are written
in
> the
> > same order as the <spectrumList> entries.
> >
> >
> >
> > Including the 'id' in the <index> entries is necessary for
efficiently
> > dereferencing a "spectrumRef" (e.g. in <precursor> element).
Without
> > this, a dereference requires reading through the <spectrumList> to
find
> > the right 'id'.  This info could be read once and cached, but this
still
> > defeats the purpose of indexing.
> >
> >
> >
> >
> >
> > Darren
> >
> >
> >
> >
> >
> >
> >
> > Darren Kessner
> >
> > Scientific Programmer
> >
> > Dar...@cs...
> >
> > 310-423-9538
> >
> >
> >
> > Spielberg Family Center for Applied Proteomics
> >
> > Cedars-Sinai Medical Center
> >
> > http://www.sfcap.cshs.org/
> >
> >
> >
> >
> >
> > IMPORTANT WARNING: This message is intended for the use of the
person or
> > entity to which it is addressed and may contain information that is
> > privileged and confidential, the disclosure of which is governed by
> > applicable law. If the reader of this message is not the intended
> > recipient, or the employee or agent responsible for delivering it to
the
> > intended recipient, you are hereby notified that any dissemination,
> > distribution or copying of this information is STRICTLY PROHIBITED.
> >
> > If you have received this message in error, please notify us
immediately
> > by calling (310) 423-6428 and destroy the related message. Thank You
for
> > your cooperation.
> >
> > IMPORTANT WARNING: This message is intended for the use of the
person or
> > entity to which it is addressed and may contain information that is
> > privileged and confidential, the disclosure of which is governed by
> > applicable law. If the reader of this message is not the intended
> > recipient, or the employee or agent responsible for delivering it to
the
> > intended recipient, you are hereby notified that any dissemination,
> > distribution or copying of this information is STRICTLY PROHIBITED.
> >
> > If you have received this message in error, please notify us
immediately
> > by calling (310) 423-6428 and destroy the related message. Thank You
for
> > your cooperation.

[Psidev-ms-dev] additional CV terms

[Kessner, D. E. <Dar...@cs...>]

Hi all,

=20

I came across a piece of info that we use in our lab that is not
currently represented in the CV: scan event.

=20

Thermo uses the "scan event" (integer) to represent a set of scan
settings.  The user chooses what settings are associated with a
particular scan event.  The instrument cycles through the scan events
repeatedly during a run.  The scan event is saved with the other scan
meta-data in the Thermo RAW file.

=20

For example, our QC runs on an LTQ-FT look something like this:

=20

scan#   scan event   settings

  1             1              Ion trap survey scan

  2             2              FT survey scan

  3             3              ms2  523.77@35

  4             4              ms2  810.41@35

=20

  5             1              Ion trap survey scan

  6             2              FT survey scan

  7             3              ms2  523.77@35

  8             4              ms2  810.41@35

=20

  9             1              Ion trap survey scan

 10            2              FT survey scan

 11            3              ms2  523.77@35

 12            4              ms2  810.41@35

=20

=2E..

=20

We include the scan event as a <scan> attribute in our mzXML files.  We
can then filter out and inspect scans by scan event with various command
line tools and scripts that we use for quality control.

=20

We'll want to have a CV term for the MSData library as well.

=20

=20

Darren

=20

=20

=20

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

=20

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

=20

=20

IMPORTANT WARNING: This message is intended for the use of the person or =
entity to which it is addressed and may contain information that is privi=
leged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipi=
ent, or the employee or agent responsible for delivering it to the intend=
ed recipient, you are hereby notified that any dissemination, distributio=
n or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for=
 your cooperation.