psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] Handling variations in generation of m/z vs. intensity data arrays

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

For a given mass spectrum, there are a large number of possible ways to 
generate m/z vs. intensity data arrays, depending on the answer to 
questions such as:
 - Entire m/z vs. intensity profile or peaks only?
 - All peaks or monoisotopic peaks only?
 - All peaks or "prominent" peaks only (must be above some signal-to-noise 
threshold, for example)?
 - "De-charge" peaks or not?
 - And so on...

I can think of 2 main ways to handle these variations (as well as options 
in-between that are a hybrid of these 2 extremes):
(1) The software that generates mzML asks the user in detail what his or 
her preferences are, and then the software generates the appropriate m/z 
vs. intensity data arrays.
(2) The software that generates mzML doesn't ask the user anything. Rather 
the software writes out all the data with bit masks and other auxiliary 
data. That is, rather than having just m/z vs. intensity data arrays, 
there are extra data arrays carrying more info. Example:
        m/z     Intensity       Monoisotopic?   S/N     Charge ...
        501.00  1000            Yes             50      3
        501.33  500             No              20      3
        501.66  100             No              10      3
        751.00  5000            Yes             150     2
        751.50  2000            No              70      2

Option (1) has the advantage of being very simple for any software 
consuming mzML to interpret the data arrays without any ambiguity. The 
disadvantage of option (1) is that any change in data requirements 
requires that one go back to the original raw data and re-generate a 
completely new mzML file. By contrast, option (2) has a lot more data 
embedded in the file and is much less likely to require re-generation of 
mzML, but requires more intelligence from the software consuming the mzML 
- for example, if only the monoisotopic peaks are desirable, the consuming 
software must nevertheless understand that it can't just read the m/z and 
intensity data arrays but it MUST ALSO read the monoisotopic data array 
and throw out some data values based on the contents of the monoisotopic 
bitmask array; otherwise the results can be bad.

Is there any guidance for how these things should be handled in mzML? What 
are the assumptions made by existing mzML consumers?

Thanks,
Wilfred

Re: [Psidev-ms-dev] Phone conference meeting minutes

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

SeeMS is a free, open source GUI-based tool to visualize spectra and 
chromatograms. It uses ProteoWizard for reading from spectral files. It 
supports formats that ProteoWizard supports, which are currently mzML, 
mzXML, MGF, Thermo RAW (w/ Xcalibur), Waters RAW (w/ MassLynx), and the 
Bruker BioTools DataExchange (BTDX.xml) format. So far, the tool is a 
sort of test-bed so it's rather unpolished, but it's very usable for 
basic visualization. SeeMS will also let you explore some of the more 
flexible metadata in mzML, like multiple precursors with multiple 
selected ions, instrument configurations, etc.

An alternative would be Insilicos's spectrum viewer, which has been 
updated with the most recent RAMP (which in turn uses ProteoWizard for 
reading mzML). It might also inherit some other formats, but Brian Pratt 
could answer that better than me.

-Matt


Wilfred H Tang wrote:
>
> > PSI-MS Phone Conference Minutes, dd. 4 August 2008
> > -------------------------------
> > Attendance:
> >   - Matt Chambers
> >   - Eric Deutsch
> >   - Jim Schofstahl
> >   - Lennart Martens
> >
> >
> > Minutes:
> >   - MS Validator
> > Lennart has submitted a revised codebase of the validator to the SVN
> > repository. Apart from some cosmetic changes to the GUI, the thing is
> > operational. There are still some CV issues however -- see below -- 
> that
> > need to be resolved prior to announcing the official release.
> >
>
> That sounds great. Also, what software currently exists that can read 
> in mzML and do something interesting with the data? For example, 
> displaying the data visually as mass spectra? Something like that 
> could be quite useful for sanity-checking if mzML files appear to be 
> correctly-formatted.
>
> Thanks,
> Wilfred
>

Re: [Psidev-ms-dev] mzML comments

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

Does the lack of dissent mean that the proposal is accepted? :)

What is the process for incorporating this into the psi-ms.obo file?

Thanks,
Wilfred




Wilfred H Tang/FOS/PEC
06/17/2008 05:36 PM

To
psi...@li...
cc

Subject
Re: mzML comments





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

Re: [Psidev-ms-dev] Phone conference meeting minutes

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

> PSI-MS Phone Conference Minutes, dd. 4 August 2008
> -------------------------------
> Attendance:
>   - Matt Chambers
>   - Eric Deutsch
>   - Jim Schofstahl
>   - Lennart Martens
> 
> 
> Minutes:
>   - MS Validator
> Lennart has submitted a revised codebase of the validator to the SVN 
> repository. Apart from some cosmetic changes to the GUI, the thing is 
> operational. There are still some CV issues however -- see below -- that 

> need to be resolved prior to announcing the official release.
> 

That sounds great. Also, what software currently exists that can read in 
mzML and do something interesting with the data? For example, displaying 
the data visually as mass spectra? Something like that could be quite 
useful for sanity-checking if mzML files appear to be correctly-formatted.

Thanks,
Wilfred

[Psidev-ms-dev] Phone conference meeting minutes

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

Dear PSI-MS Enthousiasts,


Please find below my terse meeting minutes for the PSI-MS phone 
conference dd. 4 August 2008.


Cheers,

lnnrt.


PSI-MS Phone Conference Minutes, dd. 4 August 2008
-------------------------------
Attendance:
  - Matt Chambers
  - Eric Deutsch
  - Jim Schofstahl
  - Lennart Martens


Minutes:
  - MS Validator
Lennart has submitted a revised codebase of the validator to the SVN 
repository. Apart from some cosmetic changes to the GUI, the thing is 
operational. There are still some CV issues however -- see below -- that 
need to be resolved prior to announcing the official release.

  - CV
Lennart: Why do we have the Unit ontology imported as a local copy 
again? This is essentially bad practice, and intereferes the validator. 
Eric, Matt: (i) because we couldn't save changes; (ii) some strange 
ASCII characters in unit.obo. Lennart will try to fix these outstanding 
issues. See TODO below.
Lennart: a second issue is that OLS doesn't support import statements in 
OBO files yet. We're working very hard on an OLS update, but we'll need 
to wait until that update is completely before we can upload the new CV.

  - Mapping Rules
Matt has made a stab at extending this file, but then noticed that the 
CV is difficult to map to the schema right now. Matt also suggests that 
we have a minimal set of rules for now, and expand on it later.

  - Object Rules
Matt highlights the fact that the object rules are not well-defined 
apart from the code that will enforce them. Eric suggests that they 
should be described in a ('the') specification document. Eric could 
potentially auto-include such a description of the object rules in the 
specification document.

Todo:
  - Lennart: get update of validator to Fredrik Levander for online 
validator.
  - Lennart: Resolve two points on unit.obo by contacting maintainer NOW
  - Lennart: Suggested update to the CV where schema-like placeholders 
are put in.
  - Eric: will try to find the 'rules to add' todo item we had in Toledo.

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

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

Dear PSI-MS Enthousiasts,


Yes, we'll have our regular call today (Monday August 4).


Details:

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

http://www.timeanddate.com/worldclock/fixedtime.html?day=4&month=8&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


Agenda points:

  - MS Validator
  - Mapping rules file
  - CV
  - Everything else I missed :)


Cheers,

lnnrt.

Matthew Chambers wrote:
> Presumably Eric is tied up with paternal duties, but we are still having 
> a call?
> 
> -Matt
> 
> 
> Eric Deutsch wrote:
>> - Next call
>>
>> + Next call same time in two weeks on August 4
>>
>>  
>>
>>
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

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

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

Presumably Eric is tied up with paternal duties, but we are still having 
a call?

-Matt


Eric Deutsch wrote:
>
> - Next call
>
> + Next call same time in two weeks on August 4
>
>  
>
>

Re: [Psidev-ms-dev] CV mapping rules XSL

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

Lennart Martens wrote:
>> Curiously, when I click on the xml file with Firefox (under Windows), I
>> just get the XML displayed. When I bring it up in IE (same machine), the
>> style sheet is properly applied (looks nice!). Any guesses why that is?
>> Do I have a funny Firefox setting that prevents style sheets from being
>> applied?
> 
> I get the same behaviour when I click the link in the email and it opens 
> in Firefox (3 in my case). Firefox seems to treat the XML as a file 
> download, and then shows you the file contents as if it were a text 
> file. If you save the XML file locally however, and then open it in 
> Firefox, it will apply the XSL and will provide the expected result. Go 
> figure...

Looks like Firefox is simply obeying the (incorrect) MIME type returned 
by the Sourceforge server...

   HTTP/1.1 200 OK
   Date: Thu, 24 Jul 2008 09:43:41 GMT
   Server: Apache/2.2.3 (CentOS)
   Last-Modified: Wed, 23 Jul 2008 14:23:33 GMT
   ETag: "210//psi/mzml/validator/ms-mapping.xml"
   Accept-Ranges: bytes
   Content-Length: 21302
   Connection: close
   Content-Type: text/plain; charset=UTF-8
                      ^^^^^

Regards,
Chris

--
http://www.matrixscience.com

Re: [Psidev-ms-dev] CV mapping rules XSL

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

Hi Eric,


> Curiously, when I click on the xml file with Firefox (under Windows), I
> just get the XML displayed. When I bring it up in IE (same machine), the
> style sheet is properly applied (looks nice!). Any guesses why that is?
> Do I have a funny Firefox setting that prevents style sheets from being
> applied?

I get the same behaviour when I click the link in the email and it opens 
in Firefox (3 in my case). Firefox seems to treat the XML as a file 
download, and then shows you the file contents as if it were a text 
file. If you save the XML file locally however, and then open it in 
Firefox, it will apply the XSL and will provide the expected result. Go 
figure...


Cheers,

lnnrt.

> 
> Thanks,
> Eric
> 
> 
>> -----Original Message-----
>> From: psi...@li...
> [mailto:psidev-ms-dev-
>> bo...@li...] On Behalf Of Lennart Martens
>> Sent: Wednesday, July 23, 2008 7:33 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] CV mapping rules XSL
>>
>> Dear PSI-MS Enthousiasts,
>>
>>
>> Thanks to the pioneering effort by Marc Sturm, we now have an XSL
>> stylesheet that transforms a mapping file in a relatively nicely
>> readable web page.
>>
>> The original XSL made by Marc can be found at the URL included in his
>> original message below, whereas my revised one is now committed to the
>> PSI validator framework SVN repository. You can access this file here:
>>
> https://psidev.svn.sourceforge.net/svnroot/psidev/psi/tools/current/xsl/
> cv
>> -mapping/CvMappingRules.xsl
>>
>> I have now added a reference to this stylesheet in the ms-mapping.xml
>> file (which is also in the PSI SVN repository, in our mzML validator
>> project), so this file is now automatically rendered into something
> nice
>> (provided you're online) when opened in a browser.
>>
>> If you want to give it a shot, you can access the file here:
>>
> https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-
>> mapping.xml
>>
>>
>> Enjoy,
>>
>> lnnrt.
>>
>>
>> Marc Sturm wrote:
>>> Hi Lennart,
>>>
>>> Let's try it like this:
>>> http://www-bs2.informatik.uni-tuebingen.de/services/sturm/public/ms-
>> mapping.xsl
>>>
>>> -Marc
>>>
>>> Lennart Martens wrote:
>>>> Hmmm, I just get a text file entitled 'CT_CF_Drop_3.txt' containing
> a
>>>> single '0' character.
>>>> Maybe zip the XSLT and send it again? It could be that one of the
> amil
>>>> clients or servers is trying to be clever by processing it somehow?
>>
> ------------------------------------------------------------------------
> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

Re: [Psidev-ms-dev] CV mapping rules XSL

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

Thanks guys, this is great.

Curiously, when I click on the xml file with Firefox (under Windows), I
just get the XML displayed. When I bring it up in IE (same machine), the
style sheet is properly applied (looks nice!). Any guesses why that is?
Do I have a funny Firefox setting that prevents style sheets from being
applied?

Thanks,
Eric


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Lennart Martens
> Sent: Wednesday, July 23, 2008 7:33 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] CV mapping rules XSL
> 
> Dear PSI-MS Enthousiasts,
> 
> 
> Thanks to the pioneering effort by Marc Sturm, we now have an XSL
> stylesheet that transforms a mapping file in a relatively nicely
> readable web page.
> 
> The original XSL made by Marc can be found at the URL included in his
> original message below, whereas my revised one is now committed to the
> PSI validator framework SVN repository. You can access this file here:
>
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/tools/current/xsl/
cv
> -mapping/CvMappingRules.xsl
> 
> I have now added a reference to this stylesheet in the ms-mapping.xml
> file (which is also in the PSI SVN repository, in our mzML validator
> project), so this file is now automatically rendered into something
nice
> (provided you're online) when opened in a browser.
> 
> If you want to give it a shot, you can access the file here:
>
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-
> mapping.xml
> 
> 
> Enjoy,
> 
> lnnrt.
> 
> 
> Marc Sturm wrote:
> > Hi Lennart,
> >
> > Let's try it like this:
> > http://www-bs2.informatik.uni-tuebingen.de/services/sturm/public/ms-
> mapping.xsl
> >
> >
> > -Marc
> >
> > Lennart Martens wrote:
> >> Hmmm, I just get a text file entitled 'CT_CF_Drop_3.txt' containing
a
> >> single '0' character.
> >> Maybe zip the XSLT and send it again? It could be that one of the
amil
> >> clients or servers is trying to be clever by processing it somehow?
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] CV mapping rules XSL

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

Dear PSI-MS Enthousiasts,


Thanks to the pioneering effort by Marc Sturm, we now have an XSL 
stylesheet that transforms a mapping file in a relatively nicely 
readable web page.

The original XSL made by Marc can be found at the URL included in his 
original message below, whereas my revised one is now committed to the 
PSI validator framework SVN repository. You can access this file here: 
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/tools/current/xsl/cv-mapping/CvMappingRules.xsl

I have now added a reference to this stylesheet in the ms-mapping.xml 
file (which is also in the PSI SVN repository, in our mzML validator 
project), so this file is now automatically rendered into something nice 
(provided you're online) when opened in a browser.

If you want to give it a shot, you can access the file here:
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml


Enjoy,

lnnrt.


Marc Sturm wrote:
> Hi Lennart,
> 
> Let's try it like this: 
> http://www-bs2.informatik.uni-tuebingen.de/services/sturm/public/ms-mapping.xsl 
> 
> 
> -Marc
> 
> Lennart Martens wrote:
>> Hmmm, I just get a text file entitled 'CT_CF_Drop_3.txt' containing a 
>> single '0' character.
>> Maybe zip the XSLT and send it again? It could be that one of the amil 
>> clients or servers is trying to be clever by processing it somehow?

Re: [Psidev-ms-dev] Current mapping file

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

Hi Lennart,

i'll inform you if i find other dangling ends in the mapping file.
i'm only 70% through with out mzML implementation.

Best,
  Marc

Lennart Martens wrote:
> Hi Marc,
>
>
>   
>> thanks for the up-to-date link.
>> The other version I found is at: 
>> http://psidev.cvs.sourceforge.net/psidev/psi/psi-ms/mzML/schema/ms-mapping.xml?view=log 
>>     
>
> Well spotted. I have now deleted this from CVS, and remarked in the log 
> comment of the commit that the files should be obtained from the psidev 
> SVN instead, along with the path to the validator configuration files.
>
>
>   
>> I have several questions/comments regarding the mapping file.
>>
>> Comment 1:
>> There is no mapping for the "/mzML/run" tag
>>     
>
> Correct, I couldn't easily find anything that we require or expect 
> there, so I let the rule out. Maybe there should be one or more rules 
> added for this location, but fleshing out the mapping file is still a 
> work in progress. You're very welcome to make suggestions, actually.
>
>
>   
>> Comment 2:
>> There is no mapping for the 
>> "/mzML/run/spectrumList/spectrum/spectrumDescription/precursorList/precursor/isolationWindow" 
>> tag
>>     
>
> Correct, we should add a meaningful rule here.
>
>
>   
>> Comment 3:
>> There is no mapping for the "data processing parameter" terms (MS:1000630)
>>     
>
> Correct again; needs to be added.
>
>
>   
>> Question 1:
>> According to the mapping file the "ms level" term (MS:1000511) should be 
>> under "spectrumDescription", but is under "spectrum" in the tiny1 example.
>> Which one is right?
>>     
>
> Good question. Can't remember off the top of my head what this should 
> be. So you can see: there's work yet to be done on the mapping file!
>
>
> Essentially, my main effort in these matters right now is spent on 
> getting our reference validator up and running. Once that is achieved, 
> the mapping file can be refined as we go along (the whole thing is 
> descriptively configured from the XML file, so no code needs changing).
>
> I think we should probably have a conference call dedicated to the 
> mapping file at a point in the near future, but that is open to discussion.
>
> Regardless, it would be good to have the reference validator out there 
> first, so people are free to play with the mapping rules and instance 
> documents. At the EBI, we're ironing out the last bugs in the validator 
> now (while the mzML validator itself is simple and consists of nearly 
> trivial code, this is only because (i) we have this rather complex but 
> minimal memory footprint jmzML component that effectively uses an mzML 
> file as a cache file, and (ii) we build the entire back-end on the 
> generic PSI validator framework, which is a very complicated suite of 
> modules that are high-tech codepieces in their own right -- this 
> framework is also used by the PSI-MI people, for instance).
>
>
> Cheers,
>
> lnnrt.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] dataProcessing

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

Hi Eric,

thanks for your reply.
When you want to allow both ordered and unordered processing steps, it 
all makes sense.
I thought everything should be ordered.

Regards,
  Marc

Eric Deutsch wrote:
> Hi Marc, below:
>
>   
>> From: psi...@li...
>>     
> [mailto:psidev-ms-dev-
>   
>> Hi all,
>>
>> i have problems understanding how the data processing part of the
>>     
> schema
>   
>> is intended.
>> The main question I have is: what does the "order" attribute define?
>> Is it the order of different tools that were applied or the order of
>> several processing steps done by the same software?
>>     
>
> It is the order of processing steps applied to the dataset over its
> journey from mass spec to current form.
>
>   
>> As it is under "processingMethod", I thought it defines the order of
>> several processing steps done by the same software.
>> However the terms "data processing action" and "file format
>>     
> conversion"
>   
>> should not be repeatable in this case.
>> Otherwise the order is undefined again.
>>     
>
> I don't understand what you mean by this. It would seem entirely
> possible for vendor software A to perform some thresholding first and
> write out data in thresholded profile mode. Then perhaps FOSS software B
> might be used to convert to mzML. Then some other program might be used
> to centroid the data and write out another mzML file. These might be 3
> softwares used in the history of the data with order 1, 2, 3,
> respectively.
>
>   
>> When i looked into the tiny1 example, it confused me even more.
>>     
>
> In this case there are several algorithms applied in the same step since
> it is not known precisely in what order they were performed. So in the
> example, first Xcalibur was used to perform deisotoping, charge
> deconvolution, and peak picking. These are all lumped together as step
> 1. Perhaps they are result of a single algorithm or action and not
> separatable. Or perhaps there should be some inherent order, but it is
> not know to the writer. Then step 2 is the conversion to mzML. If the
> order of deisotoping, charge deconvolution, and peak picking is
> specifically known and relevant, it would be permissible to write this
> is a 4-step process, with order 1, 2, 3, and 4.
>
> Has this answered your question? Or perhaps I have misunderstood your
> confusion? If this clears it up, I will update the documentation to
> reflect this description.
>
> Also, if any of the other designers feel I have not described the intent
> correctly, please speak up!
>
> Regards,
> Eric
>
>
>
>   
>> I attached an image that shows parts of the corresponding parts of the
>> example file, the CV file, the schema file and the mapping file.
>>
>> Best,
>>   Marc
>>     
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Nailing down NativeID

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

Hi Eric,

Of course, sorry I should have realized that the axis name concept would 
confuse matters. The axis names are just there so that a machine reading 
the format specification can associate each comma delimited section 
(what I'm calling an "axis") with a logical name.

Thermo:
0,1 (controller 0, scan 1)
0,2
0,3
1,1 (controller 1, scan 1)

Waters:
1,0,1 (function 1, process 0, scan 1)
1,0,2
1,0,3
2,0,1 (function 2, process 0, scan 1)
2,0,2
2,0,3

WIFF:
0,1,1,2 (sample 0, period 1, cycle 1, experiment 2)
0,1,1,3
0,1,2,2
0,1,2,3
0,1,2,4
0,1,3,2
0,1,3,3
0,1,3,2
0,1,4,2
1,1,1,2
1,1,1,3

When a machine reads the WIFF definition, it will know that the fields 
mean (in order) "sample #", "period #", "cycle #", "experiment #". The 
detailed meaning of those names won't be covered by the format 
definition, but it's conceivable that we define those names in detail as 
separate CV terms. Remember the main idea for nativeID is to map a 
spectrum back to a source file in a way that is more intuitive than a 
simple index, so being able to use them to look up the spectrum via a 
native interface is important.

I think we can safely require that the nativeIDs always use all the 
fields even if for an entire run all of a particular axis has the same 
value. For example, in Thermo data the controller number is almost 
always going to be the number corresponding with the MS controller 
(although the actual number is not guaranteed to be 0). For backwards 
compatibility with tools which expect Thermo ids to be scan numbers with 
an implicit assumption about the controller, it is very reasonable to 
require those tools to simply parse the id. Parsing a comma-delimited 
pair is far easier than all the other crap one must do to get proper 
mzML support. ;) In particular for you Eric and other TPP users, the 
RAMP adapter that pwiz uses will pass only the scan number (and make 
sure the spectrum is a mass spectrum).

-Matt


Eric Deutsch wrote:
> Hi Matt, thanks, this looks well thought out, although I'm not sure I
> fully understand the syntax you're proposing. Can you provide one or two
> examples of each type?
>
> Thanks!
> Eric
>
>
>   
>> -----Original Message-----
>> From: psi...@li...
>>     
> [mailto:psidev-ms-dev-
>   
>> bo...@li...] On Behalf Of Matthew Chambers
>> Sent: Tuesday, July 22, 2008 3:15 PM
>> To: Mass spectrometry standard development
>> Subject: [Psidev-ms-dev] Nailing down NativeID
>>
>> Hi all,
>>
>> I think it's overdue that we get this part of mzML formally specified
>>     
> -
>   
>> at least for the vendors and generic formats. I am proposing a draft
>>     
> of
>   
>> nativeID formats, the place to put the formats in the specification
>> documents, and to have mzML instance documents explicitly reference
>>     
> the
>   
>> format they are using. This explicit reference should be required for
>> semantic validation, but I'd also recommend that mzML readers that
>>     
> don't
>   
>> find or ignore the nativeID format term specified simply treat the
>> nativeID as a free string (rendering it pretty useless, but at least
>> there would be a defined way to handle it). The terms would be placed
>>     
> in
>   
>> the fileContent element to define the format for all nativeIDs in the
>> file.
>>
>> I propose that the nativeID formats become CV terms, and that the term
>> definitions define the formats unambiguously in a machine-readable way
>> that a semantic validator can use to validate the nativeIDs.  I will
>> list my format drafts in OBO format. Each specific native format
>> definition is a comma-delimited list of key-value pairs, where the key
>> is the axis name (e.g. "scan number") and the value specifies the
>>     
> format
>   
>> of the axis in one of two ways:
>> 1) a Perl-style regular expression that can provide semantic/logical
>> choices for strings (e.g. "controller type" can be either "MS" or
>>     
> "PDA"
>   
>> or "UV" etc.)
>> 2) an XSD type that can specify unrestricted strings or a numeric type
>> (possibly with semantic restrictions)
>>
>> I didn't actually need to use a regex for any of the formats below,
>>     
> but
>   
>> I can see their usefulness. For example, they would be needed if I'm
>> wrong about Xcalibur and it makes more sense for Thermo spectra to use
>> controller names instead of controller numbers.
>>
>> Obviously the syntax of the format definitions is flexible if people
>> have better ideas (ideally one that could combine the power of regex
>>     
> and
>   
>> XSD; "infinite cosmic power, itty bitty living space!").
>>
>> [Term]
>> id: MS:x
>> name: native spectrum identifier
>> def: "References a spectrum in a native (non-mzML) spectrum source
>> according to a strict format. The format is dependent on the type of
>>     
> the
>   
>> spectra source." [PSI:MS]
>> is_a: MS:1000524 ! data file content
>>
>> [Term]
>> id: MS:x
>> name: native chromatogram identifier
>> def: "References a chromatogram in a native (non-mzML) chromatogram
>> source according to a strict format. The format is dependent on the
>>     
> type
>   
>> of the chromatogram source." [PSI:MS]
>> is_a: MS:1000524 ! data file content
>> ! note: I don't have any instances of native chromatogram identifiers,
>> but I can conceive of the possibilities!
>>
>> [Term]
>> id: MS:x
>> name: Thermo RAW spectrum identifier
>> def: "controller type=xsd:nonNegativeInteger,scan
>> number=xsd:positiveInteger" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note to Jim: apparently, Xcalibur can handle multiple controllers of
>> the same type, so is a choice between strings still appropriate?
>>
>> [Term]
>> id: MS:x
>> name: Waters RAW spectrum identifier
>> def: "function number=xsd:positiveInteger,process
>> number=xsd:nonNegativeInteger,scan number=xsd:positiveInteger"
>>     
> [PSI:MS]
>   
>> is_a: MS:x ! native spectrum identifier
>> ! note: is process number ever non-zero?
>>
>> [Term]
>> id: MS:x
>> name: WIFF spectrum identifier
>> def: "sample number=xsd:nonNegativeInteger,period
>> number=xsd:positiveInteger,cycle number=xsd:positiveInteger,experiment
>> number=xsd:positiveInteger" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> [Term]
>> id: MS:x
>> name: ABI Oracle database spectrum identifier
>> def: "" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note: need expertise here; alternatively, we could lump these
>>     
> spectra
>   
>> in with DTA/PKL nativeIDs (see below) when they are extracted to T2Ds
>>
>> [Term]
>> id: MS:x
>> name: Bruker spectrum identifier
>> def: "" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note: need expertise here. AFAIK, each Bruker YEP/BAF/FID spectrum
>>     
> is
>   
>> natively a single file, so that seems to make nativeID irrelevant and
>> sourceFile[Ref] critical
>>
>> [Term]
>> id: MS:x
>> name: Shimadzu spectrum identifier
>> def: "" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note: need expertise here
>>
>> [Term]
>> id: MS:x
>> name: MGF spectrum identifier
>> def: "index=xsd:nonNegativeInteger" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note: TITLE attributes are optional, so the index into the file is
>>     
> the
>   
>> only reliable source (TITLE can be used for the string id if present)
>>
>> [Term]
>> id: MS:x
>> name: mzData/mzXML/MS2 spectrum identifier
>> def: "scan number=xsd:positiveInteger" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> [Term]
>> id: MS:x
>> name: PKL/DTA spectrum identifier
>> def: "" [PSI:MS]
>> is_a: MS:x ! native spectrum identifier
>> ! note: like Bruker, a PKL or DTA could be standalone so AFAIK the
>>     
> only
>   
>> way to reliably reference it is via sourceFileRef
>>
>>
>>     
>

Re: [Psidev-ms-dev] Nailing down NativeID

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

Hi Matt, thanks, this looks well thought out, although I'm not sure I
fully understand the syntax you're proposing. Can you provide one or two
examples of each type?

Thanks!
Eric


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Matthew Chambers
> Sent: Tuesday, July 22, 2008 3:15 PM
> To: Mass spectrometry standard development
> Subject: [Psidev-ms-dev] Nailing down NativeID
> 
> Hi all,
> 
> I think it's overdue that we get this part of mzML formally specified
-
> at least for the vendors and generic formats. I am proposing a draft
of
> nativeID formats, the place to put the formats in the specification
> documents, and to have mzML instance documents explicitly reference
the
> format they are using. This explicit reference should be required for
> semantic validation, but I'd also recommend that mzML readers that
don't
> find or ignore the nativeID format term specified simply treat the
> nativeID as a free string (rendering it pretty useless, but at least
> there would be a defined way to handle it). The terms would be placed
in
> the fileContent element to define the format for all nativeIDs in the
> file.
> 
> I propose that the nativeID formats become CV terms, and that the term
> definitions define the formats unambiguously in a machine-readable way
> that a semantic validator can use to validate the nativeIDs.  I will
> list my format drafts in OBO format. Each specific native format
> definition is a comma-delimited list of key-value pairs, where the key
> is the axis name (e.g. "scan number") and the value specifies the
format
> of the axis in one of two ways:
> 1) a Perl-style regular expression that can provide semantic/logical
> choices for strings (e.g. "controller type" can be either "MS" or
"PDA"
> or "UV" etc.)
> 2) an XSD type that can specify unrestricted strings or a numeric type
> (possibly with semantic restrictions)
> 
> I didn't actually need to use a regex for any of the formats below,
but
> I can see their usefulness. For example, they would be needed if I'm
> wrong about Xcalibur and it makes more sense for Thermo spectra to use
> controller names instead of controller numbers.
> 
> Obviously the syntax of the format definitions is flexible if people
> have better ideas (ideally one that could combine the power of regex
and
> XSD; "infinite cosmic power, itty bitty living space!").
> 
> [Term]
> id: MS:x
> name: native spectrum identifier
> def: "References a spectrum in a native (non-mzML) spectrum source
> according to a strict format. The format is dependent on the type of
the
> spectra source." [PSI:MS]
> is_a: MS:1000524 ! data file content
> 
> [Term]
> id: MS:x
> name: native chromatogram identifier
> def: "References a chromatogram in a native (non-mzML) chromatogram
> source according to a strict format. The format is dependent on the
type
> of the chromatogram source." [PSI:MS]
> is_a: MS:1000524 ! data file content
> ! note: I don't have any instances of native chromatogram identifiers,
> but I can conceive of the possibilities!
> 
> [Term]
> id: MS:x
> name: Thermo RAW spectrum identifier
> def: "controller type=xsd:nonNegativeInteger,scan
> number=xsd:positiveInteger" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note to Jim: apparently, Xcalibur can handle multiple controllers of
> the same type, so is a choice between strings still appropriate?
> 
> [Term]
> id: MS:x
> name: Waters RAW spectrum identifier
> def: "function number=xsd:positiveInteger,process
> number=xsd:nonNegativeInteger,scan number=xsd:positiveInteger"
[PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: is process number ever non-zero?
> 
> [Term]
> id: MS:x
> name: WIFF spectrum identifier
> def: "sample number=xsd:nonNegativeInteger,period
> number=xsd:positiveInteger,cycle number=xsd:positiveInteger,experiment
> number=xsd:positiveInteger" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> [Term]
> id: MS:x
> name: ABI Oracle database spectrum identifier
> def: "" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: need expertise here; alternatively, we could lump these
spectra
> in with DTA/PKL nativeIDs (see below) when they are extracted to T2Ds
> 
> [Term]
> id: MS:x
> name: Bruker spectrum identifier
> def: "" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: need expertise here. AFAIK, each Bruker YEP/BAF/FID spectrum
is
> natively a single file, so that seems to make nativeID irrelevant and
> sourceFile[Ref] critical
> 
> [Term]
> id: MS:x
> name: Shimadzu spectrum identifier
> def: "" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: need expertise here
> 
> [Term]
> id: MS:x
> name: MGF spectrum identifier
> def: "index=xsd:nonNegativeInteger" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: TITLE attributes are optional, so the index into the file is
the
> only reliable source (TITLE can be used for the string id if present)
> 
> [Term]
> id: MS:x
> name: mzData/mzXML/MS2 spectrum identifier
> def: "scan number=xsd:positiveInteger" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> [Term]
> id: MS:x
> name: PKL/DTA spectrum identifier
> def: "" [PSI:MS]
> is_a: MS:x ! native spectrum identifier
> ! note: like Bruker, a PKL or DTA could be standalone so AFAIK the
only
> way to reliably reference it is via sourceFileRef
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Nailing down NativeID

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

Hi all,

I think it's overdue that we get this part of mzML formally specified - 
at least for the vendors and generic formats. I am proposing a draft of 
nativeID formats, the place to put the formats in the specification 
documents, and to have mzML instance documents explicitly reference the 
format they are using. This explicit reference should be required for 
semantic validation, but I'd also recommend that mzML readers that don't 
find or ignore the nativeID format term specified simply treat the 
nativeID as a free string (rendering it pretty useless, but at least 
there would be a defined way to handle it). The terms would be placed in 
the fileContent element to define the format for all nativeIDs in the file.

I propose that the nativeID formats become CV terms, and that the term 
definitions define the formats unambiguously in a machine-readable way 
that a semantic validator can use to validate the nativeIDs.  I will 
list my format drafts in OBO format. Each specific native format 
definition is a comma-delimited list of key-value pairs, where the key 
is the axis name (e.g. "scan number") and the value specifies the format 
of the axis in one of two ways:
1) a Perl-style regular expression that can provide semantic/logical 
choices for strings (e.g. "controller type" can be either "MS" or "PDA" 
or "UV" etc.)
2) an XSD type that can specify unrestricted strings or a numeric type 
(possibly with semantic restrictions)

I didn't actually need to use a regex for any of the formats below, but 
I can see their usefulness. For example, they would be needed if I'm 
wrong about Xcalibur and it makes more sense for Thermo spectra to use 
controller names instead of controller numbers.

Obviously the syntax of the format definitions is flexible if people 
have better ideas (ideally one that could combine the power of regex and 
XSD; "infinite cosmic power, itty bitty living space!").

[Term]
id: MS:x
name: native spectrum identifier
def: "References a spectrum in a native (non-mzML) spectrum source 
according to a strict format. The format is dependent on the type of the 
spectra source." [PSI:MS]
is_a: MS:1000524 ! data file content

[Term]
id: MS:x
name: native chromatogram identifier
def: "References a chromatogram in a native (non-mzML) chromatogram 
source according to a strict format. The format is dependent on the type 
of the chromatogram source." [PSI:MS]
is_a: MS:1000524 ! data file content
! note: I don't have any instances of native chromatogram identifiers, 
but I can conceive of the possibilities!

[Term]
id: MS:x
name: Thermo RAW spectrum identifier
def: "controller type=xsd:nonNegativeInteger,scan 
number=xsd:positiveInteger" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note to Jim: apparently, Xcalibur can handle multiple controllers of 
the same type, so is a choice between strings still appropriate?

[Term]
id: MS:x
name: Waters RAW spectrum identifier
def: "function number=xsd:positiveInteger,process 
number=xsd:nonNegativeInteger,scan number=xsd:positiveInteger" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: is process number ever non-zero?

[Term]
id: MS:x
name: WIFF spectrum identifier
def: "sample number=xsd:nonNegativeInteger,period 
number=xsd:positiveInteger,cycle number=xsd:positiveInteger,experiment 
number=xsd:positiveInteger" [PSI:MS]
is_a: MS:x ! native spectrum identifier
[Term]
id: MS:x
name: ABI Oracle database spectrum identifier
def: "" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: need expertise here; alternatively, we could lump these spectra 
in with DTA/PKL nativeIDs (see below) when they are extracted to T2Ds

[Term]
id: MS:x
name: Bruker spectrum identifier
def: "" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: need expertise here. AFAIK, each Bruker YEP/BAF/FID spectrum is 
natively a single file, so that seems to make nativeID irrelevant and 
sourceFile[Ref] critical

[Term]
id: MS:x
name: Shimadzu spectrum identifier
def: "" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: need expertise here

[Term]
id: MS:x
name: MGF spectrum identifier
def: "index=xsd:nonNegativeInteger" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: TITLE attributes are optional, so the index into the file is the 
only reliable source (TITLE can be used for the string id if present)

[Term]
id: MS:x
name: mzData/mzXML/MS2 spectrum identifier
def: "scan number=xsd:positiveInteger" [PSI:MS]
is_a: MS:x ! native spectrum identifier
[Term]
id: MS:x
name: PKL/DTA spectrum identifier
def: "" [PSI:MS]
is_a: MS:x ! native spectrum identifier
! note: like Bruker, a PKL or DTA could be standalone so AFAIK the only 
way to reliably reference it is via sourceFileRef

Re: [Psidev-ms-dev] Current mapping file

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

Hi Marc,


> thanks for the up-to-date link.
> The other version I found is at: 
> http://psidev.cvs.sourceforge.net/psidev/psi/psi-ms/mzML/schema/ms-mapping.xml?view=log 

Well spotted. I have now deleted this from CVS, and remarked in the log 
comment of the commit that the files should be obtained from the psidev 
SVN instead, along with the path to the validator configuration files.


> I have several questions/comments regarding the mapping file.
> 
> Comment 1:
> There is no mapping for the "/mzML/run" tag

Correct, I couldn't easily find anything that we require or expect 
there, so I let the rule out. Maybe there should be one or more rules 
added for this location, but fleshing out the mapping file is still a 
work in progress. You're very welcome to make suggestions, actually.


> Comment 2:
> There is no mapping for the 
> "/mzML/run/spectrumList/spectrum/spectrumDescription/precursorList/precursor/isolationWindow" 
> tag

Correct, we should add a meaningful rule here.


> Comment 3:
> There is no mapping for the "data processing parameter" terms (MS:1000630)

Correct again; needs to be added.


> Question 1:
> According to the mapping file the "ms level" term (MS:1000511) should be 
> under "spectrumDescription", but is under "spectrum" in the tiny1 example.
> Which one is right?

Good question. Can't remember off the top of my head what this should 
be. So you can see: there's work yet to be done on the mapping file!


Essentially, my main effort in these matters right now is spent on 
getting our reference validator up and running. Once that is achieved, 
the mapping file can be refined as we go along (the whole thing is 
descriptively configured from the XML file, so no code needs changing).

I think we should probably have a conference call dedicated to the 
mapping file at a point in the near future, but that is open to discussion.

Regardless, it would be good to have the reference validator out there 
first, so people are free to play with the mapping rules and instance 
documents. At the EBI, we're ironing out the last bugs in the validator 
now (while the mzML validator itself is simple and consists of nearly 
trivial code, this is only because (i) we have this rather complex but 
minimal memory footprint jmzML component that effectively uses an mzML 
file as a cache file, and (ii) we build the entire back-end on the 
generic PSI validator framework, which is a very complicated suite of 
modules that are high-tech codepieces in their own right -- this 
framework is also used by the PSI-MI people, for instance).


Cheers,

lnnrt.

Re: [Psidev-ms-dev] dataProcessing

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

Hi Marc, below:

> From: psi...@li...
[mailto:psidev-ms-dev-
> 
> Hi all,
> 
> i have problems understanding how the data processing part of the
schema
> is intended.
> The main question I have is: what does the "order" attribute define?
> Is it the order of different tools that were applied or the order of
> several processing steps done by the same software?

It is the order of processing steps applied to the dataset over its
journey from mass spec to current form.

> As it is under "processingMethod", I thought it defines the order of
> several processing steps done by the same software.
> However the terms "data processing action" and "file format
conversion"
> should not be repeatable in this case.
> Otherwise the order is undefined again.

I don't understand what you mean by this. It would seem entirely
possible for vendor software A to perform some thresholding first and
write out data in thresholded profile mode. Then perhaps FOSS software B
might be used to convert to mzML. Then some other program might be used
to centroid the data and write out another mzML file. These might be 3
softwares used in the history of the data with order 1, 2, 3,
respectively.

> When i looked into the tiny1 example, it confused me even more.

In this case there are several algorithms applied in the same step since
it is not known precisely in what order they were performed. So in the
example, first Xcalibur was used to perform deisotoping, charge
deconvolution, and peak picking. These are all lumped together as step
1. Perhaps they are result of a single algorithm or action and not
separatable. Or perhaps there should be some inherent order, but it is
not know to the writer. Then step 2 is the conversion to mzML. If the
order of deisotoping, charge deconvolution, and peak picking is
specifically known and relevant, it would be permissible to write this
is a 4-step process, with order 1, 2, 3, and 4.

Has this answered your question? Or perhaps I have misunderstood your
confusion? If this clears it up, I will update the documentation to
reflect this description.

Also, if any of the other designers feel I have not described the intent
correctly, please speak up!

Regards,
Eric



> I attached an image that shows parts of the corresponding parts of the
> example file, the CV file, the schema file and the mapping file.
> 
> Best,
>   Marc

Re: [Psidev-ms-dev] Current mapping file

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

Hi Marc, thanks for the feedback. I have added a direct link to this
file on the mzML information page, so it is easier to find. Thanks for
send the XSL file. We'll add that, too.

Lennart has reported that they have built a working validator at the
EBI, using their other new development, a stand-alone jmzML component
(minimal memory footprint Java object model for reading mzML), and that
they will soon release both, and he will email the list at that point.

Hopefully your comments and questions will be addressed as the new
version is released.

Thanks!
Eric


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Marc Sturm
> Sent: Monday, July 21, 2008 6:50 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Current mapping file
> 
> Hi Matt and all others,
> 
> thanks for the up-to-date link.
> The other version I found is at:
> http://psidev.cvs.sourceforge.net/psidev/psi/psi-ms/mzML/schema/ms-
> mapping.xml?view=log
> 
> I have several questions/comments regarding the mapping file.
> 
> Comment 1:
> There is no mapping for the "/mzML/run" tag
> 
> Comment 2:
> There is no mapping for the
>
"/mzML/run/spectrumList/spectrum/spectrumDescription/precursorList/precu
rs
> or/isolationWindow"
> tag
> 
> Comment 3:
> There is no mapping for the "data processing parameter" terms
(MS:1000630)
> 
> Question 1:
> According to the mapping file the "ms level" term (MS:1000511) should
be
> under "spectrumDescription", but is under "spectrum" in the tiny1
example.
> Which one is right?
> 
> Best,
>   Marc
> 
> 
> P.S.:
> I attached a small XSL script I use to visualize the mapping file.
> Perhaps it it useful for others as well.
> You simply have to add the absolute path to the XSL script to the
> mapping, then you can visualize the file in a web browser:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet type="text/xsl"
> href="file:///C:/Desktop/Projekte/OpenMS/PSI -
> mzML/Mapping/ms-mapping.xsl"?>
> ...

[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-07-21.

 

Present: Matt, Jim, Pierre-Alain, Eric

 

- validator mapping file

+ Marc Sturm asks about location of ms-mapping file. Eric will post.

+ Lennart reports that EBI has a working version of the validator and
will announce to the list very soon

 

- CV

+ Jim says we should add a CV entry for an SRF file

+ Jim will send to Eric an SRF file definition

+ Respond to Matt's query 7/7

 

- mzML support information table

+ Add TOPP

+ Add NCBI C++ toolkit

+ Add Proteios SE

 

- schema

+ Eric will reply to Marc Sturm's dataProcessing question

+ improve documentation based on that.

 

- nativeID formats?

+ Matt will create and send out a proposal for nailing this down

+ One different CV term for each possible style of nativeID?

 

- Next call

+ Next call same time in two weeks on August 4

 

 

Older notes from last call:

 

- CV status

+ Darren will check what Matt sent and then check it in

+ Eric received CV from David Sparkman

+ Lennart mentions that "% percent collision energy" is a child MS term
under UO parent

+ It is considered bad practice to add our own terms under someone
else's ontology

+ The UO ontology maintainer appears happy to add our own strange unit
terms

+ UO has some characters that OBO-Edit hates

+ Get in touch with the maintainer to fix some things in the UO

+ Darren will make a list of things to fix in UO and email to vocab list

+ Also fix all the warnings when OBO-Edit tries to save

 

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

+ Darren 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

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

 

+ Matt will update the definition of scan time: start offset time of
beginning of the scan

+ Let's NOT check in the new terms that Matt is proposing yet. They
should not be all in root.

+ Lennart will send out a possible placement of Matt's terms.

 

+ Darren will check in minor fixing

+ Darren will then email to Lennart more controversial changes

 

- validator

+ Lennart and company will start working on this again this week

+ Lennart and Matt will work on updated rules

+ 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

+ 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

 

- Issue of generic binary array CV term issue

+ Marc Sturm wants to include his own custom binary data array types.
How should this be done?

+ Possible suggestion: there should be a special TOPP CV that they
maintain?

+ TOPP CV. These new terms live in TOPP CV, but also linked to MS binary
data array type

+ Lennart will ask Luisa et al. about this issue

 

- CV template updates to vendors

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

+ It helped Matt hand craft some nice code

+ Could have a separate CV for all this information. Or just a tsv/Excel
file

+ Start another round of vendor updates

 

- 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

 

- 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?

 

- 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)

 

 

 

[Psidev-ms-dev] dataProcessing

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

Hi all,

i have problems understanding how the data processing part of the schema 
is intended.
The main question I have is: what does the "order" attribute define?
Is it the order of different tools that were applied or the order of 
several processing steps done by the same software?

As it is under "processingMethod", I thought it defines the order of 
several processing steps done by the same software.
However the terms "data processing action" and "file format conversion" 
should not be repeatable in this case.
Otherwise the order is undefined again.

When i looked into the tiny1 example, it confused me even more.

I attached an image that shows parts of the corresponding parts of the 
example file, the CV file, the schema file and the mapping file.

Best,
  Marc

Re: [Psidev-ms-dev] Current mapping file

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

Hi Matt and all others,

thanks for the up-to-date link.
The other version I found is at: 
http://psidev.cvs.sourceforge.net/psidev/psi/psi-ms/mzML/schema/ms-mapping.xml?view=log

I have several questions/comments regarding the mapping file.

Comment 1:
There is no mapping for the "/mzML/run" tag

Comment 2:
There is no mapping for the 
"/mzML/run/spectrumList/spectrum/spectrumDescription/precursorList/precursor/isolationWindow" 
tag

Comment 3:
There is no mapping for the "data processing parameter" terms (MS:1000630)

Question 1:
According to the mapping file the "ms level" term (MS:1000511) should be 
under "spectrumDescription", but is under "spectrum" in the tiny1 example.
Which one is right?

Best,
  Marc


P.S.:
I attached a small XSL script I use to visualize the mapping file.
Perhaps it it useful for others as well.
You simply have to add the absolute path to the XSL script to the 
mapping, then you can visualize the file in a web browser:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" 
href="file:///C:/Desktop/Projekte/OpenMS/PSI - 
mzML/Mapping/ms-mapping.xsl"?>
...

Re: [Psidev-ms-dev] Current mapping file

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

This is the only version I'm aware of and it was updated to the latest 
syntax last week:
https://psidev.svn.sourceforge.net/svnroot/psidev/psi/mzml/validator/ms-mapping.xml

I volunteered to go through and flesh out the rules but haven't gotten 
to it yet; this is partly because there are many terms in the CV that I 
don't know where they belong!

-Matt


Marc Sturm wrote:
> Hi all,
>
> i was looking for the mapping file (CV to XML schema) and did not find 
> it on the website.
> Is this intended or was it simply forgotten? I think it should be easily 
> available.
>
> I did find several differing  versions of the mapping file in the CVS 
> and SVN.
> Now i'm not sure which one to use. Can you please point me to the most 
> recent one?
>
> Thanks,
>   Marc
>
>   

[Psidev-ms-dev] Current mapping file

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

Hi all,

i was looking for the mapping file (CV to XML schema) and did not find 
it on the website.
Is this intended or was it simply forgotten? I think it should be easily 
available.

I did find several differing  versions of the mapping file in the CVS 
and SVN.
Now i'm not sure which one to use. Can you please point me to the most 
recent one?

Thanks,
  Marc

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

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

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

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=21&month=7&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 some recent discussions, the mzML
implementers table and other items about the CV and such.

 

Topics:

 

- 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