psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] Collision energy units for Thermo CID vs. HCD

[Karl <cl...@br...>]

Hi Matt,

I think it would be unwise to convert from % to eV and keep only the eV
value stored in the mzML file. The main reason is that the typical user of
Thermo instruments/data only knows the values expressed as % , even though
they may not know what units are in use.  So you I think you should update
the units to allow for percent or add a new cvParam that is for collision
energy in units of %.

When you say:
	>So basically, every collision energy cvParam ever written for a
Thermo mzML file has been wrong. :)
I think it is more accurate to say that the units of the cvParam have always
been erroneous for Thermo mzML's, the values have always been right.

Nonetheless it is interesting that one can now additionally extract the
value in units of eV from the scan header for HCD spectra.
	"HCD Energy eV:" line of the scan header  for QExactive instruments
	or the "HCD=" key/value pair of the "FT Analyzer Message:" line of
the scan header for Orbitrap Elite and Velos Orbitrap instruments.
For CID spectra collected at high resolution in the Orbitrap, the scan
header and scan filter still contain only the value in % units

--Karl



-----Original Message-----
From: Shofstahl, Jim [mailto:jim...@th...] 
Sent: Friday, January 25, 2013 2:01 PM
To: Matthew Chambers; psi...@li...
Subject: Re: [Psidev-ms-dev] Collision energy units for Thermo CID vs. HCD

Matt,

I will have to ask some of our hardware/firmware people since I don' t know
the answer at this moment.

Jim 

-----Original Message-----
From: Matthew Chambers [mailto:mat...@gm...]
Sent: Friday, January 25, 2013 10:58 AM
To: psi...@li...; Shofstahl, Jim
Subject: Collision energy units for Thermo CID vs. HCD

Hi all,

It's been brought to my attention that since the LCQ the collision energies
in the scan filter for Thermo CID instruments has not been reported in
electronvolts but as a percentage because it is in fact the "Normalized
Collision Energy(tm)" described here:
https://static.thermoscientific.com/images/D13507~.pdf

Right now EV is the only unit we allow for collision energy in the CV, but I
don't know of a way to convert from NCE to EV! So basically, every collision
energy cvParam ever written for a Thermo mzML file has been wrong. :)

Jim, do you know how to convert that percentage to EV, or is the conversion
formula proprietary? If it's feasible to convert I'd prefer to do that, but
otherwise we may have to add "percentage" to the allowed unit types of the
cvParam.

Newer "HCD" instruments on the other hand report the actual EV in a couple
different places (while still reporting the NCE in the scan filter): either
in the "HCD Energy eV:" line of the scan header or the "HCD=" key/value pair
of the "FT Analyzer Message:" line of the scan header.

Furthermore, I've seen stepped collision energies for HCD like
"HCD=24..44eV"; how should that be encoded in mzML?

-Matt

----------------------------------------------------------------------------
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC,
Windows 8 Apps, JavaScript and much more. Keep your skills current with
LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and
experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Collision energy units for Thermo CID vs. HCD

[Shofstahl, J. <jim...@th...>]

Matt,

I will have to ask some of our hardware/firmware people since I don' t know the answer at this moment.

Jim 

-----Original Message-----
From: Matthew Chambers [mailto:mat...@gm...] 
Sent: Friday, January 25, 2013 10:58 AM
To: psi...@li...; Shofstahl, Jim
Subject: Collision energy units for Thermo CID vs. HCD

Hi all,

It's been brought to my attention that since the LCQ the collision energies in the scan filter for Thermo CID instruments has not been reported in electronvolts but as a percentage because it is in fact the "Normalized Collision Energy(tm)" described here:
https://static.thermoscientific.com/images/D13507~.pdf

Right now EV is the only unit we allow for collision energy in the CV, but I don't know of a way to convert from NCE to EV! So basically, every collision energy cvParam ever written for a Thermo mzML file has been wrong. :)

Jim, do you know how to convert that percentage to EV, or is the conversion formula proprietary? If it's feasible to convert I'd prefer to do that, but otherwise we may have to add "percentage" to the allowed unit types of the cvParam.

Newer "HCD" instruments on the other hand report the actual EV in a couple different places (while still reporting the NCE in the scan filter): either in the "HCD Energy eV:" line of the scan header or the "HCD=" key/value pair of the "FT Analyzer Message:" line of the scan header.

Furthermore, I've seen stepped collision energies for HCD like "HCD=24..44eV"; how should that be encoded in mzML?

-Matt

[Psidev-ms-dev] Collision energy units for Thermo CID vs. HCD

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

Hi all,

It's been brought to my attention that since the LCQ the collision energies in the scan filter for 
Thermo CID instruments has not been reported in electronvolts but as a percentage because it is in 
fact the "Normalized Collision Energy(tm)" described here:
https://static.thermoscientific.com/images/D13507~.pdf

Right now EV is the only unit we allow for collision energy in the CV, but I don't know of a way to 
convert from NCE to EV! So basically, every collision energy cvParam ever written for a Thermo mzML 
file has been wrong. :)

Jim, do you know how to convert that percentage to EV, or is the conversion formula proprietary? If 
it's feasible to convert I'd prefer to do that, but otherwise we may have to add "percentage" to the 
allowed unit types of the cvParam.

Newer "HCD" instruments on the other hand report the actual EV in a couple different places (while 
still reporting the NCE in the scan filter): either in the "HCD Energy eV:" line of the scan header 
or the "HCD=" key/value pair of the "FT Analyzer Message:" line of the scan header.

Furthermore, I've seen stepped collision energies for HCD like "HCD=24..44eV"; how should that be 
encoded in mzML?

-Matt

[Psidev-ms-dev] PSI meeting preparations

[Jones, A. <And...@li...>]

Hi all,

It is clearly some way off but I want to start planning for the items we will work on at PSI 2013 (April 15th-17th in Liverpool). For certain areas we need to do some preliminary work so we are well prepared for modelling concepts, rather than just standing round a white-board without really knowing the area well.

On my radar are the following issues:


-          Modelling protein grouping more intuitively (mzid and mzq, possibly mzTab?)

o   Sean Seymour, Terry Farrah, myself and others have been working on this, so certainly we will have a good starting point

-          PTM localisation scoring (mzid, mzq, possibly mzTab)

o   Some work on this in the context of mzTab, but far from a definitive answer on how best to do this, especially for mzid

-          Data compression

o   mz5 - pros and cons; compression protocols/formats for idents and quants?

-          SRM support in mzQuantML

-          Various minor issues discovered in mzid, reported on the list etc

Possible longer term issues:

-          Data independent acquisition - modelled sufficiently in mzML?

-          Ion mobility

-          Top down proteomics

Eric - do you have additional things you want to work on?

I realise that with competing calls on time for people, it is difficult to get good preparation work done before the meeting. As such, I was hoping on several of these issues, we could aim to write a review paper or technical viewpoint covering the relevant area over the next few months, to be published shortly after the PSI meeting, with a nominated lead (and first author). What do people think?

Specifically:

-          Sean, Terry and myself are working on a protein grouping paper, which will be circulated more widely in due course.

-          I recently discovered a good review on PTM scoring by Robert Chalkley: http://www.mcponline.org/content/early/2012/02/11/mcp.R111.015305.full.pdf but perhaps we could have a volunteer to take a lead on discovery of how all the different scores could be encoded in a consistent schema, using cvParams, anyone interested?

-          Anyone want to volunteer to review current SRM software and output formats?

-          Same for data compression? Henning and I started looking at this issue for a grant application, so I would be happy to liaise with someone to lead the writing of something on this

-          Other ideas for relevant reviews which could lead into our efforts?

Cheers
Andy

[Psidev-ms-dev] New version 3.45.0 of psi-ms.obo

[Gerhard M. <Ger...@ru...>]

Sorry, there was a mistake in the last email. The definition is now: 
should be
def: "A putative identified peptide issued from a decoy sequence 
database." [PSI:PI]

[Term]
id: MS:1002217
name: decoy peptide
def: "A putative identified peptide issued from a decoy sequence 
database." [PSI:PI]
xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
is_a: MS:1001105 ! peptide result details

Best,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.049a
Universitätsstrasse 150
D-44801 Bochum
  
Phone:	+49(0)234/32-25999
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

[Psidev-ms-dev] New version 3.45.0 of psi-ms.obo releases

[Gerhard M. <Ger...@ru...>]

Dear proteomics community,

attached there's the release 3.45.0 of the psi-ms.obo file.
It adds the new term 'decoy peptide'

New CV terms in version 3.45.0 of psi-ms.obo:
=============================================
[Term]
id: MS:1002217
name: decoy peptide
def: "An identified peptide issued from a decoy sequence database." [PSI:PI]
xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
is_a: MS:1001105 ! peptide result details

Best Regards,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.049a
Universitätsstrasse 150
D-44801 Bochum
  
Phone:	+49(0)234/32-25999
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] [Psidev-ms-vocab] Release candidate 3.45.0_rc1 of psi-ms.obo

[Juan A. V. <ju...@eb...>]

Thanks a lot Gerhard.
It looks perfectly fine for me.

Cheers,

Juan



On 10 Jan 2013, at 07:08, Gerhard Mayer wrote:

> Dear proteomics community,
> 
> attached there's the release candidate 3.45.0_rc1 of the psi-ms.obo file.
> 
> Changed CV terms in version 3.45.0_rc1 of psi-ms.obo:
> =====================================================
> ************
> No changed terms
> 
> 
> New CV terms in version 3.45.0_rc1 of psi-ms.obo:
> =================================================
> [Term]
> id: MS:1002217
> name: decoy peptide
> def: "An identified peptide issued from a decoy sequence database." [PSI:PI]
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001105 ! peptide result details
> 
> Best Regards,
> Gerhard
> 
> -- 
> ---
> Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
> BioInformatik
> Medizinisches-Proteom-Center (MPC)
> Ruhr-Universität Bochum
> Zentrum für klinische Forschung I (ZKF I)
> E.043
> Universitätsstrasse 150
> D-44801 Bochum
> Phone:	+49(0)234/32-25999
> Fax:	+49(0)234/32-14554
> Email:	Ger...@ru...
> Web:	http://www.medizinisches-proteom-center.de
> 
> <psi-ms_3.45.0_rc1.obo.zip>------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712_______________________________________________
> Psidev-ms-vocab mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-vocab

[Psidev-ms-dev] Release candidate 3.45.0_rc1 of psi-ms.obo

[Gerhard M. <Ger...@ru...>]

Dear proteomics community,

attached there's the release candidate 3.45.0_rc1 of the psi-ms.obo file.

Changed CV terms in version 3.45.0_rc1 of psi-ms.obo:
=====================================================
************
No changed terms


New CV terms in version 3.45.0_rc1 of psi-ms.obo:
=================================================
[Term]
id: MS:1002217
name: decoy peptide
def: "An identified peptide issued from a decoy sequence database." [PSI:PI]
xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
is_a: MS:1001105 ! peptide result details

Best Regards,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.043
Universitätsstrasse 150
D-44801 Bochum
  
Phone:	+49(0)234/32-25999
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

[Psidev-ms-dev] New version 3.44.0 of psi-ms.obo

[Gerhard M. <Ger...@ru...>]

Dear proteomics community,

attached there's the version 3.44.0 of the psi-ms.obo file.
The terms for Gorka are now prefixed with PAnalyzer:

Changed CV terms in version 3.44.0 of psi-ms.obo:
=================================================
************ The name of the following 4 terms are now prefixed with 
PAnalyzer:
[Term]
id: MS:1002213
name: PAnalyzer:conclusive protein
def: "A protein identified by at least one unique (distinct, discrete) 
peptide (peptides are considered different only if they can be 
distinguished by evidence in mass spectrum)." [PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1001600 ! protein inference confidence category

[Term]
id: MS:1002214
name: PAnalyzer:indistinguishable protein
def: "A member of a group of proteins sharing all peptides that are 
exclusive to the group (peptides are considered different only if they 
can be distinguished by evidence in mass spectrum)." [PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1001600 ! protein inference confidence category

[Term]
id: MS:1002215
name: PAnalyzer:non-conclusive protein
def: "A protein sharing all its matched peptides with either conclusive 
or indistinguishable proteins (peptides are considered different only if 
they can be distinguished by evidence in mass spectrum)." [PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1001600 ! protein inference confidence category

[Term]
id: MS:1002216
name: PAnalyzer:ambiguous group member
def: "A protein sharing at least one peptide not matched to either 
conclusive or indistinguishable proteins (peptides are considered 
different only if they can be distinguished by evidence in mass 
spectrum)." [PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1001600 ! protein inference confidence category


Best Regards,
Gerhard

-- 
---
Dipl. Inform. med., Dipl. Wirtsch. Inf. Gerhard Mayer
BioInformatik
Medizinisches-Proteom-Center (MPC)
Ruhr-Universität Bochum
Zentrum für klinische Forschung I (ZKF I)
E.042
Universitätsstrasse 150
D-44801 Bochum
  
Phone:	+49(0)234/32-25999
Fax:	+49(0)234/32-14554
Email:	Ger...@ru...
Web:	http://www.medizinisches-proteom-center.de

Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files

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

Hi Eric,

Seems fine. The version attribute in the 1.1.2 xsd should be changed to 
1.1.2, though.
Can you deposit the xsd at 
http://psidev.info/files/ms/mzML/xsd/mzML1.1.2_idx.xsd once it is accepted?
And consequently change to 
xsi:schemaLocation="http://psi.hupo.org/ms/mzml 
http://psidev.info/files/ms/mzML/xsd/mzML1.1.2_idx.xsd" in the 
indexedmzML element of the example file.
I believe it will then be possible to validate the indexed example file 
based on the schema location.

Thanks,

Fredrik

On 2012-12-19 09:14, Eric Deutsch wrote:
>
> Hi everyone, attached is a zip of the changes that I propose. As Brian 
> suggests, all I did was to add a minOccurs="0", where an implied 
> minimum of 1 existed before.
>
> The major implications of this change for software implementers is:
>
> 1) There will now start to be references to a new wrapper schema 
> mzML1.1.2_idx.xsd in new mzMLs where there was not before
>
> 2) Parsers now need to be prepared to handle the possibility of an 
> <index> element with no subelements present. This was not legal before 
> (although that doesn't mean there weren't any files like that before 
> anyway)
>
> 3) Files that were valid before will still be valid
>
> @Matt: I also changed in the pwiz example files cvTerm "ProteoWizard" 
> to "ProteoWizard software" as per latest CV
>
> One final little change I made was to remove spaces in an xpath 
> (surrounding the | character). Xerces was complaining about it. We had 
> a long discussion about this long ago, and I can't recall if we agreed 
> they should not be there or if we though they should be there despite 
> Xerces not liking it. Complete diff of the xsd is:
>
> diff mzML1.1.1_idx.xsd mzML1.1.2_idx.xsd
>
> 26c26
>
> < <xs:element maxOccurs="unbounded" name="offset" type="dx:OffsetType">
>
> ---
>
> ><xs:element minOccurs="0" maxOccurs="unbounded" name="offset" 
> type="dx:OffsetType">
>
> 90c90
>
> < <xs:selector 
> xpath=".//dx:indexedmzML/dx:mzML/dx:run/dx:spectrumList/dx:spectrum | 
> .//dx:indexedmzML/dx:mzML/dx:run/dx:chromatogramList/dx:chromatogram" />
>
> ---
>
> ><xs:selector 
> xpath=".//dx:indexedmzML/dx:mzML/dx:run/dx:spectrumList/dx:spectrum|.//dx:indexedmzML/dx:mzML/dx:run/dx:chromatogramList/dx:chromatogram" 
> />
>
> 98c98
>
> < </xs:schema>
>
> \ No newline at end of file
>
> ---
>
> > </xs:schema>
>
> Comments before we commit this?
>
> Thanks,
>
> Eric
>
> *From:*Brian Pratt [mailto:bri...@in... 
> <mailto:bri...@in...>]
> *Sent:* Tuesday, December 18, 2012 7:28 PM
> *To:* pro...@li... 
> <mailto:pro...@li...>
> *Cc:* Mass spectrometry standard development
> *Subject:* Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files
>
> The first option is already very nearly legal, except that the lower 
> limit for element count in <index> is unspecified and so defaults to 
> 1.  So that would be a pretty small change to the schema.
>
> On Tue, Dec 18, 2012 at 5:30 PM, Eric Deutsch 
> <ede...@sy... <mailto:ede...@sy...>> wrote:
>
> I haven't gotten to make the schema changes yet, got derailed on other 
> things, but still hope to get to it tonight. I would also advocate the 
> first option. I think we have a general policy for PSI formats 
> "xxxxxList elements shall not be empty". I don't know if it's engraved 
> anywhere, but was a policy we tried to carry through. If there's a 
> xxxxxList element, there better be something in it, or else, leave it 
> out. So I would rather implement it with an empty <index>. Clearly not 
> an obvious conclusion, but at least a precedent to guide the decision.
>
> Additional comments?
>
> Thanks,
>
> Eric
>
> *From:*Brian Pratt [mailto:bri...@in... 
> <mailto:bri...@in...>]
> *Sent:* Tuesday, December 18, 2012 10:11 AM
> *To:* pro...@li... 
> <mailto:pro...@li...>
> *Cc:* Mass spectrometry standard development
> *Subject:* Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files
>
> So is this what the tail end of such a file would look like?
>
>    ....
>
>     </run>
>
>   </mzML>
>
>   <indexList count="2">
>
>     <index name="spectrum">
>
>     </index>
>
>     <index name="chromatogram">
>
>     </index>
>
> </indexList>
>
> <indexListOffset>3960</indexListOffset>
>
> <fileChecksum>03a9be216becb05f58b9bd967ff521f5b9883154</fileChecksum>
>
> </indexedmzML>
>
> or would it be
>
>    ....
>
>     </run>
>
>   </mzML>
>
>   <indexList count="0">
>
> </indexList>
>
> <indexListOffset>3902</indexListOffset>
>
> <fileChecksum>e216bec03a9bb67ff521f5b98805f58b9bd93154</fileChecksum>
>
> </indexedmzML>
>
> ?
>
> I lean toward the former, but what would the revised schema dictate?.
>
> Brian
>
> On Mon, Dec 17, 2012 at 4:14 PM, Eric Deutsch 
> <ede...@sy... <mailto:ede...@sy...>> wrote:
>
> So it sounds like there is consensus that we update the index wrapper 
> schema to allow an empty index at version 1.1.2. I agree that this is 
> the best solution. Are there any objections to this?
>
> If no objections emerge, I would propose to update the mzML wrapper 
> schema to 1.1.2 tomorrow (Tuesday). The primary mzML schema will 
> remain unchanged at 1.1. I will also update the documentation to 
> reflect this update as well as another pending documentation update.
>
> Objections?  Comments?
>
> Thanks,
>
> Eric
>
> *From:*Brian Pratt [mailto:bri...@in... 
> <mailto:bri...@in...>]
> *Sent:* Monday, December 17, 2012 1:03 PM
> *To:* Mass spectrometry standard development; 
> pro...@li... 
> <mailto:pro...@li...>
> *Subject:* Re: [Psidev-ms-dev] Empty mzML files
>
> So the right thing to do is write an empty index with warning for 
> schema < 1.1.2, and without warning thereafter.
>
> On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander 
> <fre...@im... <mailto:fre...@im...>> 
> wrote:
>
> I just tried, and it actually worked fine to send an indexed file with
> mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
> through Mascot. There is no version attribute in the index, only in the
> mzML itself. So my worries were exaggerated, and it should probably be
> smooth to update the index schema to 1.1.2 and use it for all files.
>
> Fredrik
>
> Matt Chambers skrev 2012-12-17 21:28:
>
> > Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it 
> would only fail on the empty
> > files (which will actually be valid, but won't appear so until the 
> parser is updated). I definitely
> > prefer a long-term solution of consistent schema emptiness requirements.
> >
> > -Matt
> >
> >
> > On 12/17/2012 2:21 PM, Fredrik Levander wrote:
> >> Hi,
> >>
> >> I agree there is certainly good use cases for mzML files without
> >> spectra, and yes, it makes sense to allow for empty index as well.
> >> However, schema updates are likely to cause problems and should be
> >> avoided if possible.  I am a bit concerned that updating the index
> >> schema will cause validating tools to fail if they are not updated to
> >> support index version 1.1.2. It would maybe cause less problems if
> >> Proteowizard continues to produce 1.1.1 for files with spectra and 
> 1.1.2
> >> for empty ones, but that is maybe not such a great solution either. But
> >> on a an index schema update, all Mascot servers will need an update to
> >> support new indexed mzML files (also those with spectra). So, actually
> >> it might even be better from a practical point of view to allow pwiz to
> >> produce invalid 1.1.1 files with empty index, as Brian suggests, than
> >> updating to schema version 1.1.2 only. A validating tool would protest
> >> on receiving the file, but it could probably not use it either, so that
> >> could still be OK if the error message tells what's wrong.
> >>
> >> Fredrik
> >>
> >> Matt Chambers skrev 2012-12-17 20:09:
> >>> Hi Brian,
> >>>
> >>> I'm moving this back to psidev-ms-dev because I want to wait and 
> see how the specification
> >>> discussion works out. I'm inclined to agree with John that there 
> isn't a strong reason to disallow
> >>> empty indexed mzML files. After a schema change, a 1.1.2 empty 
> indexed mzML file submitted to a
> >>> 1.1.1 validator would fail. But it's only going to happen on an 
> empty file, so it's not a big deal.
> >>>
> > 
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li... 
> <mailto:Psi...@li...>
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li... 
> <mailto:Psi...@li...>
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li... 
> <mailto:pro...@li...>
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li... 
> <mailto:pro...@li...>
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files

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

The first option is already very nearly legal, except that the lower limit
for element count in <index> is unspecified and so defaults to 1.  So that
would be a pretty small change to the schema.

On Tue, Dec 18, 2012 at 5:30 PM, Eric Deutsch
<ede...@sy...>wrote:

> I haven’t gotten to make the schema changes yet, got derailed on other
> things, but still hope to get to it tonight. I would also advocate the
> first option. I think we have a general policy for PSI formats “xxxxxList
> elements shall not be empty”. I don’t know if it’s engraved anywhere, but
> was a policy we tried to carry through. If there’s a xxxxxList element,
> there better be something in it, or else, leave it out. So I would rather
> implement it with an empty <index>. Clearly not an obvious conclusion, but
> at least a precedent to guide the decision.
>
>
>
> Additional comments?
>
>
>
> Thanks,
>
> Eric
>
>
>
>
>
> *From:* Brian Pratt [mailto:bri...@in...]
> *Sent:* Tuesday, December 18, 2012 10:11 AM
> *To:* pro...@li...
> *Cc:* Mass spectrometry standard development
> *Subject:* Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files
>
>
>
> So is this what the tail end of such a file would look like?
>
>    ....
>
>     </run>
>
>   </mzML>
>
>   <indexList count="2">
>
>     <index name="spectrum">
>
>     </index>
>
>     <index name="chromatogram">
>
>     </index>
>
>   </indexList>
>
>   <indexListOffset>3960</indexListOffset>
>
>   <fileChecksum>03a9be216becb05f58b9bd967ff521f5b9883154</fileChecksum>
>
> </indexedmzML>
>
>
>
> or would it be
>
>    ....
>
>     </run>
>
>   </mzML>
>
>   <indexList count="0">
>
>   </indexList>
>
>   <indexListOffset>3902</indexListOffset>
>
>   <fileChecksum>e216bec03a9bb67ff521f5b98805f58b9bd93154</fileChecksum>
>
> </indexedmzML>
>
>
>
> ?
>
>
>
> I lean toward the former, but what would the revised schema dictate?.
>
>
>
> Brian
>
>
>
> On Mon, Dec 17, 2012 at 4:14 PM, Eric Deutsch <ede...@sy...>
> wrote:
>
> So it sounds like there is consensus that we update the index wrapper
> schema to allow an empty index at version 1.1.2. I agree that this is the
> best solution. Are there any objections to this?
>
>
>
> If no objections emerge, I would propose to update the mzML wrapper schema
> to 1.1.2 tomorrow (Tuesday). The primary mzML schema will remain unchanged
> at 1.1. I will also update the documentation to reflect this update as well
> as another pending documentation update.
>
>
>
> Objections?  Comments?
>
>
>
> Thanks,
>
> Eric
>
>
>
>
>
> *From:* Brian Pratt [mailto:bri...@in...]
> *Sent:* Monday, December 17, 2012 1:03 PM
> *To:* Mass spectrometry standard development;
> pro...@li...
> *Subject:* Re: [Psidev-ms-dev] Empty mzML files
>
>
>
> So the right thing to do is write an empty index with warning for schema <
> 1.1.2, and without warning thereafter.
>
> On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander <
> fre...@im...> wrote:
>
> I just tried, and it actually worked fine to send an indexed file with
> mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
> through Mascot. There is no version attribute in the index, only in the
> mzML itself. So my worries were exaggerated, and it should probably be
> smooth to update the index schema to 1.1.2 and use it for all files.
>
> Fredrik
>
> Matt Chambers skrev 2012-12-17 21:28:
>
> > Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it
> would only fail on the empty
> > files (which will actually be valid, but won't appear so until the
> parser is updated). I definitely
> > prefer a long-term solution of consistent schema emptiness requirements.
> >
> > -Matt
> >
> >
> > On 12/17/2012 2:21 PM, Fredrik Levander wrote:
> >> Hi,
> >>
> >> I agree there is certainly good use cases for mzML files without
> >> spectra, and yes, it makes sense to allow for empty index as well.
> >> However, schema updates are likely to cause problems and should be
> >> avoided if possible.  I am a bit concerned that updating the index
> >> schema will cause validating tools to fail if they are not updated to
> >> support index version 1.1.2. It would maybe cause less problems if
> >> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
> >> for empty ones, but that is maybe not such a great solution either. But
> >> on a an index schema update, all Mascot servers will need an update to
> >> support new indexed mzML files (also those with spectra). So, actually
> >> it might even be better from a practical point of view to allow pwiz to
> >> produce invalid 1.1.1 files with empty index, as Brian suggests, than
> >> updating to schema version 1.1.2 only. A validating tool would protest
> >> on receiving the file, but it could probably not use it either, so that
> >> could still be OK if the error message tells what's wrong.
> >>
> >> Fredrik
> >>
> >> Matt Chambers skrev 2012-12-17 20:09:
> >>> Hi Brian,
> >>>
> >>> I'm moving this back to psidev-ms-dev because I want to wait and see
> how the specification
> >>> discussion works out. I'm inclined to agree with John that there isn't
> a strong reason to disallow
> >>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed
> mzML file submitted to a
> >>> 1.1.1 validator would fail. But it's only going to happen on an empty
> file, so it's not a big deal.
> >>>
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>

Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files

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

I haven’t gotten to make the schema changes yet, got derailed on other
things, but still hope to get to it tonight. I would also advocate the
first option. I think we have a general policy for PSI formats “xxxxxList
elements shall not be empty”. I don’t know if it’s engraved anywhere, but
was a policy we tried to carry through. If there’s a xxxxxList element,
there better be something in it, or else, leave it out. So I would rather
implement it with an empty <index>. Clearly not an obvious conclusion, but
at least a precedent to guide the decision.



Additional comments?



Thanks,

Eric





*From:* Brian Pratt [mailto:bri...@in...]
*Sent:* Tuesday, December 18, 2012 10:11 AM
*To:* pro...@li...
*Cc:* Mass spectrometry standard development
*Subject:* Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files



So is this what the tail end of such a file would look like?

   ....

    </run>

  </mzML>

  <indexList count="2">

    <index name="spectrum">

    </index>

    <index name="chromatogram">

    </index>

  </indexList>

  <indexListOffset>3960</indexListOffset>

  <fileChecksum>03a9be216becb05f58b9bd967ff521f5b9883154</fileChecksum>

</indexedmzML>



or would it be

   ....

    </run>

  </mzML>

  <indexList count="0">

  </indexList>

  <indexListOffset>3902</indexListOffset>

  <fileChecksum>e216bec03a9bb67ff521f5b98805f58b9bd93154</fileChecksum>

</indexedmzML>



?



I lean toward the former, but what would the revised schema dictate?.



Brian



On Mon, Dec 17, 2012 at 4:14 PM, Eric Deutsch <ede...@sy...>
wrote:

So it sounds like there is consensus that we update the index wrapper
schema to allow an empty index at version 1.1.2. I agree that this is the
best solution. Are there any objections to this?



If no objections emerge, I would propose to update the mzML wrapper schema
to 1.1.2 tomorrow (Tuesday). The primary mzML schema will remain unchanged
at 1.1. I will also update the documentation to reflect this update as well
as another pending documentation update.



Objections?  Comments?



Thanks,

Eric





*From:* Brian Pratt [mailto:bri...@in...]
*Sent:* Monday, December 17, 2012 1:03 PM
*To:* Mass spectrometry standard development;
pro...@li...
*Subject:* Re: [Psidev-ms-dev] Empty mzML files



So the right thing to do is write an empty index with warning for schema <
1.1.2, and without warning thereafter.

On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander <
fre...@im...> wrote:

I just tried, and it actually worked fine to send an indexed file with
mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
through Mascot. There is no version attribute in the index, only in the
mzML itself. So my worries were exaggerated, and it should probably be
smooth to update the index schema to 1.1.2 and use it for all files.

Fredrik

Matt Chambers skrev 2012-12-17 21:28:

> Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it
would only fail on the empty
> files (which will actually be valid, but won't appear so until the parser
is updated). I definitely
> prefer a long-term solution of consistent schema emptiness requirements.
>
> -Matt
>
>
> On 12/17/2012 2:21 PM, Fredrik Levander wrote:
>> Hi,
>>
>> I agree there is certainly good use cases for mzML files without
>> spectra, and yes, it makes sense to allow for empty index as well.
>> However, schema updates are likely to cause problems and should be
>> avoided if possible.  I am a bit concerned that updating the index
>> schema will cause validating tools to fail if they are not updated to
>> support index version 1.1.2. It would maybe cause less problems if
>> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
>> for empty ones, but that is maybe not such a great solution either. But
>> on a an index schema update, all Mascot servers will need an update to
>> support new indexed mzML files (also those with spectra). So, actually
>> it might even be better from a practical point of view to allow pwiz to
>> produce invalid 1.1.1 files with empty index, as Brian suggests, than
>> updating to schema version 1.1.2 only. A validating tool would protest
>> on receiving the file, but it could probably not use it either, so that
>> could still be OK if the error message tells what's wrong.
>>
>> Fredrik
>>
>> Matt Chambers skrev 2012-12-17 20:09:
>>> Hi Brian,
>>>
>>> I'm moving this back to psidev-ms-dev because I want to wait and see
how the specification
>>> discussion works out. I'm inclined to agree with John that there isn't
a strong reason to disallow
>>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed
mzML file submitted to a
>>> 1.1.1 validator would fail. But it's only going to happen on an empty
file, so it's not a big deal.
>>>
>
------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev




------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
proteowizard-developer mailing list
pro...@li...
https://lists.sourceforge.net/lists/listinfo/proteowizard-developer

Re: [Psidev-ms-dev] [proteowizard-developer] Empty mzML files

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

So is this what the tail end of such a file would look like?
   ....
    </run>
  </mzML>
  <indexList count="2">
    <index name="spectrum">
    </index>
    <index name="chromatogram">
    </index>
  </indexList>
  <indexListOffset>3960</indexListOffset>
  <fileChecksum>03a9be216becb05f58b9bd967ff521f5b9883154</fileChecksum>
</indexedmzML>

or would it be
   ....
    </run>
  </mzML>
  <indexList count="0">
  </indexList>
  <indexListOffset>3902</indexListOffset>
  <fileChecksum>e216bec03a9bb67ff521f5b98805f58b9bd93154</fileChecksum>
</indexedmzML>

?

I lean toward the former, but what would the revised schema dictate?.

Brian

On Mon, Dec 17, 2012 at 4:14 PM, Eric Deutsch
<ede...@sy...>wrote:

> So it sounds like there is consensus that we update the index wrapper
> schema to allow an empty index at version 1.1.2. I agree that this is the
> best solution. Are there any objections to this?
>
>
>
> If no objections emerge, I would propose to update the mzML wrapper schema
> to 1.1.2 tomorrow (Tuesday). The primary mzML schema will remain unchanged
> at 1.1. I will also update the documentation to reflect this update as well
> as another pending documentation update.
>
>
>
> Objections?  Comments?
>
>
>
> Thanks,
>
> Eric
>
>
>
>
>
> *From:* Brian Pratt [mailto:bri...@in...]
> *Sent:* Monday, December 17, 2012 1:03 PM
> *To:* Mass spectrometry standard development;
> pro...@li...
> *Subject:* Re: [Psidev-ms-dev] Empty mzML files
>
>
>
> So the right thing to do is write an empty index with warning for schema <
> 1.1.2, and without warning thereafter.
>
> On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander <
> fre...@im...> wrote:
>
> I just tried, and it actually worked fine to send an indexed file with
> mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
> through Mascot. There is no version attribute in the index, only in the
> mzML itself. So my worries were exaggerated, and it should probably be
> smooth to update the index schema to 1.1.2 and use it for all files.
>
> Fredrik
>
> Matt Chambers skrev 2012-12-17 21:28:
>
> > Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it
> would only fail on the empty
> > files (which will actually be valid, but won't appear so until the
> parser is updated). I definitely
> > prefer a long-term solution of consistent schema emptiness requirements.
> >
> > -Matt
> >
> >
> > On 12/17/2012 2:21 PM, Fredrik Levander wrote:
> >> Hi,
> >>
> >> I agree there is certainly good use cases for mzML files without
> >> spectra, and yes, it makes sense to allow for empty index as well.
> >> However, schema updates are likely to cause problems and should be
> >> avoided if possible.  I am a bit concerned that updating the index
> >> schema will cause validating tools to fail if they are not updated to
> >> support index version 1.1.2. It would maybe cause less problems if
> >> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
> >> for empty ones, but that is maybe not such a great solution either. But
> >> on a an index schema update, all Mascot servers will need an update to
> >> support new indexed mzML files (also those with spectra). So, actually
> >> it might even be better from a practical point of view to allow pwiz to
> >> produce invalid 1.1.1 files with empty index, as Brian suggests, than
> >> updating to schema version 1.1.2 only. A validating tool would protest
> >> on receiving the file, but it could probably not use it either, so that
> >> could still be OK if the error message tells what's wrong.
> >>
> >> Fredrik
> >>
> >> Matt Chambers skrev 2012-12-17 20:09:
> >>> Hi Brian,
> >>>
> >>> I'm moving this back to psidev-ms-dev because I want to wait and see
> how the specification
> >>> discussion works out. I'm inclined to agree with John that there isn't
> a strong reason to disallow
> >>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed
> mzML file submitted to a
> >>> 1.1.1 validator would fail. But it's only going to happen on an empty
> file, so it's not a big deal.
> >>>
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>

Re: [Psidev-ms-dev] Empty mzML files

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

So it sounds like there is consensus that we update the index wrapper
schema to allow an empty index at version 1.1.2. I agree that this is the
best solution. Are there any objections to this?



If no objections emerge, I would propose to update the mzML wrapper schema
to 1.1.2 tomorrow (Tuesday). The primary mzML schema will remain unchanged
at 1.1. I will also update the documentation to reflect this update as well
as another pending documentation update.



Objections?  Comments?



Thanks,

Eric





*From:* Brian Pratt [mailto:bri...@in...]
*Sent:* Monday, December 17, 2012 1:03 PM
*To:* Mass spectrometry standard development;
pro...@li...
*Subject:* Re: [Psidev-ms-dev] Empty mzML files



So the right thing to do is write an empty index with warning for schema <
1.1.2, and without warning thereafter.

On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander <
fre...@im...> wrote:

I just tried, and it actually worked fine to send an indexed file with
mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
through Mascot. There is no version attribute in the index, only in the
mzML itself. So my worries were exaggerated, and it should probably be
smooth to update the index schema to 1.1.2 and use it for all files.

Fredrik

Matt Chambers skrev 2012-12-17 21:28:

> Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it
would only fail on the empty
> files (which will actually be valid, but won't appear so until the parser
is updated). I definitely
> prefer a long-term solution of consistent schema emptiness requirements.
>
> -Matt
>
>
> On 12/17/2012 2:21 PM, Fredrik Levander wrote:
>> Hi,
>>
>> I agree there is certainly good use cases for mzML files without
>> spectra, and yes, it makes sense to allow for empty index as well.
>> However, schema updates are likely to cause problems and should be
>> avoided if possible.  I am a bit concerned that updating the index
>> schema will cause validating tools to fail if they are not updated to
>> support index version 1.1.2. It would maybe cause less problems if
>> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
>> for empty ones, but that is maybe not such a great solution either. But
>> on a an index schema update, all Mascot servers will need an update to
>> support new indexed mzML files (also those with spectra). So, actually
>> it might even be better from a practical point of view to allow pwiz to
>> produce invalid 1.1.1 files with empty index, as Brian suggests, than
>> updating to schema version 1.1.2 only. A validating tool would protest
>> on receiving the file, but it could probably not use it either, so that
>> could still be OK if the error message tells what's wrong.
>>
>> Fredrik
>>
>> Matt Chambers skrev 2012-12-17 20:09:
>>> Hi Brian,
>>>
>>> I'm moving this back to psidev-ms-dev because I want to wait and see
how the specification
>>> discussion works out. I'm inclined to agree with John that there isn't
a strong reason to disallow
>>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed
mzML file submitted to a
>>> 1.1.1 validator would fail. But it's only going to happen on an empty
file, so it's not a big deal.
>>>
>
------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Empty mzML files

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

So the right thing to do is write an empty index with warning for schema <
1.1.2, and without warning thereafter.

On Mon, Dec 17, 2012 at 12:59 PM, Fredrik Levander <
fre...@im...> wrote:

> I just tried, and it actually worked fine to send an indexed file with
> mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element
> through Mascot. There is no version attribute in the index, only in the
> mzML itself. So my worries were exaggerated, and it should probably be
> smooth to update the index schema to 1.1.2 and use it for all files.
>
> Fredrik
>
> Matt Chambers skrev 2012-12-17 21:28:
> > Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it
> would only fail on the empty
> > files (which will actually be valid, but won't appear so until the
> parser is updated). I definitely
> > prefer a long-term solution of consistent schema emptiness requirements.
> >
> > -Matt
> >
> >
> > On 12/17/2012 2:21 PM, Fredrik Levander wrote:
> >> Hi,
> >>
> >> I agree there is certainly good use cases for mzML files without
> >> spectra, and yes, it makes sense to allow for empty index as well.
> >> However, schema updates are likely to cause problems and should be
> >> avoided if possible.  I am a bit concerned that updating the index
> >> schema will cause validating tools to fail if they are not updated to
> >> support index version 1.1.2. It would maybe cause less problems if
> >> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
> >> for empty ones, but that is maybe not such a great solution either. But
> >> on a an index schema update, all Mascot servers will need an update to
> >> support new indexed mzML files (also those with spectra). So, actually
> >> it might even be better from a practical point of view to allow pwiz to
> >> produce invalid 1.1.1 files with empty index, as Brian suggests, than
> >> updating to schema version 1.1.2 only. A validating tool would protest
> >> on receiving the file, but it could probably not use it either, so that
> >> could still be OK if the error message tells what's wrong.
> >>
> >> Fredrik
> >>
> >> Matt Chambers skrev 2012-12-17 20:09:
> >>> Hi Brian,
> >>>
> >>> I'm moving this back to psidev-ms-dev because I want to wait and see
> how the specification
> >>> discussion works out. I'm inclined to agree with John that there isn't
> a strong reason to disallow
> >>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed
> mzML file submitted to a
> >>> 1.1.1 validator would fail. But it's only going to happen on an empty
> file, so it's not a big deal.
> >>>
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] Empty mzML files

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

I just tried, and it actually worked fine to send an indexed file with 
mzML1.1.1_idx changed to mzML1.1.2_idx in the <indexedzmML> element 
through Mascot. There is no version attribute in the index, only in the 
mzML itself. So my worries were exaggerated, and it should probably be 
smooth to update the index schema to 1.1.2 and use it for all files.

Fredrik

Matt Chambers skrev 2012-12-17 21:28:
> Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it would only fail on the empty
> files (which will actually be valid, but won't appear so until the parser is updated). I definitely
> prefer a long-term solution of consistent schema emptiness requirements.
>
> -Matt
>
>
> On 12/17/2012 2:21 PM, Fredrik Levander wrote:
>> Hi,
>>
>> I agree there is certainly good use cases for mzML files without
>> spectra, and yes, it makes sense to allow for empty index as well.
>> However, schema updates are likely to cause problems and should be
>> avoided if possible.  I am a bit concerned that updating the index
>> schema will cause validating tools to fail if they are not updated to
>> support index version 1.1.2. It would maybe cause less problems if
>> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
>> for empty ones, but that is maybe not such a great solution either. But
>> on a an index schema update, all Mascot servers will need an update to
>> support new indexed mzML files (also those with spectra). So, actually
>> it might even be better from a practical point of view to allow pwiz to
>> produce invalid 1.1.1 files with empty index, as Brian suggests, than
>> updating to schema version 1.1.2 only. A validating tool would protest
>> on receiving the file, but it could probably not use it either, so that
>> could still be OK if the error message tells what's wrong.
>>
>> Fredrik
>>
>> Matt Chambers skrev 2012-12-17 20:09:
>>> Hi Brian,
>>>
>>> I'm moving this back to psidev-ms-dev because I want to wait and see how the specification
>>> discussion works out. I'm inclined to agree with John that there isn't a strong reason to disallow
>>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed mzML file submitted to a
>>> 1.1.1 validator would fail. But it's only going to happen on an empty file, so it's not a big deal.
>>>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Empty mzML files

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

Can a 1.1.1 validating parser accept a non-empty 1.1.2 file? Then it would only fail on the empty 
files (which will actually be valid, but won't appear so until the parser is updated). I definitely 
prefer a long-term solution of consistent schema emptiness requirements.

-Matt


On 12/17/2012 2:21 PM, Fredrik Levander wrote:
> Hi,
>
> I agree there is certainly good use cases for mzML files without
> spectra, and yes, it makes sense to allow for empty index as well.
> However, schema updates are likely to cause problems and should be
> avoided if possible.  I am a bit concerned that updating the index
> schema will cause validating tools to fail if they are not updated to
> support index version 1.1.2. It would maybe cause less problems if
> Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2
> for empty ones, but that is maybe not such a great solution either. But
> on a an index schema update, all Mascot servers will need an update to
> support new indexed mzML files (also those with spectra). So, actually
> it might even be better from a practical point of view to allow pwiz to
> produce invalid 1.1.1 files with empty index, as Brian suggests, than
> updating to schema version 1.1.2 only. A validating tool would protest
> on receiving the file, but it could probably not use it either, so that
> could still be OK if the error message tells what's wrong.
>
> Fredrik
>
> Matt Chambers skrev 2012-12-17 20:09:
>> Hi Brian,
>>
>> I'm moving this back to psidev-ms-dev because I want to wait and see how the specification
>> discussion works out. I'm inclined to agree with John that there isn't a strong reason to disallow
>> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed mzML file submitted to a
>> 1.1.1 validator would fail. But it's only going to happen on an empty file, so it's not a big deal.
>>

Re: [Psidev-ms-dev] Empty mzML files

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

Hi,

I agree there is certainly good use cases for mzML files without 
spectra, and yes, it makes sense to allow for empty index as well. 
However, schema updates are likely to cause problems and should be 
avoided if possible.  I am a bit concerned that updating the index 
schema will cause validating tools to fail if they are not updated to 
support index version 1.1.2. It would maybe cause less problems if 
Proteowizard continues to produce 1.1.1 for files with spectra and 1.1.2 
for empty ones, but that is maybe not such a great solution either. But 
on a an index schema update, all Mascot servers will need an update to 
support new indexed mzML files (also those with spectra). So, actually 
it might even be better from a practical point of view to allow pwiz to 
produce invalid 1.1.1 files with empty index, as Brian suggests, than 
updating to schema version 1.1.2 only. A validating tool would protest 
on receiving the file, but it could probably not use it either, so that 
could still be OK if the error message tells what's wrong.

Fredrik

Matt Chambers skrev 2012-12-17 20:09:
> Hi Brian,
>
> I'm moving this back to psidev-ms-dev because I want to wait and see how the specification
> discussion works out. I'm inclined to agree with John that there isn't a strong reason to disallow
> empty indexed mzML files. After a schema change, a 1.1.2 empty indexed mzML file submitted to a
> 1.1.1 validator would fail. But it's only going to happen on an empty file, so it's not a big deal.
>

Re: [Psidev-ms-dev] Empty mzML files

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

Nearer-term, though, I think it's useful for proteowizard to emit a
(technically invalid) empty index with a warning.  The file wouldn't
validate, but then most readers don't bother validating anyway for
performance reasons.  We could include a comment in the file explaining the
situation, I suppose.

It's true that this pushes the handling of the empty file error condition
downstream, but the point is that not everybody agrees that this *is* an
error  condition, and would actually view emptiness as a useful bit of
information downstream.  I don't get the sense that this is going to break
anybody's pipeline any worse than the current behavior does, but would in
fact be an improvement.

Brian

On Mon, Dec 17, 2012 at 11:18 AM, Matt Chambers
<mat...@gm...>wrote:

>
> On 12/17/2012 1:13 PM, Oliver Kohlbacher wrote:
> > On 17.12.2012, at 20:09, Matt Chambers<mat...@gm...>
>  wrote:
> >
> >> >On the other hand, AFAICT, even in a "pipeline", ending up with an
> empty file (indexed or not) is
> >> >pretty much an error condition that should abort the pipeline. The
> abort need not be an ugly one: it
>


> > I would disagree. You could have a pipeline extracting spectra matching
> certain criteria and in
> > some cases that might be a desired outcome to obtain no spectra (e.g.,
> in quality control pipelines
> > if you want to pull out all spectra matching certain contaminants).
>
> I just meant that you can't pass the resulting file to any other program
> (except one that can ignore
> empty files or simply counts spectra). So either take the error code to
> mean "it was empty" or check
> the file yourself to detect the emptiness. Checking an error code is
> usually easier than checking an
> mzML file for emptiness, but I agree the extra logic in the pipeline is
> undesirable.
>
> -Matt
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] Empty mzML files

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

On 12/17/2012 1:13 PM, Oliver Kohlbacher wrote:
> On 17.12.2012, at 20:09, Matt Chambers<mat...@gm...>  wrote:
>
>> >On the other hand, AFAICT, even in a "pipeline", ending up with an empty file (indexed or not) is
>> >pretty much an error condition that should abort the pipeline. The abort need not be an ugly one: it
> I would disagree. You could have a pipeline extracting spectra matching certain criteria and in
> some cases that might be a desired outcome to obtain no spectra (e.g., in quality control pipelines
> if you want to pull out all spectra matching certain contaminants).

I just meant that you can't pass the resulting file to any other program (except one that can ignore 
empty files or simply counts spectra). So either take the error code to mean "it was empty" or check 
the file yourself to detect the emptiness. Checking an error code is usually easier than checking an 
mzML file for emptiness, but I agree the extra logic in the pipeline is undesirable.

-Matt

Re: [Psidev-ms-dev] Empty mzML files

[Oliver K. <oli...@un...>]

On 17.12.2012, at 20:09, Matt Chambers <mat...@gm...> wrote:

> On the other hand, AFAICT, even in a "pipeline", ending up with an empty file (indexed or not) is 
> pretty much an error condition that should abort the pipeline. The abort need not be an ugly one: it 
I would disagree. You could have a pipeline extracting spectra matching certain criteria and in
some cases that might be a desired outcome to obtain no spectra (e.g., in quality control pipelines
if you want to pull out all spectra matching certain contaminants).

> I think we should move toward consistency in allowing emptiness. Either both indexed and non-indexed 
> mzMLs should be allowed to be empty, or neither. That way applications can handle them uniformly. 
> And I prefer changing the index schema instead of the core schema (even though I'm actually 
> indifferent as to whether emptiness is valid or not).
I totally agree with this.

Just my two cents,
  Oliver




---
Oliver Kohlbacher (oli...@un...)
Professor, Applied Bioinformatics, Center for Bioinformatics Tuebingen
 & Dept. of Computer Science, University of Tuebingen
Director, Quantitative Biology Center
phone: +49-7071-29-70457   http://KohlbacherLab.org 

vCard at: http://abi.inf.uni-tuebingen.de/People/kohlbach/vCard

Re: [Psidev-ms-dev] Empty mzML files

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

Hi Brian,

I'm moving this back to psidev-ms-dev because I want to wait and see how the specification 
discussion works out. I'm inclined to agree with John that there isn't a strong reason to disallow 
empty indexed mzML files. After a schema change, a 1.1.2 empty indexed mzML file submitted to a 
1.1.1 validator would fail. But it's only going to happen on an empty file, so it's not a big deal.

On the other hand, AFAICT, even in a "pipeline", ending up with an empty file (indexed or not) is 
pretty much an error condition that should abort the pipeline. The abort need not be an ugly one: it 
could simply report to the client that the result at step X was empty and nothing further could be 
done. This error condition can be detected either by getting an error code from the mzML-producing 
application which tried to write an empty indexed mzML (using the existing schema), or by examining 
the produced mzML to see if it's empty (using a revised schema). The former is easier, but only 
works for indexed mzMLs, since non-indexed mzMLs can already be empty and won't produce an error code.

I think we should move toward consistency in allowing emptiness. Either both indexed and non-indexed 
mzMLs should be allowed to be empty, or neither. That way applications can handle them uniformly. 
And I prefer changing the index schema instead of the core schema (even though I'm actually 
indifferent as to whether emptiness is valid or not).

-Matt


On 12/17/2012 12:11 PM, Brian Pratt wrote:
> It sounds like the proper proteowizard response is yet another msconvert argument to indicate what
> to do in the face of an empty output for an indexed file - write unindexed with a warning, write a
> technically invalid empty index with a warning, or fail.
>
> Currently there is the --noindex option to turn off indexing, how about we add
> --emptyindex=<force|none> to indicate that the user prefers an invalid empty index or none at all.
>   The default behavior will continue to be failure, but we'll tweak the error message to indicate
> how to work around it.  Not in love with that name "emptyindex", any better ideas?
>
> Or we could just emit an empty index with a warning.  I'm guessing that's actually the most useful
> thing we could do - most mzML readers would probably handle it just fine even if its technically
> invalid.
>
> The more I think about it, the more pragmatic the "just emit an empty index with a warning" option
> sounds.
>
> Brian
>
> On Sun, Dec 16, 2012 at 10:42 AM, John Chilton <chi...@um... <mailto:chi...@um...>> wrote:
>
>     Perhaps specification development is different than application
>     development. But in application development if you are processing
>     lists of things, it is better to allow the empty list as input unless
>     you have a good reason not to. So I think it would be more appropriate
>     to ask, "why exclude the possibility for an empty index" rather than
>     "why would you want an empty index"? Do you have an answer for that,
>     what is being harmed by an empty index?
>
>     Though I don't feel it is the right question to ask, I can respond to
>     the question of why allow an empty index. There are definitely good
>     reasons. For instances, there are programs (outside of msconvert) that
>     take in indexed mzML files but not unindexed mzML files (I think one
>     of the quant programs in the TPP for instance). Also, suppose I tell
>     msconvert (or really any program that produces mzML files) that I want
>     to do some filtering and I specify I want the output as an indexed
>     mzML file, it would be a defect in that program if it produces an
>     empty unindexed mzML file.
>
>     If I were an analyst, manually running desktop software and inspecting
>     the outputs are each step, I would never do anything with empty mzML
>     files, I would get to that point and stop. But that is not what I do,
>     I develop pipelines on top of applications. If I have to write special
>     logic to account for handling empty mzML files differently, and so do
>     the application programmers who write the applications I wrap, that
>     ends up being a lot of logic added by many different people with no
>     gain. To me this is a sign of a defect in specification.
>
>     Thanks again for your time,
>     -John
>
>      > Hello John,
>      >
>      > Thanks for your input. I might be missing something, but I don't see
>      > much point in writing out the index if it doesn't contain any entries.
>      > Wouldn't it be better to just write the mzML file without index in cases
>      > where there are no spectra? Maybe you can ask the msconvert developers
>      > to allow for that option, if it is not already possible.
>      >
>      > Best Regards
>      >
>      > Fredrik

Re: [Psidev-ms-dev] [Psidev-ms-vocab] New version 3.43.0 of psi-ms.obo

[Gorka P. <gor...@eh...>]

Hi all, and sorry for my late response, I have been out of the office 
during the last week.

I agree with Andy's suggestion and will be happy to contribute to the 
discussion. I think there is a need for a consistent terminology for 
dealing with protein inference ambiguities and even for other aspects 
beyond the terminology, like computing protein counts and FDRs with 
ambiguous proteins groups.

Until we decide how to manage this, we will keep on using the new terms 
in 3.43.0 for PAnalyzer and MIAPE Extractor software. Then we can 
migrate to the new solution.

Best regards,
Gorka

On 11/12/12 18:10, Jones, Andy wrote:
> Hi all,
>
> For info, Sean Seymour, Terry Farrah and myself have (on and off) been working on the protein inference terminology for some time and we've made some proposals to improve terms, which haven't yet made it to finalisation. Rather than adding Gorka's terms just yet, I would prefer to resurrect our work (say in early January with some conference calls) and get agreed a set of consistent terms to be used across all mzid files - does this sound okay? Gorka, are you happy to join this effort rather than getting these terms in just now?
>
> Best wishes
> Andy
>
> -----Original Message-----
> From: Gerhard Mayer [mailto:Ger...@ru...]
> Sent: 11 December 2012 16:10
> To: psi...@li...; psi...@li...; Mass spectrometry standard development
> Subject: [Psidev-ms-vocab] New version 3.43.0 of psi-ms.obo
>
> Dear proteomics community,
>
> the psi-ms.obo file is updated to the new version 3.43.0.
>
> It contains some terms for peptide grouping categories in PAnalyzer, requested by Gorka Prieto.
> In addition, following Matt's proposal, the names of terms like "Sequest:sort_by_*" are changed to "Sequest:sort by *"
>
>
> Changed CV terms in version 3.43.0 of psi-ms.obo:
> =================================================
> ************ Changed the is_a relationship from
> ************ is_a: MS:1001198 ! protein identification confidence metric
> ************ --> is_a: MS:1001101 ! protein group or subset relationship [Term]
> id: MS:1001600
> name: protein inference confidence category
> def: "Confidence category of inferred protein (conclusive, non conclusive, ambiguous group or indistinguishable)." [PSI:MS]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001101 ! protein group or subset relationship
>
>
> ************ Changed the names for the following terms following Matt's
> proposal from "sort_by_*" to "sort by *"
> [Term]
> id: MS:1001046
> name: Sequest:sort by dCn
> def: "Sort order of Sequest search results by the delta of the
> normalized correlation score." [PSI:PI]
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001047
> name: Sequest:sort by dM
> def: "Sort order of Sequest search results by the difference between a
> theoretically calculated and the corresponding experimentally measured
> molecular mass M." [PSI:PI]
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001048
> name: Sequest:sort by Ions
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001049
> name: Sequest:sort by MH+
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001050
> name: Sequest:sort by P
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001052
> name: Sequest:sort by PreviousAminoAcid
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001053
> name: Sequest:sort by Ref
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001059
> name: Sequest:sort by RSp
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001068
> name: Sequest:sort by Sp
> def: "Sort order of Sequest search results by the Sp score." [PSI:PI]
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001069
> name: Sequest:sort by TIC
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001070
> name: Sequest:sort by Scan
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001071
> name: Sequest:sort by Sequence
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001072
> name: Sequest:sort by Sf
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001086
> name: Sequest:sort by XCorr
> def: "Sort order of Sequest search results by the correlation score."
> [PSI:PI]
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
> [Term]
> id: MS:1001094
> name: Sequest:sort by z
> xref: value-type:xsd\:boolean "The allowed value-type for this CV term."
> is_a: MS:1001041 ! Sequest:sortCV
>
>
> New CV terms in version 3.43.0 of psi-ms.obo:
> =============================================
> [Term]
> id: MS:1002213
> name: conclusive protein
> def: "A protein identified by at least one unique (distinct, discrete)
> peptide (peptides are considered different only if they can be
> distinguished by evidence in mass spectrum)." [PSI:PI]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001600 ! protein inference confidence category
>
> [Term]
> id: MS:1002214
> name: indistinguishable protein
> def: "A member of a group of proteins sharing all peptides that are
> exclusive to the group (peptides are considered different only if they
> can be distinguished by evidence in mass spectrum)." [PSI:PI]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001600 ! protein inference confidence category
>
> [Term]
> id: MS:1002215
> name: non-conclusive protein
> def: "A protein sharing all its matched peptides with either conclusive
> or indistinguishable proteins (peptides are considered different only if
> they can be distinguished by evidence in mass spectrum)." [PSI:PI]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001600 ! protein inference confidence category
>
> [Term]
> id: MS:1002216
> name: ambiguous group member
> def: "A protein sharing at least one peptide not matched to either
> conclusive or indistinguishable proteins (peptides are considered
> different only if they can be distinguished by evidence in mass
> spectrum)." [PSI:PI]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001600 ! protein inference confidence category
>
> Best Regards,
> Gerhard
>

-- 

Gorka Prieto Agujeta, PhD
Senior Lecturer
gor...@eh...
(+34) 94 601 3994

DEPARTMENT OF COMMUNICATIONS ENGINEERING
UNIVERSITY OF THE BASQUE COUNTRY (UPV/EHU)
Alda. Urquijo, s/n | 48013 BILBAO (Spain)
T.: +34 946014036|F.: +34 946014259
www.ehu.es <http://www.ehu.es>

	

LEGAL NOTICE: This e-mail and any attachments may contain confidential 
and privileged information. If you are not the intended recipient, 
please notify the sender immediately by return e-mail, delete this 
e-mail and destroy any copies. Any dissemination or use of this 
information by a person other than the intended recipient is 
unauthorized and may be illegal.

	

Please consider the environment before printing this e-mail.

Re: [Psidev-ms-dev] Empty mzML files

[John C. <chi...@um...>]

Perhaps specification development is different than application
development. But in application development if you are processing
lists of things, it is better to allow the empty list as input unless
you have a good reason not to. So I think it would be more appropriate
to ask, "why exclude the possibility for an empty index" rather than
"why would you want an empty index"? Do you have an answer for that,
what is being harmed by an empty index?

Though I don't feel it is the right question to ask, I can respond to
the question of why allow an empty index. There are definitely good
reasons. For instances, there are programs (outside of msconvert) that
take in indexed mzML files but not unindexed mzML files (I think one
of the quant programs in the TPP for instance). Also, suppose I tell
msconvert (or really any program that produces mzML files) that I want
to do some filtering and I specify I want the output as an indexed
mzML file, it would be a defect in that program if it produces an
empty unindexed mzML file.

If I were an analyst, manually running desktop software and inspecting
the outputs are each step, I would never do anything with empty mzML
files, I would get to that point and stop. But that is not what I do,
I develop pipelines on top of applications. If I have to write special
logic to account for handling empty mzML files differently, and so do
the application programmers who write the applications I wrap, that
ends up being a lot of logic added by many different people with no
gain. To me this is a sign of a defect in specification.

Thanks again for your time,
-John

> Hello John,
>
> Thanks for your input. I might be missing something, but I don't see
> much point in writing out the index if it doesn't contain any entries.
> Wouldn't it be better to just write the mzML file without index in cases
> where there are no spectra? Maybe you can ask the msconvert developers
> to allow for that option, if it is not already possible.
>
> Best Regards
>
> Fredrik

Re: [Psidev-ms-dev] Empty mzML files

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

Hello John,

Thanks for your input. I might be missing something, but I don't see 
much point in writing out the index if it doesn't contain any entries. 
Wouldn't it be better to just write the mzML file without index in cases 
where there are no spectra? Maybe you can ask the msconvert developers 
to allow for that option, if it is not already possible.

Best Regards

Fredrik

On 2012-12-11 17:55, John Chilton wrote:
> This page (http://www.psidev.info/mzml_1_0_0%20) says to send feedback
> about mzML here. So I am doing that.
>
> I think it would be beneficial to allow empty indexed mzML files. It
> looks like unindexed files can be empty, but this is the problematic
> part of the indexed schema:
>
>    <xs:complexType name="IndexListType">
>      <xs:sequence>
>        <xs:element minOccurs="1" maxOccurs="unbounded" name="index"
> type="dx:IndexType">
>          <xs:annotation>
>            <xs:documentation>Index element containing one or more
> offsets for random data access for the entity described in the 'name'
> attribute.</xs:documentation>
>          </xs:annotation>
>        </xs:element>
>      </xs:sequence>
>      <xs:attribute name="count" type="xs:nonNegativeInteger" use="required">
>        <xs:annotation>
>          <xs:documentation>Number of indices in this list.</xs:documentation>
>        </xs:annotation>
>      </xs:attribute>
>    </xs:complexType>
>
> The count attribute is nonNegative which means it can be zero (good),
> but there is a minOccurs="1" on the index element.
>
> It doesn't really seem like there is a new specification on the
> horizon anytime soon, but I thought I would voice my opinion in case
> there is a new specification some day.
>
> More info:
> http://sourceforge.net/mailarchive/message.php?msg_id=30214022
>
> Thanks for your time,
> -John
>
> ------------------------------------------------
> John Chilton
> Senior Software Developer
> University of Minnesota Supercomputing Institute
> Office: 612-625-0917
> Cell: 612-226-9223
> Bitbucket: https://bitbucket.org/jmchilton
> Github: https://github.com/jmchilton
> Web: http://jmchilton.net
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev