psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] Indexing in mzML

[Joshua T. <jt...@sy...>]

Hi Mike,

Not to through any coals on the fire, but just contributing my 
experience as a software developer here in the Aebersold Lab (ISB):

All of our mzXML processing software (the TPP, etc) relies on 
pre-computed indexes.  Yes, it's a matter of trust, but we find it much 
more efficient to calculate this index once, at the time the mzXML file 
is created.  As Eric has mentioned, in practice we don't find many 
(any?) errors with this, and the mzXML files actually store a checksum 
of themselves up to the index, which can be used to give some assurance 
that the index data is appropriate (I'm sure xml purists are groaning, 
but it works.)

You may be coming from a much more stringent background, such as trying 
to provide regulatory compliance.  As far as I can tell from today's 
discussions, the index will be optional, and your more stringent 
programs will be free to generate index-less files, ignore previously 
generated indexes, rewrite them to a new file, or recalcuate them 
yourself in your own programs.

I still don't think text files are the best way to store large binary 
arrays (versus, for example, the netCDF format), but we've found xml 
with indexes to be a reasonable and useful compromise for keeping all 
the data in one human-readable file.

Hope this helps,

Josh


Mike Coleman wrote:
> On 6/19/07, Eric Deutsch <ede...@sy...> wrote:
>> - While index/data mismatch is a potential source of problem, it has
>> been our experience that problems are rare and the benefits huge.
> 
> Just to be clear, I'm not arguing against indexing in general (which
> would be silly), but rather just questioning whether it makes sense to
> include indices in (or alongside) mzML files.
> 
>>From a programming perspective, this seems like an implementation
> detail.  One can imagine that many consumers of these files either
> have no use for an index or else are easily capable of simply
> generating an index of their own.  Furthermore, applications will
> often have more information about the specific sort of index that
> would be best.
> 
> As you note, if an index is included in the mzML file it can be
> checked for sanity.  And, in fact, proper engineering requires this.
> If a program generates the index itself, it can afford to be somewhat
> trusting, but if the index is generated elsewhere, it really needs to
> be quite paranoid, which requires extra code.
> 
> So the worry would be that this feature, which is intended to make
> life simpler, might end up actually making things more difficult for
> implementers (both producers and consumers) and bloat the mzML files
> to boot.
> 
> Mike
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Indexing in mzML

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

On 6/19/07, Eric Deutsch <ede...@sy...> wrote:
> - While index/data mismatch is a potential source of problem, it has
> been our experience that problems are rare and the benefits huge.

Just to be clear, I'm not arguing against indexing in general (which
would be silly), but rather just questioning whether it makes sense to
include indices in (or alongside) mzML files.

>From a programming perspective, this seems like an implementation
detail.  One can imagine that many consumers of these files either
have no use for an index or else are easily capable of simply
generating an index of their own.  Furthermore, applications will
often have more information about the specific sort of index that
would be best.

As you note, if an index is included in the mzML file it can be
checked for sanity.  And, in fact, proper engineering requires this.
If a program generates the index itself, it can afford to be somewhat
trusting, but if the index is generated elsewhere, it really needs to
be quite paranoid, which requires extra code.

So the worry would be that this feature, which is intended to make
life simpler, might end up actually making things more difficult for
implementers (both producers and consumers) and bloat the mzML files
to boot.

Mike

Re: [Psidev-ms-dev] Indexing in mzML

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

> Hi everyone, thank you for the good discussion, here is what I take away
> from this discussion (colored with my understanding of the prevailing
> opinion on the various topics):
> 
> - Separate index/metadata files will be avoided
> - The mzML index will be *optional* as a wrapper schema (with actual
> index at the end of the file) as currently in mzXML

This works either way for me.  It makes it tricky to get to the index, but
it's not any trickier than managing two files, especially if one is
optional.  However, unless I am missing something, is it not much harder to
use a hash to check if the index is valid (i.e. that the main file has not
been altered) if the index is included in the main file?  Even if the hash
is written as the last thing, that change alone would cause the next hash to
be different, would it not?


> - The validator will enforce that scan numbers are in ascending order,
> but not necessarily without gaps
> - The validator will enforce that scan numbers and identifiers must be
> unique within a run (but there could be multiple runs in a file)

I'm confused about the difference between identifiers and scan numbers.
Since a mzML file can have more than one spectra source (e.g. multiple RAW
files), scan numbers could only be unique within a run, as you say, but I
would expect that the "SpectrumID" identifier, if it is different from the
scan number, should be unique to the whole file.  What is the reasoning
behind the SpectrumID identifier being unique only to a run, or am I
misunderstanding?  What is the purpose of having a separate SpectrumID
identifier anyway? 


> - Regarding *always* correct indexes, users of mzXML have been using
> indexes for years with no reports of problems that I'm aware.  Obviously
> if the file is altered in any way, the index should be regenerated.
> There are (for mzXML) / will be (for mzML) index checkers to make sure
> all is well along with reindexing functionality if the index is bad.
> - It should be a requirement for any reading software that uses the
> index (all readers are required to be tolerant of the presence of the
> wrapper schema index, but are not required to use it) to do some basic
> checking that the result is correct.  E.g. if scan number 17500 is
> desired and the index is used to jump to that location, it is
> straightforward and necessary to ensure that the first tag read is
> indeed <spectrum scan_number="17500">. If it is not, the software is
> free to do anything except continue as if it didn't know better (e.g.,
> stop with error, revert to sequential read, or try to regenerate the
> index and retry).

This is complicated by multiple sources being in a single mzML file.  Will
the index follow the same structure as the main section so that when you are
looking for a scan number in some source, you first traverse into the
source, and then look for the indexed spectrum to get its offset?

<source name="someSourceName">
	<spectrum scan="15">
		...
	</spectrum>
</source>
<index>
	<indexedSource name="someSourceName" offset="0">
		<indexedSpectrum scan="15" offset="33">
			...
		</indexedSpectrum>
	</indexedSource>
</index>


> - While index/data mismatch is a potential source of problem, it has
> been our experience that problems are rare and the benefits huge.

Agreed.


Regards,
Matt Chambers

Re: [Psidev-ms-dev] Indexing in mzML

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

Hi everyone, thank you for the good discussion, here is what I take away
from this discussion (colored with my understanding of the prevailing
opinion on the various topics):

- Separate index/metadata files will be avoided
- The mzML index will be *optional* as a wrapper schema (with actual
index at the end of the file) as currently in mzXML
- The validator will enforce that scan numbers are in ascending order,
but not necessarily without gaps
- The validator will enforce that scan numbers and identifiers must be
unique within a run (but there could be multiple runs in a file)
- Regarding *always* correct indexes, users of mzXML have been using
indexes for years with no reports of problems that I'm aware.  Obviously
if the file is altered in any way, the index should be regenerated.
There are (for mzXML) / will be (for mzML) index checkers to make sure
all is well along with reindexing functionality if the index is bad.
- It should be a requirement for any reading software that uses the
index (all readers are required to be tolerant of the presence of the
wrapper schema index, but are not required to use it) to do some basic
checking that the result is correct.  E.g. if scan number 17500 is
desired and the index is used to jump to that location, it is
straightforward and necessary to ensure that the first tag read is
indeed <spectrum scan_number=3D"17500">. If it is not, the software is
free to do anything except continue as if it didn't know better (e.g.,
stop with error, revert to sequential read, or try to regenerate the
index and retry).
- While index/data mismatch is a potential source of problem, it has
been our experience that problems are rare and the benefits huge.

Regards,
Eric



> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Matthew Chambers
> Sent: Tuesday, June 19, 2007 8:46 AM
> To: 'Mike Coleman'
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] Indexing in mzML
>=20
> > On 6/19/07, Matthew Chambers <mat...@va...>
wrote:
> > > On a related note, is there any guarantee in mzML (or mzData
> > > for that matter) that the spectrum IDs or scan numbers are given
in
> > > ascending order?
> >
> > This is a good question.  I haven't read the spec closely, but if
the
> > answer isn't in there, it ought to be.  Along those lines, are IDs
and
> > scan numbers even guaranteed to be unique within a file?  (I hope
the
> > answer will be "yes".)
> >
>=20
> I think IDs are definitely unique within a file, and scan numbers will
> almost always be unique within a spectra source (multiple spectra
sources
> can be in a single mzML file though).  In our software, I use
> "SourceFileName.ScanNum.ChargeState" as a unique identifier so that
> spectra
> from multiple sources can be loaded into the same data structure.
>=20
> > > But one thing I've missed a lot in mzData (even though I think
it's a
> > > better format because of the flat spectra list) is an index to
quickly
> > > access a given scan number.
> >
> > I'm torn on this myself.  On the one hand, adding *any* redundant
> > information seems to go against the basic idea of just representing
> > the experimental data.  On the other hand, it *would* make some
> > operations more convenient.  Random access reads  become easier,
> > altering the file becomes harder, and something like XSLT
> > transformations probably become impossible (I'm not an XSLT fan
> > anyway).
>=20
> I'm not sure an index counts as redundant.  It's more like metadata
(i.e.
> I
> don't think you could call the index at the end of a textbook
redundant!).
> We already store plenty of metadata, because otherwise we'd have real
> trouble reinterpreting the data's meaning.  In fact, XML is by
definition
> loaded with metadata. :)  Random access reads wouldn't just become
easier
> -
> ease of coding is not the issue to me.  I just want random access to
not
> be
> a computational nightmare due to an excess of XML parsing.
>=20
>=20
> > One point to consider: do we think that all of the various producers
> > (and transformers) of these files will be capable of producing
correct
> > (bug-free) indices?  If they're not *always* correct, or if you have
> > to validate the file before you trust it, you're basically having to
> > recreate the index anyway.  If that's so, maybe it should just be
left
> > out of the mzML file altogether.
> >
> > It looks like indices are currently stored in a separate, optional
> > file.  This seems like a good compromise.
>=20
> >From what I've read of the minutes, and I may not have gotten the
full
> picture on this discussion, the issue of indexes is set aside at the
> moment.
> I have to say that I dislike the idea of having a separate index on
> principle, but if it would really make consistency with the main file
more
> feasible, then it's an acceptable compromise.  For example, the
optional
> index file could store a SHA-1 hash of the main mzML file.  Software
could
> test whether to trust the optional index by whether its stored hash
> matches
> a new hash on the main file.  I don't think it's unreasonable to
> (re)generate the index whenever the main file is altered (and of
course
> store the new hash).
>=20
> The optional index file method also means that the software doesn't
have
> to
> skip to the end of the file to read the index.
>=20
> Unfortunately, indexing is just a necessary evil in a world of large
> datasets.
>=20
> -Matt Chambers
>=20
>=20
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, here are the notes from today's 2006-06-19 telecon.

=20

Present: Eric Deutsch (ISB), Eva Duchoslav (Sciex), Jim Langridge =
(Waters), Ruth McNally (CESAGen), Jim Shofstahl (Thermo)

=20

Web site: All latest files and information are posted at:

http://psidev.info/index.php?q=3Dnode/257

No comments at this time.  Please examine the site and let Eric know if =
there are issues.

=20

MRM support in schema:

- Jim Shofstahl points out that for centroided mode data, the current =
implementation is good and fine, but there should the option/use case of =
profile mode MRM data where for each transition there is a m/z profile =
(like a mini MS2 scan) as well.

- Eva mentioned that in speaking with Randy, it was noted that we should =
also be able to encode the dwell time for each transition, which might =
be different for each

- Jim Langridge pointed out that it's very important to have accurate =
times for each scan. However, it was generally felt that having a time =
array might be overkill

- Jim Langridge points out that repeating the Q1 Q3 arrays over and over =
for each scan is redundant. Perhaps there could be a mechanism that =
would allow Q1 Q3s to change over time, but would not need to be =
repeated every time if the same.

- There was a discussion of chromatograms. It seemed to be agreed that =
having a mechanism to store chromatograms would be nice, but is not =
critical.  We should make sure that all kinds of chromatograms (such as =
base peak chromatograms) can be stored, not just MRM chromatograms.

=20

Jim Langridge (Waters) cannot be at EBI, but would very much like to =
review the result of the EBI workshop.

=20

After CV is revised next week, it will be sent out to all vendors and =
they will be encourage to add/suggest changes via the term tracker.

=20

Please let me know if I have forgotten to add anything.

=20

Regards,

Eric

=20

=20

________________________________

From: Eric Deutsch=20
Sent: Tuesday, June 12, 2007 9:39 AM
To: 'psi...@li...'
Cc: Eric Deutsch; 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio =
Vizca=EDno Gonz=E1lez'
Subject: RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, here are the notes from today's telecom. I would like to =
have another call in a week to discuss the possible MRM implementation =
and other items as well.  I think it would also be useful to hold =
another call the following week while several of us are at EBI.  So the =
schedule for upcoming calls is:

=20

June 19: 12n EDT

June 26: 12n EDT

=20

Please mark your calendars.  In the mean time, email discussion on the =
MRM schema would be helpful!

=20

Notes from today's con:

=20

Present: Juan Antonio, Eric, Pete

=20

- Web site

Eric: The web site has been updated with the very latest files. Please =
examine.

Feedback is welcome.

=20

- schema

Eric: I added an example for encoding MRM data. The only change to the =
schema

was adding a spectrumType attribute which would distinguish MS1, MSn, =
MRMScan,

and possibly Chromatogram.  Otherwise no change needed for this =
implementation.

There is still a list of minor mods to address, hopefully by next week.

There is a meeting at EBI in two weeks. The hope is to finish the schema =
then

and disseminate to the community as a beta test version.

=20

- MRM support

Eric: Comments on the MRM implementation? Anyone?

=20

- CV

Eric: Latest OBO file is 1.7.4.  Plans to work on this?

Pete is ready to work on this. He will add terms on the list and also =
write better definitions for some.

Eric will add link to term tracker on web site. DONE.

Pete: Individual vendors should submit their new terms to the term =
tracker. Invite them after next update.

=20

- Validator

Lennart and Luisa will work on validator

=20

=20

Action Items:

- Pete has a list of things to update in the CV and will make the =
updates.

- Eric will send the new proposed terms for this latest rev

- When Pete has finished doing any specific instrument editing, invite =
all vendor to check the list and suggest changes/additions via term =
tracker.

=20

Thanks,

Eric

=20

=20

=20

________________________________

From: Eric Deutsch=20
Sent: Tuesday, June 12, 2007 12:05 AM
To: 'psi...@li...'
Cc: 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio Vizca=EDno =
Gonz=E1lez'; Eric Deutsch
Subject: RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, it would be nice if everyone interested in MRM data would =
have a peek at the proposed MRM implementation before the conference =
call in 9 hours.

=20

The high-level summary is that data are encoded something like this =
(less relevant things removed and data arrays truncated to simplify the =
view) [also attached as a txt file in case mailers wrap the xml too =
badly]:

=20

<spectrum id=3D"S19" scanNumber=3D"19" spectrumType=3D"MRMscan">

       <spectrumHeader>

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:1000038" =
name=3D"Time" value=3D"5.890500">

                     <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:1000038" name=3D"Minutes" value=3D""/>

              </cvParam>

       </spectrumHeader>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999920" =
name=3D"DataArrayContentType" value=3D"Q1MassToChargeRatioArray"/>

              <binary>AAAAwDsGeUAAAEEnEAAAADAOg6cQA=3D=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"Q3MassToChargeRatioArray"/>

              <binary>AAAAAAGJdeUAAAABA/nAAADAOg6cQA=3D=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"IntensityArray"/>

              <binary>AAAAAIBJxkAAAAAAAIrXQAAAAAMysQA=3D=3D</binary>

       </binaryData>

</spectrum>

=20

<spectrum id=3D"S20" scanNumber=3D"20" spectrumType=3D"MSn">

       <spectrumHeader>

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:1000038" =
name=3D"TimeInMinutes" value=3D"5.990230"/>

              <precursorList count=3D"1">

                     <precursor spectrumRef=3D"19">

                            <ionSelection>

                                   <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:9999920" name=3D"TransitionArrayElementNumber" =
value=3D"2"/>

                                   <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:1000041" name=3D"ChargeState" value=3D"2"/>

                            </ionSelection>

                     </precursor>

              </precursorList>

       </spectrumHeader>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"43" encodedLength=3D"5000">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999920" =
name=3D"DataArrayContentType" value=3D"MassToChargeRatioArray"/>

              <binary>AAAAAgKCYgEA=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"43" encodedLength=3D"5000">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"IntensityArray"/>

              <binary>AAAAAAD+ AAyeQAAAAAAAWIVAAAAAAABgnUA=3D</binary>

       </binaryData>

</spectrum>

=20

(excerpted from the complete:

http://db.systemsbiology.net/projects/PSI/mzML/tiny2_MRM.mzML0.91.xml =
<http://db.systemsbiology.net/projects/PSI/mzML/tiny2_MRM.mzML0.91.xml>=20

)

=20

There are clearly some known and obvious little issues that need to be =
fixed like with the format of the CV terms, but does this capture what =
we need to write out?  This just handles the transition measurements and =
not chromatograms. Although I don't see why we couldn't allow =
chromatograms with DataArrayContentTypes of "TimeArray" and =
"IntensityArray" with some CV param annotations of the appropriate q1 =
and q3 values as well.

=20

Opinions and discussion on this would be good.

=20

Thanks,

Eric

=20

=20

_____________________________________________
From: Eric Deutsch=20
Sent: Sunday, June 10, 2007 11:40 PM
To: 'psi...@li...'
Cc: 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio Vizca=EDno =
Gonz=E1lez'; Eric Deutsch
Subject: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, this is a reminder of the conference call for the PSI MS =
working group Tuesday, 9am PDT, 12n EDT, 5pm London, 4pm GMT. Call =
information is:

=20

http://www.timeanddate.com/worldclock/fixedtime.html?day=3D12&month=3D6&y=
ear=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136 =
<http://www.timeanddate.com/worldclock/fixedtime.html?day=3D12&month=3D6&=
year=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136>=20

=20

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

=20

Agenda items are:

=20

- Status and plans for:

  - Web site

  - schema

  - MRM support

  - CV

  - validator

=20

The mzML development web page has been updated with the latest files. =
You can view them at:

=20

http://psidev.info/index.php?q=3Dnode/257 =
<http://psidev.info/index.php?q=3Dnode/257>=20

=20

The ABI/Sciex folks have described in a document how they would encode =
MRM data, which seems to be consistent with previous thoughts. I have =
updated the file tiny2_MRM.mzML0.91.xml to reflect a possible simple way =
in which MRM data might be encoded (a toy example, not containing real =
data).

=20

If you are unable to attend but wish to pass on a comment, please email =
it to me or the list.

=20

Regards,

Eric

=20

=20

=20

Re: [Psidev-ms-dev] Indexing in mzML

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

> On 6/19/07, Matthew Chambers <mat...@va...> wrote:
> > On a related note, is there any guarantee in mzML (or mzData
> > for that matter) that the spectrum IDs or scan numbers are given in
> > ascending order?
> 
> This is a good question.  I haven't read the spec closely, but if the
> answer isn't in there, it ought to be.  Along those lines, are IDs and
> scan numbers even guaranteed to be unique within a file?  (I hope the
> answer will be "yes".)
> 

I think IDs are definitely unique within a file, and scan numbers will
almost always be unique within a spectra source (multiple spectra sources
can be in a single mzML file though).  In our software, I use
"SourceFileName.ScanNum.ChargeState" as a unique identifier so that spectra
from multiple sources can be loaded into the same data structure.
 
> > But one thing I've missed a lot in mzData (even though I think it's a
> > better format because of the flat spectra list) is an index to quickly
> > access a given scan number.
> 
> I'm torn on this myself.  On the one hand, adding *any* redundant
> information seems to go against the basic idea of just representing
> the experimental data.  On the other hand, it *would* make some
> operations more convenient.  Random access reads  become easier,
> altering the file becomes harder, and something like XSLT
> transformations probably become impossible (I'm not an XSLT fan
> anyway).

I'm not sure an index counts as redundant.  It's more like metadata (i.e. I
don't think you could call the index at the end of a textbook redundant!).
We already store plenty of metadata, because otherwise we'd have real
trouble reinterpreting the data's meaning.  In fact, XML is by definition
loaded with metadata. :)  Random access reads wouldn't just become easier -
ease of coding is not the issue to me.  I just want random access to not be
a computational nightmare due to an excess of XML parsing.


> One point to consider: do we think that all of the various producers
> (and transformers) of these files will be capable of producing correct
> (bug-free) indices?  If they're not *always* correct, or if you have
> to validate the file before you trust it, you're basically having to
> recreate the index anyway.  If that's so, maybe it should just be left
> out of the mzML file altogether.
> 
> It looks like indices are currently stored in a separate, optional
> file.  This seems like a good compromise.

>From what I've read of the minutes, and I may not have gotten the full
picture on this discussion, the issue of indexes is set aside at the moment.
I have to say that I dislike the idea of having a separate index on
principle, but if it would really make consistency with the main file more
feasible, then it's an acceptable compromise.  For example, the optional
index file could store a SHA-1 hash of the main mzML file.  Software could
test whether to trust the optional index by whether its stored hash matches
a new hash on the main file.  I don't think it's unreasonable to
(re)generate the index whenever the main file is altered (and of course
store the new hash).

The optional index file method also means that the software doesn't have to
skip to the end of the file to read the index.

Unfortunately, indexing is just a necessary evil in a world of large
datasets.

-Matt Chambers

Re: [Psidev-ms-dev] Indexing in mzML

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

On 6/19/07, Matthew Chambers <mat...@va...> wrote:
> On a related note, is there any guarantee in mzML (or mzData
> for that matter) that the spectrum IDs or scan numbers are given in
> ascending order?

This is a good question.  I haven't read the spec closely, but if the
answer isn't in there, it ought to be.  Along those lines, are IDs and
scan numbers even guaranteed to be unique within a file?  (I hope the
answer will be "yes".)


> But one thing I've missed a lot in mzData (even though I think it's a
> better format because of the flat spectra list) is an index to quickly
> access a given scan number.

I'm torn on this myself.  On the one hand, adding *any* redundant
information seems to go against the basic idea of just representing
the experimental data.  On the other hand, it *would* make some
operations more convenient.  Random access reads  become easier,
altering the file becomes harder, and something like XSLT
transformations probably become impossible (I'm not an XSLT fan
anyway).

One point to consider: do we think that all of the various producers
(and transformers) of these files will be capable of producing correct
(bug-free) indices?  If they're not *always* correct, or if you have
to validate the file before you trust it, you're basically having to
recreate the index anyway.  If that's so, maybe it should just be left
out of the mzML file altogether.

It looks like indices are currently stored in a separate, optional
file.  This seems like a good compromise.

It's worth noting that these arguments also apply to the other
redundant information in the file (counts and checksums, for example).
 I wouldn't mind seeing those also moved to a separate file.  If
they're left in, maybe something should be said about what's supposed
to happen when the redundant information is inconsistent.

Mike

[Psidev-ms-dev] Indexing in mzML

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

I really like the new name for the format.  I read the meeting minutes and
such and it seems like you all have gotten the best of both formats (and
then some) into the new format; I will be happy to see mzData and mzXML go
away.  But one thing I've missed a lot in mzData (even though I think it's a
better format because of the flat spectra list) is an index to quickly
access a given scan number.  I know indexes in XML are not pretty or simple,
but I really think having one is the difference between having to load the
whole file into memory (or continually parse the file to find the desired
scan number(s)) and merely jumping right to the correct point in the file to
start parsing.  For spectra files which are a hundred megabytes or more, and
especially when reading them over a network drive, that's a very bad
proposition.  On a related note, is there any guarantee in mzML (or mzData
for that matter) that the spectrum IDs or scan numbers are given in
ascending order?  The latter guarantee would at least make the absence of an
index more tolerable when looking for some range of scan numbers.

 

Thanks,

Matt Chambers

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, this is a reminder of the conference call for the PSI MS =
working group Tuesday, 9am PDT, 12n EDT, 5pm London, 4pm GMT. Call =
information is:

=20

http://www.timeanddate.com/worldclock/fixedtime.html?day=3D19&month=3D6&y=
ear=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136

=20

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

=20

Agenda items are:

=20

- Status and plans for:

  - Web site

  - schema

  - MRM support

  - CV

  - validator

=20

The mzML development web page has been updated with the latest files. =
You can view them at:

=20

http://psidev.info/index.php?q=3Dnode/257 =
<http://psidev.info/index.php?q=3Dnode/257>=20

=20

Please review the web site material and the MRM sample snippet below for =
the call.

=20

Regards,

Eric

=20

=20

=20

________________________________

From: Eric Deutsch=20
Sent: Tuesday, June 12, 2007 9:39 AM
To: 'psi...@li...'
Cc: Eric Deutsch; 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio =
Vizca=EDno Gonz=E1lez'
Subject: RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, here are the notes from today's telecom. I would like to =
have another call in a week to discuss the possible MRM implementation =
and other items as well.  I think it would also be useful to hold =
another call the following week while several of us are at EBI.  So the =
schedule for upcoming calls is:

=20

June 19: 12n EDT

June 26: 12n EDT

=20

Please mark your calendars.  In the mean time, email discussion on the =
MRM schema would be helpful!

=20

Notes from today's con:

=20

Present: Juan Antonio, Eric, Pete

=20

- Web site

Eric: The web site has been updated with the very latest files. Please =
examine.

Feedback is welcome.

=20

- schema

Eric: I added an example for encoding MRM data. The only change to the =
schema

was adding a spectrumType attribute which would distinguish MS1, MSn, =
MRMScan,

and possibly Chromatogram.  Otherwise no change needed for this =
implementation.

There is still a list of minor mods to address, hopefully by next week.

There is a meeting at EBI in two weeks. The hope is to finish the schema =
then

and disseminate to the community as a beta test version.

=20

- MRM support

Eric: Comments on the MRM implementation? Anyone?

=20

- CV

Eric: Latest OBO file is 1.7.4.  Plans to work on this?

Pete is ready to work on this. He will add terms on the list and also =
write better definitions for some.

Eric will add link to term tracker on web site. DONE.

Pete: Individual vendors should submit their new terms to the term =
tracker. Invite them after next update.

=20

- Validator

Lennart and Luisa will work on validator

=20

=20

Action Items:

- Pete has a list of things to update in the CV and will make the =
updates.

- Eric will send the new proposed terms for this latest rev

- When Pete has finished doing any specific instrument editing, invite =
all vendor to check the list and suggest changes/additions via term =
tracker.

=20

Thanks,

Eric

=20

=20

=20

________________________________

From: Eric Deutsch=20
Sent: Tuesday, June 12, 2007 12:05 AM
To: 'psi...@li...'
Cc: 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio Vizca=EDno =
Gonz=E1lez'; Eric Deutsch
Subject: RE: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, it would be nice if everyone interested in MRM data would =
have a peek at the proposed MRM implementation before the conference =
call in 9 hours.

=20

The high-level summary is that data are encoded something like this =
(less relevant things removed and data arrays truncated to simplify the =
view) [also attached as a txt file in case mailers wrap the xml too =
badly]:

=20

<spectrum id=3D"S19" scanNumber=3D"19" spectrumType=3D"MRMscan">

       <spectrumHeader>

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:1000038" =
name=3D"Time" value=3D"5.890500">

                     <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:1000038" name=3D"Minutes" value=3D""/>

              </cvParam>

       </spectrumHeader>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999920" =
name=3D"DataArrayContentType" value=3D"Q1MassToChargeRatioArray"/>

              <binary>AAAAwDsGeUAAAEEnEAAAADAOg6cQA=3D=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"Q3MassToChargeRatioArray"/>

              <binary>AAAAAAGJdeUAAAABA/nAAADAOg6cQA=3D=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"3" encodedLength=3D"50">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"IntensityArray"/>

              <binary>AAAAAIBJxkAAAAAAAIrXQAAAAAMysQA=3D=3D</binary>

       </binaryData>

</spectrum>

=20

<spectrum id=3D"S20" scanNumber=3D"20" spectrumType=3D"MSn">

       <spectrumHeader>

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:1000038" =
name=3D"TimeInMinutes" value=3D"5.990230"/>

              <precursorList count=3D"1">

                     <precursor spectrumRef=3D"19">

                            <ionSelection>

                                   <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:9999920" name=3D"TransitionArrayElementNumber" =
value=3D"2"/>

                                   <cvParam cvLabel=3D"PSI-MS" =
accession=3D"PSI-MS:1000041" name=3D"ChargeState" value=3D"2"/>

                            </ionSelection>

                     </precursor>

              </precursorList>

       </spectrumHeader>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"43" encodedLength=3D"5000">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999920" =
name=3D"DataArrayContentType" value=3D"MassToChargeRatioArray"/>

              <binary>AAAAAgKCYgEA=3D</binary>

       </binaryData>

       <binaryData precision=3D"64" compressionType=3D"none" =
length=3D"43" encodedLength=3D"5000">

              <cvParam cvLabel=3D"PSI-MS" accession=3D"PSI-MS:9999921" =
name=3D"DataArrayContentType" value=3D"IntensityArray"/>

              <binary>AAAAAAD+ AAyeQAAAAAAAWIVAAAAAAABgnUA=3D</binary>

       </binaryData>

</spectrum>

=20

(excerpted from the complete:

http://db.systemsbiology.net/projects/PSI/mzML/tiny2_MRM.mzML0.91.xml =
<http://db.systemsbiology.net/projects/PSI/mzML/tiny2_MRM.mzML0.91.xml>=20

)

=20

There are clearly some known and obvious little issues that need to be =
fixed like with the format of the CV terms, but does this capture what =
we need to write out?  This just handles the transition measurements and =
not chromatograms. Although I don't see why we couldn't allow =
chromatograms with DataArrayContentTypes of "TimeArray" and =
"IntensityArray" with some CV param annotations of the appropriate q1 =
and q3 values as well.

=20

Opinions and discussion on this would be good.

=20

Thanks,

Eric

=20

=20

_____________________________________________
From: Eric Deutsch=20
Sent: Sunday, June 10, 2007 11:40 PM
To: 'psi...@li...'
Cc: 'Trish Whetzel'; 'Puneet Souda'; 'Juan Antonio Vizca=EDno =
Gonz=E1lez'; Eric Deutsch
Subject: PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

=20

Hi everyone, this is a reminder of the conference call for the PSI MS =
working group Tuesday, 9am PDT, 12n EDT, 5pm London, 4pm GMT. Call =
information is:

=20

http://www.timeanddate.com/worldclock/fixedtime.html?day=3D12&month=3D6&y=
ear=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136 =
<http://www.timeanddate.com/worldclock/fixedtime.html?day=3D12&month=3D6&=
year=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136>=20

=20

phone numbers are:

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

=20

Agenda items are:

=20

- Status and plans for:

  - Web site

  - schema

  - MRM support

  - CV

  - validator

=20

The mzML development web page has been updated with the latest files. =
You can view them at:

=20

http://psidev.info/index.php?q=3Dnode/257 =
<http://psidev.info/index.php?q=3Dnode/257>=20

=20

The ABI/Sciex folks have described in a document how they would encode =
MRM data, which seems to be consistent with previous thoughts. I have =
updated the file tiny2_MRM.mzML0.91.xml to reflect a possible simple way =
in which MRM data might be encoded (a toy example, not containing real =
data).

=20

If you are unable to attend but wish to pass on a comment, please email =
it to me or the list.

=20

Regards,

Eric

=20

=20

=20

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

PHNwZWN0cnVtIGlkPSJTMTkiIHNjYW5OdW1iZXI9IjE5IiBzcGVjdHJ1bVR5cGU9Ik1STXNjYW4i
Pg0KCTxzcGVjdHJ1bUhlYWRlcj4NCgkJPGN2UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Np
b249IlBTSS1NUzoxMDAwMDM4IiBuYW1lPSJUaW1lIiB2YWx1ZT0iNS44OTA1MDAiPg0KCQkJPGN2
UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Npb249IlBTSS1NUzoxMDAwMDM4IiBuYW1lPSJN
aW51dGVzIiB2YWx1ZT0iIi8+DQoJCTwvY3ZQYXJhbT4NCgk8L3NwZWN0cnVtSGVhZGVyPg0KCTxi
aW5hcnlEYXRhIHByZWNpc2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3RoPSIz
IiBlbmNvZGVkTGVuZ3RoPSI1MCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIgYWNjZXNz
aW9uPSJQU0ktTVM6OTk5OTkyMCIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZhbHVlPSJR
MU1hc3NUb0NoYXJnZVJhdGlvQXJyYXkiLz4NCgkJPGJpbmFyeT5BQUFBd0RzR2VVQUFBRUVuRUFB
QUFEQU9nNmNRQT09PC9iaW5hcnk+DQoJPC9iaW5hcnlEYXRhPg0KCTxiaW5hcnlEYXRhIHByZWNp
c2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3RoPSIzIiBlbmNvZGVkTGVuZ3Ro
PSI1MCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6OTk5
OTkyMSIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZhbHVlPSJRM01hc3NUb0NoYXJnZVJh
dGlvQXJyYXkiLz4NCgkJPGJpbmFyeT5BQUFBQUFHSmRlVUFBQUFCQS9uQUFBREFPZzZjUUE9PTwv
YmluYXJ5Pg0KCTwvYmluYXJ5RGF0YT4NCgk8YmluYXJ5RGF0YSBwcmVjaXNpb249IjY0IiBjb21w
cmVzc2lvblR5cGU9Im5vbmUiIGxlbmd0aD0iMyIgZW5jb2RlZExlbmd0aD0iNTAiPg0KCQk8Y3ZQ
YXJhbSBjdkxhYmVsPSJQU0ktTVMiIGFjY2Vzc2lvbj0iUFNJLU1TOjk5OTk5MjEiIG5hbWU9IkRh
dGFBcnJheUNvbnRlbnRUeXBlIiB2YWx1ZT0iSW50ZW5zaXR5QXJyYXkiLz4NCgkJPGJpbmFyeT5B
QUFBQUlCSnhrQUFBQUFBQUlyWFFBQUFBQU15c1FBPT08L2JpbmFyeT4NCgk8L2JpbmFyeURhdGE+
DQo8L3NwZWN0cnVtPg0KDQo8c3BlY3RydW0gaWQ9IlMyMCIgc2Nhbk51bWJlcj0iMjAiIHNwZWN0
cnVtVHlwZT0iTVNuIj4NCgk8c3BlY3RydW1IZWFkZXI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBT
SS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6MTAwMDAzOCIgbmFtZT0iVGltZUluTWludXRlcyIgdmFs
dWU9IjUuOTkwMjMwIi8+DQoJCTxwcmVjdXJzb3JMaXN0IGNvdW50PSIxIj4NCgkJCTxwcmVjdXJz
b3Igc3BlY3RydW1SZWY9IjE5Ij4NCgkJCQk8aW9uU2VsZWN0aW9uPg0KCQkJCQk8Y3ZQYXJhbSBj
dkxhYmVsPSJQU0ktTVMiIGFjY2Vzc2lvbj0iUFNJLU1TOjk5OTk5MjAiIG5hbWU9IlRyYW5zaXRp
b25BcnJheUVsZW1lbnROdW1iZXIiIHZhbHVlPSIyIi8+DQoJCQkJCTxjdlBhcmFtIGN2TGFiZWw9
IlBTSS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6MTAwMDA0MSIgbmFtZT0iQ2hhcmdlU3RhdGUiIHZh
bHVlPSIyIi8+DQoJCQkJPC9pb25TZWxlY3Rpb24+DQoJCQk8L3ByZWN1cnNvcj4NCgkJPC9wcmVj
dXJzb3JMaXN0Pg0KCTwvc3BlY3RydW1IZWFkZXI+DQoJPGJpbmFyeURhdGEgcHJlY2lzaW9uPSI2
NCIgY29tcHJlc3Npb25UeXBlPSJub25lIiBsZW5ndGg9IjQzIiBlbmNvZGVkTGVuZ3RoPSI1MDAw
Ij4NCgkJPGN2UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Npb249IlBTSS1NUzo5OTk5OTIw
IiBuYW1lPSJEYXRhQXJyYXlDb250ZW50VHlwZSIgdmFsdWU9Ik1hc3NUb0NoYXJnZVJhdGlvQXJy
YXkiLz4NCgkJPGJpbmFyeT5BQUFBQWdLQ1lnRUE9PC9iaW5hcnk+DQoJPC9iaW5hcnlEYXRhPg0K
CTxiaW5hcnlEYXRhIHByZWNpc2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3Ro
PSI0MyIgZW5jb2RlZExlbmd0aD0iNTAwMCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIg
YWNjZXNzaW9uPSJQU0ktTVM6OTk5OTkyMSIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZh
bHVlPSJJbnRlbnNpdHlBcnJheSIvPg0KCQk8YmluYXJ5PkFBQUFBQUQrIEFBeWVRQUFBQUFBQVdJ
VkFBQUFBQUFCZ25VQT08L2JpbmFyeT4NCgk8L2JpbmFyeURhdGE+DQo8L3NwZWN0cnVtPg0K

Re: [Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

PHNwZWN0cnVtIGlkPSJTMTkiIHNjYW5OdW1iZXI9IjE5IiBzcGVjdHJ1bVR5cGU9Ik1STXNjYW4i
Pg0KCTxzcGVjdHJ1bUhlYWRlcj4NCgkJPGN2UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Np
b249IlBTSS1NUzoxMDAwMDM4IiBuYW1lPSJUaW1lIiB2YWx1ZT0iNS44OTA1MDAiPg0KCQkJPGN2
UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Npb249IlBTSS1NUzoxMDAwMDM4IiBuYW1lPSJN
aW51dGVzIiB2YWx1ZT0iIi8+DQoJCTwvY3ZQYXJhbT4NCgk8L3NwZWN0cnVtSGVhZGVyPg0KCTxi
aW5hcnlEYXRhIHByZWNpc2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3RoPSIz
IiBlbmNvZGVkTGVuZ3RoPSI1MCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIgYWNjZXNz
aW9uPSJQU0ktTVM6OTk5OTkyMCIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZhbHVlPSJR
MU1hc3NUb0NoYXJnZVJhdGlvQXJyYXkiLz4NCgkJPGJpbmFyeT5BQUFBd0RzR2VVQUFBRUVuRUFB
QUFEQU9nNmNRQT09PC9iaW5hcnk+DQoJPC9iaW5hcnlEYXRhPg0KCTxiaW5hcnlEYXRhIHByZWNp
c2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3RoPSIzIiBlbmNvZGVkTGVuZ3Ro
PSI1MCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6OTk5
OTkyMSIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZhbHVlPSJRM01hc3NUb0NoYXJnZVJh
dGlvQXJyYXkiLz4NCgkJPGJpbmFyeT5BQUFBQUFHSmRlVUFBQUFCQS9uQUFBREFPZzZjUUE9PTwv
YmluYXJ5Pg0KCTwvYmluYXJ5RGF0YT4NCgk8YmluYXJ5RGF0YSBwcmVjaXNpb249IjY0IiBjb21w
cmVzc2lvblR5cGU9Im5vbmUiIGxlbmd0aD0iMyIgZW5jb2RlZExlbmd0aD0iNTAiPg0KCQk8Y3ZQ
YXJhbSBjdkxhYmVsPSJQU0ktTVMiIGFjY2Vzc2lvbj0iUFNJLU1TOjk5OTk5MjEiIG5hbWU9IkRh
dGFBcnJheUNvbnRlbnRUeXBlIiB2YWx1ZT0iSW50ZW5zaXR5QXJyYXkiLz4NCgkJPGJpbmFyeT5B
QUFBQUlCSnhrQUFBQUFBQUlyWFFBQUFBQU15c1FBPT08L2JpbmFyeT4NCgk8L2JpbmFyeURhdGE+
DQo8L3NwZWN0cnVtPg0KDQo8c3BlY3RydW0gaWQ9IlMyMCIgc2Nhbk51bWJlcj0iMjAiIHNwZWN0
cnVtVHlwZT0iTVNuIj4NCgk8c3BlY3RydW1IZWFkZXI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBT
SS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6MTAwMDAzOCIgbmFtZT0iVGltZUluTWludXRlcyIgdmFs
dWU9IjUuOTkwMjMwIi8+DQoJCTxwcmVjdXJzb3JMaXN0IGNvdW50PSIxIj4NCgkJCTxwcmVjdXJz
b3Igc3BlY3RydW1SZWY9IjE5Ij4NCgkJCQk8aW9uU2VsZWN0aW9uPg0KCQkJCQk8Y3ZQYXJhbSBj
dkxhYmVsPSJQU0ktTVMiIGFjY2Vzc2lvbj0iUFNJLU1TOjk5OTk5MjAiIG5hbWU9IlRyYW5zaXRp
b25BcnJheUVsZW1lbnROdW1iZXIiIHZhbHVlPSIyIi8+DQoJCQkJCTxjdlBhcmFtIGN2TGFiZWw9
IlBTSS1NUyIgYWNjZXNzaW9uPSJQU0ktTVM6MTAwMDA0MSIgbmFtZT0iQ2hhcmdlU3RhdGUiIHZh
bHVlPSIyIi8+DQoJCQkJPC9pb25TZWxlY3Rpb24+DQoJCQk8L3ByZWN1cnNvcj4NCgkJPC9wcmVj
dXJzb3JMaXN0Pg0KCTwvc3BlY3RydW1IZWFkZXI+DQoJPGJpbmFyeURhdGEgcHJlY2lzaW9uPSI2
NCIgY29tcHJlc3Npb25UeXBlPSJub25lIiBsZW5ndGg9IjQzIiBlbmNvZGVkTGVuZ3RoPSI1MDAw
Ij4NCgkJPGN2UGFyYW0gY3ZMYWJlbD0iUFNJLU1TIiBhY2Nlc3Npb249IlBTSS1NUzo5OTk5OTIw
IiBuYW1lPSJEYXRhQXJyYXlDb250ZW50VHlwZSIgdmFsdWU9Ik1hc3NUb0NoYXJnZVJhdGlvQXJy
YXkiLz4NCgkJPGJpbmFyeT5BQUFBQWdLQ1lnRUE9PC9iaW5hcnk+DQoJPC9iaW5hcnlEYXRhPg0K
CTxiaW5hcnlEYXRhIHByZWNpc2lvbj0iNjQiIGNvbXByZXNzaW9uVHlwZT0ibm9uZSIgbGVuZ3Ro
PSI0MyIgZW5jb2RlZExlbmd0aD0iNTAwMCI+DQoJCTxjdlBhcmFtIGN2TGFiZWw9IlBTSS1NUyIg
YWNjZXNzaW9uPSJQU0ktTVM6OTk5OTkyMSIgbmFtZT0iRGF0YUFycmF5Q29udGVudFR5cGUiIHZh
bHVlPSJJbnRlbnNpdHlBcnJheSIvPg0KCQk8YmluYXJ5PkFBQUFBQUQrIEFBeWVRQUFBQUFBQVdJ
VkFBQUFBQUFCZ25VQT08L2JpbmFyeT4NCgk8L2JpbmFyeURhdGE+DQo8L3NwZWN0cnVtPg0K

[Psidev-ms-dev] PSI-MS WG ccall Tue 9am PDT, 12n EDT, 4pm GMT

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

Hi everyone, this is a reminder of the conference call for the PSI MS =
working group Tuesday, 9am PDT, 12n EDT, 5pm London, 4pm GMT. Call =
information is:

http://www.timeanddate.com/worldclock/fixedtime.html?day=3D12&month=3D6&y=
ear=3D2007&hour=3D17&min=3D0&sec=3D0&p1=3D136

phone numbers are:
+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)
access code: 297427

Agenda items are:

- Status and plans for:
  - Web site
  - schema
  - MRM support
  - CV
  - validator

The mzML development web page has been updated with the latest files. =
You can view them at:

http://psidev.info/index.php?q=3Dnode/257

The ABI/Sciex folks have described in a document how they would encode =
MRM data, which seems to be consistent with previous thoughts. I have =
updated the file tiny2_MRM.mzML0.91.xml to reflect a possible simple way =
in which MRM data might be encoded (a toy example, not containing real =
data).

If you are unable to attend but wish to pass on a comment, please email =
it to me or the list.

Regards,
Eric

Re: [Psidev-ms-dev] PSI @ASMS?

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

Hi Angel,
sorry, I already did that mistake in DC I think. And thanks for 
correcting also that you will not ba at ASMS.
Pierre-Alain

Angel Pizarro wrote:
> Hi Pierre-Alain,
>
> You spelled my last name wrong, it is "Pizarro". Also I won't be at 
> ASMS this year.
>  
> -angel
>
> On 5/23/07, *Pierre-Alain Binz * <pie...@is... 
> <mailto:pie...@is...>> wrote:
>
>     Saying this,
>     if anyone is interested to be up to date with the activities of PSI,
>
>     1) the http://psidev.info website is containing the status for
>     each group.
>     2) at ASMS, a good number of "active members" of PSI will be there
>     (here I mean people with roles and responsibilities within the PSI
>     structure as presented in the PSI organigram at
>     http://psidev.info/index.php?q=node/202). Take the opportunity to
>     talk to them. Here just a selection of them (restriction to the
>     PI, MS and MOD groups, people aware of the latest activities,
>     post-Lyon meeting):
>     Eric Deutsch (ISB), David Creasy (Matrix Science), Angel Pizzarro
>     (U Penn), Pierre-Alain Binz (SIB/GeneBio), Jim Shofsthal
>     (Thermo-Fisher), Sean Seymour (Applied Biosystems-MDS Sciex).
>     Others might
>
>     Pierre-Alain
>
>
>     David Creasy wrote:
>>     Hello Susan,
>>     No, I'm afraid that there won't be any PSI activities at ASMS this year. 
>>       There will be a PSI session at HUPO in Korea later on in the year if 
>>     you are going there.
>>
>>     David
>>
>>     Susan M. Kennedy wrote:
>>       
>>>     Hello PSI Folks,  I was wondering if there will be any PSI activities at ASMS?
>>>     Thanks,
>>>     Susan
>>>
>>>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>     Susan M Kennedy
>>>     Asst. Manager for Protein Services
>>>     MB & Proteomic Core Facility
>>>     NCCC Rubin BLD HB7937
>>>     One Medical CTR Drive
>>>     Lebanon NH 03756
>>>     ph.  603-653-6188
>>>     sm...@da... <mailto:sm...@da...>
>>>     http://www.dartmouth.edu/~mbcf/ <http://www.dartmouth.edu/%7Embcf/>
>>>
>>>     -------------------------------------------------------------------------
>>>     This SF.net email is sponsored by DB2 Express
>>>     Download DB2 Express C - the FREE version of DB2 express and take
>>>     control of your XML. No limits. Just data. Click to get it now.
>>>     http://sourceforge.net/powerbar/db2/
>>>     _______________________________________________
>>>     Psidev-ms-dev mailing list
>>>     Psi...@li... <mailto:Psi...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>         
>>       
>
>     -- 
>     --
>      Dr. Pierre-Alain Binz
>      Swiss Institute of Bioinformatics
>      Proteome Informatics Group
>      1, Rue Michel Servet
>      CH-1211 Geneve 4
>      Switzerland
>      - - - - - - - - - - - - - - - - -
>      Tel: +41-22-379 50 50
>      Fax: +41-22-379 58 58
>      Pie...@is... <mailto:Pie...@is...>
>      http://www.expasy.org/people/Pierre-Alain.Binz.html
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by DB2 Express
>     Download DB2 Express C - the FREE version of DB2 express and take
>     control of your XML. No limits. Just data. Click to get it now.
>     http://sourceforge.net/powerbar/db2/
>     _______________________________________________
>     Psidev-ms-dev mailing list
>     Psi...@li...
>     <mailto:Psi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
>
> -- 
> Angel Pizarro
> Director, Bioinformatics Facility
> Institute for Translational Medicine and Therapeutics
> University of Pennsylvania
> 806 BRB II/III
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
>
> P: 215-573-3736
> F: 215-573-9004 

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

Re: [Psidev-ms-dev] PSI @ASMS?

[Angel P. <an...@ma...>]

Hi Pierre-Alain,

You spelled my last name wrong, it is "Pizarro". Also I won't be at ASMS
this year.

-angel

On 5/23/07, Pierre-Alain Binz <pie...@is...> wrote:
>
>  Saying this,
> if anyone is interested to be up to date with the activities of PSI,
>
> 1) the http://psidev.info website is containing the status for each group.
>
> 2) at ASMS, a good number of "active members" of PSI will be there (here I
> mean people with roles and responsibilities within the PSI structure as
> presented in the PSI organigram at http://psidev.info/index.php?q=node/202).
> Take the opportunity to talk to them. Here just a selection of them
> (restriction to the PI, MS and MOD groups, people aware of the latest
> activities, post-Lyon meeting):
> Eric Deutsch (ISB), David Creasy (Matrix Science), Angel Pizzarro (U
> Penn), Pierre-Alain Binz (SIB/GeneBio), Jim Shofsthal (Thermo-Fisher), Sean
> Seymour (Applied Biosystems-MDS Sciex). Others might
>
> Pierre-Alain
>
>
> David Creasy wrote:
>
> Hello Susan,
> No, I'm afraid that there won't be any PSI activities at ASMS this year.
>   There will be a PSI session at HUPO in Korea later on in the year if
> you are going there.
>
> David
>
> Susan M. Kennedy wrote:
>
>
>  Hello PSI Folks,  I was wondering if there will be any PSI activities at ASMS?
> Thanks,
> Susan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Susan M Kennedy
> Asst. Manager for Protein Services
> MB & Proteomic Core Facility
> NCCC Rubin BLD HB7937
> One Medical CTR Drive
> Lebanon NH 03756
> ph.  603...@da...http://www.dartmouth.edu/~mbcf/ <http://www.dartmouth.edu/%7Embcf/>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> --
> --
>  Dr. Pierre-Alain Binz
>  Swiss Institute of Bioinformatics
>  Proteome Informatics Group
>  1, Rue Michel Servet
>  CH-1211 Geneve 4
>  Switzerland
>  - - - - - - - - - - - - - - - - -
>  Tel: +41-22-379 50 50
>  Fax: +41-22-379 58 58
>  Pie...@is...
>  http://www.expasy.org/people/Pierre-Alain.Binz.html
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>


-- 
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

Re: [Psidev-ms-dev] PSI @ASMS?

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

Saying this,
if anyone is interested to be up to date with the activities of PSI,

1) the http://psidev.info website is containing the status for each group.
2) at ASMS, a good number of "active members" of PSI will be there (here 
I mean people with roles and responsibilities within the PSI structure 
as presented in the PSI organigram at 
http://psidev.info/index.php?q=node/202). Take the opportunity to talk 
to them. Here just a selection of them (restriction to the PI, MS and 
MOD groups, people aware of the latest activities, post-Lyon meeting):
Eric Deutsch (ISB), David Creasy (Matrix Science), Angel Pizzarro (U 
Penn), Pierre-Alain Binz (SIB/GeneBio), Jim Shofsthal (Thermo-Fisher), 
Sean Seymour (Applied Biosystems-MDS Sciex). Others might

Pierre-Alain


David Creasy wrote:
> Hello Susan,
> No, I'm afraid that there won't be any PSI activities at ASMS this year. 
>   There will be a PSI session at HUPO in Korea later on in the year if 
> you are going there.
>
> David
>
> Susan M. Kennedy wrote:
>   
>> Hello PSI Folks,  I was wondering if there will be any PSI activities at ASMS?
>> Thanks,
>> Susan
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Susan M Kennedy
>> Asst. Manager for Protein Services
>> MB & Proteomic Core Facility
>> NCCC Rubin BLD HB7937
>> One Medical CTR Drive
>> Lebanon NH 03756
>> ph.  603-653-6188
>> sm...@da...
>> http://www.dartmouth.edu/~mbcf/
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
>   

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

Re: [Psidev-ms-dev] PSI @ASMS?

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

Hello Susan,
No, I'm afraid that there won't be any PSI activities at ASMS this year. 
  There will be a PSI session at HUPO in Korea later on in the year if 
you are going there.

David

Susan M. Kennedy wrote:
> Hello PSI Folks,  I was wondering if there will be any PSI activities at ASMS?
> Thanks,
> Susan
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Susan M Kennedy
> Asst. Manager for Protein Services
> MB & Proteomic Core Facility
> NCCC Rubin BLD HB7937
> One Medical CTR Drive
> Lebanon NH 03756
> ph.  603-653-6188
> sm...@da...
> http://www.dartmouth.edu/~mbcf/
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

[Psidev-ms-dev] Notes for the teleconference dd. 15 May 2007

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

Dear PSI-MS enthousiasts,


Please find the minutes for the PSI-MS phone conference dd. 15 May 2007 
here:

http://www.psidev.info/index.php?q=node/285

These minutes can also be accessed from the event on the calendar on the 
PSI website (www.psidev.info), as well as from the 'Meeting reports' 
section on the PSI MS homepage:

http://www.psidev.info/index.php?q=node/80#meetingReports

If there are any comments, remarks or additions for these minutes (e.g.: 
I misspelled your name), please let me know.

Finally, the next PSI-MS phone conference has been inserted in the 
agenda, and the event has been linked from the current meeting minutes.


PS: For those of you who have not noticed, the website now sports a 
fully functional search box as well. The index for this search 
functionality is renewed every night, so any new content you add should 
be indexed after at most 24 hours (and the inverse goes for removed 
content).


Cheers,

lnnrt.

Re: [Psidev-ms-dev] Referendum for 'mzML/runList/run/dataGroupList' in mzML (used to be dataXML)

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

Thanks Josh for keeping our memory alive!
Right. The use cases were:
1) point to spectra of interest within the full list and annotate them 
with some data (as you said, list "good" or "bad" scans)
2) associate information to only a portion of a spectrum (for instance 
charge states of some fragment ions, labels or annotations to specific 
peaks)

Therefore clearly optional, but specs need to be done in case of use.

Pierre-Alain


Joshua Tasman wrote:
> I believe the original intention was to have a mechanism for denoting 
> subsets of spectra; each subset of interest would be one "data group". 
> I don't remember this being an essential feature, but one that would 
> assist in processing, for example by grouping all "good" scans 
> (presumably determined by some external program.)
>
> Hope this helps,
>
> Josh
>
>
> Lennart Martens wrote:
>   
>> Dear PSI-MS enthousiasts,
>>
>>
>> During the PSI meeting in Lyon in April, concerns were raised about the
>> 'mzML/runList/run/dataGroupList' element in mzML (originally dataXML).
>>
>> This element is a bit of a monster (essentially a placeholder for lists
>> that each can contain anything at all).
>>
>> Since no one present at the meeting could remember exactly why this
>> element should be there, it was decided to forward this on to the
>> mailing list for a final consultation.
>>
>> You can find the current draft of the schema, an XML Spy image of the 
>> element and the information in this mail on the PSI website as well, at 
>> the following link:
>>
>> http://www.psidev.info/index.php?q=node/283
>>
>> Note that you can directly make comments on this site as well.
>>
>> The following proposal is made: if you feel that this element should
>> remain in place, please send your motivation to the list or post it on 
>> the above webpage BEFORE Monday, 18th of June 2007.
>>
>> If a good reason for maintaining this element hasn't surfaced by that
>> time, the element will be retired from the schema.
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>   

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

Re: [Psidev-ms-dev] Referendum for 'mzML/runList/run/dataGroupList' in mzML (used to be dataXML)

[Joshua T. <jt...@sy...>]

I believe the original intention was to have a mechanism for denoting 
subsets of spectra; each subset of interest would be one "data group". 
I don't remember this being an essential feature, but one that would 
assist in processing, for example by grouping all "good" scans 
(presumably determined by some external program.)

Hope this helps,

Josh


Lennart Martens wrote:
> Dear PSI-MS enthousiasts,
> 
> 
> During the PSI meeting in Lyon in April, concerns were raised about the
> 'mzML/runList/run/dataGroupList' element in mzML (originally dataXML).
> 
> This element is a bit of a monster (essentially a placeholder for lists
> that each can contain anything at all).
> 
> Since no one present at the meeting could remember exactly why this
> element should be there, it was decided to forward this on to the
> mailing list for a final consultation.
> 
> You can find the current draft of the schema, an XML Spy image of the 
> element and the information in this mail on the PSI website as well, at 
> the following link:
> 
> http://www.psidev.info/index.php?q=node/283
> 
> Note that you can directly make comments on this site as well.
> 
> The following proposal is made: if you feel that this element should
> remain in place, please send your motivation to the list or post it on 
> the above webpage BEFORE Monday, 18th of June 2007.
> 
> If a good reason for maintaining this element hasn't surfaced by that
> time, the element will be retired from the schema.
> 
> 
> Cheers,
> 
> lnnrt.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] PSI @ASMS?

[<Sus...@Da...>]

Hello PSI Folks,  I was wondering if there will be any PSI activities at ASMS?
Thanks,
Susan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Susan M Kennedy
Asst. Manager for Protein Services
MB & Proteomic Core Facility
NCCC Rubin BLD HB7937
One Medical CTR Drive
Lebanon NH 03756
ph.  603-653-6188
sm...@da...
http://www.dartmouth.edu/~mbcf/

[Psidev-ms-dev] Referendum for 'mzML/runList/run/dataGroupList' in mzML (used to be dataXML)

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

Dear PSI-MS enthousiasts,


During the PSI meeting in Lyon in April, concerns were raised about the
'mzML/runList/run/dataGroupList' element in mzML (originally dataXML).

This element is a bit of a monster (essentially a placeholder for lists
that each can contain anything at all).

Since no one present at the meeting could remember exactly why this
element should be there, it was decided to forward this on to the
mailing list for a final consultation.

You can find the current draft of the schema, an XML Spy image of the 
element and the information in this mail on the PSI website as well, at 
the following link:

http://www.psidev.info/index.php?q=node/283

Note that you can directly make comments on this site as well.

The following proposal is made: if you feel that this element should
remain in place, please send your motivation to the list or post it on 
the above webpage BEFORE Monday, 18th of June 2007.

If a good reason for maintaining this element hasn't surfaced by that
time, the element will be retired from the schema.


Cheers,

lnnrt.

[Psidev-ms-dev] PSI-MS WG conference call, 15 May

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

Dear PSI-MS participants,


The next PSI-MS phone conference is scheduled to take place on Tuesday, 
15th of May, at a time near you as indicated on the URL below (cheat 
sheet: 17.00 UK time, 18.00 European continental time, 09.00 Seattle time).


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


- Phone numbers:

   + Germany: 08001012079

   + Switzerland: 0800000860

   + UK: 08081095644

   + USA: 1-866-314-3683

   + Generic international: +44 2083222500 (UK number)

access code: 297427


Hope to hear you all then,


Best regards,

lnnrt.

[Psidev-ms-dev] Missing File on psidev.info

[Thomas S. <sp...@ts...>]

Hello,

I am looking for the most recent version of MzData_1.05_spec.doc (or any 
more recent version number), which was published on your page a while 
ago. Meanwhile, it seems to have vanished from there (or I'm too 
confused to find it).

Can you point me to the current location? Thank you.


Best regards


Thomas Schreiner

PS. Please CC your answer to me, I don't know if the subscription worked.

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

[Coleman, M. <MK...@St...>]

> I sincerely doubt that any instrument vendor will use dataxml as their
native format

I can dream, anyway...

Re: [Psidev-ms-dev] Separate binary file for very large data sets?

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

The odds of zlib actually expanding the data are pretty slim unless the =
data
is thoroughly random, in which case you probably don't want it anyway.
Easy enough to check for this, of course, and elect to write it out
uncompressed (which I guess shoots down my "mandatory" goal, oh well).
=20
Zlib is a pretty small and self contained library (and fairly dumb =
itself!),
I don't think it would be a problem even for an embedded system to use =
it.
=20
Brian

  _____ =20

From: psi...@li...
[mailto:psi...@li...] On Behalf Of =
Coleman,
Michael
Sent: Friday, April 20, 2007 1:15 PM
To: Brian Pratt; Angel Pizarro
Cc: psi...@li...; Andreas R=F6mpp
Subject: Re: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Angel, thanks for the clarification. =20
=20
I agree that there'd generally be no reason not to zlib-compress--the =
base64
string is already quite opaque.  The only factors I'd see would be (a)
occasionally zlib will make strings larger (though not by too much), and =
(b)
whether it'd be a burden for dumb instruments to have to know zlib.
=20
Mike
=20

-----Original Message-----
From: Brian Pratt [mailto:bri...@in...]=20
Sent: Friday, April 20, 2007 3:04 PM
To: 'Angel Pizarro'; Coleman, Michael
Cc: psi...@li...; 'Andreas R=F6mpp'
Subject: RE: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Angel is correct - I did mean compression (base64 encoding actually =
bloats
the data a bit). =20
=20
I believe the proposed next version of mzData adopts Patrick Pedrioli's
mzXML 3.0 technique of optionally first compressing (with zlib) the =
binary
data before encoding it (with base64).    I'd argue for making it =
manditory,
since it's not like there's any loss of human-readability, and the files =
do
shrink admirably.
=20
- Brian

  _____ =20

From: psi...@li...
[mailto:psi...@li...] On Behalf Of Angel
Pizarro
Sent: Friday, April 20, 2007 12:43 PM
To: Coleman, Michael
Cc: psi...@li...; Brian Pratt; Andreas R=F6mpp
Subject: Re: [Psidev-ms-dev] Separate binary file for very large data =
sets?


Brian is refering to the way mzXML 3.0 (and the new dataXML format) zlib
compress the "base64-encoded" spectra. While not an official part of the
mzData 1.05 schema, I believe there are several groups that use this
technique in-house for storage of mzData files.=20

-angel



On 4/20/07, Coleman, Michael <MK...@st...> wrote:=20

If by "compressed" you mean "base64-encoded", I think it's important to =
use
the latter term, to avoid giving the wrong impression.  As far as I =
know,
compression is not a feature--nor a goal--of mzData.=20

For what it's worth, I encountered my first mzData file in a work =
situation
this week.  It's 2.7 times as large as the corresponding ms2 file.

Mike



> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Brian Pratt
> Sent: Friday, April 20, 2007 2:02 PM
> To: 'Andreas R=F6mpp'; psi...@li...
> Subject: Re: [Psidev-ms-dev] Separate binary file for very=20
> large data sets?
>
>
> I wonder if it wouldn't make as much sense to treat the
> mzData file as the
> "binary file" and come up with a sort of summary schema of
> your own that=20
> could point into the mzData file.  You'd get maximum reuse of
> community
> source code that way.
>
> But first, I'd say try it with straight-up mzData with
> compressed peak lists=20
> and see if you really need to go to the bother of a separate
> file.  I'm
> guessing you'll be pleasantly surprised.  Plus, I really,
> really dislike the
> use of interdependent files - one or the other is forever=20
> getting out of
> synch, lost, renamed, etc.
>
> Hope this helps,
>
> Brian Pratt
> www.insilicos.com
>
> -----Original Message-----=20
> From: psi...@li...
> [mailto:psi...@li...
<mailto:psi...@li...> ] On
> Behalf Of Andreas
> R=F6mpp
> Sent: Friday, April 20, 2007 8:45 AM
> To: psi...@li...;
> And...@an...
> Subject: [Psidev-ms-dev] Separate binary file for very large
> data sets?
>
> Hello everybody,
>
> We develop software for imaging mass spectrometry in the=20
> framework of a
> project funded by the European Union. We intend to use
> dataXML as a standard
> format to exchange data between the different partner labs
> and also (as far
> as possible) as the internal data format for a joint=20
> processing software
> suite. However, we run into the problem of very large data
> sets which can
> easily exceed 1GB (e.g. 256
> *256 pixels with one high resolution mass spectrum each). Therefore we =

> thought about storing the spectrum data
> ('MassToChargeRatioArray' and '
> 'IntensityArray') in a separate binary file. This would make
> data handling
> much faster and easier ( e.g. when parsing the XML file). So instead =
of
> writing the binary data in the XML file we plan to include a link to a
> separate file (file location, start and end position of
> spectrum in binary
> file).=20
> This problem is somewhat similar to the already discussed
> issue of an index
> file.
> Would it be possible to include such an option (external
> binary file) into
> the dataXML standard?=20
>
> Best regards,
> Andreas
>
> --
> --------------------------------------------------------------
> --------------
> -------------
> Dr. Andreas Roempp
> Institute of Inorganic and Analytical Chemistry=20
> - Analytical Chemistry -
> Justus Liebig University Giessen
> Schubertstrasse 60, Build. 16
> D-35392 Giessen
> Germany
>
> phone:  +49-641-99 34802
> fax:    +49-641-99 34809=20
> email: And...@an...
> Internet: http://www.uni-giessen.de/analytik/
<http://www.uni-giessen.de/analytik/>=20
>
>
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express Download DB2
> Express C - the
> FREE version of DB2 express and take control of your XML. No
> limits. Just
> data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express=20
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
<http://sourceforge.net/powerbar/db2/>=20
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take=20
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Psidev-ms-dev mailing list=20
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
<https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev>=20





--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.=20
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004=20