psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] MzML 0.99.11 schema update

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

Hi all,

In the absence of further feedback about the acquisition attribute vs. 
element issue, I went ahead and did it the way we talked about in the 
conference call and it will require semantic validation because all the 
attributes are optional in the schema. I made the other changes as well. 
The new version is in CVS.

-Matt

[Psidev-ms-dev] FW: PSI-MS CV updated

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

FYI

 

________________________________

From: Eric Deutsch 
Sent: Wednesday, May 07, 2008 12:46 AM
To: psi...@li...
Cc: Eric Deutsch
Subject: PSI-MS CV updated

 

Hi everyone, I have just committed some changes to the psi-ms.obo file
in CVS, taking care of:

- Adding some terms from Jim S

- Adding new chromatogram tree for this new element

- A little bit of cleaning

- Took care of all open items in the term tracker, which will now be
obsoleted

- I poked around purgatory for a while and only found one term: "total
ion chromatogram ?" that I wanted to resurrect. I changed the name to
"total ion current chromatogram". There are maybe a few other nice terms
in there, but most of them aren't useful. Do we have clearance to
destroy the ones that are uncontroversially useless like "461:
additional description"? Some will definitely need some discussion if we
feel up to it.

 

- I would like to hand over the bear to whoever will edit it next. I
suggest:

+ Luisa delete/destroy/deprecate the units in common with the UO to
force us to start using the UO

+ Darren to start adding in the datatype and needs_units fields for
appropriate terms

 

Here's the diff for you to look over:

 

< def: "Three-character symbol m/z is used to denote the dimensionless
quantity formed by dividing the mass of an ion in unified atomic mass
units by its charge number (regardless of sign). The symbol is written
in italicized lower case letters with no spaces. Note 1: The term
mass-to-charge-ratio is deprecated. Mass-to-charge-ratio has been used
for the abscissa of a mass spectrum, although the quantity measured is
not the quotient of the ion's mass to its electric charge. The
three-character symbol m/z is recommended for the dimensionless quantity
that is the independent variable in a mass spectrum Note 2: The proposed
unit thomson (Th) is deprecated." [PSI:MS]

< synonym: "Mass To Charge Ratio" EXACT []

< synonym: "thomson" RELATED []

---

> def: "Three-character symbol m/z is used to denote the quantity formed
by dividing the mass of an ion in unified atomic mass units by its
charge number (regardless of sign). The symbol is written in italicized
lower case letters with no spaces. Note 1: The term mass-to-charge-ratio
is deprecated. Mass-to-charge ratio has been used for the abscissa of a
mass spectrum, although the quantity measured is not the quotient of the
ion's mass to its electric charge. The three-character symbol m/z is
recommended for the quantity that is the independent variable in a mass
spectrum Note 2: The proposed unit Thomson (Th) is deprecated." [PSI:MS]

> synonym: "Mass-to-charge ratio" EXACT []

> synonym: "Th" EXACT []

> synonym: "Thomson" EXACT []

257a259

> is_a: MS:1000460 ! unit

1176c1178

< name: q-tof micro

---

> name: Q-Tof micro

1182c1184

< name: q-tof ultima

---

> name: Q-Tof ultima

1329c1331

< name: dalton

---

> name: Dalton

1475c1477

< name: total ion chromatogram ?

---

> name: total ion current chromatogram

1477c1479,1481

< relationship: part_of MS:1000461 ! additional description

---

> synonym: "TIC chromatogram" EXACT []

> is_a: MS:1000524 ! data file content

> is_a: MS:1000626 ! chromatogram type

3223c3227

< def: "Binary Data Type." [PSI:MS]

---

> def: "A data array of values." [PSI:MS]

3224a3229

> relationship: part_of MS:1000625 ! chromatogram

3229c3234

< def: "M/Z Array." [PSI:MS]

---

> def: "A data array of mass divided by charge values." [PSI:MS]

3235c3240

< def: "Intensity Array." [PSI:MS]

---

> def: "A data array of intensity values." [PSI:MS]

3241c3246

< def: "Charge Array." [PSI:MS]

---

> def: "A data array of charge values." [PSI:MS]

3247c3252

< def: "Singal to Noise Array." [PSI:MS]

---

> def: "A data array of signal-to-noise values." [PSI:MS]

3254a3260

> relationship: part_of MS:1000625 ! chromatogram

3404c3410

< def: "Data processing attribute used to describe the type of data
processing performed on the data file." [PSI:MS]

---

> def: "Type of data processing performed on the data file." [PSI:MS]

3581a3588

> relationship: part_of MS:1000625 ! chromatogram

3720a3728

> synonym: "thresholding" EXACT []

3726c3734

< def: "Array of increasing time points." [PSI:MS]

---

> def: "A data array of relative time offset values from a reference
time." [PSI:MS]

3860a3869,3971

> [Term]

> id: MS:1000617

> name: wavelength array

> def: "A data array of electromagnetic radiation wavelength values."
[PSI:MS]

> is_a: MS:1000513 ! binary data array

> 

> [Term]

> id: MS:1000618

> name: highest wavelength value

> def: "Highest wavelength value observed in the uv/vis spectum."
[PSI:MS]

> is_a: MS:1000499 ! spectrum attribute

> 

> [Term]

> id: MS:1000619

> name: lowest wavelength value

> def: "Lowest wavelength value observed in the uv/vis spectrum."
[PSI:MS]

> is_a: MS:1000499 ! spectrum attribute

> 

> [Term]

> id: MS:1000620

> name: PDA spectrum

> def: "Spectrum generated from a photodiode array detector
(ultraviolet/visible spectrum)." [PSI:MS]

> is_a: MS:1000524 ! data file content

> is_a: MS:1000559 ! spectrum type

> 

> [Term]

> id: MS:1000621

> name: photodiode array detector

> def: "An array detector used to record spectra in the ultraviolet and
visable region of light." [PSI:MS]

> synonym: "PDA" EXACT []

> is_a: MS:1000026 ! detector type

> 

> [Term]

> id: MS:1000622

> name: Surveyor PDA

> def: "Surveyor PDA." [PSI:MS]

> is_a: MS:1000494 ! Thermo Scientific instrument model

> 

> [Term]

> id: MS:1000623

> name: Accela PDA

> def: "Accela PDA." [PSI:MS]

> is_a: MS:1000494 ! Thermo Scientific instrument model

> 

> [Term]

> id: MS:1000624

> name: inductive detector

> def: "Inductive detector." [PSI:MS]

> synonym: "image current detector" EXACT []

> is_a: MS:1000026 ! detector type

> 

> [Term]

> id: MS:1000625

> name: chromatogram

> def: "The representation of detector response versus time." [PSI:MS]

> relationship: part_of MS:0000000 ! Proteomics Standards Initiative
Mass Spectrometry Ontology

> 

> [Term]

> id: MS:1000626

> name: chromatogram type

> def: "Broad category or type of a chromatogram." [PSI:MS]

> relationship: part_of MS:1000625 ! chromatogram

> 

> [Term]

> id: MS:1000627

> name: selected ion current chromatogram

> def: "Chromatogram created by creating an array of the measurements of
a specific single ion current at each time point." [PSI:MS]

> synonym: "SIC chromatogram" EXACT []

> is_a: MS:1000524 ! data file content

> is_a: MS:1000559 ! spectrum type

> is_a: MS:1000626 ! chromatogram type

> 

> [Term]

> id: MS:1000628

> name: basepeak chromatogram

> def: "Chromatogram created by creating an array of the most intense
peaks at each time point." [PSI:MS]

> is_a: MS:1000524 ! data file content

> is_a: MS:1000626 ! chromatogram type

> 

> [Term]

> id: MS:1000629

> name: low intensity threshold

> def: "Threshold below which some action is taken." [PSI:MS]

> is_a: MS:1000630 ! data processing parameter

> 

> [Term]

> id: MS:1000630

> name: data processing parameter

> def: "Data processing parameter used in the data processing performed
on the data file." [PSI:MS]

> is_a: MS:1000452 ! data transformation

> 

> [Term]

> id: MS:1000631

> name: high intensity threshold

> def: "Threshold above which some action is taken." [PSI:MS]

> is_a: MS:1000630 ! data processing parameter

> 

> [Term]

> id: MS:1000632

> name: Q-Tof Premier

> def: "Waters Q-Tof Premier MS." [PSI:MS]

> is_a: MS:1000126 ! Waters instrument model

> 

[Psidev-ms-dev] MS Vendor contacts?

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

Hi everyone, I have sent requests to help update our CV to several
vendors, but I don't have contact information for these vendors:

 

Dionex

Hitachi

Shimadzu

Varian

 

Can anyone out there help me contact an appropriate person to help
update the instrument and software terms for these vendors?

 

Thank you!

Eric

 

 

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

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

 

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

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

Hi all,

It looks like I was wrong about the "choice" xsd concept. It only works 
on elements, not attributes. If we want to do this with schematic 
validation, we could make two acquisition types:
<acquisition spectrumRef="..." />
<externalAcquisition sourceFileRef="..." spectrumRef="..." 
nativeID="(optional)" />

Or we can keep the current suggestion and leave it to the semantic 
validator to enforce the right attributes:
spectrumRef (infer reference as current file and spectrumRef is IDREF 
pointing to an existing spectrum's id)
sourceFileRef + externalNativeID (original file is native)
sourceFileRef + externalSpectrumID (original file is mzML)

-Matt


Eric Deutsch wrote:
>
> Hi everyone, here are the minutes for the telecon. Please see action 
> items for you. Anyone not on the call willing to help out is welcome.
>
> Present: Darren, Matt, Eric, Jim, Pierre-Alain
>
> Thank you to Juan Antonio for setting up the call.
>
> Agenda:
>
> - What is the purpose of <mzML> id and accession attributes?
>
> + Make the id= attribute optional in schema
>
> + Recommend in the documentation that you use LSID or local identifiers
>
> + Make all sample instance documents use a psidev LSID
>
> + Leave accession= optional as is, perhaps with better documentation
>
> - Make <run> instrumentConfigurationRef optional or remove it:
>
> - if remove, then this attribute can be required in <scan>
>
> - if optional, semval must insure that it is provide either in <run> 
> or <scan>
>
> + OR consensus opinion: rename <run> instrumentConfigurationRef to 
> defaultInstrumentConfigurationRef and keep it required
>
> + Document the intrumentConfiguration a bit better. Applies to LTQ-FT 
> but not LTQ, for example. For different modes, use ParamGroups
>
> + Discussion of issue of how to use ParamGroups without having to do 
> two passes through the file.
>
> - Issue of exactly how other spectra are referenced in <acquisition>
>
> + We agree to move forward with Matt suggestion:
>
> spectrumRef (infer reference as current file and spectrumRef is IDREF
>
> pointing to an existing spectrum's id)
>
> sourceFileRef + externalNativeID (original file is native)
>
> sourceFileRef + externalSpectrumID (original file is mzML)
>
> For example external mzXML files, the externalNativeID would refer to 
> mzXML scanNumber
>
> In fact, anything that’s not mzML would have externNativeID
>
> Matt says that XML schema can enforce these various options
>
> - MIAPE spreadsheet?
>
> + Pierre-Alain has spreadsheet. Darren added some comments trying to 
> implement it
>
> + Rename Darren’s tiny2 to tiny5 or some other name since “tiny2” is 
> used by another document
>
> + Get miape-ms.pwiz.mzML posted
>
> + Pierre-Alain will continue to work on the spreadsheet
>
> + Before next call, send out or post miape-ms.pwiz.mzML and 
> spreadsheet of issues to discuss
>
> - CV?
>
> + Randy has pink teddy bear, but haven’t heard from him
>
> + Eric will take it and work on some changes to the CV
>
> + Eric will create the CV spreadsheets and start sending to vendors
>
> + Some contacts: Bruker :Herbert Thiele? Waters: Ronan O’Malley?
>
> - documentation?
>
> + latest is posted without figures
>
> - schema?
>
> + Eric will add Darren & Matt as a developers (dkessner) (chambm)
>
> + Darren will update 0.99.10 to 0.99.11 with changes above
>
> + Matt can help with multiple accession configs in <acquisition>
>
> - website
>
> + Eric post 0.99.10 schemas
>
> + Darren verify that tiny.pwiz encodes all ideas of tiny1 and then 
> post as a single tiny1
>
> - example files
>
> + Jim has an example that he will send out
>
> + Jim will send out examples of the nativeIDs for Thermo
>
> ------------------------------------------------------------------------
>
> *From:* Eric Deutsch
> *Sent:* Monday, May 05, 2008 12:12 AM
> *To:* 'Mass spectrometry standard development'; Juan Antonio Vizcaíno 
> González
> *Cc:* Eric Deutsch
> *Subject:* RE: PSI-MSS WG call Tuesday
>
> Hi everyone, as previously mentioned, the PSI Mass Spectrometry 
> Standards Working Group call is Tuesday May 6 at 9am PDT:
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=5&year=2008&hour=17&min=0&sec=0&p1=136 
> <http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=5&year=2008&hour=17&min=0&sec=0&p1=136>
>
> + Germany: 08001012079
>
> + Switzerland: 0800000860
>
> + UK: 08081095644
>
> + USA: 1-866-314-3683
>
> + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>
> The agenda will be to review and discuss what remains to be done to 
> finish up mzML, including the latest release and some recent issues 
> discovered while making examples.
>
> Thanks,
>
> Eric
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

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

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

Hi everyone, here are the minutes for the telecon. Please see action items for you. Anyone not on the call willing to help out is welcome.

 

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

 

Thank you to Juan Antonio for setting up the call.

 

Agenda:

 

- What is the purpose of <mzML> id and accession attributes?

+ Make the id= attribute optional in schema

+ Recommend in the documentation that you use LSID or local identifiers

+ Make all sample instance documents use a psidev LSID

+ Leave accession= optional as is, perhaps with better documentation

 

- Make <run> instrumentConfigurationRef optional or remove it:

  - if remove, then this attribute can be required in <scan>

  - if optional, semval must insure that it is provide either in <run> or <scan>

  + OR consensus opinion: rename <run> instrumentConfigurationRef to defaultInstrumentConfigurationRef and keep it required

  + Document the intrumentConfiguration a bit better. Applies to LTQ-FT but not LTQ, for example. For different modes, use ParamGroups

 

+ Discussion of issue of how to use ParamGroups without having to do two passes through the file.

 

- Issue of exactly how other spectra are referenced in <acquisition>

+ We agree to move forward with Matt suggestion:

  spectrumRef (infer reference as current file and spectrumRef is IDREF 

  pointing to an existing spectrum's id)

  sourceFileRef + externalNativeID (original file is native)

  sourceFileRef + externalSpectrumID (original file is mzML)

  For example external mzXML files, the externalNativeID would refer to mzXML scanNumber

  In fact, anything that's not mzML would have externNativeID

  Matt says that XML schema can enforce these various options

 

- MIAPE spreadsheet?

+ Pierre-Alain has spreadsheet. Darren added some comments trying to implement it

+ Rename Darren's tiny2 to tiny5 or some other name since "tiny2" is used by another document

+ Get miape-ms.pwiz.mzML posted

+ Pierre-Alain will continue to work on the spreadsheet

+ Before next call, send out or post miape-ms.pwiz.mzML and spreadsheet of issues to discuss

 

- CV?

+ Randy has pink teddy bear, but haven't heard from him

+ Eric will take it and work on some changes to the CV

+ Eric will create the CV spreadsheets and start sending to vendors

+ Some contacts: Bruker :Herbert Thiele?  Waters: Ronan O'Malley?

 

- documentation?

+ latest is posted without figures

 

- schema?

+ Eric will add Darren & Matt as a developers (dkessner) (chambm)

+ Darren will update 0.99.10 to 0.99.11 with changes above

+ Matt can help with multiple accession configs in <acquisition>

 

- website

+ Eric post 0.99.10 schemas

+ Darren verify that tiny.pwiz encodes all ideas of tiny1 and then post as a single tiny1

 

- example files

+ Jim has an example that he will send out

+ Jim will send out examples of the nativeIDs for Thermo

 

 

 

 

________________________________

From: Eric Deutsch 
Sent: Monday, May 05, 2008 12:12 AM
To: 'Mass spectrometry standard development'; Juan Antonio Vizcaíno González
Cc: Eric Deutsch
Subject: RE: PSI-MSS WG call Tuesday

 

Hi everyone, as previously mentioned, the PSI Mass Spectrometry Standards Working Group call is Tuesday May 6 at 9am PDT:

 

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

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to review and discuss what remains to be done to finish up mzML, including the latest release and some recent issues discovered while making examples.

 

Thanks,

Eric

 

[Psidev-ms-dev] <mzML> attributes

[Darren K. <Dar...@cs...>]

Hi all,

What is the intended purpose for the 'id' and 'accession' attributes  
in the top <mzML> element?  I assume 'version' is the mzML version.


Darren

[Psidev-ms-dev] <run instrumentConfigRef="?">

[Darren K. <Dar...@cs...>]

Hi all,

Today I was working on implementing multiple <instrumentConfiguration>  
elements for converting LTQ-FT RAW files.  The converted files have  
two <instrumentConfiguration> elements, one for each mass analyzer:   
FT and ion trap.  Individual <scan> elements have their  
instrumentConfigurationRef attribute set according to the mass  
analyzer used in that scan.

I found that the <run> element currently requires an  
instrumentConfigurationRef attribute, which doesn't make sense for  
this situation.  I propose we remove the attribute (or at least make  
it optional).


Darren

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

Hi Matt, good point about mzXML referencing. The easy rule would be to  
have all non-mzML referencing as externalNativeID, but if I get it  
correctly mzXML both have scan num and native id nowadays (correct me  
if I am wrong) which could make this confusing? And I guess we'd like  
to reference the scan num, so maybe mzXML and mzData files (in  
addition to mzML files) should be referenced by externalSpectrumID,  
and all other files using externalNativeID?

I think the first three classes that you suggest should be enough. If  
we don't know what the source file is, it seems unlikely that we'd  
like to reference a specific scan in it.

I am not sure whether there is a need for a possibility to add a  
reference to the nativeID in addition to a spectrumRef (IDREF type).  
It could be easily retrieved by looking up the spectrum in the same  
file, so it may be unneccesary. I don't think this is the kind of  
information that needs very fast lookup.

Fredrik

2 maj 2008 kl. 23.40 skrev Matthew Chambers:

> Is a native file one that an actual instrument wrote or is it anything
> that isn't mzML? I.e. do we use externalNativeID to refer to a scan in
> an mzXML file, or do we use externalSpectrumID? Also, I'm willing to
> forfeit the possibility of referencing a spectrum within the current
> file that is not actually there.
>
> So I see three possibilities, adding one to Darren's list:
> spectrumRef (infer reference as current file and spectrumRef is IDREF
> pointing to an existing spectrum's id)
> sourceFileRef + externalNativeID (original file is native)
> sourceFileRef + externalSpectrumID (original file is mzML)
>
> A fourth possibility may be useful, but not necessary:
> nativeSpectrumRef (infer reference as current file and  
> nativeSpectrumRef
> is string pointing to an existing spectrum's nativeID)
>
> The three main cases can be schematically validated. Semantic  
> validation
> would not be necessary to ensure that we don't get:
> sourceFileRef + spectrumRef or
> externalNativeID or
> externalSpectrumID or
> externalNativeID + externalSpectrumID or
> spectrumRef + externalSpectrumID, etc...
>
> -Matt
>
>
> Darren Kessner wrote:
>> Hi Eric,
>>
>> Thanks for the nice summary.
>>
>> I agree with Fredrik's proposal to add:
>>     sourceFileRef + externalNativeID
>> since the sourceFileRef may refer to a native data file, so
>> externalSpectrumID won't make sense.
>>
>> I believe Matt's case is covered by the two possibilities:
>>     sourceFileRef + externalNativeID       (original file is native)
>>     sourceFileRef + externalSpectrumID   (original file is mzML)
>>
>>
>> Darren
>>
>>
>> On May 2, 2008, at 12:28 PM, Fredrik Levander wrote:
>>
>>
>>> Hi Eric and others,
>>>
>>> All nice thoughts and proposals. I would also add an example 4 which
>>> is:
>>>
>>> Example 4: (the current spectrum is a sum of two scans which had
>>> nativeIDs func1scan19 and func1scan20, the source file is found in
>>> the source file list)
>>>
>>> <acquisitionList count="2">
>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>> <acquisition nativeID="func1scan19" sourceFileRef="rawFile1" />
>>> <acquisition nativeID="func1scan20" sourceFileRef="rawFile1" />
>>> </acquisitionList>
>>>
>>> It would all be covered by the following xsd:
>>>
>>>   <xs:complexType name="AcquisitionType">
>>>       <xs:annotation>
>>>           <xs:documentation>Scan or acquisition from original file
>>> used to
>>> create this peak list.  A spectrumRef or an externalSpectrumID or
>>> nativeID
>>> plus sourceFileRef should be given .</xs:documentation>
>>>       </xs:annotation>
>>>       <xs:complexContent>
>>>           <xs:extension base="dx:ParamGroupType">
>>>               <xs:attribute name="number" type="xs:int"
>>> use="required">
>>>                   <xs:annotation>
>>>                       <xs:documentation>A number for this
>>> acquisition.</
>>> xs:documentation>
>>>                   </xs:annotation>
>>>               </xs:attribute>
>>>               <xs:attribute name="spectrumRef" type="xs:IDREF"
>>> use="optional">
>>>                   <xs:annotation>
>>>                       <xs:documentation>This attribute must  
>>> reference
>>> the 'id'
>>> attribute of the appropriate spectrum. </xs:documentation>
>>>                   </xs:annotation>
>>>               </xs:attribute>
>>>               <xs:attribute name="nativeID" type="xs:string"
>>> use="optional">
>>>                   <xs:annotation>
>>>                       <xs:documentation>This attribute references  
>>> the
>>> native
>>> spectrum identifier in a raw file. </xs:documentation>
>>>                   </xs:annotation>
>>>               </xs:attribute>
>>>              <xs:attribute name="externalSpectrumID"  
>>> type="xs:string"
>>> use="optional">
>>>                   <xs:annotation>
>>>                       <xs:documentation>This attribute must  
>>> reference
>>> the 'id'
>>> attribute of the appropriate spectrum in an external mzML
>>> file. </xs:documentation>
>>>                   </xs:annotation>
>>>               </xs:attribute>
>>>               <xs:attribute name="sourceFileRef" type="xs:IDREF"
>>> use="optional">
>>>                   <xs:annotation>
>>>                       <xs:documentation>This attribute must  
>>> reference
>>> the 'id'
>>> attribute of the appropriate sourceFile.
>>>                       </xs:documentation>
>>>                   </xs:annotation>
>>>               </xs:attribute>
>>>           </xs:extension>
>>>       </xs:complexContent>
>>>   </xs:complexType>
>>>
>>> The semantic validation would be to check that at least one of the
>>> attributes spectrumRef, externalSpectrumID (+sourceFileRef) or
>>> nativeID
>>> is given.
>>>
>>> Or maybe there is even more to consider?
>>>
>>> Fredrik
>>>
>>>
>>> Eric Deutsch skrev:
>>>
>>>> Hi Fredrik and everyone, thank you for thinking about these last  
>>>> few
>>>> problems. It seems that there are several different ways in which  
>>>> one
>>>> might want to reference the source scans for a summed scan. Based  
>>>> on
>>>> what's been said so far, here are my thoughts and proposal. What do
>>>> you
>>>> think?
>>>>
>>>> Currently for acquisitionList we have (in XML/XSD hybrid):
>>>> ---------------
>>>> <acquisitionList count="2">
>>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of  
>>>> spectra"/>
>>>> <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>>>> spectrumRef="xs:IDREF">
>>>>   <cvParam cvLabel="MS" (optional child of scan attribute)/>
>>>> </acquisition>
>>>> <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>>>> spectrumRef="xs:IDREF">
>>>> </acquisitionList>
>>>> ---------------
>>>>
>>>> Frederik suggests spectrumRef -> xs:string
>>>> externalSpectrumID="xs:string"
>>>>
>>>> This brought up the question of how would sourceFileRef reference
>>>> itself
>>>> if everything were in the same file?
>>>>
>>>> Rune points out that we want nativeID references, like for Waters:
>>>> function1scan2, func1scan2, 1.2 or ....
>>>>
>>>> Darren suggests:
>>>> externalSpectrumID="URI"
>>>> externalNativeID="xs:string"
>>>>
>>>> -------------------------------------------
>>>>
>>>> So, I suggest something like this (in XML/XSD hybrid):
>>>>
>>>> <acquisitionList count="2">
>>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of  
>>>> spectra"/>
>>>> (three possible options:)
>>>> <acquisition spectrumRef="xs:IDREF">
>>>> <acquisition nativeID="xs:string">
>>>> <acquisition sourceFileRef="xs:IDREF"
>>>> externalSpectrumID="xs:string">
>>>> <acquisition
>>>> </acquisitionList>
>>>>
>>>> ---
>>>>
>>>> Example 1: (the current spectrum is a sum of two scans which are  
>>>> also
>>>> present in the current file as ids S57 and S58.)
>>>>
>>>> <acquisitionList count="2">
>>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of  
>>>> spectra"/>
>>>> <acquisition spectrumRef="S57">
>>>> <acquisition spectrumRef="S58">
>>>> </acquisitionList>
>>>>
>>>> ---
>>>>
>>>> Example 2: (the current spectrum is a sum of two scans which had
>>>> nativeIDs func1scan19 and func1scan20, the exact location of which
>>>> are not specifiable)
>>>>
>>>> <acquisitionList count="2">
>>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of  
>>>> spectra"/>
>>>> <acquisition nativeID="func1scan19">
>>>> <acquisition nativeID="func1scan20">
>>>> </acquisitionList>
>>>>
>>>> ---
>>>>
>>>> Example 3: (the current spectrum is a sum of two scans which are
>>>> explicitly referenced externally by a specific file previously
>>>> defined in the current document and with IDs in that other file)
>>>>
>>>> <acquisitionList count="2">
>>>> <cvParam cvLabel="MS" accession="MS:1000571" name="sum of  
>>>> spectra"/>
>>>> <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57">
>>>> <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58">
>>>> </acquisitionList>
>>>>
>>>> ---
>>>>
>>>> Also okay is 1+2:
>>>>
>>>> <acquisition spectrumRef="S57" nativeID="func1scan19">
>>>> <acquisition spectrumRef="S58" nativeID="func1scan20">
>>>>
>>>> ---
>>>>
>>>> Also okay is 2+3:
>>>>
>>>> <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01"
>>>> externalSpectrumID="S57">
>>>> <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01"
>>>> externalSpectrumID="S58">
>>>>
>>>> ---
>>>>
>>>> Thus, all four possible attributes are optional, and we would  
>>>> rely on
>>>> the sematic validator to enforce:
>>>>
>>>>  spectrumRef alone
>>>> OR nativeID alone
>>>> OR spectrumRef AND nativeID
>>>> OR sourceFileRef AND externalSpectrumID
>>>> OR sourceFileRef AND externalSpectrumID AND nativeID
>>>>
>>>> What do you think? A little unpleasant to have several different
>>>> options, but I don't see how we could practically exclude any of  
>>>> the
>>>> options.
>>>>
>>>>
>>>> As a related side note, Matt also asks if we can handle the case
>>>> where
>>>> MS1 scans have been stripped out of a file, but the the MS2 scans
>>>> still
>>>> need to say something useful about their precursor scan (IDREF not
>>>> possible).
>>>>
>>>> I have not checked this, but we should spend some time thinking  
>>>> about
>>>> that once we have solved this problem.
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: psi...@li...
>>>>>
>>>>>
>>>> [mailto:psidev-ms-dev-
>>>>
>>>>
>>>>> bo...@li...] On Behalf Of Darren Kessner
>>>>> Sent: Friday, May 02, 2008 9:13 AM
>>>>> To: Mass spectrometry standard development
>>>>> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in
>>>>> mzML
>>>>> 0.99.10
>>>>>
>>>>> I think it's a bad idea to have a spectrumRef to a spectrum that
>>>>> isn't
>>>>> in the file.  We should be consistent in the use of internal
>>>>> references, all of which use IDREF so that dangling references can
>>>>> be
>>>>> caught during XML validation.
>>>>>
>>>>> External references, including those to spectra that have been
>>>>> removed
>>>>> for space reasons, should be indicated specifically (e.g. with
>>>>> externalSpectrumID or externalNativeID) so that the reader  
>>>>> (human or
>>>>> software) knows that they'll have to do some extra work to find  
>>>>> the
>>>>> referent.
>>>>>
>>>>>
>>>>> Darren
>>>>>
>>>>>
>>>>>
>>>>> On May 2, 2008, at 6:17 AM, Matt Chambers wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Perhaps we should follow the same logic of the spectrum element
>>>>>> itself,
>>>>>> where id is required but nativeID is optional. Thus, id is  
>>>>>> required
>>>>>> for
>>>>>> a spectrum reference and a reference to the nativeID would be
>>>>>>
>>>>>>
>>>> optional
>>>>
>>>>
>>>>>> (but recommended!). We can't use the same attribute to point to
>>>>>>
>>>>>>
>>>> either
>>>>
>>>>
>>>>>> id or nativeID because then it won't be known which is being
>>>>>>
>>>>>>
>>>> referred
>>>>
>>>>
>>>>>> to, unless I'm missing something in Fredrik's proposal.
>>>>>>
>>>>>> To deal with IDs that aren't in the file, I agree with Fredrik.  
>>>>>> Any
>>>>>> time
>>>>>> we have a reference that can be to a non-existent or external
>>>>>>
>>>>>>
>>>> element,
>>>>
>>>>
>>>>>> we can't use IDREF. We either need to switch to xlink (in which
>>>>>> case
>>>>>> IDREF would probably still be ok) or fall back to string.  
>>>>>> However,
>>>>>> since
>>>>>> I think that acquisitions should be able to reference spectra in
>>>>>> the
>>>>>> current file, we shouldn't change it to externalSpectrumID. We
>>>>>>
>>>>>>
>>>> should
>>>>
>>>>
>>>>>> just document that all spectrumRef and spectrumNativeID(Ref?)
>>>>>> attributes
>>>>>> may refer to a spectrum in the current file or in another one,  
>>>>>> and
>>>>>>
>>>>>>
>>>> in
>>>>
>>>>
>>>>>> the former case the spectrum might not actually be there (i.e.  
>>>>>> MSn
>>>>>> spectra referencing precursor spectra that have been stripped out
>>>>>> to
>>>>>> conserve space).
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>> Rune Schjellerup Philosof wrote:
>>>>>>
>>>>>>
>>>>>>> I think the format by which external file elements are reference
>>>>>>> should
>>>>>>> be defined.
>>>>>>> For instance, a reference to a Waters raw file, should that be
>>>>>>> function1scan2, func1scan2, 1.2 or ....
>>>>>>>
>>>>>>> --
>>>>>>> Rune
>>>>>>>
>>>>>>> Fredrik Levander wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> There is an issue with the current mzML schema (0.99.10) when  
>>>>>>>> it
>>>>>>>> comes
>>>>>>>> to referencing the origin of acquisitions in an  
>>>>>>>> acquistionList of
>>>>>>>> summed spectra. In most cases the referenced spectra will not  
>>>>>>>> be
>>>>>>>>
>>>>>>>>
>>>> in
>>>>
>>>>
>>>>>>>> the current mzML file, and thus the spectrumRef cannot be of  
>>>>>>>> the
>>>>>>>> type
>>>>>>>> xs:IDREF, but should be xs:string to also cover references to
>>>>>>>> spectrum
>>>>>>>> IDs in other mzML files, or native IDs in vendor files.
>>>>>>>>
>>>>>>>> The following would cover both internal and external spectrum
>>>>>>>> referencing:
>>>>>>>>
>>>>>>>>
>>>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>>>> 		<xs:annotation>
>>>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>>>
>>>>>>>>
>>>> original raw
>>>>
>>>>
>>>>> file used
>>>>>
>>>>>
>>>>>>>> to create this peak list, as specified in sourceFile.</
>>>>>>>> xs:documentation>
>>>>>>>> 		</xs:annotation>
>>>>>>>> 		<xs:complexContent>
>>>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>>>> 				<xs:attribute name="number"
>>>>>>>>
>>>>>>>>
>>>> type="xs:int"
>>>>
>>>>
>>>>> use="required">
>>>>>
>>>>>
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>A
>>>>>>>>
>>>>>>>>
>>>> number for this
>>>>
>>>>
>>>>> acquisition.</
>>>>>
>>>>>
>>>>>>>> xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>>>
>>>>>>>>
>>>> type="xs:string"
>>>>
>>>>
>>>>>>>> use="required">
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>This
>>>>>>>>
>>>>>>>>
>>>> attribute must
>>>>
>>>>
>>>>> reference the 'id'
>>>>>
>>>>>
>>>>>>>> attribute of the appropriate spectrum if found within an mzML
>>>>>>>> file, or
>>>>>>>> the native spectrum identifier in a raw file in another format.
>>>>>>>> </
>>>>>>>> xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 				<xs:attribute name="sourceFileRef"
>>>>>>>>
>>>>>>>>
>>>> type="xs:IDREF"
>>>>
>>>>
>>>>>>>> use="required">
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>This
>>>>>>>>
>>>>>>>>
>>>> attribute must
>>>>
>>>>
>>>>> reference the 'id'
>>>>>
>>>>>
>>>>>>>> attribute of the appropriate sourceFile. It can also refer to  
>>>>>>>> the
>>>>>>>> present mzML file.</xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 			</xs:extension>
>>>>>>>> 		</xs:complexContent>
>>>>>>>> 	</xs:complexType>
>>>>>>>>
>>>>>>>> However, I am not sure if there are any use cases when both the
>>>>>>>> summed
>>>>>>>> spectrum and the original spectra are found in the same file.  
>>>>>>>> If
>>>>>>>> not,
>>>>>>>> the spectrumRef attribute should maybe be renamed to
>>>>>>>> 'externalSpectrumID' or something else, since 'spectrumRef'
>>>>>>>>
>>>>>>>>
>>>> somehow
>>>>
>>>>
>>>>>>>> indicates that the spectrum is in the present file.
>>>>>>>>
>>>>>>>> If there is a need to reference spectra within the file the
>>>>>>>> following
>>>>>>>> may be an alternative (I think Darren proposed something
>>>>>>>> similar):
>>>>>>>>
>>>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>>>> 		<xs:annotation>
>>>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>>>
>>>>>>>>
>>>> original file
>>>>
>>>>
>>>>> used to
>>>>>
>>>>>
>>>>>>>> create this peak list. Either a spectrumRef or an
>>>>>>>>
>>>>>>>>
>>>> externalSpectrumID
>>>>
>>>>
>>>>>>>> plus sourceFileRef should be given .</xs:documentation>
>>>>>>>> 		</xs:annotation>
>>>>>>>> 		<xs:complexContent>
>>>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>>>> 				<xs:attribute name="number"
>>>>>>>>
>>>>>>>>
>>>> type="xs:int"
>>>>
>>>>
>>>>> use="required">
>>>>>
>>>>>
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>A
>>>>>>>>
>>>>>>>>
>>>> number for this
>>>>
>>>>
>>>>> acquisition.</
>>>>>
>>>>>
>>>>>>>> xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>>>
>>>>>>>>
>>>> type="xs:IDREF"
>>>>
>>>>
>>>>> use="optional">
>>>>>
>>>>>
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>This
>>>>>>>>
>>>>>>>>
>>>> attribute must
>>>>
>>>>
>>>>> reference the 'id'
>>>>>
>>>>>
>>>>>>>> attribute of the appropriate spectrum. </xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 				<xs:attribute name="externalSpectrumID"
>>>>>>>>
>>>>>>>>
>>>>> type="xs:string"
>>>>>
>>>>>
>>>>>>>> use="optional">
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>This
>>>>>>>>
>>>>>>>>
>>>> attribute must
>>>>
>>>>
>>>>> reference the 'id'
>>>>>
>>>>>
>>>>>>>> attribute of the appropriate spectrum if found within an  
>>>>>>>> external
>>>>>>>> mzML
>>>>>>>> file, or the native spectrum identifier in a raw file in  
>>>>>>>> another
>>>>>>>> format. </xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> <xs:attribute name="sourceFileRef" type="xs:IDREF"
>>>>>>>> use="optional">
>>>>>>>> 					<xs:annotation>
>>>>>>>> 						<xs:documentation>This
>>>>>>>>
>>>>>>>>
>>>> attribute must
>>>>
>>>>
>>>>> reference the 'id'
>>>>>
>>>>>
>>>>>>>> attribute of the appropriate sourceFile. It can also refer to  
>>>>>>>> the
>>>>>>>> present mzML file.</xs:documentation>
>>>>>>>> 					</xs:annotation>
>>>>>>>> 				</xs:attribute>
>>>>>>>> 			</xs:extension>
>>>>>>>> 		</xs:complexContent>
>>>>>>>> 	</xs:complexType>
>>>>>>>>
>>>>>>>> So, main question: are there any use cases with the original
>>>>>>>> scans
>>>>>>>> and
>>>>>>>> the summed spectrum in the same file, and is there in this  
>>>>>>>> case a
>>>>>>>> need
>>>>>>>> to distinguish clearly between external and internal  
>>>>>>>> referencing
>>>>>>>> (second schema alternative)?
>>>>>>>>
>>>>>>>> A minor point is also that the documentation of the spectrum
>>>>>>>> attribute
>>>>>>>> nativeID should be updated to something like:
>>>>>>>>
>>>>>>>> The native identifier for the spectrum, used by the acquisition
>>>>>>>> software. If the spectrum is reconstructed from more than one
>>>>>>>> spectrum, the native identifier of the first acquisition in  
>>>>>>>> time
>>>>>>>> should be used.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Fredrik
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>> -
>>>>>
>>>>>
>>>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>>>> Don't miss this year's exciting event. There's still time to save
>>>>>> $100.
>>>>>> Use priority code J8TL2D2.
>>>>>>
>>>>>>
>>>>>>
>>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>>>> av
>>>>
>>>>
>>>>> aone
>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> Psidev-ms-dev mailing list
>>>>>> Psi...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>>
>>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>> -
>>>>
>>>>
>>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>>> Don't miss this year's exciting event. There's still time to save
>>>>>
>>>>>
>>>> $100.
>>>>
>>>>
>>>>> Use priority code J8TL2D2.
>>>>>
>>>>>
>>>>>
>>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>>>> av
>>>>
>>>>
>>>>> aone
>>>>> _______________________________________________
>>>>> Psidev-ms-dev mailing list
>>>>> Psi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>
>>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>> Don't miss this year's exciting event. There's still time to save
>>>> $100.
>>>> Use priority code J8TL2D2.
>>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save
>>> $100.
>>> Use priority code J8TL2D2.
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save  
>> $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

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

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

Hi everyone, as previously mentioned, the PSI Mass Spectrometry Standards Working Group call is Tuesday May 6 at 9am PDT:

 

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

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to review and discuss what remains to be done to finish up mzML, including the latest release and some recent issues discovered while making examples.

 

Thanks,

Eric

 

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

Is a native file one that an actual instrument wrote or is it anything 
that isn't mzML? I.e. do we use externalNativeID to refer to a scan in 
an mzXML file, or do we use externalSpectrumID? Also, I'm willing to 
forfeit the possibility of referencing a spectrum within the current 
file that is not actually there.

So I see three possibilities, adding one to Darren's list:
spectrumRef (infer reference as current file and spectrumRef is IDREF 
pointing to an existing spectrum's id)
sourceFileRef + externalNativeID (original file is native)
sourceFileRef + externalSpectrumID (original file is mzML)

A fourth possibility may be useful, but not necessary:
nativeSpectrumRef (infer reference as current file and nativeSpectrumRef 
is string pointing to an existing spectrum's nativeID)

The three main cases can be schematically validated. Semantic validation 
would not be necessary to ensure that we don't get:
sourceFileRef + spectrumRef or
externalNativeID or
externalSpectrumID or
externalNativeID + externalSpectrumID or
spectrumRef + externalSpectrumID, etc...

-Matt


Darren Kessner wrote:
> Hi Eric,
>
> Thanks for the nice summary.
>
> I agree with Fredrik's proposal to add:
>      sourceFileRef + externalNativeID
> since the sourceFileRef may refer to a native data file, so  
> externalSpectrumID won't make sense.
>
> I believe Matt's case is covered by the two possibilities:
>      sourceFileRef + externalNativeID       (original file is native)
>      sourceFileRef + externalSpectrumID   (original file is mzML)
>
>
> Darren
>
>
> On May 2, 2008, at 12:28 PM, Fredrik Levander wrote:
>
>   
>> Hi Eric and others,
>>
>> All nice thoughts and proposals. I would also add an example 4 which  
>> is:
>>
>> Example 4: (the current spectrum is a sum of two scans which had
>> nativeIDs func1scan19 and func1scan20, the source file is found in  
>> the source file list)
>>
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>  <acquisition nativeID="func1scan19" sourceFileRef="rawFile1" />
>>  <acquisition nativeID="func1scan20" sourceFileRef="rawFile1" />
>> </acquisitionList>
>>
>> It would all be covered by the following xsd:
>>
>>    <xs:complexType name="AcquisitionType">
>>        <xs:annotation>
>>            <xs:documentation>Scan or acquisition from original file
>> used to
>> create this peak list.  A spectrumRef or an externalSpectrumID or  
>> nativeID
>> plus sourceFileRef should be given .</xs:documentation>
>>        </xs:annotation>
>>        <xs:complexContent>
>>            <xs:extension base="dx:ParamGroupType">
>>                <xs:attribute name="number" type="xs:int"  
>> use="required">
>>                    <xs:annotation>
>>                        <xs:documentation>A number for this  
>> acquisition.</
>> xs:documentation>
>>                    </xs:annotation>
>>                </xs:attribute>
>>                <xs:attribute name="spectrumRef" type="xs:IDREF"
>> use="optional">
>>                    <xs:annotation>
>>                        <xs:documentation>This attribute must reference
>> the 'id'
>> attribute of the appropriate spectrum. </xs:documentation>
>>                    </xs:annotation>
>>                </xs:attribute>
>>                <xs:attribute name="nativeID" type="xs:string"
>> use="optional">
>>                    <xs:annotation>
>>                        <xs:documentation>This attribute references the
>> native
>> spectrum identifier in a raw file. </xs:documentation>
>>                    </xs:annotation>
>>                </xs:attribute>
>>               <xs:attribute name="externalSpectrumID" type="xs:string"
>> use="optional">
>>                    <xs:annotation>
>>                        <xs:documentation>This attribute must reference
>> the 'id'
>> attribute of the appropriate spectrum in an external mzML
>> file. </xs:documentation>
>>                    </xs:annotation>
>>                </xs:attribute>
>>                <xs:attribute name="sourceFileRef" type="xs:IDREF"
>> use="optional">
>>                    <xs:annotation>
>>                        <xs:documentation>This attribute must reference
>> the 'id'
>> attribute of the appropriate sourceFile.
>>                        </xs:documentation>
>>                    </xs:annotation>
>>                </xs:attribute>
>>            </xs:extension>
>>        </xs:complexContent>
>>    </xs:complexType>
>>
>> The semantic validation would be to check that at least one of the
>> attributes spectrumRef, externalSpectrumID (+sourceFileRef) or  
>> nativeID
>> is given.
>>
>> Or maybe there is even more to consider?
>>
>> Fredrik
>>
>>
>> Eric Deutsch skrev:
>>     
>>> Hi Fredrik and everyone, thank you for thinking about these last few
>>> problems. It seems that there are several different ways in which one
>>> might want to reference the source scans for a summed scan. Based on
>>> what's been said so far, here are my thoughts and proposal. What do  
>>> you
>>> think?
>>>
>>> Currently for acquisitionList we have (in XML/XSD hybrid):
>>> ---------------
>>> <acquisitionList count="2">
>>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>>  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>>> spectrumRef="xs:IDREF">
>>>    <cvParam cvLabel="MS" (optional child of scan attribute)/>
>>>  </acquisition>
>>>  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>>> spectrumRef="xs:IDREF">
>>> </acquisitionList>
>>> ---------------
>>>
>>> Frederik suggests spectrumRef -> xs:string
>>> externalSpectrumID="xs:string"
>>>
>>> This brought up the question of how would sourceFileRef reference  
>>> itself
>>> if everything were in the same file?
>>>
>>> Rune points out that we want nativeID references, like for Waters:
>>>  function1scan2, func1scan2, 1.2 or ....
>>>
>>> Darren suggests:
>>>  externalSpectrumID="URI"
>>>  externalNativeID="xs:string"
>>>
>>> -------------------------------------------
>>>
>>> So, I suggest something like this (in XML/XSD hybrid):
>>>
>>> <acquisitionList count="2">
>>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>> (three possible options:)
>>>  <acquisition spectrumRef="xs:IDREF">
>>>  <acquisition nativeID="xs:string">
>>>  <acquisition sourceFileRef="xs:IDREF"  
>>> externalSpectrumID="xs:string">
>>>  <acquisition
>>> </acquisitionList>
>>>
>>> ---
>>>
>>> Example 1: (the current spectrum is a sum of two scans which are also
>>> present in the current file as ids S57 and S58.)
>>>
>>> <acquisitionList count="2">
>>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>>  <acquisition spectrumRef="S57">
>>>  <acquisition spectrumRef="S58">
>>> </acquisitionList>
>>>
>>> ---
>>>
>>> Example 2: (the current spectrum is a sum of two scans which had
>>> nativeIDs func1scan19 and func1scan20, the exact location of which
>>> are not specifiable)
>>>
>>> <acquisitionList count="2">
>>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>>  <acquisition nativeID="func1scan19">
>>>  <acquisition nativeID="func1scan20">
>>> </acquisitionList>
>>>
>>> ---
>>>
>>> Example 3: (the current spectrum is a sum of two scans which are
>>> explicitly referenced externally by a specific file previously
>>> defined in the current document and with IDs in that other file)
>>>
>>> <acquisitionList count="2">
>>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>>  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57">
>>>  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58">
>>> </acquisitionList>
>>>
>>> ---
>>>
>>> Also okay is 1+2:
>>>
>>>  <acquisition spectrumRef="S57" nativeID="func1scan19">
>>>  <acquisition spectrumRef="S58" nativeID="func1scan20">
>>>
>>> ---
>>>
>>> Also okay is 2+3:
>>>
>>>  <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01"
>>> externalSpectrumID="S57">
>>>  <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01"
>>> externalSpectrumID="S58">
>>>
>>> ---
>>>
>>> Thus, all four possible attributes are optional, and we would rely on
>>> the sematic validator to enforce:
>>>
>>>   spectrumRef alone
>>> OR nativeID alone
>>> OR spectrumRef AND nativeID
>>> OR sourceFileRef AND externalSpectrumID
>>> OR sourceFileRef AND externalSpectrumID AND nativeID
>>>
>>> What do you think? A little unpleasant to have several different
>>> options, but I don't see how we could practically exclude any of the
>>> options.
>>>
>>>
>>> As a related side note, Matt also asks if we can handle the case  
>>> where
>>> MS1 scans have been stripped out of a file, but the the MS2 scans  
>>> still
>>> need to say something useful about their precursor scan (IDREF not
>>> possible).
>>>
>>> I have not checked this, but we should spend some time thinking about
>>> that once we have solved this problem.
>>>
>>> Thanks,
>>> Eric
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: psi...@li...
>>>>
>>>>         
>>> [mailto:psidev-ms-dev-
>>>
>>>       
>>>> bo...@li...] On Behalf Of Darren Kessner
>>>> Sent: Friday, May 02, 2008 9:13 AM
>>>> To: Mass spectrometry standard development
>>>> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in  
>>>> mzML
>>>> 0.99.10
>>>>
>>>> I think it's a bad idea to have a spectrumRef to a spectrum that  
>>>> isn't
>>>> in the file.  We should be consistent in the use of internal
>>>> references, all of which use IDREF so that dangling references can  
>>>> be
>>>> caught during XML validation.
>>>>
>>>> External references, including those to spectra that have been  
>>>> removed
>>>> for space reasons, should be indicated specifically (e.g. with
>>>> externalSpectrumID or externalNativeID) so that the reader (human or
>>>> software) knows that they'll have to do some extra work to find the
>>>> referent.
>>>>
>>>>
>>>> Darren
>>>>
>>>>
>>>>
>>>> On May 2, 2008, at 6:17 AM, Matt Chambers wrote:
>>>>
>>>>
>>>>         
>>>>> Perhaps we should follow the same logic of the spectrum element
>>>>> itself,
>>>>> where id is required but nativeID is optional. Thus, id is required
>>>>> for
>>>>> a spectrum reference and a reference to the nativeID would be
>>>>>
>>>>>           
>>> optional
>>>
>>>       
>>>>> (but recommended!). We can't use the same attribute to point to
>>>>>
>>>>>           
>>> either
>>>
>>>       
>>>>> id or nativeID because then it won't be known which is being
>>>>>
>>>>>           
>>> referred
>>>
>>>       
>>>>> to, unless I'm missing something in Fredrik's proposal.
>>>>>
>>>>> To deal with IDs that aren't in the file, I agree with Fredrik. Any
>>>>> time
>>>>> we have a reference that can be to a non-existent or external
>>>>>
>>>>>           
>>> element,
>>>
>>>       
>>>>> we can't use IDREF. We either need to switch to xlink (in which  
>>>>> case
>>>>> IDREF would probably still be ok) or fall back to string. However,
>>>>> since
>>>>> I think that acquisitions should be able to reference spectra in  
>>>>> the
>>>>> current file, we shouldn't change it to externalSpectrumID. We
>>>>>
>>>>>           
>>> should
>>>
>>>       
>>>>> just document that all spectrumRef and spectrumNativeID(Ref?)
>>>>> attributes
>>>>> may refer to a spectrum in the current file or in another one, and
>>>>>
>>>>>           
>>> in
>>>
>>>       
>>>>> the former case the spectrum might not actually be there (i.e. MSn
>>>>> spectra referencing precursor spectra that have been stripped out  
>>>>> to
>>>>> conserve space).
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>> Rune Schjellerup Philosof wrote:
>>>>>
>>>>>           
>>>>>> I think the format by which external file elements are reference
>>>>>> should
>>>>>> be defined.
>>>>>> For instance, a reference to a Waters raw file, should that be
>>>>>> function1scan2, func1scan2, 1.2 or ....
>>>>>>
>>>>>> --
>>>>>> Rune
>>>>>>
>>>>>> Fredrik Levander wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Hi All,
>>>>>>>
>>>>>>> There is an issue with the current mzML schema (0.99.10) when it
>>>>>>> comes
>>>>>>> to referencing the origin of acquisitions in an acquistionList of
>>>>>>> summed spectra. In most cases the referenced spectra will not be
>>>>>>>
>>>>>>>               
>>> in
>>>
>>>       
>>>>>>> the current mzML file, and thus the spectrumRef cannot be of the
>>>>>>> type
>>>>>>> xs:IDREF, but should be xs:string to also cover references to
>>>>>>> spectrum
>>>>>>> IDs in other mzML files, or native IDs in vendor files.
>>>>>>>
>>>>>>> The following would cover both internal and external spectrum
>>>>>>> referencing:
>>>>>>>
>>>>>>>
>>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>>> 		<xs:annotation>
>>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>>
>>>>>>>               
>>> original raw
>>>
>>>       
>>>> file used
>>>>
>>>>         
>>>>>>> to create this peak list, as specified in sourceFile.</
>>>>>>> xs:documentation>
>>>>>>> 		</xs:annotation>
>>>>>>> 		<xs:complexContent>
>>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>>> 				<xs:attribute name="number"
>>>>>>>
>>>>>>>               
>>> type="xs:int"
>>>
>>>       
>>>> use="required">
>>>>
>>>>         
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>A
>>>>>>>
>>>>>>>               
>>> number for this
>>>
>>>       
>>>> acquisition.</
>>>>
>>>>         
>>>>>>> xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>>
>>>>>>>               
>>> type="xs:string"
>>>
>>>       
>>>>>>> use="required">
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>This
>>>>>>>
>>>>>>>               
>>> attribute must
>>>
>>>       
>>>> reference the 'id'
>>>>
>>>>         
>>>>>>> attribute of the appropriate spectrum if found within an mzML
>>>>>>> file, or
>>>>>>> the native spectrum identifier in a raw file in another format.  
>>>>>>> </
>>>>>>> xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 				<xs:attribute name="sourceFileRef"
>>>>>>>
>>>>>>>               
>>> type="xs:IDREF"
>>>
>>>       
>>>>>>> use="required">
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>This
>>>>>>>
>>>>>>>               
>>> attribute must
>>>
>>>       
>>>> reference the 'id'
>>>>
>>>>         
>>>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>>>> present mzML file.</xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 			</xs:extension>
>>>>>>> 		</xs:complexContent>
>>>>>>> 	</xs:complexType>
>>>>>>>
>>>>>>> However, I am not sure if there are any use cases when both the
>>>>>>> summed
>>>>>>> spectrum and the original spectra are found in the same file. If
>>>>>>> not,
>>>>>>> the spectrumRef attribute should maybe be renamed to
>>>>>>> 'externalSpectrumID' or something else, since 'spectrumRef'
>>>>>>>
>>>>>>>               
>>> somehow
>>>
>>>       
>>>>>>> indicates that the spectrum is in the present file.
>>>>>>>
>>>>>>> If there is a need to reference spectra within the file the
>>>>>>> following
>>>>>>> may be an alternative (I think Darren proposed something  
>>>>>>> similar):
>>>>>>>
>>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>>> 		<xs:annotation>
>>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>>
>>>>>>>               
>>> original file
>>>
>>>       
>>>> used to
>>>>
>>>>         
>>>>>>> create this peak list. Either a spectrumRef or an
>>>>>>>
>>>>>>>               
>>> externalSpectrumID
>>>
>>>       
>>>>>>> plus sourceFileRef should be given .</xs:documentation>
>>>>>>> 		</xs:annotation>
>>>>>>> 		<xs:complexContent>
>>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>>> 				<xs:attribute name="number"
>>>>>>>
>>>>>>>               
>>> type="xs:int"
>>>
>>>       
>>>> use="required">
>>>>
>>>>         
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>A
>>>>>>>
>>>>>>>               
>>> number for this
>>>
>>>       
>>>> acquisition.</
>>>>
>>>>         
>>>>>>> xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>>
>>>>>>>               
>>> type="xs:IDREF"
>>>
>>>       
>>>> use="optional">
>>>>
>>>>         
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>This
>>>>>>>
>>>>>>>               
>>> attribute must
>>>
>>>       
>>>> reference the 'id'
>>>>
>>>>         
>>>>>>> attribute of the appropriate spectrum. </xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 				<xs:attribute name="externalSpectrumID"
>>>>>>>
>>>>>>>               
>>>> type="xs:string"
>>>>
>>>>         
>>>>>>> use="optional">
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>This
>>>>>>>
>>>>>>>               
>>> attribute must
>>>
>>>       
>>>> reference the 'id'
>>>>
>>>>         
>>>>>>> attribute of the appropriate spectrum if found within an external
>>>>>>> mzML
>>>>>>> file, or the native spectrum identifier in a raw file in another
>>>>>>> format. </xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> <xs:attribute name="sourceFileRef" type="xs:IDREF"  
>>>>>>> use="optional">
>>>>>>> 					<xs:annotation>
>>>>>>> 						<xs:documentation>This
>>>>>>>
>>>>>>>               
>>> attribute must
>>>
>>>       
>>>> reference the 'id'
>>>>
>>>>         
>>>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>>>> present mzML file.</xs:documentation>
>>>>>>> 					</xs:annotation>
>>>>>>> 				</xs:attribute>
>>>>>>> 			</xs:extension>
>>>>>>> 		</xs:complexContent>
>>>>>>> 	</xs:complexType>
>>>>>>>
>>>>>>> So, main question: are there any use cases with the original  
>>>>>>> scans
>>>>>>> and
>>>>>>> the summed spectrum in the same file, and is there in this case a
>>>>>>> need
>>>>>>> to distinguish clearly between external and internal referencing
>>>>>>> (second schema alternative)?
>>>>>>>
>>>>>>> A minor point is also that the documentation of the spectrum
>>>>>>> attribute
>>>>>>> nativeID should be updated to something like:
>>>>>>>
>>>>>>> The native identifier for the spectrum, used by the acquisition
>>>>>>> software. If the spectrum is reconstructed from more than one
>>>>>>> spectrum, the native identifier of the first acquisition in time
>>>>>>> should be used.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Fredrik
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>           
>>> ------------------------------------------------------------------------
>>>
>>>       
>>>> -
>>>>
>>>>         
>>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>>> Don't miss this year's exciting event. There's still time to save
>>>>> $100.
>>>>> Use priority code J8TL2D2.
>>>>>
>>>>>
>>>>>           
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>>> av
>>>
>>>       
>>>> aone
>>>>
>>>>         
>>>>> _______________________________________________
>>>>> Psidev-ms-dev mailing list
>>>>> Psi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>>
>>>>>           
>>>>         
>>> ------------------------------------------------------------------------
>>> -
>>>
>>>       
>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>> Don't miss this year's exciting event. There's still time to save
>>>>
>>>>         
>>> $100.
>>>
>>>       
>>>> Use priority code J8TL2D2.
>>>>
>>>>
>>>>         
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>>> av
>>>
>>>       
>>>> aone
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>
>>>>         
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save  
>>> $100.
>>> Use priority code J8TL2D2.
>>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save  
>> $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

[Darren K. <Dar...@cs...>]

Hi Eric,

Thanks for the nice summary.

I agree with Fredrik's proposal to add:
     sourceFileRef + externalNativeID
since the sourceFileRef may refer to a native data file, so  
externalSpectrumID won't make sense.

I believe Matt's case is covered by the two possibilities:
     sourceFileRef + externalNativeID       (original file is native)
     sourceFileRef + externalSpectrumID   (original file is mzML)


Darren


On May 2, 2008, at 12:28 PM, Fredrik Levander wrote:

> Hi Eric and others,
>
> All nice thoughts and proposals. I would also add an example 4 which  
> is:
>
> Example 4: (the current spectrum is a sum of two scans which had
> nativeIDs func1scan19 and func1scan20, the source file is found in  
> the source file list)
>
> <acquisitionList count="2">
>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>  <acquisition nativeID="func1scan19" sourceFileRef="rawFile1" />
>  <acquisition nativeID="func1scan20" sourceFileRef="rawFile1" />
> </acquisitionList>
>
> It would all be covered by the following xsd:
>
>    <xs:complexType name="AcquisitionType">
>        <xs:annotation>
>            <xs:documentation>Scan or acquisition from original file
> used to
> create this peak list.  A spectrumRef or an externalSpectrumID or  
> nativeID
> plus sourceFileRef should be given .</xs:documentation>
>        </xs:annotation>
>        <xs:complexContent>
>            <xs:extension base="dx:ParamGroupType">
>                <xs:attribute name="number" type="xs:int"  
> use="required">
>                    <xs:annotation>
>                        <xs:documentation>A number for this  
> acquisition.</
> xs:documentation>
>                    </xs:annotation>
>                </xs:attribute>
>                <xs:attribute name="spectrumRef" type="xs:IDREF"
> use="optional">
>                    <xs:annotation>
>                        <xs:documentation>This attribute must reference
> the 'id'
> attribute of the appropriate spectrum. </xs:documentation>
>                    </xs:annotation>
>                </xs:attribute>
>                <xs:attribute name="nativeID" type="xs:string"
> use="optional">
>                    <xs:annotation>
>                        <xs:documentation>This attribute references the
> native
> spectrum identifier in a raw file. </xs:documentation>
>                    </xs:annotation>
>                </xs:attribute>
>               <xs:attribute name="externalSpectrumID" type="xs:string"
> use="optional">
>                    <xs:annotation>
>                        <xs:documentation>This attribute must reference
> the 'id'
> attribute of the appropriate spectrum in an external mzML
> file. </xs:documentation>
>                    </xs:annotation>
>                </xs:attribute>
>                <xs:attribute name="sourceFileRef" type="xs:IDREF"
> use="optional">
>                    <xs:annotation>
>                        <xs:documentation>This attribute must reference
> the 'id'
> attribute of the appropriate sourceFile.
>                        </xs:documentation>
>                    </xs:annotation>
>                </xs:attribute>
>            </xs:extension>
>        </xs:complexContent>
>    </xs:complexType>
>
> The semantic validation would be to check that at least one of the
> attributes spectrumRef, externalSpectrumID (+sourceFileRef) or  
> nativeID
> is given.
>
> Or maybe there is even more to consider?
>
> Fredrik
>
>
> Eric Deutsch skrev:
>> Hi Fredrik and everyone, thank you for thinking about these last few
>> problems. It seems that there are several different ways in which one
>> might want to reference the source scans for a summed scan. Based on
>> what's been said so far, here are my thoughts and proposal. What do  
>> you
>> think?
>>
>> Currently for acquisitionList we have (in XML/XSD hybrid):
>> ---------------
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>> spectrumRef="xs:IDREF">
>>    <cvParam cvLabel="MS" (optional child of scan attribute)/>
>>  </acquisition>
>>  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
>> spectrumRef="xs:IDREF">
>> </acquisitionList>
>> ---------------
>>
>> Frederik suggests spectrumRef -> xs:string
>> externalSpectrumID="xs:string"
>>
>> This brought up the question of how would sourceFileRef reference  
>> itself
>> if everything were in the same file?
>>
>> Rune points out that we want nativeID references, like for Waters:
>>  function1scan2, func1scan2, 1.2 or ....
>>
>> Darren suggests:
>>  externalSpectrumID="URI"
>>  externalNativeID="xs:string"
>>
>> -------------------------------------------
>>
>> So, I suggest something like this (in XML/XSD hybrid):
>>
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>> (three possible options:)
>>  <acquisition spectrumRef="xs:IDREF">
>>  <acquisition nativeID="xs:string">
>>  <acquisition sourceFileRef="xs:IDREF"  
>> externalSpectrumID="xs:string">
>>  <acquisition
>> </acquisitionList>
>>
>> ---
>>
>> Example 1: (the current spectrum is a sum of two scans which are also
>> present in the current file as ids S57 and S58.)
>>
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>  <acquisition spectrumRef="S57">
>>  <acquisition spectrumRef="S58">
>> </acquisitionList>
>>
>> ---
>>
>> Example 2: (the current spectrum is a sum of two scans which had
>> nativeIDs func1scan19 and func1scan20, the exact location of which
>> are not specifiable)
>>
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>  <acquisition nativeID="func1scan19">
>>  <acquisition nativeID="func1scan20">
>> </acquisitionList>
>>
>> ---
>>
>> Example 3: (the current spectrum is a sum of two scans which are
>> explicitly referenced externally by a specific file previously
>> defined in the current document and with IDs in that other file)
>>
>> <acquisitionList count="2">
>>  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>>  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57">
>>  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58">
>> </acquisitionList>
>>
>> ---
>>
>> Also okay is 1+2:
>>
>>  <acquisition spectrumRef="S57" nativeID="func1scan19">
>>  <acquisition spectrumRef="S58" nativeID="func1scan20">
>>
>> ---
>>
>> Also okay is 2+3:
>>
>>  <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01"
>> externalSpectrumID="S57">
>>  <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01"
>> externalSpectrumID="S58">
>>
>> ---
>>
>> Thus, all four possible attributes are optional, and we would rely on
>> the sematic validator to enforce:
>>
>>   spectrumRef alone
>> OR nativeID alone
>> OR spectrumRef AND nativeID
>> OR sourceFileRef AND externalSpectrumID
>> OR sourceFileRef AND externalSpectrumID AND nativeID
>>
>> What do you think? A little unpleasant to have several different
>> options, but I don't see how we could practically exclude any of the
>> options.
>>
>>
>> As a related side note, Matt also asks if we can handle the case  
>> where
>> MS1 scans have been stripped out of a file, but the the MS2 scans  
>> still
>> need to say something useful about their precursor scan (IDREF not
>> possible).
>>
>> I have not checked this, but we should spend some time thinking about
>> that once we have solved this problem.
>>
>> Thanks,
>> Eric
>>
>>
>>
>>> -----Original Message-----
>>> From: psi...@li...
>>>
>> [mailto:psidev-ms-dev-
>>
>>> bo...@li...] On Behalf Of Darren Kessner
>>> Sent: Friday, May 02, 2008 9:13 AM
>>> To: Mass spectrometry standard development
>>> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in  
>>> mzML
>>> 0.99.10
>>>
>>> I think it's a bad idea to have a spectrumRef to a spectrum that  
>>> isn't
>>> in the file.  We should be consistent in the use of internal
>>> references, all of which use IDREF so that dangling references can  
>>> be
>>> caught during XML validation.
>>>
>>> External references, including those to spectra that have been  
>>> removed
>>> for space reasons, should be indicated specifically (e.g. with
>>> externalSpectrumID or externalNativeID) so that the reader (human or
>>> software) knows that they'll have to do some extra work to find the
>>> referent.
>>>
>>>
>>> Darren
>>>
>>>
>>>
>>> On May 2, 2008, at 6:17 AM, Matt Chambers wrote:
>>>
>>>
>>>> Perhaps we should follow the same logic of the spectrum element
>>>> itself,
>>>> where id is required but nativeID is optional. Thus, id is required
>>>> for
>>>> a spectrum reference and a reference to the nativeID would be
>>>>
>> optional
>>
>>>> (but recommended!). We can't use the same attribute to point to
>>>>
>> either
>>
>>>> id or nativeID because then it won't be known which is being
>>>>
>> referred
>>
>>>> to, unless I'm missing something in Fredrik's proposal.
>>>>
>>>> To deal with IDs that aren't in the file, I agree with Fredrik. Any
>>>> time
>>>> we have a reference that can be to a non-existent or external
>>>>
>> element,
>>
>>>> we can't use IDREF. We either need to switch to xlink (in which  
>>>> case
>>>> IDREF would probably still be ok) or fall back to string. However,
>>>> since
>>>> I think that acquisitions should be able to reference spectra in  
>>>> the
>>>> current file, we shouldn't change it to externalSpectrumID. We
>>>>
>> should
>>
>>>> just document that all spectrumRef and spectrumNativeID(Ref?)
>>>> attributes
>>>> may refer to a spectrum in the current file or in another one, and
>>>>
>> in
>>
>>>> the former case the spectrum might not actually be there (i.e. MSn
>>>> spectra referencing precursor spectra that have been stripped out  
>>>> to
>>>> conserve space).
>>>>
>>>> -Matt
>>>>
>>>>
>>>> Rune Schjellerup Philosof wrote:
>>>>
>>>>> I think the format by which external file elements are reference
>>>>> should
>>>>> be defined.
>>>>> For instance, a reference to a Waters raw file, should that be
>>>>> function1scan2, func1scan2, 1.2 or ....
>>>>>
>>>>> --
>>>>> Rune
>>>>>
>>>>> Fredrik Levander wrote:
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> There is an issue with the current mzML schema (0.99.10) when it
>>>>>> comes
>>>>>> to referencing the origin of acquisitions in an acquistionList of
>>>>>> summed spectra. In most cases the referenced spectra will not be
>>>>>>
>> in
>>
>>>>>> the current mzML file, and thus the spectrumRef cannot be of the
>>>>>> type
>>>>>> xs:IDREF, but should be xs:string to also cover references to
>>>>>> spectrum
>>>>>> IDs in other mzML files, or native IDs in vendor files.
>>>>>>
>>>>>> The following would cover both internal and external spectrum
>>>>>> referencing:
>>>>>>
>>>>>>
>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>> 		<xs:annotation>
>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>
>> original raw
>>
>>> file used
>>>
>>>>>> to create this peak list, as specified in sourceFile.</
>>>>>> xs:documentation>
>>>>>> 		</xs:annotation>
>>>>>> 		<xs:complexContent>
>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>> 				<xs:attribute name="number"
>>>>>>
>> type="xs:int"
>>
>>> use="required">
>>>
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>A
>>>>>>
>> number for this
>>
>>> acquisition.</
>>>
>>>>>> xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>
>> type="xs:string"
>>
>>>>>> use="required">
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>This
>>>>>>
>> attribute must
>>
>>> reference the 'id'
>>>
>>>>>> attribute of the appropriate spectrum if found within an mzML
>>>>>> file, or
>>>>>> the native spectrum identifier in a raw file in another format.  
>>>>>> </
>>>>>> xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 				<xs:attribute name="sourceFileRef"
>>>>>>
>> type="xs:IDREF"
>>
>>>>>> use="required">
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>This
>>>>>>
>> attribute must
>>
>>> reference the 'id'
>>>
>>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>>> present mzML file.</xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 			</xs:extension>
>>>>>> 		</xs:complexContent>
>>>>>> 	</xs:complexType>
>>>>>>
>>>>>> However, I am not sure if there are any use cases when both the
>>>>>> summed
>>>>>> spectrum and the original spectra are found in the same file. If
>>>>>> not,
>>>>>> the spectrumRef attribute should maybe be renamed to
>>>>>> 'externalSpectrumID' or something else, since 'spectrumRef'
>>>>>>
>> somehow
>>
>>>>>> indicates that the spectrum is in the present file.
>>>>>>
>>>>>> If there is a need to reference spectra within the file the
>>>>>> following
>>>>>> may be an alternative (I think Darren proposed something  
>>>>>> similar):
>>>>>>
>>>>>> 	<xs:complexType name="AcquisitionType">
>>>>>> 		<xs:annotation>
>>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>>
>> original file
>>
>>> used to
>>>
>>>>>> create this peak list. Either a spectrumRef or an
>>>>>>
>> externalSpectrumID
>>
>>>>>> plus sourceFileRef should be given .</xs:documentation>
>>>>>> 		</xs:annotation>
>>>>>> 		<xs:complexContent>
>>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>>> 				<xs:attribute name="number"
>>>>>>
>> type="xs:int"
>>
>>> use="required">
>>>
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>A
>>>>>>
>> number for this
>>
>>> acquisition.</
>>>
>>>>>> xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 				<xs:attribute name="spectrumRef"
>>>>>>
>> type="xs:IDREF"
>>
>>> use="optional">
>>>
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>This
>>>>>>
>> attribute must
>>
>>> reference the 'id'
>>>
>>>>>> attribute of the appropriate spectrum. </xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 				<xs:attribute name="externalSpectrumID"
>>>>>>
>>> type="xs:string"
>>>
>>>>>> use="optional">
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>This
>>>>>>
>> attribute must
>>
>>> reference the 'id'
>>>
>>>>>> attribute of the appropriate spectrum if found within an external
>>>>>> mzML
>>>>>> file, or the native spectrum identifier in a raw file in another
>>>>>> format. </xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> <xs:attribute name="sourceFileRef" type="xs:IDREF"  
>>>>>> use="optional">
>>>>>> 					<xs:annotation>
>>>>>> 						<xs:documentation>This
>>>>>>
>> attribute must
>>
>>> reference the 'id'
>>>
>>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>>> present mzML file.</xs:documentation>
>>>>>> 					</xs:annotation>
>>>>>> 				</xs:attribute>
>>>>>> 			</xs:extension>
>>>>>> 		</xs:complexContent>
>>>>>> 	</xs:complexType>
>>>>>>
>>>>>> So, main question: are there any use cases with the original  
>>>>>> scans
>>>>>> and
>>>>>> the summed spectrum in the same file, and is there in this case a
>>>>>> need
>>>>>> to distinguish clearly between external and internal referencing
>>>>>> (second schema alternative)?
>>>>>>
>>>>>> A minor point is also that the documentation of the spectrum
>>>>>> attribute
>>>>>> nativeID should be updated to something like:
>>>>>>
>>>>>> The native identifier for the spectrum, used by the acquisition
>>>>>> software. If the spectrum is reconstructed from more than one
>>>>>> spectrum, the native identifier of the first acquisition in time
>>>>>> should be used.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Fredrik
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>> ------------------------------------------------------------------------
>>
>>> -
>>>
>>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>>> Don't miss this year's exciting event. There's still time to save
>>>> $100.
>>>> Use priority code J8TL2D2.
>>>>
>>>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>> av
>>
>>> aone
>>>
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>
>>>
>>>
>> ------------------------------------------------------------------------
>> -
>>
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save
>>>
>> $100.
>>
>>> Use priority code J8TL2D2.
>>>
>>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
>> av
>>
>>> aone
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save  
>> $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

Hi Eric and others,

All nice thoughts and proposals. I would also add an example 4 which is:

Example 4: (the current spectrum is a sum of two scans which had
nativeIDs func1scan19 and func1scan20, the source file is found in the source file list)

<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
  <acquisition nativeID="func1scan19" sourceFileRef="rawFile1" />
  <acquisition nativeID="func1scan20" sourceFileRef="rawFile1" />
</acquisitionList>

It would all be covered by the following xsd:

    <xs:complexType name="AcquisitionType">
        <xs:annotation>
            <xs:documentation>Scan or acquisition from original file 
used to 
create this peak list.  A spectrumRef or an externalSpectrumID or nativeID
plus sourceFileRef should be given .</xs:documentation>
        </xs:annotation>
        <xs:complexContent>
            <xs:extension base="dx:ParamGroupType">
                <xs:attribute name="number" type="xs:int" use="required">
                    <xs:annotation>
                        <xs:documentation>A number for this acquisition.</
xs:documentation>
                    </xs:annotation>
                </xs:attribute>
                <xs:attribute name="spectrumRef" type="xs:IDREF" 
use="optional">
                    <xs:annotation>
                        <xs:documentation>This attribute must reference 
the 'id' 
attribute of the appropriate spectrum. </xs:documentation>
                    </xs:annotation>
                </xs:attribute>
                <xs:attribute name="nativeID" type="xs:string" 
use="optional">
                    <xs:annotation>
                        <xs:documentation>This attribute references the 
native
spectrum identifier in a raw file. </xs:documentation>
                    </xs:annotation>
                </xs:attribute>
               <xs:attribute name="externalSpectrumID" type="xs:string" 
use="optional">
                    <xs:annotation>
                        <xs:documentation>This attribute must reference 
the 'id' 
attribute of the appropriate spectrum in an external mzML 
file. </xs:documentation>
                    </xs:annotation>
                </xs:attribute>
                <xs:attribute name="sourceFileRef" type="xs:IDREF" 
use="optional">
                    <xs:annotation>
                        <xs:documentation>This attribute must reference 
the 'id' 
attribute of the appropriate sourceFile.
                        </xs:documentation>
                    </xs:annotation>
                </xs:attribute>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

The semantic validation would be to check that at least one of the 
attributes spectrumRef, externalSpectrumID (+sourceFileRef) or nativeID 
is given.

Or maybe there is even more to consider?

Fredrik


Eric Deutsch skrev:
> Hi Fredrik and everyone, thank you for thinking about these last few
> problems. It seems that there are several different ways in which one
> might want to reference the source scans for a summed scan. Based on
> what's been said so far, here are my thoughts and proposal. What do you
> think?
>
> Currently for acquisitionList we have (in XML/XSD hybrid):
> ---------------
> <acquisitionList count="2">
>   <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>   <acquisition number="xs:int" sourceFileRef="xs:IDREF"
> spectrumRef="xs:IDREF">
>     <cvParam cvLabel="MS" (optional child of scan attribute)/>
>   </acquisition>
>   <acquisition number="xs:int" sourceFileRef="xs:IDREF"
> spectrumRef="xs:IDREF">
> </acquisitionList>
> ---------------
>
> Frederik suggests spectrumRef -> xs:string
> externalSpectrumID="xs:string"
>
> This brought up the question of how would sourceFileRef reference itself
> if everything were in the same file?
>
> Rune points out that we want nativeID references, like for Waters:
>   function1scan2, func1scan2, 1.2 or ....
>
> Darren suggests:
>   externalSpectrumID="URI"
>   externalNativeID="xs:string"
>
> -------------------------------------------
>
> So, I suggest something like this (in XML/XSD hybrid):
>
> <acquisitionList count="2">
>   <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
> (three possible options:)
>   <acquisition spectrumRef="xs:IDREF">
>   <acquisition nativeID="xs:string">
>   <acquisition sourceFileRef="xs:IDREF" externalSpectrumID="xs:string">
>   <acquisition 
> </acquisitionList>
>
> ---
>
> Example 1: (the current spectrum is a sum of two scans which are also
> present in the current file as ids S57 and S58.)
>
> <acquisitionList count="2">
>   <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>   <acquisition spectrumRef="S57">
>   <acquisition spectrumRef="S58">
> </acquisitionList>
>
> ---
>
> Example 2: (the current spectrum is a sum of two scans which had
> nativeIDs func1scan19 and func1scan20, the exact location of which
> are not specifiable)
>
> <acquisitionList count="2">
>   <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>   <acquisition nativeID="func1scan19">
>   <acquisition nativeID="func1scan20">
> </acquisitionList>
>
> ---
>
> Example 3: (the current spectrum is a sum of two scans which are
> explicitly referenced externally by a specific file previously
> defined in the current document and with IDs in that other file)
>
> <acquisitionList count="2">
>   <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
>   <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57">
>   <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58">
> </acquisitionList>
>
> ---
>
> Also okay is 1+2:
>
>   <acquisition spectrumRef="S57" nativeID="func1scan19">
>   <acquisition spectrumRef="S58" nativeID="func1scan20">
>
> ---
>
> Also okay is 2+3:
>
>   <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01"
> externalSpectrumID="S57">
>   <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01"
> externalSpectrumID="S58">
>
> ---
>
> Thus, all four possible attributes are optional, and we would rely on
> the sematic validator to enforce:
>
>    spectrumRef alone
> OR nativeID alone
> OR spectrumRef AND nativeID
> OR sourceFileRef AND externalSpectrumID
> OR sourceFileRef AND externalSpectrumID AND nativeID
>
> What do you think? A little unpleasant to have several different
> options, but I don't see how we could practically exclude any of the
> options.
>
>
> As a related side note, Matt also asks if we can handle the case where
> MS1 scans have been stripped out of a file, but the the MS2 scans still
> need to say something useful about their precursor scan (IDREF not
> possible).
>
> I have not checked this, but we should spend some time thinking about
> that once we have solved this problem.
>
> Thanks,
> Eric
>
>
>   
>> -----Original Message-----
>> From: psi...@li...
>>     
> [mailto:psidev-ms-dev-
>   
>> bo...@li...] On Behalf Of Darren Kessner
>> Sent: Friday, May 02, 2008 9:13 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML
>> 0.99.10
>>
>> I think it's a bad idea to have a spectrumRef to a spectrum that isn't
>> in the file.  We should be consistent in the use of internal
>> references, all of which use IDREF so that dangling references can be
>> caught during XML validation.
>>
>> External references, including those to spectra that have been removed
>> for space reasons, should be indicated specifically (e.g. with
>> externalSpectrumID or externalNativeID) so that the reader (human or
>> software) knows that they'll have to do some extra work to find the
>> referent.
>>
>>
>> Darren
>>
>>
>>
>> On May 2, 2008, at 6:17 AM, Matt Chambers wrote:
>>
>>     
>>> Perhaps we should follow the same logic of the spectrum element
>>> itself,
>>> where id is required but nativeID is optional. Thus, id is required
>>> for
>>> a spectrum reference and a reference to the nativeID would be
>>>       
> optional
>   
>>> (but recommended!). We can't use the same attribute to point to
>>>       
> either
>   
>>> id or nativeID because then it won't be known which is being
>>>       
> referred
>   
>>> to, unless I'm missing something in Fredrik's proposal.
>>>
>>> To deal with IDs that aren't in the file, I agree with Fredrik. Any
>>> time
>>> we have a reference that can be to a non-existent or external
>>>       
> element,
>   
>>> we can't use IDREF. We either need to switch to xlink (in which case
>>> IDREF would probably still be ok) or fall back to string. However,
>>> since
>>> I think that acquisitions should be able to reference spectra in the
>>> current file, we shouldn't change it to externalSpectrumID. We
>>>       
> should
>   
>>> just document that all spectrumRef and spectrumNativeID(Ref?)
>>> attributes
>>> may refer to a spectrum in the current file or in another one, and
>>>       
> in
>   
>>> the former case the spectrum might not actually be there (i.e. MSn
>>> spectra referencing precursor spectra that have been stripped out to
>>> conserve space).
>>>
>>> -Matt
>>>
>>>
>>> Rune Schjellerup Philosof wrote:
>>>       
>>>> I think the format by which external file elements are reference
>>>> should
>>>> be defined.
>>>> For instance, a reference to a Waters raw file, should that be
>>>> function1scan2, func1scan2, 1.2 or ....
>>>>
>>>> --
>>>> Rune
>>>>
>>>> Fredrik Levander wrote:
>>>>
>>>>         
>>>>> Hi All,
>>>>>
>>>>> There is an issue with the current mzML schema (0.99.10) when it
>>>>> comes
>>>>> to referencing the origin of acquisitions in an acquistionList of
>>>>> summed spectra. In most cases the referenced spectra will not be
>>>>>           
> in
>   
>>>>> the current mzML file, and thus the spectrumRef cannot be of the
>>>>> type
>>>>> xs:IDREF, but should be xs:string to also cover references to
>>>>> spectrum
>>>>> IDs in other mzML files, or native IDs in vendor files.
>>>>>
>>>>> The following would cover both internal and external spectrum
>>>>> referencing:
>>>>>
>>>>>
>>>>> 	<xs:complexType name="AcquisitionType">
>>>>> 		<xs:annotation>
>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>           
> original raw
>   
>> file used
>>     
>>>>> to create this peak list, as specified in sourceFile.</
>>>>> xs:documentation>
>>>>> 		</xs:annotation>
>>>>> 		<xs:complexContent>
>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>> 				<xs:attribute name="number"
>>>>>           
> type="xs:int"
>   
>> use="required">
>>     
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>A
>>>>>           
> number for this
>   
>> acquisition.</
>>     
>>>>> xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 				<xs:attribute name="spectrumRef"
>>>>>           
> type="xs:string"
>   
>>>>> use="required">
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>This
>>>>>           
> attribute must
>   
>> reference the 'id'
>>     
>>>>> attribute of the appropriate spectrum if found within an mzML
>>>>> file, or
>>>>> the native spectrum identifier in a raw file in another format. </
>>>>> xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 				<xs:attribute name="sourceFileRef"
>>>>>           
> type="xs:IDREF"
>   
>>>>> use="required">
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>This
>>>>>           
> attribute must
>   
>> reference the 'id'
>>     
>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>> present mzML file.</xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 			</xs:extension>
>>>>> 		</xs:complexContent>
>>>>> 	</xs:complexType>
>>>>>
>>>>> However, I am not sure if there are any use cases when both the
>>>>> summed
>>>>> spectrum and the original spectra are found in the same file. If
>>>>> not,
>>>>> the spectrumRef attribute should maybe be renamed to
>>>>> 'externalSpectrumID' or something else, since 'spectrumRef'
>>>>>           
> somehow
>   
>>>>> indicates that the spectrum is in the present file.
>>>>>
>>>>> If there is a need to reference spectra within the file the
>>>>> following
>>>>> may be an alternative (I think Darren proposed something similar):
>>>>>
>>>>> 	<xs:complexType name="AcquisitionType">
>>>>> 		<xs:annotation>
>>>>> 			<xs:documentation>Scan or acquisition from
>>>>>           
> original file
>   
>> used to
>>     
>>>>> create this peak list. Either a spectrumRef or an
>>>>>           
> externalSpectrumID
>   
>>>>> plus sourceFileRef should be given .</xs:documentation>
>>>>> 		</xs:annotation>
>>>>> 		<xs:complexContent>
>>>>> 			<xs:extension base="dx:ParamGroupType">
>>>>> 				<xs:attribute name="number"
>>>>>           
> type="xs:int"
>   
>> use="required">
>>     
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>A
>>>>>           
> number for this
>   
>> acquisition.</
>>     
>>>>> xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 				<xs:attribute name="spectrumRef"
>>>>>           
> type="xs:IDREF"
>   
>> use="optional">
>>     
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>This
>>>>>           
> attribute must
>   
>> reference the 'id'
>>     
>>>>> attribute of the appropriate spectrum. </xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 				<xs:attribute name="externalSpectrumID"
>>>>>           
>> type="xs:string"
>>     
>>>>> use="optional">
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>This
>>>>>           
> attribute must
>   
>> reference the 'id'
>>     
>>>>> attribute of the appropriate spectrum if found within an external
>>>>> mzML
>>>>> file, or the native spectrum identifier in a raw file in another
>>>>> format. </xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
>>>>> 					<xs:annotation>
>>>>> 						<xs:documentation>This
>>>>>           
> attribute must
>   
>> reference the 'id'
>>     
>>>>> attribute of the appropriate sourceFile. It can also refer to the
>>>>> present mzML file.</xs:documentation>
>>>>> 					</xs:annotation>
>>>>> 				</xs:attribute>
>>>>> 			</xs:extension>
>>>>> 		</xs:complexContent>
>>>>> 	</xs:complexType>
>>>>>
>>>>> So, main question: are there any use cases with the original scans
>>>>> and
>>>>> the summed spectrum in the same file, and is there in this case a
>>>>> need
>>>>> to distinguish clearly between external and internal referencing
>>>>> (second schema alternative)?
>>>>>
>>>>> A minor point is also that the documentation of the spectrum
>>>>> attribute
>>>>> nativeID should be updated to something like:
>>>>>
>>>>> The native identifier for the spectrum, used by the acquisition
>>>>> software. If the spectrum is reconstructed from more than one
>>>>> spectrum, the native identifier of the first acquisition in time
>>>>> should be used.
>>>>>
>>>>> Regards
>>>>>
>>>>> Fredrik
>>>>>
>>>>>
>>>>>           
>>>
>>>       
> ------------------------------------------------------------------------
>   
>> -
>>     
>>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>>> Don't miss this year's exciting event. There's still time to save
>>> $100.
>>> Use priority code J8TL2D2.
>>>
>>>       
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
> av
>   
>> aone
>>     
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>       
>>
>>     
> ------------------------------------------------------------------------
> -
>   
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save
>>     
> $100.
>   
>> Use priority code J8TL2D2.
>>
>>     
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
> av
>   
>> aone
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

Hi Fredrik and everyone, thank you for thinking about these last few
problems. It seems that there are several different ways in which one
might want to reference the source scans for a summed scan. Based on
what's been said so far, here are my thoughts and proposal. What do you
think?

Currently for acquisitionList we have (in XML/XSD hybrid):
---------------
<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
spectrumRef="xs:IDREF">
    <cvParam cvLabel="MS" (optional child of scan attribute)/>
  </acquisition>
  <acquisition number="xs:int" sourceFileRef="xs:IDREF"
spectrumRef="xs:IDREF">
</acquisitionList>
---------------

Frederik suggests spectrumRef -> xs:string
externalSpectrumID="xs:string"

This brought up the question of how would sourceFileRef reference itself
if everything were in the same file?

Rune points out that we want nativeID references, like for Waters:
  function1scan2, func1scan2, 1.2 or ....

Darren suggests:
  externalSpectrumID="URI"
  externalNativeID="xs:string"

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

So, I suggest something like this (in XML/XSD hybrid):

<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
(three possible options:)
  <acquisition spectrumRef="xs:IDREF">
  <acquisition nativeID="xs:string">
  <acquisition sourceFileRef="xs:IDREF" externalSpectrumID="xs:string">
  <acquisition 
</acquisitionList>

---

Example 1: (the current spectrum is a sum of two scans which are also
present in the current file as ids S57 and S58.)

<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
  <acquisition spectrumRef="S57">
  <acquisition spectrumRef="S58">
</acquisitionList>

---

Example 2: (the current spectrum is a sum of two scans which had
nativeIDs func1scan19 and func1scan20, the exact location of which
are not specifiable)

<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
  <acquisition nativeID="func1scan19">
  <acquisition nativeID="func1scan20">
</acquisitionList>

---

Example 3: (the current spectrum is a sum of two scans which are
explicitly referenced externally by a specific file previously
defined in the current document and with IDs in that other file)

<acquisitionList count="2">
  <cvParam cvLabel="MS" accession="MS:1000571" name="sum of spectra"/>
  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S57">
  <acquisition sourceFileRef="mzMLsF01" externalSpectrumID="S58">
</acquisitionList>

---

Also okay is 1+2:

  <acquisition spectrumRef="S57" nativeID="func1scan19">
  <acquisition spectrumRef="S58" nativeID="func1scan20">

---

Also okay is 2+3:

  <acquisition nativeID="func1scan19" sourceFileRef="mzMLsF01"
externalSpectrumID="S57">
  <acquisition nativeID="func1scan20" sourceFileRef="mzMLsF01"
externalSpectrumID="S58">

---

Thus, all four possible attributes are optional, and we would rely on
the sematic validator to enforce:

   spectrumRef alone
OR nativeID alone
OR spectrumRef AND nativeID
OR sourceFileRef AND externalSpectrumID
OR sourceFileRef AND externalSpectrumID AND nativeID

What do you think? A little unpleasant to have several different
options, but I don't see how we could practically exclude any of the
options.


As a related side note, Matt also asks if we can handle the case where
MS1 scans have been stripped out of a file, but the the MS2 scans still
need to say something useful about their precursor scan (IDREF not
possible).

I have not checked this, but we should spend some time thinking about
that once we have solved this problem.

Thanks,
Eric


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Darren Kessner
> Sent: Friday, May 02, 2008 9:13 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML
> 0.99.10
> 
> I think it's a bad idea to have a spectrumRef to a spectrum that isn't
> in the file.  We should be consistent in the use of internal
> references, all of which use IDREF so that dangling references can be
> caught during XML validation.
> 
> External references, including those to spectra that have been removed
> for space reasons, should be indicated specifically (e.g. with
> externalSpectrumID or externalNativeID) so that the reader (human or
> software) knows that they'll have to do some extra work to find the
> referent.
> 
> 
> Darren
> 
> 
> 
> On May 2, 2008, at 6:17 AM, Matt Chambers wrote:
> 
> > Perhaps we should follow the same logic of the spectrum element
> > itself,
> > where id is required but nativeID is optional. Thus, id is required
> > for
> > a spectrum reference and a reference to the nativeID would be
optional
> > (but recommended!). We can't use the same attribute to point to
either
> > id or nativeID because then it won't be known which is being
referred
> > to, unless I'm missing something in Fredrik's proposal.
> >
> > To deal with IDs that aren't in the file, I agree with Fredrik. Any
> > time
> > we have a reference that can be to a non-existent or external
element,
> > we can't use IDREF. We either need to switch to xlink (in which case
> > IDREF would probably still be ok) or fall back to string. However,
> > since
> > I think that acquisitions should be able to reference spectra in the
> > current file, we shouldn't change it to externalSpectrumID. We
should
> > just document that all spectrumRef and spectrumNativeID(Ref?)
> > attributes
> > may refer to a spectrum in the current file or in another one, and
in
> > the former case the spectrum might not actually be there (i.e. MSn
> > spectra referencing precursor spectra that have been stripped out to
> > conserve space).
> >
> > -Matt
> >
> >
> > Rune Schjellerup Philosof wrote:
> >> I think the format by which external file elements are reference
> >> should
> >> be defined.
> >> For instance, a reference to a Waters raw file, should that be
> >> function1scan2, func1scan2, 1.2 or ....
> >>
> >> --
> >> Rune
> >>
> >> Fredrik Levander wrote:
> >>
> >>> Hi All,
> >>>
> >>> There is an issue with the current mzML schema (0.99.10) when it
> >>> comes
> >>> to referencing the origin of acquisitions in an acquistionList of
> >>> summed spectra. In most cases the referenced spectra will not be
in
> >>> the current mzML file, and thus the spectrumRef cannot be of the
> >>> type
> >>> xs:IDREF, but should be xs:string to also cover references to
> >>> spectrum
> >>> IDs in other mzML files, or native IDs in vendor files.
> >>>
> >>> The following would cover both internal and external spectrum
> >>> referencing:
> >>>
> >>>
> >>> 	<xs:complexType name="AcquisitionType">
> >>> 		<xs:annotation>
> >>> 			<xs:documentation>Scan or acquisition from
original raw
> file used
> >>> to create this peak list, as specified in sourceFile.</
> >>> xs:documentation>
> >>> 		</xs:annotation>
> >>> 		<xs:complexContent>
> >>> 			<xs:extension base="dx:ParamGroupType">
> >>> 				<xs:attribute name="number"
type="xs:int"
> use="required">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>A
number for this
> acquisition.</
> >>> xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 				<xs:attribute name="spectrumRef"
type="xs:string"
> >>> use="required">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>This
attribute must
> reference the 'id'
> >>> attribute of the appropriate spectrum if found within an mzML
> >>> file, or
> >>> the native spectrum identifier in a raw file in another format. </
> >>> xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 				<xs:attribute name="sourceFileRef"
type="xs:IDREF"
> >>> use="required">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>This
attribute must
> reference the 'id'
> >>> attribute of the appropriate sourceFile. It can also refer to the
> >>> present mzML file.</xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 			</xs:extension>
> >>> 		</xs:complexContent>
> >>> 	</xs:complexType>
> >>>
> >>> However, I am not sure if there are any use cases when both the
> >>> summed
> >>> spectrum and the original spectra are found in the same file. If
> >>> not,
> >>> the spectrumRef attribute should maybe be renamed to
> >>> 'externalSpectrumID' or something else, since 'spectrumRef'
somehow
> >>> indicates that the spectrum is in the present file.
> >>>
> >>> If there is a need to reference spectra within the file the
> >>> following
> >>> may be an alternative (I think Darren proposed something similar):
> >>>
> >>> 	<xs:complexType name="AcquisitionType">
> >>> 		<xs:annotation>
> >>> 			<xs:documentation>Scan or acquisition from
original file
> used to
> >>> create this peak list. Either a spectrumRef or an
externalSpectrumID
> >>> plus sourceFileRef should be given .</xs:documentation>
> >>> 		</xs:annotation>
> >>> 		<xs:complexContent>
> >>> 			<xs:extension base="dx:ParamGroupType">
> >>> 				<xs:attribute name="number"
type="xs:int"
> use="required">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>A
number for this
> acquisition.</
> >>> xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 				<xs:attribute name="spectrumRef"
type="xs:IDREF"
> use="optional">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>This
attribute must
> reference the 'id'
> >>> attribute of the appropriate spectrum. </xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 				<xs:attribute name="externalSpectrumID"
> type="xs:string"
> >>> use="optional">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>This
attribute must
> reference the 'id'
> >>> attribute of the appropriate spectrum if found within an external
> >>> mzML
> >>> file, or the native spectrum identifier in a raw file in another
> >>> format. </xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
> >>> 					<xs:annotation>
> >>> 						<xs:documentation>This
attribute must
> reference the 'id'
> >>> attribute of the appropriate sourceFile. It can also refer to the
> >>> present mzML file.</xs:documentation>
> >>> 					</xs:annotation>
> >>> 				</xs:attribute>
> >>> 			</xs:extension>
> >>> 		</xs:complexContent>
> >>> 	</xs:complexType>
> >>>
> >>> So, main question: are there any use cases with the original scans
> >>> and
> >>> the summed spectrum in the same file, and is there in this case a
> >>> need
> >>> to distinguish clearly between external and internal referencing
> >>> (second schema alternative)?
> >>>
> >>> A minor point is also that the documentation of the spectrum
> >>> attribute
> >>> nativeID should be updated to something like:
> >>>
> >>> The native identifier for the spectrum, used by the acquisition
> >>> software. If the spectrum is reconstructed from more than one
> >>> spectrum, the native identifier of the first acquisition in time
> >>> should be used.
> >>>
> >>> Regards
> >>>
> >>> Fredrik
> >>>
> >>>
> >>
> >
> >
> >
------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save
> > $100.
> > Use priority code J8TL2D2.
> >
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
av
> aone
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save
$100.
> Use priority code J8TL2D2.
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
av
> aone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

[Darren K. <Dar...@cs...>]

I think it's a bad idea to have a spectrumRef to a spectrum that isn't  
in the file.  We should be consistent in the use of internal  
references, all of which use IDREF so that dangling references can be  
caught during XML validation.

External references, including those to spectra that have been removed  
for space reasons, should be indicated specifically (e.g. with  
externalSpectrumID or externalNativeID) so that the reader (human or  
software) knows that they'll have to do some extra work to find the  
referent.


Darren



On May 2, 2008, at 6:17 AM, Matt Chambers wrote:

> Perhaps we should follow the same logic of the spectrum element  
> itself,
> where id is required but nativeID is optional. Thus, id is required  
> for
> a spectrum reference and a reference to the nativeID would be optional
> (but recommended!). We can't use the same attribute to point to either
> id or nativeID because then it won't be known which is being referred
> to, unless I'm missing something in Fredrik's proposal.
>
> To deal with IDs that aren't in the file, I agree with Fredrik. Any  
> time
> we have a reference that can be to a non-existent or external element,
> we can't use IDREF. We either need to switch to xlink (in which case
> IDREF would probably still be ok) or fall back to string. However,  
> since
> I think that acquisitions should be able to reference spectra in the
> current file, we shouldn't change it to externalSpectrumID. We should
> just document that all spectrumRef and spectrumNativeID(Ref?)  
> attributes
> may refer to a spectrum in the current file or in another one, and in
> the former case the spectrum might not actually be there (i.e. MSn
> spectra referencing precursor spectra that have been stripped out to
> conserve space).
>
> -Matt
>
>
> Rune Schjellerup Philosof wrote:
>> I think the format by which external file elements are reference  
>> should
>> be defined.
>> For instance, a reference to a Waters raw file, should that be
>> function1scan2, func1scan2, 1.2 or ....
>>
>> --
>> Rune
>>
>> Fredrik Levander wrote:
>>
>>> Hi All,
>>>
>>> There is an issue with the current mzML schema (0.99.10) when it  
>>> comes
>>> to referencing the origin of acquisitions in an acquistionList of
>>> summed spectra. In most cases the referenced spectra will not be in
>>> the current mzML file, and thus the spectrumRef cannot be of the  
>>> type
>>> xs:IDREF, but should be xs:string to also cover references to  
>>> spectrum
>>> IDs in other mzML files, or native IDs in vendor files.
>>>
>>> The following would cover both internal and external spectrum
>>> referencing:
>>>
>>>
>>> 	<xs:complexType name="AcquisitionType">
>>> 		<xs:annotation>
>>> 			<xs:documentation>Scan or acquisition from original raw file used
>>> to create this peak list, as specified in sourceFile.</ 
>>> xs:documentation>
>>> 		</xs:annotation>
>>> 		<xs:complexContent>
>>> 			<xs:extension base="dx:ParamGroupType">
>>> 				<xs:attribute name="number" type="xs:int" use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>A number for this acquisition.</
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="spectrumRef" type="xs:string"  
>>> use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum if found within an mzML  
>>> file, or
>>> the native spectrum identifier in a raw file in another format. </
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="sourceFileRef" type="xs:IDREF"  
>>> use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate sourceFile. It can also refer to the
>>> present mzML file.</xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 			</xs:extension>
>>> 		</xs:complexContent>
>>> 	</xs:complexType>
>>>
>>> However, I am not sure if there are any use cases when both the  
>>> summed
>>> spectrum and the original spectra are found in the same file. If  
>>> not,
>>> the spectrumRef attribute should maybe be renamed to
>>> 'externalSpectrumID' or something else, since 'spectrumRef' somehow
>>> indicates that the spectrum is in the present file.
>>>
>>> If there is a need to reference spectra within the file the  
>>> following
>>> may be an alternative (I think Darren proposed something similar):
>>>
>>> 	<xs:complexType name="AcquisitionType">
>>> 		<xs:annotation>
>>> 			<xs:documentation>Scan or acquisition from original file used to
>>> create this peak list. Either a spectrumRef or an externalSpectrumID
>>> plus sourceFileRef should be given .</xs:documentation>
>>> 		</xs:annotation>
>>> 		<xs:complexContent>
>>> 			<xs:extension base="dx:ParamGroupType">
>>> 				<xs:attribute name="number" type="xs:int" use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>A number for this acquisition.</
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="spectrumRef" type="xs:IDREF" use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum. </xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="externalSpectrumID" type="xs:string"
>>> use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum if found within an external  
>>> mzML
>>> file, or the native spectrum identifier in a raw file in another
>>> format. </xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate sourceFile. It can also refer to the
>>> present mzML file.</xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 			</xs:extension>
>>> 		</xs:complexContent>
>>> 	</xs:complexType>
>>>
>>> So, main question: are there any use cases with the original scans  
>>> and
>>> the summed spectrum in the same file, and is there in this case a  
>>> need
>>> to distinguish clearly between external and internal referencing
>>> (second schema alternative)?
>>>
>>> A minor point is also that the documentation of the spectrum  
>>> attribute
>>> nativeID should be updated to something like:
>>>
>>> The native identifier for the spectrum, used by the acquisition
>>> software. If the spectrum is reconstructed from more than one
>>> spectrum, the native identifier of the first acquisition in time
>>> should be used.
>>>
>>> Regards
>>>
>>> Fredrik
>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

Perhaps we should follow the same logic of the spectrum element itself, 
where id is required but nativeID is optional. Thus, id is required for 
a spectrum reference and a reference to the nativeID would be optional 
(but recommended!). We can't use the same attribute to point to either 
id or nativeID because then it won't be known which is being referred 
to, unless I'm missing something in Fredrik's proposal.

To deal with IDs that aren't in the file, I agree with Fredrik. Any time 
we have a reference that can be to a non-existent or external element, 
we can't use IDREF. We either need to switch to xlink (in which case 
IDREF would probably still be ok) or fall back to string. However, since 
I think that acquisitions should be able to reference spectra in the 
current file, we shouldn't change it to externalSpectrumID. We should 
just document that all spectrumRef and spectrumNativeID(Ref?) attributes 
may refer to a spectrum in the current file or in another one, and in 
the former case the spectrum might not actually be there (i.e. MSn 
spectra referencing precursor spectra that have been stripped out to 
conserve space).

-Matt


Rune Schjellerup Philosof wrote:
> I think the format by which external file elements are reference should 
> be defined.
> For instance, a reference to a Waters raw file, should that be 
> function1scan2, func1scan2, 1.2 or ....
>
> --
> Rune
>
> Fredrik Levander wrote:
>   
>> Hi All,
>>
>> There is an issue with the current mzML schema (0.99.10) when it comes  
>> to referencing the origin of acquisitions in an acquistionList of  
>> summed spectra. In most cases the referenced spectra will not be in  
>> the current mzML file, and thus the spectrumRef cannot be of the type  
>> xs:IDREF, but should be xs:string to also cover references to spectrum  
>> IDs in other mzML files, or native IDs in vendor files.
>>
>> The following would cover both internal and external spectrum  
>> referencing:
>>
>>
>> 	<xs:complexType name="AcquisitionType">
>> 		<xs:annotation>
>> 			<xs:documentation>Scan or acquisition from original raw file used  
>> to create this peak list, as specified in sourceFile.</xs:documentation>
>> 		</xs:annotation>
>> 		<xs:complexContent>
>> 			<xs:extension base="dx:ParamGroupType">
>> 				<xs:attribute name="number" type="xs:int" use="required">
>> 					<xs:annotation>
>> 						<xs:documentation>A number for this acquisition.</ 
>> xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 				<xs:attribute name="spectrumRef" type="xs:string" use="required">
>> 					<xs:annotation>
>> 						<xs:documentation>This attribute must reference the 'id'  
>> attribute of the appropriate spectrum if found within an mzML file, or  
>> the native spectrum identifier in a raw file in another format. </ 
>> xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 				<xs:attribute name="sourceFileRef" type="xs:IDREF" use="required">
>> 					<xs:annotation>
>> 						<xs:documentation>This attribute must reference the 'id'  
>> attribute of the appropriate sourceFile. It can also refer to the  
>> present mzML file.</xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 			</xs:extension>
>> 		</xs:complexContent>
>> 	</xs:complexType>
>>
>> However, I am not sure if there are any use cases when both the summed  
>> spectrum and the original spectra are found in the same file. If not,  
>> the spectrumRef attribute should maybe be renamed to  
>> 'externalSpectrumID' or something else, since 'spectrumRef' somehow  
>> indicates that the spectrum is in the present file.
>>
>> If there is a need to reference spectra within the file the following  
>> may be an alternative (I think Darren proposed something similar):
>>
>> 	<xs:complexType name="AcquisitionType">
>> 		<xs:annotation>
>> 			<xs:documentation>Scan or acquisition from original file used to  
>> create this peak list. Either a spectrumRef or an externalSpectrumID  
>> plus sourceFileRef should be given .</xs:documentation>
>> 		</xs:annotation>
>> 		<xs:complexContent>
>> 			<xs:extension base="dx:ParamGroupType">
>> 				<xs:attribute name="number" type="xs:int" use="required">
>> 					<xs:annotation>
>> 						<xs:documentation>A number for this acquisition.</ 
>> xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 				<xs:attribute name="spectrumRef" type="xs:IDREF" use="optional">
>> 					<xs:annotation>
>> 						<xs:documentation>This attribute must reference the 'id'  
>> attribute of the appropriate spectrum. </xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 				<xs:attribute name="externalSpectrumID" type="xs:string"  
>> use="optional">
>> 					<xs:annotation>
>> 						<xs:documentation>This attribute must reference the 'id'  
>> attribute of the appropriate spectrum if found within an external mzML  
>> file, or the native spectrum identifier in a raw file in another  
>> format. </xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
>> 					<xs:annotation>
>> 						<xs:documentation>This attribute must reference the 'id'  
>> attribute of the appropriate sourceFile. It can also refer to the  
>> present mzML file.</xs:documentation>
>> 					</xs:annotation>
>> 				</xs:attribute>
>> 			</xs:extension>
>> 		</xs:complexContent>
>> 	</xs:complexType>
>>
>> So, main question: are there any use cases with the original scans and  
>> the summed spectrum in the same file, and is there in this case a need  
>> to distinguish clearly between external and internal referencing  
>> (second schema alternative)?
>>
>> A minor point is also that the documentation of the spectrum attribute  
>> nativeID should be updated to something like:
>>
>> The native identifier for the spectrum, used by the acquisition  
>> software. If the spectrum is reconstructed from more than one  
>> spectrum, the native identifier of the first acquisition in time  
>> should be used.
>>
>> Regards
>>
>> Fredrik
>>
>>     
>

Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

I think the format by which external file elements are reference should 
be defined.
For instance, a reference to a Waters raw file, should that be 
function1scan2, func1scan2, 1.2 or ....

--
Rune

Fredrik Levander wrote:
>
> Hi All,
>
> There is an issue with the current mzML schema (0.99.10) when it comes  
> to referencing the origin of acquisitions in an acquistionList of  
> summed spectra. In most cases the referenced spectra will not be in  
> the current mzML file, and thus the spectrumRef cannot be of the type  
> xs:IDREF, but should be xs:string to also cover references to spectrum  
> IDs in other mzML files, or native IDs in vendor files.
>
> The following would cover both internal and external spectrum  
> referencing:
>
>
> 	<xs:complexType name="AcquisitionType">
> 		<xs:annotation>
> 			<xs:documentation>Scan or acquisition from original raw file used  
> to create this peak list, as specified in sourceFile.</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexContent>
> 			<xs:extension base="dx:ParamGroupType">
> 				<xs:attribute name="number" type="xs:int" use="required">
> 					<xs:annotation>
> 						<xs:documentation>A number for this acquisition.</ 
> xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 				<xs:attribute name="spectrumRef" type="xs:string" use="required">
> 					<xs:annotation>
> 						<xs:documentation>This attribute must reference the 'id'  
> attribute of the appropriate spectrum if found within an mzML file, or  
> the native spectrum identifier in a raw file in another format. </ 
> xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 				<xs:attribute name="sourceFileRef" type="xs:IDREF" use="required">
> 					<xs:annotation>
> 						<xs:documentation>This attribute must reference the 'id'  
> attribute of the appropriate sourceFile. It can also refer to the  
> present mzML file.</xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 			</xs:extension>
> 		</xs:complexContent>
> 	</xs:complexType>
>
> However, I am not sure if there are any use cases when both the summed  
> spectrum and the original spectra are found in the same file. If not,  
> the spectrumRef attribute should maybe be renamed to  
> 'externalSpectrumID' or something else, since 'spectrumRef' somehow  
> indicates that the spectrum is in the present file.
>
> If there is a need to reference spectra within the file the following  
> may be an alternative (I think Darren proposed something similar):
>
> 	<xs:complexType name="AcquisitionType">
> 		<xs:annotation>
> 			<xs:documentation>Scan or acquisition from original file used to  
> create this peak list. Either a spectrumRef or an externalSpectrumID  
> plus sourceFileRef should be given .</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexContent>
> 			<xs:extension base="dx:ParamGroupType">
> 				<xs:attribute name="number" type="xs:int" use="required">
> 					<xs:annotation>
> 						<xs:documentation>A number for this acquisition.</ 
> xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 				<xs:attribute name="spectrumRef" type="xs:IDREF" use="optional">
> 					<xs:annotation>
> 						<xs:documentation>This attribute must reference the 'id'  
> attribute of the appropriate spectrum. </xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 				<xs:attribute name="externalSpectrumID" type="xs:string"  
> use="optional">
> 					<xs:annotation>
> 						<xs:documentation>This attribute must reference the 'id'  
> attribute of the appropriate spectrum if found within an external mzML  
> file, or the native spectrum identifier in a raw file in another  
> format. </xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
> 					<xs:annotation>
> 						<xs:documentation>This attribute must reference the 'id'  
> attribute of the appropriate sourceFile. It can also refer to the  
> present mzML file.</xs:documentation>
> 					</xs:annotation>
> 				</xs:attribute>
> 			</xs:extension>
> 		</xs:complexContent>
> 	</xs:complexType>
>
> So, main question: are there any use cases with the original scans and  
> the summed spectrum in the same file, and is there in this case a need  
> to distinguish clearly between external and internal referencing  
> (second schema alternative)?
>
> A minor point is also that the documentation of the spectrum attribute  
> nativeID should be updated to something like:
>
> The native identifier for the spectrum, used by the acquisition  
> software. If the spectrum is reconstructed from more than one  
> spectrum, the native identifier of the first acquisition in time  
> should be used.
>
> Regards
>
> Fredrik
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

[Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

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

>

Hi All,

There is an issue with the current mzML schema (0.99.10) when it comes  
to referencing the origin of acquisitions in an acquistionList of  
summed spectra. In most cases the referenced spectra will not be in  
the current mzML file, and thus the spectrumRef cannot be of the type  
xs:IDREF, but should be xs:string to also cover references to spectrum  
IDs in other mzML files, or native IDs in vendor files.

The following would cover both internal and external spectrum  
referencing:


	<xs:complexType name="AcquisitionType">
		<xs:annotation>
			<xs:documentation>Scan or acquisition from original raw file used  
to create this peak list, as specified in sourceFile.</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="dx:ParamGroupType">
				<xs:attribute name="number" type="xs:int" use="required">
					<xs:annotation>
						<xs:documentation>A number for this acquisition.</ 
xs:documentation>
					</xs:annotation>
				</xs:attribute>
				<xs:attribute name="spectrumRef" type="xs:string" use="required">
					<xs:annotation>
						<xs:documentation>This attribute must reference the 'id'  
attribute of the appropriate spectrum if found within an mzML file, or  
the native spectrum identifier in a raw file in another format. </ 
xs:documentation>
					</xs:annotation>
				</xs:attribute>
				<xs:attribute name="sourceFileRef" type="xs:IDREF" use="required">
					<xs:annotation>
						<xs:documentation>This attribute must reference the 'id'  
attribute of the appropriate sourceFile. It can also refer to the  
present mzML file.</xs:documentation>
					</xs:annotation>
				</xs:attribute>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

However, I am not sure if there are any use cases when both the summed  
spectrum and the original spectra are found in the same file. If not,  
the spectrumRef attribute should maybe be renamed to  
'externalSpectrumID' or something else, since 'spectrumRef' somehow  
indicates that the spectrum is in the present file.

If there is a need to reference spectra within the file the following  
may be an alternative (I think Darren proposed something similar):

	<xs:complexType name="AcquisitionType">
		<xs:annotation>
			<xs:documentation>Scan or acquisition from original file used to  
create this peak list. Either a spectrumRef or an externalSpectrumID  
plus sourceFileRef should be given .</xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:extension base="dx:ParamGroupType">
				<xs:attribute name="number" type="xs:int" use="required">
					<xs:annotation>
						<xs:documentation>A number for this acquisition.</ 
xs:documentation>
					</xs:annotation>
				</xs:attribute>
				<xs:attribute name="spectrumRef" type="xs:IDREF" use="optional">
					<xs:annotation>
						<xs:documentation>This attribute must reference the 'id'  
attribute of the appropriate spectrum. </xs:documentation>
					</xs:annotation>
				</xs:attribute>
				<xs:attribute name="externalSpectrumID" type="xs:string"  
use="optional">
					<xs:annotation>
						<xs:documentation>This attribute must reference the 'id'  
attribute of the appropriate spectrum if found within an external mzML  
file, or the native spectrum identifier in a raw file in another  
format. </xs:documentation>
					</xs:annotation>
				</xs:attribute>
<xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
					<xs:annotation>
						<xs:documentation>This attribute must reference the 'id'  
attribute of the appropriate sourceFile. It can also refer to the  
present mzML file.</xs:documentation>
					</xs:annotation>
				</xs:attribute>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

So, main question: are there any use cases with the original scans and  
the summed spectrum in the same file, and is there in this case a need  
to distinguish clearly between external and internal referencing  
(second schema alternative)?

A minor point is also that the documentation of the spectrum attribute  
nativeID should be updated to something like:

The native identifier for the spectrum, used by the acquisition  
software. If the spectrum is reconstructed from more than one  
spectrum, the native identifier of the first acquisition in time  
should be used.

Regards

Fredrik

[Psidev-ms-dev] New schema iteration commited to CVS, along with two example instance documents

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

Dear PSI-MS Enthousiasts,


I have just committed a new mzML schema iteration (0.99.10) to CVS, 
along with two updated instance documents. Nothing very drastic, and 
most existing instance documents probably wouldn't notice the changes.


Change log:
  - SourceFileListRef in acquisitionSettings
	+ Introduced sourceFileRefs instead of the list of sourceFiles
  - Recursive referenceableParamGroup
	+ Removed recursiveness
  - UserParam
	+ added optional unit and unitaccession
	+ type should be used for 'datatype' -- added documentation to indicate 
this.
	+ type and value are now optional
  - Updated some schema documentation things highlighted by Eric


Files:

mzML
    - schema
	+ mzML0.99.10.xsd
         + mzML0.99.10_idx.xsd
    - instanceFile
         + tiny.msdata.mzML0.99.10.mzML
         + tiny.pwiz.mzML0.99.10.mzML


Have fun!


Cheers,

lnnrt.

Re: [Psidev-ms-dev] userParam attributes

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eric and Others with User Param interest, <br>
<br>
The 'type' attribute is clearly a bit confusing, I thought of it like
the 'category' you've been discussing.<br>
The user params are useful for capturing information instead of just
throwing it away, so I think they should be rather free form since
these parameters will probably not be used by software. For example,
when converting files from ProteinLynx Global Server to mzML&nbsp; we've
used the&nbsp; userParams to capture software settings that one would like
to keep, but where there is no perfectly matching CV term:<br>
&nbsp;<font face="Courier New, Courier, monospace" size="-2">&lt;dataProcessing
id="PLGS_processing" softwareRef="PLGS"&gt;<br>
&nbsp;&nbsp; &nbsp;&nbsp; &lt;processingMethod order="1"&gt;<br>
&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;userParam name="Level 0 BACKGROUND_SUBTRACT BELOW_CURVE"
type="data processing action" value="35.0"/&gt;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="Level 0 BACKGROUND_SUBTRACT
POLYNOMIAL_ORDER" type="data processing action" value="5"/&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="Level 0 BACKGROUND_SUBTRACT TYPE"
type="data processing action" value="Adaptive"/&gt;<br>
</font>,etc.<br>
<br>
And similarily for multiple dta to mzML conversion:<br>
&nbsp;<tt><font size="-2"> &lt;dataProcessing id="Bioworks_processing"
softwareRef="Bioworks"&gt;<br>
&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;processingMethod order="1"&gt;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="group scan" type="data processing
parameter" value="100"/&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="min group count" type="data processing
parameter" value="1"/&gt;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="min ion threshold" type="data processing
parameter" value="15"/&gt;<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;userParam name="intensity threshold" type="data
processing parameter" value="5000"/&gt;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;userParam name="precursor tolerance" type="data
processing parameter" value="1.4000 amu"/&gt;</font></tt><br>
,etc.<br>
Note that the last parameter here also has a unit in the value field<span
 class="moz-smiley-s1"><span> :-) </span></span>.<br>
It would look better to have a separate unit attribute (or multiple
with cv accession etc), but it should definitely be optional.<br>
If 'type' means 'dataType', I would like to have it as optional too,
since it can be hard to determine whether a setting is xs:integer or
xs:float for example (no one would be happy to see xs:string
everywhere, even if it is always correct).<br>
<br>
I have no clear opinion on this one, in the examples above the
type(category) attributes could be left out without much loss, but I
think they make the parameters slightly more accessible.<br>
I can't think of a user param without value, only if the value is
included in the name:<br>
<tt><font size="-2">&lt;userParam name="group scan=100"/&gt;</font></tt><br>
<br>
Actually, to add more confusion:<br>
It would also be possible to switch the 'name' and 'type' attributes in
the above examples: <br>
<tt><font size="-2">&lt;userParam name="</font></tt><tt><font size="-2">data
processing parameter" </font></tt><tt><font size="-2">type="</font></tt><tt><font
 size="-2">group scan"</font></tt><tt><font size="-2"> value="100"/&gt;</font></tt><br>
<br>
Opinions on this?<br>
<br>
Cheers<br>
<br>
Fredrik<br>
<br>
<br>
Eric Deutsch skrev:
<blockquote
 cite="mid:5BE...@he..."
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo7;
	font-size:16.0pt;
	font-family:Arial;}
h3
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:1.0in;
	text-indent:0in;
	page-break-after:avoid;
	mso-list:l0 level3 lfo7;
	font-size:12.0pt;
	font-family:Arial;}
h4
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:1.5in;
	text-indent:0in;
	page-break-after:avoid;
	mso-list:l0 level4 lfo7;
	font-size:14.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:346298316;
	mso-list-template-ids:67698727;}
@list l0:level1
	{mso-level-number-format:roman-upper;
	mso-level-style-link:"Heading 1";
	mso-level-tab-stop:.25in;
	mso-level-number-position:left;
	margin-left:0in;
	text-indent:0in;}
@list l0:level2
	{mso-level-number-format:alpha-upper;
	mso-level-tab-stop:.75in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:0in;}
@list l0:level3
	{mso-level-style-link:"Heading 3";
	mso-level-tab-stop:1.25in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:0in;}
@list l0:level4
	{mso-level-number-format:alpha-lower;
	mso-level-style-link:"Heading 4";
	mso-level-text:"%4\)";
	mso-level-tab-stop:1.75in;
	mso-level-number-position:left;
	margin-left:1.5in;
	text-indent:0in;}
@list l0:level5
	{mso-level-text:"\(%5\)";
	mso-level-tab-stop:2.25in;
	mso-level-number-position:left;
	margin-left:2.0in;
	text-indent:0in;}
@list l0:level6
	{mso-level-number-format:alpha-lower;
	mso-level-text:"\(%6\)";
	mso-level-tab-stop:2.75in;
	mso-level-number-position:left;
	margin-left:2.5in;
	text-indent:0in;}
@list l0:level7
	{mso-level-number-format:roman-lower;
	mso-level-text:"\(%7\)";
	mso-level-tab-stop:3.25in;
	mso-level-number-position:left;
	margin-left:3.0in;
	text-indent:0in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-text:"\(%8\)";
	mso-level-tab-stop:3.75in;
	mso-level-number-position:left;
	margin-left:3.5in;
	text-indent:0in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-text:"\(%9\)";
	mso-level-tab-stop:4.25in;
	mso-level-number-position:left;
	margin-left:4.0in;
	text-indent:0in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
  </style>
  <div class="Section1">
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">Hi everyone,
my own summary and thoughts
on the userParam issue:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">My first
question is: what are these
userParams supposed to look like anyway? There don&#8217;t seem to be any
good
examples of use of this (except for something about cats, which I don&#8217;t
understand). We should definitely fix that and get some example
userParams in
the example docs. I always thought userParam was supposed to look like
this:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">&lt;userParam
name=&#8221;ReAdW quality score&#8221;
value=&#8221;0.94&#8221; type=&#8221;xs:float&#8221;&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">What would
be a good example of a userParam
without a value?<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">&lt;userParam
name=&#8221;rejected&#8221;&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">? I kind of
like the idea of requiring a
value and a type. Seems like we&#8217;d get more useful userParams. We argued
for
quite a while about whether to include a &#8220;category&#8221; like thing in
cvParam, and
concluded &#8220;no&#8221; because it is implicit in the CV. For a userParam, there
is no CV,
and so it seems natural to use the name attribute as a kind of
category, which
is then qualified by the value. Instead of the above, I&#8217;d rather see:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">&lt;userParam
name=&#8221;MSFilter spectrum inclusion
flag&#8221; value=&#8221;rejected&#8221; type=&#8221;xs:string&#8221;&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">Regarding
adding optional units, I like
the idea. We want something like:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">&lt;userParam
name=&#8221;LTQ cycle delay time&#8221;
value=&#8221;0.00012&#8221; type=&#8221;xs:float&#8221; unitAccession="MS:1000038"
unitName="minute"/&gt;<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">? (adjusted
by the impending change to the
unit ontology)<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">Maybe I&#8217;m
confused because type doesn&#8217;t
mean datatype, but rather category?<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">We need
quality examples!<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">Thanks,<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;">Eric<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial; color: navy;"><o:p>&nbsp;</o:p></span></font></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><font
 face="Times New Roman" size="3"><span style="font-size: 12pt;">
  <hr tabindex="-1" align="center" size="2" width="100%"></span></font></div>
  <p class="MsoNormal"><b><font face="Tahoma" size="2"><span
 style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font
 face="Tahoma" size="2"><span
 style="font-size: 10pt; font-family: Tahoma;">
<a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:psi...@li...">mailto:psi...@li...</a>] <b><span
 style="font-weight: bold;">On Behalf Of </span></b>Darren Kessner<br>
  <b><span style="font-weight: bold;">Sent:</span></b> Monday, April
28, 2008 8:47
AM<br>
  <b><span style="font-weight: bold;">To:</span></b> Mass spectrometry
standard
development<br>
  <b><span style="font-weight: bold;">Subject:</span></b> Re:
[Psidev-ms-dev]
Update from the PSI meeting</span></font><o:p></o:p></p>
  </div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">I think it's a good idea to add a units
attribute to CVParam --
actually, I just noticed it was missing on Sunday when I was working on
the
latest example file. &nbsp;I agree that everything other than "name"
should be optional.<o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">Regarding data type -- I believe Lennart was
finalizing how it will be
encoded in the terms in the OBO file, but there wasn't much discussion
about
how it will be validated. &nbsp;It seems that data types could be validated
during semantic validation though. &nbsp;<o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">In pwiz I'm planning to use the type info to
validate casts at compile
time.<o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">Darren<o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  </div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
  <div>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">On Apr 28, 2008, at 8:05 AM, Randy Julian
wrote:<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><br>
  <br>
  <o:p></o:p></span></font></p>
  <span style="orphans: 2; widows: 2; word-spacing: 0px;">
  <div link="blue" vlink="purple">
  <div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">Good
catch Andy,<u1:p></u1:p></span></font><font color="black"><span
 style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">I
don&#8217;t see why the
value is a required attribute. &nbsp;The idea of userParam is that it is
just
like cvParam, expect the names and values are uncontrolled.<u1:p></u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">I
think we need the
units in the userParam too.&nbsp; This raises the question of data type in
both
elements.<u1:p></u1:p></span></font><font color="black"><span
 style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">In
userParam we have
a data type field explicitly:<u1:p></u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div><span style="">
  <p class="MsoNormal"><font color="blue" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&lt;</span></font></p>
  </span><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:complexType</span></span></font><span
 class="apple-converted-space"><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">name</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">UserParamType</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p></span><o:p></o:p></font>
  <span style=""></span></div>
  <div><span style="">
  <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
 class="apple-converted-space">&nbsp;</span></span></font></p>
  </span><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&lt;</span></span></font><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:attribute</span></span></font><span
 class="apple-converted-space"><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">name</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">name</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">type</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:string</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">use</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">required</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"/&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p></span><o:p></o:p></font>
  <span style=""></span></div>
  <div><span style="">
  <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
 class="apple-converted-space">&nbsp;</span></span></font></p>
  </span><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&lt;</span></span></font><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:attribute</span></span></font><span
 class="apple-converted-space"><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">name</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">type</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">type</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:string</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"
/&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p></span><o:p></o:p></font>
  <span style=""></span></div>
  <div><span style="">
  <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
 class="apple-converted-space">&nbsp;</span></span></font></p>
  </span><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&lt;</span></span></font><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:attribute</span></span></font><span
 class="apple-converted-space"><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">name</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">value</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">type</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:string</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"
/&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p></span><o:p></o:p></font>
  <span style=""></span></div>
  <div><span style="">
  <p class="MsoNormal"><font color="black" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
 class="apple-converted-space">&nbsp;</span></span></font></p>
  </span><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&lt;</span></span></font><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:attribute</span></span></font><span
 class="apple-converted-space"><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">name</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">unitName</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">type</span></font><font
 color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">="</span></span></font><font color="black"><span
 style="background: white none repeat scroll 0%; color: black; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:string</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">"</span></span></font><span class="apple-converted-space"><font
 color="red"><span
 style="background: white none repeat scroll 0%; color: red; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&nbsp;</span></span></font></span><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">/&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p></span><o:p></o:p></font>
  <span style=""></span></div>
  <div><span style="">
  <p class="MsoNormal"><font color="blue" face="Times New Roman"
 size="3"><span
 style="background: white none repeat scroll 0%; font-size: 12pt; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">&lt;/</span></font></p>
  </span><font color="maroon"><span
 style="background: white none repeat scroll 0%; color: maroon; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">xs:complexType</span></span></font><font color="blue"><span
 style="background: white none repeat scroll 0%; color: blue; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;"><span
 style="">&gt;</span></span></font><font color="black"><span
 style="color: black;"><u1:p></u1:p><o:p></o:p></span></font>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">Is
everyone OK with
adding unitName to the userParam as an optional attribute, and changing
the
other attributes (except name) to optional?<u1:p></u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">Also,
I must have
missed the data type discussion &#8211; are we adding something somewhere for
data
type validation?<u1:p></u1:p></span></font><font color="black"><span
 style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">Thanks,<u1:p></u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);">Randy<u1:p></u1:p></span></font><font
 color="black"><span style="color: black;"><o:p></o:p></span></font></p>
  </div>
  <div>
  <p class="MsoNormal"><font color="#1f497d" face="Calibri" size="2"><span
 style="font-size: 11pt; font-family: Calibri; color: rgb(31, 73, 125);"><u1:p>&nbsp;</u1:p></span></font></p>
  </div>
  </div>
  </div>
  </span></div>
  </div>
  </div>
</blockquote>
<br>
</body>
</html>

[Psidev-ms-dev] Minutes from PSI-MSS WG call

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

Hi everyone, here are the minutes from today's call. Please let me know
if there are any errors or omissions. See the action items with your
name on them. The next call will be in one week at the same time. We
will discuss the progress made during the week.

 

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

 

Agenda:

 

- Problem of two <sourceFileList> places

+Yes, just go to one sourceFileList in fileDescription

- recursive referenceableParamGroup

+Remove recursive possibilities

- userParam required value and type attributes

+Make value and type optional. Create some examples showing that type is
a datatype

+Add optional unitName and unitAccession

- How will we organize CV editing?

+Take off line with main CV coordinators

- Use db_xref to add datatype and needs_units. Who will? Maybe Darren?

+Lennart will update validator to handle this

+Darren will update the CV for the datatypes and needs_units

- Lennart will release schema 0.99.10

+Yes will do.

- New mailing list psidev-ms-vocab for sending term (change) requests

+Good.

+ - Issue of what to call an Orbi & FT

+Primary term name: inductive detector (exact syn: image current
detector)

+In LTQ-FT or Orbi examples make the detectors: inductive detector

- Needed example files

 

- Example instance documents:

  - MIAPE-MS compliant example

+Pierre-Alain and Darren will finish this by next week, by making
ProteoWizard generate a MIAPE-MS compliant file

  - Working examples that include compressed spectra

+Matt or Darren will do this

  - Get an example 4700 file. How to encode the sourceFile for that?

+See if Sean Seymour will do this

  - MS^E example (I think Rune sent one out. Is it great?)

+See if Rune would do it

  - We need to develop a good MALDI example file with spot id refs

+Maybe part of 4700 example

  - We need to develop a good example of a file created from individual
dtas including examples to multiple possible charge states

+Frederik volunteered to do this within a week

  - We need to develop a good example of a file that contains summed
scans and acquisitionList

+Frederik volunteered do this within a week

  - Create an example of encoding a transient in an mzML file

+Jim will do this

- Get example than includes both PDA and MSn spectra in one file

+Jim will finish this and send out

  - Example that Rune suggests about lockspray reference scans (implying
multiple samples)

+Rune??

  - Create a metabolomics experiment example

+Jim has done 

 

Other items:

 

+Eric will populate the vocab list

+Add Jim and Pierre-Alain to the vocab list

 

+Add software to the vendor update request spreadsheets where possible

 

+Address two open entries in term tracker, and then disable the term
tracker

 

+Jim needs addition of PDA terms to CV

 

+Next call in exactly one week.  Lennart will not be there but will
arrange for someone at EBI to start the call.

 

 

 

________________________________

From: Eric Deutsch 
Sent: Tuesday, April 29, 2008 8:53 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: RE: PSI-MSS WG call tomorrow

 

Hi everyone, here's the agenda for the call coming up at the top of the
hour:

 

Agenda:

 

- Problem of two <sourceFileList> places

- recursive referenceableParamGroup

- userParam required value and type attributes

- How will we organize CV editing?

- Use db_xref to add data_type and hasUnits. Who will? Maybe Darren?

- Lennart will release schema 0.99.10

- New mailing list psidev-ms-vocab for sending term (change) requests

- Needed example files

 

- Example instance documents:

  - Workin examples that include compressed spectra

  - Get an example 4700 file. How to encode the sourceFile for that?

  - MS^E example (I think Rune sent one out. Is it great?)

  - We need to develop a good MALDI example file with spot id refs

  - We need to develop a good example of a file created from individual
dtas including examples to multiple possible charge states

  - We need to develop a good example of a file that contains summed
scans and acquisitionList

  - Create an example of encoding a transient in an mzML file

- Get example than includes both PDA and MSn spectra in one file

 

 

________________________________

From: Eric Deutsch 
Sent: Monday, April 28, 2008 3:10 PM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: PSI-MSS WG call tomorrow

 

Hi everyone, as previously mentioned, the PSI Mass Spectrometry
Standards Working Group call is tomorrow at 9am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=4&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 quickly review and discuss what remains to be done
after the workshop in the next month, and discuss some of the flurry of
emails since the workshop already.

 

Please attend!

 

Thanks,

Eric

 

 

 

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

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

Hi everyone, here's the agenda for the call coming up at the top of the
hour:

 

Agenda:

 

- Problem of two <sourceFileList> places

- recursive referenceableParamGroup

- userParam required value and type attributes

- How will we organize CV editing?

- Use db_xref to add data_type and hasUnits. Who will? Maybe Darren?

- Lennart will release schema 0.99.10

- New mailing list psidev-ms-vocab for sending term (change) requests

- Needed example files

 

- Example instance documents:

  - Workin examples that include compressed spectra

  - Get an example 4700 file. How to encode the sourceFile for that?

  - MS^E example (I think Rune sent one out. Is it great?)

  - We need to develop a good MALDI example file with spot id refs

  - We need to develop a good example of a file created from individual
dtas including examples to multiple possible charge states

  - We need to develop a good example of a file that contains summed
scans and acquisitionList

  - Create an example of encoding a transient in an mzML file

- Get example than includes both PDA and MSn spectra in one file

 

 

________________________________

From: Eric Deutsch 
Sent: Monday, April 28, 2008 3:10 PM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: PSI-MSS WG call tomorrow

 

Hi everyone, as previously mentioned, the PSI Mass Spectrometry
Standards Working Group call is tomorrow at 9am PDT:

 

http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=4&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 quickly review and discuss what remains to be done
after the workshop in the next month, and discuss some of the flurry of
emails since the workshop already.

 

Please attend!

 

Thanks,

Eric

 

 

 

Re: [Psidev-ms-dev] Update from the PSI meeting

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

Rune Schjellerup Philosof skrev:
> However, maybe the information below is not possible to store in either 
> format.
> For instance in each fragmentation scan the activation energy is 
> linearly increased in coordination with that the quadrupole is limiting 
> the mass range and move that range, so that low m/z ions get through 
> when the activation energy is low, and high m/z ions when the energy is 
> high.
>   

I just talked to a Waters guy again.
I don't think they move the range as described above, sorry for any 
confusion.

-
Rune

Re: [Psidev-ms-dev] CV terms

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

Does anyone have input to how locksprayer reference scans should be saved?
Some thoughts:
- It is actually a separate sample, is it supported to have multiple 
samples in mzML yet?
- If a separate sample is saved in the mzML then that sample could have 
the property of being a reference sample, possibly indicating the 
contents and the masses to be used for calibration.
- Those properties might also be saved in the instrument description, by 
the lockspray source, or in the scan description.

Rune Schjellerup Philosof skrev:
> Something needs to be added to be able to indicate that a scan is a 
> reference scan (locksprayer source for instance).
> I think either it should be noted in the instrument description or in 
> the specific scan somehow.
>   

[Psidev-ms-dev] mzML for centroided data

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

Hi

When the data stored is cenroided data, the charge states will probably 
be stored along with it.
Does the documentation specify how an unknown charge state must be 
indicated?

--
Rune

Re: [Psidev-ms-dev] Update from the PSI meeting

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

Eric Deutsch skrev:
> - MS^E example (I think Rune sent one out. Is it great?)
>   
I only sent out a mzData example to illustrate how the MS^E data, I am 
using, looks.
So a mzML example still needs to be made.

I think mzML is prepared for storing ms^e data. Probably more so than 
Waters own raw format.
It seems like there's some data that Waters doesn't store (like which 
instrument was used).

However, maybe the information below is not possible to store in either 
format.
For instance in each fragmentation scan the activation energy is 
linearly increased in coordination with that the quadrupole is limiting 
the mass range and move that range, so that low m/z ions get through 
when the activation energy is low, and high m/z ions when the energy is 
high.

--
Regards,
Rune