Menu
▾
▴
psidev-pi-dev — General Development List for Proteomics Informatics
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(4) |
Oct
(10) |
Nov
(1) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(8) |
May
(40) |
Jun
(30) |
Jul
(61) |
Aug
(21) |
Sep
(12) |
Oct
(56) |
Nov
(99) |
Dec
(83) |
| 2009 |
Jan
(3) |
Feb
(9) |
Mar
(1) |
Apr
(5) |
May
(88) |
Jun
(43) |
Jul
(60) |
Aug
(54) |
Sep
(4) |
Oct
(18) |
Nov
(9) |
Dec
(5) |
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(8) |
May
(10) |
Jun
(8) |
Jul
(10) |
Aug
(18) |
Sep
(11) |
Oct
(19) |
Nov
(14) |
Dec
(26) |
| 2011 |
Jan
(27) |
Feb
(38) |
Mar
(50) |
Apr
(128) |
May
(54) |
Jun
(116) |
Jul
(79) |
Aug
(163) |
Sep
(21) |
Oct
(14) |
Nov
(19) |
Dec
(9) |
| 2012 |
Jan
(7) |
Feb
(34) |
Mar
(34) |
Apr
(50) |
May
(70) |
Jun
(23) |
Jul
(8) |
Aug
(24) |
Sep
(35) |
Oct
(40) |
Nov
(276) |
Dec
(34) |
| 2013 |
Jan
(25) |
Feb
(23) |
Mar
(12) |
Apr
(59) |
May
(31) |
Jun
(11) |
Jul
(21) |
Aug
(7) |
Sep
(18) |
Oct
(11) |
Nov
(12) |
Dec
(18) |
| 2014 |
Jan
(37) |
Feb
(22) |
Mar
(9) |
Apr
(10) |
May
(38) |
Jun
(20) |
Jul
(15) |
Aug
(4) |
Sep
(4) |
Oct
(3) |
Nov
(8) |
Dec
(5) |
| 2015 |
Jan
(13) |
Feb
(34) |
Mar
(27) |
Apr
(5) |
May
(12) |
Jun
(10) |
Jul
(12) |
Aug
(3) |
Sep
(1) |
Oct
(13) |
Nov
|
Dec
(6) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
(17) |
Apr
(139) |
May
(120) |
Jun
(90) |
Jul
(10) |
Aug
|
Sep
|
Oct
(11) |
Nov
(6) |
Dec
(2) |
| 2017 |
Jan
(24) |
Feb
(8) |
Mar
(7) |
Apr
(2) |
May
(5) |
Jun
(11) |
Jul
(5) |
Aug
(9) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(4) |
| 2018 |
Jan
(7) |
Feb
|
Mar
(4) |
Apr
(6) |
May
(10) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(3) |
Dec
(3) |
| 2019 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(12) |
Dec
(1) |
| 2020 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <cod...@go...> - 2008-12-17 13:59:21
|
Status: Accepted Owner: andrewrobertjones Labels: Type-Defect Priority-Medium New issue 47 by andrewrobertjones: The name of AnalysisXML http://code.google.com/p/psi-pi/issues/detail?id=47 Eric posted the following comment on the list: At the risk of reopening old wounds and causing screams of rage, this may be the last good opportunity to settle on a better name. When I mention AnalysisXML, it still invokes smirks and muttered comparisons with StuffXML and OpenXML and DataXML, all fairly meaningless terms. It seems like the new scheme for PSI seems to be just ML instead of XML (e.g. sepML, gelML, mzML, etc.) Can I interest anyone in piaML (proteomics informatic analysis ML) or just paML or even piML? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-17 13:55:21
|
Updates: Status: Invalid Comment #1 on issue 46 by andrewrobertjones: Problems encountered during the document process http://code.google.com/p/psi-pi/issues/detail?id=46 Decided to have separate issues for problems identified during doc process -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: Jones, A. <And...@li...> - 2008-12-17 13:36:55
|
>A link to the validator would be useful: http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/analysisXML/index.php Good suggestion, I also added a section to the spec doc where this is referenced and briefly discussed. I have added one or two small sections to the spec doc since the last review by people but nothing controversial I promise ;-) >Is it also worth having a link to the issues list, which we will use for issues reported during the review process? Y will do – I created a new issue (46) on the list for this, although perhaps this isn’t the best idea – I guess we may need multiple issues creating... Cheers Andy From: David Creasy [mailto:dc...@ma...] Sent: 17 December 2008 13:32 To: Jones, Andy Cc: psi...@li... Subject: Re: [Psidev-pi-dev] Submission to doc process Hi Andy, Jones, Andy wrote: Hi all, This afternoon I intend to submit the specifications to the PSI document process. The following files will be included in the upload: -Specification document -AXML + FuGE XSDs -A link to instance documents: http://code.google.com/p/psi-pi/source/browse/#svn/trunk/examples -A link to the current CV and mapping file: http://code.google.com/p/psi-pi/source/browse/#svn/trunk/cv -A link to MIAPE conformance HTML page: http://www.psidev.info/index.php?q=node/386 I would rather upload the spec doc and XSDs instead of just publishing a link to ensure that the versions that get reviewed cannot change. I think it is acceptable for there to be updates to the CV, mapping file and instances during the document process. Any views on this? I think that sounds reasonable. People can always see the changes the docs under svn if they need them. If I’m forgetting anything else, let me know, otherwise I’ll submit in an hour or so... A link to the validator would be useful: http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/analysisXML/index.php Is it also worth having a link to the issues list, which we will use for issues reported during the review process? (I checked the list of items to submit in issue 41 - nothing else listed there.) Amazing.... David Cheers Andy ________________________________ ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ________________________________ _______________________________________________ Psidev-pi-dev mailing list Psi...@li... https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: <cod...@go...> - 2008-12-17 13:35:24
|
Status: Accepted Owner: andrewrobertjones Labels: Type-Defect Priority-Medium New issue 46 by andrewrobertjones: Problems encountered during the document process http://code.google.com/p/psi-pi/issues/detail?id=46 Issues identified during the document process should be inserted here. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: David C. <dc...@ma...> - 2008-12-17 13:31:53
|
<!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">
Hi Andy,<br>
<br>
Jones, Andy wrote:
<blockquote
cite="mid:08D...@EV..."
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal">This afternoon I intend to submit the
specifications to the
PSI document process. The following files will be included in the
upload:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Specification document<o:p></o:p></p>
<p class="MsoNormal">-AXML + FuGE XSDs<o:p></o:p></p>
<p class="MsoNormal">-A link to instance documents: <a
moz-do-not-send="true"
href="http://code.google.com/p/psi-pi/source/browse/#svn/trunk/examples">http://code.google.com/p/psi-pi/source/browse/#svn/trunk/examples</a><o:p></o:p></p>
<p class="MsoNormal">-A link to the current CV and mapping file: <a
moz-do-not-send="true"
href="http://code.google.com/p/psi-pi/source/browse/#svn/trunk/cv">http://code.google.com/p/psi-pi/source/browse/#svn/trunk/cv</a><o:p></o:p></p>
<p class="MsoNormal">-A link to MIAPE conformance HTML page: <a
moz-do-not-send="true"
href="http://www.psidev.info/index.php?q=node/386">http://www.psidev.info/index.php?q=node/386</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would rather upload the spec doc and XSDs
instead of just
publishing a link to ensure that the versions that get reviewed cannot
change.
I think it is acceptable for there to be updates to the CV, mapping
file and instances
during the document process. Any views on this?</p>
</div>
</blockquote>
I think that sounds reasonable. People can always see the changes the
docs under svn if they need them.<br>
<blockquote
cite="mid:08D...@EV..."
type="cite">
<div class="Section1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If I’m forgetting anything else, let me know,
otherwise I’ll submit in an hour or so...</p>
</div>
</blockquote>
A link to the validator would be useful:<br>
<a class="moz-txt-link-freetext" href="http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/analysisXML/index.php">http://www-bs2.informatik.uni-tuebingen.de/services/OpenMS/analysisXML/index.php</a><br>
<br>
Is it also worth having a link to the issues list, which we will use
for issues reported during the review process?<br>
<br>
(I checked the list of items to submit in issue 41 - nothing else
listed there.)<br>
<br>
Amazing....<br>
<br>
David<br>
<blockquote
cite="mid:08D...@EV..."
type="cite">
<div class="Section1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">Cheers<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/">http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Psidev-pi-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-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-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: Jones, A. <And...@li...> - 2008-12-17 13:16:42
|
Hi all, This afternoon I intend to submit the specifications to the PSI document process. The following files will be included in the upload: -Specification document -AXML + FuGE XSDs -A link to instance documents: http://code.google.com/p/psi-pi/source/browse/#svn/trunk/examples -A link to the current CV and mapping file: http://code.google.com/p/psi-pi/source/browse/#svn/trunk/cv -A link to MIAPE conformance HTML page: http://www.psidev.info/index.php?q=node/386 I would rather upload the spec doc and XSDs instead of just publishing a link to ensure that the versions that get reviewed cannot change. I think it is acceptable for there to be updates to the CV, mapping file and instances during the document process. Any views on this? If I'm forgetting anything else, let me know, otherwise I'll submit in an hour or so... Cheers Andy |
|
From: Matthew C. <mat...@va...> - 2008-12-16 15:41:49
|
Richard Scheltema wrote:
> Dear all,
>
> Thank you for your comments. A question from my side, is the phone
> conference scheduled for this afternoon open? As I'm on the agenda I
> would like to join if possible.
>
Yes, the call is open to all interested parties. BYOB. :)
> Matthew Chambers wrote:
>
>> I'm not sure what this would look like. We certainly didn't have 3d
>> chromatograms in mind, but perhaps they can be accommodated. Would that
>> be a chromatogram with three axes (data arrays): time, m/z, and
>> intensity? Is this akin to the "psuedo-2d-gel" view?
>>
> The mass chromatogram would indeed consist of time, m/z and intensity.
> The m/z data coming from the profile spectrum data. If you plot the mass
> chromatogram it will look a bit like a bell. I'm not quite sure what you
> mean with the pseudo-2d-gel view, but as I understand it, this is a 2d
> view of all the mass chromatograms found in for example a LC/MS profile.
> In the definition of the chromatogram block some semantics should be
> worked out in order to let the parser figure out what is stored there.
>
> I would suggest something as following (a mass chromatogram spanning 9
> scans, sorry for the verbosity of it all). For the centroid data the
> original structure would hold with the addition of the cvParam MS:1000127:
>
> <snip>
I fear this is a pretty cryptic representation that would rarely be
supported. I'm thinking the preferable way to store these chromatograms
is simply as a series of 2d chromatograms. Yes, it means repeating the
metadata and the time array every time, but I don't feel that's a
critical issue. Actually, repeating the metadata is probably a bonus,
because each slice of the 3d chromatogram (the separated dimension being
m/z) should correspond with a single m/z. We have yet to settle on the
"right" way to put m/z in the chromatogram elements, even for simpler
concepts like an SRM chromatogram.
>> Yes, I think a background ion chromatogram is reasonable. But there may
>> be some semantics to work out: is there a distinction between
>> "background ions" and "noise"? I know there are different kinds of noise
>> to think about...
>>
> There is a distinction between noise and background ions. The definition
> for a background ion should according to me in LC/MS be a compound which
> is continuously eluting from the LC/GC or continuously being injected
> into the MS. A famous example of this would be PEGs dissolving from the
> plastic tubing used to transport the sample from the LC to the MS. So
> background ions are real (usable) compounds, while noise are artefacts
> from the measurement technique used not describing a real compound.
>
I would argue that both electronic noise and chemical ("real") noise are
kinds of noise. They are also both ways to get a certain level of
background intensity. I glean these meanings from the "signal to noise"
calculation often used. As far as I know, the "noise" denominator there
refers to the sum of electronic and chemical noise. So in my lexicon,
noise and background are nearly synonymous, but "electronic noise" and
"chemical noise" are distinct causes of noise. A "background ion
chromatogram" would also, I expect, refer to the sum of electronic and
chemical noise. How would you separate them?
> Isomers forming a peak on top of the elution pattern of a background ion
> should probably be removed.
>
I'm not sure I understand this statement; does it refer to some data
processing on the raw chromatogram to remove signal when it is
co-eluting with noise?
> If this definition is maintained I think the addition to the CV that I
> proposed still holds, but I could be wrong and more is necessary?
> Probably single spectra (no separation up front) would suffer a bit,
> although then we're not really talking about a chromatogram right?
>
> name: backgroundion chromatogram
> is_a: chromatogram type (MS:1000626)
> definition: chromatogram created by creating an array of a ubiquitously present mass.
>
I'm used to chromatograms referring to either a specific m/z (selected
ion chromatogram), the total ion current, or some mass range within each
spectrum. In the last case, the intensity within the mass range is
summed to create a single value. Does this definition invoke the
"specific m/z" usage by choosing an m/z known to be a source of chemical
noise/background intensity? And if so, we're talking about a specific
kind of selected ion chromatogram?
-Matt
|
|
From: Richard S. <r.a...@ru...> - 2008-12-16 13:57:41
|
My email ended up only in ms-dev, so trying to repost here to.
Dear all,
Thank you for your comments. A question from my side, is the phone
conference scheduled for this afternoon open? As I'm on the agenda I
would like to join if possible.
Matthew Chambers wrote:
> > I'm not sure what this would look like. We certainly didn't have 3d
> > chromatograms in mind, but perhaps they can be accommodated. Would that
> > be a chromatogram with three axes (data arrays): time, m/z, and
> > intensity? Is this akin to the "psuedo-2d-gel" view?
>
The mass chromatogram would indeed consist of time, m/z and intensity.
The m/z data coming from the profile spectrum data. If you plot the mass
chromatogram it will look a bit like a bell. I'm not quite sure what you
mean with the pseudo-2d-gel view, but as I understand it, this is a 2d
view of all the mass chromatograms found in for example a LC/MS profile.
In the definition of the chromatogram block some semantics should be
worked out in order to let the parser figure out what is stored there.
I would suggest something as following (a mass chromatogram spanning 9
scans, sorry for the verbosity of it all). For the centroid data the
original structure would hold with the addition of the cvParam MS:1000127:
<chromatogram id="0" index="0" defaultArrayLength="9">
<cvParam cvRef="MS" accession="MS:1000627" name="selected ion current
chromatogram" value="" />
<cvParam cvRef="MS" accession="MS:1000128" name="profile mass
spectrum" value="" />
<binaryDataArrayList count="19">
<binaryDataArray encodedLength="36">
<cvParam cvRef="MS" accession="MS:1000519" name="32-bit
integer" value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000595" name="time array"
value="" />
<binary>.......</binary>
</binaryDataArray>
// scan 0
<binaryDataArray encodedLength="72">
<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float"
value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000514" name="m/z array"
value="" />
<binary>.......</binary>
</binaryDataArray>
<binaryDataArray encodedLength="72">
<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float"
value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000515" name="intensity
array" value="" />
<binary>.......</binary>
</binaryDataArray>
// scan 1
...
</binaryDataArrayList>
</chromatogram>
> > Yes, I think a background ion chromatogram is reasonable. But there may
> > be some semantics to work out: is there a distinction between
> > "background ions" and "noise"? I know there are different kinds of noise
> > to think about...
>
There is a distinction between noise and background ions. The definition
for a background ion should according to me in LC/MS be a compound which
is continuously eluting from the LC/GC or continuously being injected
into the MS. A famous example of this would be PEGs dissolving from the
plastic tubing used to transport the sample from the LC to the MS. So
background ions are real (usable) compounds, while noise are artefacts
from the measurement technique used not describing a real compound.
Isomers forming a peak on top of the elution pattern of a background ion
should probably be removed.
If this definition is maintained I think the addition to the CV that I
proposed still holds, but I could be wrong and more is necessary?
Probably single spectra (no separation up front) would suffer a bit,
although then we're not really talking about a chromatogram right?
name: backgroundion chromatogram
is_a: chromatogram type (MS:1000626)
definition: chromatogram created by creating an array of a ubiquitously present mass.
David Creasy wrote:
> > We're still alive (I think!), but I don't think we have what you want:
> > http://psidev.info/index.php?q=node/319
>
My _very_ quick overview would make me agree. How would we continue from
here?
Cheers,
Richard
--
Drs. ing. RA Scheltema Groningen Bioinformatics Centre
Tel: +31 50 363 8078 Kerklaan 30
Fax: +31 50 363 7976 9751 NN, Haren
Mob: +31 6 140 280 21 The Netherlands
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618
|
|
From: Richard S. <r.a...@ru...> - 2008-12-16 10:41:30
|
Dear all,
Thank you for your comments. A question from my side, is the phone
conference scheduled for this afternoon open? As I'm on the agenda I
would like to join if possible.
Matthew Chambers wrote:
> I'm not sure what this would look like. We certainly didn't have 3d
> chromatograms in mind, but perhaps they can be accommodated. Would that
> be a chromatogram with three axes (data arrays): time, m/z, and
> intensity? Is this akin to the "psuedo-2d-gel" view?
The mass chromatogram would indeed consist of time, m/z and intensity.
The m/z data coming from the profile spectrum data. If you plot the mass
chromatogram it will look a bit like a bell. I'm not quite sure what you
mean with the pseudo-2d-gel view, but as I understand it, this is a 2d
view of all the mass chromatograms found in for example a LC/MS profile.
In the definition of the chromatogram block some semantics should be
worked out in order to let the parser figure out what is stored there.
I would suggest something as following (a mass chromatogram spanning 9
scans, sorry for the verbosity of it all). For the centroid data the
original structure would hold with the addition of the cvParam MS:1000127:
<chromatogram id="0" index="0" defaultArrayLength="9">
<cvParam cvRef="MS" accession="MS:1000627" name="selected ion current
chromatogram" value="" />
<cvParam cvRef="MS" accession="MS:1000128" name="profile mass
spectrum" value="" />
<binaryDataArrayList count="19">
<binaryDataArray encodedLength="36">
<cvParam cvRef="MS" accession="MS:1000519" name="32-bit
integer" value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000595" name="time array"
value="" />
<binary>.......</binary>
</binaryDataArray>
// scan 0
<binaryDataArray encodedLength="72">
<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float"
value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000514" name="m/z array"
value="" />
<binary>.......</binary>
</binaryDataArray>
<binaryDataArray encodedLength="72">
<cvParam cvRef="MS" accession="MS:1000523" name="64-bit float"
value="" />
<cvParam cvRef="MS" accession="MS:1000576" name="no
compression" value="" />
<cvParam cvRef="MS" accession="MS:1000515" name="intensity
array" value="" />
<binary>.......</binary>
</binaryDataArray>
// scan 1
...
</binaryDataArrayList>
</chromatogram>
> Yes, I think a background ion chromatogram is reasonable. But there may
> be some semantics to work out: is there a distinction between
> "background ions" and "noise"? I know there are different kinds of noise
> to think about...
There is a distinction between noise and background ions. The definition
for a background ion should according to me in LC/MS be a compound which
is continuously eluting from the LC/GC or continuously being injected
into the MS. A famous example of this would be PEGs dissolving from the
plastic tubing used to transport the sample from the LC to the MS. So
background ions are real (usable) compounds, while noise are artefacts
from the measurement technique used not describing a real compound.
Isomers forming a peak on top of the elution pattern of a background ion
should probably be removed.
If this definition is maintained I think the addition to the CV that I
proposed still holds, but I could be wrong and more is necessary?
Probably single spectra (no separation up front) would suffer a bit,
although then we're not really talking about a chromatogram right?
name: backgroundion chromatogram
is_a: chromatogram type (MS:1000626)
definition: chromatogram created by creating an array of a ubiquitously present mass.
David Creasy wrote:
> We're still alive (I think!), but I don't think we have what you want:
> http://psidev.info/index.php?q=node/319
My _very_ quick overview would make me agree. How would we continue from
here?
Cheers,
Richard
--
Drs. ing. RA Scheltema Groningen Bioinformatics Centre
Tel: +31 50 363 8078 Kerklaan 30
Fax: +31 50 363 7976 9751 NN, Haren
Mob: +31 6 140 280 21 The Netherlands
Public PGP key: http://pgp.surfnet.nl:11371/
Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618
|
|
From: David C. <dc...@ma...> - 2008-12-15 18:13:02
|
<!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">
TODOs in the Mascot examples have been removed.<br>
I guess that the CAUTIONs in the MPC example should remain, so if you
could remove them manually from the doc that would be best<br>
- David<br>
<br>
Jones, Andy wrote:
<blockquote
cite="mid:08D...@EV..."
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1367213029;
mso-list-type:hybrid;
mso-list-template-ids:-604096576 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal">We are pretty close to submitting the specs but
there are
quite a few dependencies so to get everything finished we have a few
fixes to
do in order... Here is the to do list as I see it before I can put all
the
final docs together and submit:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top: 0cm;" start="1" type="1">
<li class="MsoNormal" style="">Some fixes to the mapping file
(changing MAY to MUST for most entries for requirement level), except
(I think):<o:p></o:p></li>
<ol style="margin-top: 0cm;" start="1" type="a">
<li class="MsoNormal" style="">GenericMaterial: MAY (we’ll never
cover all options)<o:p></o:p></li>
<li class="MsoNormal" style="">include and exclude (filter) –
this looks like it’s not currently implemented to map to NCBI taxonomy
or NEWT. I guess this will be MAY?<o:p></o:p></li>
<li class="MsoNormal" style="">...psi-pi:SearchDatabase/psi-pi:DatabaseName/pf:cvParam–
SHOULD or MAY? (don’t think we will be able to include all database
names?)<o:p></o:p></li>
</ol>
<li class="MsoNormal" style="">Add CV term and example for
translation table URI<o:p></o:p></li>
<li class="MsoNormal" style="">Add CV term, mapping and example for
setting thresholds e.g. by global FDR<o:p></o:p></li>
<li class="MsoNormal" style="">Regenerate docs<o:p></o:p></li>
</ol>
<p class="MsoNormal" style="margin-left: 36pt;"><o:p> </o:p></p>
<p class="MsoNormal">There are still a couple of problems with
example files that
get picked up by the auto-generation script, eg. “CAUTION...” at
the top of the MPC example and several TODOs in the Mascot examples. I
can
manually remove these from the specs but it would be good to get these
fixed if
possible.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/">http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Psidev-pi-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-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-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: Jones, A. <And...@li...> - 2008-12-15 16:53:03
|
Hi all, We are pretty close to submitting the specs but there are quite a few dependencies so to get everything finished we have a few fixes to do in order... Here is the to do list as I see it before I can put all the final docs together and submit: 1. Some fixes to the mapping file (changing MAY to MUST for most entries for requirement level), except (I think): a. GenericMaterial: MAY (we'll never cover all options) b. include and exclude (filter) - this looks like it's not currently implemented to map to NCBI taxonomy or NEWT. I guess this will be MAY? c. ...psi-pi:SearchDatabase/psi-pi:DatabaseName/pf:cvParam- SHOULD or MAY? (don't think we will be able to include all database names?) 2. Add CV term and example for translation table URI 3. Add CV term, mapping and example for setting thresholds e.g. by global FDR 4. Regenerate docs There are still a couple of problems with example files that get picked up by the auto-generation script, eg. "CAUTION..." at the top of the MPC example and several TODOs in the Mascot examples. I can manually remove these from the specs but it would be good to get these fixed if possible. Cheers Andy |
|
From: <cod...@go...> - 2008-12-15 16:41:50
|
Comment #62 on issue 42 by andrewrobertjones: Issues with the CV http://code.google.com/p/psi-pi/issues/detail?id=42 I think there is a minor issue with the mapping and CV for: <CvMappingRule id="R26" cvElementPath="/psi-pi:AnalysisXML/psi-pi:DataCollection/psi-pi:Inputs/psi-pi:SourceFile/pf:cvParam/@accession" requirementLevel="MAY" scopePath="" cvTermsCombinationLogic="OR"> <CvTerm termAccession="PI:00186" useTermName="false" useTerm="false" termName="source file details" isRepeatable="true" allowChildren="true" cvIdentifierRef="PSI-PI" /> </CvMappingRule> PI:00186 has a child node of source file format and source file name but the source file format is given in a separate CVParam and mapping, this mapping would allow it to be given twice. [Term] id: PI:00040 name: source file format def: "Type of the source file, the AnalysisXML was created from." [PSI:PI] is_a: PI:00186 ! source file details I think PI:00040 should just be child of the root node? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: Jones, A. <And...@li...> - 2008-12-15 16:21:40
|
This reminds me that I noticed we have a problem with the PSI website. If you follow the links from Groups to Proteomics Informatics on the PSI site, you get this page: http://psidev.info/index.php?q=node/70 which is unclear what it contains. I don't know how you can actually browse to the main page (http://psidev.info/index.php?q=node/319). And even worse... if you browse via Workgroups, you get to this page: http://psidev.info/index.php?q=node/40 Would someone be able to fix these please? All links to Proteomics Informatics should go here: http://psidev.info/index.php?q=node/319 thanks Andy > -----Original Message----- > From: David Creasy [mailto:dc...@ma...] > Sent: 15 December 2008 16:13 > To: Richard Scheltema > Cc: psi...@li... > Subject: Re: [Psidev-pi-dev] storing intermediate results in mzML > > Hi Richard, > > You've posted this to the analysisXML list. > I think you should post it to: > psi...@li... > Sorry for any confusion between the two lists. > > > Another thing, I > > once heard somebody mention AnalysisML to be something along these > > lines, however this project seems to have suffered a fatal end as I > > cannot find anything? > > We're still alive (I think!), but I don't think we have what you want: > > http://psidev.info/index.php?q=node/319 > > David > > > Richard Scheltema wrote: > > Dear all, > > > > I'm writing a metabolomics Java library for my processing software > > targeted towards high resolution LC/MS data (components like: peak > > picking, noise detection, etc). The basic element for this library is a > > mass chromatogram (x-axis time, y-axis intensity). In order to deal with > > the size of the datasets, enable other people to easily write > > components, etc. an intermediate file format is required. I've already > > defined one myself to see what would be required for a really dynamic > > pipeline and created a library on top of it. In order to hop on the > > international standards bandwagon I would off course like to move to a > > recognized standard like mzML. However, this _seems_ to fall short of my > > requirements. I've been browsing through this list and the standards > > document and tried to implement something, but I can't seem to figure > > out how to approach this. > > > > What I would like to be able to do is store the following pieces of > > information: > > > > - Multiple runs in a single file > > From the specification document: "A run in mzML should correspond to a > > single, consecutive and coherent set of scans on an instrument". This > > means that I essentially can only store data from a single raw file? I > > would like to do mix-models (see sets). > > > > - MassChromatograms (single mass) > > I would like to ubiquitously store mass chromatograms picked from the > > raw data. This means that both mass chromatograms made from centroid as > > well as profile data need to be stored. There is the option to store > > chromatogram data, but this seems limited to '2D' data where mass > > chromatogram data build with profile data needs '3D' data. In order to > > solve this the accession="MS:1000627" name="selected ion current > > chromatogram" needs sub-children? Or can it be set globally in the > > header or run, but then I would like to be able to mix models (see sets). > > > > - BackgroundIons > > The use of background ions are part of the pipeline. To store this an > > addition to the CV needs to be made. > > name: backgroundion chromatogram > > is_a: chromatogram type (MS:1000626) > > definition: chromatogram created by creating an array of a ubiquitously > > present mass. > > > > - sets > > The goal of the pipeline is to combine information from lots of > > measurements (biological, technical replicates, different machines, etc) > > and do perform various analysis methods. This means for example that > > background ions or mass chromatograms from various measurements need to > > be combined into sets. Different operations and visualizations are then > > possible on the data stored in the files. The same as the different runs > > applies here. Another option would be to make sets of sets, which means > > that the relation needs to be recursive. I can probably solve some of > > the issues with id-fields, but that would make it hard to parse for > > other people and sort of rule out the recursive relation. > > > > > > I can off course solve a lot with the use of userParam tags, but then > > other people will have a hard time reading the data. Another thing, I > > once heard somebody mention AnalysisML to be something along these > > lines, however this project seems to have suffered a fatal end as I > > cannot find anything? Am I trying to use mzML outside of its boundries? > > If so, is a viable alternative available which I have so far been unable > > to find? > > > > > > Cheers, > > Richard > > > > -- > 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 > > Matrix Science Ltd. is registered in England and Wales > Company number 3533898 > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
|
From: Jones, A. <And...@li...> - 2008-12-15 16:16:21
|
Hi David, > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > really looks wrong to me - it's a global value, so we shouldn't have to > report it for each spectrum... (Not to be confused with "PI:00250" > name="local FDR" which is also under SpectrumIdentificationItem) Agreed but I wasn't suggesting this ;-) I put it under SpectrumIdentificationProtocol. Currently, PI:00364 is set as a child term of: [Term] id: PI:00213 name: search result details def: "Scores and global result characteristics So I guess it would be fine to map to this from either AdditionalSearchParams or from SpectrumIdentificationList. Just to be clear, I was suggesting the term be used for a very specific purpose though - documenting which identifications are flagged with passThreshold = "true". It shouldn't impact how many results are actually output by the search engine. I would also vote for putting this as AdditionalSearchParams. Cheers, Andy > -----Original Message----- > From: David Creasy [mailto:dc...@ma...] > Sent: 15 December 2008 16:03 > To: psi...@li... > Subject: Re: [Psidev-pi-dev] Reporting identifications passing threshold > > Hi, > > Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem > really looks wrong to me - it's a global value, so we shouldn't have to > report it for each spectrum... (Not to be confused with "PI:00250" > name="local FDR" which is also under SpectrumIdentificationItem) > > However, there are arguments for putting it in two separate places: > a) <AdditionalSearchParams> > You choose a FDR and the search/analysis software only creates a list of > peptides within that FDR - therefore it is a 'search' parameter. > > b) <SpectrumIdentificationList> > You do the search against a forward and decoy database. From the results > you calculate the global FDR. In this case, I suppose it's part of the > results. > > As far as I'm aware, the net effect for the consumer of the AnalysisXML > document is the same. > > We don't want to allow the same cv term in two places, so I'd vote for > having it under <AdditionalSearchParams> > > Any other thoughts? > > David > > > Jones, Andy wrote: > > Hi all, > > > > I want to insert the following text into the spec document but the first example > > probably will not validate, since this would not be counted as a valid mapping > > for AdditionalSearchParams: > > > > <pf:cvParam accession="PI:00364" name="pep:global FDR" cvRef="PSI-PI" > value = > > "0.01"/> > > > > Can we update this mapping or someone suggest a suitable example CV term for > > setting a threshold for peptide-spectrum matches. > > > > Also, feel free to suggest any amendments to this text. > > > > Cheers > > Andy > > > > > > > > 7.1.4 Reporting peptide and protein identifications passing a significance > > threshold > > > > The elements <SpectrumIdentificationItem> and <ProteinDetectionHypothesis> > have > > a mandatory Boolean attribute passThreshold that allows a file producer to > > indicate that an identification has passed a given threshold or that it has been > > manually validated. Depending on the intended purpose of the file, the file > > producer MAY wish to report a number of identifications that fall below the > > given significance threshold, for example to allow global statistics to be > > performed which is not possible if only identifications passing the threshold > > are reported. If the file producer does not want to indicate that a threshold > > has been set, all identifications MUST have passThreshold = “true”. Thresholds > > for peptide-spectrum matches or for protein identification can be encoded as > > instances of <cvParam> within <SpectrumDetectionProtocol> or > > <ProteinDetectionProtocol> for example as follows: > > > > <SpectrumIdentificationProtocol id="SEQUEST_proto" > > AnalysisSoftware_ref="SEQUEST_SW"> > > <SearchType> > > <pf:cvParam accession="PI:00083" name="ms-ms search" > > cvRef="PSI-PI"/> > > </SearchType> > > <AdditionalSearchParams> > > <pf:cvParam accession="PI:00364" name="pep:global FDR" > > cvRef="PSI-PI" value = "0.01"/> > > ... > > > > > > <ProteinDetectionProtocol id="PDP_MascotParser_1" > > AnalysisSoftware_ref="AS_mascot_parser"> > > <AnalysisParams> > > <pf:cvParam accession="PI:00316" name="mascot:SigThreshold" > cvRef="PSI-PI" > > value="0.05"/> > > … > > > > > > ------------------------------------------------------------------------------ > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > The future of the web can't happen without you. Join us at MIX09 to help > > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > _______________________________________________ > > Psidev-pi-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 > > Matrix Science Ltd. is registered in England and Wales > Company number 3533898 > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
|
From: David C. <dc...@ma...> - 2008-12-15 16:13:17
|
Hi Richard, You've posted this to the analysisXML list. I think you should post it to: psi...@li... Sorry for any confusion between the two lists. > Another thing, I > once heard somebody mention AnalysisML to be something along these > lines, however this project seems to have suffered a fatal end as I > cannot find anything? We're still alive (I think!), but I don't think we have what you want: http://psidev.info/index.php?q=node/319 David Richard Scheltema wrote: > Dear all, > > I'm writing a metabolomics Java library for my processing software > targeted towards high resolution LC/MS data (components like: peak > picking, noise detection, etc). The basic element for this library is a > mass chromatogram (x-axis time, y-axis intensity). In order to deal with > the size of the datasets, enable other people to easily write > components, etc. an intermediate file format is required. I've already > defined one myself to see what would be required for a really dynamic > pipeline and created a library on top of it. In order to hop on the > international standards bandwagon I would off course like to move to a > recognized standard like mzML. However, this _seems_ to fall short of my > requirements. I've been browsing through this list and the standards > document and tried to implement something, but I can't seem to figure > out how to approach this. > > What I would like to be able to do is store the following pieces of > information: > > - Multiple runs in a single file > From the specification document: "A run in mzML should correspond to a > single, consecutive and coherent set of scans on an instrument". This > means that I essentially can only store data from a single raw file? I > would like to do mix-models (see sets). > > - MassChromatograms (single mass) > I would like to ubiquitously store mass chromatograms picked from the > raw data. This means that both mass chromatograms made from centroid as > well as profile data need to be stored. There is the option to store > chromatogram data, but this seems limited to '2D' data where mass > chromatogram data build with profile data needs '3D' data. In order to > solve this the accession="MS:1000627" name="selected ion current > chromatogram" needs sub-children? Or can it be set globally in the > header or run, but then I would like to be able to mix models (see sets). > > - BackgroundIons > The use of background ions are part of the pipeline. To store this an > addition to the CV needs to be made. > name: backgroundion chromatogram > is_a: chromatogram type (MS:1000626) > definition: chromatogram created by creating an array of a ubiquitously > present mass. > > - sets > The goal of the pipeline is to combine information from lots of > measurements (biological, technical replicates, different machines, etc) > and do perform various analysis methods. This means for example that > background ions or mass chromatograms from various measurements need to > be combined into sets. Different operations and visualizations are then > possible on the data stored in the files. The same as the different runs > applies here. Another option would be to make sets of sets, which means > that the relation needs to be recursive. I can probably solve some of > the issues with id-fields, but that would make it hard to parse for > other people and sort of rule out the recursive relation. > > > I can off course solve a lot with the use of userParam tags, but then > other people will have a hard time reading the data. Another thing, I > once heard somebody mention AnalysisML to be something along these > lines, however this project seems to have suffered a fatal end as I > cannot find anything? Am I trying to use mzML outside of its boundries? > If so, is a viable alternative available which I have so far been unable > to find? > > > Cheers, > Richard > -- 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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: Matthew C. <mat...@va...> - 2008-12-15 16:12:11
|
Hi Richard, You posted this message on the analysisXML mailing list. :) I'll cc it to the ms-dev list along with my response, although I expect the PI guys will have valuable comments as well. Richard Scheltema wrote: > Dear all, > > I'm writing a metabolomics Java library for my processing software > targeted towards high resolution LC/MS data (components like: peak > picking, noise detection, etc). The basic element for this library is a > mass chromatogram (x-axis time, y-axis intensity). In order to deal with > the size of the datasets, enable other people to easily write > components, etc. an intermediate file format is required. I've already > defined one myself to see what would be required for a really dynamic > pipeline and created a library on top of it. In order to hop on the > international standards bandwagon I would off course like to move to a > recognized standard like mzML. However, this _seems_ to fall short of my > requirements. I've been browsing through this list and the standards > document and tried to implement something, but I can't seem to figure > out how to approach this. > > What I would like to be able to do is store the following pieces of > information: > > - Multiple runs in a single file > From the specification document: "A run in mzML should correspond to a > single, consecutive and coherent set of scans on an instrument". This > means that I essentially can only store data from a single raw file? I > would like to do mix-models (see sets). > MzML does not support multiple runs in a single file. It was a design decision to make the format simpler. Nothing is stopping you from managing a collection of mzML files as a set, though. But it's important to understand that mzML is intended to store the raw output of a vendor's instrument, as well as processing to the level of a peak list. The chromatogram semantics were tacked on as something of an afterthought: I lobbied for it because on-demand building of chromatograms from tens of thousands of tiny SRM spectra is ridiculously slow. > - MassChromatograms (single mass) > I would like to ubiquitously store mass chromatograms picked from the > raw data. This means that both mass chromatograms made from centroid as > well as profile data need to be stored. There is the option to store > chromatogram data, but this seems limited to '2D' data where mass > chromatogram data build with profile data needs '3D' data. In order to > solve this the accession="MS:1000627" name="selected ion current > chromatogram" needs sub-children? Or can it be set globally in the > header or run, but then I would like to be able to mix models (see sets). > I'm not sure what this would look like. We certainly didn't have 3d chromatograms in mind, but perhaps they can be accommodated. Would that be a chromatogram with three axes (data arrays): time, m/z, and intensity? Is this akin to the "psuedo-2d-gel" view? > - BackgroundIons > The use of background ions are part of the pipeline. To store this an > addition to the CV needs to be made. > name: backgroundion chromatogram > is_a: chromatogram type (MS:1000626) > definition: chromatogram created by creating an array of a ubiquitously > present mass. > Yes, I think a background ion chromatogram is reasonable. But there may be some semantics to work out: is there a distinction between "background ions" and "noise"? I know there are different kinds of noise to think about... > - sets > The goal of the pipeline is to combine information from lots of > measurements (biological, technical replicates, different machines, etc) > and do perform various analysis methods. This means for example that > background ions or mass chromatograms from various measurements need to > be combined into sets. Different operations and visualizations are then > possible on the data stored in the files. The same as the different runs > applies here. Another option would be to make sets of sets, which means > that the relation needs to be recursive. I can probably solve some of > the issues with id-fields, but that would make it hard to parse for > other people and sort of rule out the recursive relation. > > > I can off course solve a lot with the use of userParam tags, but then > other people will have a hard time reading the data. Another thing, I > once heard somebody mention AnalysisML to be something along these > lines, however this project seems to have suffered a fatal end as I > cannot find anything? Am I trying to use mzML outside of its boundries? > If so, is a viable alternative available which I have so far been unable > to find? > AnalysisXML is alive and well and about to submit to the PSI documentation process AFAIK. As I understand it, it is mostly a proteomics identification standard at the moment, but with a flexible enough framework to support other kinds of data in later releases. I don't recall if it supports multiple runs per file. You can check out examples and schema at: http://code.google.com/p/psi-pi/ -Matt |
|
From: David C. <dc...@ma...> - 2008-12-15 16:03:00
|
Hi, Text looks fine to me. Having PI:00364 under SpectrumIdentificationItem really looks wrong to me - it's a global value, so we shouldn't have to report it for each spectrum... (Not to be confused with "PI:00250" name="local FDR" which is also under SpectrumIdentificationItem) However, there are arguments for putting it in two separate places: a) <AdditionalSearchParams> You choose a FDR and the search/analysis software only creates a list of peptides within that FDR - therefore it is a 'search' parameter. b) <SpectrumIdentificationList> You do the search against a forward and decoy database. From the results you calculate the global FDR. In this case, I suppose it's part of the results. As far as I'm aware, the net effect for the consumer of the AnalysisXML document is the same. We don't want to allow the same cv term in two places, so I'd vote for having it under <AdditionalSearchParams> Any other thoughts? David Jones, Andy wrote: > Hi all, > > I want to insert the following text into the spec document but the first example > probably will not validate, since this would not be counted as a valid mapping > for AdditionalSearchParams: > > <pf:cvParam accession="PI:00364" name="pep:global FDR" cvRef="PSI-PI" value = > "0.01"/> > > Can we update this mapping or someone suggest a suitable example CV term for > setting a threshold for peptide-spectrum matches. > > Also, feel free to suggest any amendments to this text. > > Cheers > Andy > > > > 7.1.4 Reporting peptide and protein identifications passing a significance > threshold > > The elements <SpectrumIdentificationItem> and <ProteinDetectionHypothesis> have > a mandatory Boolean attribute passThreshold that allows a file producer to > indicate that an identification has passed a given threshold or that it has been > manually validated. Depending on the intended purpose of the file, the file > producer MAY wish to report a number of identifications that fall below the > given significance threshold, for example to allow global statistics to be > performed which is not possible if only identifications passing the threshold > are reported. If the file producer does not want to indicate that a threshold > has been set, all identifications MUST have passThreshold = “true”. Thresholds > for peptide-spectrum matches or for protein identification can be encoded as > instances of <cvParam> within <SpectrumDetectionProtocol> or > <ProteinDetectionProtocol> for example as follows: > > <SpectrumIdentificationProtocol id="SEQUEST_proto" > AnalysisSoftware_ref="SEQUEST_SW"> > <SearchType> > <pf:cvParam accession="PI:00083" name="ms-ms search" > cvRef="PSI-PI"/> > </SearchType> > <AdditionalSearchParams> > <pf:cvParam accession="PI:00364" name="pep:global FDR" > cvRef="PSI-PI" value = "0.01"/> > ... > > > <ProteinDetectionProtocol id="PDP_MascotParser_1" > AnalysisSoftware_ref="AS_mascot_parser"> > <AnalysisParams> > <pf:cvParam accession="PI:00316" name="mascot:SigThreshold" cvRef="PSI-PI" > value="0.05"/> > … > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: Richard S. <r.a...@ru...> - 2008-12-15 15:47:38
|
Dear all, I'm writing a metabolomics Java library for my processing software targeted towards high resolution LC/MS data (components like: peak picking, noise detection, etc). The basic element for this library is a mass chromatogram (x-axis time, y-axis intensity). In order to deal with the size of the datasets, enable other people to easily write components, etc. an intermediate file format is required. I've already defined one myself to see what would be required for a really dynamic pipeline and created a library on top of it. In order to hop on the international standards bandwagon I would off course like to move to a recognized standard like mzML. However, this _seems_ to fall short of my requirements. I've been browsing through this list and the standards document and tried to implement something, but I can't seem to figure out how to approach this. What I would like to be able to do is store the following pieces of information: - Multiple runs in a single file From the specification document: "A run in mzML should correspond to a single, consecutive and coherent set of scans on an instrument". This means that I essentially can only store data from a single raw file? I would like to do mix-models (see sets). - MassChromatograms (single mass) I would like to ubiquitously store mass chromatograms picked from the raw data. This means that both mass chromatograms made from centroid as well as profile data need to be stored. There is the option to store chromatogram data, but this seems limited to '2D' data where mass chromatogram data build with profile data needs '3D' data. In order to solve this the accession="MS:1000627" name="selected ion current chromatogram" needs sub-children? Or can it be set globally in the header or run, but then I would like to be able to mix models (see sets). - BackgroundIons The use of background ions are part of the pipeline. To store this an addition to the CV needs to be made. name: backgroundion chromatogram is_a: chromatogram type (MS:1000626) definition: chromatogram created by creating an array of a ubiquitously present mass. - sets The goal of the pipeline is to combine information from lots of measurements (biological, technical replicates, different machines, etc) and do perform various analysis methods. This means for example that background ions or mass chromatograms from various measurements need to be combined into sets. Different operations and visualizations are then possible on the data stored in the files. The same as the different runs applies here. Another option would be to make sets of sets, which means that the relation needs to be recursive. I can probably solve some of the issues with id-fields, but that would make it hard to parse for other people and sort of rule out the recursive relation. I can off course solve a lot with the use of userParam tags, but then other people will have a hard time reading the data. Another thing, I once heard somebody mention AnalysisML to be something along these lines, however this project seems to have suffered a fatal end as I cannot find anything? Am I trying to use mzML outside of its boundries? If so, is a viable alternative available which I have so far been unable to find? Cheers, Richard -- Drs. ing. RA Scheltema Groningen Bioinformatics Centre Tel: +31 50 363 8078 Kerklaan 30 Fax: +31 50 363 7976 9751 NN, Haren Mob: +31 6 140 280 21 The Netherlands Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 3A4F 3029 DF7D 2562 6653 053B 458C 39E7 C428 4618 |
|
From: Jones, A. <And...@li...> - 2008-12-15 15:17:39
|
Hi David, I think that CV term looks fine to me as long as its use is optional. I guess we may need to add some other options later in case other translation tables are used that don't have a URL to identify them, Cheers Andy > -----Original Message----- > From: David Creasy [mailto:dc...@ma...] > Sent: 15 December 2008 14:39 > To: psi...@li... > Subject: Re: [Psidev-pi-dev] Minutes of Telecon. 11th December > > Hi everyone, > > From the minutes: > > Encoding NCBI translational tables, I'm not sure about the current > > encoding in the instance doc - id numbers match NCBI accession numbers > > - just in document references. David to change to make simpler. Add in > > a translation table source location.. > > The change isn't so much to make it simpler, but to make it clearer. > > <TranslationTable id="1" name="Standard"> > . . . > <PeptideEvidence ... TranslationTable_ref="1"> > > > Will become: > <TranslationTable id="TT_1" name="Standard"> > . . . > <PeptideEvidence ... TranslationTable_ref="TT_1"> > > The aim is to try and avoid any confusion with the '1' being an NCBI id > value - it is just an internal reference value. > > > Now google is back up and running (thought the world would end if google > went down...), I can check in the changed example file. > > > > David to look over and propose a > CV term so it is known where the > > value has come from. > > How about another CV term: > > [Term] > id: PI:xxxxx > name: translation table description > def: "A URL that describes the translation table used to translate the > nucleotides to amino acids." [PSI:PI] > xref_analog: value-type:xsd\:anyURI "The allowed value-type for this CV > term." > is_a: PI:00011 ! search database details > > > <pf:cvParam accession="PI:00xxx" name="translation table description" > cvRef="PSI-PI" > value="http://www.ncbi.nlm.nih.gov/Taxonomy/taxonomyhome.html/index.cgi?chapt > er=cgencodes#SG1" > > > > Does this look reasonable, or can someone think of a better way of doing it? > > > David > > Jennifer Siepen wrote: > > Hi, > > > > Please find the minutes of todays teleconference here: > > > > http://www.psidev.info/index.php?q=node/400 > > > > Thanks, > > > > Jenny > > > > -- > 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 > > Matrix Science Ltd. is registered in England and Wales > Company number 3533898 > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
|
From: David C. <dc...@ma...> - 2008-12-15 14:39:20
|
Hi everyone, From the minutes: > Encoding NCBI translational tables, I'm not sure about the current > encoding in the instance doc - id numbers match NCBI accession numbers > - just in document references. David to change to make simpler. Add in > a translation table source location.. The change isn't so much to make it simpler, but to make it clearer. <TranslationTable id="1" name="Standard"> . . . <PeptideEvidence ... TranslationTable_ref="1"> Will become: <TranslationTable id="TT_1" name="Standard"> . . . <PeptideEvidence ... TranslationTable_ref="TT_1"> The aim is to try and avoid any confusion with the '1' being an NCBI id value - it is just an internal reference value. Now google is back up and running (thought the world would end if google went down...), I can check in the changed example file. > David to look over and propose a > CV term so it is known where the > value has come from. How about another CV term: [Term] id: PI:xxxxx name: translation table description def: "A URL that describes the translation table used to translate the nucleotides to amino acids." [PSI:PI] xref_analog: value-type:xsd\:anyURI "The allowed value-type for this CV term." is_a: PI:00011 ! search database details <pf:cvParam accession="PI:00xxx" name="translation table description" cvRef="PSI-PI" value="http://www.ncbi.nlm.nih.gov/Taxonomy/taxonomyhome.html/index.cgi?chapter=cgencodes#SG1" Does this look reasonable, or can someone think of a better way of doing it? David Jennifer Siepen wrote: > Hi, > > Please find the minutes of todays teleconference here: > > http://www.psidev.info/index.php?q=node/400 > > Thanks, > > Jenny > -- 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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: Jones, A. <And...@li...> - 2008-12-15 14:11:12
|
> Also, throughout we have the attribute cvTermsCombinationLogic set as "OR". > This > means that only one of the terms listed can be provided. Some of these should > definitely be "AND" e.g. AdditionalSearchParams. I would guess that they should > all be set to "AND" by default. If only one term should be provided, this is > almost certainly checked in the schema anyway e.g. SearchType. I can't think of > any other examples where we want to use an OR for restricting the terms that can > be selected. I think this attribute was added to the mapping file XSD in essence > to encode some ontology logic for mzML that couldn't be done in OBO. Hmm, maybe I'm wrong about the purpose of AND and OR here, since there is also an XOR option. > -----Original Message----- > From: Jones, Andy [mailto:And...@li...] > Sent: 15 December 2008 14:03 > To: Andreas Bertsch; psi...@li... > Subject: Re: [Psidev-pi-dev] Minutes of Telecon. 11th December > > Hi Andreas, > > I've just looked through the mapping file and I think we have some errors in how > it's being implemented at the moment. Each mapping has the requirementLevel set > as "MAY", which means that the terms are optional and should not throw an error > if they are not provided. > > I think most of these should be set as "MUST" with a few exceptions e.g. > GenericMaterial (where descriptive terms could come from anywhere), which > should > be set as "MAY"? > > Also, throughout we have the attribute cvTermsCombinationLogic set as "OR". > This > means that only one of the terms listed can be provided. Some of these should > definitely be "AND" e.g. AdditionalSearchParams. I would guess that they should > all be set to "AND" by default. If only one term should be provided, this is > almost certainly checked in the schema anyway e.g. SearchType. I can't think of > any other examples where we want to use an OR for restricting the terms that can > be selected. I think this attribute was added to the mapping file XSD in essence > to encode some ontology logic for mzML that couldn't be done in OBO. > > Each term has the attribute isRepeatable set to true at the moment. By default, > I think all of these should be set to false (Documentation: "Value is 'True' > when a term can be repeated in the same instance of the associated XML > element.") > > > Cheers > Andy > > > > > > > > > > > > > > > > -----Original Message----- > > From: Andreas Bertsch [mailto:be...@in...] > > Sent: 15 December 2008 10:40 > > To: psi...@li... > > Subject: Re: [Psidev-pi-dev] Minutes of Telecon. 11th December > > > > Hi David, hi all, > > > > > The Mascot examples have been updated and validate against the schema. > > > > > > Andreas, I'm not sure why, but I get this from the validator: > > > > > > Validation against the schema: > > > Error at file Mascot_MSMS_example.axml, line 691, char 193 Message: > > > attribute 'passThreshold' is not declared for element > > > 'SpectrumIdentificationItem' > > > But it is? I must be missing something subtle! > > Sorry, the schema for validation was not up-to-date. > > > > > Also, for PMF I get: > > > > > > Error: CV term used in invalid element: 'PI:00362 - number of unmatched > > > peaks' at element > > > '/AnalysisXML/DataCollection/AnalysisData/ProteinDetectionList/ProteinAmbig > > >uityGroup/ProteinDetectionHypothesis' But I think I have put it in the > > > correct place. Or maybe not... > > You're right. I've updated the cv and added the parent PI:00116 "single > > protein result details". > > > > All allowed terms for a specific location in the schema can be found at > > "http://www-bs2.informatik.uni- > > tuebingen.de/services/OpenMS/analysisXML/mapping_and_cv.html" everything > > which > > is not listed here, will probably not validate! > > > > Best, > > A. > > > > > > > > -- > > Div. for Simulation of Biological Systems, WSI, University of Tuebingen > > Room C322, Sand 14, 72076 Tuebingen, Germany > > phone: +49-7071-29-70461 fax: +49-7071-29-5152 > > http://www-bs.informatik.uni-tuebingen.de > > > > ------------------------------------------------------------------------------ > > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > > The future of the web can't happen without you. Join us at MIX09 to help > > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > _______________________________________________ > > Psidev-pi-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
|
From: Jones, A. <And...@li...> - 2008-12-15 14:03:25
|
Hi all,
I want to insert the following text into the spec document but the first example
probably will not validate, since this would not be counted as a valid mapping
for AdditionalSearchParams:
<pf:cvParam accession="PI:00364" name="pep:global FDR" cvRef="PSI-PI" value =
"0.01"/>
Can we update this mapping or someone suggest a suitable example CV term for
setting a threshold for peptide-spectrum matches.
Also, feel free to suggest any amendments to this text.
Cheers
Andy
7.1.4 Reporting peptide and protein identifications passing a significance
threshold
The elements <SpectrumIdentificationItem> and <ProteinDetectionHypothesis> have
a mandatory Boolean attribute passThreshold that allows a file producer to
indicate that an identification has passed a given threshold or that it has been
manually validated. Depending on the intended purpose of the file, the file
producer MAY wish to report a number of identifications that fall below the
given significance threshold, for example to allow global statistics to be
performed which is not possible if only identifications passing the threshold
are reported. If the file producer does not want to indicate that a threshold
has been set, all identifications MUST have passThreshold = “true”. Thresholds
for peptide-spectrum matches or for protein identification can be encoded as
instances of <cvParam> within <SpectrumDetectionProtocol> or
<ProteinDetectionProtocol> for example as follows:
<SpectrumIdentificationProtocol id="SEQUEST_proto"
AnalysisSoftware_ref="SEQUEST_SW">
<SearchType>
<pf:cvParam accession="PI:00083" name="ms-ms search"
cvRef="PSI-PI"/>
</SearchType>
<AdditionalSearchParams>
<pf:cvParam accession="PI:00364" name="pep:global FDR"
cvRef="PSI-PI" value = "0.01"/>
...
<ProteinDetectionProtocol id="PDP_MascotParser_1"
AnalysisSoftware_ref="AS_mascot_parser">
<AnalysisParams>
<pf:cvParam accession="PI:00316" name="mascot:SigThreshold" cvRef="PSI-PI"
value="0.05"/>
…
|
|
From: Jones, A. <And...@li...> - 2008-12-15 14:03:15
|
Hi Andreas, I've just looked through the mapping file and I think we have some errors in how it's being implemented at the moment. Each mapping has the requirementLevel set as "MAY", which means that the terms are optional and should not throw an error if they are not provided. I think most of these should be set as "MUST" with a few exceptions e.g. GenericMaterial (where descriptive terms could come from anywhere), which should be set as "MAY"? Also, throughout we have the attribute cvTermsCombinationLogic set as "OR". This means that only one of the terms listed can be provided. Some of these should definitely be "AND" e.g. AdditionalSearchParams. I would guess that they should all be set to "AND" by default. If only one term should be provided, this is almost certainly checked in the schema anyway e.g. SearchType. I can't think of any other examples where we want to use an OR for restricting the terms that can be selected. I think this attribute was added to the mapping file XSD in essence to encode some ontology logic for mzML that couldn't be done in OBO. Each term has the attribute isRepeatable set to true at the moment. By default, I think all of these should be set to false (Documentation: "Value is 'True' when a term can be repeated in the same instance of the associated XML element.") Cheers Andy > -----Original Message----- > From: Andreas Bertsch [mailto:be...@in...] > Sent: 15 December 2008 10:40 > To: psi...@li... > Subject: Re: [Psidev-pi-dev] Minutes of Telecon. 11th December > > Hi David, hi all, > > > The Mascot examples have been updated and validate against the schema. > > > > Andreas, I'm not sure why, but I get this from the validator: > > > > Validation against the schema: > > Error at file Mascot_MSMS_example.axml, line 691, char 193 Message: > > attribute 'passThreshold' is not declared for element > > 'SpectrumIdentificationItem' > > But it is? I must be missing something subtle! > Sorry, the schema for validation was not up-to-date. > > > Also, for PMF I get: > > > > Error: CV term used in invalid element: 'PI:00362 - number of unmatched > > peaks' at element > > '/AnalysisXML/DataCollection/AnalysisData/ProteinDetectionList/ProteinAmbig > >uityGroup/ProteinDetectionHypothesis' But I think I have put it in the > > correct place. Or maybe not... > You're right. I've updated the cv and added the parent PI:00116 "single > protein result details". > > All allowed terms for a specific location in the schema can be found at > "http://www-bs2.informatik.uni- > tuebingen.de/services/OpenMS/analysisXML/mapping_and_cv.html" everything > which > is not listed here, will probably not validate! > > Best, > A. > > > > -- > Div. for Simulation of Biological Systems, WSI, University of Tuebingen > Room C322, Sand 14, 72076 Tuebingen, Germany > phone: +49-7071-29-70461 fax: +49-7071-29-5152 > http://www-bs.informatik.uni-tuebingen.de > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev |
|
From: Andreas B. <be...@in...> - 2008-12-15 10:38:28
|
Hi David, hi all, > The Mascot examples have been updated and validate against the schema. > > Andreas, I'm not sure why, but I get this from the validator: > > Validation against the schema: > Error at file Mascot_MSMS_example.axml, line 691, char 193 Message: > attribute 'passThreshold' is not declared for element > 'SpectrumIdentificationItem' > But it is? I must be missing something subtle! Sorry, the schema for validation was not up-to-date. > Also, for PMF I get: > > Error: CV term used in invalid element: 'PI:00362 - number of unmatched > peaks' at element > '/AnalysisXML/DataCollection/AnalysisData/ProteinDetectionList/ProteinAmbig >uityGroup/ProteinDetectionHypothesis' But I think I have put it in the > correct place. Or maybe not... You're right. I've updated the cv and added the parent PI:00116 "single protein result details". All allowed terms for a specific location in the schema can be found at "http://www-bs2.informatik.uni- tuebingen.de/services/OpenMS/analysisXML/mapping_and_cv.html" everything which is not listed here, will probably not validate! Best, A. -- Div. for Simulation of Biological Systems, WSI, University of Tuebingen Room C322, Sand 14, 72076 Tuebingen, Germany phone: +49-7071-29-70461 fax: +49-7071-29-5152 http://www-bs.informatik.uni-tuebingen.de |
|
From: David C. <dc...@ma...> - 2008-12-14 22:39:06
|
The Mascot examples have been updated and validate against the schema. Andreas, I'm not sure why, but I get this from the validator: Validation against the schema: Error at file Mascot_MSMS_example.axml, line 691, char 193 Message: attribute 'passThreshold' is not declared for element 'SpectrumIdentificationItem' But it is? I must be missing something subtle! Also, for PMF I get: Error: CV term used in invalid element: 'PI:00362 - number of unmatched peaks' at element '/AnalysisXML/DataCollection/AnalysisData/ProteinDetectionList/ProteinAmbiguityGroup/ProteinDetectionHypothesis' But I think I have put it in the correct place. Or maybe not... Thanks, David Jones, Andy wrote: > New schema uploaded by SVN: > > Made rank attribute mandatory. > > Added attribute passThreshold to SpectrumIdentificationItem and > ProteinDetectionHypothesis. > > > >> -----Original Message----- >> From: Jennifer Siepen [mailto:jen...@ma...] >> Sent: 11 December 2008 17:22 >> To: psi...@li... >> Subject: [Psidev-pi-dev] Minutes of Telecon. 11th December >> >> Hi, >> >> Please find the minutes of todays teleconference here: >> >> http://www.psidev.info/index.php?q=node/400 >> >> Thanks, >> >> Jenny >> >> -- >> >> Dr. Jennifer Siepen >> Research Associate >> University of Manchester >> Faculty of Life Sciences >> Michael Smith Building >> Manchester >> M13 9PT >> >> Tel: 0161 275 1680 >> >> >> ------------------------------------------------------------------------------ >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. >> The future of the web can't happen without you. Join us at MIX09 to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> Psidev-pi-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
42 messages has been excluded from this view by a project administrator.
