psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] mzML's binary arrays

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

Hi all,

i think there should be a term 'named custom array' (we can discuss about the name) that contains the name of the array in the 'value' attribute.
Putting the name in the UserParam is too unstructured in my opinion. There won't be two tools that store the name in the same way...

<binaryDataArray encodedLength="12">
  <cvParam cvRef="MS" accession="MS:1000523" name="64-bit float" value=""/>
  <cvParam cvRef="MS" accession="MS:1000576" name="no compression" value=""/>
  <cvParam cvRef="MS" accession="MS:????????" name="named custom array" value="full width at half max"/>
  <binary>AAAAAAAANEAAAAAAAA</binary>
</binaryDataArray>

What do you think?

Best,
  Marc

> If the supplemental array is defined in the CV (right now it's just m/z, 
> time, and intensity), you can use a CV term. Otherwise, you'll have to 
> use a userParam. If it's a kind of array you think should be in the CV, 
> you can make that suggestion as well. I know we should probably put 
> transient array in there at least (time array can be used for time 
> domain data). For something like charge states, that's probably going to 
> stay a userParam AFAIK.

[Psidev-ms-dev] PSI-MSS WG call minutes

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

Hi everyone, here are the minutes for the PSI-MSS WG telecon of
2008-06-23.

 

Present: Matt, Darren, Eric

 

- schema

+ No major schema changes planned

+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change

+ One desirable addition is retention time in the index

+ Current examples show:
xmlns="http://psi.hupo.org/schema_revision/mzML_1.0.0"

  What should it be instead? Perhaps:
xmlns="http://psidev.info/schemas/mzML_1.0.0"

  Poll SG to get an answer

- Johannes Junker asks about supDataArrays. Should be fine as is. Ask
for clarification

 

- MIAPE example document?

+ Done and posted except for switching criteria and parameters for
creating peaklists

+ Pierre-Alain and Jim will get together and finish this

 

- CV status

+ Consider that we may need to have a parent term to contain (m/z, mass,
ppm) but not yet

+ Darren's email: 1 - fine, 2 - fine,

   3: Darren will add xsd:string to the few terms that do need. Does
such a term allow empty string ""

   4 - fine, 5 -fine, 6 - fine.

   At some point, someone should deal with everything in purgatory

   7 - rename MS "unit" to "specialized mass spectrometry unit" which is
child of UO "unit"

   8 - put UO "energy unit" under MS "intensity unit". Hm, this is
tricky. Darren will write up a proposal.

   9 - okay to be wordy and precise

+ Matt email: redo, removing duplicates. No lists, but do include the
singular concepts and repropose

+ Matt will remove all entries: synonym: "<new synonym>" RELATED []

+ Not sure what to do with Wilfred's suggestions. Ask how he wants to
use those.

+ Matt will remove extraneous \n in definitions

                               

- CV template updates to vendors

+ What's up with Thermo CVTerms and instrument attributes Excel sheet?

+ Start another round of vendor updates

 

- documentation

+ Documentation is up to date

 

- website

+ Post the mapping file directly

+ Should we set up an mzML.org?

+ Instead of maintaining a separate page, set up a redirect?

 

- mzML support information table

+ Insilicos viewer is now released supporting mzML

+ Definitely post it on the web site

 

- validator

+ Validator will be a little delayed. There are many back-end changes
due to the MI group

+ Does the validator check that if there is an acquisition list, then
there would be a combination type (like sum of spectra) provided?

+ We will allow spectrum representation (like centroid/profile) in the
fileContent section

+ Need to incorporate the information in the OBO file (datatypes and
units)

+ Need to fix up the mapping file rules

+ Lennart hopes to have coding update done at the end of this week and
then we need help from everyone to update the mapping file

+ Maybe need a rule that if a spectrum and if a mass spectrum, the need
mz array and similar

+ Need some sort of unit for intensity arrays

+ At the moment, we do not require any units for the array type. We
should add that.

+ Darren will explore that while adding has_units to CV

 

- example files

+ Matt will take a stab at MALDI example and post it

+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage

+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML.
Eric will post.

+ Matt will generate an example MGF -> mzML using pwiz and post

+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)

 

- Amsterdam

+ Pierre-Alain will do the presentation of the mzML talk during main
conference

+ PSI session during the congress at Sunday 17th 9:30a-12

+ Tentative presenter at PSI session is Jim Shofstahl with backups of
Randy and Pierre-Alain

 

- Next call

+ Switch call time to *Monday* morning 9am PDT due to conflicts

+ Same time in two weeks on July 7

 

 

Re: [Psidev-ms-dev] mzML's binary arrays

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

Nevermind, there already are terms for charge and signal to noise arrays. :)

-Matt


Matthew Chambers wrote:
> Hi Johannes,
>
> If the supplemental array is defined in the CV (right now it's just m/z, 
> time, and intensity), you can use a CV term. Otherwise, you'll have to 
> use a userParam. If it's a kind of array you think should be in the CV, 
> you can make that suggestion as well. I know we should probably put 
> transient array in there at least (time array can be used for time 
> domain data). For something like charge states, that's probably going to 
> stay a userParam AFAIK.
>
> -Matt
>
>
> Johannes Junker wrote:
>   
>> Hi there,
>>
>> I'm trying to implement mzML 1.0.0 and I just stumbled across a problem: 
>> I don't understand how the supDataArrays of mzData are represented in 
>> mzML. Obviously there are two obligatory binary arrays for m/z and 
>> intensity (which can be identified by the corresponding CV terms for m/z 
>> and intensity, respectively). But I don't know how to identify the other 
>> arrays that might follow. Is there a CV term for the name of such a 
>> supplementary binary array? I couldn't find anything. How does this work?
>>
>> It would be very nice if you could help me with this!!
>>
>> Thanks in advance!
>>
>> Best regards,
>> Johannes Junker
>>     

Re: [Psidev-ms-dev] mzML's binary arrays

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

Hi Johannes,

If the supplemental array is defined in the CV (right now it's just m/z, 
time, and intensity), you can use a CV term. Otherwise, you'll have to 
use a userParam. If it's a kind of array you think should be in the CV, 
you can make that suggestion as well. I know we should probably put 
transient array in there at least (time array can be used for time 
domain data). For something like charge states, that's probably going to 
stay a userParam AFAIK.

-Matt


Johannes Junker wrote:
> Hi there,
>
> I'm trying to implement mzML 1.0.0 and I just stumbled across a problem: 
> I don't understand how the supDataArrays of mzData are represented in 
> mzML. Obviously there are two obligatory binary arrays for m/z and 
> intensity (which can be identified by the corresponding CV terms for m/z 
> and intensity, respectively). But I don't know how to identify the other 
> arrays that might follow. Is there a CV term for the name of such a 
> supplementary binary array? I couldn't find anything. How does this work?
>
> It would be very nice if you could help me with this!!
>
> Thanks in advance!
>
> Best regards,
> Johannes Junker
>
>   

[Psidev-ms-dev] CV terms for fundamental mzML concepts

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

Hi all,

I proposed this on the vocab list and didn't get any complaints so I 
came up with a draft to add to the CV. I copied the definitions straight 
out of the schema (for the most part), with a few modifications. I don't 
think these definitions are good enough (especially the empty ones ;) ), 
so that indicates to me a need for improved documentation in the schema. 
I also am not sure whether to include the various "list" types in the 
CV. In the schema, the lists are often better documented than the list's 
members.

-Matt


[Term]
id: MS:1000740
name: fundamental concept
def: "Describes an important concept in Mass Spectrometry that is 
intended for documentation only; not intended for use in data files." 
[PSI:MS]

[Term]
id: MS:1000741
name: run
def: "Corresponds to a single, consecutive and coherent set of scans on 
an instrument." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000742
name: sample
def: "Expansible description of the sample used to generate the 
dataset." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000743
name: source file
def: "Description of the source file, including location and type." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000744
name: target list
def: "Target list (or 'inclusion list') configured prior to the run." 
[PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000745
name: acquisition settings
def: "Description of the acquisition settings of the instrument prior to 
the start of the run." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000746
name: data processing
def: "Description of the way in which a particular software was used." 
[PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000747
name: software
def: "Software information." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000748
name: instrument configuration
def: "Description of a particular hardware configuration of a mass 
spectrometer. Each configuration must have one (and only one) of the 
three different components used for an analysis. For hybrid instruments, 
such as an LTQ-FT, there must be one configuration for each permutation 
of the components that is used in the document. For software 
configuration, use a ReferenceableParamGroup element." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000749
name: component list
def: "List with the different components used in the mass spectrometer. 
At least one source, one mass analyzer and one detector need to be 
specified." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000750
name: source
def: "A source component." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000751
name: analyzer
def: "A mass analyzer (or mass filter) component." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000752
name: detector
def: "A detector component." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000753
name: spectrum
def: "The structure that captures the generation of a peak list 
(including the underlying acquisitions)." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000754
name: chromatogram
def: "A single chromatogram." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000755
name: spectrum description
def: "Description of the parameters for the mass spectrometer for a 
given acquisition (or list of acquisitions)." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000756
name: acquisition
def: "Scan or acquisition from a raw file used to create a spectrum's 
peak list." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000757
name: precursor
def: "The method of precursor ion selection and activation." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000758
name: activation
def: "The type and energy level used for activation." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000759
name: scan
def: "The instrument's 'run time' parameters." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000760
name: selected ion
def: "" [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000761
name: scan window
def: "Definition of a selection window." [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Term]
id: MS:1000761
name: processing method
def: "" [PSI:MS]
is_a: MS:1000740 ! fundamental concept

[Psidev-ms-dev] mzML's binary arrays

[Johannes J. <dr....@go...>]

Hi there,

I'm trying to implement mzML 1.0.0 and I just stumbled across a problem: 
I don't understand how the supDataArrays of mzData are represented in 
mzML. Obviously there are two obligatory binary arrays for m/z and 
intensity (which can be identified by the corresponding CV terms for m/z 
and intensity, respectively). But I don't know how to identify the other 
arrays that might follow. Is there a CV term for the name of such a 
supplementary binary array? I couldn't find anything. How does this work?

It would be very nice if you could help me with this!!

Thanks in advance!

Best regards,
Johannes Junker

[Psidev-ms-dev] PSI-MSS WG call Monday

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

Hi everyone, the PSI Mass Spectrometry Standards Working Group call is
Monday June 23 at 9am PDT:

 

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

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to review and discuss thoughts from the ASMS
conference and keep the momentum going to try to start pushing
implementation of mzML.

 

Topics:

 

- CV

- Documentation

- Web site

- mzML support information table

- Validator

- Amsterdam

- Next call

 

Thanks,

Eric

 

Re: [Psidev-ms-dev] MS CV now on OBO

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

The OLS still has the old mzData ontology. What is the fate is that? The 
name "PSI-MS" will conflict, but the root namespace won't.

And congrats everyone! :)

-Matt


Eric Deutsch wrote:
>
> Hi everyone, our psi-ms controlled vocabulary is now listed at the OBO 
> Foundry with the namespace “MS”:
>
> http://www.obofoundry.org/
>
> It’s official!
>
> Regards,
>
> Eric
>

[Psidev-ms-dev] MS CV now on OBO

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

Hi everyone, our psi-ms controlled vocabulary is now listed at the OBO
Foundry with the namespace "MS":

 

http://www.obofoundry.org/

 

It's official!

 

Regards,

Eric

 

 

Re: [Psidev-ms-dev] mzML comments

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

Any thoughts regarding the comments below?

For the last point, I would like to propose to add the following terms to 
the controlled vocabulary:

[Term]
id: MS:9999999
name: MS1 scan
def: "The specific scan function or process that records a MS1 spectrum." 
[PSI:MS]
is_a: MS:1000020 ! scanning method

[Term]
id: MS:9999999
name: MSn scan
def: "The specific scan function or process that records a MSn spectrum." 
[PSI:MS]
is_a: MS:1000020 ! scanning method

[Term]
id: MS:9999999
name: precursor ion spectrum
def: "Spectrum generated by scanning precursor m/z while monitoring a 
fixed product m/z" [PSI:MS]
is_a: MS:1000524 ! data file content
is_a: MS:1000559 ! spectrum type

[Term]
id: MS:9999999
name: constant neutral loss spectrum
def: "Spectrum generated by scanning precursor m/z and product m/z 
simultaneously, maintaining a constant difference between the two" 
[PSI:MS]
is_a: MS:1000524 ! data file content
is_a: MS:1000559 ! spectrum type

Thanks,
Wilfred




Wilfred H Tang/FOS/PEC 
05/24/2008 07:03 PM

To
psi...@li...
cc

Subject
mzML comments





I recently looked over the mzML format draft and have a few comments.


Regarding the schema (http://www.sbeams.org/tmp/mzML0.99.12.html):

* For the "cvParam Mapping Rules," I suggest that the number of "musts" be 
decreased significantly (or changed to "mays"). For example, for the 
element <sourceFile>, there's a rule saying: "MUST supply a *child* term 
of MS:1000561 (data file checksum type) one or more times." This sort of 
information does not seem to be critical for downstream processing of mzML 
files and thus doesn't deserve "must" status. There are quite a few 
similar examples.

* For the elements <fileDescription>, <sourceFileList>, <sourceFile>, 
etc., would it make sense to change the name to be more general (such as 
dataSource) to reflect the fact that not all instrument data is stored in 
files? For example, for the Applied Biosystems|MDS Sciex instruments, some 
instruments (such as the QSTAR or QTRAP systems) store data in .wiff 
files, while other instruments (such as the 4700 and 4800 systems) store 
data in an Oracle database.


Regarding the controlled vocabulary (
http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo
):

* Under "spectrum"-->"spectrum representation", the only 2 choices are 
"centroid mass spectrum" and "profile mass spectrum". That doesn't 
adequately capture the full range of spectrum representations. For example 
in addition to centroiding, the data could be de-isotoped, smoothed, 
converted to +1 charge, etc. Also, having just the 2 choices of centroid 
vs. profile is inconsistent with the software processing options listed 
under "data transformation"-->"data processing action", where a much wider 
range of options are listed ("baseline reduction", "charge deconvolution", 
"deisotoping", etc.). It seems desirable to expand the choices under 
"spectrum"-->"spectrum representation" to at least be consistent. 
Alternatively, maybe a slightly different categorization might make sense 
- something like raw data vs. processed data (full data vs. reduced data).

* Under "spectrum"-->"spectrum type", some triple quad-type scans are 
missing - precursor ion (scan Q1, fixed Q3), neutral loss (scan Q1 and Q3 
together with a constant difference between Q1 and Q3).


Please accept my apologies in advance if any of these topics have already 
been discussed/resolved previously, as I am new to this discussion.

Thanks,
Wilfred

[Psidev-ms-dev] Update to the MS CV

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

Hi everyone, I have updated the controlled vocabulary. I have tidied the
unit section:

 

- All unit entries that already have another entry in the Unit Ontology
have been obsoleted

- Remaining unit entries have marginally better definitions

 

What remains is:

 - [energy unit] -> [percent collision energy]

 - [intensity unit] -> [number of counts]

 - [intensity unit] -> [percent of base peak]

 

Maybe the [number of counts] should be obsoleted in favor of the UO term
[count]?

 

Please make sure that your software is not using these terms, or any
term with:

is_obsolete: true

 

Current revision is now:

remark: version: 1.1.0

remark: release date: 2008-06-12

 

Let me know if you have comments or questions.

 

Eric

 

----------------------------------

Eric Deutsch, Ph.D.
Institute for Systems Biology
1441 North 34th Street
Seattle WA 98103
Tel: 206-732-1397
Fax: 206-732-1260
Email: ede...@sy...
WWW:
http://www.systemsbiology.org/Senior_Research_Scientists/Eric_Deutsch

 

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

[Brian P. <bri...@in...>]

Hello All,

 

>> - mzML support information table

 

You can add InsilicosViewer to the list, we've just finished integrating the
latest RAMP+ProteoWizard code for reading mzML.

 

Brian

 

  _____  

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Eric
Deutsch
Sent: Tuesday, June 10, 2008 10:26 AM
To: Mass spectrometry standard development
Cc: Eric Deutsch
Subject: [Psidev-ms-dev] PSI-MSS WG call minutes

 

Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-06-10.

 

Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim

 

- ASMS

+ Douglas Slotta has implemented mzML in their C++ toolkit

+ Jim talked to Steve Musser at FDA. They are considering accepting mzML as
a format to avoid cherry-picked spectra, but it would need some kind of
non-text audit trail information. Randy will talk with Vish about this talk.
Follow up.

+ There was a suggestion at ASMS that we move toward ISO certification for
the standard to promote adoption

+ Users are very positive about a single format

 

- schema

+ No major schema changes planned

+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change

+ One desirable addition is retention time in the index

 

- MIAPE example document?

+ Done and posted except for switching criteria and parameters for creating
peaklists

+ Pierre-Alain and Jim will get together and finish this

 

- CV status

+ Darren has sent a proposal for of datatype and relationship "has_units".
It's good. Proceed with all terms.

+ "scan time" is one example

+ OBO-Edit will write out all terms including imported terms unless told not
to. That can be done with filters.

+ Darren will post a recipe on how to filter out non-MS terms

+ Darren is still figuring out how to get OBO-Edit to write out "import"
statements

+ Darren will email John Richter-Day about that

+ Current CV version is 1.0.0

+ As Darren or anyone makes changes, increment the version number.

+ Darren will try to import the unit ontology from its source

+ Would a side effect of this prevent OBO-Edit from opening a file w/o
Internet? Darren will check

+ Normally all terms going forward now should be deprecated (deleted in
OBO-Edit terms)

+ However, the unit terms could be destroyed. Eric will destroy them.

                               

- CV template updates to vendors

+ Start another round of vendor updates

+ Some software organized by vendor

 

- documentation

+ Documentation is up to date

+ Images in documentation still mention 0.99.12. Should update to 1.0.0

+ Lennart will regenerate embedded figures and send to Eric who will update

 

- website

+ Post the mapping file directly

+ Should we set up an mzML.org?

+ Instead of maintaining a separate page, set up a redirect?

 

- mzML support information table

+ Definitely post it on the web site

+ Bruker will likely support mzML. Find out their plans

 

- validator

+ Validator will be a little delayed. There are many back-end changes due to
the MI group

+ Does the validator check that if there is an acquisition list, then there
would be a combination type (like sum of spectra) provided?

+ We will allow spectrum representation (like centroid/profile) in the
fileContent section

+ Need to incorporate the information in the OBO file (datatypes and units)

+ Need to fix up the mapping file rules

+ Lennart hopes to have coding update done at the end of this week and then
we need help from everyone to update the mapping file

+ Maybe need a rule that if a spectrum and if a mass spectrum, the need mz
array and similar

+ Need some sort of unit for intensity arrays

+ At the moment, we do not require any units for the array type. We should
add that.

+ Darren will explore that while adding has_units to CV

 

- example files

+ Matt will take a stab at MALDI example and post it

+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage

+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric
will post.

+ Matt will generate an example MGF -> mzML using pwiz and post

+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)

 

- Amsterdam

+ Pierre-Alain will do the presentation of the mzML talk during main
conference

+ PSI session during the congress at Sunday 17th 9:30a-12

+ Tentative presenter at PSI session is Jim Shofstahl with backups of Randy
and Pierre-Alain

 

- Next call

+ Switch call time to *Monday* morning 9am PDT due to conflicts

+ Same time in two weeks on June 23rd

 

 

 

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

[Brian P. <bri...@gm...>]

Hello All,

 

>> - mzML support information table

 

You can add InsilicosViewer to the list, we've just finished integrating the
latest RAMP+ProteoWizard code for reading mzML.

 

Brian

 

  _____  

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Eric
Deutsch
Sent: Tuesday, June 10, 2008 10:26 AM
To: Mass spectrometry standard development
Cc: Eric Deutsch
Subject: [Psidev-ms-dev] PSI-MSS WG call minutes

 

Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-06-10.

 

Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim

 

- ASMS

+ Douglas Slotta has implemented mzML in their C++ toolkit

+ Jim talked to Steve Musser at FDA. They are considering accepting mzML as
a format to avoid cherry-picked spectra, but it would need some kind of
non-text audit trail information. Randy will talk with Vish about this talk.
Follow up.

+ There was a suggestion at ASMS that we move toward ISO certification for
the standard to promote adoption

+ Users are very positive about a single format

 

- schema

+ No major schema changes planned

+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change

+ One desirable addition is retention time in the index

 

- MIAPE example document?

+ Done and posted except for switching criteria and parameters for creating
peaklists

+ Pierre-Alain and Jim will get together and finish this

 

- CV status

+ Darren has sent a proposal for of datatype and relationship "has_units".
It's good. Proceed with all terms.

+ "scan time" is one example

+ OBO-Edit will write out all terms including imported terms unless told not
to. That can be done with filters.

+ Darren will post a recipe on how to filter out non-MS terms

+ Darren is still figuring out how to get OBO-Edit to write out "import"
statements

+ Darren will email John Richter-Day about that

+ Current CV version is 1.0.0

+ As Darren or anyone makes changes, increment the version number.

+ Darren will try to import the unit ontology from its source

+ Would a side effect of this prevent OBO-Edit from opening a file w/o
Internet? Darren will check

+ Normally all terms going forward now should be deprecated (deleted in
OBO-Edit terms)

+ However, the unit terms could be destroyed. Eric will destroy them.

                               

- CV template updates to vendors

+ Start another round of vendor updates

+ Some software organized by vendor

 

- documentation

+ Documentation is up to date

+ Images in documentation still mention 0.99.12. Should update to 1.0.0

+ Lennart will regenerate embedded figures and send to Eric who will update

 

- website

+ Post the mapping file directly

+ Should we set up an mzML.org?

+ Instead of maintaining a separate page, set up a redirect?

 

- mzML support information table

+ Definitely post it on the web site

+ Bruker will likely support mzML. Find out their plans

 

- validator

+ Validator will be a little delayed. There are many back-end changes due to
the MI group

+ Does the validator check that if there is an acquisition list, then there
would be a combination type (like sum of spectra) provided?

+ We will allow spectrum representation (like centroid/profile) in the
fileContent section

+ Need to incorporate the information in the OBO file (datatypes and units)

+ Need to fix up the mapping file rules

+ Lennart hopes to have coding update done at the end of this week and then
we need help from everyone to update the mapping file

+ Maybe need a rule that if a spectrum and if a mass spectrum, the need mz
array and similar

+ Need some sort of unit for intensity arrays

+ At the moment, we do not require any units for the array type. We should
add that.

+ Darren will explore that while adding has_units to CV

 

- example files

+ Matt will take a stab at MALDI example and post it

+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage

+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric
will post.

+ Matt will generate an example MGF -> mzML using pwiz and post

+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)

 

- Amsterdam

+ Pierre-Alain will do the presentation of the mzML talk during main
conference

+ PSI session during the congress at Sunday 17th 9:30a-12

+ Tentative presenter at PSI session is Jim Shofstahl with backups of Randy
and Pierre-Alain

 

- Next call

+ Switch call time to *Monday* morning 9am PDT due to conflicts

+ Same time in two weeks on June 23rd

 

 

 

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

[Susanna <sa...@eb...>]

Hi Randy,

could you, please, expand on this....

 > I presented a way of using XML for data submission for the FDA to 
Janet Woodcock
 > who is their Chief Medical Officer and is now head of the drug 
approving CDER group and she
 > was very supportive.

..do you refer to proteomics submissions to FDA?

Thanks,
Susanna

Randy Julian wrote:

>I have met extensively with both the FDA DSI (audit division) and Pharma
>QA Reps (and been audited for GLP compliance at Indigo).  Based on this,
>I suggest we look at a standard data integrity method which leaves the
>document as clear XML.
>
>I have not dug in depth yet, but the XML digital signature standard
>seems like a good place to start.
>
>In essence, I think you encrypt a SHA1 (or MD5) of the document to
>create a Message Authentication Code (MAC) using a Public/Private Key
>Pair.  The traditional key stores should work, but I have not gotten
>further than this.  The receiver decrypts the SHA1 with the public key
>and then compares it to the computed SHA1 of the document.  This would
>protect the entire document and confirm authorship - we might even be
>able to come up with a time-stamp mechanism which would help with IP
>protection use cases.
>
>Since we have created the index schema already, it seems like a good
>place to put additional authentication devices.  I really favor leaving
>the raw data and audit trail itself as normal XML (and readable).
>
>21CFR11 does not suggest that binary encoding is a sufficient method for
>protecting the integrity of data.  You have to have SOPs in place to
>ensure document security even with binary files.  The agency has
>accepted the argument that the degree of difficulty in recreating a
>valid binary file set for a data system lowers the probability for an
>undetected modification, but SOPs have always been required on top of
>this.
>
>I think we have a great opportunity here.  I presented a way of using
>XML for data submission for the FDA to Janet Woodcock who is their Chief
>Medical Officer and is now head of the drug approving CDER group and she
>was very supportive.  It fits very nicely with their Critical Path
>Initiative and also helps the Quality By Design Initiatives, where
>analytical instruments are used in-line during manufacturing to
>continuously monitor processes.
>
>Does anyone have experience with the XML Digital Signature standard?
>
>Randy
>
>
>
>
>
>-----Original Message-----
>From: psi...@li...
>[mailto:psi...@li...] On Behalf Of
>Pierre-Alain Binz
>Sent: Wednesday, June 11, 2008 3:56 AM
>To: Mass spectrometry standard development
>Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes
>
>Inbetween, I have also contacted a world-wide QA in Pharma and asked 
>what they are doing to comply with text documents, across regulation 
>bodies (FDA, ISO, etc). Let's see
>Pierre-Alain
>
>Mike Coleman wrote:
>  
>
>>I agree with your points.
>>
>>As far as I can see, the checksum within the mzML file is not good for
>>anything other than as an additional check that (say) Windows hasn't
>>flipped any bits in the file.  Arguably, this kind of checksumming is
>>barely worth doing, unless you're also checksumming the other parts of
>>the system regularly.  Who among us periodically checksums our
>>instrument software or configuration files, for example?
>>
>>If you're concerned about instrument operators faking results, it
>>seems like the only meaningful bar would be to have the instrument
>>software cryptographically sign the result file.  This would entail
>>all kinds of key management problems that would rule this out in
>>practice (I would think).
>>
>>If you're concerned about downstream people faking the results, my
>>thought would be that you'd checksum (SHA1, etc.) the file at creation
>>or "publication" (the point at which others have access to the file),
>>and then publish that checksum in a "read only" location.  As you say,
>>this is pretty much the method used by thousands currently for file
>>verification.  If you already have a decent backup regime, just
>>backing up the checksums might qualify.  Or you could publish a
>>grand-checksum in the newspaper occasionally, or whatever.
>>
>>Note, though, that for these latter scenarios you specifically *must
>>ignore* the checksum within the file itself, as it is (as you and Jim
>>say) not trustworthy.  Rather, the checksum must be recalculated.
>>
>>I'm not familiar with 21 CFR Part 11, but it would seem that the mzML
>>file itself ought to simply include all of the useful details about
>>what it contains.  Any further audit trail should happen outside of
>>mzML, though--once the file comes off of the instrument, it should
>>never change, in my opinion.
>>
>>Mike
>>
>>
>>    
>>
>------------------------------------------------------------------------
>-
>  
>
>>Check out the new SourceForge.net Marketplace.
>>It's the best place to buy or sell services for
>>just about anything Open Source.
>>http://sourceforge.net/services/buy/index.php
>>_______________________________________________
>>Psidev-ms-dev mailing list
>>Psi...@li...
>>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>  
>>    
>>
>
>------------------------------------------------------------------------
>-
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://sourceforge.net/services/buy/index.php
>_______________________________________________
>Psidev-ms-dev mailing list
>Psi...@li...
>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>-------------------------------------------------------------------------
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://sourceforge.net/services/buy/index.php
>_______________________________________________
>Psidev-ms-dev mailing list
>Psi...@li...
>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>  
>

-- 
Susanna-Assunta Sansone, PhD

NET Project - Coordinator

www.ebi.ac.uk/net-project
	
The European Bioinformatics Institute   email:  sa...@eb...
EMBL Outstation - Hinxton               direct: +44 (0)1223 494 691
Wellcome Trust Genome Campus            fax: +44 (0)1223 492 620
Cambridge CB10 1SD, UK                  room: A229            

  

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

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

I have met extensively with both the FDA DSI (audit division) and Pharma
QA Reps (and been audited for GLP compliance at Indigo).  Based on this,
I suggest we look at a standard data integrity method which leaves the
document as clear XML.

I have not dug in depth yet, but the XML digital signature standard
seems like a good place to start.

In essence, I think you encrypt a SHA1 (or MD5) of the document to
create a Message Authentication Code (MAC) using a Public/Private Key
Pair.  The traditional key stores should work, but I have not gotten
further than this.  The receiver decrypts the SHA1 with the public key
and then compares it to the computed SHA1 of the document.  This would
protect the entire document and confirm authorship - we might even be
able to come up with a time-stamp mechanism which would help with IP
protection use cases.

Since we have created the index schema already, it seems like a good
place to put additional authentication devices.  I really favor leaving
the raw data and audit trail itself as normal XML (and readable).

21CFR11 does not suggest that binary encoding is a sufficient method for
protecting the integrity of data.  You have to have SOPs in place to
ensure document security even with binary files.  The agency has
accepted the argument that the degree of difficulty in recreating a
valid binary file set for a data system lowers the probability for an
undetected modification, but SOPs have always been required on top of
this.

I think we have a great opportunity here.  I presented a way of using
XML for data submission for the FDA to Janet Woodcock who is their Chief
Medical Officer and is now head of the drug approving CDER group and she
was very supportive.  It fits very nicely with their Critical Path
Initiative and also helps the Quality By Design Initiatives, where
analytical instruments are used in-line during manufacturing to
continuously monitor processes.

Does anyone have experience with the XML Digital Signature standard?

Randy





-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Pierre-Alain Binz
Sent: Wednesday, June 11, 2008 3:56 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes

Inbetween, I have also contacted a world-wide QA in Pharma and asked 
what they are doing to comply with text documents, across regulation 
bodies (FDA, ISO, etc). Let's see
Pierre-Alain

Mike Coleman wrote:
> I agree with your points.
>
> As far as I can see, the checksum within the mzML file is not good for
> anything other than as an additional check that (say) Windows hasn't
> flipped any bits in the file.  Arguably, this kind of checksumming is
> barely worth doing, unless you're also checksumming the other parts of
> the system regularly.  Who among us periodically checksums our
> instrument software or configuration files, for example?
>
> If you're concerned about instrument operators faking results, it
> seems like the only meaningful bar would be to have the instrument
> software cryptographically sign the result file.  This would entail
> all kinds of key management problems that would rule this out in
> practice (I would think).
>
> If you're concerned about downstream people faking the results, my
> thought would be that you'd checksum (SHA1, etc.) the file at creation
> or "publication" (the point at which others have access to the file),
> and then publish that checksum in a "read only" location.  As you say,
> this is pretty much the method used by thousands currently for file
> verification.  If you already have a decent backup regime, just
> backing up the checksums might qualify.  Or you could publish a
> grand-checksum in the newspaper occasionally, or whatever.
>
> Note, though, that for these latter scenarios you specifically *must
> ignore* the checksum within the file itself, as it is (as you and Jim
> say) not trustworthy.  Rather, the checksum must be recalculated.
>
> I'm not familiar with 21 CFR Part 11, but it would seem that the mzML
> file itself ought to simply include all of the useful details about
> what it contains.  Any further audit trail should happen outside of
> mzML, though--once the file comes off of the instrument, it should
> never change, in my opinion.
>
> Mike
>
>
------------------------------------------------------------------------
-
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

[Pierre-Alain B. <pie...@is...>]

Inbetween, I have also contacted a world-wide QA in Pharma and asked 
what they are doing to comply with text documents, across regulation 
bodies (FDA, ISO, etc). Let's see
Pierre-Alain

Mike Coleman wrote:
> I agree with your points.
>
> As far as I can see, the checksum within the mzML file is not good for
> anything other than as an additional check that (say) Windows hasn't
> flipped any bits in the file.  Arguably, this kind of checksumming is
> barely worth doing, unless you're also checksumming the other parts of
> the system regularly.  Who among us periodically checksums our
> instrument software or configuration files, for example?
>
> If you're concerned about instrument operators faking results, it
> seems like the only meaningful bar would be to have the instrument
> software cryptographically sign the result file.  This would entail
> all kinds of key management problems that would rule this out in
> practice (I would think).
>
> If you're concerned about downstream people faking the results, my
> thought would be that you'd checksum (SHA1, etc.) the file at creation
> or "publication" (the point at which others have access to the file),
> and then publish that checksum in a "read only" location.  As you say,
> this is pretty much the method used by thousands currently for file
> verification.  If you already have a decent backup regime, just
> backing up the checksums might qualify.  Or you could publish a
> grand-checksum in the newspaper occasionally, or whatever.
>
> Note, though, that for these latter scenarios you specifically *must
> ignore* the checksum within the file itself, as it is (as you and Jim
> say) not trustworthy.  Rather, the checksum must be recalculated.
>
> I'm not familiar with 21 CFR Part 11, but it would seem that the mzML
> file itself ought to simply include all of the useful details about
> what it contains.  Any further audit trail should happen outside of
> mzML, though--once the file comes off of the instrument, it should
> never change, in my opinion.
>
> Mike
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

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

I agree with your points.

As far as I can see, the checksum within the mzML file is not good for
anything other than as an additional check that (say) Windows hasn't
flipped any bits in the file.  Arguably, this kind of checksumming is
barely worth doing, unless you're also checksumming the other parts of
the system regularly.  Who among us periodically checksums our
instrument software or configuration files, for example?

If you're concerned about instrument operators faking results, it
seems like the only meaningful bar would be to have the instrument
software cryptographically sign the result file.  This would entail
all kinds of key management problems that would rule this out in
practice (I would think).

If you're concerned about downstream people faking the results, my
thought would be that you'd checksum (SHA1, etc.) the file at creation
or "publication" (the point at which others have access to the file),
and then publish that checksum in a "read only" location.  As you say,
this is pretty much the method used by thousands currently for file
verification.  If you already have a decent backup regime, just
backing up the checksums might qualify.  Or you could publish a
grand-checksum in the newspaper occasionally, or whatever.

Note, though, that for these latter scenarios you specifically *must
ignore* the checksum within the file itself, as it is (as you and Jim
say) not trustworthy.  Rather, the checksum must be recalculated.

I'm not familiar with 21 CFR Part 11, but it would seem that the mzML
file itself ought to simply include all of the useful details about
what it contains.  Any further audit trail should happen outside of
mzML, though--once the file comes off of the instrument, it should
never change, in my opinion.

Mike

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

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

Hi Mike,

I took some issue with the "non-text" audit trail because it is merely 
security through obscurity, which seems out of place in an open 
standard. Jim made the valid point that the checksum IN the file could 
be modified at the same time the file itself is modified to make it look 
like the file is still original. That kind of potential attack is why 
download sites provide the MD5/SHA1 checksum of a download file 
separately from the file itself. An attacker could mess with the file 
and try to pass it off as real, but if you go back to an original source 
you can confirm that the external checksum doesn't match anymore. I 
suggest this approach as the robust way to protect against tampering 
with audit trails, no matter how they are encoded (for a determined 
attacker, it is a very simple matter to decode a base64 audit trail, 
tamper with it, and re-encode it).

As for the contents of the audit trail itself I hope it will basically 
be a series of dataProcessing elements describing the acquisition 
parameters and any processing that the data has undergone. If there is 
more information needed, I'm eager to hear what it is. For those of you 
just joining us, the "audit trail" is intended to meet the criteria of 
21 CFR Part 11 (http://www.fda.gov/ora/compliance_ref/part11/). I expect 
a proper conformance to the MIAPE-MS guidelines will necessitate 
conformance to the FDA guidelines though. I'm interested to hear if any 
other jurisdictions, e.g. EU countries, have similar compliance concerns 
that we should account for?

-Matt


Mike Coleman wrote:
> On Tue, Jun 10, 2008 at 12:25 PM, Eric Deutsch
> <ede...@sy...> wrote:
>   
>> + Jim talked to Steve Musser at FDA. They are considering accepting mzML as
>> a format to avoid cherry-picked spectra, but it would need some kind of
>> non-text audit trail information.
>>     
>
> Does this actually mean that they want "non-text" audit trail
> information as opposed to textual audit trail information?
>
> I wonder what an audit trail would entail here.  The obvious thing to
> do would be to simply cryptographically sign the mzML file using
> something like PGP.
>
>
>   
>> + Should we set up an mzML.org?
>>     
>
> If you're seriously considering this, I suggest that someone grab it
> immediately.  (I've had good luck with gandi.net as a registrar.)
>
> Mike
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] PSI-MSS WG call minutes

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

On Tue, Jun 10, 2008 at 12:25 PM, Eric Deutsch
<ede...@sy...> wrote:
> + Jim talked to Steve Musser at FDA. They are considering accepting mzML as
> a format to avoid cherry-picked spectra, but it would need some kind of
> non-text audit trail information.

Does this actually mean that they want "non-text" audit trail
information as opposed to textual audit trail information?

I wonder what an audit trail would entail here.  The obvious thing to
do would be to simply cryptographically sign the mzML file using
something like PGP.


> + Should we set up an mzML.org?

If you're seriously considering this, I suggest that someone grab it
immediately.  (I've had good luck with gandi.net as a registrar.)

Mike

[Psidev-ms-dev] PSI-MSS WG call minutes

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

Hi everyone, here are the minutes for the PSI-MSS WG telecon of
2008-06-10.

 

Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim

 

- ASMS

+ Douglas Slotta has implemented mzML in their C++ toolkit

+ Jim talked to Steve Musser at FDA. They are considering accepting mzML
as a format to avoid cherry-picked spectra, but it would need some kind
of non-text audit trail information. Randy will talk with Vish about
this talk. Follow up.

+ There was a suggestion at ASMS that we move toward ISO certification
for the standard to promote adoption

+ Users are very positive about a single format

 

- schema

+ No major schema changes planned

+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change

+ One desirable addition is retention time in the index

 

- MIAPE example document?

+ Done and posted except for switching criteria and parameters for
creating peaklists

+ Pierre-Alain and Jim will get together and finish this

 

- CV status

+ Darren has sent a proposal for of datatype and relationship
"has_units". It's good. Proceed with all terms.

+ "scan time" is one example

+ OBO-Edit will write out all terms including imported terms unless told
not to. That can be done with filters.

+ Darren will post a recipe on how to filter out non-MS terms

+ Darren is still figuring out how to get OBO-Edit to write out "import"
statements

+ Darren will email John Richter-Day about that

+ Current CV version is 1.0.0

+ As Darren or anyone makes changes, increment the version number.

+ Darren will try to import the unit ontology from its source

+ Would a side effect of this prevent OBO-Edit from opening a file w/o
Internet? Darren will check

+ Normally all terms going forward now should be deprecated (deleted in
OBO-Edit terms)

+ However, the unit terms could be destroyed. Eric will destroy them.

                               

- CV template updates to vendors

+ Start another round of vendor updates

+ Some software organized by vendor

 

- documentation

+ Documentation is up to date

+ Images in documentation still mention 0.99.12. Should update to 1.0.0

+ Lennart will regenerate embedded figures and send to Eric who will
update

 

- website

+ Post the mapping file directly

+ Should we set up an mzML.org?

+ Instead of maintaining a separate page, set up a redirect?

 

- mzML support information table

+ Definitely post it on the web site

+ Bruker will likely support mzML. Find out their plans

 

- validator

+ Validator will be a little delayed. There are many back-end changes
due to the MI group

+ Does the validator check that if there is an acquisition list, then
there would be a combination type (like sum of spectra) provided?

+ We will allow spectrum representation (like centroid/profile) in the
fileContent section

+ Need to incorporate the information in the OBO file (datatypes and
units)

+ Need to fix up the mapping file rules

+ Lennart hopes to have coding update done at the end of this week and
then we need help from everyone to update the mapping file

+ Maybe need a rule that if a spectrum and if a mass spectrum, the need
mz array and similar

+ Need some sort of unit for intensity arrays

+ At the moment, we do not require any units for the array type. We
should add that.

+ Darren will explore that while adding has_units to CV

 

- example files

+ Matt will take a stab at MALDI example and post it

+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage

+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML.
Eric will post.

+ Matt will generate an example MGF -> mzML using pwiz and post

+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)

 

- Amsterdam

+ Pierre-Alain will do the presentation of the mzML talk during main
conference

+ PSI session during the congress at Sunday 17th 9:30a-12

+ Tentative presenter at PSI session is Jim Shofstahl with backups of
Randy and Pierre-Alain

 

- Next call

+ Switch call time to *Monday* morning 9am PDT due to conflicts

+ Same time in two weeks on June 23rd

 

 

 

[Psidev-ms-dev] PSI-MSS WG call Tuesday

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

Hi everyone, the PSI Mass Spectrometry Standards Working Group call is
Tuesday May 27 at 9am PDT:

 

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

 

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to review and discuss thoughts from the ASMS
conference and keep the momentum going to try to start pushing
implementation of mzML.

 

Topics:

 

- ASMS wrapup

- schema

- MIAPE example document

- Other example documents

- CV

- CV template updates to vendors

- Documentation

- Web site

- mzML support information table

- Validator

- Amsterdam

- Next call

 

 

Thanks,

Eric

 

Re: [Psidev-ms-dev] mzML 1.0.0 released

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

Hi Eric,


> Hi everyone, I am pleased to report that mzML 1.0.0 has completed the 
> PSI document process and has been released. 

GREAT! That was a fast turn-around this time!

And on this momentous occassion, I'd like to take a moment (and I think 
I speak for all the people involved in the PSI-MS group) to explicitly 
thank Eric for his leadership by example and his efforts in driving mzML 
development.

The whole group has done amazing work, and it has been a privilege to 
work with all of you. Fortunately, since there's still lots to do in 
promoting and supporting mzML, we'll all be working together in the 
future as well :).


Once more, a very big thanks and congratulations to all of us - job very 
well done! I feel really fortunate to have a been a small part of this 
great undertaking.


Cheers,

lnnrt.

[Psidev-ms-dev] mzML 1.0.0 released

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

Hi everyone, I am pleased to report that mzML 1.0.0 has completed the
PSI document process and has been released. We encourage everyone to
implement the final 1.0.0 version. The information about this release is
still at the same address:

 

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

 

Although the schema is finalized, work will continue to expand the
controlled vocabulary, provide additional example files, and clarify the
documentation as ambiguities are noticed. And, of course, we will work
with those trying to implement the format in their software. There
already exist quite a number of software programs that read or write
mzML, so be sure to contact us before starting your own parser/writer;
you may be able to complete your work faster by using existing code.

 

Additional activities going forward will include contacting all vendors
so that they are aware of the format and trying to get a committed plan
for supporting mzML. We will soon provide an expanded listing at the web
site of implementation plans.

 

I would like to extend many thanks to all of you who participated in the
development of mzML. It has truly been an international group effort.

 

Regards,

Eric

 

 

----------------------------------
Eric Deutsch, Ph.D.
Institute for Systems Biology
1441 North 34th Street
Seattle WA 98103
Tel: 206-732-1397
Fax: 206-732-1260
Email: ede...@sy...
WWW:
http://www.systemsbiology.org/Senior_Research_Scientists/Eric_Deutsch

 

Re: [Psidev-ms-dev] Unit terms in binaryDataArrays

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

When you say state a fixed unit, do you mean in the binaryDataArray 
(i.e. always require a MS_second term) or just implicit? I don't like 
the implicit idea. And I think the vendors should store whatever comes 
off the instrument. Thermo's control software talks in minutes as far as 
I can tell, I don't see a reason to force it to seconds for mzML. It 
might be possible to force the time array to seconds, but it isn't 
possible to force the intensity array to be ion current because some 
instruments measure counts. So intensity arrays should also have units 
specified. The rule mapping should have logic like:
binaryDataArray:
    // m/z array has no unit
    if type is intensity array: MAY have intensity unit type
    else if type is time array: MAY have time unit type
    else if type is wavelength array: MAY have wavelength unit type // 
UV spectra?

These units can't be required, but MIAPE should probably have them.

-Matt


Rune Schjellerup Philosof wrote:
> I think the easiest solution for chromatograms is to state a fixed unit, 
> seconds for instance, and I can not see any drawbacks to this (at least 
> when it comes to chromatograms).
>
> --
> Rune
>
> Matt Chambers wrote:
>   
>> The semantic mapping should allow for a unit term to be specified that 
>> indicates the unit for a given binaryDataArray. This is particularly 
>> important for chromatograms, as it's totally arbitrary which time unit 
>> is chosen for the primary time axis!
>>
>> -Matt
>>     

Re: [Psidev-ms-dev] Unit terms in binaryDataArrays

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

I think the easiest solution for chromatograms is to state a fixed unit, 
seconds for instance, and I can not see any drawbacks to this (at least 
when it comes to chromatograms).

--
Rune

Matt Chambers wrote:
> The semantic mapping should allow for a unit term to be specified that 
> indicates the unit for a given binaryDataArray. This is particularly 
> important for chromatograms, as it's totally arbitrary which time unit 
> is chosen for the primary time axis!
>
> -Matt
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>