Menu
▾
▴
psidev-ms-dev — Mass spectroscopy standard development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(2) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(22) |
Nov
(10) |
Dec
(15) |
| 2006 |
Jan
(15) |
Feb
(8) |
Mar
(16) |
Apr
(8) |
May
(2) |
Jun
(5) |
Jul
(3) |
Aug
(1) |
Sep
(34) |
Oct
(21) |
Nov
(14) |
Dec
(2) |
| 2007 |
Jan
|
Feb
(17) |
Mar
(10) |
Apr
(25) |
May
(11) |
Jun
(30) |
Jul
(1) |
Aug
(38) |
Sep
|
Oct
(119) |
Nov
(18) |
Dec
(3) |
| 2008 |
Jan
(34) |
Feb
(202) |
Mar
(57) |
Apr
(76) |
May
(44) |
Jun
(33) |
Jul
(33) |
Aug
(32) |
Sep
(41) |
Oct
(49) |
Nov
(84) |
Dec
(216) |
| 2009 |
Jan
(102) |
Feb
(126) |
Mar
(112) |
Apr
(26) |
May
(91) |
Jun
(54) |
Jul
(39) |
Aug
(29) |
Sep
(16) |
Oct
(18) |
Nov
(12) |
Dec
(23) |
| 2010 |
Jan
(29) |
Feb
(7) |
Mar
(11) |
Apr
(22) |
May
(9) |
Jun
(13) |
Jul
(7) |
Aug
(10) |
Sep
(9) |
Oct
(20) |
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(4) |
Mar
(27) |
Apr
(15) |
May
(23) |
Jun
(13) |
Jul
(15) |
Aug
(11) |
Sep
(23) |
Oct
(18) |
Nov
(10) |
Dec
(7) |
| 2012 |
Jan
(23) |
Feb
(19) |
Mar
(7) |
Apr
(20) |
May
(16) |
Jun
(4) |
Jul
(6) |
Aug
(6) |
Sep
(14) |
Oct
(16) |
Nov
(31) |
Dec
(23) |
| 2013 |
Jan
(14) |
Feb
(19) |
Mar
(7) |
Apr
(25) |
May
(8) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(20) |
Oct
(19) |
Nov
(10) |
Dec
(12) |
| 2014 |
Jan
(6) |
Feb
(15) |
Mar
(6) |
Apr
(4) |
May
(16) |
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(3) |
| 2015 |
Jan
(3) |
Feb
(8) |
Mar
(14) |
Apr
(3) |
May
(17) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(13) |
Nov
|
Dec
(6) |
| 2016 |
Jan
(8) |
Feb
(1) |
Mar
(20) |
Apr
(16) |
May
(11) |
Jun
(6) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(7) |
Dec
(2) |
| 2017 |
Jan
(10) |
Feb
(3) |
Mar
(17) |
Apr
(7) |
May
(5) |
Jun
(11) |
Jul
(4) |
Aug
(12) |
Sep
(9) |
Oct
(7) |
Nov
(2) |
Dec
(4) |
| 2018 |
Jan
(7) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(7) |
Jun
(7) |
Jul
(7) |
Aug
(1) |
Sep
(9) |
Oct
(5) |
Nov
(3) |
Dec
(5) |
| 2019 |
Jan
(10) |
Feb
|
Mar
(4) |
Apr
(4) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(9) |
Dec
(1) |
| 2020 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Natalie T. <nt...@sy...> - 2008-11-12 01:10:11
|
Hi all, I recently tried following the links on the main mzML page ( http://www.psidev.info/index.php?q=node/257); here are some notes. * the OBOEdit link is broken; * the OBO file is v1.2, while the stable OBOEdit release doesn't seem to read this format. A note and/or link to the development version of OBOEdit would be useful; * even after downloading units.obo, I'm getting lots of parser errors from OBOEdit which seem to mean that it's looking for other obo resources on the net, but not finding them. -Natalie |
|
From: Lennart M. <len...@gm...> - 2008-11-11 14:15:40
|
Dear PSI MS enthusiasts, Unfortunately, I am travelling today, and while I'll make sure the call is started, I can not participate in the call. Cheers, lnnrt. |
|
From: Eric D. <ede...@sy...> - 2008-11-11 08:02:26
|
Hi everyone, the next PSI Mass Spectrometry Standards Working Group call will be Tuesday 8am PST (in 8 hr): http://www.timeanddate.com/worldclock/fixedtime.html?day=11 <http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=11&year=2 008&hour=16&min=0&sec=0&p1=136> &month=11&year=2008&hour=16&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 Topics: - Schema changes: no one protested, so we should go ahead and make the changes? - change location of <spectrum> cvParams - scan/acquisition issue. Multiple scans inside acquisition? We need examples of what we want - Update rev to mzML 1.0.1 and update all documentation and examples - nativeID format: Resolved. Add to documentation - Marc has raised a number of issues to discuss. He has volunteered to maintain an open issues list - dataProcessingRef - <scanWindow> questions from Marc? - Removing/fixing scanning method child terms in CV - Export of CV to OLS - Validator (TOPP validator and EBI validator) - Next call |
|
From: Wilfred H T. <Ta...@ap...> - 2008-11-10 22:10:23
|
Why is userParam disallowed as a subelement? Why is referenceableParamGroupRef disallowed as a subelement? What if the scan window is unknown? Does scanWindow make sense for SRM? In light of the previous 2 questions, does it make sense to make scanWindow a mandatory subelement under the scan hierarchy? Thanks, Wilfred |
|
From: Marc S. <stu...@gm...> - 2008-11-07 06:54:04
|
Hello everyone, I finished the mzML Validator for OpenMS. You can find a web interface to the TOPP tool at: http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/mzML/ The used mapping and CV file can be found on this page as well. They contain some minor changes, which should probably be included in the official files as well. Best, Marc |
|
From: David C. <dc...@ma...> - 2008-11-03 14:51:34
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Marc,<br>
<br>
We tried using the 'cases' on psidev.info for PSI-PI but found that you
couldn't for example see a list of all open cases for a project due to
some bugs. Unfortunately, none of the web site admins had time to look
at the problem which is why we ended up using a google code project.<br>
<br>
David<br>
<br>
Angel Pizarro wrote:
<blockquote
cite="mid:e59...@ma..."
type="cite">The drupal site does have a "cases" functionality, which
we used for the FuGE spec as it was going through the process. Worked
well enough, but need someone to actively maintain it, since it is
not-ultra-obvious what one needs to do to make issues public, and also
move the comments unvariably only made in emails back into the issue's
timeline. <br>
<br>
For PSI-PI we just use a google code project and use the issue tracker
there. <br>
<br>
-angel<br>
<br>
<div class="gmail_quote">On Mon, Nov 3, 2008 at 8:18 AM, Marc Sturm <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:stu...@gm...">stu...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
all,<br>
<br>
I just noticed that the entries in "AcquisitionSettingsList" are not<br>
referenced from the whole schema.<br>
<br>
Best,<br>
Marc<br>
<br>
P.S.: Perhaps we should create a page where all open issues are listed<br>
together with the proposed resolution. I would voluteer for the<br>
maintainance of the list.<br>
<br>
-------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge<br>
Build the coolest Linux based applications with Moblin SDK & win
great prizes<br>
Grand prize is a trip for two to an Open Source event anywhere in the
world<br>
<a moz-do-not-send="true"
href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"
target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>
_______________________________________________<br>
Psidev-ms-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Psi...@li...">Psi...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev"
target="_blank">https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Angel Pizarro<br>
Director, ITMAT Bioinformatics Facility<br>
806 Biological Research Building<br>
421 Curie Blvd.<br>
Philadelphia, PA 19104-6160<br>
215-573-3736<br>
<pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
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
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Psidev-ms-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Psi...@li...">Psi...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev">https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344
<a class="moz-txt-link-abbreviated" href="mailto:dc...@ma...">dc...@ma...</a>
<a class="moz-txt-link-freetext" href="http://www.matrixscience.com">http://www.matrixscience.com</a>
Matrix Science Ltd. is registered in England and Wales
Company number 3533898</pre>
</body>
</html>
|
|
From: Angel P. <an...@ma...> - 2008-11-03 14:11:30
|
The drupal site does have a "cases" functionality, which we used for the FuGE spec as it was going through the process. Worked well enough, but need someone to actively maintain it, since it is not-ultra-obvious what one needs to do to make issues public, and also move the comments unvariably only made in emails back into the issue's timeline. For PSI-PI we just use a google code project and use the issue tracker there. -angel On Mon, Nov 3, 2008 at 8:18 AM, Marc Sturm <stu...@gm...> wrote: > Hi all, > > I just noticed that the entries in "AcquisitionSettingsList" are not > referenced from the whole schema. > > Best, > Marc > > P.S.: Perhaps we should create a page where all open issues are listed > together with the proposed resolution. I would voluteer for the > maintainance of the list. > > ------------------------------------------------------------------------- > 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 > -- Angel Pizarro Director, ITMAT Bioinformatics Facility 806 Biological Research Building 421 Curie Blvd. Philadelphia, PA 19104-6160 215-573-3736 |
|
From: Marc S. <stu...@gm...> - 2008-11-03 13:18:10
|
Hi all, I just noticed that the entries in "AcquisitionSettingsList" are not referenced from the whole schema. Best, Marc P.S.: Perhaps we should create a page where all open issues are listed together with the proposed resolution. I would voluteer for the maintainance of the list. |
|
From: Marc S. <st...@in...> - 2008-11-01 16:47:09
|
I understood the "scan" tag as a container of the CV terms related to the scan that created the "spectrum", so a 1:1 relation would be ok. But I'm abit puzzled about the difference between "spectrum"-"spectrum type" and "scan"-"scanning method". What would it mean if the two cvParams contradict? So, instead of duplicating the whole CV hierachy, I would only allow it either in "spectrum" or in "scan". Best, Marc > I agree it's a bit weird to have multiple <acquisition> and only one > <scan>. Perhaps we should have put <scan> inside <acquisition>? |
|
From: Marc S. <st...@in...> - 2008-11-01 16:00:29
|
Hi all, I just noticed that the for CV terms with a value, the 'xref' declaration is used to define the value type. Which types are allowed there? String, integer and float only? Thanks, Marc |
|
From: Marc S. <st...@in...> - 2008-11-01 15:57:45
|
Hi all, after implementing our own version of the semantic validator for mzML, i now have this question: Which children are allowed, if the mapping file contains a parent term with allowChildren="true"? Only those with a 'is_a' relationship or children with a 'part_of' relationship as well? Thanks for your help, Marc |
|
From: Marc S. <st...@in...> - 2008-10-30 06:31:57
|
Hi all, the schema, CV and mapping file on the website are for the released version i guess. Can someone please point me to the locations of the latest development versions of the files. Thanks, Marc |
|
From: Marc S. <st...@in...> - 2008-10-30 06:26:02
|
> I would vote for either adding a softwareRef to processingMethod or > moving dataProcessing's softwareRef to there. The DataProcessingRefList > seems like a bigger schema change to accomplish the same goal; the > adding approach would even be backward compatible. > I guess moving the softwareRef would be best. Otherwise the two softwareRefs could contradict. We should weight a intuitive design over backward compatibility, as we have to change the schema anyway. > I think that defaultDataProcessingRef is appropriate: it's a fallback > because it is only referred to if the dataProcessingRef on > spectrum/chromatogram is not set. These semantics and nomenclature would > be somewhat consistent with the defaultArrayLength approach. > Sounds ok, but we have to document that well (also for defaultArrayLength). Best, Marc |
|
From: Matthew C. <mat...@va...> - 2008-10-29 21:05:17
|
I would vote for either adding a softwareRef to processingMethod or moving dataProcessing's softwareRef to there. The DataProcessingRefList seems like a bigger schema change to accomplish the same goal; the adding approach would even be backward compatible. I think that defaultDataProcessingRef is appropriate: it's a fallback because it is only referred to if the dataProcessingRef on spectrum/chromatogram is not set. These semantics and nomenclature would be somewhat consistent with the defaultArrayLength approach. -Matt Marc Sturm wrote: >> After more thought, I think the defaultDataProcessingRef should go on >> spectrumList and chromatogramList instead of run, because those defaults >> are virtually certain to be different. This is slightly different from >> the defaultInstrumentConfigurationRef, but it's in the same spirit. >> >> > Good point! > I still think it should be "DataProcessingRefList" for spectrumList and > chromatogramList then. > Been able to use different softwares is quite important. > And I dont like "default" very much, because it sounds like a fallback, > which it isn't. > >> I am still pretty skeptical about having both spectrum/chromatogram and >> binaryDataArray with dataProcessingRef. The potential for ambiguous >> usage is too great and the benefit is pretty obscure as far as I can >> tell. This situation is essentially the same as we had with >> defaultArrayLength. How about we make spectrum's dataProcessingRef >> explicitly apply to both the m/z and intensity arrays, and it would be >> semantically invalid to have dataProcessingRef attributes on them, but >> fine on the auxiliary arrays? >> >> > Fine with me. I cannot imagine a usecase this approach would not cover. > > Best, > Marc > > |
|
From: Marc S. <st...@in...> - 2008-10-29 20:56:55
|
> After more thought, I think the defaultDataProcessingRef should go on > spectrumList and chromatogramList instead of run, because those defaults > are virtually certain to be different. This is slightly different from > the defaultInstrumentConfigurationRef, but it's in the same spirit. > Good point! I still think it should be "DataProcessingRefList" for spectrumList and chromatogramList then. Been able to use different softwares is quite important. And I dont like "default" very much, because it sounds like a fallback, which it isn't. > I am still pretty skeptical about having both spectrum/chromatogram and > binaryDataArray with dataProcessingRef. The potential for ambiguous > usage is too great and the benefit is pretty obscure as far as I can > tell. This situation is essentially the same as we had with > defaultArrayLength. How about we make spectrum's dataProcessingRef > explicitly apply to both the m/z and intensity arrays, and it would be > semantically invalid to have dataProcessingRef attributes on them, but > fine on the auxiliary arrays? > Fine with me. I cannot imagine a usecase this approach would not cover. Best, Marc |
|
From: Matthew C. <mat...@va...> - 2008-10-29 19:17:58
|
After more thought, I think the defaultDataProcessingRef should go on spectrumList and chromatogramList instead of run, because those defaults are virtually certain to be different. This is slightly different from the defaultInstrumentConfigurationRef, but it's in the same spirit. I am still pretty skeptical about having both spectrum/chromatogram and binaryDataArray with dataProcessingRef. The potential for ambiguous usage is too great and the benefit is pretty obscure as far as I can tell. This situation is essentially the same as we had with defaultArrayLength. How about we make spectrum's dataProcessingRef explicitly apply to both the m/z and intensity arrays, and it would be semantically invalid to have dataProcessingRef attributes on them, but fine on the auxiliary arrays? -Matt Marc Sturm wrote: >> To question 1: >> I think we should have a defaultDataProcessingRef on run like we have a >> defaultInstrumentConfigurationRef. In the absence of that, we can >> recommend every spectrum reference the global DP. I would definitely >> vote against implied global data processing. >> >> > I agree. > >> To question 2: >> Ack. This does seem to be a missing capability. Either each processing >> method needs a softwareRef, or any current usage of dataProcessingRef >> needs to turn into a ListRef. >> >> > I think it would be best to have a dataProcessingRefList for > "run","spectrum", "binary data array" and "chromatogram". > > > > >>> Question 1: >>> When a tool is applied to the whole mzML file (e.g. conversion to >>> mzML).Where does this information go? I see two possibilities: >>> 1) Repeat it for every spectrum. >>> 2) All dataProcessing sections not referenced by a "spectrum"/"binary >>> data array"/"chromatogram" are valid for the whole file. In this case a >>> "dataProcessingRefList" under "run" would be much clearer in my opinion. >>> >>> > > >>> Question 2: >>> Is it not possible to store that a single spectrum has been processed by >>> two different Softwares? >>> I see only one "dataProcessingRef", which in turn can only has one >>> "SoftwareRef". >>> From Eric's post I get the impression that the "dataProcessingRef" of >>> the spectrum should be used for the software that created the specturm. >>> Is that right? |
|
From: Marc S. <st...@in...> - 2008-10-29 15:12:43
|
> To question 1: > I think we should have a defaultDataProcessingRef on run like we have a > defaultInstrumentConfigurationRef. In the absence of that, we can > recommend every spectrum reference the global DP. I would definitely > vote against implied global data processing. > I agree. > To question 2: > Ack. This does seem to be a missing capability. Either each processing > method needs a softwareRef, or any current usage of dataProcessingRef > needs to turn into a ListRef. > I think it would be best to have a dataProcessingRefList for "run","spectrum", "binary data array" and "chromatogram". >> Question 1: >> When a tool is applied to the whole mzML file (e.g. conversion to >> mzML).Where does this information go? I see two possibilities: >> 1) Repeat it for every spectrum. >> 2) All dataProcessing sections not referenced by a "spectrum"/"binary >> data array"/"chromatogram" are valid for the whole file. In this case a >> "dataProcessingRefList" under "run" would be much clearer in my opinion. >> >> Question 2: >> Is it not possible to store that a single spectrum has been processed by >> two different Softwares? >> I see only one "dataProcessingRef", which in turn can only has one >> "SoftwareRef". >> From Eric's post I get the impression that the "dataProcessingRef" of >> the spectrum should be used for the software that created the specturm. >> Is that right? >> |
|
From: Matthew C. <mat...@va...> - 2008-10-29 14:42:04
|
To question 1: I think we should have a defaultDataProcessingRef on run like we have a defaultInstrumentConfigurationRef. In the absence of that, we can recommend every spectrum reference the global DP. I would definitely vote against implied global data processing. To question 2: Ack. This does seem to be a missing capability. Either each processing method needs a softwareRef, or any current usage of dataProcessingRef needs to turn into a ListRef. -Matt Marc Sturm wrote: > Hi all, > > I have two more question about the dataProcessing: > > Question 1: > When a tool is applied to the whole mzML file (e.g. conversion to > mzML).Where does this information go? I see two possibilities: > 1) Repeat it for every spectrum. > 2) All dataProcessing sections not referenced by a "spectrum"/"binary > data array"/"chromatogram" are valid for the whole file. In this case a > "dataProcessingRefList" under "run" would be much clearer in my opinion. > > Question 2: > Is it not possible to store that a single spectrum has been processed by > two different Softwares? > I see only one "dataProcessingRef", which in turn can only has one > "SoftwareRef". > From Eric's post I get the impression that the "dataProcessingRef" of > the spectrum should be used for the software that created the specturm. > Is that right? > > Best, > Marc |
|
From: Marc S. <st...@in...> - 2008-10-29 07:07:51
|
Hi all, I have two more question about the dataProcessing: Question 1: When a tool is applied to the whole mzML file (e.g. conversion to mzML).Where does this information go? I see two possibilities: 1) Repeat it for every spectrum. 2) All dataProcessing sections not referenced by a "spectrum"/"binary data array"/"chromatogram" are valid for the whole file. In this case a "dataProcessingRefList" under "run" would be much clearer in my opinion. Question 2: Is it not possible to store that a single spectrum has been processed by two different Softwares? I see only one "dataProcessingRef", which in turn can only has one "SoftwareRef". From Eric's post I get the impression that the "dataProcessingRef" of the spectrum should be used for the software that created the specturm. Is that right? Best, Marc |
|
From: Eric D. <ede...@sy...> - 2008-10-29 00:46:46
|
> From: Matthew Chambers [mailto:mat...@va...] > > What is the rationale for this? Are we supporting annotation of data > processing to a specific array? I could imagine a case where different algorithms calculate some different binaryDataArrays. Algorithm A calculates the S/N array and algorithm B calculates the charge state of the peaks. Or something like that. I don't think we have a specific example. > What does it mean when both the spectrum > and its m/z array have different dataProcessingRefs? Unclear to me. If I were looking to use it, I would probably use the spectrum dataProcessingRef to refer to some centroiding/summing algorithm that was used to generate the m/z and Int pairs. And I would only likely use dataProcessingRef if a subset of the non-(m/z,Int) binaryDataArrays were generated by a *different* algorithm than the one primarily responsible for the (m/z,Int) binaryDataArrays. An obscure case most likely, but the option is there. It shouldn't affect readers, I think. Other ideas? > -Matt > > ------------------------------------------------------------------------- > 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 |
|
From: Matthew C. <mat...@va...> - 2008-10-28 18:52:56
|
What is the rationale for this? Are we supporting annotation of data processing to a specific array? What does it mean when both the spectrum and its m/z array have different dataProcessingRefs? -Matt |
|
From: Lennart M. <len...@eb...> - 2008-10-28 15:55:32
|
Dear PSI-MS'ers, Les minutes ;). Cheers, lnnrt. |
|
From: Matthew C. <mat...@va...> - 2008-10-27 20:58:24
|
I agree it's a bit weird to have multiple <acquisition> and only one <scan>. Perhaps we should have put <scan> inside <acquisition>? -Matt Fredrik Levander wrote: > Hi Wilfred, > > Multiple scans defining one spectrum would be 'acquisitions' in the > acquistionList, where the retention times of these scans can be defined. > However, I don't know what to do if these individual scans have > different scan settings, since as you say there can currently be only > one scan element. > > Regards > > Fredrik > > Wilfred H Tang skrev: > >> I'm still puzzled by the distinction between spectrum vs. scan. At the >> previous meeting, I thought the explanation was that a spectrum can >> consist of multiple scans. But the schema actually says that a >> spectrum can only have one scan. So now I'm as confused as ever... >> >> Thanks, >> Wilfred >> |
|
From: Fredrik L. <Fre...@im...> - 2008-10-27 19:43:00
|
Hi Wilfred, Multiple scans defining one spectrum would be 'acquisitions' in the acquistionList, where the retention times of these scans can be defined. However, I don't know what to do if these individual scans have different scan settings, since as you say there can currently be only one scan element. Regards Fredrik Wilfred H Tang skrev: > > I'm still puzzled by the distinction between spectrum vs. scan. At the > previous meeting, I thought the explanation was that a spectrum can > consist of multiple scans. But the schema actually says that a > spectrum can only have one scan. So now I'm as confused as ever... > > Thanks, > Wilfred > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > |
|
From: Eric D. <ede...@sy...> - 2008-10-27 19:41:47
|
Hi everyone, I'm sorry, I missed a series of posts for this topic. It got mis-shuffled in my inbox. Thanks for Fredrik, David, Matt et al. for that discussion. Here is another revision of the native ID proposal now incorporating the additional comments that I previously missed. Please continue to edit/comment: The nativeID attribute is a required attribute for every spectrum and is intended to provide a identifier to a spectrum in the name convention used by the original (or previous) source of the data, so that it may be easily mapped to previous forms of the data. Since the nativeID can take on different formats for different vendors, then allowed formats must be specified at the top of the file in the fileDescription section as a cvParam. Such a description will appear like this: <fileContent> <cvParam cvRef="MS" accession="MS:1000580" name="MSn spectrum"/> <cvParam cvRef="MS" accession="MS:1000127" name="centroid mass spectrum"/> <cvParam cvRef="MS" accession="MS:1000XXX" name="Thermo nativeID format"/> </fileContent> The formats to be used for different course formats is: "Thermo nativeID format": nativeID="controller=0 scan=1" nativeID="controller=0 scan=1243" nativeID="controller=1 scan=1" (where controller 0 is probably always the mass spec?) "Waters nativeID format": nativeID="function=1 process=0 scan=1" nativeID="function=1 process=0 scan=2" nativeID="function=2 process=0 scan=1" "WIFF nativeID format": nativeID="Sample=0 period=1 cycle=1 experiment=2" nativeID="Sample=0 period=1 cycle=1 experiment=3" nativeID="Sample=0 period=1 cycle=2 experiment=2" nativeID="Sample=0 period=1 cycle=2 experiment=3" "Bruker/Agilent YEP nativeID format": nativeID="scan=1" "Bruker BAF nativeID format": nativeID="scan=1" "Bruker FID nativeID format": nativeID="sourceFileId=xxxxxx" (each sourceFileRef is different) "Multiple peak list nativeID format": (conversion of peak list files with multiple spectra, i.e. MGF, PKL, merged DTA files. Index is the spectrum number in the file, starting from 0) nativeID="index=0" "Single peak list nativeID format" (conversion of peak list files with one spectrum per file, typically folder of PKL or DTAs, each sourceFileRef is different) nativeID="sourceFileId=xxxxxx" "Scan number only nativeID format" (conversion from mzData or mzXML, or dta folder where native scan numbers can be derived): nativeID="scan=1" "MassHunter nativeID format": nativeID=??? "ABI TOFTOF nativeID format": ??? nativeID=??? If there are multiple elements that compose a nativeID, all must be specified. The rationale for this is that allowing default values for certain elements would likely encourage some implementors not to support those elements. Then when those implementations encountered a fully specified nativeID, they would break. Note that there is a rule that all nativeIDs within a file must be unique, and we have nativeID in the index. Therefore nativeID cannot be empty. So if the file is assembled from PKL files or similar (where there is one file per spectrum), then the nativeIDs should be set to the IDs of the sourceFiles. In cases of summed scans, the nativeID will take the value of the earliest scan in time. Further information in <acquisition> will describe the full extent of the summing. > -----Original Message----- > From: Matt Chambers [mailto:mat...@va...] > Sent: Monday, October 13, 2008 6:32 AM > To: Mass spectrometry standard development > Subject: Re: [Psidev-ms-dev] Proposed nativeID format and examples > > Hi Fredrik, > > We discussed optional fields before as it is true that almost all Thermo > files will use only 1 controller, and most of those will use only > controller 0. But I don't think the small benefit in file size would be > worth the implementation/comprehension cost of partially implicit ids. > > You're the first person I've talked to that actually knows what the > Waters process id is. :) If it is indeed used when the data has been > MassLynx-processed, I think it's critical to keep in. If some components > of the id are optional, then the term specifier in the CV needs to > indicate which ones and what their default values are. > > I do not understand the use case of "what to write if some value for > some reason is not known." If the file is being converted from native > data or from another mzML file, the values should always be known. We > are putting the components in the id because they are necessary to link > a spectrum to a native acquisition. If conversion is taking place from a > less explicit format like MGF, mzData, or mzXML, then it is pretty much > futile to try to reconstruct the native ids. Instead, we the nativeID > should point to the less explicit format. For MGF, that should be a > simple index except in specific cases where the native id can be parsed > from the TITLE attribute. For mzData and mzXML it should be scan number > except in specific cases where mzXML's scanOrigin element has been > provided. So for nativeID I think it's all or nothing as far > constructing a link to a vendor acquisition is concerned. > > As I proposed before, we should provide nativeID formats for the generic > text/xml formats. > MGF: nativeID="index=0" > mzData: nativeID="scan=1" > mzXML: nativeID="scan=1" > > I think we can get Bruker support in there too as I recently have done > quite a bit of work with CompassXtract. > Bruker/Agilent YEP: nativeID="scan=1" > Bruker BAF: nativeID="scan=1" > Bruker FID: nativeID="" // required to be empty because each FID is a > single spectrum, so sourceFileRef is all that is needed > > DTA is a bit of a tricky one because for Thermo derived data it can be > used to get the scan numbers (assuming - quite safely I think - that > controller 0 was used), but for other data the scan numbers would be > wrong and/or misleading. For consistency I'll argue that DTA be like > mzData and mzXML: nativeID="scan=1" > > PKL can be handled like FID, an empty nativeID and a sourceFileRef. > > Eric, can you ask Natalie for the format of the MassTrapper nativeIDs? > > T2D can be handled like FID as well. I haven't a clue how to properly > handle a direct reference to the Oracle database, we can probably divert > that one until later. ;) > > -Matt > > > Fredrik Levander wrote: > > Hi Eric, > > > > Looks fine. One comment though: Could some of the fields be optional? > > 'Controller' doesn't always make sense for the Thermo files, and > > 'process' is maybe not so relevant for all Waters data (OK, if it hasn't > > been processed in MassLynx, process could be put to zero, but Ithink I > > would prefer to leave it out). > > Also, I would like to have a recommendation on what to write if some > > value for some reason not is known. This could be to leave out or to > > replace the number with a question mark. Worst option would be to put a > > value which is maybe not correct, in order to produce a 'valid' file. > > > > Thanks > > > > Fredrik > > > > Eric Deutsch skrev: > > > >> Hi Matt, right you are. Sorry I neglected to follow up. I believe the > >> proposal we agreed upon on to use this: > >> > >> Thermo: > >> nativeID="controller=0 scan=1" > >> nativeID="controller=0 scan=1243" > >> nativeID="controller=1 scan=1" > >> (where controller 0 is probably always the mass spec?) > >> > >> Waters: > >> nativeID="function=1 process=0 scan=1" > >> nativeID="function=1 process=0 scan=2" > >> nativeID="function=2 process=0 scan=1" > >> > >> WIFF: > >> nativeID="Sample=0 period=1 cycle=1 experiment=2" > >> nativeID="Sample=0 period=1 cycle=1 experiment=3" > >> nativeID="Sample=0 period=1 cycle=2 experiment=2" > >> nativeID="Sample=0 period=1 cycle=2 experiment=3" > >> > >> Can anyone provide any more other vendor/format examples or further > comments > >> that should appear in the documentation of the above? > >> > >> Thanks, > >> Eric > >> > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Matthew Chambers [mailto:mat...@va...] > >>> Sent: Friday, October 10, 2008 12:57 PM > >>> To: Mass spectrometry standard development > >>> Subject: Re: [Psidev-ms-dev] PSI-MSS WG call Monday > >>> > >>> Hi Eric, we were supposed to refine the nativeID format over the last > >>> two weeks. :) > >>> You had this in the last meeting minutes: > >>> + Eric will send out a summary of what formats should look like for > all > >>> vendors and we'll refine > >>> > >>> Would you like me to put together the summary instead? I'd basically > >>> replace my format and examples with the key=value format and it'd be > set > >>> unless you had some other ideas. > >>> > >>> -Matt > >>> > >>> > >>> Eric Deutsch wrote: > >>> > >>> > >>>> Hi everyone, this is a reminder that the next PSI-MSS WG call is > >>>> Monday October 13 at 9am PDT: > >>>> > >>>> > >>>> > >>>> > >>> > http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year= > >>> 2008&hour=17&min=0&sec=0&p1=136 > >>> > >>> > <http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year > >>> =2008&hour=17&min=0&sec=0&p1=136> > >>> > >>> > >>>> + Germany: 08001012079 > >>>> > >>>> + Switzerland: 0800000860 > >>>> > >>>> + UK: 08081095644 > >>>> > >>>> + USA: 1-866-314-3683 > >>>> > >>>> Generic international: +44 2083222500 (UK number) > >>>> > >>>> access code: 297427 > >>>> > >>>> The agenda will be to review some recent discussions and review all > >>>> the aspects related to mzML to start making progress again on the > >>>> highest priorities > >>>> > >>>> Topics: > >>>> > >>>> - nativeID format > >>>> > >>>> - mzML support information table > >>>> > >>>> - MIAPE example document > >>>> > >>>> - Other example documents > >>>> > >>>> - CV > >>>> > >>>> - CV template updates to vendors > >>>> > >>>> - Documentation > >>>> > >>>> - Web site > >>>> > >>>> - Validator > >>>> > >>>> - WIFF converter > >>>> > >>>> - Manuscript > >>>> > >>>> - Next call perhaps Tuesday 8am so that Pierre-Alain can join? > >>>> > >>>> Thanks, > >>>> > >>>> Eric > >>>> > > > ------------------------------------------------------------------------- > 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 |
49 messages has been excluded from this view by a project administrator.
