Menu
▾
▴
psidev-ms-dev
|
From: Eric D. <ede...@sy...> - 2008-05-27 17:38:33
|
Hi everyone, there are the minutes for the telecon of 2008-05-27.
Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim
- schema
+ Discussed Matt's <precursor> issue 2008-05-26
+ Leave the schema as is? Have the semval require <precursor> in certain
cases?
+ Matt will try to make an example of putting the SRM precursor
information in <targetList> and refer to it
+ Document why checksum should be required.
+ Reply to Wilfred
+ Document that by default the validator doesn't allow anything beyond
what is listed in the mapping file
+ Stay at release 0.99.12 for now. Convert to 1.0.0 later this week when
ready.
- MIAPE example document?
+ Done except for switching criteria and parameters for creating
peaklists
+ Pierre-Alain and Jim will get together and finish this
+ State of MIAPE-MS
- CV status
+ Darren has sent a proposal for of datatype and relationship
"has_units"
+ OBO-Edit will write out all terms including imported terms unless told
not to
+ Figure out how to get OBO-Edit to write out "import" statements
+ Darren will email John Richter-Day about that
- CV template updates to vendors
+ We have had pretty good response from vendors and Luisa is integrating
+ Okay to have some software organized by vendor
- documentation
+ Documentation is up to date
+ Lennart will regenerate embedded figures and send to Eric who will
update
- website
+ Eric will update web site for 0.99.12
+ Eric will update link from tiny1 to tiny-pwiz
+ Post the mapping file directly
- validator
+ Validator will be a little delayed. There are many back-end changes
due to the MI group
+ Does the validator check that if there is an acquisition list, then
there would be a combination type (like sum of spectra) provided?
- example files
+ Matt will take a stab at MALDI example
+ Remove tiny4 and point to "small" which includes LTQ-FT demo usage
+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML.
Eric will post.
+ Matt will generate an example MGF -> mzML using pwiz and post
+ Jim will send Eric some example RAW files and converted files
(including PDA, SRM)
- ASMS
+ Eric will have a draft of a poster today and send out for folks to
look at
+ Jim will follow up with Mark about ASMS "Computer applications
interest group"
+ Try to plan for one night going out to dinner as a group Mon, Tue,
Wed. Jim can't due Tue.
+ Or a lunch
- Amsterdam
+ Pierre-Alain will do the presentation of the mzML talk during main
conference
+ PSI session during the congress at Sunday 17th 9:30a-12
+ Tentative presenter at PSI session is Jim Shofstahl with backups of
Randy and Pierre-Alain
- Open schema issue: where to put "centroided" and "deisotoped"
+ We will allow spectrum representation (like centroid/profile) in the
fileContent section
- Next call
+ Same time in two weeks
|
|
From: Eric D. <ede...@sy...> - 2008-06-10 17:25:47
|
Hi everyone, here are the minutes for the PSI-MSS WG telecon of
2008-06-10.
Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim
- ASMS
+ Douglas Slotta has implemented mzML in their C++ toolkit
+ Jim talked to Steve Musser at FDA. They are considering accepting mzML
as a format to avoid cherry-picked spectra, but it would need some kind
of non-text audit trail information. Randy will talk with Vish about
this talk. Follow up.
+ There was a suggestion at ASMS that we move toward ISO certification
for the standard to promote adoption
+ Users are very positive about a single format
- schema
+ No major schema changes planned
+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change
+ One desirable addition is retention time in the index
- MIAPE example document?
+ Done and posted except for switching criteria and parameters for
creating peaklists
+ Pierre-Alain and Jim will get together and finish this
- CV status
+ Darren has sent a proposal for of datatype and relationship
"has_units". It's good. Proceed with all terms.
+ "scan time" is one example
+ OBO-Edit will write out all terms including imported terms unless told
not to. That can be done with filters.
+ Darren will post a recipe on how to filter out non-MS terms
+ Darren is still figuring out how to get OBO-Edit to write out "import"
statements
+ Darren will email John Richter-Day about that
+ Current CV version is 1.0.0
+ As Darren or anyone makes changes, increment the version number.
+ Darren will try to import the unit ontology from its source
+ Would a side effect of this prevent OBO-Edit from opening a file w/o
Internet? Darren will check
+ Normally all terms going forward now should be deprecated (deleted in
OBO-Edit terms)
+ However, the unit terms could be destroyed. Eric will destroy them.
- CV template updates to vendors
+ Start another round of vendor updates
+ Some software organized by vendor
- documentation
+ Documentation is up to date
+ Images in documentation still mention 0.99.12. Should update to 1.0.0
+ Lennart will regenerate embedded figures and send to Eric who will
update
- website
+ Post the mapping file directly
+ Should we set up an mzML.org?
+ Instead of maintaining a separate page, set up a redirect?
- mzML support information table
+ Definitely post it on the web site
+ Bruker will likely support mzML. Find out their plans
- validator
+ Validator will be a little delayed. There are many back-end changes
due to the MI group
+ Does the validator check that if there is an acquisition list, then
there would be a combination type (like sum of spectra) provided?
+ We will allow spectrum representation (like centroid/profile) in the
fileContent section
+ Need to incorporate the information in the OBO file (datatypes and
units)
+ Need to fix up the mapping file rules
+ Lennart hopes to have coding update done at the end of this week and
then we need help from everyone to update the mapping file
+ Maybe need a rule that if a spectrum and if a mass spectrum, the need
mz array and similar
+ Need some sort of unit for intensity arrays
+ At the moment, we do not require any units for the array type. We
should add that.
+ Darren will explore that while adding has_units to CV
- example files
+ Matt will take a stab at MALDI example and post it
+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage
+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML.
Eric will post.
+ Matt will generate an example MGF -> mzML using pwiz and post
+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)
- Amsterdam
+ Pierre-Alain will do the presentation of the mzML talk during main
conference
+ PSI session during the congress at Sunday 17th 9:30a-12
+ Tentative presenter at PSI session is Jim Shofstahl with backups of
Randy and Pierre-Alain
- Next call
+ Switch call time to *Monday* morning 9am PDT due to conflicts
+ Same time in two weeks on June 23rd
|
|
From: Mike C. <tu...@gm...> - 2008-06-10 17:43:47
|
On Tue, Jun 10, 2008 at 12:25 PM, Eric Deutsch <ede...@sy...> wrote: > + Jim talked to Steve Musser at FDA. They are considering accepting mzML as > a format to avoid cherry-picked spectra, but it would need some kind of > non-text audit trail information. Does this actually mean that they want "non-text" audit trail information as opposed to textual audit trail information? I wonder what an audit trail would entail here. The obvious thing to do would be to simply cryptographically sign the mzML file using something like PGP. > + Should we set up an mzML.org? If you're seriously considering this, I suggest that someone grab it immediately. (I've had good luck with gandi.net as a registrar.) Mike |
|
From: Matthew C. <mat...@va...> - 2008-06-10 18:16:55
|
Hi Mike, I took some issue with the "non-text" audit trail because it is merely security through obscurity, which seems out of place in an open standard. Jim made the valid point that the checksum IN the file could be modified at the same time the file itself is modified to make it look like the file is still original. That kind of potential attack is why download sites provide the MD5/SHA1 checksum of a download file separately from the file itself. An attacker could mess with the file and try to pass it off as real, but if you go back to an original source you can confirm that the external checksum doesn't match anymore. I suggest this approach as the robust way to protect against tampering with audit trails, no matter how they are encoded (for a determined attacker, it is a very simple matter to decode a base64 audit trail, tamper with it, and re-encode it). As for the contents of the audit trail itself I hope it will basically be a series of dataProcessing elements describing the acquisition parameters and any processing that the data has undergone. If there is more information needed, I'm eager to hear what it is. For those of you just joining us, the "audit trail" is intended to meet the criteria of 21 CFR Part 11 (http://www.fda.gov/ora/compliance_ref/part11/). I expect a proper conformance to the MIAPE-MS guidelines will necessitate conformance to the FDA guidelines though. I'm interested to hear if any other jurisdictions, e.g. EU countries, have similar compliance concerns that we should account for? -Matt Mike Coleman wrote: > On Tue, Jun 10, 2008 at 12:25 PM, Eric Deutsch > <ede...@sy...> wrote: > >> + Jim talked to Steve Musser at FDA. They are considering accepting mzML as >> a format to avoid cherry-picked spectra, but it would need some kind of >> non-text audit trail information. >> > > Does this actually mean that they want "non-text" audit trail > information as opposed to textual audit trail information? > > I wonder what an audit trail would entail here. The obvious thing to > do would be to simply cryptographically sign the mzML file using > something like PGP. > > > >> + Should we set up an mzML.org? >> > > If you're seriously considering this, I suggest that someone grab it > immediately. (I've had good luck with gandi.net as a registrar.) > > Mike > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > |
|
From: Mike C. <tu...@gm...> - 2008-06-10 19:45:48
|
I agree with your points. As far as I can see, the checksum within the mzML file is not good for anything other than as an additional check that (say) Windows hasn't flipped any bits in the file. Arguably, this kind of checksumming is barely worth doing, unless you're also checksumming the other parts of the system regularly. Who among us periodically checksums our instrument software or configuration files, for example? If you're concerned about instrument operators faking results, it seems like the only meaningful bar would be to have the instrument software cryptographically sign the result file. This would entail all kinds of key management problems that would rule this out in practice (I would think). If you're concerned about downstream people faking the results, my thought would be that you'd checksum (SHA1, etc.) the file at creation or "publication" (the point at which others have access to the file), and then publish that checksum in a "read only" location. As you say, this is pretty much the method used by thousands currently for file verification. If you already have a decent backup regime, just backing up the checksums might qualify. Or you could publish a grand-checksum in the newspaper occasionally, or whatever. Note, though, that for these latter scenarios you specifically *must ignore* the checksum within the file itself, as it is (as you and Jim say) not trustworthy. Rather, the checksum must be recalculated. I'm not familiar with 21 CFR Part 11, but it would seem that the mzML file itself ought to simply include all of the useful details about what it contains. Any further audit trail should happen outside of mzML, though--once the file comes off of the instrument, it should never change, in my opinion. Mike |
|
From: Pierre-Alain B. <pie...@is...> - 2008-06-11 07:56:24
|
Inbetween, I have also contacted a world-wide QA in Pharma and asked what they are doing to comply with text documents, across regulation bodies (FDA, ISO, etc). Let's see Pierre-Alain Mike Coleman wrote: > I agree with your points. > > As far as I can see, the checksum within the mzML file is not good for > anything other than as an additional check that (say) Windows hasn't > flipped any bits in the file. Arguably, this kind of checksumming is > barely worth doing, unless you're also checksumming the other parts of > the system regularly. Who among us periodically checksums our > instrument software or configuration files, for example? > > If you're concerned about instrument operators faking results, it > seems like the only meaningful bar would be to have the instrument > software cryptographically sign the result file. This would entail > all kinds of key management problems that would rule this out in > practice (I would think). > > If you're concerned about downstream people faking the results, my > thought would be that you'd checksum (SHA1, etc.) the file at creation > or "publication" (the point at which others have access to the file), > and then publish that checksum in a "read only" location. As you say, > this is pretty much the method used by thousands currently for file > verification. If you already have a decent backup regime, just > backing up the checksums might qualify. Or you could publish a > grand-checksum in the newspaper occasionally, or whatever. > > Note, though, that for these latter scenarios you specifically *must > ignore* the checksum within the file itself, as it is (as you and Jim > say) not trustworthy. Rather, the checksum must be recalculated. > > I'm not familiar with 21 CFR Part 11, but it would seem that the mzML > file itself ought to simply include all of the useful details about > what it contains. Any further audit trail should happen outside of > mzML, though--once the file comes off of the instrument, it should > never change, in my opinion. > > Mike > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > |
|
From: Randy J. <rkj...@in...> - 2008-06-11 11:38:04
|
I have met extensively with both the FDA DSI (audit division) and Pharma QA Reps (and been audited for GLP compliance at Indigo). Based on this, I suggest we look at a standard data integrity method which leaves the document as clear XML. I have not dug in depth yet, but the XML digital signature standard seems like a good place to start. In essence, I think you encrypt a SHA1 (or MD5) of the document to create a Message Authentication Code (MAC) using a Public/Private Key Pair. The traditional key stores should work, but I have not gotten further than this. The receiver decrypts the SHA1 with the public key and then compares it to the computed SHA1 of the document. This would protect the entire document and confirm authorship - we might even be able to come up with a time-stamp mechanism which would help with IP protection use cases. Since we have created the index schema already, it seems like a good place to put additional authentication devices. I really favor leaving the raw data and audit trail itself as normal XML (and readable). 21CFR11 does not suggest that binary encoding is a sufficient method for protecting the integrity of data. You have to have SOPs in place to ensure document security even with binary files. The agency has accepted the argument that the degree of difficulty in recreating a valid binary file set for a data system lowers the probability for an undetected modification, but SOPs have always been required on top of this. I think we have a great opportunity here. I presented a way of using XML for data submission for the FDA to Janet Woodcock who is their Chief Medical Officer and is now head of the drug approving CDER group and she was very supportive. It fits very nicely with their Critical Path Initiative and also helps the Quality By Design Initiatives, where analytical instruments are used in-line during manufacturing to continuously monitor processes. Does anyone have experience with the XML Digital Signature standard? Randy -----Original Message----- From: psi...@li... [mailto:psi...@li...] On Behalf Of Pierre-Alain Binz Sent: Wednesday, June 11, 2008 3:56 AM To: Mass spectrometry standard development Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes Inbetween, I have also contacted a world-wide QA in Pharma and asked what they are doing to comply with text documents, across regulation bodies (FDA, ISO, etc). Let's see Pierre-Alain Mike Coleman wrote: > I agree with your points. > > As far as I can see, the checksum within the mzML file is not good for > anything other than as an additional check that (say) Windows hasn't > flipped any bits in the file. Arguably, this kind of checksumming is > barely worth doing, unless you're also checksumming the other parts of > the system regularly. Who among us periodically checksums our > instrument software or configuration files, for example? > > If you're concerned about instrument operators faking results, it > seems like the only meaningful bar would be to have the instrument > software cryptographically sign the result file. This would entail > all kinds of key management problems that would rule this out in > practice (I would think). > > If you're concerned about downstream people faking the results, my > thought would be that you'd checksum (SHA1, etc.) the file at creation > or "publication" (the point at which others have access to the file), > and then publish that checksum in a "read only" location. As you say, > this is pretty much the method used by thousands currently for file > verification. If you already have a decent backup regime, just > backing up the checksums might qualify. Or you could publish a > grand-checksum in the newspaper occasionally, or whatever. > > Note, though, that for these latter scenarios you specifically *must > ignore* the checksum within the file itself, as it is (as you and Jim > say) not trustworthy. Rather, the checksum must be recalculated. > > I'm not familiar with 21 CFR Part 11, but it would seem that the mzML > file itself ought to simply include all of the useful details about > what it contains. Any further audit trail should happen outside of > mzML, though--once the file comes off of the instrument, it should > never change, in my opinion. > > Mike > > ------------------------------------------------------------------------ - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > ------------------------------------------------------------------------ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Psidev-ms-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev |
|
From: Susanna <sa...@eb...> - 2008-06-11 13:02:39
|
Hi Randy, could you, please, expand on this.... > I presented a way of using XML for data submission for the FDA to Janet Woodcock > who is their Chief Medical Officer and is now head of the drug approving CDER group and she > was very supportive. ..do you refer to proteomics submissions to FDA? Thanks, Susanna Randy Julian wrote: >I have met extensively with both the FDA DSI (audit division) and Pharma >QA Reps (and been audited for GLP compliance at Indigo). Based on this, >I suggest we look at a standard data integrity method which leaves the >document as clear XML. > >I have not dug in depth yet, but the XML digital signature standard >seems like a good place to start. > >In essence, I think you encrypt a SHA1 (or MD5) of the document to >create a Message Authentication Code (MAC) using a Public/Private Key >Pair. The traditional key stores should work, but I have not gotten >further than this. The receiver decrypts the SHA1 with the public key >and then compares it to the computed SHA1 of the document. This would >protect the entire document and confirm authorship - we might even be >able to come up with a time-stamp mechanism which would help with IP >protection use cases. > >Since we have created the index schema already, it seems like a good >place to put additional authentication devices. I really favor leaving >the raw data and audit trail itself as normal XML (and readable). > >21CFR11 does not suggest that binary encoding is a sufficient method for >protecting the integrity of data. You have to have SOPs in place to >ensure document security even with binary files. The agency has >accepted the argument that the degree of difficulty in recreating a >valid binary file set for a data system lowers the probability for an >undetected modification, but SOPs have always been required on top of >this. > >I think we have a great opportunity here. I presented a way of using >XML for data submission for the FDA to Janet Woodcock who is their Chief >Medical Officer and is now head of the drug approving CDER group and she >was very supportive. It fits very nicely with their Critical Path >Initiative and also helps the Quality By Design Initiatives, where >analytical instruments are used in-line during manufacturing to >continuously monitor processes. > >Does anyone have experience with the XML Digital Signature standard? > >Randy > > > > > >-----Original Message----- >From: psi...@li... >[mailto:psi...@li...] On Behalf Of >Pierre-Alain Binz >Sent: Wednesday, June 11, 2008 3:56 AM >To: Mass spectrometry standard development >Subject: Re: [Psidev-ms-dev] PSI-MSS WG call minutes > >Inbetween, I have also contacted a world-wide QA in Pharma and asked >what they are doing to comply with text documents, across regulation >bodies (FDA, ISO, etc). Let's see >Pierre-Alain > >Mike Coleman wrote: > > >>I agree with your points. >> >>As far as I can see, the checksum within the mzML file is not good for >>anything other than as an additional check that (say) Windows hasn't >>flipped any bits in the file. Arguably, this kind of checksumming is >>barely worth doing, unless you're also checksumming the other parts of >>the system regularly. Who among us periodically checksums our >>instrument software or configuration files, for example? >> >>If you're concerned about instrument operators faking results, it >>seems like the only meaningful bar would be to have the instrument >>software cryptographically sign the result file. This would entail >>all kinds of key management problems that would rule this out in >>practice (I would think). >> >>If you're concerned about downstream people faking the results, my >>thought would be that you'd checksum (SHA1, etc.) the file at creation >>or "publication" (the point at which others have access to the file), >>and then publish that checksum in a "read only" location. As you say, >>this is pretty much the method used by thousands currently for file >>verification. If you already have a decent backup regime, just >>backing up the checksums might qualify. Or you could publish a >>grand-checksum in the newspaper occasionally, or whatever. >> >>Note, though, that for these latter scenarios you specifically *must >>ignore* the checksum within the file itself, as it is (as you and Jim >>say) not trustworthy. Rather, the checksum must be recalculated. >> >>I'm not familiar with 21 CFR Part 11, but it would seem that the mzML >>file itself ought to simply include all of the useful details about >>what it contains. Any further audit trail should happen outside of >>mzML, though--once the file comes off of the instrument, it should >>never change, in my opinion. >> >>Mike >> >> >> >> >------------------------------------------------------------------------ >- > > >>Check out the new SourceForge.net Marketplace. >>It's the best place to buy or sell services for >>just about anything Open Source. >>http://sourceforge.net/services/buy/index.php >>_______________________________________________ >>Psidev-ms-dev mailing list >>Psi...@li... >>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> >> >> > >------------------------------------------------------------------------ >- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Psidev-ms-dev mailing list >Psi...@li... >https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Psidev-ms-dev mailing list >Psi...@li... >https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- Susanna-Assunta Sansone, PhD NET Project - Coordinator www.ebi.ac.uk/net-project The European Bioinformatics Institute email: sa...@eb... EMBL Outstation - Hinxton direct: +44 (0)1223 494 691 Wellcome Trust Genome Campus fax: +44 (0)1223 492 620 Cambridge CB10 1SD, UK room: A229 |
|
From: Brian P. <bri...@gm...> - 2008-06-11 19:56:13
|
Hello All,
>> - mzML support information table
You can add InsilicosViewer to the list, we've just finished integrating the
latest RAMP+ProteoWizard code for reading mzML.
Brian
_____
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Eric
Deutsch
Sent: Tuesday, June 10, 2008 10:26 AM
To: Mass spectrometry standard development
Cc: Eric Deutsch
Subject: [Psidev-ms-dev] PSI-MSS WG call minutes
Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-06-10.
Present: Matt, Darren, Eric, Lennart, Pierre-Alain, Jim
- ASMS
+ Douglas Slotta has implemented mzML in their C++ toolkit
+ Jim talked to Steve Musser at FDA. They are considering accepting mzML as
a format to avoid cherry-picked spectra, but it would need some kind of
non-text audit trail information. Randy will talk with Vish about this talk.
Follow up.
+ There was a suggestion at ASMS that we move toward ISO certification for
the standard to promote adoption
+ Users are very positive about a single format
- schema
+ No major schema changes planned
+ Let's keep a list of minor possibly desirable changes to make if there
needs to be an important change
+ One desirable addition is retention time in the index
- MIAPE example document?
+ Done and posted except for switching criteria and parameters for creating
peaklists
+ Pierre-Alain and Jim will get together and finish this
- CV status
+ Darren has sent a proposal for of datatype and relationship "has_units".
It's good. Proceed with all terms.
+ "scan time" is one example
+ OBO-Edit will write out all terms including imported terms unless told not
to. That can be done with filters.
+ Darren will post a recipe on how to filter out non-MS terms
+ Darren is still figuring out how to get OBO-Edit to write out "import"
statements
+ Darren will email John Richter-Day about that
+ Current CV version is 1.0.0
+ As Darren or anyone makes changes, increment the version number.
+ Darren will try to import the unit ontology from its source
+ Would a side effect of this prevent OBO-Edit from opening a file w/o
Internet? Darren will check
+ Normally all terms going forward now should be deprecated (deleted in
OBO-Edit terms)
+ However, the unit terms could be destroyed. Eric will destroy them.
- CV template updates to vendors
+ Start another round of vendor updates
+ Some software organized by vendor
- documentation
+ Documentation is up to date
+ Images in documentation still mention 0.99.12. Should update to 1.0.0
+ Lennart will regenerate embedded figures and send to Eric who will update
- website
+ Post the mapping file directly
+ Should we set up an mzML.org?
+ Instead of maintaining a separate page, set up a redirect?
- mzML support information table
+ Definitely post it on the web site
+ Bruker will likely support mzML. Find out their plans
- validator
+ Validator will be a little delayed. There are many back-end changes due to
the MI group
+ Does the validator check that if there is an acquisition list, then there
would be a combination type (like sum of spectra) provided?
+ We will allow spectrum representation (like centroid/profile) in the
fileContent section
+ Need to incorporate the information in the OBO file (datatypes and units)
+ Need to fix up the mapping file rules
+ Lennart hopes to have coding update done at the end of this week and then
we need help from everyone to update the mapping file
+ Maybe need a rule that if a spectrum and if a mass spectrum, the need mz
array and similar
+ Need some sort of unit for intensity arrays
+ At the moment, we do not require any units for the array type. We should
add that.
+ Darren will explore that while adding has_units to CV
- example files
+ Matt will take a stab at MALDI example and post it
+ Eric will remove tiny4 and point to "small" which includes LTQ-FT demo
usage
+ Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric
will post.
+ Matt will generate an example MGF -> mzML using pwiz and post
+ Jim will send Eric & Matt some example RAW files and converted files
(including PDA, SRM)
- Amsterdam
+ Pierre-Alain will do the presentation of the mzML talk during main
conference
+ PSI session during the congress at Sunday 17th 9:30a-12
+ Tentative presenter at PSI session is Jim Shofstahl with backups of Randy
and Pierre-Alain
- Next call
+ Switch call time to *Monday* morning 9am PDT due to conflicts
+ Same time in two weeks on June 23rd
|
|
From: Eric D. <ede...@sy...> - 2008-06-23 17:34:45
|
Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-06-23. Present: Matt, Darren, Eric - schema + No major schema changes planned + Let's keep a list of minor possibly desirable changes to make if there needs to be an important change + One desirable addition is retention time in the index + Current examples show: xmlns="http://psi.hupo.org/schema_revision/mzML_1.0.0" What should it be instead? Perhaps: xmlns="http://psidev.info/schemas/mzML_1.0.0" Poll SG to get an answer - Johannes Junker asks about supDataArrays. Should be fine as is. Ask for clarification - MIAPE example document? + Done and posted except for switching criteria and parameters for creating peaklists + Pierre-Alain and Jim will get together and finish this - CV status + Consider that we may need to have a parent term to contain (m/z, mass, ppm) but not yet + Darren's email: 1 - fine, 2 - fine, 3: Darren will add xsd:string to the few terms that do need. Does such a term allow empty string "" 4 - fine, 5 -fine, 6 - fine. At some point, someone should deal with everything in purgatory 7 - rename MS "unit" to "specialized mass spectrometry unit" which is child of UO "unit" 8 - put UO "energy unit" under MS "intensity unit". Hm, this is tricky. Darren will write up a proposal. 9 - okay to be wordy and precise + Matt email: redo, removing duplicates. No lists, but do include the singular concepts and repropose + Matt will remove all entries: synonym: "<new synonym>" RELATED [] + Not sure what to do with Wilfred's suggestions. Ask how he wants to use those. + Matt will remove extraneous \n in definitions - CV template updates to vendors + What's up with Thermo CVTerms and instrument attributes Excel sheet? + Start another round of vendor updates - documentation + Documentation is up to date - website + Post the mapping file directly + Should we set up an mzML.org? + Instead of maintaining a separate page, set up a redirect? - mzML support information table + Insilicos viewer is now released supporting mzML + Definitely post it on the web site - validator + Validator will be a little delayed. There are many back-end changes due to the MI group + Does the validator check that if there is an acquisition list, then there would be a combination type (like sum of spectra) provided? + We will allow spectrum representation (like centroid/profile) in the fileContent section + Need to incorporate the information in the OBO file (datatypes and units) + Need to fix up the mapping file rules + Lennart hopes to have coding update done at the end of this week and then we need help from everyone to update the mapping file + Maybe need a rule that if a spectrum and if a mass spectrum, the need mz array and similar + Need some sort of unit for intensity arrays + At the moment, we do not require any units for the array type. We should add that. + Darren will explore that while adding has_units to CV - example files + Matt will take a stab at MALDI example and post it + Eric will remove tiny4 and point to "small" which includes LTQ-FT demo usage + Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric will post. + Matt will generate an example MGF -> mzML using pwiz and post + Jim will send Eric & Matt some example RAW files and converted files (including PDA, SRM) - Amsterdam + Pierre-Alain will do the presentation of the mzML talk during main conference + PSI session during the congress at Sunday 17th 9:30a-12 + Tentative presenter at PSI session is Jim Shofstahl with backups of Randy and Pierre-Alain - Next call + Switch call time to *Monday* morning 9am PDT due to conflicts + Same time in two weeks on July 7 |
|
From: Eric D. <ede...@sy...> - 2008-07-07 17:29:14
|
Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-07-07. Present: Matt, Lennart, Jim, Darren, Pierre-Alain, Eric - mzML support information table + Is now posted + Add TOPP + Add NCBI C++ toolkit + Phenyx, and InSilicoSpectro listing is fine as is. - CV status + Darren will check what Matt sent and then check it in + Eric received CV from David Sparkman + Lennart mentions that "% percent collision energy" is a child MS term under UO parent + It is considered bad practice to add our own terms under someone else's ontology + The UO ontology maintainer appears happy to add our own strange unit terms + UO has some characters that OBO-Edit hates + Get in touch with the maintainer to fix some things in the UO + Darren will make a list of things to fix in UO and email to vocab list + Also fix all the warnings when OBO-Edit tries to save + Matt email: redo, removing duplicates. No lists, but do include the singular concepts and repropose + Darren will remove all entries: synonym: "<new synonym>" RELATED [] + Not sure what to do with Wilfred's suggestions. Ask how he wants to use those. + Matt will remove extraneous \n in definitions + Consider that we may need to have a parent term to contain (m/z, mass, ppm) but not yet + Matt will update the definition of scan time: start offset time of beginning of the scan + Let's NOT check in the new terms that Matt is proposing yet. They should not be all in root. + Lennart will send out a possible placement of Matt's terms. + Darren will check in minor fixing + Darren will then email to Lennart more controversial changes - validator + Lennart and company will start working on this again this week + Lennart and Matt will work on updated rules + There are many back-end changes due to the MI group + Does the validator check that if there is an acquisition list, then there would be a combination type (like sum of spectra) provided? + We will allow spectrum representation (like centroid/profile) in the fileContent section + Need to incorporate the information in the OBO file (datatypes and units) + Need to fix up the mapping file rules + Maybe need a rule that if a spectrum and if a mass spectrum, the need mz array and similar + Need some sort of unit for intensity arrays + At the moment, we do not require any units for the array type. We should add that? + Darren will explore that while adding has_units to CV - Issue of generic binary array CV term issue + Marc Sturm wants to include his own custom binary data array types. How should this be done? + Possible suggestion: there should be a special TOPP CV that they maintain? + TOPP CV. These new terms live in TOPP CV, but also linked to MS binary data array type + Lennart will ask Luisa et al. about this issue - CV template updates to vendors + What's up with Thermo CVTerms and instrument attributes Excel sheet? + It helped Matt hand craft some nice code + Could have a separate CV for all this information. Or just a tsv/Excel file + Start another round of vendor updates - schema + No major schema changes planned + Let's keep a list of minor possibly desirable changes to make if there needs to be an important change + One desirable addition is retention time in the index + Current examples show: xmlns="http://psi.hupo.org/schema_revision/mzML_1.0.0" What should it be instead? Perhaps: xmlns="http://psidev.info/schemas/mzML_1.0.0" Poll SG to get an answer - Johannes Junker asks about supDataArrays. Should be fine as is. Ask for clarification - MIAPE example document? + Done and posted except for switching criteria and parameters for creating peaklists + Pierre-Alain and Jim will get together and finish this - documentation + Documentation is up to date - website + Post the mapping file directly + Should we set up an mzML.org? + Instead of maintaining a separate page, set up a redirect? - example files + Matt will take a stab at MALDI example and post it + Eric will remove tiny4 and point to "small" which includes LTQ-FT demo usage + Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric will post. + Matt will generate an example MGF -> mzML using pwiz and post + Jim will send Eric & Matt some example RAW files and converted files (including PDA, SRM) - Next call + Next call same time in two weeks on July 21 |
|
From: Eric D. <ede...@sy...> - 2008-07-21 16:54:13
|
Hi everyone, here are the minutes for the PSI-MSS WG telecon of 2008-07-21. Present: Matt, Jim, Pierre-Alain, Eric - validator mapping file + Marc Sturm asks about location of ms-mapping file. Eric will post. + Lennart reports that EBI has a working version of the validator and will announce to the list very soon - CV + Jim says we should add a CV entry for an SRF file + Jim will send to Eric an SRF file definition + Respond to Matt's query 7/7 - mzML support information table + Add TOPP + Add NCBI C++ toolkit + Add Proteios SE - schema + Eric will reply to Marc Sturm's dataProcessing question + improve documentation based on that. - nativeID formats? + Matt will create and send out a proposal for nailing this down + One different CV term for each possible style of nativeID? - Next call + Next call same time in two weeks on August 4 Older notes from last call: - CV status + Darren will check what Matt sent and then check it in + Eric received CV from David Sparkman + Lennart mentions that "% percent collision energy" is a child MS term under UO parent + It is considered bad practice to add our own terms under someone else's ontology + The UO ontology maintainer appears happy to add our own strange unit terms + UO has some characters that OBO-Edit hates + Get in touch with the maintainer to fix some things in the UO + Darren will make a list of things to fix in UO and email to vocab list + Also fix all the warnings when OBO-Edit tries to save + Matt email: redo, removing duplicates. No lists, but do include the singular concepts and repropose + Darren will remove all entries: synonym: "<new synonym>" RELATED [] + Not sure what to do with Wilfred's suggestions. Ask how he wants to use those. + Matt will remove extraneous \n in definitions + Consider that we may need to have a parent term to contain (m/z, mass, ppm) but not yet + Matt will update the definition of scan time: start offset time of beginning of the scan + Let's NOT check in the new terms that Matt is proposing yet. They should not be all in root. + Lennart will send out a possible placement of Matt's terms. + Darren will check in minor fixing + Darren will then email to Lennart more controversial changes - validator + Lennart and company will start working on this again this week + Lennart and Matt will work on updated rules + There are many back-end changes due to the MI group + Does the validator check that if there is an acquisition list, then there would be a combination type (like sum of spectra) provided? + We will allow spectrum representation (like centroid/profile) in the fileContent section + Need to incorporate the information in the OBO file (datatypes and units) + Need to fix up the mapping file rules + Maybe need a rule that if a spectrum and if a mass spectrum, the need mz array and similar + Need some sort of unit for intensity arrays + At the moment, we do not require any units for the array type. We should add that? + Darren will explore that while adding has_units to CV - Issue of generic binary array CV term issue + Marc Sturm wants to include his own custom binary data array types. How should this be done? + Possible suggestion: there should be a special TOPP CV that they maintain? + TOPP CV. These new terms live in TOPP CV, but also linked to MS binary data array type + Lennart will ask Luisa et al. about this issue - CV template updates to vendors + What's up with Thermo CVTerms and instrument attributes Excel sheet? + It helped Matt hand craft some nice code + Could have a separate CV for all this information. Or just a tsv/Excel file + Start another round of vendor updates - schema + No major schema changes planned + Let's keep a list of minor possibly desirable changes to make if there needs to be an important change + One desirable addition is retention time in the index + Current examples show: xmlns="http://psi.hupo.org/schema_revision/mzML_1.0.0" What should it be instead? Perhaps: xmlns="http://psidev.info/schemas/mzML_1.0.0" Poll SG to get an answer - Johannes Junker asks about supDataArrays. Should be fine as is. Ask for clarification - MIAPE example document? + Done and posted except for switching criteria and parameters for creating peaklists + Pierre-Alain and Jim will get together and finish this - documentation + Documentation is up to date - website + Post the mapping file directly + Should we set up an mzML.org? + Instead of maintaining a separate page, set up a redirect? - example files + Matt will take a stab at MALDI example and post it + Eric will remove tiny4 and point to "small" which includes LTQ-FT demo usage + Fredrik sent to Eric nice examples of dta -> mzML and plgs -> mzML. Eric will post. + Matt will generate an example MGF -> mzML using pwiz and post + Jim will send Eric & Matt some example RAW files and converted files (including PDA, SRM) |
|
From: Matthew C. <mat...@va...> - 2008-08-04 14:19:10
|
Presumably Eric is tied up with paternal duties, but we are still having a call? -Matt Eric Deutsch wrote: > > - Next call > > + Next call same time in two weeks on August 4 > > > > |
|
From: Lennart M. <len...@eb...> - 2008-08-04 14:26:19
|
Dear PSI-MS Enthousiasts, Yes, we'll have our regular call today (Monday August 4). Details: Hi everyone, the PSI Mass Spectrometry Standards Working Group call is Monday August 4 at 9am PDT: http://www.timeanddate.com/worldclock/fixedtime.html?day=4&month=8&year=2008&hour=17&min=0&sec=0&p1=136 + Germany: 08001012079 + Switzerland: 0800000860 + UK: 08081095644 + USA: 1-866-314-3683 + Generic international: +44 2083222500 (UK number) access code: 297427 Agenda points: - MS Validator - Mapping rules file - CV - Everything else I missed :) Cheers, lnnrt. Matthew Chambers wrote: > Presumably Eric is tied up with paternal duties, but we are still having > a call? > > -Matt > > > Eric Deutsch wrote: >> - Next call >> >> + Next call same time in two weeks on August 4 >> >> >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X