psidev-ms-dev

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Since it is quite unlikely with a sequence of isolation events within one scan, I revised the scan examples, xsd and examples to only allow either a precursorList, product or neutralLoss. This way there would not be any changes to normal MS2 files.
The updated files are found at the same URL.
http://dev.thep.lu.se/fp6-prodac/browser/trun/mzML/scans

These examples are really minimalistic, and probably they are not semantically complete, but at least they validate with the xsd.

thoughts?

Fredrik 

----- Original Message -----
From: Fredrik Levander <Fre...@im...>
Date: Thursday, December 18, 2008 5:02 pm
Subject: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

> Hi All,
> 
> To find out whether mzML is OK for various scan types, I've tried 
> to 
> write down some example scans of different types in mzML format. As 
> discussed previously, precursor and neutral loss scans didn't fit 
> well 
> into the schema. I've tried to make a minimal set of changes to the 
> schema to support different scan types.
> I've uploaded scan examples (product / precursor / neutral loss / 
> MRM / 
> MSe / MS3) and an updated schema and sample file for discussion at:
> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
> 
> In schema terms my proposal would be to generalise precursorList by 
> renaming it to isolationList and then allow elements of types 
> 'precursor', 'product' and 'neutralLoss', that are all of the 
> 'IsolationType', which is about the same as the previous 
> 'PrecursorType'. This would make it possible to accomodate quite 
> complex 
> combinations of scans.
> 
> Other  observations:
> - The isolation window width might not be known, should the center 
> mass 
> be given instead then? See the neutral loss example.
> - scanList should probably be optional (as was acquisitionList and 
> scan 
> preciously)
> - keyrefs are only necessary for spectrumId, other keys are checked 
> automatically since they are ID-IDREF.
> 
> If anyone would like to download the files using subversion:
> svn checkout  http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans 
> scans
> Thanks,
> 
> Fredrik
> 
> 
> 
> --------------------------------------------------------------------
> ----------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, 
> Nevada.The future of the web can't happen without you.  Join us at 
> MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

I think holidays and snow are hampering feedback, so far, but I could 
summarize the proposed schema changes to make it easier to follow.
Note that it will not change anything for product scans or normal MS 
scans (apart from the xmlns and version), the tiny example validates 
without problem.

Summary of changes:

 - Target namespace changed to allow schema to reside there. Version 
updated to 1.1.0
 - scanList minOccurs="0"
 - in spectrum, allow either precursors, product or neutraLoss element:
          <xs:choice minOccurs="0" maxOccurs="1">
              <xs:element name="precursorList" 
type="dx:PrecursorListType" />
              <xs:element name="product" type="dx:ProductType" />
              <xs:element name="neutralLoss" type="dx:NeutralLossType" />
          </xs:choice>
 - IsolationWindowType description generalized to accomodate all types 
of isolated ions. 
 - SelectedIonList description generalized to accomodate all types of 
isolated ions
 - Addition of ProductType and NeutralLossType (containing activation 
and isolationWindow, no selectIonList ).
 - Removed some keyrefs

If this is OK the schema is found at:

http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/mzML_dev_scans.xsd

and sample spectrum examples:
http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
(The link was not correct in the previous post)

Thanks,

Fredrik

Fredrik Levander wrote:
> Since it is quite unlikely with a sequence of isolation events within one scan, I revised the scan examples, xsd and examples to only allow either a precursorList, product or neutralLoss. This way there would not be any changes to normal MS2 files.
> The updated files are found at the same URL.
> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
>
> These examples are really minimalistic, and probably they are not semantically complete, but at least they validate with the xsd.
>
> thoughts?
>
> Fredrik 
>
> ----- Original Message -----
> From: Fredrik Levander <Fre...@im...>
> Date: Thursday, December 18, 2008 5:02 pm
> Subject: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans
>
>   
>> Hi All,
>>
>> To find out whether mzML is OK for various scan types, I've tried 
>> to 
>> write down some example scans of different types in mzML format. As 
>> discussed previously, precursor and neutral loss scans didn't fit 
>> well 
>> into the schema. I've tried to make a minimal set of changes to the 
>> schema to support different scan types.
>> I've uploaded scan examples (product / precursor / neutral loss / 
>> MRM / 
>> MSe / MS3) and an updated schema and sample file for discussion at:
>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
>>
>> In schema terms my proposal would be to generalise precursorList by 
>> renaming it to isolationList and then allow elements of types 
>> 'precursor', 'product' and 'neutralLoss', that are all of the 
>> 'IsolationType', which is about the same as the previous 
>> 'PrecursorType'. This would make it possible to accomodate quite 
>> complex 
>> combinations of scans.
>>
>> Other  observations:
>> - The isolation window width might not be known, should the center 
>> mass 
>> be given instead then? See the neutral loss example.
>> - scanList should probably be optional (as was acquisitionList and 
>> scan 
>> preciously)
>> - keyrefs are only necessary for spectrumId, other keys are checked 
>> automatically since they are ID-IDREF.
>>
>> If anyone would like to download the files using subversion:
>> svn checkout  http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans 
>> scans
>> Thanks,
>>
>> Fredrik
>>
>>
>>
>> --------------------------------------------------------------------
>> ----------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, 
>> Nevada.The future of the web can't happen without you.  Join us at 
>> MIX09 to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>     
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Hi Fredrick, thank you for the summary. This looks very good to me. Let's
discuss and approve at tomorrow's call if we can get a quorum.

Regarding the keyrefs, you just removed some keyrefs that were already of
type ID or IDREF and therefore don't need the keyref?

Thanks!
Eric


> -----Original Message-----
> From: Fredrik Levander [mailto:Fre...@im...]
> Sent: Tuesday, December 23, 2008 12:59 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
> scans
> 
> I think holidays and snow are hampering feedback, so far, but I could
> summarize the proposed schema changes to make it easier to follow.
> Note that it will not change anything for product scans or normal MS
> scans (apart from the xmlns and version), the tiny example validates
> without problem.
> 
> Summary of changes:
> 
>  - Target namespace changed to allow schema to reside there. Version
> updated to 1.1.0
>  - scanList minOccurs="0"
>  - in spectrum, allow either precursors, product or neutraLoss element:
>           <xs:choice minOccurs="0" maxOccurs="1">
>               <xs:element name="precursorList"
> type="dx:PrecursorListType" />
>               <xs:element name="product" type="dx:ProductType" />
>               <xs:element name="neutralLoss" type="dx:NeutralLossType" />
>           </xs:choice>
>  - IsolationWindowType description generalized to accomodate all types
> of isolated ions.
>  - SelectedIonList description generalized to accomodate all types of
> isolated ions
>  - Addition of ProductType and NeutralLossType (containing activation
> and isolationWindow, no selectIonList ).
>  - Removed some keyrefs
> 
> If this is OK the schema is found at:
> 
> http://dev.thep.lu.se/fp6-
> prodac/browser/trunk/mzML/scans/mzML_dev_scans.xsd
> 
> and sample spectrum examples:
> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
> (The link was not correct in the previous post)
> 
> Thanks,
> 
> Fredrik
> 
> Fredrik Levander wrote:
> > Since it is quite unlikely with a sequence of isolation events within
> one scan, I revised the scan examples, xsd and examples to only allow
> either a precursorList, product or neutralLoss. This way there would not
> be any changes to normal MS2 files.
> > The updated files are found at the same URL.
> > http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
> >
> > These examples are really minimalistic, and probably they are not
> semantically complete, but at least they validate with the xsd.
> >
> > thoughts?
> >
> > Fredrik
> >
> > ----- Original Message -----
> > From: Fredrik Levander <Fre...@im...>
> > Date: Thursday, December 18, 2008 5:02 pm
> > Subject: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
> scans
> >
> >
> >> Hi All,
> >>
> >> To find out whether mzML is OK for various scan types, I've tried
> >> to
> >> write down some example scans of different types in mzML format. As
> >> discussed previously, precursor and neutral loss scans didn't fit
> >> well
> >> into the schema. I've tried to make a minimal set of changes to the
> >> schema to support different scan types.
> >> I've uploaded scan examples (product / precursor / neutral loss /
> >> MRM /
> >> MSe / MS3) and an updated schema and sample file for discussion at:
> >> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
> >>
> >> In schema terms my proposal would be to generalise precursorList by
> >> renaming it to isolationList and then allow elements of types
> >> 'precursor', 'product' and 'neutralLoss', that are all of the
> >> 'IsolationType', which is about the same as the previous
> >> 'PrecursorType'. This would make it possible to accomodate quite
> >> complex
> >> combinations of scans.
> >>
> >> Other  observations:
> >> - The isolation window width might not be known, should the center
> >> mass
> >> be given instead then? See the neutral loss example.
> >> - scanList should probably be optional (as was acquisitionList and
> >> scan
> >> preciously)
> >> - keyrefs are only necessary for spectrumId, other keys are checked
> >> automatically since they are ID-IDREF.
> >>
> >> If anyone would like to download the files using subversion:
> >> svn checkout  http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans
> >> scans
> >> Thanks,
> >>
> >> Fredrik
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> ----------
> >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> >> Nevada.The future of the web can't happen without you.  Join us at
> >> MIX09 to help
> >> pave the way to the Next Web now. Learn more and register at
> >>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.co
> m/
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> ------
> > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> Nevada.
> > The future of the web can't happen without you.  Join us at MIX09 to
> help
> > pave the way to the Next Web now. Learn more and register at
> >
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.co
> m/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> 
> 
> --------------------------------------------------------------------------
> ----
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Hi Fredrik,

The new examples for precursor ion scans and neutral loss scans look 
good. I'm not sure about the names "product" and "neutralLoss" because 
they seem to refer to a single ion as opposed to the configuration of 
the scan. But I don't have any better ideas at the moment. Also, can we 
reasonably expect future fantastic configurations (like a forked triple 
quad which splits after Q2 to two Q3s, for example) to scan for multiple 
neutral losses from a given initial ion? And is it possible to compose a 
precursor ion scan intensity from multiple Q3 products?

As far as the keyrefs go, I put them because ID and IDREF merely 
validate that any id is pointed to, not an id of the appropriate element 
type. For example, with just ID/IDREF, a spectrumRef could refer to a 
sourceFile's id attribute. That's obviously undesirable and with 
key/keyref it's easily avoidable and validates with just the schema. 
Thanks to Angel for showing me how to use them.

-Matt


Eric Deutsch wrote:
> Hi Fredrick, thank you for the summary. This looks very good to me. Let's
> discuss and approve at tomorrow's call if we can get a quorum.
>
> Regarding the keyrefs, you just removed some keyrefs that were already of
> type ID or IDREF and therefore don't need the keyref?
>
> Thanks!
> Eric
>
>
>   
>> -----Original Message-----
>> From: Fredrik Levander [mailto:Fre...@im...]
>> Sent: Tuesday, December 23, 2008 12:59 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
>> scans
>>
>> I think holidays and snow are hampering feedback, so far, but I could
>> summarize the proposed schema changes to make it easier to follow.
>> Note that it will not change anything for product scans or normal MS
>> scans (apart from the xmlns and version), the tiny example validates
>> without problem.
>>
>> Summary of changes:
>>
>>  - Target namespace changed to allow schema to reside there. Version
>> updated to 1.1.0
>>  - scanList minOccurs="0"
>>  - in spectrum, allow either precursors, product or neutraLoss element:
>>           <xs:choice minOccurs="0" maxOccurs="1">
>>               <xs:element name="precursorList"
>> type="dx:PrecursorListType" />
>>               <xs:element name="product" type="dx:ProductType" />
>>               <xs:element name="neutralLoss" type="dx:NeutralLossType" />
>>           </xs:choice>
>>  - IsolationWindowType description generalized to accomodate all types
>> of isolated ions.
>>  - SelectedIonList description generalized to accomodate all types of
>> isolated ions
>>  - Addition of ProductType and NeutralLossType (containing activation
>> and isolationWindow, no selectIonList ).
>>  - Removed some keyrefs
>>
>> If this is OK the schema is found at:
>>
>> http://dev.thep.lu.se/fp6-
>> prodac/browser/trunk/mzML/scans/mzML_dev_scans.xsd
>>
>> and sample spectrum examples:
>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
>> (The link was not correct in the previous post)
>>
>> Thanks,
>>
>> Fredrik
>>
>> Fredrik Levander wrote:
>>     
>>> Since it is quite unlikely with a sequence of isolation events within
>>>       
>> one scan, I revised the scan examples, xsd and examples to only allow
>> either a precursorList, product or neutralLoss. This way there would not
>> be any changes to normal MS2 files.
>>     
>>> The updated files are found at the same URL.
>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
>>>
>>> These examples are really minimalistic, and probably they are not
>>>       
>> semantically complete, but at least they validate with the xsd.
>>     
>>> thoughts?
>>>
>>> Fredrik
>>>
>>> ----- Original Message -----
>>> From: Fredrik Levander <Fre...@im...>
>>> Date: Thursday, December 18, 2008 5:02 pm
>>> Subject: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
>>>       
>> scans
>>     
>>>       
>>>> Hi All,
>>>>
>>>> To find out whether mzML is OK for various scan types, I've tried
>>>> to
>>>> write down some example scans of different types in mzML format. As
>>>> discussed previously, precursor and neutral loss scans didn't fit
>>>> well
>>>> into the schema. I've tried to make a minimal set of changes to the
>>>> schema to support different scan types.
>>>> I've uploaded scan examples (product / precursor / neutral loss /
>>>> MRM /
>>>> MSe / MS3) and an updated schema and sample file for discussion at:
>>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans
>>>>
>>>> In schema terms my proposal would be to generalise precursorList by
>>>> renaming it to isolationList and then allow elements of types
>>>> 'precursor', 'product' and 'neutralLoss', that are all of the
>>>> 'IsolationType', which is about the same as the previous
>>>> 'PrecursorType'. This would make it possible to accomodate quite
>>>> complex
>>>> combinations of scans.
>>>>
>>>> Other  observations:
>>>> - The isolation window width might not be known, should the center
>>>> mass
>>>> be given instead then? See the neutral loss example.
>>>> - scanList should probably be optional (as was acquisitionList and
>>>> scan
>>>> preciously)
>>>> - keyrefs are only necessary for spectrumId, other keys are checked
>>>> automatically since they are ID-IDREF.
>>>>
>>>> If anyone would like to download the files using subversion:
>>>> svn checkout  http://dev.thep.lu.se/fp6-prodac/svn/trunk/mzML/scans
>>>> scans
>>>> Thanks,
>>>>
>>>> Fredrik
>>>>
>>>>         
>

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Hi Matt, you're right about the keyrefs, I didn't think about that 
possibility. All of them should definitely be there then.

Fredrik

Matt Chambers skrev:
> Hi Fredrik,
>
> As far as the keyrefs go, I put them because ID and IDREF merely 
> validate that any id is pointed to, not an id of the appropriate element 
> type. For example, with just ID/IDREF, a spectrumRef could refer to a 
> sourceFile's id attribute. That's obviously undesirable and with 
> key/keyref it's easily avoidable and validates with just the schema. 
> Thanks to Angel for showing me how to use them.
>
> -Matt
>   

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Hi Fredrik, would you update your xsd to reflect this when you have a
chance?


> -----Original Message-----
> From: Fredrik Levander [mailto:Fre...@im...]
> Sent: Tuesday, December 30, 2008 7:34 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
> scans
> 
> Hi Matt, you're right about the keyrefs, I didn't think about that
> possibility. All of them should definitely be there then.
> 
> Fredrik
> 
> Matt Chambers skrev:
> > Hi Fredrik,
> >
> > As far as the keyrefs go, I put them because ID and IDREF merely
> > validate that any id is pointed to, not an id of the appropriate element
> > type. For example, with just ID/IDREF, a spectrumRef could refer to a
> > sourceFile's id attribute. That's obviously undesirable and with
> > key/keyref it's easily avoidable and validates with just the schema.
> > Thanks to Angel for showing me how to use them.
> >
> > -Matt
> >
> 
> --------------------------------------------------------------------------
> ----
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3 scans

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

Hi Eric, it's done. Also the dta conversion example was updated to 
prelimary mzML 1.1.0:
http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/dta_example_1.1.0.mzML
It should be checked with the semantic validators once these are 
updated, too.

XSD at:
http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/mzML_dev_scans.xsd

cheers

Fredrik

Eric Deutsch wrote:
> Hi Fredrik, would you update your xsd to reflect this when you have a
> chance?
>
>
>   
>> -----Original Message-----
>> From: Fredrik Levander [mailto:Fre...@im...]
>> Sent: Tuesday, December 30, 2008 7:34 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] precursor/product/neutral loss/SRM/MSE/MS3
>> scans
>>
>> Hi Matt, you're right about the keyrefs, I didn't think about that
>> possibility. All of them should definitely be there then.
>>
>> Fredrik
>>
>> Matt Chambers skrev:
>>     
>>> Hi Fredrik,
>>>
>>> As far as the keyrefs go, I put them because ID and IDREF merely
>>> validate that any id is pointed to, not an id of the appropriate element
>>> type. For example, with just ID/IDREF, a spectrumRef could refer to a
>>> sourceFile's id attribute. That's obviously undesirable and with
>>> key/keyref it's easily avoidable and validates with just the schema.
>>> Thanks to Angel for showing me how to use them.
>>>
>>> -Matt
>>>
>>>       
>> --------------------------------------------------------------------------
>> ----
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] scanList example

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

Hi All,

I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
generated by conversion of a ProteinLynx Global Server file.

http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML

The file still has to go through semantic validation, but I was mainly 
wondering if anyone has opinions about how the spectrum/scan ids are 
written, (and if the file makes sense at all)?

Regards

Fredrik

Re: [Psidev-ms-dev] scanList example

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

It looks good. I think we should stick with "merged=<index>" for the id 
format, just because it's simpler to ignore the method of combination at 
that level. Presumably the other scan elements will have their own scan 
times in the final file? Can't think of anything else, good job! The 
file makes perfect sense to me, this approach is leaps and bounds better 
than previous attempts at showing merged scans.

-Matt


Fredrik Levander wrote:
> Hi All,
>
> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
> generated by conversion of a ProteinLynx Global Server file.
>
> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>
> The file still has to go through semantic validation, but I was mainly 
> wondering if anyone has opinions about how the spectrum/scan ids are 
> written, (and if the file makes sense at all)?
>
> Regards
>
> Fredrik
>
>   

Re: [Psidev-ms-dev] scanList example

[David C. <dc...@ma...>]

Hi,

It came up on the 'pi' list that the mzML documentation doesn't include 
anything about the 'merged=<index>' format.

I may be missing something, but the only reference I can see to 'merged' 
is for <spectrum id= where it says:

The native identifier for a spectrum. For unmerged native spectra or 
spectra from older open file formats, the format of the identifier is 
defined in the PSI-MS CV and referred to in the mzML header. External 
documents may use this identifier together with the mzML filename or 
accession to reference a particular spectrum.

However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
high priority.

 From discussion on the pi list, I guess the documentation should also say:
"merged=<index>" is a valid id for ANY nativeID format.

Thanks,
David

Matt Chambers wrote:
> It looks good. I think we should stick with "merged=<index>" for the id 
> format, just because it's simpler to ignore the method of combination at 
> that level. Presumably the other scan elements will have their own scan 
> times in the final file? Can't think of anything else, good job! The 
> file makes perfect sense to me, this approach is leaps and bounds better 
> than previous attempts at showing merged scans.
> 
> -Matt
> 
> 
> Fredrik Levander wrote:
>> Hi All,
>>
>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>> generated by conversion of a ProteinLynx Global Server file.
>>
>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>
>> The file still has to go through semantic validation, but I was mainly 
>> wondering if anyone has opinions about how the spectrum/scan ids are 
>> written, (and if the file makes sense at all)?
>>
>> Regards
>>
>> Fredrik
>>
>>   
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-ms-dev] scanList example

[David C. <dc...@ma...>]

Hi,
(Also from the pi list - just in case it gets lost here)

The documentation should probably also say:

"It is not valid for a user to combine multiple runs together into a 
single mzML file"
(Looking through the mailing list, there was some discussion about this 
a year or so ago at which time it looks as though it was supported).

and the statement referenced below that says:
   External  documents may use this identifier together with the mzML
   filename or accession to reference a particular spectrum.

needs changing to say:

"You can't simply point to the mzML with an id because that id is only 
unique in the mzML when combined with the sourceFileRef."


Thanks,
David

David Creasy wrote:
> Hi,
> 
> It came up on the 'pi' list that the mzML documentation doesn't include 
> anything about the 'merged=<index>' format.
> 
> I may be missing something, but the only reference I can see to 'merged' 
> is for <spectrum id= where it says:
> 
> The native identifier for a spectrum. For unmerged native spectra or 
> spectra from older open file formats, the format of the identifier is 
> defined in the PSI-MS CV and referred to in the mzML header. External 
> documents may use this identifier together with the mzML filename or 
> accession to reference a particular spectrum.
> 
> However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
> high priority.
> 
>  From discussion on the pi list, I guess the documentation should also say:
> "merged=<index>" is a valid id for ANY nativeID format.
> 
> Thanks,
> David
> 
> Matt Chambers wrote:
>> It looks good. I think we should stick with "merged=<index>" for the id 
>> format, just because it's simpler to ignore the method of combination at 
>> that level. Presumably the other scan elements will have their own scan 
>> times in the final file? Can't think of anything else, good job! The 
>> file makes perfect sense to me, this approach is leaps and bounds better 
>> than previous attempts at showing merged scans.
>>
>> -Matt
>>
>>
>> Fredrik Levander wrote:
>>> Hi All,
>>>
>>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>>> generated by conversion of a ProteinLynx Global Server file.
>>>
>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>>
>>> The file still has to go through semantic validation, but I was mainly 
>>> wondering if anyone has opinions about how the spectrum/scan ids are 
>>> written, (and if the file makes sense at all)?
>>>
>>> Regards
>>>
>>> Fredrik
>>>
>>>   
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-ms-dev] scanList example

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

Sorry David, I misspoke. Right now the schema does guarantee that 
spectrum::id is unique. I believe this won't be a problem in the future 
because we will always add a unique axis to the nativeID (like Waters 
RAW has function=x instead of "process=x scan=x" and pointing to the 
sourceFile). And since we currently don't have any cases where there are 
different nativeID formats for MS spectra (BAF/U2 is the only case and 
that's MS/UV), I think mzIdentML is fine to say it supports mzML. Thanks 
for forwarding the issues to the list, I don't know how many here are 
also subscribed to PI.

-Matt


David Creasy wrote:
> Hi,
> (Also from the pi list - just in case it gets lost here)
>
> The documentation should probably also say:
>
> "It is not valid for a user to combine multiple runs together into a 
> single mzML file"
> (Looking through the mailing list, there was some discussion about this 
> a year or so ago at which time it looks as though it was supported).
>
> and the statement referenced below that says:
>    External  documents may use this identifier together with the mzML
>    filename or accession to reference a particular spectrum.
>
> needs changing to say:
>
> "You can't simply point to the mzML with an id because that id is only 
> unique in the mzML when combined with the sourceFileRef."
>
>
> Thanks,
> David
>
> David Creasy wrote:
>   
>> Hi,
>>
>> It came up on the 'pi' list that the mzML documentation doesn't include 
>> anything about the 'merged=<index>' format.
>>
>> I may be missing something, but the only reference I can see to 'merged' 
>> is for <spectrum id= where it says:
>>
>> The native identifier for a spectrum. For unmerged native spectra or 
>> spectra from older open file formats, the format of the identifier is 
>> defined in the PSI-MS CV and referred to in the mzML header. External 
>> documents may use this identifier together with the mzML filename or 
>> accession to reference a particular spectrum.
>>
>> However, the plgs_example_1.1.0.mzML seems to make sense, so it's not a 
>> high priority.
>>
>>  From discussion on the pi list, I guess the documentation should also say:
>> "merged=<index>" is a valid id for ANY nativeID format.
>>
>> Thanks,
>> David
>>
>> Matt Chambers wrote:
>>     
>>> It looks good. I think we should stick with "merged=<index>" for the id 
>>> format, just because it's simpler to ignore the method of combination at 
>>> that level. Presumably the other scan elements will have their own scan 
>>> times in the final file? Can't think of anything else, good job! The 
>>> file makes perfect sense to me, this approach is leaps and bounds better 
>>> than previous attempts at showing merged scans.
>>>
>>> -Matt
>>>
>>>
>>> Fredrik Levander wrote:
>>>       
>>>> Hi All,
>>>>
>>>> I uploaded a preliminary 1.1.0 mzML file which contains summed scans, 
>>>> generated by conversion of a ProteinLynx Global Server file.
>>>>
>>>> http://dev.thep.lu.se/fp6-prodac/browser/trunk/mzML/scans/plgs_example_1.1.0.mzML
>>>>
>>>> The file still has to go through semantic validation, but I was mainly 
>>>> wondering if anyone has opinions about how the spectrum/scan ids are 
>>>> written, (and if the file makes sense at all)?
>>>>
>>>> Regards
>>>>
>>>> Fredrik
>>>>
>>>>   
>>>>         
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>       
>
>