psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] multiple mass analyzers, documentation

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

Hi Wilfred,


The instrument configuration is a rather complex bit of XML Schema 
engineering. The configuration has a list of components (at least 3 
components must be specified) and component is an abstract type for 
source, analyzer and detector. This allows the mixing of any number of 
components in any order, as long as there are a minimum of three (a 
source, an analyzer, and a detector).

As you've pointed out, the documentation thus contains some errors. 
We'll fix these.

Finally, when in doubt, always consult the XML Schema -- it is the basic 
definition of an mzML file. The semantic validator then simply adds an 
additional layer on top of the schema.


Cheers,

lnnrt.


Wilfred H Tang wrote:
> 
>  > > * There is a mistake somewhere in the rules regarding the
>  > > specification of mass analyzer. There are numerous instrument types
>  > > that have multiple mass analyzers, but the validator rejects any
>  > > instrument that contains more than one mass analyzer.  Currently, only
>  > > one <analyzer> subelement is allowed under <componentList>, and the
>  > > <analyzer> element is only allowed to have one child mass analyzer
>  > > type CV term.
> 
>  > You can indeed have several analyzer elements in your componentList, see:
>  > 
> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_example.mzML
>  > at line 29-44.
> 
> Yes, I see from the example how that is supposed to work.  So it appears 
> that the documentation 
> (http://www.sbeams.org/tmp/mzML1.0.0.html#analyzer) is wrong?
> 
> *Element <componentList>*
> *Definition:* 	List with the different components used in the mass 
> spectrometer. At least one source, one mass analyzer and one detector 
> need to be specified.
> *Attributes:* 	
> *Attribute Name*
> 	
> *Data Type*
> 	
> *Use*
> 	
> *Definition*
> count 	xs:nonNegativeInteger 	required 	The number of components in this 
> list.
> 
> 
> *Subelements:* 	
> *Subelement Name*
> 	
> *minOccurs*
> 	
> *maxOccurs*
> 	
> *Definition*
> _source_ <http://www.sbeams.org/tmp/mzML1.0.0.html#source> 	1 	1 	A 
> source component.
> _analyzer_ <http://www.sbeams.org/tmp/mzML1.0.0.html#analyzer> 	1 	1 	A 
> mass analyzer (or mass filter) component.
> _detector_ <http://www.sbeams.org/tmp/mzML1.0.0.html#detector> 	1 	1 	A 
> detector component.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 

Re: [Psidev-ms-dev] multiple mass analyzers, documentation

[Wilfred H T. <Ta...@ap...>]

More to the point, the XSD + ms-mapping.xml file say one thing, while the 
HTML documentation says another thing. Why is there a discrepancy? And is 
there consensus as to which is correct?

Thanks,
Wilfred




Wilfred H Tang <Ta...@ap...> 
Sent by: psi...@li...
08/27/2008 09:58 AM
Please respond to
Mass spectrometry standard development 
<psi...@li...>


To
Mass spectrometry standard development 
<psi...@li...>
cc

Subject
[Psidev-ms-dev] multiple mass analyzers, documentation







> > * There is a mistake somewhere in the rules regarding the 
> > specification of mass analyzer. There are numerous instrument types 
> > that have multiple mass analyzers, but the validator rejects any 
> > instrument that contains more than one mass analyzer.  Currently, only 

> > one <analyzer> subelement is allowed under <componentList>, and the 
> > <analyzer> element is only allowed to have one child mass analyzer 
> > type CV term.

> You can indeed have several analyzer elements in your componentList, 
see:
> 
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_example.mzML

> at line 29-44.

Yes, I see from the example how that is supposed to work.  So it appears 
that the documentation (http://www.sbeams.org/tmp/mzML1.0.0.html#analyzer) 
is wrong? 

Element <componentList> 
Definition: 
List with the different components used in the mass spectrometer. At least 
one source, one mass analyzer and one detector need to be specified. 
Attributes: 


Attribute Name
Data Type
Use
Definition
count 
xs:nonNegativeInteger 
required 
The number of components in this list.

Subelements: 


Subelement Name
minOccurs
maxOccurs
Definition
source 
1 
1 
A source component. 
analyzer 
1 
1 
A mass analyzer (or mass filter) component. 
detector 
1 
1 
A detector component.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
Build the coolest Linux based applications with Moblin SDK & win great 
prizes
Grand prize is a trip for two to an Open Source event anywhere in the 
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] multiple mass analyzers, documentation

[Wilfred H T. <Ta...@ap...>]

> > * There is a mistake somewhere in the rules regarding the 
> > specification of mass analyzer. There are numerous instrument types 
> > that have multiple mass analyzers, but the validator rejects any 
> > instrument that contains more than one mass analyzer.  Currently, only 

> > one <analyzer> subelement is allowed under <componentList>, and the 
> > <analyzer> element is only allowed to have one child mass analyzer 
> > type CV term.

> You can indeed have several analyzer elements in your componentList, 
see:
> 
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_example.mzML
> at line 29-44.

Yes, I see from the example how that is supposed to work.  So it appears 
that the documentation (http://www.sbeams.org/tmp/mzML1.0.0.html#analyzer) 
is wrong?

Element <componentList>
Definition:
List with the different components used in the mass spectrometer. At least 
one source, one mass analyzer and one detector need to be specified. 
Attributes:


Attribute Name
Data Type
Use
Definition
count
xs:nonNegativeInteger
required
The number of components in this list.

Subelements:


Subelement Name
minOccurs
maxOccurs
Definition
source
1
1
A source component.
analyzer
1
1
A mass analyzer (or mass filter) component.
detector
1
1
A detector component.

Re: [Psidev-ms-dev] mzML comments

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

Chris Allen wrote:
> Fredrik Levander wrote:
>   
>> Wilfred H Tang wrote:
>>     
>>> For method 1 to 
>>> work well, there must be a way to specify a m/z point spacing. Is 
>>> there a way to do this currently? Furthermore, the program reading in 
>>> the mzML must understand that the m/z point spacing implicitly 
>>> requires reconstruction of all the zero-intensity data pairs; 
>>> otherwise, for example, a mass spectrum plot would look funny.
>>>       
> Not only that, with profile data points missing it makes it very 
> difficult (if not impossible) to fit the mass scale.  Then you have to 
> look at alternatives like regridding the data.
>   
It's not clear to me what you mean here. If you're referring to the scan 
range, that is specified in <scanWindow>.


>>> A further complication for method 1 is that the m/z point spacing may 
>>> not necessarily be a constant. For example, for the AB/Sciex QSTAR 
>>> instrument, the m/z spacing is proportional to the square root of m/z, 
>>> and this is a natural consequence of this being a TOF instrument.
>>>       
>> There is a method 3 which efficiently reduces space for profile spectra 
>> which contain a lot of zeros.  All data points with zero intensity that 
>> are surrounded by data points of zero intensity can be left out. If you 
>> have the following arrays:
>> int: 1 5 1 0 0 0 0 0 1 6
>> m/z: 1 2 3 4 5 6 7 8 9 10
>> These can be reduced to:
>> int: 1 5 1 0 0 1 6
>> m/z: 1 2 3 4 8 9 10
>> This is ok to do in mzML.
>>     
> If that's OK in mzML, there really should be a CV term to say "profile 
> with points missing" otherwise you have to look through the data to try 
> and figure out if the spectrum is complete or not.
>   
If profile data is not contiguous, it must have gone through some data 
processing to do the zero thresholding (typically resulting in output 
like method 3 which preserves the integrity of each profile). That 
processing would be represented in dataProcessing:

[Term]
id: MS:1000594
name: low intensity data point removal
def: "The removal of very low intensity data points that are likely to be spurious noise rather than real signal." [PSI:MS]

[Term]
id: MS:1000629
name: low intensity threshold
def: "Threshold below which some action is taken." [PSI:MS]

If users desire the unprocessed data, that is the job of the converter, or a "data unprocessor" :)

Re: [Psidev-ms-dev] mzML comments

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

On Wed, Aug 27, 2008 at 1:58 AM, Wilfred H Tang <
Ta...@ap...> wrote:

>
> * When m/z vs. intensity data is written out in profile mode, it is pretty
> common to see a LARGE majority of the intensities to be zero. Given the
> preponderance of zero intensities, a space-efficient way to write the data
> out would be to specify a point spacing in the m/z dimension and then write
> out a (m/z, intensity) pair only if the intensity is non-zero. (Call this
> method 1.) The alternative, less space-efficient way would be to write out
> all of the (m/z, intensity) data pairs even though most of them have zero
> intensities and hence are not all that interesting. (Call this method 2.)
> For method 1 to work well, there must be a way to specify a m/z point
> spacing. Is there a way to do this currently? Furthermore, the program
> reading in the mzML must understand that the m/z point spacing implicitly
> requires reconstruction of all the zero-intensity data pairs; otherwise, for
> example, a mass spectrum plot would look funny. A further complication for
> method 1 is that the m/z point spacing may not necessarily be a constant.
> For example, for the AB/Sciex QSTAR instrument, the m/z spacing is
> proportional to the square root of m/z, and this is a natural consequence of
> this being a TOF instrument.
>

Two points:
1) compression should make file size concerns (relatively) moot.
2) including the zeros makes reading in documents (and translation to/from
other formats) much easier. I just don't see the cost/benefit ratio being in
favor of adding this sort of complexity to the standard.



>
> * The validator expects elements to appear in a certain order. This is due
> to the usage of xs:sequence in the XSD file. All deviations from the
> specified order are marked as errors, and I don't think that this is really
> the desired behavior. There's nothing intrinsic to XML that makes
> restricting order desirable, and in most cases for mzML, there is absolutely
> nothing to be gained by restricting order.
>

Three points:
1) Order of elements is intrinsic to XML and always has been. It makes XPath
travesal an implementation possible.
2) As Fredrik mentions in a later email, SAX parsing strategies are made
easier due to the current ordering of elements.
3) Ordering of elements makes writing mzML documents easier.

Cheers,
angel

Re: [Psidev-ms-dev] mzML comments

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

> If that's OK in mzML, there really should be a CV term to say "profile 
> with points missing" otherwise you have to look through the data to try 
> and figure out if the spectrum is complete or not.
>
>   
Yes, this was actually discussed in a thread in April:
http://sourceforge.net/mailarchive/message.php?msg_id=48070F90.60609%40matrixscience.com

In the last post David Creasy came up with the following list:

centroided
profile
   linear
   quadratic
   higher order polynomial
   FT
   other
      contiguous
      missing zeros  (thresholded)
      multiple calibration coefficients
      multiple segments (stitched psd)

I don't know if this discussion continued elsewhere, but anyway it would 
be nice to be able to have a CV term group for m/z spacing: linear / 
quadratic etc,
and also possibilities for annotating contiguous / missing zeros.
ms-mapping rules could then be added for 'm/z spacing', etc, for profile 
spectra.

Fredrik

Re: [Psidev-ms-dev] mzML comments

[Chris A. <ch...@ma...>]

Fredrik Levander wrote:
> Wilfred H Tang wrote:
>> For method 1 to 
>> work well, there must be a way to specify a m/z point spacing. Is 
>> there a way to do this currently? Furthermore, the program reading in 
>> the mzML must understand that the m/z point spacing implicitly 
>> requires reconstruction of all the zero-intensity data pairs; 
>> otherwise, for example, a mass spectrum plot would look funny.

Not only that, with profile data points missing it makes it very 
difficult (if not impossible) to fit the mass scale.  Then you have to 
look at alternatives like regridding the data.

>> A further complication for method 1 is that the m/z point spacing may 
>> not necessarily be a constant. For example, for the AB/Sciex QSTAR 
>> instrument, the m/z spacing is proportional to the square root of m/z, 
>> and this is a natural consequence of this being a TOF instrument.
> There is a method 3 which efficiently reduces space for profile spectra 
> which contain a lot of zeros.  All data points with zero intensity that 
> are surrounded by data points of zero intensity can be left out. If you 
> have the following arrays:
> int: 1 5 1 0 0 0 0 0 1 6
> m/z: 1 2 3 4 5 6 7 8 9 10
> These can be reduced to:
> int: 1 5 1 0 0 1 6
> m/z: 1 2 3 4 8 9 10
> This is ok to do in mzML.

If that's OK in mzML, there really should be a CV term to say "profile 
with points missing" otherwise you have to look through the data to try 
and figure out if the spectrum is complete or not.

> On the other hand, it would be very useful with a way to specify the m/z 
> spacing, since it can be quite tricky to get this for TOF data, 
> especially when a calibration function have been applied over the square 
> root spaced m/z values, so that they are no longer spaced exactly 
> proportional to the square root of m/z. Probably the initial spacing and 
> polynomial calibration functions could be specified using CV terms, just 
> that such terms are not in the CV (yet). Suggestions for this would be 
> welcome.

Agreed, but I suspect many instrument vendors will be unwilling to 
divulge their calibration functions/constants.

Regards,
Chris

Re: [Psidev-ms-dev] mzML comments

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

Hi Wilfred, some comments to some of your comments:

Wilfred H Tang wrote:
>
> * When m/z vs. intensity data is written out in profile mode, it is 
> pretty common to see a LARGE majority of the intensities to be zero. 
> Given the preponderance of zero intensities, a space-efficient way to 
> write the data out would be to specify a point spacing in the m/z 
> dimension and then write out a (m/z, intensity) pair only if the 
> intensity is non-zero. (Call this method 1.) The alternative, less 
> space-efficient way would be to write out all of the (m/z, intensity) 
> data pairs even though most of them have zero intensities and hence 
> are not all that interesting. (Call this method 2.) For method 1 to 
> work well, there must be a way to specify a m/z point spacing. Is 
> there a way to do this currently? Furthermore, the program reading in 
> the mzML must understand that the m/z point spacing implicitly 
> requires reconstruction of all the zero-intensity data pairs; 
> otherwise, for example, a mass spectrum plot would look funny. A 
> further complication for method 1 is that the m/z point spacing may 
> not necessarily be a constant. For example, for the AB/Sciex QSTAR 
> instrument, the m/z spacing is proportional to the square root of m/z, 
> and this is a natural consequence of this being a TOF instrument.
There is a method 3 which efficiently reduces space for profile spectra 
which contain a lot of zeros.  All data points with zero intensity that 
are surrounded by data points of zero intensity can be left out. If you 
have the following arrays:
int: 1 5 1 0 0 0 0 0 1 6
m/z: 1 2 3 4 5 6 7 8 9 10
These can be reduced to:
int: 1 5 1 0 0 1 6
m/z: 1 2 3 4 8 9 10
This is ok to do in mzML.

On the other hand, it would be very useful with a way to specify the m/z 
spacing, since it can be quite tricky to get this for TOF data, 
especially when a calibration function have been applied over the square 
root spaced m/z values, so that they are no longer spaced exactly 
proportional to the square root of m/z. Probably the initial spacing and 
polynomial calibration functions could be specified using CV terms, just 
that such terms are not in the CV (yet). Suggestions for this would be 
welcome.

> * The validator expects elements to appear in a certain order. This is 
> due to the usage of xs:sequence in the XSD file. All deviations from 
> the specified order are marked as errors, and I don't think that this 
> is really the desired behavior. There's nothing intrinsic to XML that 
> makes restricting order desirable, and in most cases for mzML, there 
> is absolutely nothing to be gained by restricting order.
I think the order gets quite important since parsers will not be able to 
load most files into memory. SAX/StAX parsing is needed due to the large 
size of mzML files. Things get easier when parsing the files if we now 
that referencableParamGroups and other referencable things are found in 
the beginning of the file.

>
> * The validator doesn't appear to recognize <userParam> at all - i.e., 
> any time <userParam> is put into the mzML, the validator gives an 
> error. This may possibly be related to the previous point, but I tried 
> putting <userParam> in all possible locations, and nothing seemed to 
> work.
The userParams are simply ignored by the semantic validator (or at least 
are supposed to be). On the other hand, the xsd specifies that for a 
given element cvParams must come before userParams. I don't think this 
is a problem. If we were allowed to write a mixture of cvParams and 
userParams in a block of data, we could not be sure which are related 
anyway due to the unordered nature of XML.
The tiny1 example and also the peak list example files contain 
userParams and  validate.
>
> * For the <sourceFile> element, the cvParam mapping rule "MUST supply 
> a *child* term of MS:1000561 (data file checksum type) one or more 
> times" should be deleted. The checksum of the SOURCE data file seems 
> to be completely irrelevant.
I also agreed on this previously, but was convinced after discussions 
that this is important for the integrity of data. The file checksum of 
the source file is irrelevant when looking at spectra in the file, but 
very important for traceability of data, and this is also a key role of 
mzML.
But in some cases it is not workable to retrieve the checksum of a 
source file, if it was several steps upstream in the analysis for 
example, and not available to a converter. I guess just specifying 
'unknown' as checksum value is OK, the requirement for the CV term just 
points out that one really should try to specify the checksum value if 
possible.

>
> * There is a mistake somewhere in the rules regarding the 
> specification of mass analyzer. There are numerous instrument types 
> that have multiple mass analyzers, but the validator rejects any 
> instrument that contains more than one mass analyzer.  Currently, only 
> one <analyzer> subelement is allowed under <componentList>, and the 
> <analyzer> element is only allowed to have one child mass analyzer 
> type CV term.
You can indeed have several analyzer elements in your componentList, see:
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_example.mzML
at line 29-44.

Regards

Fredrik

[Psidev-ms-dev] mzML comments

[Wilfred H T. <Ta...@ap...>]

* When m/z vs. intensity data is written out in profile mode, it is pretty 
common to see a LARGE majority of the intensities to be zero. Given the 
preponderance of zero intensities, a space-efficient way to write the data 
out would be to specify a point spacing in the m/z dimension and then 
write out a (m/z, intensity) pair only if the intensity is non-zero. (Call 
this method 1.) The alternative, less space-efficient way would be to 
write out all of the (m/z, intensity) data pairs even though most of them 
have zero intensities and hence are not all that interesting. (Call this 
method 2.) For method 1 to work well, there must be a way to specify a m/z 
point spacing. Is there a way to do this currently? Furthermore, the 
program reading in the mzML must understand that the m/z point spacing 
implicitly requires reconstruction of all the zero-intensity data pairs; 
otherwise, for example, a mass spectrum plot would look funny. A further 
complication for method 1 is that the m/z point spacing may not 
necessarily be a constant. For example, for the AB/Sciex QSTAR instrument, 
the m/z spacing is proportional to the square root of m/z, and this is a 
natural consequence of this being a TOF instrument.

* The <scanWindow> element should accept <referenceableParamGroupRef> as a 
subelement. Banning <userParam> as a subelement should not lead to also 
banning <referenceableParamGroupRef> as a subelement.

* The validator expects elements to appear in a certain order. This is due 
to the usage of xs:sequence in the XSD file. All deviations from the 
specified order are marked as errors, and I don't think that this is 
really the desired behavior. There's nothing intrinsic to XML that makes 
restricting order desirable, and in most cases for mzML, there is 
absolutely nothing to be gained by restricting order.

* The validator doesn't appear to recognize <userParam> at all - i.e., any 
time <userParam> is put into the mzML, the validator gives an error. This 
may possibly be related to the previous point, but I tried putting 
<userParam> in all possible locations, and nothing seemed to work.

* For the <sourceFile> element, the cvParam mapping rule "MUST supply a 
*child* term of MS:1000561 (data file checksum type) one or more times" 
should be deleted. The checksum of the SOURCE data file seems to be 
completely irrelevant.

* There is a mistake somewhere in the rules regarding the specification of 
mass analyzer. There are numerous instrument types that have multiple mass 
analyzers, but the validator rejects any instrument that contains more 
than one mass analyzer.  Currently, only one <analyzer> subelement is 
allowed under <componentList>, and the <analyzer> element is only allowed 
to have one child mass analyzer type CV term.

* There are serious problems with the CV terms under scan-->scanning 
method and spectrum-->spectrum type. There is partial duplication of 
analogous terms (example of analagous terms: "SIM spectrum" <===> 
"selected ion monitoring") between the two categories. While it's not 
clear that the duplication of analogous terms is desirable, as pointed out 
in a previous email thread, in any case, there should be either no 
duplication or full duplication; partial duplication is obviously flat-out 
wrong. Is it possible to devise a plan to resolve this? I don't think it 
will take too much time and effort to work things out, but the current 
state of these CV terms is unworkable.

* Somewhat related to the previous point, I suggest that the CV terms 
"full scan" and "zoom scan" under scan-->scanning method be re-named. The 
reason for doing a zoom scan is to scan more slowly over a smaller, zoomed 
m/z range (without sacrificing time) in order to obtained a spectrum with 
improved resolution. A name more descriptive of the purpose would be 
improved resolution or enhanced resolution. "Full scan" does not convey 
all that much information, so it could actually be removed.

Thanks,
Wilfred

Re: [Psidev-ms-dev] referenceableParamGroup

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

Hi Wilfred,

The on-line validator has now been updated to use the latest code from 
Lennart, so please try it with your file and report back if there are 
problems.

There is also an example file in which referencableParamGroups are used 
in the binary data array blocks at:
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_ref_params.mzML?format=raw
It may be useful for testing mzML parsers.

Cheers

Fredrik

Lennart Martens wrote:
> Hi Wilfred,
>
>
>   
>>  > The validator, however, currently is NOT properly handling the
>>  > referenceable param groups. I did a controlled experiment where
>>  > information was written out (1) using referenceable param group
>>  > references, or (2) writing out the actual data elements represented
>>  > by the referenceable param group references. The validator does
>>  > parse things properly for case (2) but not for case (1).
>>     
>
> You are absolutely right! The validator doesn't function correctly in 
> these cases!
>
> The reason for this was simple: while jmzML nicely resolved the 
> ReferenceableParamGroupRefs into ReferenceableParamGroup instances, it 
> didn't connect the last few dots, as it forgot to then initialize the CV 
> and user params in the ReferenceableParamGroup on the object's CV and 
> user param lists.
>
> Thus: essentially, a silly oversight on our behalf.
>
> Well spotted! Thanks for highlighting this serious bug.
>
> The problem has now been fixed in the latest jmzML version 
> (0.2-SNAPSHOT), and by plugging this version (rather than the original 
> 0.1-SNAPSHOT) into the validator, things will be OK again.
> Unfortunately, while Google Code allowed me to commit the jmzML changes, 
> its SVN currently seems down for developer access, and I haven't managed 
> to commit the latest Maven POM file for the validator yet. I'll do that 
> as soon as Google get their act back together again. Meanwhile, I'm 
> notifying Fredrik directly on how to fix the online validator already.
>
> Thanks once again for helping to spot the nasty bug, and hope you'll 
> have some more fun with the validator!
>
>
> Cheers,
>
> lnnrt.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] referenceableParamGroup

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

Hi Wilfred,


>  > The validator, however, currently is NOT properly handling the
>  > referenceable param groups. I did a controlled experiment where
>  > information was written out (1) using referenceable param group
>  > references, or (2) writing out the actual data elements represented
>  > by the referenceable param group references. The validator does
>  > parse things properly for case (2) but not for case (1).

You are absolutely right! The validator doesn't function correctly in 
these cases!

The reason for this was simple: while jmzML nicely resolved the 
ReferenceableParamGroupRefs into ReferenceableParamGroup instances, it 
didn't connect the last few dots, as it forgot to then initialize the CV 
and user params in the ReferenceableParamGroup on the object's CV and 
user param lists.

Thus: essentially, a silly oversight on our behalf.

Well spotted! Thanks for highlighting this serious bug.

The problem has now been fixed in the latest jmzML version 
(0.2-SNAPSHOT), and by plugging this version (rather than the original 
0.1-SNAPSHOT) into the validator, things will be OK again.
Unfortunately, while Google Code allowed me to commit the jmzML changes, 
its SVN currently seems down for developer access, and I haven't managed 
to commit the latest Maven POM file for the validator yet. I'll do that 
as soon as Google get their act back together again. Meanwhile, I'm 
notifying Fredrik directly on how to fix the online validator already.

Thanks once again for helping to spot the nasty bug, and hope you'll 
have some more fun with the validator!


Cheers,

lnnrt.

Re: [Psidev-ms-dev] referenceableParamGroup

[Wilfred H T. <Ta...@ap...>]

> The validator, however, currently is NOT properly handling the 
> referenceable param groups. I did a controlled experiment where 
> information was written out (1) using referenceable param group 
> references, or (2) writing out the actual data elements represented 
> by the referenceable param group references. The validator does 
> parse things properly for case (2) but not for case (1). 

BTW, I'm looking at the one at 
http://eddie.thep.lu.se/prodac_validator/validator.pl
Is that the latest?

Thanks,
Wilfred

Re: [Psidev-ms-dev] referenceableParamGroup

[Wilfred H T. <Ta...@ap...>]

After further investigation, I found that pwiz/SeeMS are indeed properly 
handling the referenceable param groups. Thanks to Matt Chambers for 
setting me straight!

My real problem was related to putting data into the proper place in the 
spectrum/spectrumDescription/scan/... hierarchy. A way to solve this 
problem was to replicate the referenceable param group reference 4(!!) 
times for each of the locations in the hierarchy where some data was 
required. A somewhat ugly solution, IMHO.

      <spectrum index="9" id="x1x1x4x1" nativeID="1.1.4.1" 
defaultArrayLength="5207">
        <referenceableParamGroupRef ref="Sample1Experiment1" />
        <spectrumDescription>
          <referenceableParamGroupRef ref="Sample1Experiment1" />
          <cvParam cvRef="MS" accession="MS:1000285" name="total ion 
current" value="86446" />
          <scan>
            <referenceableParamGroupRef ref="Sample1Experiment1" />
            <cvParam cvRef="MS" accession="MS:1000016" name="scan time" 
value="0.134683333333333" />
            <scanWindowList count="1">
              <scanWindow>
                <referenceableParamGroupRef ref="Sample1Experiment1" />
              </scanWindow>
            </scanWindowList>
          </scan>
        </spectrumDescription>

The validator, however, currently is NOT properly handling the 
referenceable param groups. I did a controlled experiment where 
information was written out (1) using referenceable param group 
references, or (2) writing out the actual data elements represented by the 
referenceable param group references. The validator does parse things 
properly for case (2) but not for case (1).

Thanks,
Wilfred




Matt Chambers <mat...@va...> 
Sent by: psi...@li...
08/13/2008 04:33 PM
Please respond to
Mass spectrometry standard development 
<psi...@li...>


To
Mass spectrometry standard development 
<psi...@li...>
cc

Subject
Re: [Psidev-ms-dev] referenceableParamGroup






A vile calumny! ;)

SeeMS, based on ProteoWizard, does properly recurse into referenceable 
param groups when they are actually referenced. If you were testing on 
the tiny2_pwiz.mzML file, it has referenceableParamGroups set up for 
common MS1 and MS2 params, but no other elements make a reference to 
them. It also has a rPG for common instrument params (model term and 
serial number), and that reference is resolved properly (hold the mouse 
over a the IC Id in the grid control to see it working in SeeMS). It's 
conceivable you've found a bug in pwiz though so please email me with 
details off-list if you're sure you're seeing improper behavior.

It is my understanding that the semantic validator uses a Java-based 
equivalent of ProteoWizard which also supports resolving references to 
param groups (i.e. checking in them when checking the term rules).

I agree though that rPG is a fantastic concept that may be 
undersupported. It's especially bad for writers which have the difficult 
task of coming up with the groups before writing the data containing the 
references to them. Since it's unlikely many writers will use them it 
follows that some reader implementors will be lazy and not support 
parsing them. That means there's even more reason to use a robust 
library implementation instead of reinventing the wheel. :)

-Matt


Wilfred H Tang wrote:
>
> The referenceableParamGroup concept is a fantastic idea, but I have 
> some reservations about using it when I'm writing out mzML data. I'm 
> concerned that not all mzML parsers will understand this fully, and 
> there's no mechanism to force mzML parsers to treat 
> referenceableParamGroup properly.
>
> For example:
>  - I tried loading a mzML file containing referenceableParamGroup 
> references into SeeMS, and the information contained in the 
> referenceableParamGroup references didn't show up at all (though it is 
> possible some other problem is causing the information to not get read 
> in properly).
>  - Does the validator parse referenceableParamGroup references when 
> checking that all the "musts" are present?
>
> Thanks,
> Wilfred


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
Build the coolest Linux based applications with Moblin SDK & win great 
prizes
Grand prize is a trip for two to an Open Source event anywhere in the 
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] referenceableParamGroup

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

Hi Wilfred,


Great to have you on board, you're helping us out a lot with your 
comments and suggestions! Keep up the good work and thank you for your 
interest!

> The referenceableParamGroup concept is a fantastic idea, but I have some 
> reservations about using it when I'm writing out mzML data. I'm 
> concerned that not all mzML parsers will understand this fully, and 
> there's no mechanism to force mzML parsers to treat 
> referenceableParamGroup properly.

Well, one thing that we're thinking loudly about in PSI-MS is to cook up 
a validation scheme for readers and writers of mzML, so we can stamp 
such software as 'reliable' one way or the other. This would mean that 
they fully cover the mzML specifications. This obviously is not a new 
concept in software engineering, is therefore certainly doable, and it 
will make for a good next phase of the PSI-MS group. We've already had a 
preliminary thread on the subject, and I'm sure we'll see more about 
this topic on the mailing list over the coming months.


> For example:
>  - Does the validator parse referenceableParamGroup references when 
> checking that all the "musts" are present?

Yes, it certainly does. The current validator implementation uses the 
jmzML component to read mzML, which was developed by Richard Cote in my 
group to present a powerful Java component for developers to interact 
with mzML. It's very permissively licensed as Apache2, but keep in mind 
that the thing is still only in a good beta stage right now (works, but 
don't run a nuclear power plant on it). You can sort through the 
sourcecode for the things if you're technically inclined, and see the 
magic at work. Briefly, jmzML uses a very clever combination of JAXB 
schema-based object model generation, and the XPath-based XML Indexer to 
parse and materialize into objects parts of mzML files on-the-fly.
In laymen's terms: the thing can handle very big mzML files (multiple 
gigabytes) without breaking a sweat, and will resolve all internal 
references automatically. So not only does it treat 
referenceableParamGroups as if they were physically present at the 
locations where they are referenced, it will do the same thing for 
references to instrumentconfigurations, precursor spectra, etc.

So essentially, jmzML allows you to get a spectrum and ask it for the 
mass spectrometer source that was used in the instrumentconfiguration 
that was used to acquire the spectrum. All this even though the actual 
description of the source in the instrument configuration is miles away 
(or rather: gigabytes away) in the actual mzML file.

I hope you see why I love the little gadget :).

Hope this helps!

Cheers,

lnnrt.

Re: [Psidev-ms-dev] referenceableParamGroup

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

A vile calumny! ;)

SeeMS, based on ProteoWizard, does properly recurse into referenceable 
param groups when they are actually referenced. If you were testing on 
the tiny2_pwiz.mzML file, it has referenceableParamGroups set up for 
common MS1 and MS2 params, but no other elements make a reference to 
them. It also has a rPG for common instrument params (model term and 
serial number), and that reference is resolved properly (hold the mouse 
over a the IC Id in the grid control to see it working in SeeMS). It's 
conceivable you've found a bug in pwiz though so please email me with 
details off-list if you're sure you're seeing improper behavior.

It is my understanding that the semantic validator uses a Java-based 
equivalent of ProteoWizard which also supports resolving references to 
param groups (i.e. checking in them when checking the term rules).

I agree though that rPG is a fantastic concept that may be 
undersupported. It's especially bad for writers which have the difficult 
task of coming up with the groups before writing the data containing the 
references to them. Since it's unlikely many writers will use them it 
follows that some reader implementors will be lazy and not support 
parsing them. That means there's even more reason to use a robust 
library implementation instead of reinventing the wheel. :)

-Matt


Wilfred H Tang wrote:
>
> The referenceableParamGroup concept is a fantastic idea, but I have 
> some reservations about using it when I'm writing out mzML data. I'm 
> concerned that not all mzML parsers will understand this fully, and 
> there's no mechanism to force mzML parsers to treat 
> referenceableParamGroup properly.
>
> For example:
>  - I tried loading a mzML file containing referenceableParamGroup 
> references into SeeMS, and the information contained in the 
> referenceableParamGroup references didn't show up at all (though it is 
> possible some other problem is causing the information to not get read 
> in properly).
>  - Does the validator parse referenceableParamGroup references when 
> checking that all the "musts" are present?
>
> Thanks,
> Wilfred

Re: [Psidev-ms-dev] mzML comments

[Wilfred H T. <Ta...@ap...>]

Similarly, I also don't get why there are separate XML elements 
<spectrum>, <spectrumDescription>, and <scan> (in a nested hierarchy).

Thanks,
Wilfred




Marc Sturm <st...@in...> 
Sent by: psi...@li...
08/12/2008 11:45 PM
Please respond to
Mass spectrometry standard development 
<psi...@li...    >


To
Mass spectrometry standard development 
<psi...@li...>
cc

Subject
Re: [Psidev-ms-dev] mzML comments






Hi all,

I didn't get the difference between "scan method" and "spectrum type" 
either, so I parse "spectrum type" only.
I'm not convinced we need "scan method" at all.

Another related question:
Is it ok to have "MSn spectrum" spectrum type and "ms level" = 1?
If so, when should the type "MS1 spectrum" be used?

-Marc

Matt Chambers wrote:
> The full scan definition is wrong in that full scans can be done on many 

> different types of MS instruments.
>
> I have been working under the impression that the "spectrum type" refers 

> to a brief meaning of a spectrum (the current term definition for 
> "spectrum type" is woefully inadequate), whereas "scanning method" 
> refers to the technique used to acquire the scan(s). This interpretation 

> may be too vague to capture in the CV, though. We will discuss this 
> further and clarify it. :)
>
> The scanning method definition ("Describes the acquisition data type 
> produced by a tandem mass spectrometry experiment.") is also wrong 
> because not all scans are tandem MS.
>
> It makes little sense to me to have spectrum type and scanning method 
> have a one-to-one correspondence because it implies redundant terms.
>
> The terms "precursor ion scan" and "product ion scan" seems to mean a 
> scanning role/purpose instead of a scanning method/technique. The 
> role/purpose terms are, I think, redundant with their "spectrum type" 
> counterparts. The method/technique terms are not. I may be missing 
> something about "precursor/product ion scan" though - are they not 
> simply an MSn spectrum acquired with a full scan (m/z range)?
>
> -Matt
>
>
> Wilfred H Tang wrote:
> 
>> In that case
>>  - the definition for "full scan" ("Feature of the ion trap mass 
>> spectrometer where MS data is acquired over a mass range.") is very 
>> misleading
>>  - why is there a "product ion scan"?
>>
>> Also, wouldn't it make sense for there to be a one-to-one 
>> correspondence between the entries under "scanning method" and the 
>> entries under "spectrum type"? After all, a spectrum is the result of 
>> a scan. Any reason why there should not be a one-to-one correspondence?
>>
>> Thanks,
>> Wilfred
>>
>>
>>
>> *Matt Chambers <mat...@va...>*
>> Sent by: psi...@li...
>>
>> 08/08/2008 06:07 AM
>> Please respond to
>> Mass spectrometry standard development 
>> <psi...@li...>
>>
>>
>> 
>> To
>>               Mass spectrometry standard development 
>> <psi...@li...>
>> cc
>> 
>> Subject
>>               Re: [Psidev-ms-dev] mzML comments
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>> Hi Wilfred,
>>
>> I didn't realize we hadn't responded to your suggestions for these
>> terms. We did discuss them on a WG call. The consensus, IIRC, was that
>> MS1 scan and MSn scan are already fully encapsulated by the "full scan"
>> term (in concert with the "MS level" term), and that precursor ion
>> spectrum and constant neutral loss spectrum will be added to the CV. 
The
>> process is that someone checks out the CV from CVS, makes some valid
>> changes (readable by OBO-Edit), and then someone with commit access to
>> CVS would check it in. Yes, we need a more detailed and explicit 
process
>> than that; we're working on it! :)
>>
>> -Matt
>>
>>
>> Wilfred H Tang wrote:
>> 
>>> Does the lack of dissent mean that the proposal is accepted? :)
>>>
>>> What is the process for incorporating this into the psi-ms.obo file?
>>>
>>> Thanks,
>>> Wilfred
>>>
>>>
>>> Any thoughts regarding the comments below?
>>>
>>> For the last point, I would like to propose to add the following terms
>>> to the controlled vocabulary:
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MS1 scan
>>> def: "The specific scan function or process that records a MS1
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MSn scan
>>> def: "The specific scan function or process that records a MSn
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: precursor ion spectrum
>>> def: "Spectrum generated by scanning precursor m/z while monitoring a
>>> fixed product m/z" [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: constant neutral loss spectrum
>>> def: "Spectrum generated by scanning precursor m/z and product m/z
>>> simultaneously, maintaining a constant difference between the two"
>>> [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> Thanks,
>>> Wilfred
>>> 
>
>
> 
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
Build the coolest Linux based applications with Moblin SDK & win great 
prizes
Grand prize is a trip for two to an Open Source event anywhere in the 
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] referenceableParamGroup

[Wilfred H T. <Ta...@ap...>]

The referenceableParamGroup concept is a fantastic idea, but I have some 
reservations about using it when I'm writing out mzML data. I'm concerned 
that not all mzML parsers will understand this fully, and there's no 
mechanism to force mzML parsers to treat referenceableParamGroup properly.

For example:
 - I tried loading a mzML file containing referenceableParamGroup 
references into SeeMS, and the information contained in the 
referenceableParamGroup references didn't show up at all (though it is 
possible some other problem is causing the information to not get read in 
properly).
 - Does the validator parse referenceableParamGroup references when 
checking that all the "musts" are present?

Thanks,
Wilfred

Re: [Psidev-ms-dev] mzML comments

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

Hi Marc,

Yes, the comment is no longer valid and should be removed. I'll forward 
to the ms-vocab list so that it's not forgotten again.

Fredrik

Marc Sturm wrote:
> I for got something:
>
> In the CV I found the following note for the "ms level" term:
> "The attribute 'ms level' should be encoded in the homonymous XML 
> attribute of the element 'dx:Spectrum', and not using the CvParam element."
>
> Is it still valid, or has someone simply forgotten to remove it?
>
> -Marc
>
>
> Matt Chambers wrote:
>   
>> The full scan definition is wrong in that full scans can be done on many 
>> different types of MS instruments.
>>
>> I have been working under the impression that the "spectrum type" refers 
>> to a brief meaning of a spectrum (the current term definition for 
>> "spectrum type" is woefully inadequate), whereas "scanning method" 
>> refers to the technique used to acquire the scan(s). This interpretation 
>> may be too vague to capture in the CV, though. We will discuss this 
>> further and clarify it. :)
>>
>> The scanning method definition ("Describes the acquisition data type 
>> produced by a tandem mass spectrometry experiment.") is also wrong 
>> because not all scans are tandem MS.
>>
>> It makes little sense to me to have spectrum type and scanning method 
>> have a one-to-one correspondence because it implies redundant terms.
>>
>> The terms "precursor ion scan" and "product ion scan" seems to mean a 
>> scanning role/purpose instead of a scanning method/technique. The 
>> role/purpose terms are, I think, redundant with their "spectrum type" 
>> counterparts. The method/technique terms are not. I may be missing 
>> something about "precursor/product ion scan" though - are they not 
>> simply an MSn spectrum acquired with a full scan (m/z range)?
>>
>> -Matt
>>
>>
>> Wilfred H Tang wrote:
>>   
>>     
>>> In that case
>>>  - the definition for "full scan" ("Feature of the ion trap mass 
>>> spectrometer where MS data is acquired over a mass range.") is very 
>>> misleading
>>>  - why is there a "product ion scan"?
>>>
>>> Also, wouldn't it make sense for there to be a one-to-one 
>>> correspondence between the entries under "scanning method" and the 
>>> entries under "spectrum type"? After all, a spectrum is the result of 
>>> a scan. Any reason why there should not be a one-to-one correspondence?
>>>
>>> Thanks,
>>> Wilfred
>>>
>>>
>>>
>>> *Matt Chambers <mat...@va...>*
>>> Sent by: psi...@li...
>>>
>>> 08/08/2008 06:07 AM
>>> Please respond to
>>> Mass spectrometry standard development 
>>> <psi...@li...>
>>>
>>>
>>> 	
>>> To
>>> 	Mass spectrometry standard development 
>>> <psi...@li...>
>>> cc
>>> 	
>>> Subject
>>> 	Re: [Psidev-ms-dev] mzML comments
>>>
>>>
>>>
>>> 	
>>>
>>>
>>>
>>>
>>>
>>> Hi Wilfred,
>>>
>>> I didn't realize we hadn't responded to your suggestions for these
>>> terms. We did discuss them on a WG call. The consensus, IIRC, was that
>>> MS1 scan and MSn scan are already fully encapsulated by the "full scan"
>>> term (in concert with the "MS level" term), and that precursor ion
>>> spectrum and constant neutral loss spectrum will be added to the CV. The
>>> process is that someone checks out the CV from CVS, makes some valid
>>> changes (readable by OBO-Edit), and then someone with commit access to
>>> CVS would check it in. Yes, we need a more detailed and explicit process
>>> than that; we're working on it! :)
>>>
>>> -Matt
>>>
>>>
>>> Wilfred H Tang wrote:
>>>     
>>>       
>>>> Does the lack of dissent mean that the proposal is accepted? :)
>>>>
>>>> What is the process for incorporating this into the psi-ms.obo file?
>>>>
>>>> Thanks,
>>>> Wilfred
>>>>
>>>>
>>>> Any thoughts regarding the comments below?
>>>>
>>>> For the last point, I would like to propose to add the following terms
>>>> to the controlled vocabulary:
>>>>
>>>> [Term]
>>>> id: MS:9999999
>>>> name: MS1 scan
>>>> def: "The specific scan function or process that records a MS1
>>>> spectrum." [PSI:MS]
>>>> is_a: MS:1000020 ! scanning method
>>>>
>>>> [Term]
>>>> id: MS:9999999
>>>> name: MSn scan
>>>> def: "The specific scan function or process that records a MSn
>>>> spectrum." [PSI:MS]
>>>> is_a: MS:1000020 ! scanning method
>>>>
>>>> [Term]
>>>> id: MS:9999999
>>>> name: precursor ion spectrum
>>>> def: "Spectrum generated by scanning precursor m/z while monitoring a
>>>> fixed product m/z" [PSI:MS]
>>>> is_a: MS:1000524 ! data file content
>>>> is_a: MS:1000559 ! spectrum type
>>>>
>>>> [Term]
>>>> id: MS:9999999
>>>> name: constant neutral loss spectrum
>>>> def: "Spectrum generated by scanning precursor m/z and product m/z
>>>> simultaneously, maintaining a constant difference between the two"
>>>> [PSI:MS]
>>>> is_a: MS:1000524 ! data file content
>>>> is_a: MS:1000559 ! spectrum type
>>>>
>>>> Thanks,
>>>> Wilfred
>>>>       
>>>>         
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>   
>>     
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] Small errors in example files

[Marc S. <stu...@gm...>]

Hi all,

I found two small errors in the examples:

(1)
"tiny1.mzML" uses the obsolete CV term MS:1000038 as scan time unit.

(2)
"small.pwiz.mzML" and "small_zlib.pwiz.mzML" have an empty mzML version tag.
I checked and "version" is a string attribute without any other constraints.
So it would be valid right now, but i think it should not be valid.
Perhaps we should restrict it using a regular expression like 
"[1-9]{1}.[0-9]+".

-Marc

Re: [Psidev-ms-dev] mzML comments

[Marc S. <st...@in...>]

I for got something:

In the CV I found the following note for the "ms level" term:
"The attribute 'ms level' should be encoded in the homonymous XML 
attribute of the element 'dx:Spectrum', and not using the CvParam element."

Is it still valid, or has someone simply forgotten to remove it?

-Marc


Matt Chambers wrote:
> The full scan definition is wrong in that full scans can be done on many 
> different types of MS instruments.
>
> I have been working under the impression that the "spectrum type" refers 
> to a brief meaning of a spectrum (the current term definition for 
> "spectrum type" is woefully inadequate), whereas "scanning method" 
> refers to the technique used to acquire the scan(s). This interpretation 
> may be too vague to capture in the CV, though. We will discuss this 
> further and clarify it. :)
>
> The scanning method definition ("Describes the acquisition data type 
> produced by a tandem mass spectrometry experiment.") is also wrong 
> because not all scans are tandem MS.
>
> It makes little sense to me to have spectrum type and scanning method 
> have a one-to-one correspondence because it implies redundant terms.
>
> The terms "precursor ion scan" and "product ion scan" seems to mean a 
> scanning role/purpose instead of a scanning method/technique. The 
> role/purpose terms are, I think, redundant with their "spectrum type" 
> counterparts. The method/technique terms are not. I may be missing 
> something about "precursor/product ion scan" though - are they not 
> simply an MSn spectrum acquired with a full scan (m/z range)?
>
> -Matt
>
>
> Wilfred H Tang wrote:
>   
>> In that case
>>  - the definition for "full scan" ("Feature of the ion trap mass 
>> spectrometer where MS data is acquired over a mass range.") is very 
>> misleading
>>  - why is there a "product ion scan"?
>>
>> Also, wouldn't it make sense for there to be a one-to-one 
>> correspondence between the entries under "scanning method" and the 
>> entries under "spectrum type"? After all, a spectrum is the result of 
>> a scan. Any reason why there should not be a one-to-one correspondence?
>>
>> Thanks,
>> Wilfred
>>
>>
>>
>> *Matt Chambers <mat...@va...>*
>> Sent by: psi...@li...
>>
>> 08/08/2008 06:07 AM
>> Please respond to
>> Mass spectrometry standard development 
>> <psi...@li...>
>>
>>
>> 	
>> To
>> 	Mass spectrometry standard development 
>> <psi...@li...>
>> cc
>> 	
>> Subject
>> 	Re: [Psidev-ms-dev] mzML comments
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Hi Wilfred,
>>
>> I didn't realize we hadn't responded to your suggestions for these
>> terms. We did discuss them on a WG call. The consensus, IIRC, was that
>> MS1 scan and MSn scan are already fully encapsulated by the "full scan"
>> term (in concert with the "MS level" term), and that precursor ion
>> spectrum and constant neutral loss spectrum will be added to the CV. The
>> process is that someone checks out the CV from CVS, makes some valid
>> changes (readable by OBO-Edit), and then someone with commit access to
>> CVS would check it in. Yes, we need a more detailed and explicit process
>> than that; we're working on it! :)
>>
>> -Matt
>>
>>
>> Wilfred H Tang wrote:
>>     
>>> Does the lack of dissent mean that the proposal is accepted? :)
>>>
>>> What is the process for incorporating this into the psi-ms.obo file?
>>>
>>> Thanks,
>>> Wilfred
>>>
>>>
>>> Any thoughts regarding the comments below?
>>>
>>> For the last point, I would like to propose to add the following terms
>>> to the controlled vocabulary:
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MS1 scan
>>> def: "The specific scan function or process that records a MS1
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MSn scan
>>> def: "The specific scan function or process that records a MSn
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: precursor ion spectrum
>>> def: "Spectrum generated by scanning precursor m/z while monitoring a
>>> fixed product m/z" [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: constant neutral loss spectrum
>>> def: "Spectrum generated by scanning precursor m/z and product m/z
>>> simultaneously, maintaining a constant difference between the two"
>>> [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> Thanks,
>>> Wilfred
>>>       
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] mzML comments

[Marc S. <st...@in...>]

Hi all,

I didn't get the difference between "scan method" and "spectrum type" 
either, so I parse "spectrum type" only.
I'm not convinced we need "scan method" at all.

Another related question:
Is it ok to have "MSn spectrum" spectrum type and "ms level" = 1?
If so, when should the type "MS1 spectrum" be used?

-Marc

Matt Chambers wrote:
> The full scan definition is wrong in that full scans can be done on many 
> different types of MS instruments.
>
> I have been working under the impression that the "spectrum type" refers 
> to a brief meaning of a spectrum (the current term definition for 
> "spectrum type" is woefully inadequate), whereas "scanning method" 
> refers to the technique used to acquire the scan(s). This interpretation 
> may be too vague to capture in the CV, though. We will discuss this 
> further and clarify it. :)
>
> The scanning method definition ("Describes the acquisition data type 
> produced by a tandem mass spectrometry experiment.") is also wrong 
> because not all scans are tandem MS.
>
> It makes little sense to me to have spectrum type and scanning method 
> have a one-to-one correspondence because it implies redundant terms.
>
> The terms "precursor ion scan" and "product ion scan" seems to mean a 
> scanning role/purpose instead of a scanning method/technique. The 
> role/purpose terms are, I think, redundant with their "spectrum type" 
> counterparts. The method/technique terms are not. I may be missing 
> something about "precursor/product ion scan" though - are they not 
> simply an MSn spectrum acquired with a full scan (m/z range)?
>
> -Matt
>
>
> Wilfred H Tang wrote:
>   
>> In that case
>>  - the definition for "full scan" ("Feature of the ion trap mass 
>> spectrometer where MS data is acquired over a mass range.") is very 
>> misleading
>>  - why is there a "product ion scan"?
>>
>> Also, wouldn't it make sense for there to be a one-to-one 
>> correspondence between the entries under "scanning method" and the 
>> entries under "spectrum type"? After all, a spectrum is the result of 
>> a scan. Any reason why there should not be a one-to-one correspondence?
>>
>> Thanks,
>> Wilfred
>>
>>
>>
>> *Matt Chambers <mat...@va...>*
>> Sent by: psi...@li...
>>
>> 08/08/2008 06:07 AM
>> Please respond to
>> Mass spectrometry standard development 
>> <psi...@li...>
>>
>>
>> 	
>> To
>> 	Mass spectrometry standard development 
>> <psi...@li...>
>> cc
>> 	
>> Subject
>> 	Re: [Psidev-ms-dev] mzML comments
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Hi Wilfred,
>>
>> I didn't realize we hadn't responded to your suggestions for these
>> terms. We did discuss them on a WG call. The consensus, IIRC, was that
>> MS1 scan and MSn scan are already fully encapsulated by the "full scan"
>> term (in concert with the "MS level" term), and that precursor ion
>> spectrum and constant neutral loss spectrum will be added to the CV. The
>> process is that someone checks out the CV from CVS, makes some valid
>> changes (readable by OBO-Edit), and then someone with commit access to
>> CVS would check it in. Yes, we need a more detailed and explicit process
>> than that; we're working on it! :)
>>
>> -Matt
>>
>>
>> Wilfred H Tang wrote:
>>     
>>> Does the lack of dissent mean that the proposal is accepted? :)
>>>
>>> What is the process for incorporating this into the psi-ms.obo file?
>>>
>>> Thanks,
>>> Wilfred
>>>
>>>
>>> Any thoughts regarding the comments below?
>>>
>>> For the last point, I would like to propose to add the following terms
>>> to the controlled vocabulary:
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MS1 scan
>>> def: "The specific scan function or process that records a MS1
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: MSn scan
>>> def: "The specific scan function or process that records a MSn
>>> spectrum." [PSI:MS]
>>> is_a: MS:1000020 ! scanning method
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: precursor ion spectrum
>>> def: "Spectrum generated by scanning precursor m/z while monitoring a
>>> fixed product m/z" [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> [Term]
>>> id: MS:9999999
>>> name: constant neutral loss spectrum
>>> def: "Spectrum generated by scanning precursor m/z and product m/z
>>> simultaneously, maintaining a constant difference between the two"
>>> [PSI:MS]
>>> is_a: MS:1000524 ! data file content
>>> is_a: MS:1000559 ! spectrum type
>>>
>>> Thanks,
>>> Wilfred
>>>       
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] mzML comments

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

The full scan definition is wrong in that full scans can be done on many 
different types of MS instruments.

I have been working under the impression that the "spectrum type" refers 
to a brief meaning of a spectrum (the current term definition for 
"spectrum type" is woefully inadequate), whereas "scanning method" 
refers to the technique used to acquire the scan(s). This interpretation 
may be too vague to capture in the CV, though. We will discuss this 
further and clarify it. :)

The scanning method definition ("Describes the acquisition data type 
produced by a tandem mass spectrometry experiment.") is also wrong 
because not all scans are tandem MS.

It makes little sense to me to have spectrum type and scanning method 
have a one-to-one correspondence because it implies redundant terms.

The terms "precursor ion scan" and "product ion scan" seems to mean a 
scanning role/purpose instead of a scanning method/technique. The 
role/purpose terms are, I think, redundant with their "spectrum type" 
counterparts. The method/technique terms are not. I may be missing 
something about "precursor/product ion scan" though - are they not 
simply an MSn spectrum acquired with a full scan (m/z range)?

-Matt


Wilfred H Tang wrote:
>
> In that case
>  - the definition for "full scan" ("Feature of the ion trap mass 
> spectrometer where MS data is acquired over a mass range.") is very 
> misleading
>  - why is there a "product ion scan"?
>
> Also, wouldn't it make sense for there to be a one-to-one 
> correspondence between the entries under "scanning method" and the 
> entries under "spectrum type"? After all, a spectrum is the result of 
> a scan. Any reason why there should not be a one-to-one correspondence?
>
> Thanks,
> Wilfred
>
>
>
> *Matt Chambers <mat...@va...>*
> Sent by: psi...@li...
>
> 08/08/2008 06:07 AM
> Please respond to
> Mass spectrometry standard development 
> <psi...@li...>
>
>
> 	
> To
> 	Mass spectrometry standard development 
> <psi...@li...>
> cc
> 	
> Subject
> 	Re: [Psidev-ms-dev] mzML comments
>
>
>
> 	
>
>
>
>
>
> Hi Wilfred,
>
> I didn't realize we hadn't responded to your suggestions for these
> terms. We did discuss them on a WG call. The consensus, IIRC, was that
> MS1 scan and MSn scan are already fully encapsulated by the "full scan"
> term (in concert with the "MS level" term), and that precursor ion
> spectrum and constant neutral loss spectrum will be added to the CV. The
> process is that someone checks out the CV from CVS, makes some valid
> changes (readable by OBO-Edit), and then someone with commit access to
> CVS would check it in. Yes, we need a more detailed and explicit process
> than that; we're working on it! :)
>
> -Matt
>
>
> Wilfred H Tang wrote:
> >
> > Does the lack of dissent mean that the proposal is accepted? :)
> >
> > What is the process for incorporating this into the psi-ms.obo file?
> >
> > Thanks,
> > Wilfred
> >
> >
> > Any thoughts regarding the comments below?
> >
> > For the last point, I would like to propose to add the following terms
> > to the controlled vocabulary:
> >
> > [Term]
> > id: MS:9999999
> > name: MS1 scan
> > def: "The specific scan function or process that records a MS1
> > spectrum." [PSI:MS]
> > is_a: MS:1000020 ! scanning method
> >
> > [Term]
> > id: MS:9999999
> > name: MSn scan
> > def: "The specific scan function or process that records a MSn
> > spectrum." [PSI:MS]
> > is_a: MS:1000020 ! scanning method
> >
> > [Term]
> > id: MS:9999999
> > name: precursor ion spectrum
> > def: "Spectrum generated by scanning precursor m/z while monitoring a
> > fixed product m/z" [PSI:MS]
> > is_a: MS:1000524 ! data file content
> > is_a: MS:1000559 ! spectrum type
> >
> > [Term]
> > id: MS:9999999
> > name: constant neutral loss spectrum
> > def: "Spectrum generated by scanning precursor m/z and product m/z
> > simultaneously, maintaining a constant difference between the two"
> > [PSI:MS]
> > is_a: MS:1000524 ! data file content
> > is_a: MS:1000559 ! spectrum type
> >
> > Thanks,
> > Wilfred
>

Re: [Psidev-ms-dev] mzML comments

[Wilfred H T. <Ta...@ap...>]

psi...@li... wrote on 08/12/2008 03:38:52 
PM:

> 
> In that case 
>  - the definition for "full scan" ("Feature of the ion trap mass 
> spectrometer where MS data is acquired over a mass range.") is very 
misleading

Actually the definition for "full scan" might be considered accurate if 
read the right way without the ion trap qualification, but the definition 
for "zoom scan" is clearly misleading - "Feature of the ion trap mass 
spectrometer where MSMS data is acquired over a certain mass range."

>  - why is there a "product ion scan"? 
> 
> Also, wouldn't it make sense for there to be a one-to-one 
> correspondence between the entries under "scanning method" and the 
> entries under "spectrum type"? After all, a spectrum is the result 
> of a scan. Any reason why there should not be a one-to-one 
correspondence? 
> 
> Thanks, 
> Wilfred 
> 
> 

> 
> Matt Chambers <mat...@va...> 
> Sent by: psi...@li... 
> 08/08/2008 06:07 AM 
> 
> Please respond to
> Mass spectrometry standard development 
<psi...@li...>
> 
> To
> 
> Mass spectrometry standard development 
<psi...@li...> 
> 
> cc
> 
> Subject
> 
> Re: [Psidev-ms-dev] mzML comments
> 
> 
> 
> 
> Hi Wilfred,
> 
> I didn't realize we hadn't responded to your suggestions for these 
> terms. We did discuss them on a WG call. The consensus, IIRC, was that 
> MS1 scan and MSn scan are already fully encapsulated by the "full scan" 
> term (in concert with the "MS level" term), and that precursor ion 
> spectrum and constant neutral loss spectrum will be added to the CV. The 

> process is that someone checks out the CV from CVS, makes some valid 
> changes (readable by OBO-Edit), and then someone with commit access to 
> CVS would check it in. Yes, we need a more detailed and explicit process 

> than that; we're working on it! :)
> 
> -Matt
> 
> 
> Wilfred H Tang wrote:
> >
> > Does the lack of dissent mean that the proposal is accepted? :)
> >
> > What is the process for incorporating this into the psi-ms.obo file?
> >
> > Thanks,
> > Wilfred
> >
> >
> > Any thoughts regarding the comments below?
> >
> > For the last point, I would like to propose to add the following terms 

> > to the controlled vocabulary:
> >
> > [Term]
> > id: MS:9999999
> > name: MS1 scan
> > def: "The specific scan function or process that records a MS1 
> > spectrum." [PSI:MS]
> > is_a: MS:1000020 ! scanning method
> >
> > [Term]
> > id: MS:9999999
> > name: MSn scan
> > def: "The specific scan function or process that records a MSn 
> > spectrum." [PSI:MS]
> > is_a: MS:1000020 ! scanning method
> >
> > [Term]
> > id: MS:9999999
> > name: precursor ion spectrum
> > def: "Spectrum generated by scanning precursor m/z while monitoring a 
> > fixed product m/z" [PSI:MS]
> > is_a: MS:1000524 ! data file content
> > is_a: MS:1000559 ! spectrum type
> >
> > [Term]
> > id: MS:9999999
> > name: constant neutral loss spectrum
> > def: "Spectrum generated by scanning precursor m/z and product m/z 
> > simultaneously, maintaining a constant difference between the two" 
> > [PSI:MS]
> > is_a: MS:1000524 ! data file content
> > is_a: MS:1000559 ! spectrum type
> >
> > Thanks,
> > Wilfred
> 
> 
> 
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML comments

[Wilfred H T. <Ta...@ap...>]

In that case
 - the definition for "full scan" ("Feature of the ion trap mass 
spectrometer where MS data is acquired over a mass range.") is very 
misleading
 - why is there a "product ion scan"?

Also, wouldn't it make sense for there to be a one-to-one correspondence 
between the entries under "scanning method" and the entries under 
"spectrum type"? After all, a spectrum is the result of a scan. Any reason 
why there should not be a one-to-one correspondence?

Thanks,
Wilfred




Matt Chambers <mat...@va...> 
Sent by: psi...@li...
08/08/2008 06:07 AM
Please respond to
Mass spectrometry standard development 
<psi...@li...>


To
Mass spectrometry standard development 
<psi...@li...>
cc

Subject
Re: [Psidev-ms-dev] mzML comments






Hi Wilfred,

I didn't realize we hadn't responded to your suggestions for these 
terms. We did discuss them on a WG call. The consensus, IIRC, was that 
MS1 scan and MSn scan are already fully encapsulated by the "full scan" 
term (in concert with the "MS level" term), and that precursor ion 
spectrum and constant neutral loss spectrum will be added to the CV. The 
process is that someone checks out the CV from CVS, makes some valid 
changes (readable by OBO-Edit), and then someone with commit access to 
CVS would check it in. Yes, we need a more detailed and explicit process 
than that; we're working on it! :)

-Matt


Wilfred H Tang wrote:
>
> Does the lack of dissent mean that the proposal is accepted? :)
>
> What is the process for incorporating this into the psi-ms.obo file?
>
> Thanks,
> Wilfred
>
>
> Any thoughts regarding the comments below?
>
> For the last point, I would like to propose to add the following terms 
> to the controlled vocabulary:
>
> [Term]
> id: MS:9999999
> name: MS1 scan
> def: "The specific scan function or process that records a MS1 
> spectrum." [PSI:MS]
> is_a: MS:1000020 ! scanning method
>
> [Term]
> id: MS:9999999
> name: MSn scan
> def: "The specific scan function or process that records a MSn 
> spectrum." [PSI:MS]
> is_a: MS:1000020 ! scanning method
>
> [Term]
> id: MS:9999999
> name: precursor ion spectrum
> def: "Spectrum generated by scanning precursor m/z while monitoring a 
> fixed product m/z" [PSI:MS]
> is_a: MS:1000524 ! data file content
> is_a: MS:1000559 ! spectrum type
>
> [Term]
> id: MS:9999999
> name: constant neutral loss spectrum
> def: "Spectrum generated by scanning precursor m/z and product m/z 
> simultaneously, maintaining a constant difference between the two" 
> [PSI:MS]
> is_a: MS:1000524 ! data file content
> is_a: MS:1000559 ! spectrum type
>
> Thanks,
> Wilfred


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's 
challenge
Build the coolest Linux based applications with Moblin SDK & win great 
prizes
Grand prize is a trip for two to an Open Source event anywhere in the 
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML comments

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

Hi Wilfred,

I didn't realize we hadn't responded to your suggestions for these 
terms. We did discuss them on a WG call. The consensus, IIRC, was that 
MS1 scan and MSn scan are already fully encapsulated by the "full scan" 
term (in concert with the "MS level" term), and that precursor ion 
spectrum and constant neutral loss spectrum will be added to the CV. The 
process is that someone checks out the CV from CVS, makes some valid 
changes (readable by OBO-Edit), and then someone with commit access to 
CVS would check it in. Yes, we need a more detailed and explicit process 
than that; we're working on it! :)

-Matt


Wilfred H Tang wrote:
>
> Does the lack of dissent mean that the proposal is accepted? :)
>
> What is the process for incorporating this into the psi-ms.obo file?
>
> Thanks,
> Wilfred
>
>
> Any thoughts regarding the comments below?
>
> For the last point, I would like to propose to add the following terms 
> to the controlled vocabulary:
>
> [Term]
> id: MS:9999999
> name: MS1 scan
> def: "The specific scan function or process that records a MS1 
> spectrum." [PSI:MS]
> is_a: MS:1000020 ! scanning method
>
> [Term]
> id: MS:9999999
> name: MSn scan
> def: "The specific scan function or process that records a MSn 
> spectrum." [PSI:MS]
> is_a: MS:1000020 ! scanning method
>
> [Term]
> id: MS:9999999
> name: precursor ion spectrum
> def: "Spectrum generated by scanning precursor m/z while monitoring a 
> fixed product m/z" [PSI:MS]
> is_a: MS:1000524 ! data file content
> is_a: MS:1000559 ! spectrum type
>
> [Term]
> id: MS:9999999
> name: constant neutral loss spectrum
> def: "Spectrum generated by scanning precursor m/z and product m/z 
> simultaneously, maintaining a constant difference between the two" 
> [PSI:MS]
> is_a: MS:1000524 ! data file content
> is_a: MS:1000559 ! spectrum type
>
> Thanks,
> Wilfred