psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

I think we've hit at some of the key points for the discussion tomorrow.


What is your recommendation for storing ADC (or PDA) data?

Also, does the current idea for the data vectors support storing the
original time axis from a TOF or an FT instrument?

Thanks,
Randy

-----Original Message-----
From: Matthew Chambers [mailto:mat...@va...] 
Sent: Monday, February 18, 2008 3:19 PM
To: Mass spectrometry standard development
Cc: Randy Julian
Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008



Randy Julian wrote:
> I originally presented a draft of mzData 1.1 which had chromatogram
> elements in it, and it worked just fine for all sorts of acquisitions
an
> instrument can perform in addition to acquiring a spectrum.  I
> appreciate that this suggestion also created some other difficulties
> (like multiple ways to store the same data), and I dropped the draft
as
> a serious suggestion in favor of a merger between mzData and mzXML.
>   
Yes, as I understand the term, a chromatogram is a generic concept for 
any data stored with time as one axis.

> "Analog Channel" is a nickname for the typical analog-to-digital
> converters available on most mass spectrometers for recording data
from
> external devices which generate either a voltage or current output.
> These ADC inputs, and everything else recorded by the data system,
> undergo digitization.  And yes, historically detectors were mostly
> analog, but over the past decade or so, they are increasingly pulse
> counting systems with all sorts of signal processing possibilities.
> Most people don't consider pulse counting systems to be analog...
>   
OK. I can't say I like that nickname to refer to an extra/auxiliary data

channel, but so be it.

> We have already gone to generic vectors where the name (like mz and
> intensity) have to be provided in a cvParam.  It is easy already to
name
> the vectors anything you like.  This is important, especially since we
> got rid of the supplemental data vectors for holding things like
> individual peak annotations, and alternative processing of the
spectrum
> (like digital filtering, etc.).  This is all really good, and pretty
> generic already.  I'm not suggesting that we complicate things more
with
> specialization, but acknowledge the generalization which is already
> present and needed to record common extensions to the base use case.
>
> Because of the generic, unnamed vectors, a display program will
already
> have to sort out what it's looking at when it reads each vector.  They
> are not ordered, for example, and there is not a schema-enforced
> requirement that there are always two - or even that they are named at
> all.  I'm suggesting that since a robust viewing program is going to
> have to do a lot of checking to determine how the vectors are used in
> the current scheme, we would not have to do much to make the schema
much
> more broadly applicable.  Since the schema is being considered for use
> in metabolomics and other small molecule work, I think this is
> important.
>   
Yes, the vectors are generic, but their parent element is not 
(<spectrum*>), so the only thing they should be generic for are things 
within the domain of the "spectrum" concept. You are suggesting that we 
take away the (intuitive) attribute requirements of a spectrum so that 
it can be used as a generic concept. I am not at all opposed to the idea

of a generic concept at the level of <spectrum> in the data hierarchy, 
I'm just opposed to the idea that such a concept be called a "spectrum".

If you were to suggest that we rename the spectrum element to something 
generic like "runItem" (and spectrumList possibly to "runItemList") I 
could live with that. It looks silly, but it wouldn't be flat-out wrong 
and counter-intuitive! :) I would prefer to keep the spectrum element 
and add a generic sibling concept instead, though.

-Matt

> Randy    
>
> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...] 
> Sent: Monday, February 18, 2008 2:23 PM
> To: Mass spectrometry standard development
> Cc: Randy Julian
> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Have you previously made a detailed proposal about what the 
> representation of these non-MS signals should look like? And to my 
> (limited) knowledge, calling them "analog" signals is rather
misleading,
>
> because by necessity they must be digitized to be represented
digitally.
>
> :) Don't MS signals come from analog detectors as well?
>
> It sounds like you either want a specialized way to encode each 
> non-spectral data type, or a generic way to encode any non-spectral
data
>
> type. In the former case, the schema and the validator mapping would 
> define semantics for which data axes are allowed in which data type 
> (e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a 
> <chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter 
> case, there would be a generic <channel> element which would have a 
> variable set of binary data arrays and the names/types of those arrays

> would be determined by the file creator. Or both approaches could be 
> combined. But either (or both) approaches are superior to trying to 
> shove generic "channel" data into a <spectrum> element IMO. Like you 
> said, it should be possible for readers which only care about spectral

> data to easily skip the non-spectral data and that would be vastly
more 
> intuitive if there were other element names to put the non-spectra
data
> in.
>
> -Matt
>
>
> Randy Julian wrote:
>   
>> Matt,
>>
>> I'm only talking about data which is collected by the mass
>>     
> spectrometer
>   
>> data system in conjunction with the mass spectral experiment.
>>
>> When we did LC-LC experiments in my lab, we would sometimes put a UV
>> detector between the two columns, and collect data on analog channels
>> recorded by XCalibur.  Most instruments have this capability.
>>
>> Since there seems to be resistance to the whole idea of a
>>     
> <chromatogram>
>   
>> element (which I appreciate), it leaves open the question about what
>>     
> to
>   
>> do with data collected by the data system during the LC-MS
experiment.
>>
>> I don't understand why we don't want to acknowledge that almost all
MS
>> data systems can be used to collect analog signals during experiments
>> along with spectra.  This is simple stuff, and very useful.  I don't
>> want to lose this use case, and we've no place else to put this data.
>>
>> Randy
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
>> Matthew Chambers
>> Sent: Monday, February 18, 2008 1:53 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>
>> Is there a reason to accommodate non-spectral data inside spectrum 
>> elements? If the file should be able to handle non-spectral data,
then
>>     
> I
>   
>> think we should have other kinds of elements instead of introducing 
>> strange logic about deciding whether a spectrum is really spectrum or

>> not based on its MS level. Working out the other data representations

>> would take time, though. It's worth discussing in the teleconference.
>>
>> As for the scanNumber vs. scan element question, I'm a bit confused 
>> about that so I'd also like to cover it tomorrow.
>>
>> When are we going to open the cvParam-format can of worms?
>>
>> -Matt
>>
>>
>> Randy Julian wrote:
>>   
>>     
>>> I'd like to get a couple of schema items on the agenda tomorrow.
>>>
>>> I've been asking about a possible change in the schema regarding
>>> msLevel.  As an alternative to moving the attribute, or making it
>>> optional, I would like to propose that we allow non-MS channels
>>>     
>>>       
>> acquired
>>   
>>     
>>> by the MS data system and stored in the raw file to be marked as
>>> msLevel=0.  This would require a change to the specification
document
>>> but would allow software to ignore non-spectral content (whatever it
>>> might be) if the level is not at least 1.
>>>
>>> Another approach which is also consistent with the rest of the
schema
>>>     
>>>       
>> is
>>   
>>     
>>> to make the attribute a cvParam like the axis names.  This would
>>>     
>>>       
>> require
>>   
>>     
>>> a schema change and shift the validation of msLevel to the validator
>>> program.  If there is strong support for a required msLevel
attribute
>>>     
>>>       
>> in
>>   
>>     
>>> the current location, we could still represent the other signals
with
>>> the suggestion above.
>>>
>>> Also, I haven't heard back about the relationship between the 'scan'
>>> number attributes and the scan elements.  Has anyone looked at this
>>>     
>>>       
>> yet?
>>   
>>     
>>> Can we also discuss how this is supposed to work tomorrow?
>>>
>>> Thanks,
>>> Randy
>>>
>>>
>>> -----Original Message-----
>>> From: psi...@li...
>>> [mailto:psi...@li...] On Behalf Of
>>> Lennart Martens
>>> Sent: Monday, February 18, 2008 1:07 PM
>>> To: Mass spectrometry standard development
>>> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>>
>>> Dear PSI-MS Enthousiasts,
>>>
>>>
>>> The next telephone conference for the PSI-MS development group will
>>>     
>>>       
>> take
>>   
>>     
>>> place on Tuesday, 19 february 2008.
>>>
>>> The phone conference will take place at the time indicated below
>>>     
>>>       
>> (please
>>   
>>     
>>> find a location near you ):
>>>
>>>
>>>     
>>>       
>
http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
>   
>>   
>>     
>>> =2008&hour=17&min=0&sec=0&p1=0
>>>
>>> phone numbers are:
>>>
>>> + Germany: 08001012079
>>>
>>> + Switzerland: 0800000860
>>>
>>> + UK: 08081095644
>>>
>>> + USA: 1-866-314-3683
>>>
>>> + Generic international: +44 2083222500 (UK number)
>>>
>>> access code: 297427
>>>
>>>
>>> You can also view these details online on the PSI website:
>>>
>>> http://www.psidev.info/index.php?q=node/313
>>>
>>>
>>> Best regards,
>>>
>>> lnnrt.
>>>
>>>
>>>     
>>>       
>
------------------------------------------------------------------------
>   
>>   
>>     
>>> -
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>
>>>     
>>>       
>
------------------------------------------------------------------------
>   
>> -
>>   
>>     
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>   
>>>     
>>>       
>>     
>
------------------------------------------------------------------------
>   
>> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
>   

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

Randy Julian wrote:
> I originally presented a draft of mzData 1.1 which had chromatogram
> elements in it, and it worked just fine for all sorts of acquisitions an
> instrument can perform in addition to acquiring a spectrum.  I
> appreciate that this suggestion also created some other difficulties
> (like multiple ways to store the same data), and I dropped the draft as
> a serious suggestion in favor of a merger between mzData and mzXML.
>   
Yes, as I understand the term, a chromatogram is a generic concept for 
any data stored with time as one axis.

> "Analog Channel" is a nickname for the typical analog-to-digital
> converters available on most mass spectrometers for recording data from
> external devices which generate either a voltage or current output.
> These ADC inputs, and everything else recorded by the data system,
> undergo digitization.  And yes, historically detectors were mostly
> analog, but over the past decade or so, they are increasingly pulse
> counting systems with all sorts of signal processing possibilities.
> Most people don't consider pulse counting systems to be analog...
>   
OK. I can't say I like that nickname to refer to an extra/auxiliary data 
channel, but so be it.

> We have already gone to generic vectors where the name (like mz and
> intensity) have to be provided in a cvParam.  It is easy already to name
> the vectors anything you like.  This is important, especially since we
> got rid of the supplemental data vectors for holding things like
> individual peak annotations, and alternative processing of the spectrum
> (like digital filtering, etc.).  This is all really good, and pretty
> generic already.  I'm not suggesting that we complicate things more with
> specialization, but acknowledge the generalization which is already
> present and needed to record common extensions to the base use case.
>
> Because of the generic, unnamed vectors, a display program will already
> have to sort out what it's looking at when it reads each vector.  They
> are not ordered, for example, and there is not a schema-enforced
> requirement that there are always two - or even that they are named at
> all.  I'm suggesting that since a robust viewing program is going to
> have to do a lot of checking to determine how the vectors are used in
> the current scheme, we would not have to do much to make the schema much
> more broadly applicable.  Since the schema is being considered for use
> in metabolomics and other small molecule work, I think this is
> important.
>   
Yes, the vectors are generic, but their parent element is not 
(<spectrum*>), so the only thing they should be generic for are things 
within the domain of the "spectrum" concept. You are suggesting that we 
take away the (intuitive) attribute requirements of a spectrum so that 
it can be used as a generic concept. I am not at all opposed to the idea 
of a generic concept at the level of <spectrum> in the data hierarchy, 
I'm just opposed to the idea that such a concept be called a "spectrum". 
If you were to suggest that we rename the spectrum element to something 
generic like "runItem" (and spectrumList possibly to "runItemList") I 
could live with that. It looks silly, but it wouldn't be flat-out wrong 
and counter-intuitive! :) I would prefer to keep the spectrum element 
and add a generic sibling concept instead, though.

-Matt

> Randy    
>
> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...] 
> Sent: Monday, February 18, 2008 2:23 PM
> To: Mass spectrometry standard development
> Cc: Randy Julian
> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Have you previously made a detailed proposal about what the 
> representation of these non-MS signals should look like? And to my 
> (limited) knowledge, calling them "analog" signals is rather misleading,
>
> because by necessity they must be digitized to be represented digitally.
>
> :) Don't MS signals come from analog detectors as well?
>
> It sounds like you either want a specialized way to encode each 
> non-spectral data type, or a generic way to encode any non-spectral data
>
> type. In the former case, the schema and the validator mapping would 
> define semantics for which data axes are allowed in which data type 
> (e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a 
> <chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter 
> case, there would be a generic <channel> element which would have a 
> variable set of binary data arrays and the names/types of those arrays 
> would be determined by the file creator. Or both approaches could be 
> combined. But either (or both) approaches are superior to trying to 
> shove generic "channel" data into a <spectrum> element IMO. Like you 
> said, it should be possible for readers which only care about spectral 
> data to easily skip the non-spectral data and that would be vastly more 
> intuitive if there were other element names to put the non-spectra data
> in.
>
> -Matt
>
>
> Randy Julian wrote:
>   
>> Matt,
>>
>> I'm only talking about data which is collected by the mass
>>     
> spectrometer
>   
>> data system in conjunction with the mass spectral experiment.
>>
>> When we did LC-LC experiments in my lab, we would sometimes put a UV
>> detector between the two columns, and collect data on analog channels
>> recorded by XCalibur.  Most instruments have this capability.
>>
>> Since there seems to be resistance to the whole idea of a
>>     
> <chromatogram>
>   
>> element (which I appreciate), it leaves open the question about what
>>     
> to
>   
>> do with data collected by the data system during the LC-MS experiment.
>>
>> I don't understand why we don't want to acknowledge that almost all MS
>> data systems can be used to collect analog signals during experiments
>> along with spectra.  This is simple stuff, and very useful.  I don't
>> want to lose this use case, and we've no place else to put this data.
>>
>> Randy
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
>> Matthew Chambers
>> Sent: Monday, February 18, 2008 1:53 PM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>
>> Is there a reason to accommodate non-spectral data inside spectrum 
>> elements? If the file should be able to handle non-spectral data, then
>>     
> I
>   
>> think we should have other kinds of elements instead of introducing 
>> strange logic about deciding whether a spectrum is really spectrum or 
>> not based on its MS level. Working out the other data representations 
>> would take time, though. It's worth discussing in the teleconference.
>>
>> As for the scanNumber vs. scan element question, I'm a bit confused 
>> about that so I'd also like to cover it tomorrow.
>>
>> When are we going to open the cvParam-format can of worms?
>>
>> -Matt
>>
>>
>> Randy Julian wrote:
>>   
>>     
>>> I'd like to get a couple of schema items on the agenda tomorrow.
>>>
>>> I've been asking about a possible change in the schema regarding
>>> msLevel.  As an alternative to moving the attribute, or making it
>>> optional, I would like to propose that we allow non-MS channels
>>>     
>>>       
>> acquired
>>   
>>     
>>> by the MS data system and stored in the raw file to be marked as
>>> msLevel=0.  This would require a change to the specification document
>>> but would allow software to ignore non-spectral content (whatever it
>>> might be) if the level is not at least 1.
>>>
>>> Another approach which is also consistent with the rest of the schema
>>>     
>>>       
>> is
>>   
>>     
>>> to make the attribute a cvParam like the axis names.  This would
>>>     
>>>       
>> require
>>   
>>     
>>> a schema change and shift the validation of msLevel to the validator
>>> program.  If there is strong support for a required msLevel attribute
>>>     
>>>       
>> in
>>   
>>     
>>> the current location, we could still represent the other signals with
>>> the suggestion above.
>>>
>>> Also, I haven't heard back about the relationship between the 'scan'
>>> number attributes and the scan elements.  Has anyone looked at this
>>>     
>>>       
>> yet?
>>   
>>     
>>> Can we also discuss how this is supposed to work tomorrow?
>>>
>>> Thanks,
>>> Randy
>>>
>>>
>>> -----Original Message-----
>>> From: psi...@li...
>>> [mailto:psi...@li...] On Behalf Of
>>> Lennart Martens
>>> Sent: Monday, February 18, 2008 1:07 PM
>>> To: Mass spectrometry standard development
>>> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>>
>>> Dear PSI-MS Enthousiasts,
>>>
>>>
>>> The next telephone conference for the PSI-MS development group will
>>>     
>>>       
>> take
>>   
>>     
>>> place on Tuesday, 19 february 2008.
>>>
>>> The phone conference will take place at the time indicated below
>>>     
>>>       
>> (please
>>   
>>     
>>> find a location near you ):
>>>
>>>
>>>     
>>>       
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
>   
>>   
>>     
>>> =2008&hour=17&min=0&sec=0&p1=0
>>>
>>> phone numbers are:
>>>
>>> + Germany: 08001012079
>>>
>>> + Switzerland: 0800000860
>>>
>>> + UK: 08081095644
>>>
>>> + USA: 1-866-314-3683
>>>
>>> + Generic international: +44 2083222500 (UK number)
>>>
>>> access code: 297427
>>>
>>>
>>> You can also view these details online on the PSI website:
>>>
>>> http://www.psidev.info/index.php?q=node/313
>>>
>>>
>>> Best regards,
>>>
>>> lnnrt.
>>>
>>>
>>>     
>>>       
> ------------------------------------------------------------------------
>   
>>   
>>     
>>> -
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>
>>>     
>>>       
> ------------------------------------------------------------------------
>   
>> -
>>   
>>     
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>   
>>>     
>>>       
>>     
> ------------------------------------------------------------------------
>   
>> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
>   

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

I agree with randy here, in semantics, where the data vectors should live
and how to identify what the vector represents.
-angel

On Feb 18, 2008 2:45 PM, Randy Julian <rkj...@in...> wrote:

> I originally presented a draft of mzData 1.1 which had chromatogram
> elements in it, and it worked just fine for all sorts of acquisitions an
> instrument can perform in addition to acquiring a spectrum.  I
> appreciate that this suggestion also created some other difficulties
> (like multiple ways to store the same data), and I dropped the draft as
> a serious suggestion in favor of a merger between mzData and mzXML.
>
> "Analog Channel" is a nickname for the typical analog-to-digital
> converters available on most mass spectrometers for recording data from
> external devices which generate either a voltage or current output.
> These ADC inputs, and everything else recorded by the data system,
> undergo digitization.  And yes, historically detectors were mostly
> analog, but over the past decade or so, they are increasingly pulse
> counting systems with all sorts of signal processing possibilities.
> Most people don't consider pulse counting systems to be analog...
>
> We have already gone to generic vectors where the name (like mz and
> intensity) have to be provided in a cvParam.  It is easy already to name
> the vectors anything you like.  This is important, especially since we
> got rid of the supplemental data vectors for holding things like
> individual peak annotations, and alternative processing of the spectrum
> (like digital filtering, etc.).  This is all really good, and pretty
> generic already.  I'm not suggesting that we complicate things more with
> specialization, but acknowledge the generalization which is already
> present and needed to record common extensions to the base use case.
>
> Because of the generic, unnamed vectors, a display program will already
> have to sort out what it's looking at when it reads each vector.  They
> are not ordered, for example, and there is not a schema-enforced
> requirement that there are always two - or even that they are named at
> all.  I'm suggesting that since a robust viewing program is going to
> have to do a lot of checking to determine how the vectors are used in
> the current scheme, we would not have to do much to make the schema much
> more broadly applicable.  Since the schema is being considered for use
> in metabolomics and other small molecule work, I think this is
> important.
>
> Randy
>
> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Monday, February 18, 2008 2:23 PM
> To: Mass spectrometry standard development
> Cc: Randy Julian
> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Have you previously made a detailed proposal about what the
> representation of these non-MS signals should look like? And to my
> (limited) knowledge, calling them "analog" signals is rather misleading,
>
> because by necessity they must be digitized to be represented digitally.
>
> :) Don't MS signals come from analog detectors as well?
>
> It sounds like you either want a specialized way to encode each
> non-spectral data type, or a generic way to encode any non-spectral data
>
> type. In the former case, the schema and the validator mapping would
> define semantics for which data axes are allowed in which data type
> (e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a
> <chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter
> case, there would be a generic <channel> element which would have a
> variable set of binary data arrays and the names/types of those arrays
> would be determined by the file creator. Or both approaches could be
> combined. But either (or both) approaches are superior to trying to
> shove generic "channel" data into a <spectrum> element IMO. Like you
> said, it should be possible for readers which only care about spectral
> data to easily skip the non-spectral data and that would be vastly more
> intuitive if there were other element names to put the non-spectra data
> in.
>
> -Matt
>
>
> Randy Julian wrote:
> > Matt,
> >
> > I'm only talking about data which is collected by the mass
> spectrometer
> > data system in conjunction with the mass spectral experiment.
> >
> > When we did LC-LC experiments in my lab, we would sometimes put a UV
> > detector between the two columns, and collect data on analog channels
> > recorded by XCalibur.  Most instruments have this capability.
> >
> > Since there seems to be resistance to the whole idea of a
> <chromatogram>
> > element (which I appreciate), it leaves open the question about what
> to
> > do with data collected by the data system during the LC-MS experiment.
> >
> > I don't understand why we don't want to acknowledge that almost all MS
> > data systems can be used to collect analog signals during experiments
> > along with spectra.  This is simple stuff, and very useful.  I don't
> > want to lose this use case, and we've no place else to put this data.
> >
> > Randy
> >
> >
> > -----Original Message-----
> > From: psi...@li...
> > [mailto:psi...@li...] On Behalf Of
> > Matthew Chambers
> > Sent: Monday, February 18, 2008 1:53 PM
> > To: Mass spectrometry standard development
> > Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
> >
> > Is there a reason to accommodate non-spectral data inside spectrum
> > elements? If the file should be able to handle non-spectral data, then
> I
> >
> > think we should have other kinds of elements instead of introducing
> > strange logic about deciding whether a spectrum is really spectrum or
> > not based on its MS level. Working out the other data representations
> > would take time, though. It's worth discussing in the teleconference.
> >
> > As for the scanNumber vs. scan element question, I'm a bit confused
> > about that so I'd also like to cover it tomorrow.
> >
> > When are we going to open the cvParam-format can of worms?
> >
> > -Matt
> >
> >
> > Randy Julian wrote:
> >
> >> I'd like to get a couple of schema items on the agenda tomorrow.
> >>
> >> I've been asking about a possible change in the schema regarding
> >> msLevel.  As an alternative to moving the attribute, or making it
> >> optional, I would like to propose that we allow non-MS channels
> >>
> > acquired
> >
> >> by the MS data system and stored in the raw file to be marked as
> >> msLevel=0.  This would require a change to the specification document
> >> but would allow software to ignore non-spectral content (whatever it
> >> might be) if the level is not at least 1.
> >>
> >> Another approach which is also consistent with the rest of the schema
> >>
> > is
> >
> >> to make the attribute a cvParam like the axis names.  This would
> >>
> > require
> >
> >> a schema change and shift the validation of msLevel to the validator
> >> program.  If there is strong support for a required msLevel attribute
> >>
> > in
> >
> >> the current location, we could still represent the other signals with
> >> the suggestion above.
> >>
> >> Also, I haven't heard back about the relationship between the 'scan'
> >> number attributes and the scan elements.  Has anyone looked at this
> >>
> > yet?
> >
> >> Can we also discuss how this is supposed to work tomorrow?
> >>
> >> Thanks,
> >> Randy
> >>
> >>
> >> -----Original Message-----
> >> From: psi...@li...
> >> [mailto:psi...@li...] On Behalf Of
> >> Lennart Martens
> >> Sent: Monday, February 18, 2008 1:07 PM
> >> To: Mass spectrometry standard development
> >> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
> >>
> >> Dear PSI-MS Enthousiasts,
> >>
> >>
> >> The next telephone conference for the PSI-MS development group will
> >>
> > take
> >
> >> place on Tuesday, 19 february 2008.
> >>
> >> The phone conference will take place at the time indicated below
> >>
> > (please
> >
> >> find a location near you ):
> >>
> >>
> >>
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
> >
> >> =2008&hour=17&min=0&sec=0&p1=0
> >>
> >> phone numbers are:
> >>
> >> + Germany: 08001012079
> >>
> >> + Switzerland: 0800000860
> >>
> >> + UK: 08081095644
> >>
> >> + USA: 1-866-314-3683
> >>
> >> + Generic international: +44 2083222500 (UK number)
> >>
> >> access code: 297427
> >>
> >>
> >> You can also view these details online on the PSI website:
> >>
> >> http://www.psidev.info/index.php?q=node/313
> >>
> >>
> >> Best regards,
> >>
> >> lnnrt.
> >>
> >>
> >>
> >
> ------------------------------------------------------------------------
> >
> >> -
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>
> >>
> >
> ------------------------------------------------------------------------
> > -
> >
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>
> >>
> >
> >
> ------------------------------------------------------------------------
> > -
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

I originally presented a draft of mzData 1.1 which had chromatogram
elements in it, and it worked just fine for all sorts of acquisitions an
instrument can perform in addition to acquiring a spectrum.  I
appreciate that this suggestion also created some other difficulties
(like multiple ways to store the same data), and I dropped the draft as
a serious suggestion in favor of a merger between mzData and mzXML.

"Analog Channel" is a nickname for the typical analog-to-digital
converters available on most mass spectrometers for recording data from
external devices which generate either a voltage or current output.
These ADC inputs, and everything else recorded by the data system,
undergo digitization.  And yes, historically detectors were mostly
analog, but over the past decade or so, they are increasingly pulse
counting systems with all sorts of signal processing possibilities.
Most people don't consider pulse counting systems to be analog...

We have already gone to generic vectors where the name (like mz and
intensity) have to be provided in a cvParam.  It is easy already to name
the vectors anything you like.  This is important, especially since we
got rid of the supplemental data vectors for holding things like
individual peak annotations, and alternative processing of the spectrum
(like digital filtering, etc.).  This is all really good, and pretty
generic already.  I'm not suggesting that we complicate things more with
specialization, but acknowledge the generalization which is already
present and needed to record common extensions to the base use case.

Because of the generic, unnamed vectors, a display program will already
have to sort out what it's looking at when it reads each vector.  They
are not ordered, for example, and there is not a schema-enforced
requirement that there are always two - or even that they are named at
all.  I'm suggesting that since a robust viewing program is going to
have to do a lot of checking to determine how the vectors are used in
the current scheme, we would not have to do much to make the schema much
more broadly applicable.  Since the schema is being considered for use
in metabolomics and other small molecule work, I think this is
important.

Randy    

-----Original Message-----
From: Matthew Chambers [mailto:mat...@va...] 
Sent: Monday, February 18, 2008 2:23 PM
To: Mass spectrometry standard development
Cc: Randy Julian
Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

Have you previously made a detailed proposal about what the 
representation of these non-MS signals should look like? And to my 
(limited) knowledge, calling them "analog" signals is rather misleading,

because by necessity they must be digitized to be represented digitally.

:) Don't MS signals come from analog detectors as well?

It sounds like you either want a specialized way to encode each 
non-spectral data type, or a generic way to encode any non-spectral data

type. In the former case, the schema and the validator mapping would 
define semantics for which data axes are allowed in which data type 
(e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a 
<chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter 
case, there would be a generic <channel> element which would have a 
variable set of binary data arrays and the names/types of those arrays 
would be determined by the file creator. Or both approaches could be 
combined. But either (or both) approaches are superior to trying to 
shove generic "channel" data into a <spectrum> element IMO. Like you 
said, it should be possible for readers which only care about spectral 
data to easily skip the non-spectral data and that would be vastly more 
intuitive if there were other element names to put the non-spectra data
in.

-Matt


Randy Julian wrote:
> Matt,
>
> I'm only talking about data which is collected by the mass
spectrometer
> data system in conjunction with the mass spectral experiment.
>
> When we did LC-LC experiments in my lab, we would sometimes put a UV
> detector between the two columns, and collect data on analog channels
> recorded by XCalibur.  Most instruments have this capability.
>
> Since there seems to be resistance to the whole idea of a
<chromatogram>
> element (which I appreciate), it leaves open the question about what
to
> do with data collected by the data system during the LC-MS experiment.
>
> I don't understand why we don't want to acknowledge that almost all MS
> data systems can be used to collect analog signals during experiments
> along with spectra.  This is simple stuff, and very useful.  I don't
> want to lose this use case, and we've no place else to put this data.
>
> Randy
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Matthew Chambers
> Sent: Monday, February 18, 2008 1:53 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Is there a reason to accommodate non-spectral data inside spectrum 
> elements? If the file should be able to handle non-spectral data, then
I
>
> think we should have other kinds of elements instead of introducing 
> strange logic about deciding whether a spectrum is really spectrum or 
> not based on its MS level. Working out the other data representations 
> would take time, though. It's worth discussing in the teleconference.
>
> As for the scanNumber vs. scan element question, I'm a bit confused 
> about that so I'd also like to cover it tomorrow.
>
> When are we going to open the cvParam-format can of worms?
>
> -Matt
>
>
> Randy Julian wrote:
>   
>> I'd like to get a couple of schema items on the agenda tomorrow.
>>
>> I've been asking about a possible change in the schema regarding
>> msLevel.  As an alternative to moving the attribute, or making it
>> optional, I would like to propose that we allow non-MS channels
>>     
> acquired
>   
>> by the MS data system and stored in the raw file to be marked as
>> msLevel=0.  This would require a change to the specification document
>> but would allow software to ignore non-spectral content (whatever it
>> might be) if the level is not at least 1.
>>
>> Another approach which is also consistent with the rest of the schema
>>     
> is
>   
>> to make the attribute a cvParam like the axis names.  This would
>>     
> require
>   
>> a schema change and shift the validation of msLevel to the validator
>> program.  If there is strong support for a required msLevel attribute
>>     
> in
>   
>> the current location, we could still represent the other signals with
>> the suggestion above.
>>
>> Also, I haven't heard back about the relationship between the 'scan'
>> number attributes and the scan elements.  Has anyone looked at this
>>     
> yet?
>   
>> Can we also discuss how this is supposed to work tomorrow?
>>
>> Thanks,
>> Randy
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
>> Lennart Martens
>> Sent: Monday, February 18, 2008 1:07 PM
>> To: Mass spectrometry standard development
>> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>
>> Dear PSI-MS Enthousiasts,
>>
>>
>> The next telephone conference for the PSI-MS development group will
>>     
> take
>   
>> place on Tuesday, 19 february 2008.
>>
>> The phone conference will take place at the time indicated below
>>     
> (please
>   
>> find a location near you ):
>>
>>
>>     
>
http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
>   
>> =2008&hour=17&min=0&sec=0&p1=0
>>
>> phone numbers are:
>>
>> + Germany: 08001012079
>>
>> + Switzerland: 0800000860
>>
>> + UK: 08081095644
>>
>> + USA: 1-866-314-3683
>>
>> + Generic international: +44 2083222500 (UK number)
>>
>> access code: 297427
>>
>>
>> You can also view these details online on the PSI website:
>>
>> http://www.psidev.info/index.php?q=node/313
>>
>>
>> Best regards,
>>
>> lnnrt.
>>
>>
>>     
>
------------------------------------------------------------------------
>   
>> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>>     
>
------------------------------------------------------------------------
> -
>   
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

Have you previously made a detailed proposal about what the 
representation of these non-MS signals should look like? And to my 
(limited) knowledge, calling them "analog" signals is rather misleading, 
because by necessity they must be digitized to be represented digitally. 
:) Don't MS signals come from analog detectors as well?

It sounds like you either want a specialized way to encode each 
non-spectral data type, or a generic way to encode any non-spectral data 
type. In the former case, the schema and the validator mapping would 
define semantics for which data axes are allowed in which data type 
(e.g. "mz vs. intensity in a <spectrum>", "time vs. intensity in a 
<chromatogram>", "x vs. y in a <uvChannel>", etc.), and in the latter 
case, there would be a generic <channel> element which would have a 
variable set of binary data arrays and the names/types of those arrays 
would be determined by the file creator. Or both approaches could be 
combined. But either (or both) approaches are superior to trying to 
shove generic "channel" data into a <spectrum> element IMO. Like you 
said, it should be possible for readers which only care about spectral 
data to easily skip the non-spectral data and that would be vastly more 
intuitive if there were other element names to put the non-spectra data in.

-Matt


Randy Julian wrote:
> Matt,
>
> I'm only talking about data which is collected by the mass spectrometer
> data system in conjunction with the mass spectral experiment.
>
> When we did LC-LC experiments in my lab, we would sometimes put a UV
> detector between the two columns, and collect data on analog channels
> recorded by XCalibur.  Most instruments have this capability.
>
> Since there seems to be resistance to the whole idea of a <chromatogram>
> element (which I appreciate), it leaves open the question about what to
> do with data collected by the data system during the LC-MS experiment.
>
> I don't understand why we don't want to acknowledge that almost all MS
> data systems can be used to collect analog signals during experiments
> along with spectra.  This is simple stuff, and very useful.  I don't
> want to lose this use case, and we've no place else to put this data.
>
> Randy
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Matthew Chambers
> Sent: Monday, February 18, 2008 1:53 PM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Is there a reason to accommodate non-spectral data inside spectrum 
> elements? If the file should be able to handle non-spectral data, then I
>
> think we should have other kinds of elements instead of introducing 
> strange logic about deciding whether a spectrum is really spectrum or 
> not based on its MS level. Working out the other data representations 
> would take time, though. It's worth discussing in the teleconference.
>
> As for the scanNumber vs. scan element question, I'm a bit confused 
> about that so I'd also like to cover it tomorrow.
>
> When are we going to open the cvParam-format can of worms?
>
> -Matt
>
>
> Randy Julian wrote:
>   
>> I'd like to get a couple of schema items on the agenda tomorrow.
>>
>> I've been asking about a possible change in the schema regarding
>> msLevel.  As an alternative to moving the attribute, or making it
>> optional, I would like to propose that we allow non-MS channels
>>     
> acquired
>   
>> by the MS data system and stored in the raw file to be marked as
>> msLevel=0.  This would require a change to the specification document
>> but would allow software to ignore non-spectral content (whatever it
>> might be) if the level is not at least 1.
>>
>> Another approach which is also consistent with the rest of the schema
>>     
> is
>   
>> to make the attribute a cvParam like the axis names.  This would
>>     
> require
>   
>> a schema change and shift the validation of msLevel to the validator
>> program.  If there is strong support for a required msLevel attribute
>>     
> in
>   
>> the current location, we could still represent the other signals with
>> the suggestion above.
>>
>> Also, I haven't heard back about the relationship between the 'scan'
>> number attributes and the scan elements.  Has anyone looked at this
>>     
> yet?
>   
>> Can we also discuss how this is supposed to work tomorrow?
>>
>> Thanks,
>> Randy
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of
>> Lennart Martens
>> Sent: Monday, February 18, 2008 1:07 PM
>> To: Mass spectrometry standard development
>> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>>
>> Dear PSI-MS Enthousiasts,
>>
>>
>> The next telephone conference for the PSI-MS development group will
>>     
> take
>   
>> place on Tuesday, 19 february 2008.
>>
>> The phone conference will take place at the time indicated below
>>     
> (please
>   
>> find a location near you ):
>>
>>
>>     
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
>   
>> =2008&hour=17&min=0&sec=0&p1=0
>>
>> phone numbers are:
>>
>> + Germany: 08001012079
>>
>> + Switzerland: 0800000860
>>
>> + UK: 08081095644
>>
>> + USA: 1-866-314-3683
>>
>> + Generic international: +44 2083222500 (UK number)
>>
>> access code: 297427
>>
>>
>> You can also view these details online on the PSI website:
>>
>> http://www.psidev.info/index.php?q=node/313
>>
>>
>> Best regards,
>>
>> lnnrt.
>>
>>
>>     
> ------------------------------------------------------------------------
>   
>> -
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>>     
> ------------------------------------------------------------------------
> -
>   
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

Matt,

I'm only talking about data which is collected by the mass spectrometer
data system in conjunction with the mass spectral experiment.

When we did LC-LC experiments in my lab, we would sometimes put a UV
detector between the two columns, and collect data on analog channels
recorded by XCalibur.  Most instruments have this capability.

Since there seems to be resistance to the whole idea of a <chromatogram>
element (which I appreciate), it leaves open the question about what to
do with data collected by the data system during the LC-MS experiment.

I don't understand why we don't want to acknowledge that almost all MS
data systems can be used to collect analog signals during experiments
along with spectra.  This is simple stuff, and very useful.  I don't
want to lose this use case, and we've no place else to put this data.

Randy


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Monday, February 18, 2008 1:53 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

Is there a reason to accommodate non-spectral data inside spectrum 
elements? If the file should be able to handle non-spectral data, then I

think we should have other kinds of elements instead of introducing 
strange logic about deciding whether a spectrum is really spectrum or 
not based on its MS level. Working out the other data representations 
would take time, though. It's worth discussing in the teleconference.

As for the scanNumber vs. scan element question, I'm a bit confused 
about that so I'd also like to cover it tomorrow.

When are we going to open the cvParam-format can of worms?

-Matt


Randy Julian wrote:
> I'd like to get a couple of schema items on the agenda tomorrow.
>
> I've been asking about a possible change in the schema regarding
> msLevel.  As an alternative to moving the attribute, or making it
> optional, I would like to propose that we allow non-MS channels
acquired
> by the MS data system and stored in the raw file to be marked as
> msLevel=0.  This would require a change to the specification document
> but would allow software to ignore non-spectral content (whatever it
> might be) if the level is not at least 1.
>
> Another approach which is also consistent with the rest of the schema
is
> to make the attribute a cvParam like the axis names.  This would
require
> a schema change and shift the validation of msLevel to the validator
> program.  If there is strong support for a required msLevel attribute
in
> the current location, we could still represent the other signals with
> the suggestion above.
>
> Also, I haven't heard back about the relationship between the 'scan'
> number attributes and the scan elements.  Has anyone looked at this
yet?
> Can we also discuss how this is supposed to work tomorrow?
>
> Thanks,
> Randy
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Lennart Martens
> Sent: Monday, February 18, 2008 1:07 PM
> To: Mass spectrometry standard development
> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Dear PSI-MS Enthousiasts,
>
>
> The next telephone conference for the PSI-MS development group will
take
>
> place on Tuesday, 19 february 2008.
>
> The phone conference will take place at the time indicated below
(please
>
> find a location near you ):
>
>
http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
> =2008&hour=17&min=0&sec=0&p1=0
>
> phone numbers are:
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-314-3683
>
> + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
>
> You can also view these details online on the PSI website:
>
> http://www.psidev.info/index.php?q=node/313
>
>
> Best regards,
>
> lnnrt.
>
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

Is there a reason to accommodate non-spectral data inside spectrum 
elements? If the file should be able to handle non-spectral data, then I 
think we should have other kinds of elements instead of introducing 
strange logic about deciding whether a spectrum is really spectrum or 
not based on its MS level. Working out the other data representations 
would take time, though. It's worth discussing in the teleconference.

As for the scanNumber vs. scan element question, I'm a bit confused 
about that so I'd also like to cover it tomorrow.

When are we going to open the cvParam-format can of worms?

-Matt


Randy Julian wrote:
> I'd like to get a couple of schema items on the agenda tomorrow.
>
> I've been asking about a possible change in the schema regarding
> msLevel.  As an alternative to moving the attribute, or making it
> optional, I would like to propose that we allow non-MS channels acquired
> by the MS data system and stored in the raw file to be marked as
> msLevel=0.  This would require a change to the specification document
> but would allow software to ignore non-spectral content (whatever it
> might be) if the level is not at least 1.
>
> Another approach which is also consistent with the rest of the schema is
> to make the attribute a cvParam like the axis names.  This would require
> a schema change and shift the validation of msLevel to the validator
> program.  If there is strong support for a required msLevel attribute in
> the current location, we could still represent the other signals with
> the suggestion above.
>
> Also, I haven't heard back about the relationship between the 'scan'
> number attributes and the scan elements.  Has anyone looked at this yet?
> Can we also discuss how this is supposed to work tomorrow?
>
> Thanks,
> Randy
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Lennart Martens
> Sent: Monday, February 18, 2008 1:07 PM
> To: Mass spectrometry standard development
> Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008
>
> Dear PSI-MS Enthousiasts,
>
>
> The next telephone conference for the PSI-MS development group will take
>
> place on Tuesday, 19 february 2008.
>
> The phone conference will take place at the time indicated below (please
>
> find a location near you ):
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=19&month=2&year
> =2008&hour=17&min=0&sec=0&p1=0
>
> phone numbers are:
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-314-3683
>
> + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
>
> You can also view these details online on the PSI website:
>
> http://www.psidev.info/index.php?q=node/313
>
>
> Best regards,
>
> lnnrt.
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

I'd like to get a couple of schema items on the agenda tomorrow.

I've been asking about a possible change in the schema regarding
msLevel.  As an alternative to moving the attribute, or making it
optional, I would like to propose that we allow non-MS channels acquired
by the MS data system and stored in the raw file to be marked as
msLevel=0.  This would require a change to the specification document
but would allow software to ignore non-spectral content (whatever it
might be) if the level is not at least 1.

Another approach which is also consistent with the rest of the schema is
to make the attribute a cvParam like the axis names.  This would require
a schema change and shift the validation of msLevel to the validator
program.  If there is strong support for a required msLevel attribute in
the current location, we could still represent the other signals with
the suggestion above.

Also, I haven't heard back about the relationship between the 'scan'
number attributes and the scan elements.  Has anyone looked at this yet?
Can we also discuss how this is supposed to work tomorrow?

Thanks,
Randy


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Lennart Martens
Sent: Monday, February 18, 2008 1:07 PM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

Dear PSI-MS Enthousiasts,


The next telephone conference for the PSI-MS development group will take

place on Tuesday, 19 february 2008.

The phone conference will take place at the time indicated below (please

find a location near you ):

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

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427


You can also view these details online on the PSI website:

http://www.psidev.info/index.php?q=node/313


Best regards,

lnnrt.

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Teleconference Tuesday 19 Feb 2008

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

Dear PSI-MS Enthousiasts,


The next telephone conference for the PSI-MS development group will take 
place on Tuesday, 19 february 2008.

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

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

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427


You can also view these details online on the PSI website:

http://www.psidev.info/index.php?q=node/313


Best regards,

lnnrt.

Re: [Psidev-ms-dev] DTA to mzML conversion

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

Hi Matt and Rune,

Thanks for the comments. I agree that the important information is the 
scan number, since this is what you would like to look up in the raw 
data file. And it doesn't make much sense to have the scan repeated 
twice in the file, so I think we'll go for solution 2 and just keep the 
sourceFileRef to one of the files.
However, since we do have unique spectrum ids there should not be any 
real need to stick to the unique scan number requirement from what I got 
from the indexing discussion, even if it is still in the specs (?). 
Couldn't there be cases when data is collected in different channels 
where the scan numbers are the same in different channels?

Regards

Fredrik

Matthew Chambers skrev:
> Hi Fredrik,
>
> Our group has a converter that does this conversion (to mzXML or mzData 
> currently, not yet mzML, but they all have the same uniqueness 
> constraints on scan numbers and they all support multiple precursors at 
> least in theory); we went with solution 2 because solution 1 is invalid 
> for all the XML formats (i.e. it would need a schema change and that 
> change isn't likely to happen, whereas multiple sourceFileRefs would be 
> understandable). As I understand it, sourceFileRef is optional 
> ("<xs:attribute name="sourceFileRef" type="xs:anyURI" use="optional">"), 
> so if you can't or don't want to encode it correctly, just don't include 
> it. Our converter doesn't even bother to include the sourceFileRefs to 
> the DTAs, it's not helpful information IMO. As long as the conversion is 
> done without data loss, get it over with and then have mercy on your 
> filesystem by deleting the DTAs. ;)
>
> -Matt
>
>
> Fredrik Levander wrote:
>   
>> Hi All,
>>
>> In the Proteios platform we're including converters from some peak list 
>> formats to mzData, and now also to mzML. It is clearly not optimal with 
>> such conversion since instrument settings etcetera are lost. However, I 
>> guess there will be need for such converters if someone wants to use 
>> their old instruments with manufacturer peak picking algorithms.
>>
>> There are sample files generated from DTAs and ProteinLynx by the 
>> converters (0.99.1) at:
>> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML
>>
>> The converters will be part of the new release of the Proteios Software 
>> Environment, but if anyone would like to try them with their files, 
>> there is a standalone package (mzMLconverters.zip) at the address above 
>> which should work under Windows/Linux/OSX with Java 1.5 or higher.
>>
>> Please notice that the output files are not schematically valid since 
>> some terms are still missing in the CV.
>>
>> For the conversion of multiple DTA files to one mzML file there is a 
>> small problem which is related to how lcq_dta generates dta files: If 
>> the charge state of the precursor can not be determined, a spectrum can 
>> result in two DTA files which are identical apart from the precursor. 
>> There are two solutions on how to handle this:
>> 1) Two spectra, with the same scanNumber but different spectrum Ids (The 
>> solution used by the current converter)
>> 2) One spectrum, two precursors. However, this will not work with the 
>> current schema since there can only be one sourceFileRef for a spectrum.
>> Do you all think solution 1 is fine, or is there a better solution? 
>> Solution 2 seems to need schema changes.
>> Other comments are also welcome
>>
>> Thanks,
>>
>> Fredrik
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Thank you for pointing that out, Fredrik.  Please ignore my last post.

A couple of general CV terms for "type" should be fine.  Everything I
was talking about should go in <dataProcessing>.



Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Fredrik Levander
Sent: Thursday, February 14, 2008 9:36 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute

Isn't the actual usage of the software described under dataProcessing? 
If the same software suite was used for two processing steps it can be 
defined using two separate dataProcessing elements. I think what Angel 
proposes should work out fine. Ok, there may be some ambiguities s for 
converting mzML to mzXML if a piece of software belongs to several 
software types categories, but apart from that I see no problem. Maybe a

CV term for 'data acquisition' could be added as a MS:1000543 ( data 
processing action), though? Or doesn't data acquisition qualify as 
'processing'?

Fredrik

Matthew Chambers skrev:
> I share your concern Lennart. AFAIK, Xcalibur is the name of a library

> or suite of applications, it's not a single program. It could be
called 
> once for instrument control (acquisition) and another time for peak 
> picking & export to XML (currently only mzData). There may be other 
> processing options in the future. It probably either needs more than
one 
> entry in the CV (one per application in the Xcalibur suite) or we need
a 
> separate group of CV terms to annotate software purpose. The former 
> route would probably be more CV-friendly and intuitive. The latter
route 
> would require all the semantic logic about which software CV terms are

> able to be used for which purpose to be in the validator or in client 
> software, a bad idea IMO.
>
> -Matt
>
>
> Lennart Martens wrote:
>   
>> Hi Angel,
>>
>>
>>   
>>     
>>> I would have thought the ontology entry for XCalibur would have 
>>> qualified it as acquisition software (e.g. this should have been
encoded 
>>> into the CV element and hence referencing the accession MS:1000532
would 
>>> suffice to identify it as acquisition software.)
>>>     
>>>       
>> Seems like a very reasonable suggestion to me. Currently not
implemented 
>> in the CV, but I'll make another tentative note on CV development.
>>
>> One thing that I just thought of: what if a piece of software can 
>> perform multiple functions (i.e.: 'acquisition' as well as
'peakpicking' 
>> -- doable in the CV through simple multi-parenting), but is used in
only 
>> one capacity (say 'acquisition') while another piece of software is
used 
>> for the other functionality (e.g., I used 'Mascot Distiller' for 
>> 'peakpicking').
>>
>> Do we want to keep track of such things, and is this possibly an 
>> argument against CV encoding here?
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>>   
>>     
>>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>>> <len...@eb... <mailto:len...@eb...>>
wrote:
>>>
>>>     Hi Darren, hi PSI-MS enthousiasts,
>>>
>>>
>>>     I have included the ability to use cvParams in the 'software'
element in
>>>     a new schema iteration as per your suggestion.
>>>     Find it here:
>>>
>>>
http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>>
<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>>
>>>     Kessner, Darren E. wrote:
>>>      > Hi all,
>>>      >
>>>      >
>>>      >
>>>      > Please excuse me if this has been discussed before.
>>>      >
>>>      >
>>>      >
>>>      > In mzXML, the <software> element is encoded as follows:
>>>      >
>>>      >     <software type="acquisition"
>>>      >
>>>      >                    name="Xcalibur"
>>>      >
>>>      >                    version="1.3 alpha 8"/>
>>>      >
>>>      >
>>>      >
>>>      > In mzML, we have:
>>>      >
>>>      >     <software id="Xcalibur">
>>>      >
>>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>>      > name="Xcalibur" version="2.0.5"/>
>>>      >
>>>      >     </software>
>>>      >
>>>      >
>>>      >
>>>      > Note that the name and version are encodable, but there is no
>>>     convenient
>>>      > place to save the "type" attribute, since the <software>
element does
>>>      > not have <cvParam> or <userParam> sub-elements.
>>>     
>>>       
>>
------------------------------------------------------------------------
-
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

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

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

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Isn't the actual usage of the software described under dataProcessing? 
If the same software suite was used for two processing steps it can be 
defined using two separate dataProcessing elements. I think what Angel 
proposes should work out fine. Ok, there may be some ambiguities s for 
converting mzML to mzXML if a piece of software belongs to several 
software types categories, but apart from that I see no problem. Maybe a 
CV term for 'data acquisition' could be added as a MS:1000543 ( data 
processing action), though? Or doesn't data acquisition qualify as 
'processing'?

Fredrik

Matthew Chambers skrev:
> I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
> or suite of applications, it's not a single program. It could be called 
> once for instrument control (acquisition) and another time for peak 
> picking & export to XML (currently only mzData). There may be other 
> processing options in the future. It probably either needs more than one 
> entry in the CV (one per application in the Xcalibur suite) or we need a 
> separate group of CV terms to annotate software purpose. The former 
> route would probably be more CV-friendly and intuitive. The latter route 
> would require all the semantic logic about which software CV terms are 
> able to be used for which purpose to be in the validator or in client 
> software, a bad idea IMO.
>
> -Matt
>
>
> Lennart Martens wrote:
>   
>> Hi Angel,
>>
>>
>>   
>>     
>>> I would have thought the ontology entry for XCalibur would have 
>>> qualified it as acquisition software (e.g. this should have been encoded 
>>> into the CV element and hence referencing the accession MS:1000532 would 
>>> suffice to identify it as acquisition software.)
>>>     
>>>       
>> Seems like a very reasonable suggestion to me. Currently not implemented 
>> in the CV, but I'll make another tentative note on CV development.
>>
>> One thing that I just thought of: what if a piece of software can 
>> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
>> -- doable in the CV through simple multi-parenting), but is used in only 
>> one capacity (say 'acquisition') while another piece of software is used 
>> for the other functionality (e.g., I used 'Mascot Distiller' for 
>> 'peakpicking').
>>
>> Do we want to keep track of such things, and is this possibly an 
>> argument against CV encoding here?
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>>   
>>     
>>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>>> <len...@eb... <mailto:len...@eb...>> wrote:
>>>
>>>     Hi Darren, hi PSI-MS enthousiasts,
>>>
>>>
>>>     I have included the ability to use cvParams in the 'software' element in
>>>     a new schema iteration as per your suggestion.
>>>     Find it here:
>>>
>>>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>>
>>>     Kessner, Darren E. wrote:
>>>      > Hi all,
>>>      >
>>>      >
>>>      >
>>>      > Please excuse me if this has been discussed before.
>>>      >
>>>      >
>>>      >
>>>      > In mzXML, the <software> element is encoded as follows:
>>>      >
>>>      >     <software type="acquisition"
>>>      >
>>>      >                    name="Xcalibur"
>>>      >
>>>      >                    version="1.3 alpha 8"/>
>>>      >
>>>      >
>>>      >
>>>      > In mzML, we have:
>>>      >
>>>      >     <software id="Xcalibur">
>>>      >
>>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>>      > name="Xcalibur" version="2.0.5"/>
>>>      >
>>>      >     </software>
>>>      >
>>>      >
>>>      >
>>>      > Note that the name and version are encodable, but there is no
>>>     convenient
>>>      > place to save the "type" attribute, since the <software> element does
>>>      > not have <cvParam> or <userParam> sub-elements.
>>>     
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>   
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Thanks for adding that, Lennart.  I like the idea of cvParams to
annotate what the software did to create the file.

One use case that we have is a conversion (say RAW -> mzML) by a single
program with various modules that may be turned on or off (centroiding,
peak picking, recalibration, precursor recalculation, etc.).  I think it
is very useful to record which of these modules was used during the
creation of the mzML file. 

Another thing from a maintainability perspective:  software will add
functionality as it grows, so I don't think it's a good idea to
pigeon-hole it via parenting in the CV.  It will be much more convenient
to add cvParam annotations for future versions of the software than to
request a CV change.  In fact, changing the CV parents may be valid for
a new version of a program, but then may be incorrect/misleading when an
old version is used.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, February 14, 2008 8:15 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute

I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
or suite of applications, it's not a single program. It could be called 
once for instrument control (acquisition) and another time for peak 
picking & export to XML (currently only mzData). There may be other 
processing options in the future. It probably either needs more than one

entry in the CV (one per application in the Xcalibur suite) or we need a

separate group of CV terms to annotate software purpose. The former 
route would probably be more CV-friendly and intuitive. The latter route

would require all the semantic logic about which software CV terms are 
able to be used for which purpose to be in the validator or in client 
software, a bad idea IMO.

-Matt


Lennart Martens wrote:
> Hi Angel,
>
>
>   
>> I would have thought the ontology entry for XCalibur would have 
>> qualified it as acquisition software (e.g. this should have been
encoded 
>> into the CV element and hence referencing the accession MS:1000532
would 
>> suffice to identify it as acquisition software.)
>>     
>
> Seems like a very reasonable suggestion to me. Currently not
implemented 
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can 
> perform multiple functions (i.e.: 'acquisition' as well as
'peakpicking' 
> -- doable in the CV through simple multi-parenting), but is used in
only 
> one capacity (say 'acquisition') while another piece of software is
used 
> for the other functionality (e.g., I used 'Mascot Distiller' for 
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an 
> argument against CV encoding here?
>
>
> Cheers,
>
> lnnrt.
>
>   
>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>> <len...@eb... <mailto:len...@eb...>> wrote:
>>
>>     Hi Darren, hi PSI-MS enthousiasts,
>>
>>
>>     I have included the ability to use cvParams in the 'software'
element in
>>     a new schema iteration as per your suggestion.
>>     Find it here:
>>
>>
http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>
<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>
>>     Kessner, Darren E. wrote:
>>      > Hi all,
>>      >
>>      >
>>      >
>>      > Please excuse me if this has been discussed before.
>>      >
>>      >
>>      >
>>      > In mzXML, the <software> element is encoded as follows:
>>      >
>>      >     <software type="acquisition"
>>      >
>>      >                    name="Xcalibur"
>>      >
>>      >                    version="1.3 alpha 8"/>
>>      >
>>      >
>>      >
>>      > In mzML, we have:
>>      >
>>      >     <software id="Xcalibur">
>>      >
>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>      > name="Xcalibur" version="2.0.5"/>
>>      >
>>      >     </software>
>>      >
>>      >
>>      >
>>      > Note that the name and version are encodable, but there is no
>>     convenient
>>      > place to save the "type" attribute, since the <software>
element does
>>      > not have <cvParam> or <userParam> sub-elements.
>>     
>
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

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

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

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
or suite of applications, it's not a single program. It could be called 
once for instrument control (acquisition) and another time for peak 
picking & export to XML (currently only mzData). There may be other 
processing options in the future. It probably either needs more than one 
entry in the CV (one per application in the Xcalibur suite) or we need a 
separate group of CV terms to annotate software purpose. The former 
route would probably be more CV-friendly and intuitive. The latter route 
would require all the semantic logic about which software CV terms are 
able to be used for which purpose to be in the validator or in client 
software, a bad idea IMO.

-Matt


Lennart Martens wrote:
> Hi Angel,
>
>
>   
>> I would have thought the ontology entry for XCalibur would have 
>> qualified it as acquisition software (e.g. this should have been encoded 
>> into the CV element and hence referencing the accession MS:1000532 would 
>> suffice to identify it as acquisition software.)
>>     
>
> Seems like a very reasonable suggestion to me. Currently not implemented 
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can 
> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
> -- doable in the CV through simple multi-parenting), but is used in only 
> one capacity (say 'acquisition') while another piece of software is used 
> for the other functionality (e.g., I used 'Mascot Distiller' for 
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an 
> argument against CV encoding here?
>
>
> Cheers,
>
> lnnrt.
>
>   
>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>> <len...@eb... <mailto:len...@eb...>> wrote:
>>
>>     Hi Darren, hi PSI-MS enthousiasts,
>>
>>
>>     I have included the ability to use cvParams in the 'software' element in
>>     a new schema iteration as per your suggestion.
>>     Find it here:
>>
>>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>
>>     Kessner, Darren E. wrote:
>>      > Hi all,
>>      >
>>      >
>>      >
>>      > Please excuse me if this has been discussed before.
>>      >
>>      >
>>      >
>>      > In mzXML, the <software> element is encoded as follows:
>>      >
>>      >     <software type="acquisition"
>>      >
>>      >                    name="Xcalibur"
>>      >
>>      >                    version="1.3 alpha 8"/>
>>      >
>>      >
>>      >
>>      > In mzML, we have:
>>      >
>>      >     <software id="Xcalibur">
>>      >
>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>      > name="Xcalibur" version="2.0.5"/>
>>      >
>>      >     </software>
>>      >
>>      >
>>      >
>>      > Note that the name and version are encodable, but there is no
>>     convenient
>>      > place to save the "type" attribute, since the <software> element does
>>      > not have <cvParam> or <userParam> sub-elements.
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

On Thu, Feb 14, 2008 at 10:50 AM, Lennart Martens <len...@eb...>
wrote:

> Hi Angel,
>
>
> > I would have thought the ontology entry for XCalibur would have
> > qualified it as acquisition software (e.g. this should have been encoded
> > into the CV element and hence referencing the accession MS:1000532 would
> > suffice to identify it as acquisition software.)
>
> Seems like a very reasonable suggestion to me. Currently not implemented
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can
> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking'
> -- doable in the CV through simple multi-parenting), but is used in only
> one capacity (say 'acquisition') while another piece of software is used
> for the other functionality (e.g., I used 'Mascot Distiller' for
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an
> argument against CV encoding here?
>

meh... As long as it fulfills the role in the from where it is referenced, I
see no problem with software that has multiple functionality.

-angel

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Hi Angel,


> I would have thought the ontology entry for XCalibur would have 
> qualified it as acquisition software (e.g. this should have been encoded 
> into the CV element and hence referencing the accession MS:1000532 would 
> suffice to identify it as acquisition software.)

Seems like a very reasonable suggestion to me. Currently not implemented 
in the CV, but I'll make another tentative note on CV development.

One thing that I just thought of: what if a piece of software can 
perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
-- doable in the CV through simple multi-parenting), but is used in only 
one capacity (say 'acquisition') while another piece of software is used 
for the other functionality (e.g., I used 'Mascot Distiller' for 
'peakpicking').

Do we want to keep track of such things, and is this possibly an 
argument against CV encoding here?


Cheers,

lnnrt.

> 
> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
> <len...@eb... <mailto:len...@eb...>> wrote:
> 
>     Hi Darren, hi PSI-MS enthousiasts,
> 
> 
>     I have included the ability to use cvParams in the 'software' element in
>     a new schema iteration as per your suggestion.
>     Find it here:
> 
>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
> 
>     Kessner, Darren E. wrote:
>      > Hi all,
>      >
>      >
>      >
>      > Please excuse me if this has been discussed before.
>      >
>      >
>      >
>      > In mzXML, the <software> element is encoded as follows:
>      >
>      >     <software type="acquisition"
>      >
>      >                    name="Xcalibur"
>      >
>      >                    version="1.3 alpha 8"/>
>      >
>      >
>      >
>      > In mzML, we have:
>      >
>      >     <software id="Xcalibur">
>      >
>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>      > name="Xcalibur" version="2.0.5"/>
>      >
>      >     </software>
>      >
>      >
>      >
>      > Note that the name and version are encodable, but there is no
>     convenient
>      > place to save the "type" attribute, since the <software> element does
>      > not have <cvParam> or <userParam> sub-elements.

[Psidev-ms-dev] Schema error for SoftwareType

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

Just saw what may be an error in either the documentation or in the schema:

<xs:complexType name="SourceFileType"> has an id attribute:
<xs:attribute name="id" type="xs:string" use="required">

<xs:attribute name="sourceFileRef" type="xs:anyURI" use="optional"> is supposed to be a URI, but it should reference the 'id' which is a string? That doesn't make sense.
<xs:documentation>This attribute can optionally  reference the 'id' of the appropriate SourceFileType.</xs:documentation>

Actually, looking a little closer, a lot of the Ref types (but not all) use xs:anyURI to point to an id attribute which is a string. What is the rationale for this? Out-of-file referencing?


-Matt

Re: [Psidev-ms-dev] DTA to mzML conversion

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

Hi Fredrik,

Our group has a converter that does this conversion (to mzXML or mzData 
currently, not yet mzML, but they all have the same uniqueness 
constraints on scan numbers and they all support multiple precursors at 
least in theory); we went with solution 2 because solution 1 is invalid 
for all the XML formats (i.e. it would need a schema change and that 
change isn't likely to happen, whereas multiple sourceFileRefs would be 
understandable). As I understand it, sourceFileRef is optional 
("<xs:attribute name="sourceFileRef" type="xs:anyURI" use="optional">"), 
so if you can't or don't want to encode it correctly, just don't include 
it. Our converter doesn't even bother to include the sourceFileRefs to 
the DTAs, it's not helpful information IMO. As long as the conversion is 
done without data loss, get it over with and then have mercy on your 
filesystem by deleting the DTAs. ;)

-Matt


Fredrik Levander wrote:
> Hi All,
>
> In the Proteios platform we're including converters from some peak list 
> formats to mzData, and now also to mzML. It is clearly not optimal with 
> such conversion since instrument settings etcetera are lost. However, I 
> guess there will be need for such converters if someone wants to use 
> their old instruments with manufacturer peak picking algorithms.
>
> There are sample files generated from DTAs and ProteinLynx by the 
> converters (0.99.1) at:
> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML
>
> The converters will be part of the new release of the Proteios Software 
> Environment, but if anyone would like to try them with their files, 
> there is a standalone package (mzMLconverters.zip) at the address above 
> which should work under Windows/Linux/OSX with Java 1.5 or higher.
>
> Please notice that the output files are not schematically valid since 
> some terms are still missing in the CV.
>
> For the conversion of multiple DTA files to one mzML file there is a 
> small problem which is related to how lcq_dta generates dta files: If 
> the charge state of the precursor can not be determined, a spectrum can 
> result in two DTA files which are identical apart from the precursor. 
> There are two solutions on how to handle this:
> 1) Two spectra, with the same scanNumber but different spectrum Ids (The 
> solution used by the current converter)
> 2) One spectrum, two precursors. However, this will not work with the 
> current schema since there can only be one sourceFileRef for a spectrum.
> Do you all think solution 1 is fine, or is there a better solution? 
> Solution 2 seems to need schema changes.
> Other comments are also welcome
>
> Thanks,
>
> Fredrik
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] DTA to mzML conversion

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

Isn't it required that scan numbers are unique and increasing within a run?

Is it necessary for your scan numbers to be the same?

-- Rune

Fredrik Levander wrote:
> For the conversion of multiple DTA files to one mzML file there is a 
> small problem which is related to how lcq_dta generates dta files: If 
> the charge state of the precursor can not be determined, a spectrum can 
> result in two DTA files which are identical apart from the precursor. 
> There are two solutions on how to handle this:
> 1) Two spectra, with the same scanNumber but different spectrum Ids (The 
> solution used by the current converter)
> 2) One spectrum, two precursors. However, this will not work with the 
> current schema since there can only be one sourceFileRef for a spectrum.
> Do you all think solution 1 is fine, or is there a better solution? 
> Solution 2 seems to need schema changes.
> Other comments are also welcome
>   

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

I would have thought the ontology entry for XCalibur would have qualified it
as acquisition software (e.g. this should have been encoded into the CV
element and hence referencing the accession MS:1000532 would suffice to
identify it as acquisition software.)
-angel

On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens <len...@eb...>
wrote:

> Hi Darren, hi PSI-MS enthousiasts,
>
>
> I have included the ability to use cvParams in the 'software' element in
> a new schema iteration as per your suggestion.
> Find it here:
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>
> Kessner, Darren E. wrote:
> > Hi all,
> >
> >
> >
> > Please excuse me if this has been discussed before.
> >
> >
> >
> > In mzXML, the <software> element is encoded as follows:
> >
> >     <software type="acquisition"
> >
> >                    name="Xcalibur"
> >
> >                    version="1.3 alpha 8"/>
> >
> >
> >
> > In mzML, we have:
> >
> >     <software id="Xcalibur">
> >
> >         <softwareParam cvLabel="MS" accession="MS:1000532"
> > name="Xcalibur" version="2.0.5"/>
> >
> >     </software>
> >
> >
> >
> > Note that the name and version are encodable, but there is no convenient
> > place to save the "type" attribute, since the <software> element does
> > not have <cvParam> or <userParam> sub-elements.
> >
> >
>
>

[Psidev-ms-dev] DTA to mzML conversion

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

Hi All,

In the Proteios platform we're including converters from some peak list 
formats to mzData, and now also to mzML. It is clearly not optimal with 
such conversion since instrument settings etcetera are lost. However, I 
guess there will be need for such converters if someone wants to use 
their old instruments with manufacturer peak picking algorithms.

There are sample files generated from DTAs and ProteinLynx by the 
converters (0.99.1) at:
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML

The converters will be part of the new release of the Proteios Software 
Environment, but if anyone would like to try them with their files, 
there is a standalone package (mzMLconverters.zip) at the address above 
which should work under Windows/Linux/OSX with Java 1.5 or higher.

Please notice that the output files are not schematically valid since 
some terms are still missing in the CV.

For the conversion of multiple DTA files to one mzML file there is a 
small problem which is related to how lcq_dta generates dta files: If 
the charge state of the precursor can not be determined, a spectrum can 
result in two DTA files which are identical apart from the precursor. 
There are two solutions on how to handle this:
1) Two spectra, with the same scanNumber but different spectrum Ids (The 
solution used by the current converter)
2) One spectrum, two precursors. However, this will not work with the 
current schema since there can only be one sourceFileRef for a spectrum.
Do you all think solution 1 is fine, or is there a better solution? 
Solution 2 seems to need schema changes.
Other comments are also welcome

Thanks,

Fredrik

Re: [Psidev-ms-dev] a few more CV name issues

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

Hi Darren,


> 1) exact_synonym same as name (except for capitalization):
> 
> [Term]
> id: MS:1000114
> name: microchannel plate detector
> def: ...
> exact_synonym: "Microchannel Plate Detector" []
> exact_synonym: "multichannel plate" []
> is_a: MS:1000026 ! detector type

I believe this one is intentional so I'm unsure about whether to record 
it as 'to correct' (thoughts anyone?), but the rest is certainly flagged 
now!


Thanks!

Cheers,

lnnrt.
> 
>  
> 
>  
> 
> 2) near name collision with exact_synonym:
> 
>  
> 
> [Term]
> 
> id: MS:1000270
> 
> name: multiple stage mass spectrometry
> 
> def: ...
> 
> exact_synonym: "MSn" []
> 
> is_a: MS:1000445 ! sequential m/z separation method ?
> 
>  
> 
> [Term]
> 
> id: MS:1000580
> 
> name: MSn spectrum
> 
> def: ...
> 
> exact_synonym: "Multiple-Stage Mass Spectrometry" []
> 
> is_a: MS:1000524 ! data file content
> 
> is_a: MS:1000559 ! spectrum type
> 
>  
> 
>  
> 
> 3) some term names have ? at end -- I assume this is to flag for 
> reconsideration

[Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Hi Darren, hi PSI-MS enthousiasts,


I have included the ability to use cvParams in the 'software' element in 
a new schema iteration as per your suggestion.
Find it here:

http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd


I have also included an example instance document that is valid against 
this schema (do note that it currently uses a made-up CV term for the 
software type). Note that this example instance also has the binary 
array thingie at software level, and is essentially a hack of tiny1.
Find it here:

http://www.ebi.ac.uk/~lmartens/mzML/20080214_example_mzML0.99.9_SNAPSHOT.mzML

Sorry for the convoluted filenames, but it'll help keep things clear and 
separated, and somewhat archived.

One more note: if we get a consensus for this approach, we should 
probably extend the CV as well, so I'm already making a note about 
potentially including software types in a dedicated branch in the CV -- 
tentatively, of course.


Cheers,

lnnrt.

Kessner, Darren E. wrote:
> Hi all,
> 
>  
> 
> Please excuse me if this has been discussed before. 
> 
>  
> 
> In mzXML, the <software> element is encoded as follows:
> 
>     <software type="acquisition"
> 
>                    name="Xcalibur"
> 
>                    version="1.3 alpha 8"/>
> 
>  
> 
> In mzML, we have:
> 
>     <software id="Xcalibur">
> 
>         <softwareParam cvLabel="MS" accession="MS:1000532" 
> name="Xcalibur" version="2.0.5"/>
> 
>     </software>
> 
>  
> 
> Note that the name and version are encodable, but there is no convenient 
> place to save the "type" attribute, since the <software> element does 
> not have <cvParam> or <userParam> sub-elements.
> 
>  
> 
> Currently this causes a loss of this info when converting mzXML->mzML. 
> 
>  
> 
> If there is a good place to put this attribute, the conversion mzXML -> 
> mzML -> mzXML will be doable with no loss of information.  (I think this 
> is the last missing piece).  Or perhaps it's no great loss?  I don't 
> have a strong attachment to this attribute -- just thought it would be 
> nice to be able to get the same mzXML after converting to and from mzML...
> 
>  
> 
> Thoughts?
> 
>  
> 
>  
> 
> Darren
> 
>  
> 
>  
> 
>  
> 
> Darren Kessner
> 
> Scientific Programmer
> 
> Dar...@cs... <mailto:Dar...@cs...>
> 
> 310-423-9538
> 
>  
> 
> Spielberg Family Center for Applied Proteomics
> 
> Cedars-Sinai Medical Center
> 
> http://www.sfcap.cshs.org/
> 
>  
> 
>  
> 
> IMPORTANT WARNING: This message is intended for the use of the person or 
> entity to which it is addressed and may contain information that is 
> privileged and confidential, the disclosure of which is governed by
> applicable law. If the reader of this message is not the intended 
> recipient, or the employee or agent responsible for delivering it to the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this information is STRICTLY PROHIBITED.
> 
> If you have received this message in error, please notify us immediately
> by calling (310) 423-6428 and destroy the related message. Thank You for 
> your cooperation.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT binaryArrayData lengths

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

Hi Angel,


> quick validation error, the xml namespace has a different version than 
> target schema spec, still @ 0.99.1

Oooops :). Thanks for pointing that out! I've put a fixed version online 
now, replacing the previous file. My apologies for the glitch!


BTW: to all, the fact that I put these 'SNAPSHOT' schemata up doesn't 
mean that they convey some sort of decision - they just show what 
certain decisions might look like, in case people want to experiment 
with them. Additionally, we can always reverse changes at any point.

So treat them as 'stuff to play with' rather than anything else. I will 
however try to follow the general consensus view as we go along (I'm 
sure that even when decisions are ultimately made, some of these will 
remain somewhat contested, and this is of course not a bad thing -- 
it'll be food for thought for what we want to do next :)).


Cheers,

lnnrt.

> 
> is:
> xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.1"
> 
> should be:
> 
> xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.9"
> 
> 
> -angel
> 
> On Feb 13, 2008 9:28 AM, Lennart Martens <len...@eb... 
> <mailto:len...@eb...>> wrote:
> 
>     Dear PSI-MS enthousiasts,
> 
> 
>     I have started to update the mzML schema as per the progress we're
>     making.
> 
>     As the basis schema, I have used the reformatted version helpfully
>     contributed by Phil Jones and Richard Cote (I believe no one objects
>     against a schema form that facilitates code generation).
> 
>     I will post all (incremental!) updates I make to the schema as we go
>     along, and these will be called:
> 
>     YYYYMMdd_mzML0.99.9_SNAPSHOT.xsd
> 
>     And the subject line will look like the one in this mail, with the end
>     bit indicating the latest change.
> 
>     A download link to the latest schema version will also be provided,
>     current one is:
> 
>     http://www.ebi.ac.uk/~lmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd
>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd>
> 
> 
>     This one has the binaryArrayData length as a Spectrum element attribute,
>     and slightly revised documentation accordingly.
> 
> 
>     Cheers,
> 
>     lnnrt.
> 
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2008.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     _______________________________________________
>     Psidev-ms-dev mailing list
>     Psi...@li...
>     <mailto:Psi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] a few more CV name issues

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

1) exact_synonym same as name (except for capitalization):

 

[Term]

id: MS:1000114

name: microchannel plate detector

def: ...

exact_synonym: "Microchannel Plate Detector" []

exact_synonym: "multichannel plate" []

is_a: MS:1000026 ! detector type

 

 

2) near name collision with exact_synonym:

 

[Term]

id: MS:1000270

name: multiple stage mass spectrometry

def: ...

exact_synonym: "MSn" []

is_a: MS:1000445 ! sequential m/z separation method ?

 

[Term]

id: MS:1000580

name: MSn spectrum

def: ...

exact_synonym: "Multiple-Stage Mass Spectrometry" []

is_a: MS:1000524 ! data file content

is_a: MS:1000559 ! spectrum type

 

 

3) some term names have ? at end -- I assume this is to flag for
reconsideration

 

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

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

 

 

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

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