psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] FW: Proposed nativeID format and examples

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

Hi Eric,

Peak list formats with multiple spectra other than MGF still need to be 
covered, so I would like to change the MGF native ID definition to be a 
more general peak list definition:

So:
> "MGF nativeID format":
>   nativeID="index=0"
>   
could be changed to something like:

"Peak list file native ID format (conversion of peak list file 
containing multiple spectra, i.e. MGF, PKL or merged DTA)":
nativeID="index=0" (index is the spectrum number in the peak list file, 
starting from 0)

Maybe a comment about adding MGF TITLEs as cvParams could also be added.

Otherwise everything seems fine.

Fredrik
> "Scan number only nativeID format" (conversion from mzData or mzXML or dta
> files):
>   nativeID="scan=1"
>
> "PKL files nativeID format" (conversion from a folder of PKL files)
>   nativeID="sourceFile id" (each sourceFileRef is different)
>
> "MassHunter nativeID format":
>   nativeID=???
>
> "ABI TOFTOF nativeID format": ???
>   nativeID=???
>
> If there are multiple elements that compose a nativeID, all must be
> specified. The rationale for this is that allowing default values for
> certain elements would likely encourage some implementors not to support
> those elements. Then when those implementations encountered a fully
> specified nativeID, they would break.
>
> Note that there is a rule that all nativeIDs within a file must be unique,
> and we have nativeID in the index. Therefore nativeID cannot be empty. So if
> the file is assembled from PKL files or similar (where there is one file per
> spectrum), then the nativeIDs should be set to the IDs of the sourceFiles.
>
>   

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

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

Hi everyone, we're trying a different day and time so that more members have
an opportunity to make the meeting. The next PSI Mass Spectrometry Standards
Working Group call will be Tuesday 8am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=28
<http://www.timeanddate.com/worldclock/fixedtime.html?day=28&month=10&year=2
008&hour=15&min=0&sec=0&p1=136>
&month=10&year=2008&hour=15&min=0&sec=0&p1=136

 

Note that Europe has already changed clocks to end daylights savings, but in
the US, since we use inches instead of cm, clocks will change next weekend,
so 8am PDT is 3pm London time. Does this cause a major conflict with anyone?

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

Generic international: +44 2083222500 (UK number)

 

access code: 297427

 

Topics:

- nativeID format

- Changing location of <spectrum> cvParams

- Removing/fixing scanning method child terms

- Allow out-of-place cvParams for simplicity and reusability of
referenceableParamGroups?

- Status of unit ontology problems

- Export of CV to OLS

- Validator

- Next call

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Monday, October 13, 2008 10:08 AM
To: 'Mass spectrometry standard development'
Cc: 'Natalie Tasman'; 'Eric Deutsch'
Subject: RE: PSI-MSS WG call minutes

 

Hi everyone, here are the notes from today's call:

 

Present: Eric, Lennart, Darren, Matt, Wilfred, Jim

 

- nativeID format

+ Matt has sent out some suggestions for kinds of source data

+ Eric will revise and send out a new thread for further discussion

+ Need to add a required cvParam in fileDescription setting the nativeID
format

- Are elements optional?

+ All elements of a nativeID must be present

- validator

+ There are two proposals:

+ 1) MS CV: whitelist, all other CV: blacklist (Matt)

+ 2) All CV black list, but if a term mandated anywhere, then nowhere else
(Eric)

+ Start a new thread discussing this topic

- unit ontology

+ in progress

- Reusing paramGroups in different context? (polymorphism) (Wilfred)

+ This would be very hard if not impossible to properly validate
semantically

+ A fully dereferenced paramGroup data (tree view) would yield a messy state

+ Conclusion is that this is probably not a good idea. Wilfred will try to
post a compelling example

+ One problem is that we have cvParams in both <spectrum> and
<spectrumDescription>, which is redundant

+ Would be better to move them all into <spectrumDescription>

+ Suggestion is to move the <spectrum> cvParams to <spectrumDescription>

+ Is this too great a change to make at this point?

+ Eric will post to the list a proposal to make this change and see if there
are complaints

- other CV issues

- next call? 9am Monday or 8am Tuesday?

+ Let's try the next call at Tuesday the Oct 28 at 8am so that Pierre-Alain
can make it.

+ The new time is fine for Jim, but awkward for Eric and Darren. We'll try
it.

 

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Monday, September 29, 2008 10:28 AM
To: 'Mass spectrometry standard development'
Cc: 'Natalie Tasman'; 'Eric Deutsch'
Subject: PSI-MSS WG call minutes

 

Hi everyone, here are the notes from today's call:

 

Present: Eric, Lennart, Darren, Matt, Randy, Jim

 

- nativeID format

+ Note that nativeID is required in the index

+ We seem in agreement that we should not try to scrimp, and so we should
make the format like "sample=1 period=2 cycle=123 experiment=4"

+ Eric will send out a summary of what formats should look like for all
vendors and we'll refine

- Imaging/separate data file issue

+ imzML contacted Randy and have an example file and are concerned about XML
verbosity and secondary data file

+ Randy will send out the contact information and we will try to continue
the discussion in the future

- Validator

+ Eric sent some big files to Lennart

+ Lennart wants to make some performance enhancements

+ Need to flesh out all the rules in the rules file

+ There is a problem with the inclusion of the unit CV

+ Matt says that the on-line validator is a blacklist-based validation

+ We had once talked about the validator should be whitelist base

+ Eric proposes that the validation goes like:

  = Any term that is controlled by the mapping file may ONLY appear in the
specified location

  = Any term that it NOT controlled anywhere by the mapping file may appear
anywhere with a mild warning

+ Need to also include the nativeID validation

+ Eric will try to find the old list of things the validator should check
and email to Lennart who will publish

- WIFF converter

+ ABI is working on a WIFF -> mzML converter. Matt and Eric are testing an
alpha version

- Next PSI meeting in Turku Apr 27-29

+ Describe proposed activities: CV, software promotion, validation

- Manuscript

+ Waiting for MS CV. Needs to be in OLS first. And need to resolve the unit
ontology.

+ Aim to submit by end of the year

- Unit Ontology

+ We need to add some terms for mass spec and send to maintainer

+ We need to change some funny characters in there that are causing our
software some problems

+ Maybe we can just fix the problem by converting unit.obo to proper
Unicode? Lennart will try in next two weeks.

- Next call

+ In two weeks: Oct 13 9am. Eric will consult with PAB about possibly 8am so
he can make it.

 

Not discussed:

- mzML support information table

- MIAPE example document

- Other example documents

- CV

- CV template updates to vendors

- Documentation

- Web site

 

 

 

 

 

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Wednesday, September 24, 2008 11:25 PM
To: 'Mass spectrometry standard development'
Cc: 'Eric Deutsch'; 'Natalie Tasman'
Subject: PSI-MSS WG call Monday

 

Hi everyone, after a bit of a hiatus, the PSI Mass Spectrometry Standards
Working Group will resume with calls this Monday *September* 29 at 9am PDT:

 http://www.timeanddate.com/worldclock/fixedtime.html?day=29
<http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=9&year=20
08&hour=17&min=0&sec=0&p1=136> &month=9&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 and review all the
aspects related to mzML to start making progress again on the highest
priorities

 

Topics:

- nativeID format

- mzML support information table

- MIAPE example document

- Other example documents

- CV

- CV template updates to vendors

- Documentation

- Web site

- Validator

- WIFF converter

- Manuscript

- Turku

- Next call

 

Thanks,

Eric

 

 

Re: [Psidev-ms-dev] FW: Proposed nativeID format and examples

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

This looks good to me except for this small error:

Eric Deutsch wrote:
> "Bruker FID nativeID format":
>   nativeID=""
>   (nativeID is required to be empty because each FID is a single spectrum,
> so sourceFileRef is all that is needed)
>   
should be
> "Bruker FID nativeID format":
>   nativeID="sourceFile id" (each sourceFileRef is different)
>   
And of course we still need input about MassHunter and ABI TOF/TOF. I 
think TOF/TOF may be do-able by sourceFile id of the appropriate T2D 
file, but that still isn't really a nativeID that can link back to the 
native database.

Thanks,
Matt


>> -----Original Message-----
>> From: Matt Chambers [mailto:mat...@va...]
>> Sent: Monday, October 13, 2008 6:32 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples
>>
>> Hi Fredrik,
>>
>> We discussed optional fields before as it is true that almost all Thermo
>> files will use only 1 controller, and most of those will use only
>> controller 0. But I don't think the small benefit in file size would be
>> worth the implementation/comprehension cost of partially implicit ids.
>>
>> You're the first person I've talked to that actually knows what the
>> Waters process id is. :) If it is indeed used when the data has been
>> MassLynx-processed, I think it's critical to keep in. If some components
>> of the id are optional, then the term specifier in the CV needs to
>> indicate which ones and what their default values are.
>>
>> I do not understand the use case of "what to write if some value for
>> some reason is not known." If the file is being converted from native
>> data or from another mzML file, the values should always be known. We
>> are putting the components in the id because they are necessary to link
>> a spectrum to a native acquisition. If conversion is taking place from a
>> less explicit format like MGF, mzData, or mzXML, then it is pretty much
>> futile to try to reconstruct the native ids. Instead, we the nativeID
>> should point to the less explicit format. For MGF, that should be a
>> simple index except in specific cases where the native id can be parsed
>> from the TITLE attribute. For mzData and mzXML it should be scan number
>> except in specific cases where mzXML's scanOrigin element has been
>> provided. So for nativeID I think it's all or nothing as far
>> constructing a link to a vendor acquisition is concerned.
>>
>> As I proposed before, we should provide nativeID formats for the generic
>> text/xml formats.
>> MGF: nativeID="index=0"
>> mzData: nativeID="scan=1"
>> mzXML: nativeID="scan=1"
>>
>> I think we can get Bruker support in there too as I recently have done
>> quite a bit of work with CompassXtract.
>> Bruker/Agilent YEP: nativeID="scan=1"
>> Bruker BAF: nativeID="scan=1"
>> Bruker FID: nativeID="" // required to be empty because each FID is a
>> single spectrum, so sourceFileRef is all that is needed
>>
>> DTA is a bit of a tricky one because for Thermo derived data it can be
>> used to get the scan numbers (assuming - quite safely I think - that
>> controller 0 was used), but for other data the scan numbers would be
>> wrong and/or misleading. For consistency I'll argue that DTA be like
>> mzData and mzXML: nativeID="scan=1"
>>
>> PKL can be handled like FID, an empty nativeID and a sourceFileRef.
>>
>> Eric, can you ask Natalie for the format of the MassTrapper nativeIDs?
>>
>> T2D can be handled like FID as well. I haven't a clue how to properly
>> handle a direct reference to the Oracle database, we can probably divert
>> that one until later. ;)
>>
>> -Matt
>>
>>
>> Fredrik Levander wrote:
>>     
>>> Hi Eric,
>>>
>>> Looks fine. One comment though: Could some of the fields be optional?
>>> 'Controller' doesn't always make sense for the Thermo files, and
>>> 'process' is maybe not so relevant for all Waters data (OK, if it hasn't
>>> been processed in MassLynx, process could be put to zero, but Ithink I
>>> would prefer to leave it out).
>>> Also, I would like to have a recommendation on what to write if some
>>> value for some reason not is known. This could be to leave out or to
>>> replace the number with a question mark. Worst option would be to put a
>>> value which is maybe not correct, in order to produce a 'valid' file.
>>>
>>> Thanks
>>>
>>> Fredrik
>>>
>>> Eric Deutsch skrev:
>>>
>>>       
>>>> Hi Matt, right you are. Sorry I neglected to follow up. I believe the
>>>> proposal we agreed upon on to use this:
>>>>
>>>> Thermo:
>>>> nativeID="controller=0 scan=1"
>>>> nativeID="controller=0 scan=1243"
>>>> nativeID="controller=1 scan=1"
>>>> (where controller 0 is probably always the mass spec?)
>>>>
>>>> Waters:
>>>> nativeID="function=1 process=0 scan=1"
>>>> nativeID="function=1 process=0 scan=2"
>>>> nativeID="function=2 process=0 scan=1"
>>>>
>>>> WIFF:
>>>> nativeID="Sample=0 period=1 cycle=1 experiment=2"
>>>> nativeID="Sample=0 period=1 cycle=1 experiment=3"
>>>> nativeID="Sample=0 period=1 cycle=2 experiment=2"
>>>> nativeID="Sample=0 period=1 cycle=2 experiment=3"
>>>>
>>>> Can anyone provide any more other vendor/format examples or further
>>>>         
>> comments
>>     
>>>> that should appear in the documentation of the above?
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Matthew Chambers [mailto:mat...@va...]
>>>>> Sent: Friday, October 10, 2008 12:57 PM
>>>>> To: Mass spectrometry standard development
>>>>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday
>>>>>
>>>>> Hi Eric, we were supposed to refine the nativeID format over the last
>>>>> two weeks. :)
>>>>> You had this in the last meeting minutes:
>>>>> + Eric will send out a summary of what formats should look like for
>>>>>           
>> all
>>     
>>>>> vendors and we'll refine
>>>>>
>>>>> Would you like me to put together the summary instead? I'd basically
>>>>> replace my format and examples with the key=value format and it'd be
>>>>>           
>> set
>>     
>>>>> unless you had some other ideas.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>> Eric Deutsch wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is
>>>>>> Monday October 13 at 9am PDT:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=
>>     
>>>>> 2008&hour=17&min=0&sec=0&p1=136
>>>>>
>>>>>
>>>>>           
>> <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&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 and review all
>>>>>> the aspects related to mzML to start making progress again on the
>>>>>> highest priorities
>>>>>>
>>>>>> Topics:
>>>>>>
>>>>>> - nativeID format
>>>>>>
>>>>>> - mzML support information table
>>>>>>
>>>>>> - MIAPE example document
>>>>>>
>>>>>> - Other example documents
>>>>>>
>>>>>> - CV
>>>>>>
>>>>>> - CV template updates to vendors
>>>>>>
>>>>>> - Documentation
>>>>>>
>>>>>> - Web site
>>>>>>
>>>>>> - Validator
>>>>>>
>>>>>> - WIFF converter
>>>>>>
>>>>>> - Manuscript
>>>>>>
>>>>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>             
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

[Psidev-ms-dev] Change to mzML format???

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

Hi everyone, just in case you glossed over the previous message to the mass
spec dev list, there is an important question for everyone out there:

 

We are faced with an opportunity to make a small change to mzML that makes
it cleaner, but would *require* a small change to all existing files and
software that writes/reads mzML. We would rev to mzML 1.0.1.

 

Is there anyone out there that says "my mzML software has shipped. You can't
change it now!"

 

Thanks,

Eric

 

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

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

HI Wilfred, thanks for the post. I had a look at your example. I think I
would advocate that this should not be valid. Although not egregious as it
stands, it begins a process of having different dialects of the format,
which we want to avoid. If this is permitted, then the concept can be
stretched even more and more terms that belong in different placed could all
be piled up in inappropriate places.

 

In my view, we should follow the spec as written and place terms only where
the spec says they can occur so that we don't have different dialects and so
that reader implementations can count on where to find their terms. However,
now armed with you example, let's revisit it briefly at the call tomorrow.

 

Thanks,

Eric

 

 

  _____  

From: Wilfred H Tang [mailto:Ta...@ap...] 
Sent: Sunday, October 26, 2008 10:41 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes

 



"Eric Deutsch" <ede...@sy...> wrote on 10/13/2008 10:08:16
AM:
> - Reusing paramGroups in different context? (polymorphism) (Wilfred) 
> + This would be very hard if not impossible to properly validate
semantically 
> + A fully dereferenced paramGroup data (tree view) would yield a messy
state 
> + Conclusion is that this is probably not a good idea. Wilfred will 
> try to post a compelling example 

The attached mzML file shows an example of what I'm interested in doing.
Don't know if it's compelling though :) 


After the last meeting, I appreciate the difficulties in trying to do
semantic validation on extra terms. But I guess I'm still unclear on why
it's important for the validator to detect the presence of extra
information. In my mind, I envision the validator as a tool for detecting if
any given mzML file contains at least a minimal amount of information. That
is, does the mzML file provide enough context to enable a file to be
deposited in a repository somewhere and later anybody can pick up the file
and find all the relevant information for interpreting the data embedded in
the file already? So I'm not sure I understand why having extra terms is a
bad thing that the validator needs to flag. What am I missing here? 

Thanks, 
Wilfred 

[Psidev-ms-dev] Proposal: move spectrum cvParams to spectrumDescription

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

Hi everyone, there is a proposal to change the mzML use of cvParams in the
spectrum element is a major way as follows:

 

<spectrum index="0" id="S19" nativeID="19" defaultArrayLength="15">

  <cvParam cvRef="MS" accession="MS:1000580" name="MSn spectrum" value=""/>

  <cvParam cvRef="MS" accession="MS:1000511" name="ms level" value="1"/>

  <spectrumDescription>

    <cvParam cvRef="MS" accession="MS:1000127" name="centroid mass spectrum"
value=""/>

    <cvParam cvRef="MS" accession="MS:1000285" name="total ion current"
value="16675500"/>

    ..

    <scan>

      ..

    </scan>

  </spectrumDescription>

  ..

</spectrum>

 

Would change to:

 

<spectrum index="0" id="S19" nativeID="19" defaultArrayLength="15">

  <spectrumDescription>

    <cvParam cvRef="MS" accession="MS:1000580" name="MSn spectrum"
value=""/>

    <cvParam cvRef="MS" accession="MS:1000511" name="ms level" value="1"/>

    <cvParam cvRef="MS" accession="MS:1000127" name="centroid mass spectrum"
value=""/>

    <cvParam cvRef="MS" accession="MS:1000285" name="total ion current"
value="16675500"/>

    ..

    <scan>

      ..

    </scan>

  </spectrumDescription>

  ..

</spectrum>

 

That is, all cvParams in <spectrum> itself would be moved in
<spectrumDescription>.

 

Reasons to make this change:

- It is silly to have some attributes in <spectrum> and some in
<spectrumDescription> with no logical reason for the two varied locations

- It is perhaps slightly more difficult to read by having these attributes
in two places

- There are not yet many mzML files in the wild and it is better to change
it now than live with this silliness for years

 

Reasons NOT to make the change

- We said that we wouldn't make any major changes after we released 1.0
unless they were fundamental mistakes.

- This is slightly awkward and suboptimal, but is unambiguous and not a
mistake

- We lose credibility if we start making minor tidy-up changes to the format
after we release it

- *All* existing examples of mzML would be to be changed to accommodate this

 

There were proponents on both sides. A fundamental question is if there is
any released software packages out there that couldn't be easily changed?
Proponents for this change claim the ship hasn't sailed yet. Has it? Please
speak up if accommodating this major change causes you hardship and you find
it unacceptable.

 

Thanks,

Eric

 

 

 

 

 

 

 

 

 

 

[Psidev-ms-dev] FW: Proposed nativeID format and examples

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

Hi everyone, there was only one set of comments to my previous rev of the
nativeID proposal. Here is another rev of the native ID proposal based on
that. Please edit/comment:

The nativeID attribute is a required attribute for every spectrum and is
intended to provide a identifier to a spectrum in the name convention used
by the original (or previous) source of the data, so that it may be easily
mapped to previous forms of the data. Since the nativeID can take on
different formats for different vendors, then allowed formats must be
specified at the top of the file in the fileDescription section as a
cvParam. Such a description will appear like this:

<fileContent>
  <cvParam cvRef="MS" accession="MS:1000580" name="MSn spectrum"/>
  <cvParam cvRef="MS" accession="MS:1000127" name="centroid mass spectrum"/>
  <cvParam cvRef="MS" accession="MS:1000XXX" name="Thermo nativeID format"/>
</fileContent>

The formats to be used for different course formats is:

"Thermo nativeID format":
  nativeID="controller=0 scan=1"
  nativeID="controller=0 scan=1243"
  nativeID="controller=1 scan=1"
  (where controller 0 is probably always the mass spec?)

"Waters nativeID format":
  nativeID="function=1 process=0 scan=1"
  nativeID="function=1 process=0 scan=2"
  nativeID="function=2 process=0 scan=1"

"WIFF nativeID format":
  nativeID="Sample=0 period=1 cycle=1 experiment=2"
  nativeID="Sample=0 period=1 cycle=1 experiment=3"
  nativeID="Sample=0 period=1 cycle=2 experiment=2"
  nativeID="Sample=0 period=1 cycle=2 experiment=3"

"Bruker/Agilent YEP nativeID format":
  nativeID="scan=1"

"Bruker BAF nativeID format":
  nativeID="scan=1"

"Bruker FID nativeID format":
  nativeID=""
  (nativeID is required to be empty because each FID is a single spectrum,
so sourceFileRef is all that is needed)

"MGF nativeID format":
  nativeID="index=0"

"Scan number only nativeID format" (conversion from mzData or mzXML or dta
files):
  nativeID="scan=1"

"PKL files nativeID format" (conversion from a folder of PKL files)
  nativeID="sourceFile id" (each sourceFileRef is different)

"MassHunter nativeID format":
  nativeID=???

"ABI TOFTOF nativeID format": ???
  nativeID=???

If there are multiple elements that compose a nativeID, all must be
specified. The rationale for this is that allowing default values for
certain elements would likely encourage some implementors not to support
those elements. Then when those implementations encountered a fully
specified nativeID, they would break.

Note that there is a rule that all nativeIDs within a file must be unique,
and we have nativeID in the index. Therefore nativeID cannot be empty. So if
the file is assembled from PKL files or similar (where there is one file per
spectrum), then the nativeIDs should be set to the IDs of the sourceFiles.




> -----Original Message-----
> From: Matt Chambers [mailto:mat...@va...]
> Sent: Monday, October 13, 2008 6:32 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples
> 
> Hi Fredrik,
> 
> We discussed optional fields before as it is true that almost all Thermo
> files will use only 1 controller, and most of those will use only
> controller 0. But I don't think the small benefit in file size would be
> worth the implementation/comprehension cost of partially implicit ids.
> 
> You're the first person I've talked to that actually knows what the
> Waters process id is. :) If it is indeed used when the data has been
> MassLynx-processed, I think it's critical to keep in. If some components
> of the id are optional, then the term specifier in the CV needs to
> indicate which ones and what their default values are.
> 
> I do not understand the use case of "what to write if some value for
> some reason is not known." If the file is being converted from native
> data or from another mzML file, the values should always be known. We
> are putting the components in the id because they are necessary to link
> a spectrum to a native acquisition. If conversion is taking place from a
> less explicit format like MGF, mzData, or mzXML, then it is pretty much
> futile to try to reconstruct the native ids. Instead, we the nativeID
> should point to the less explicit format. For MGF, that should be a
> simple index except in specific cases where the native id can be parsed
> from the TITLE attribute. For mzData and mzXML it should be scan number
> except in specific cases where mzXML's scanOrigin element has been
> provided. So for nativeID I think it's all or nothing as far
> constructing a link to a vendor acquisition is concerned.
> 
> As I proposed before, we should provide nativeID formats for the generic
> text/xml formats.
> MGF: nativeID="index=0"
> mzData: nativeID="scan=1"
> mzXML: nativeID="scan=1"
> 
> I think we can get Bruker support in there too as I recently have done
> quite a bit of work with CompassXtract.
> Bruker/Agilent YEP: nativeID="scan=1"
> Bruker BAF: nativeID="scan=1"
> Bruker FID: nativeID="" // required to be empty because each FID is a
> single spectrum, so sourceFileRef is all that is needed
> 
> DTA is a bit of a tricky one because for Thermo derived data it can be
> used to get the scan numbers (assuming - quite safely I think - that
> controller 0 was used), but for other data the scan numbers would be
> wrong and/or misleading. For consistency I'll argue that DTA be like
> mzData and mzXML: nativeID="scan=1"
> 
> PKL can be handled like FID, an empty nativeID and a sourceFileRef.
> 
> Eric, can you ask Natalie for the format of the MassTrapper nativeIDs?
> 
> T2D can be handled like FID as well. I haven't a clue how to properly
> handle a direct reference to the Oracle database, we can probably divert
> that one until later. ;)
> 
> -Matt
> 
> 
> Fredrik Levander wrote:
> > Hi Eric,
> >
> > Looks fine. One comment though: Could some of the fields be optional?
> > 'Controller' doesn't always make sense for the Thermo files, and
> > 'process' is maybe not so relevant for all Waters data (OK, if it hasn't
> > been processed in MassLynx, process could be put to zero, but Ithink I
> > would prefer to leave it out).
> > Also, I would like to have a recommendation on what to write if some
> > value for some reason not is known. This could be to leave out or to
> > replace the number with a question mark. Worst option would be to put a
> > value which is maybe not correct, in order to produce a 'valid' file.
> >
> > Thanks
> >
> > Fredrik
> >
> > Eric Deutsch skrev:
> >
> >> Hi Matt, right you are. Sorry I neglected to follow up. I believe the
> >> proposal we agreed upon on to use this:
> >>
> >> Thermo:
> >> nativeID="controller=0 scan=1"
> >> nativeID="controller=0 scan=1243"
> >> nativeID="controller=1 scan=1"
> >> (where controller 0 is probably always the mass spec?)
> >>
> >> Waters:
> >> nativeID="function=1 process=0 scan=1"
> >> nativeID="function=1 process=0 scan=2"
> >> nativeID="function=2 process=0 scan=1"
> >>
> >> WIFF:
> >> nativeID="Sample=0 period=1 cycle=1 experiment=2"
> >> nativeID="Sample=0 period=1 cycle=1 experiment=3"
> >> nativeID="Sample=0 period=1 cycle=2 experiment=2"
> >> nativeID="Sample=0 period=1 cycle=2 experiment=3"
> >>
> >> Can anyone provide any more other vendor/format examples or further
> comments
> >> that should appear in the documentation of the above?
> >>
> >> Thanks,
> >> Eric
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Matthew Chambers [mailto:mat...@va...]
> >>> Sent: Friday, October 10, 2008 12:57 PM
> >>> To: Mass spectrometry standard development
> >>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday
> >>>
> >>> Hi Eric, we were supposed to refine the nativeID format over the last
> >>> two weeks. :)
> >>> You had this in the last meeting minutes:
> >>> + Eric will send out a summary of what formats should look like for
> all
> >>> vendors and we'll refine
> >>>
> >>> Would you like me to put together the summary instead? I'd basically
> >>> replace my format and examples with the key=value format and it'd be
> set
> >>> unless you had some other ideas.
> >>>
> >>> -Matt
> >>>
> >>>
> >>> Eric Deutsch wrote:
> >>>
> >>>
> >>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is
> >>>> Monday October 13 at 9am PDT:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=
> >>> 2008&hour=17&min=0&sec=0&p1=136
> >>>
> >>>
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&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 and review all
> >>>> the aspects related to mzML to start making progress again on the
> >>>> highest priorities
> >>>>
> >>>> Topics:
> >>>>
> >>>> - nativeID format
> >>>>
> >>>> - mzML support information table
> >>>>
> >>>> - MIAPE example document
> >>>>
> >>>> - Other example documents
> >>>>
> >>>> - CV
> >>>>
> >>>> - CV template updates to vendors
> >>>>
> >>>> - Documentation
> >>>>
> >>>> - Web site
> >>>>
> >>>> - Validator
> >>>>
> >>>> - WIFF converter
> >>>>
> >>>> - Manuscript
> >>>>
> >>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Eric
> >>>>
> 
> 
> -------------------------------------------------------------------------
> 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 terms under scan-->scanning method andspectrum-->spectrum type

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

Hi Wilfred, you're right that there is partial duplication that is wrong. I
suggest option 4. Under scanning method:

 

MUST supply a *child* term of MS:1000020 (scanning method) only once
x e.g.: MS:1000100 (precursor ion scan)
x e.g.: MS:1000101 (product ion scan)
x e.g.: MS:1000205 (selected ion monitoring)
x e.g.: MS:1000206 (selected reaction monitoring)
x e.g.: MS:1000244 (consecutive reaction monitoring)
  e.g.: MS:1000323 (constant neutral loss scan)
  e.g.: MS:1000324 (constant neutral gain scan)
  e.g.: MS:1000497 (zoom scan)
  e.g.: MS:1000498 (full scan)

 

The first 5 are duplicates and should be removed and thus disallowed in this
location.

 

The last 2 are what was primarily intended for scanning method, I think. I'm
not sure about the neutral loss/gain terms. Anyone understand these terms
and know where to put them?

 

Comments?

 

Discuss tomorrow?

 

Thanks,

Eric

 

 

 

  _____  

From: Wilfred H Tang [mailto:Ta...@ap...] 
Sent: Sunday, October 26, 2008 10:44 PM
To: Mass spectrometry standard development
Subject: [Psidev-ms-dev] CV terms under scan-->scanning method
andspectrum-->spectrum type

 


There is partial duplication of analogous terms (example of analagous terms:
"SIM spectrum" <===> "selected ion monitoring") between the two categories.
While it's not clear that the duplication of analogous terms is desirable,
in any case, there should be either no duplication or full duplication;
partial duplication is obviously flat-out wrong. 

Here are a few options for solving this: 

Option 1: Add the following terms to make the duplication of analagous terms
consistent 

[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 

Option 2: Delete all the CV terms under scan-->scanning method. Allow both
spectrum and scan to use the CV terms under spectrum-->spectrum type 

Option 3: Delete all the CV terms under spectrum-->spectrum type. Allow both
spectrum and scan to use the CV terms under scan-->scanning method 

Thanks, 
Wilfred

[Psidev-ms-dev] spectrum vs. scan

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

I'm still puzzled by the distinction between spectrum vs. scan. At the 
previous meeting, I thought the explanation was that a spectrum can 
consist of multiple scans. But the schema actually says that a spectrum 
can only have one scan. So now I'm as confused as ever...

Thanks,
Wilfred

[Psidev-ms-dev] CV terms under scan-->scanning method and spectrum-->spectrum type

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

There is partial duplication of analogous terms (example of analagous 
terms: "SIM spectrum" <===> "selected ion monitoring") between the two 
categories. While it's not clear that the duplication of analogous terms 
is desirable, in any case, there should be either no duplication or full 
duplication; partial duplication is obviously flat-out wrong.

Here are a few options for solving this:

Option 1: Add the following terms to make the duplication of analagous 
terms consistent

[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

Option 2: Delete all the CV terms under scan-->scanning method. Allow both 
spectrum and scan to use the CV terms under spectrum-->spectrum type

Option 3: Delete all the CV terms under spectrum-->spectrum type. Allow 
both spectrum and scan to use the CV terms under scan-->scanning method

Thanks,
Wilfred

[Psidev-ms-dev] FYA: XML alternative

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

For your amusement, if you're starting to get a little cross-eyed
looking at all of this XML, you might find this alternative
interesting:

    http://api.flickr.com/services/feeds/photos_public.gne?id=68497070@N00&lang=en-us&format=lol

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Good question. The semantic validator (as well as semantically conscious 
readers, like ProteoWizard will be once we settle this format :) ) will 
check the syntax. It won't be necessary to do it with regular 
expressions I think because the syntax is so rigid. Simple tokenizing 
should suffice.

-Matt


Toorn, H.W.P. van den (Henk) wrote:
>
> Hi,
>
>  
>
> Are there any plans on checking the syntax of these nativeIDs? Would 
> there be some regular expression checking in the schema?
>
>  
>
> Henk
>
>  
>
> *From:* David Creasy [mailto:dc...@ma...]
> *Sent:* Wednesday, October 15, 2008 1:08 PM
> *To:* Mass spectrometry standard development
> *Subject:* Re: [Psidev-ms-dev] Proposed nativeID format and examples
>
>  
>
> Hi,
>
> I've not been following this in detail (so may have not understood), 
> but I'm not convinced that it's a good idea to have the nativeID of an 
> MGF file as the index. In an MGF file, you can have, for example:
>
> TITLE=129: Sum of 9 scans in range 1896 (rt=2406.79, f=2, i=767) to 
> 1904 (rt=2415.69, f=2, i=775) [Y:\masslynx\3.5\qtof10348.raw]
> SCANS=1896-1904
> RTINSECONDS=2406.7902-2415.6901
>
> Hopefully, not many people will convert mgf to mzML, but imagine the 
> use case of someone converting an MGF to mzML, performing a search, 
> exporting the results to an analysisXML document.
> To be able to locate the spectrum in the original raw data for a 
> particular peptide match, they will need the mzML 'id' (which is what 
> we'll be recording in analysisXML). They will then find this in the 
> mzML file and realise that there isn't much to help there except the 
> nativeID for the mgf file. They hopefully still have the mgf file and 
> have to somehow find the correct lines in the mgf (btw, is 'index' a 
> line number or a spectrum number?). From this, they then have 
> information which hopefully enables them to find the relevant spectrum 
> in the raw data. Phew!
> Maybe it's possible to get more information into the mzML, or maybe it 
> doesn't matter?
>
> (btw, the "TITLE" in an mgf can contain any information that the 
> creator of the mgf likes, so it's not possible to parse this reliably)
>
> Likewise, if someone writes a converter that takes a bunch of .dta 
> files and puts these into an mzML, we surely don't want to lose the 
> information that's encapsulated in the .dta file names?
>
> David
>
> Fredrik Levander wrote:
>
> Hi Eric and Matt,
>  
> I don't get why PKL files cannot have native ID in the same way as MGF 
> files (index=0 etc). Normally there is 1 PKL per raw file (with 
> peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
> file, since multiple runs are currently not supported in mzML.  Merged  
> DTA files could be treated in the same way, while folders of DTA files 
> optionally could be converted to get native IDs in the Thermo form (if 
> these can be derived). For folders of DTA files where scan numbers 
> cannot be derived from the file names I guess there will be the problem 
> with the same nativeID and only source file differing though, so 
> probably nativeIDs cannot be required to be unique. If multiple runs 
> will be allowed at some time, there could also be nativeID repetition.
>  
> Fredrik
>  
> Eric Deutsch wrote:
>   
>
>     Hi everyone, here is another rev of the native ID proposal. Please
>
>     edit/comment:
>
>      
>
>     "MGF nativeID format":
>
>       nativeID="index=0"
>
>      
>
>     "Scan number only nativeID format" (conversion from mzData or mzXML or dta
>
>     files):
>
>       nativeID="scan=1"
>
>      
>
>     "PKL files nativeID format" (conversion from a folder of PKL files)
>
>       nativeID="" (each sourceFileRef is different)
>
>      
>
>       
>
>         
>
>  
>  
> -------------------------------------------------------------------------
> 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=/ <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li... <mailto:Psi...@li...>
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   
>
>  
>
> -- 
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
>  
> dc...@ma... <mailto:dc...@ma...>
> http://www.matrixscience.com
>  
> Matrix Science Ltd. is registered in England and Wales
> Company number 3533898
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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] Proposed nativeID format and examples

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

Matt Chambers wrote:
> Hi Fredrik,
>
> I didn't realize that about PKL files. Can PKL also be one file per 
> spectrum (all in a single run)? If it is virtually certain that all 
> spectra in a single run are in a single PKL, then I agree the MGF 
> nativeID approach makes sense. If it's arbitrary though and readers may 
> run into both types, I'm not sure which route to take.
>
>   
Hi Matt,

After having a look at PLGS it seems like you can choose to output one 
PKL file per spectrum, although I have never seen anyone using it. So 
PKLs can be like DTAs.  There is maybe need for something like this to 
cover all possibilities:

"Multiple peak list nativeID format" (conversion of peak list files with multiple spectra, i.e. MGF, PKL, merged DTA files. Index is the spectrum number in the file, starting from 0)
  nativeID="index=0"

"Single peak list nativeID format" (conversion of peak list files with one spectrum per file, typically folder of PKL or DTAs, each sourceFileRef is different)
  nativeID="" (???? OR nativeID="filename"????)

"Scan number only nativeID format" (conversion from mzData or mzXML, or dta
folder where native scan numbers can be derived):
  nativeID="scan=1"


Fredrik

Re: [Psidev-ms-dev] Proposed nativeID format and examples

[Toorn, H.W.P. v. d. (Henk) <H.W...@uu...>]

Hi,

 

Are there any plans on checking the syntax of these nativeIDs? Would
there be some regular expression checking in the schema?

 

Henk

 

From: David Creasy [mailto:dc...@ma...] 
Sent: Wednesday, October 15, 2008 1:08 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples

 

Hi,

I've not been following this in detail (so may have not understood), but
I'm not convinced that it's a good idea to have the nativeID of an MGF
file as the index. In an MGF file, you can have, for example:

TITLE=129: Sum of 9 scans in range 1896 (rt=2406.79, f=2, i=767) to 1904
(rt=2415.69, f=2, i=775) [Y:\masslynx\3.5\qtof10348.raw]
SCANS=1896-1904
RTINSECONDS=2406.7902-2415.6901

Hopefully, not many people will convert mgf to mzML, but imagine the use
case of someone converting an MGF to mzML, performing a search,
exporting the results to an analysisXML document. 
To be able to locate the spectrum in the original raw data for a
particular peptide match, they will need the mzML 'id' (which is what
we'll be recording in analysisXML). They will then find this in the mzML
file and realise that there isn't much to help there except the nativeID
for the mgf file. They hopefully still have the mgf file and have to
somehow find the correct lines in the mgf (btw, is 'index' a line number
or a spectrum number?). From this, they then have information which
hopefully enables them to find the relevant spectrum in the raw data.
Phew!
Maybe it's possible to get more information into the mzML, or maybe it
doesn't matter?

(btw, the "TITLE" in an mgf can contain any information that the creator
of the mgf likes, so it's not possible to parse this reliably)

Likewise, if someone writes a converter that takes a bunch of .dta files
and puts these into an mzML, we surely don't want to lose the
information that's encapsulated in the .dta file names?

David

Fredrik Levander wrote: 

Hi Eric and Matt,
 
I don't get why PKL files cannot have native ID in the same way as MGF 
files (index=0 etc). Normally there is 1 PKL per raw file (with 
peaklists separated by blank lines), so it would scale to 1 mzML per PKL

file, since multiple runs are currently not supported in mzML.  Merged  
DTA files could be treated in the same way, while folders of DTA files 
optionally could be converted to get native IDs in the Thermo form (if 
these can be derived). For folders of DTA files where scan numbers 
cannot be derived from the file names I guess there will be the problem 
with the same nativeID and only source file differing though, so 
probably nativeIDs cannot be required to be unique. If multiple runs 
will be allowed at some time, there could also be nativeID repetition.
 
Fredrik
 
Eric Deutsch wrote:
  

	Hi everyone, here is another rev of the native ID proposal.
Please
	edit/comment:
	 
	"MGF nativeID format":
	  nativeID="index=0"
	 
	"Scan number only nativeID format" (conversion from mzData or
mzXML or dta
	files):
	  nativeID="scan=1"
	 
	"PKL files nativeID format" (conversion from a folder of PKL
files)
	  nativeID="" (each sourceFileRef is different)
	 
	  
	    

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

 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344
 
dc...@ma...
http://www.matrixscience.com
 
Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Comments below:

Matt Chambers wrote:
> Hi David, it's good to have any extra feedback. :)
>
> Because all the attributes you mentioned are optional, we can't use them 
> for nativeID. However, I think it's reasonable to add a CV param for the 
> MGF TITLE attribute and include it when available. That way, at least 
> the impossible-to-parse line will be available in the right place in the 
> mzML for users to read.
>   
This sounds like a good solution

> This mention of the case of summed/averaged acquisitions raises the 
> tricky question of what to do with nativeID in those cases - even when 
> doing the summing straight from the native data. A single nativeID 
> doesn't make sense for a merged spectrum. I suspect we discussed this 
> before but I don't remember what the answer was. :)
>
> -Matt
>   
I think the agreed solution was to give the native ID of the first 
spectrum in the 'spectrum' element, and then all of the spectra are 
referred to by externalNativeID under 'acquisition'. At least it is so 
in the example (row 107-)
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/plgs_example.mzML
(The native ids are not updated to the new format yet)

An advanced MGF parser could also try to do this, but the MGF TITLE is 
free text so it is probably not worth bothering.

-Fredrik
>
> David Creasy wrote:
>   
>> Hi,
>>
>> I've not been following this in detail (so may have not understood), 
>> but I'm not convinced that it's a good idea to have the nativeID of an 
>> MGF file as the index. In an MGF file, you can have, for example:
>>
>> TITLE=129: Sum of 9 scans in range 1896 (rt=2406.79, f=2, i=767) to 
>> 1904 (rt=2415.69, f=2, i=775) [Y:\masslynx\3.5\qtof10348.raw]
>> SCANS=1896-1904
>> RTINSECONDS=2406.7902-2415.6901
>>
>> Hopefully, not many people will convert mgf to mzML, but imagine the 
>> use case of someone converting an MGF to mzML, performing a search, 
>> exporting the results to an analysisXML document.
>> To be able to locate the spectrum in the original raw data for a 
>> particular peptide match, they will need the mzML 'id' (which is what 
>> we'll be recording in analysisXML). They will then find this in the 
>> mzML file and realise that there isn't much to help there except the 
>> nativeID for the mgf file. They hopefully still have the mgf file and 
>> have to somehow find the correct lines in the mgf (btw, is 'index' a 
>> line number or a spectrum number?). From this, they then have 
>> information which hopefully enables them to find the relevant spectrum 
>> in the raw data. Phew!
>> Maybe it's possible to get more information into the mzML, or maybe it 
>> doesn't matter?
>>
>> (btw, the "TITLE" in an mgf can contain any information that the 
>> creator of the mgf likes, so it's not possible to parse this reliably)
>>
>> Likewise, if someone writes a converter that takes a bunch of .dta 
>> files and puts these into an mzML, we surely don't want to lose the 
>> information that's encapsulated in the .dta file names?
>>
>> David
>>
>> Fredrik Levander wrote:
>>     
>>> Hi Eric and Matt,
>>>
>>> I don't get why PKL files cannot have native ID in the same way as MGF 
>>> files (index=0 etc). Normally there is 1 PKL per raw file (with 
>>> peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
>>> file, since multiple runs are currently not supported in mzML.  Merged  
>>> DTA files could be treated in the same way, while folders of DTA files 
>>> optionally could be converted to get native IDs in the Thermo form (if 
>>> these can be derived). For folders of DTA files where scan numbers 
>>> cannot be derived from the file names I guess there will be the problem 
>>> with the same nativeID and only source file differing though, so 
>>> probably nativeIDs cannot be required to be unique. If multiple runs 
>>> will be allowed at some time, there could also be nativeID repetition.
>>>
>>> Fredrik
>>>
>>> Eric Deutsch wrote:
>>>   
>>>       
>>>> Hi everyone, here is another rev of the native ID proposal. Please
>>>> edit/comment:
>>>>
>>>> "MGF nativeID format":
>>>>   nativeID="index=0"
>>>>
>>>> "Scan number only nativeID format" (conversion from mzData or mzXML or dta
>>>> files):
>>>>   nativeID="scan=1"
>>>>
>>>> "PKL files nativeID format" (conversion from a folder of PKL files)
>>>>   nativeID="" (each sourceFileRef is different)
>>>>       
>>>>         
>
> -------------------------------------------------------------------------
> 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] Proposed nativeID format and examples

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

Hi Fredrik,

I didn't realize that about PKL files. Can PKL also be one file per 
spectrum (all in a single run)? If it is virtually certain that all 
spectra in a single run are in a single PKL, then I agree the MGF 
nativeID approach makes sense. If it's arbitrary though and readers may 
run into both types, I'm not sure which route to take.

For DTA, you are right. DTA will use the "Scan number only nativeID 
format" which is not necessarily the same as a Thermo id. This is 
because even for non-Thermo data you will get consecutively numbered 
DTAs, and without non-conventional metadata there's no way to know the 
DTAs came from a Thermo instrument.

I've never seen DTAs where scan numbers couldn't be derived with a 
simple parser (although the parsing necessary varies slightly). In such 
a case though, I can see using the same approach as FID: using the 
nativeID to point to the filename.

-Matt


Fredrik Levander wrote:
> Hi Eric and Matt,
>
> I don't get why PKL files cannot have native ID in the same way as MGF 
> files (index=0 etc). Normally there is 1 PKL per raw file (with 
> peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
> file, since multiple runs are currently not supported in mzML.  Merged  
> DTA files could be treated in the same way, while folders of DTA files 
> optionally could be converted to get native IDs in the Thermo form (if 
> these can be derived). For folders of DTA files where scan numbers 
> cannot be derived from the file names I guess there will be the problem 
> with the same nativeID and only source file differing though, so 
> probably nativeIDs cannot be required to be unique. If multiple runs 
> will be allowed at some time, there could also be nativeID repetition.
>
> Fredrik
>
> Eric Deutsch wrote:
>   
>> Hi everyone, here is another rev of the native ID proposal. Please
>> edit/comment:
>>
>> "MGF nativeID format":
>>   nativeID="index=0"
>>
>> "Scan number only nativeID format" (conversion from mzData or mzXML or dta
>> files):
>>   nativeID="scan=1"
>>
>> "PKL files nativeID format" (conversion from a folder of PKL files)
>>   nativeID="" (each sourceFileRef is different)
>>     

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Hi David, it's good to have any extra feedback. :)

Because all the attributes you mentioned are optional, we can't use them 
for nativeID. However, I think it's reasonable to add a CV param for the 
MGF TITLE attribute and include it when available. That way, at least 
the impossible-to-parse line will be available in the right place in the 
mzML for users to read.

This mention of the case of summed/averaged acquisitions raises the 
tricky question of what to do with nativeID in those cases - even when 
doing the summing straight from the native data. A single nativeID 
doesn't make sense for a merged spectrum. I suspect we discussed this 
before but I don't remember what the answer was. :)

-Matt


David Creasy wrote:
> Hi,
>
> I've not been following this in detail (so may have not understood), 
> but I'm not convinced that it's a good idea to have the nativeID of an 
> MGF file as the index. In an MGF file, you can have, for example:
>
> TITLE=129: Sum of 9 scans in range 1896 (rt=2406.79, f=2, i=767) to 
> 1904 (rt=2415.69, f=2, i=775) [Y:\masslynx\3.5\qtof10348.raw]
> SCANS=1896-1904
> RTINSECONDS=2406.7902-2415.6901
>
> Hopefully, not many people will convert mgf to mzML, but imagine the 
> use case of someone converting an MGF to mzML, performing a search, 
> exporting the results to an analysisXML document.
> To be able to locate the spectrum in the original raw data for a 
> particular peptide match, they will need the mzML 'id' (which is what 
> we'll be recording in analysisXML). They will then find this in the 
> mzML file and realise that there isn't much to help there except the 
> nativeID for the mgf file. They hopefully still have the mgf file and 
> have to somehow find the correct lines in the mgf (btw, is 'index' a 
> line number or a spectrum number?). From this, they then have 
> information which hopefully enables them to find the relevant spectrum 
> in the raw data. Phew!
> Maybe it's possible to get more information into the mzML, or maybe it 
> doesn't matter?
>
> (btw, the "TITLE" in an mgf can contain any information that the 
> creator of the mgf likes, so it's not possible to parse this reliably)
>
> Likewise, if someone writes a converter that takes a bunch of .dta 
> files and puts these into an mzML, we surely don't want to lose the 
> information that's encapsulated in the .dta file names?
>
> David
>
> Fredrik Levander wrote:
>> Hi Eric and Matt,
>>
>> I don't get why PKL files cannot have native ID in the same way as MGF 
>> files (index=0 etc). Normally there is 1 PKL per raw file (with 
>> peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
>> file, since multiple runs are currently not supported in mzML.  Merged  
>> DTA files could be treated in the same way, while folders of DTA files 
>> optionally could be converted to get native IDs in the Thermo form (if 
>> these can be derived). For folders of DTA files where scan numbers 
>> cannot be derived from the file names I guess there will be the problem 
>> with the same nativeID and only source file differing though, so 
>> probably nativeIDs cannot be required to be unique. If multiple runs 
>> will be allowed at some time, there could also be nativeID repetition.
>>
>> Fredrik
>>
>> Eric Deutsch wrote:
>>   
>>> Hi everyone, here is another rev of the native ID proposal. Please
>>> edit/comment:
>>>
>>> "MGF nativeID format":
>>>   nativeID="index=0"
>>>
>>> "Scan number only nativeID format" (conversion from mzData or mzXML or dta
>>> files):
>>>   nativeID="scan=1"
>>>
>>> "PKL files nativeID format" (conversion from a folder of PKL files)
>>>   nativeID="" (each sourceFileRef is different)
>>>       

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I've not been following this in detail (so may have not understood),
but I'm not convinced that it's a good idea to have the nativeID of an
MGF file as the index. In an MGF file, you can have, for example:<br>
<br>
TITLE=129: Sum of 9 scans in range 1896 (rt=2406.79, f=2, i=767) to
1904 (rt=2415.69, f=2, i=775) [Y:\masslynx\3.5\qtof10348.raw]<br>
SCANS=1896-1904<br>
RTINSECONDS=2406.7902-2415.6901<br>
<br>
Hopefully, not many people will convert mgf to mzML, but imagine the
use case of someone converting an MGF to mzML, performing a search,
exporting the results to an analysisXML document. <br>
To be able to locate the spectrum in the original raw data for a
particular peptide match, they will need the mzML 'id' (which is what
we'll be recording in analysisXML). They will then find this in the
mzML file and realise that there isn't much to help there except the
nativeID for the mgf file. They hopefully still have the mgf file and
have to somehow find the correct lines in the mgf (btw, is 'index' a
line number or a spectrum number?). From this, they then have
information which hopefully enables them to find the relevant spectrum
in the raw data. Phew!<br>
Maybe it's possible to get more information into the mzML, or maybe it
doesn't matter?<br>
<br>
(btw, the "TITLE" in an mgf can contain any information that the
creator of the mgf likes, so it's not possible to parse this reliably)<br>
<br>
Likewise, if someone writes a converter that takes a bunch of .dta
files and puts these into an mzML, we surely don't want to lose the
information that's encapsulated in the .dta file names?<br>
<br>
David<br>
<br>
Fredrik Levander wrote:
<blockquote cite="mid:48F...@im..." type="cite">
  <pre wrap="">Hi Eric and Matt,

I don't get why PKL files cannot have native ID in the same way as MGF 
files (index=0 etc). Normally there is 1 PKL per raw file (with 
peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
file, since multiple runs are currently not supported in mzML.  Merged  
DTA files could be treated in the same way, while folders of DTA files 
optionally could be converted to get native IDs in the Thermo form (if 
these can be derived). For folders of DTA files where scan numbers 
cannot be derived from the file names I guess there will be the problem 
with the same nativeID and only source file differing though, so 
probably nativeIDs cannot be required to be unique. If multiple runs 
will be allowed at some time, there could also be nativeID repetition.

Fredrik

Eric Deutsch wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi everyone, here is another rev of the native ID proposal. Please
edit/comment:

"MGF nativeID format":
  nativeID="index=0"

"Scan number only nativeID format" (conversion from mzData or mzXML or dta
files):
  nativeID="scan=1"

"PKL files nativeID format" (conversion from a folder of PKL files)
  nativeID="" (each sourceFileRef is different)

  
    </pre>
  </blockquote>
  <pre wrap=""><!---->

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a>
_______________________________________________
Psidev-ms-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Psi...@li...">Psi...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev">https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

<a class="moz-txt-link-abbreviated" href="mailto:dc...@ma...">dc...@ma...</a>
<a class="moz-txt-link-freetext" href="http://www.matrixscience.com">http://www.matrixscience.com</a>

Matrix Science Ltd. is registered in England and Wales
Company number 3533898</pre>
</body>
</html>

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Hi Eric and Matt,

I don't get why PKL files cannot have native ID in the same way as MGF 
files (index=0 etc). Normally there is 1 PKL per raw file (with 
peaklists separated by blank lines), so it would scale to 1 mzML per PKL 
file, since multiple runs are currently not supported in mzML.  Merged  
DTA files could be treated in the same way, while folders of DTA files 
optionally could be converted to get native IDs in the Thermo form (if 
these can be derived). For folders of DTA files where scan numbers 
cannot be derived from the file names I guess there will be the problem 
with the same nativeID and only source file differing though, so 
probably nativeIDs cannot be required to be unique. If multiple runs 
will be allowed at some time, there could also be nativeID repetition.

Fredrik

Eric Deutsch wrote:
> Hi everyone, here is another rev of the native ID proposal. Please
> edit/comment:
>
> "MGF nativeID format":
>   nativeID="index=0"
>
> "Scan number only nativeID format" (conversion from mzData or mzXML or dta
> files):
>   nativeID="scan=1"
>
> "PKL files nativeID format" (conversion from a folder of PKL files)
>   nativeID="" (each sourceFileRef is different)
>
>   

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

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

Hi Eric and all,
thanks for trying to accomodate, I appreciate.
Let see during the ccall if we can find another slot that would suit 
best for all
And sorry for not being able to join mondays at this current timeslot.

Pierre-Alain

Eric Deutsch wrote:
>
> Hi everyone, here are the notes from today's call:
>
>  
>
> Present: Eric, Lennart, Darren, Matt, Wilfred, Jim
>
>  
>
> - nativeID format
>
> + Matt has sent out some suggestions for kinds of source data
>
> + Eric will revise and send out a new thread for further discussion
>
> + Need to add a required cvParam in fileDescription setting the 
> nativeID format
>
> - Are elements optional?
>
> + All elements of a nativeID must be present
>
> - validator
>
> + There are two proposals:
>
> + 1) MS CV: whitelist, all other CV: blacklist (Matt)
>
> + 2) All CV black list, but if a term mandated anywhere, then nowhere 
> else (Eric)
>
> + Start a new thread discussing this topic
>
> - unit ontology
>
> + in progress
>
> - Reusing paramGroups in different context? (polymorphism) (Wilfred)
>
> + This would be very hard if not impossible to properly validate 
> semantically
>
> + A fully dereferenced paramGroup data (tree view) would yield a messy 
> state
>
> + Conclusion is that this is probably not a good idea. Wilfred will 
> try to post a compelling example
>
> + One problem is that we have cvParams in both <spectrum> and 
> <spectrumDescription>, which is redundant
>
> + Would be better to move them all into <spectrumDescription>
>
> + Suggestion is to move the <spectrum> cvParams to <spectrumDescription>
>
> + Is this too great a change to make at this point?
>
> + Eric will post to the list a proposal to make this change and see if 
> there are complaints
>
> - other CV issues
>
> - next call? 9am Monday or 8am Tuesday?
>
> + Let's try the next call at Tuesday the Oct 28 at 8am so that 
> Pierre-Alain can make it.
>
> + The new time is fine for Jim, but awkward for Eric and Darren. We'll 
> try it.
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Eric Deutsch [mailto:ede...@sy...]
> *Sent:* Monday, September 29, 2008 10:28 AM
> *To:* 'Mass spectrometry standard development'
> *Cc:* 'Natalie Tasman'; 'Eric Deutsch'
> *Subject:* PSI-MSS WG call minutes
>
>  
>
> Hi everyone, here are the notes from today's call:
>
>  
>
> Present: Eric, Lennart, Darren, Matt, Randy, Jim
>
>  
>
> - nativeID format
>
> + Note that nativeID is required in the index
>
> + We seem in agreement that we should not try to scrimp, and so we 
> should make the format like "sample=1 period=2 cycle=123 experiment=4"
>
> + Eric will send out a summary of what formats should look like for 
> all vendors and we'll refine
>
> - Imaging/separate data file issue
>
> + imzML contacted Randy and have an example file and are concerned 
> about XML verbosity and secondary data file
>
> + Randy will send out the contact information and we will try to 
> continue the discussion in the future
>
> - Validator
>
> + Eric sent some big files to Lennart
>
> + Lennart wants to make some performance enhancements
>
> + Need to flesh out all the rules in the rules file
>
> + There is a problem with the inclusion of the unit CV
>
> + Matt says that the on-line validator is a blacklist-based validation
>
> + We had once talked about the validator should be whitelist base
>
> + Eric proposes that the validation goes like:
>
>   = Any term that is controlled by the mapping file may ONLY appear in 
> the specified location
>
>   = Any term that it NOT controlled anywhere by the mapping file may 
> appear anywhere with a mild warning
>
> + Need to also include the nativeID validation
>
> + Eric will try to find the old list of things the validator should 
> check and email to Lennart who will publish
>
> - WIFF converter
>
> + ABI is working on a WIFF -> mzML converter. Matt and Eric are 
> testing an alpha version
>
> - Next PSI meeting in Turku Apr 27-29
>
> + Describe proposed activities: CV, software promotion, validation
>
> - Manuscript
>
> + Waiting for MS CV. Needs to be in OLS first. And need to resolve the 
> unit ontology.
>
> + Aim to submit by end of the year
>
> - Unit Ontology
>
> + We need to add some terms for mass spec and send to maintainer
>
> + We need to change some funny characters in there that are causing 
> our software some problems
>
> + Maybe we can just fix the problem by converting unit.obo to proper 
> Unicode? Lennart will try in next two weeks.
>
> - Next call
>
> + In two weeks: Oct 13 9am. Eric will consult with PAB about possibly 
> 8am so he can make it.
>
>  
>
> Not discussed:
>
> - mzML support information table
>
> - MIAPE example document
>
> - Other example documents
>
> - CV
>
> - CV template updates to vendors
>
> - Documentation
>
> - Web site
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Eric Deutsch [mailto:ede...@sy...]
> *Sent:* Wednesday, September 24, 2008 11:25 PM
> *To:* 'Mass spectrometry standard development'
> *Cc:* 'Eric Deutsch'; 'Natalie Tasman'
> *Subject:* PSI-MSS WG call Monday
>
>  
>
> Hi everyone, after a bit of a hiatus, the PSI Mass Spectrometry 
> Standards Working Group will resume with calls this Monday 
> **September** 29 at 9am PDT:
>
>  http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=9&year=2008&hour=17&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=9&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 and review all 
> the aspects related to mzML to start making progress again on the 
> highest priorities
>
>  
>
> Topics:
>
> - nativeID format
>
> - mzML support information table
>
> - MIAPE example document
>
> - Other example documents
>
> - CV
>
> - CV template updates to vendors
>
> - Documentation
>
> - Web site
>
> - Validator
>
> - WIFF converter
>
> - Manuscript
>
> - Turku
>
> - Next call
>
>  
>
> Thanks,
>
> Eric
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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] Sean L Seymour/FOS/PEC is out of the office.

[Sean L S. <Sey...@ap...>]

I will be out of the office starting  10/11/2008 and will not return until
10/14/2008.

I will have limited access to email.

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Eric Deutsch wrote:
> "MassLynx nativeID format": ???
>   nativeID=???
>
> "ABI T2D nativeID format": ???
>   nativeID=???
>   
I think you meant MassHunter, not MassLynx (which is Waters RAW). And 
for T2D we can go the same route as FID and PKL.


> If there are multiple elements that compose a nativeID, all must be
> specified.
>   
The rationale for this is that allowing default values for certain 
elements would likely encourage some implementors not to support those 
elements. Then when those implementations encountered a fully specified 
nativeID, they would break.


> [Issues:
> - Don't we/shouldn't we have a rule that all nativeIDs within a file must be
> unique? If we do, then having an empty nativeID is a problem. We have
> nativeID in the index. But if the file is from PKL files, and there are no
> nativeIDs, just source file differences, one couldn't capture this in the
> index. Maybe not a problem.
> ]
>   
Good point Eric. Perhaps the nativeID in those cases should not be 
empty, but should rather be the sourceFile's id itself? I.e. it would 
duplicate the sourceFileRef attribute and still be unique per file.

-Matt


>> -----Original Message-----
>> From: Matt Chambers [mailto:mat...@va...]
>> Sent: Monday, October 13, 2008 6:32 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples
>>
>> Hi Fredrik,
>>
>> We discussed optional fields before as it is true that almost all Thermo
>> files will use only 1 controller, and most of those will use only
>> controller 0. But I don't think the small benefit in file size would be
>> worth the implementation/comprehension cost of partially implicit ids.
>>
>> You're the first person I've talked to that actually knows what the
>> Waters process id is. :) If it is indeed used when the data has been
>> MassLynx-processed, I think it's critical to keep in. If some components
>> of the id are optional, then the term specifier in the CV needs to
>> indicate which ones and what their default values are.
>>
>> I do not understand the use case of "what to write if some value for
>> some reason is not known." If the file is being converted from native
>> data or from another mzML file, the values should always be known. We
>> are putting the components in the id because they are necessary to link
>> a spectrum to a native acquisition. If conversion is taking place from a
>> less explicit format like MGF, mzData, or mzXML, then it is pretty much
>> futile to try to reconstruct the native ids. Instead, we the nativeID
>> should point to the less explicit format. For MGF, that should be a
>> simple index except in specific cases where the native id can be parsed
>> from the TITLE attribute. For mzData and mzXML it should be scan number
>> except in specific cases where mzXML's scanOrigin element has been
>> provided. So for nativeID I think it's all or nothing as far
>> constructing a link to a vendor acquisition is concerned.
>>
>> As I proposed before, we should provide nativeID formats for the generic
>> text/xml formats.
>> MGF: nativeID="index=0"
>> mzData: nativeID="scan=1"
>> mzXML: nativeID="scan=1"
>>
>> I think we can get Bruker support in there too as I recently have done
>> quite a bit of work with CompassXtract.
>> Bruker/Agilent YEP: nativeID="scan=1"
>> Bruker BAF: nativeID="scan=1"
>> Bruker FID: nativeID="" // required to be empty because each FID is a
>> single spectrum, so sourceFileRef is all that is needed
>>
>> DTA is a bit of a tricky one because for Thermo derived data it can be
>> used to get the scan numbers (assuming - quite safely I think - that
>> controller 0 was used), but for other data the scan numbers would be
>> wrong and/or misleading. For consistency I'll argue that DTA be like
>> mzData and mzXML: nativeID="scan=1"
>>
>> PKL can be handled like FID, an empty nativeID and a sourceFileRef.
>>
>> Eric, can you ask Natalie for the format of the MassTrapper nativeIDs?
>>
>> T2D can be handled like FID as well. I haven't a clue how to properly
>> handle a direct reference to the Oracle database, we can probably divert
>> that one until later. ;)
>>
>> -Matt
>>
>>
>> Fredrik Levander wrote:
>>     
>>> Hi Eric,
>>>
>>> Looks fine. One comment though: Could some of the fields be optional?
>>> 'Controller' doesn't always make sense for the Thermo files, and
>>> 'process' is maybe not so relevant for all Waters data (OK, if it hasn't
>>> been processed in MassLynx, process could be put to zero, but Ithink I
>>> would prefer to leave it out).
>>> Also, I would like to have a recommendation on what to write if some
>>> value for some reason not is known. This could be to leave out or to
>>> replace the number with a question mark. Worst option would be to put a
>>> value which is maybe not correct, in order to produce a 'valid' file.
>>>
>>> Thanks
>>>
>>> Fredrik
>>>
>>> Eric Deutsch skrev:
>>>
>>>       
>>>> Hi Matt, right you are. Sorry I neglected to follow up. I believe the
>>>> proposal we agreed upon on to use this:
>>>>
>>>> Thermo:
>>>> nativeID="controller=0 scan=1"
>>>> nativeID="controller=0 scan=1243"
>>>> nativeID="controller=1 scan=1"
>>>> (where controller 0 is probably always the mass spec?)
>>>>
>>>> Waters:
>>>> nativeID="function=1 process=0 scan=1"
>>>> nativeID="function=1 process=0 scan=2"
>>>> nativeID="function=2 process=0 scan=1"
>>>>
>>>> WIFF:
>>>> nativeID="Sample=0 period=1 cycle=1 experiment=2"
>>>> nativeID="Sample=0 period=1 cycle=1 experiment=3"
>>>> nativeID="Sample=0 period=1 cycle=2 experiment=2"
>>>> nativeID="Sample=0 period=1 cycle=2 experiment=3"
>>>>
>>>> Can anyone provide any more other vendor/format examples or further
>>>>         
>> comments
>>     
>>>> that should appear in the documentation of the above?
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Matthew Chambers [mailto:mat...@va...]
>>>>> Sent: Friday, October 10, 2008 12:57 PM
>>>>> To: Mass spectrometry standard development
>>>>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday
>>>>>
>>>>> Hi Eric, we were supposed to refine the nativeID format over the last
>>>>> two weeks. :)
>>>>> You had this in the last meeting minutes:
>>>>> + Eric will send out a summary of what formats should look like for
>>>>>           
>> all
>>     
>>>>> vendors and we'll refine
>>>>>
>>>>> Would you like me to put together the summary instead? I'd basically
>>>>> replace my format and examples with the key=value format and it'd be
>>>>>           
>> set
>>     
>>>>> unless you had some other ideas.
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>> Eric Deutsch wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is
>>>>>> Monday October 13 at 9am PDT:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=
>>     
>>>>> 2008&hour=17&min=0&sec=0&p1=136
>>>>>
>>>>>
>>>>>           
>> <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&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 and review all
>>>>>> the aspects related to mzML to start making progress again on the
>>>>>> highest priorities
>>>>>>
>>>>>> Topics:
>>>>>>
>>>>>> - nativeID format
>>>>>>
>>>>>> - mzML support information table
>>>>>>
>>>>>> - MIAPE example document
>>>>>>
>>>>>> - Other example documents
>>>>>>
>>>>>> - CV
>>>>>>
>>>>>> - CV template updates to vendors
>>>>>>
>>>>>> - Documentation
>>>>>>
>>>>>> - Web site
>>>>>>
>>>>>> - Validator
>>>>>>
>>>>>> - WIFF converter
>>>>>>
>>>>>> - Manuscript
>>>>>>
>>>>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>             
>> -------------------------------------------------------------------------
>> 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] Proposed nativeID format and examples

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

Hi everyone, here is another rev of the native ID proposal. Please
edit/comment:

The nativeID attribute is a required attribute for every spectrum and is
intended to provide a identifier to a spectrum in the name convention used
by the original (or previous) source of the data, so that it may be easily
mapped to previous forms of the data. Since the nativeID can take on
different formats for different vendors, then allowed formats must be
specified at the top of the file in the fileDescription section as a
cvParam. Such a description will appear like this:

<fileContent>
  <cvParam cvRef="MS" accession="MS:1000580" name="MSn spectrum"/>
  <cvParam cvRef="MS" accession="MS:1000127" name="centroid mass spectrum"/>
  <cvParam cvRef="MS" accession="MS:1000XXX" name="Thermo nativeID format"/>
</fileContent>

The formats to be used for different course formats is:

"Thermo nativeID format":
  nativeID="controller=0 scan=1"
  nativeID="controller=0 scan=1243"
  nativeID="controller=1 scan=1"
  (where controller 0 is probably always the mass spec?)

"Waters nativeID format":
  nativeID="function=1 process=0 scan=1"
  nativeID="function=1 process=0 scan=2"
  nativeID="function=2 process=0 scan=1"

"WIFF nativeID format":
  nativeID="Sample=0 period=1 cycle=1 experiment=2"
  nativeID="Sample=0 period=1 cycle=1 experiment=3"
  nativeID="Sample=0 period=1 cycle=2 experiment=2"
  nativeID="Sample=0 period=1 cycle=2 experiment=3"

"Bruker/Agilent YEP nativeID format":
  nativeID="scan=1"

"Bruker BAF nativeID format":
  nativeID="scan=1"

"Bruker FID nativeID format":
  nativeID=""
  (nativeID is required to be empty because each FID is a single spectrum,
so sourceFileRef is all that is needed)

"MGF nativeID format":
  nativeID="index=0"

"Scan number only nativeID format" (conversion from mzData or mzXML or dta
files):
  nativeID="scan=1"

"PKL files nativeID format" (conversion from a folder of PKL files)
  nativeID="" (each sourceFileRef is different)

"MassLynx nativeID format": ???
  nativeID=???

"ABI T2D nativeID format": ???
  nativeID=???

If there are multiple elements that compose a nativeID, all must be
specified.

[Issues:
- Don't we/shouldn't we have a rule that all nativeIDs within a file must be
unique? If we do, then having an empty nativeID is a problem. We have
nativeID in the index. But if the file is from PKL files, and there are no
nativeIDs, just source file differences, one couldn't capture this in the
index. Maybe not a problem.
]



> -----Original Message-----
> From: Matt Chambers [mailto:mat...@va...]
> Sent: Monday, October 13, 2008 6:32 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples
> 
> Hi Fredrik,
> 
> We discussed optional fields before as it is true that almost all Thermo
> files will use only 1 controller, and most of those will use only
> controller 0. But I don't think the small benefit in file size would be
> worth the implementation/comprehension cost of partially implicit ids.
> 
> You're the first person I've talked to that actually knows what the
> Waters process id is. :) If it is indeed used when the data has been
> MassLynx-processed, I think it's critical to keep in. If some components
> of the id are optional, then the term specifier in the CV needs to
> indicate which ones and what their default values are.
> 
> I do not understand the use case of "what to write if some value for
> some reason is not known." If the file is being converted from native
> data or from another mzML file, the values should always be known. We
> are putting the components in the id because they are necessary to link
> a spectrum to a native acquisition. If conversion is taking place from a
> less explicit format like MGF, mzData, or mzXML, then it is pretty much
> futile to try to reconstruct the native ids. Instead, we the nativeID
> should point to the less explicit format. For MGF, that should be a
> simple index except in specific cases where the native id can be parsed
> from the TITLE attribute. For mzData and mzXML it should be scan number
> except in specific cases where mzXML's scanOrigin element has been
> provided. So for nativeID I think it's all or nothing as far
> constructing a link to a vendor acquisition is concerned.
> 
> As I proposed before, we should provide nativeID formats for the generic
> text/xml formats.
> MGF: nativeID="index=0"
> mzData: nativeID="scan=1"
> mzXML: nativeID="scan=1"
> 
> I think we can get Bruker support in there too as I recently have done
> quite a bit of work with CompassXtract.
> Bruker/Agilent YEP: nativeID="scan=1"
> Bruker BAF: nativeID="scan=1"
> Bruker FID: nativeID="" // required to be empty because each FID is a
> single spectrum, so sourceFileRef is all that is needed
> 
> DTA is a bit of a tricky one because for Thermo derived data it can be
> used to get the scan numbers (assuming - quite safely I think - that
> controller 0 was used), but for other data the scan numbers would be
> wrong and/or misleading. For consistency I'll argue that DTA be like
> mzData and mzXML: nativeID="scan=1"
> 
> PKL can be handled like FID, an empty nativeID and a sourceFileRef.
> 
> Eric, can you ask Natalie for the format of the MassTrapper nativeIDs?
> 
> T2D can be handled like FID as well. I haven't a clue how to properly
> handle a direct reference to the Oracle database, we can probably divert
> that one until later. ;)
> 
> -Matt
> 
> 
> Fredrik Levander wrote:
> > Hi Eric,
> >
> > Looks fine. One comment though: Could some of the fields be optional?
> > 'Controller' doesn't always make sense for the Thermo files, and
> > 'process' is maybe not so relevant for all Waters data (OK, if it hasn't
> > been processed in MassLynx, process could be put to zero, but Ithink I
> > would prefer to leave it out).
> > Also, I would like to have a recommendation on what to write if some
> > value for some reason not is known. This could be to leave out or to
> > replace the number with a question mark. Worst option would be to put a
> > value which is maybe not correct, in order to produce a 'valid' file.
> >
> > Thanks
> >
> > Fredrik
> >
> > Eric Deutsch skrev:
> >
> >> Hi Matt, right you are. Sorry I neglected to follow up. I believe the
> >> proposal we agreed upon on to use this:
> >>
> >> Thermo:
> >> nativeID="controller=0 scan=1"
> >> nativeID="controller=0 scan=1243"
> >> nativeID="controller=1 scan=1"
> >> (where controller 0 is probably always the mass spec?)
> >>
> >> Waters:
> >> nativeID="function=1 process=0 scan=1"
> >> nativeID="function=1 process=0 scan=2"
> >> nativeID="function=2 process=0 scan=1"
> >>
> >> WIFF:
> >> nativeID="Sample=0 period=1 cycle=1 experiment=2"
> >> nativeID="Sample=0 period=1 cycle=1 experiment=3"
> >> nativeID="Sample=0 period=1 cycle=2 experiment=2"
> >> nativeID="Sample=0 period=1 cycle=2 experiment=3"
> >>
> >> Can anyone provide any more other vendor/format examples or further
> comments
> >> that should appear in the documentation of the above?
> >>
> >> Thanks,
> >> Eric
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Matthew Chambers [mailto:mat...@va...]
> >>> Sent: Friday, October 10, 2008 12:57 PM
> >>> To: Mass spectrometry standard development
> >>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday
> >>>
> >>> Hi Eric, we were supposed to refine the nativeID format over the last
> >>> two weeks. :)
> >>> You had this in the last meeting minutes:
> >>> + Eric will send out a summary of what formats should look like for
> all
> >>> vendors and we'll refine
> >>>
> >>> Would you like me to put together the summary instead? I'd basically
> >>> replace my format and examples with the key=value format and it'd be
> set
> >>> unless you had some other ideas.
> >>>
> >>> -Matt
> >>>
> >>>
> >>> Eric Deutsch wrote:
> >>>
> >>>
> >>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is
> >>>> Monday October 13 at 9am PDT:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=
> >>> 2008&hour=17&min=0&sec=0&p1=136
> >>>
> >>>
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&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 and review all
> >>>> the aspects related to mzML to start making progress again on the
> >>>> highest priorities
> >>>>
> >>>> Topics:
> >>>>
> >>>> - nativeID format
> >>>>
> >>>> - mzML support information table
> >>>>
> >>>> - MIAPE example document
> >>>>
> >>>> - Other example documents
> >>>>
> >>>> - CV
> >>>>
> >>>> - CV template updates to vendors
> >>>>
> >>>> - Documentation
> >>>>
> >>>> - Web site
> >>>>
> >>>> - Validator
> >>>>
> >>>> - WIFF converter
> >>>>
> >>>> - Manuscript
> >>>>
> >>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Eric
> >>>>
> 
> 
> -------------------------------------------------------------------------
> 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

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

Hi everyone, here are the notes from today's call:

 

Present: Eric, Lennart, Darren, Matt, Wilfred, Jim

 

- nativeID format

+ Matt has sent out some suggestions for kinds of source data

+ Eric will revise and send out a new thread for further discussion

+ Need to add a required cvParam in fileDescription setting the nativeID
format

- Are elements optional?

+ All elements of a nativeID must be present

- validator

+ There are two proposals:

+ 1) MS CV: whitelist, all other CV: blacklist (Matt)

+ 2) All CV black list, but if a term mandated anywhere, then nowhere else
(Eric)

+ Start a new thread discussing this topic

- unit ontology

+ in progress

- Reusing paramGroups in different context? (polymorphism) (Wilfred)

+ This would be very hard if not impossible to properly validate
semantically

+ A fully dereferenced paramGroup data (tree view) would yield a messy state

+ Conclusion is that this is probably not a good idea. Wilfred will try to
post a compelling example

+ One problem is that we have cvParams in both <spectrum> and
<spectrumDescription>, which is redundant

+ Would be better to move them all into <spectrumDescription>

+ Suggestion is to move the <spectrum> cvParams to <spectrumDescription>

+ Is this too great a change to make at this point?

+ Eric will post to the list a proposal to make this change and see if there
are complaints

- other CV issues

- next call? 9am Monday or 8am Tuesday?

+ Let's try the next call at Tuesday the Oct 28 at 8am so that Pierre-Alain
can make it.

+ The new time is fine for Jim, but awkward for Eric and Darren. We'll try
it.

 

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Monday, September 29, 2008 10:28 AM
To: 'Mass spectrometry standard development'
Cc: 'Natalie Tasman'; 'Eric Deutsch'
Subject: PSI-MSS WG call minutes

 

Hi everyone, here are the notes from today's call:

 

Present: Eric, Lennart, Darren, Matt, Randy, Jim

 

- nativeID format

+ Note that nativeID is required in the index

+ We seem in agreement that we should not try to scrimp, and so we should
make the format like "sample=1 period=2 cycle=123 experiment=4"

+ Eric will send out a summary of what formats should look like for all
vendors and we'll refine

- Imaging/separate data file issue

+ imzML contacted Randy and have an example file and are concerned about XML
verbosity and secondary data file

+ Randy will send out the contact information and we will try to continue
the discussion in the future

- Validator

+ Eric sent some big files to Lennart

+ Lennart wants to make some performance enhancements

+ Need to flesh out all the rules in the rules file

+ There is a problem with the inclusion of the unit CV

+ Matt says that the on-line validator is a blacklist-based validation

+ We had once talked about the validator should be whitelist base

+ Eric proposes that the validation goes like:

  = Any term that is controlled by the mapping file may ONLY appear in the
specified location

  = Any term that it NOT controlled anywhere by the mapping file may appear
anywhere with a mild warning

+ Need to also include the nativeID validation

+ Eric will try to find the old list of things the validator should check
and email to Lennart who will publish

- WIFF converter

+ ABI is working on a WIFF -> mzML converter. Matt and Eric are testing an
alpha version

- Next PSI meeting in Turku Apr 27-29

+ Describe proposed activities: CV, software promotion, validation

- Manuscript

+ Waiting for MS CV. Needs to be in OLS first. And need to resolve the unit
ontology.

+ Aim to submit by end of the year

- Unit Ontology

+ We need to add some terms for mass spec and send to maintainer

+ We need to change some funny characters in there that are causing our
software some problems

+ Maybe we can just fix the problem by converting unit.obo to proper
Unicode? Lennart will try in next two weeks.

- Next call

+ In two weeks: Oct 13 9am. Eric will consult with PAB about possibly 8am so
he can make it.

 

Not discussed:

- mzML support information table

- MIAPE example document

- Other example documents

- CV

- CV template updates to vendors

- Documentation

- Web site

 

 

 

 

 

 

 

  _____  

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: Wednesday, September 24, 2008 11:25 PM
To: 'Mass spectrometry standard development'
Cc: 'Eric Deutsch'; 'Natalie Tasman'
Subject: PSI-MSS WG call Monday

 

Hi everyone, after a bit of a hiatus, the PSI Mass Spectrometry Standards
Working Group will resume with calls this Monday *September* 29 at 9am PDT:

 http://www.timeanddate.com/worldclock/fixedtime.html?day=29
<http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=9&year=20
08&hour=17&min=0&sec=0&p1=136> &month=9&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 and review all the
aspects related to mzML to start making progress again on the highest
priorities

 

Topics:

- nativeID format

- mzML support information table

- MIAPE example document

- Other example documents

- CV

- CV template updates to vendors

- Documentation

- Web site

- Validator

- WIFF converter

- Manuscript

- Turku

- Next call

 

Thanks,

Eric

 

 

Re: [Psidev-ms-dev] Proposed nativeID format and examples

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

Hi Fredrik,

We discussed optional fields before as it is true that almost all Thermo 
files will use only 1 controller, and most of those will use only 
controller 0. But I don't think the small benefit in file size would be 
worth the implementation/comprehension cost of partially implicit ids.

You're the first person I've talked to that actually knows what the 
Waters process id is. :) If it is indeed used when the data has been 
MassLynx-processed, I think it's critical to keep in. If some components 
of the id are optional, then the term specifier in the CV needs to 
indicate which ones and what their default values are.

I do not understand the use case of "what to write if some value for 
some reason is not known." If the file is being converted from native 
data or from another mzML file, the values should always be known. We 
are putting the components in the id because they are necessary to link 
a spectrum to a native acquisition. If conversion is taking place from a 
less explicit format like MGF, mzData, or mzXML, then it is pretty much 
futile to try to reconstruct the native ids. Instead, we the nativeID 
should point to the less explicit format. For MGF, that should be a 
simple index except in specific cases where the native id can be parsed 
from the TITLE attribute. For mzData and mzXML it should be scan number 
except in specific cases where mzXML's scanOrigin element has been 
provided. So for nativeID I think it's all or nothing as far 
constructing a link to a vendor acquisition is concerned.

As I proposed before, we should provide nativeID formats for the generic 
text/xml formats.
MGF: nativeID="index=0"
mzData: nativeID="scan=1"
mzXML: nativeID="scan=1"

I think we can get Bruker support in there too as I recently have done 
quite a bit of work with CompassXtract.
Bruker/Agilent YEP: nativeID="scan=1"
Bruker BAF: nativeID="scan=1"
Bruker FID: nativeID="" // required to be empty because each FID is a 
single spectrum, so sourceFileRef is all that is needed

DTA is a bit of a tricky one because for Thermo derived data it can be 
used to get the scan numbers (assuming - quite safely I think - that 
controller 0 was used), but for other data the scan numbers would be 
wrong and/or misleading. For consistency I'll argue that DTA be like 
mzData and mzXML: nativeID="scan=1"

PKL can be handled like FID, an empty nativeID and a sourceFileRef.

Eric, can you ask Natalie for the format of the MassTrapper nativeIDs?

T2D can be handled like FID as well. I haven't a clue how to properly 
handle a direct reference to the Oracle database, we can probably divert 
that one until later. ;)

-Matt


Fredrik Levander wrote:
> Hi Eric,
>
> Looks fine. One comment though: Could some of the fields be optional? 
> 'Controller' doesn't always make sense for the Thermo files, and 
> 'process' is maybe not so relevant for all Waters data (OK, if it hasn't 
> been processed in MassLynx, process could be put to zero, but Ithink I 
> would prefer to leave it out).
> Also, I would like to have a recommendation on what to write if some 
> value for some reason not is known. This could be to leave out or to 
> replace the number with a question mark. Worst option would be to put a 
> value which is maybe not correct, in order to produce a 'valid' file.
>
> Thanks
>
> Fredrik
>
> Eric Deutsch skrev:
>   
>> Hi Matt, right you are. Sorry I neglected to follow up. I believe the
>> proposal we agreed upon on to use this:
>>
>> Thermo:
>> nativeID="controller=0 scan=1"
>> nativeID="controller=0 scan=1243"
>> nativeID="controller=1 scan=1"
>> (where controller 0 is probably always the mass spec?)
>>
>> Waters:
>> nativeID="function=1 process=0 scan=1"
>> nativeID="function=1 process=0 scan=2"
>> nativeID="function=2 process=0 scan=1"
>>
>> WIFF:
>> nativeID="Sample=0 period=1 cycle=1 experiment=2"
>> nativeID="Sample=0 period=1 cycle=1 experiment=3"
>> nativeID="Sample=0 period=1 cycle=2 experiment=2"
>> nativeID="Sample=0 period=1 cycle=2 experiment=3"
>>
>> Can anyone provide any more other vendor/format examples or further comments
>> that should appear in the documentation of the above?
>>
>> Thanks,
>> Eric
>>
>>
>>
>>
>>
>>   
>>     
>>> -----Original Message-----
>>> From: Matthew Chambers [mailto:mat...@va...]
>>> Sent: Friday, October 10, 2008 12:57 PM
>>> To: Mass spectrometry standard development
>>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday
>>>
>>> Hi Eric, we were supposed to refine the nativeID format over the last
>>> two weeks. :)
>>> You had this in the last meeting minutes:
>>> + Eric will send out a summary of what formats should look like for all
>>> vendors and we'll refine
>>>
>>> Would you like me to put together the summary instead? I'd basically
>>> replace my format and examples with the key=value format and it'd be set
>>> unless you had some other ideas.
>>>
>>> -Matt
>>>
>>>
>>> Eric Deutsch wrote:
>>>     
>>>       
>>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is
>>>> Monday October 13 at 9am PDT:
>>>>
>>>>
>>>>       
>>>>         
>>> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=
>>> 2008&hour=17&min=0&sec=0&p1=136
>>>     
>>> <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&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 and review all
>>>> the aspects related to mzML to start making progress again on the
>>>> highest priorities
>>>>
>>>> Topics:
>>>>
>>>> - nativeID format
>>>>
>>>> - mzML support information table
>>>>
>>>> - MIAPE example document
>>>>
>>>> - Other example documents
>>>>
>>>> - CV
>>>>
>>>> - CV template updates to vendors
>>>>
>>>> - Documentation
>>>>
>>>> - Web site
>>>>
>>>> - Validator
>>>>
>>>> - WIFF converter
>>>>
>>>> - Manuscript
>>>>
>>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join?
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>