From: Rune S. P. <mai...@ph...> - 2008-02-13 10:37:50
|
Hello all Eric Deutsch wrote: > <spectrum id="S19" scanNumber="19" msLevel="1" arrayLength="1313"> > <spectrumDescription> > ... > </spectrumDescription> > The information could be an element under <spectrumDescription> -- Regards Rune |
From: Rune S. P. <ru...@ph...> - 2008-02-13 10:29:07
|
Hello all Eric Deutsch wrote: > <spectrum id="S19" scanNumber="19" msLevel="1" arrayLength="1313"> > <spectrumDescription> > ... > </spectrumDescription> > The information could be an element under <spectrumDescription> -- Regards Rune |
From: Lennart M. <len...@eb...> - 2008-02-13 14:28:23
|
Dear PSI-MS enthousiasts, I have started to update the mzML schema as per the progress we're making. As the basis schema, I have used the reformatted version helpfully contributed by Phil Jones and Richard Cote (I believe no one objects against a schema form that facilitates code generation). I will post all (incremental!) updates I make to the schema as we go along, and these will be called: YYYYMMdd_mzML0.99.9_SNAPSHOT.xsd And the subject line will look like the one in this mail, with the end bit indicating the latest change. A download link to the latest schema version will also be provided, current one is: http://www.ebi.ac.uk/~lmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd This one has the binaryArrayData length as a Spectrum element attribute, and slightly revised documentation accordingly. Cheers, lnnrt. |
From: Angel P. <an...@ma...> - 2008-02-13 19:33:18
|
quick validation error, the xml namespace has a different version than target schema spec, still @ 0.99.1 is: xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.1" should be: xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.9" -angel On Feb 13, 2008 9:28 AM, Lennart Martens <len...@eb...> wrote: > Dear PSI-MS enthousiasts, > > > I have started to update the mzML schema as per the progress we're making. > > As the basis schema, I have used the reformatted version helpfully > contributed by Phil Jones and Richard Cote (I believe no one objects > against a schema form that facilitates code generation). > > I will post all (incremental!) updates I make to the schema as we go > along, and these will be called: > > YYYYMMdd_mzML0.99.9_SNAPSHOT.xsd > > And the subject line will look like the one in this mail, with the end > bit indicating the latest change. > > A download link to the latest schema version will also be provided, > current one is: > > http://www.ebi.ac.uk/~lmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd<http://www.ebi.ac.uk/%7Elmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd> > > > This one has the binaryArrayData length as a Spectrum element attribute, > and slightly revised documentation accordingly. > > > Cheers, > > lnnrt. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > -- Angel Pizarro Director, ITMAT Bioinformatics Facility 806 Biological Research Building 421 Curie Blvd. Philadelphia, PA 19104-6160 215-573-3736 |
From: Lennart M. <len...@eb...> - 2008-02-14 11:00:37
|
Hi Angel, > quick validation error, the xml namespace has a different version than > target schema spec, still @ 0.99.1 Oooops :). Thanks for pointing that out! I've put a fixed version online now, replacing the previous file. My apologies for the glitch! BTW: to all, the fact that I put these 'SNAPSHOT' schemata up doesn't mean that they convey some sort of decision - they just show what certain decisions might look like, in case people want to experiment with them. Additionally, we can always reverse changes at any point. So treat them as 'stuff to play with' rather than anything else. I will however try to follow the general consensus view as we go along (I'm sure that even when decisions are ultimately made, some of these will remain somewhat contested, and this is of course not a bad thing -- it'll be food for thought for what we want to do next :)). Cheers, lnnrt. > > is: > xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.1" > > should be: > > xmlns:dx="http://psi.hupo.org/schema_revision/mzML_0.99.9" > > > -angel > > On Feb 13, 2008 9:28 AM, Lennart Martens <len...@eb... > <mailto:len...@eb...>> wrote: > > Dear PSI-MS enthousiasts, > > > I have started to update the mzML schema as per the progress we're > making. > > As the basis schema, I have used the reformatted version helpfully > contributed by Phil Jones and Richard Cote (I believe no one objects > against a schema form that facilitates code generation). > > I will post all (incremental!) updates I make to the schema as we go > along, and these will be called: > > YYYYMMdd_mzML0.99.9_SNAPSHOT.xsd > > And the subject line will look like the one in this mail, with the end > bit indicating the latest change. > > A download link to the latest schema version will also be provided, > current one is: > > http://www.ebi.ac.uk/~lmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd > <http://www.ebi.ac.uk/%7Elmartens/mzML/20080213_mzML0.99.9_SNAPSHOT.xsd> > > > This one has the binaryArrayData length as a Spectrum element attribute, > and slightly revised documentation accordingly. > > > Cheers, > > lnnrt. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > <mailto:Psi...@li...> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
From: Fredrik L. <Fre...@el...> - 2008-02-13 17:25:33
|
As Eric concluded, a problem with arrays of different lengths is that you would normally want pairs of data, i.e. an m/z and charge state pair. This would require two m/z arrays in the set. OK, you could identify pairs by looking at the arrayLength of the different arrays and use that for pairing, but it seems suboptimal to me. Also, if the spectrum element represents a list of picked peaks I think you would have charge assignments for all the peaks, even if some would be zero or another dummy value if the assignment failed. So, I also vote for binary arrays of the same length for a spectrum. Fredrik 13 feb 2008 kl. 17.12 skrev Matthew Chambers: > It's true that identification output doesn't belong in mzML, but peak > charge state assignments and isotope assignments (to name two > examples) > do not fall under that umbrella. Such annotation does belong in the > mzML > IMO, either in the same file or in a new one, it doesn't really > matter. > And such advanced annotation is unlikely to be available for every > peak > (much less every data point for profile data!). I fail to see the harm > of allowing the length attribute of binaryDataArrays to be optional, > and > if not present for a given binaryDataArray, readers would be > instructed > to treat it the same as the required length attribute (given as an > attribute on the corresponding spectrum element). As for how this will > allow for user-defined craziness, "userParam" does already allow for > that, but binary data cannot be encoded in a userParam to my > knowledge. > > -Matt > > > Lennart Martens wrote: >> Hi Marc, >> >> >> >>> i like that idea of being able to annotate a small subset of the >>> peaks >>> in a spectrum. >>> This is e.g. needed when assigning ion types for MS/MS: b1, >>> b2, ..., y1, >>> y2, ..., y7-H2O, ... >>> Most of the peaks are simply noise and so only a minority of peaks >>> will >>> have an annotation. >>> Using a full-sized array would be possible, but a waste of space. >>> In my opinion, there should be a recommended way to do such a thing. >>> What do you suggest? >>> >>> Before i forget: Is it possible to annotate peaks with strings? >>> Otherwise we would have to use some kind of dictionary to assign ion >>> type an integer index. >>> >> >> The annotation of a mass spectrum with fragment ion types and indices >> presents a significant amount of processing of the original mass spec >> data, as well as a certain type of 'inference' (uncertainty, and >> often >> ambiguity!) that has nothing to do with the mass spectrometer, but >> relates to an identification algorithm of some description. >> >> As such, I don't think we want to annotate this information in mzML >> at >> all, or encourage people to do so. The scope of mzML should remain >> limited to the instrument output (with possibly some signal >> processing >> done by the instrument software). >> >> Fragment ion annotation should therefore be held elsewhere, and the >> PSI >> is actually creating analysisXML for the purpose of recording >> identification algorithm output (such as fragment ion assignment). >> analysisXML will link back to the mzML files used as input, and >> through >> this link, peak annotation can be extracted. >> >> >> Cheers, >> >> lnnrt. >> >>> -Marc >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Psidev-ms-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |