psidev-pi-dev — General Development List for Proteomics Informatics

Re: [Psidev-pi-dev] FW: Spec doc

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

Just a question about these tolerances:
if one need to specify a union of 2 sets of tolerances, such as 200ppm 
and 0.1Da (which means 200ppm with a minimum of 0.1Da), can one just 
have twice the pair of tolerances? for instance:

      <FragmentTolerance>
        <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
unitCvRef="UO" />
        <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
value="500" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="ppm" 
unitCvRef="UO" />
        <pf:cvParam accession="PI:00413" name="search tolerance minus value" 
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
unitCvRef="UO" />
        <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
value="500" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="ppm" 
unitCvRef="UO" />
      </FragmentTolerance>


Pierre-Alain


Andreas Bertsch wrote:
> Hi David,
>
>   
>> Andy suggested:
>> Andreas can you add: “search tolerance plus value” and “search tolerance
>> minus value” to the CV and mapping file and I’ll change the schema, does
>> this seem reasonable to everyone…?
>>     
> Sorry, that is my fault, I have overlooked this structure. I have added the cv 
> two terms, 412 and 413, plus and minus value. The Mascot MSMS example would 
> look like this using the new terms.
>
>       <FragmentTolerance>
>         <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
> unitCvRef="UO" />
>         <pf:cvParam accession="PI:00413" name="search tolerance minus value" 
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
> unitCvRef="UO" />
>       </FragmentTolerance>
>       <ParentTolerance>
>         <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent" 
> unitCvRef="UO" />
>         <pf:cvParam accession="PI:00413" name="search tolerance minus value" 
> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent" 
> unitCvRef="UO" />
>       </ParentTolerance>
>
> I have also updated the mapping file accordingly. Now two values (exactly two 
> terms) are required, one plus and one minus value. The units are directly 
> associated with the two terms. So the "mass units" tree becomes obsolete 
> (absolut(e)ly), and I would suggest to delete it, if there is no good reason 
> to keep it. I also think that a distinction into absolute and relative is not 
> necessary as it is clear by specifying the units.
>
>   
>> So, I think that we must add the two CV terms Andy originally suggested?
>> Could you do that please? (I don't think Martin will be doing any edits).
>>     
> Done. Semantic validator is also updated. Sorry for any inconvencience.
>
> Thanks,
> A.
>
>
>   

Re: [Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi all,

New spec doc uploaded by SVN: 

Several updates, inserted new auto-generated documentation, section on
spectrumID, section on internal ions, added listing of example files.

Hopefully the images should appear this time, let me know if they don't. Can
everyone take a look in particular at the comments in the margin. Also we need a
more complete list of the contributors at the end, please mail me names of
people to add.

Cheers
Andy








> -----Original Message-----
> From: Andreas Bertsch [mailto:be...@in...]
> Sent: 04 December 2008 15:10
> To: David Creasy
> Cc: psi...@li...
> Subject: Re: [Psidev-pi-dev] FW: Spec doc
> 
> Hi David,
> 
> > Andy suggested:
> > Andreas can you add: “search tolerance plus value” and “search tolerance
> > minus value” to the CV and mapping file and I’ll change the schema, does
> > this seem reasonable to everyone…?
> Sorry, that is my fault, I have overlooked this structure. I have added the cv
> two terms, 412 and 413, plus and minus value. The Mascot MSMS example would
> look like this using the new terms.
> 
>       <FragmentTolerance>
>         <pf:cvParam accession="PI:00412" name="search tolerance plus value"
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
> unitCvRef="UO" />
>         <pf:cvParam accession="PI:00413" name="search tolerance minus value"
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
> unitCvRef="UO" />
>       </FragmentTolerance>
>       <ParentTolerance>
>         <pf:cvParam accession="PI:00412" name="search tolerance plus value"
> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent"
> unitCvRef="UO" />
>         <pf:cvParam accession="PI:00413" name="search tolerance minus value"
> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent"
> unitCvRef="UO" />
>       </ParentTolerance>
> 
> I have also updated the mapping file accordingly. Now two values (exactly two
> terms) are required, one plus and one minus value. The units are directly
> associated with the two terms. So the "mass units" tree becomes obsolete
> (absolut(e)ly), and I would suggest to delete it, if there is no good reason
> to keep it. I also think that a distinction into absolute and relative is not
> necessary as it is clear by specifying the units.
> 
> > So, I think that we must add the two CV terms Andy originally suggested?
> > Could you do that please? (I don't think Martin will be doing any edits).
> Done. Semantic validator is also updated. Sorry for any inconvencience.
> 
> Thanks,
> 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
> 
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] FW: Spec doc

[Andreas B. <be...@in...>]

Hi David,

> Andy suggested:
> Andreas can you add: “search tolerance plus value” and “search tolerance
> minus value” to the CV and mapping file and I’ll change the schema, does
> this seem reasonable to everyone…?
Sorry, that is my fault, I have overlooked this structure. I have added the cv 
two terms, 412 and 413, plus and minus value. The Mascot MSMS example would 
look like this using the new terms.

      <FragmentTolerance>
        <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
unitCvRef="UO" />
        <pf:cvParam accession="PI:00413" name="search tolerance minus value" 
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton" 
unitCvRef="UO" />
      </FragmentTolerance>
      <ParentTolerance>
        <pf:cvParam accession="PI:00412" name="search tolerance plus value" 
value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent" 
unitCvRef="UO" />
        <pf:cvParam accession="PI:00413" name="search tolerance minus value" 
value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent" 
unitCvRef="UO" />
      </ParentTolerance>

I have also updated the mapping file accordingly. Now two values (exactly two 
terms) are required, one plus and one minus value. The units are directly 
associated with the two terms. So the "mass units" tree becomes obsolete 
(absolut(e)ly), and I would suggest to delete it, if there is no good reason 
to keep it. I also think that a distinction into absolute and relative is not 
necessary as it is clear by specifying the units.

> So, I think that we must add the two CV terms Andy originally suggested?
> Could you do that please? (I don't think Martin will be doing any edits).
Done. Semantic validator is also updated. Sorry for any inconvencience.

Thanks,
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

Re: [Psidev-pi-dev] FW: Spec doc

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

Hi Andreas,

 > (Maybe the CV and mapping file look much clearer with enough absolut)
I'm not sure why you can see double
CV entries for the fragment and parent tolerance ;)

So, originally we had:
<PlusValue   >
<MinusValue  >

Andy suggested:
Andreas can you add: “search tolerance plus value” and “search tolerance 
minus value” to the CV and mapping file and I’ll change the schema, does 
this seem reasonable to everyone…?

I looked in the mapping file and saw:
         <CvMappingRule id="R17a" 
cvElementPath="/psi-pi:AnalysisXML/psi-pi:AnalysisProtocolCollection/psi-pi:SpectrumIdentificationProtocol/psi-pi:ParentTolerance/pf:cvParam/@accession" 
requirementLevel="MUST"  scopePath="" cvTermsCombinationLogic="OR">
             <CvTerm termAccession="PI:00402" useTermName="false" 
useTerm="false" termName="mass units" isRepeatable="false" 
allowChildren="true" cvIdentifierRef="PSI-PI" />
         </CvMappingRule>


and then must have forgotten what we were trying to do....

So, I think that we must add the two CV terms Andy originally suggested?
Could you do that please? (I don't think Martin will be doing any edits).

Thanks,

David

Andreas Bertsch wrote:
> Hi David,
> 
>>  I've updated the Mascot_MSMS_example.axml,
>>        <FragmentTolerance>
>>          <pf:cvParam accession="PI:00404" name="absolut mass unit"
>> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
>> unitCvRef="UO" /> <pf:cvParam accession="PI:00404" name="absolut mass unit"
>> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
>> unitCvRef="UO" /> </FragmentTolerance>
>>        <ParentTolerance>
>>          <pf:cvParam accession="PI:00403" name="relative mass unit"
>> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent"
>> unitCvRef="UO" /> <pf:cvParam accession="PI:00403" name="relative mass
>> unit" value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187"
>> unitName="percent" unitCvRef="UO" /> </ParentTolerance>
> Is there a reason to repeat the unit lines? I've added term UO:0000187 percent 
> to the allowed ones, this is a synonym of parts per hundred, however 
> separately listed in unit.obo...
> 
>>  but this doesn't validate:
> The file still does not validate with some new errors, as you suggested ;)
> Error: Name of CVTerm not correct: 'PI:00404 - absolut mass unit' should be 
> 'absolute mass unit'
> Error: Violated mapping rule 'R17a' number of term repeats at element 
> '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/ParentTolerance'
> Error: Violated mapping rule 'R17b' number of term repeats at element 
> '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/FragmentTolerance'
> 
> Blame me, if you experience other unexpected results.
> 
>>  I'm also slightly concerned about PSI-PI group getting the wrong(?)
>> reputation. Martin, could you change PI:00404 from being a brand of vodka
>> to "absolute". Thanks. (I've still not installed OboEdit.)
> (Maybe the CV and mapping file look much clearer with enough absolut)
> @Martin: I've changed terms 403 and 404, added value-types and added 
> percentage unit. Hopefully this merges with your local changes (if any).
> 
> Thanks,
> A.
> 
> 

-- 
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

Re: [Psidev-pi-dev] FW: Spec doc

[Andreas B. <be...@in...>]

Hi David,

>  I've updated the Mascot_MSMS_example.axml,
>        <FragmentTolerance>
>          <pf:cvParam accession="PI:00404" name="absolut mass unit"
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
> unitCvRef="UO" /> <pf:cvParam accession="PI:00404" name="absolut mass unit"
> value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
> unitCvRef="UO" /> </FragmentTolerance>
>        <ParentTolerance>
>          <pf:cvParam accession="PI:00403" name="relative mass unit"
> value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187" unitName="percent"
> unitCvRef="UO" /> <pf:cvParam accession="PI:00403" name="relative mass
> unit" value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187"
> unitName="percent" unitCvRef="UO" /> </ParentTolerance>
Is there a reason to repeat the unit lines? I've added term UO:0000187 percent 
to the allowed ones, this is a synonym of parts per hundred, however 
separately listed in unit.obo...

>  but this doesn't validate:
The file still does not validate with some new errors, as you suggested ;)
Error: Name of CVTerm not correct: 'PI:00404 - absolut mass unit' should be 
'absolute mass unit'
Error: Violated mapping rule 'R17a' number of term repeats at element 
'/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/ParentTolerance'
Error: Violated mapping rule 'R17b' number of term repeats at element 
'/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/FragmentTolerance'

Blame me, if you experience other unexpected results.

>  I'm also slightly concerned about PSI-PI group getting the wrong(?)
> reputation. Martin, could you change PI:00404 from being a brand of vodka
> to "absolute". Thanks. (I've still not installed OboEdit.)
(Maybe the CV and mapping file look much clearer with enough absolut)
@Martin: I've changed terms 403 and 404, added value-types and added 
percentage unit. Hopefully this merges with your local changes (if any).

Thanks,
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

Re: [Psidev-pi-dev] FW: Spec doc

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Andy, Andreas,<br>
<br>
I assume that this is a typo below:<br>
<pre><span style="font-size: 8pt;" lang="EN-US">&lt;pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5” cvRef="PSI-PI"<o:p></o:p></span></pre>
<p class="MsoNormal"><span
 style="font-size: 8pt; font-family: &quot;Courier New&quot;;" lang="EN-US">unitAccession="UO:0000221"
name="dalton" cvRef="UO" /&gt;<o:p></o:p></span></p>
<span style="color: rgb(31, 73, 125);"><o:p></o:p></span><br>
and the second cvRef is meant to be a unitCvRef??<br>
<br>
I've updated the Mascot_MSMS_example.axml, <br>
<small><tt>      &lt;FragmentTolerance&gt;<br>
        &lt;pf:cvParam accession="PI:00404" name="absolut mass unit"
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
unitCvRef="UO" /&gt;<br>
        &lt;pf:cvParam accession="PI:00404" name="absolut mass unit"
value="0.5" cvRef="PSI-PI" unitAccession="UO:0000221" unitName="dalton"
unitCvRef="UO" /&gt;<br>
      &lt;/FragmentTolerance&gt;<br>
      &lt;ParentTolerance&gt;<br>
        &lt;pf:cvParam accession="PI:00403" name="relative mass unit"
value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187"
unitName="percent" unitCvRef="UO" /&gt;<br>
        &lt;pf:cvParam accession="PI:00403" name="relative mass unit"
value="0.1" cvRef="PSI-PI" unitAccession="UO:0000187"
unitName="percent" unitCvRef="UO" /&gt;<br>
      &lt;/ParentTolerance&gt;<br>
</tt></small><br>
<br>
but this doesn't validate:<br>
<br>
<pre><font color="red">Error: Unit CVTerm not allowed: UO:0000187 - percent of term PI:00403 - relative mass unit</font>
<font color="red">Error: Unit CVTerm not allowed: UO:0000221 - dalton of term PI:00404 - absolut mass unit</font>
<font color="red">Error: Value of CVTerm not allowed: 'PI:00403 - relative mass unit, value=0.1' at element '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/ParentTolerance'</font>
<font color="red">Error: Value of CVTerm not allowed: 'PI:00404 - absolut mass unit, value=0.5' at element '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/FragmentTolerance'</font>
<font color="red">Error: Violated mapping rule 'R17a' number of term repeats at element '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/ParentTolerance'</font>
<font color="red">Error: Violated mapping rule 'R17b' number of term repeats at element '/AnalysisXML/AnalysisProtocolCollection/SpectrumIdentificationProtocol/FragmentTolerance'

</font></pre>
What am I doing wrong?<br>
<br>
I'm also slightly concerned about PSI-PI group getting the wrong(?)
reputation. Martin, could you change PI:00404 from being a brand of
vodka to "absolute". Thanks.<br>
(I've still not installed OboEdit.)<br>
<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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 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";
	color:black;}
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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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"><span style="color: rgb(31, 73, 125);">Hi all,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">New
schema uploaded:<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Various
documentation changes, as
discussed below.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">PlusValue
/ MinusValue now
encoded as CVParams<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Made a
change to
AnalysisProtocolCollection and AnalysisCollection that prevented
GenericProtocol and GenericProtocolApplication being used – I’ve been
meaning
to fix this for a while. It also means the files are now restricted to
containing at most one ProteinDetection and one
ProteinDetectionApplication.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">In the
schema, we have some
fairly pointless abstract classes AnalysisProtocol and
AnalysisProtocolApplication. They were put in the schema at one stage
to
demonstrate how the format should be extended in the future, following
this
design pattern (or something like this...). I vote we get rid of them,
and
write in the spec document about future extension strategies.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Cheers<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: windowtext;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: windowtext;"
 lang="EN-US">
Jones, Andy [<a class="moz-txt-link-freetext" href="mailto:And...@li...">mailto:And...@li...</a>] <br>
  <b>Sent:</b> 02 December 2008 12:23<br>
  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> Re: [Psidev-pi-dev] FW: Spec doc<o:p></o:p></span></p>
  </div>
  </div>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi David,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">The
changes relating the
instance docs are coming from the Mascot MS/MS example so these are for
you to
fix ;-)<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Eric, are
you able to import
certain parts of the instance docs from other examples. Element
&lt;DatabaseTranslation&gt; could take examples from
Mascot_NA_example.axml? <o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">I’ll make
the other recommended
changes to the XSD documentation (some of these require a fix to the
generating
script, which I’ve flagged to Eric separately).<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Martin,
are you happy for us to
make the change relating to peptide mass documentation (see below).<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">&gt;semiSpecific
- shouldn't
this be a boolean?<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Agreed,
I’ll make this change.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">&gt;&lt;PlusValue&gt;<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Eric is
right to query this part
of the schema. In fact, we’ve used the PropertyValue element only for
PlusValue
and MinusValue in the entire schema. Let’s make these CV terms:<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <pre><span style="font-size: 8pt;" lang="EN-US">&lt;pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5” cvRef="PSI-PI"<o:p></o:p></span></pre>
  <p class="MsoNormal"><span
 style="font-size: 8pt; font-family: &quot;Courier New&quot;;" lang="EN-US">unitAccession="UO:0000221"
name="dalton" cvRef="UO" /&gt;<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andreas
can you add: “</span><span style="color: rgb(31, 73, 125);" lang="EN-US">search
tolerance plus value” and “search
tolerance minus value” to the CV and mapping file and I’ll change the
schema,
does this seem reasonable to everyone…?<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"
 lang="EN-US">Getting there…<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"
 lang="EN-US">Cheers<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"
 lang="EN-US">Andy<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: windowtext;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;; color: windowtext;"
 lang="EN-US">
Pierre-Alain Binz [<a class="moz-txt-link-freetext" href="mailto:pie...@is...">mailto:pie...@is...</a>] <br>
  <b>Sent:</b> 02 December 2008 11:17<br>
  <b>To:</b> David Creasy<br>
  <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> Re: [Psidev-pi-dev] FW: Spec doc<o:p></o:p></span></p>
  </div>
  </div>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">Hi,<br>
  <br>
David Creasy wrote: <o:p></o:p></p>
  <p class="MsoNormal">Hi Andy,<br>
  <br>
Some minor changes:<o:p></o:p></p>
  <pre>From:<o:p></o:p></pre>
  <pre>&lt;pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person" email=<a
 moz-do-not-send="true" href="mailto:so...@so...">"so...@so..."</a>&gt;<o:p></o:p></pre>
  <pre>to:<o:p></o:p></pre>
  <pre>&lt;pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person" email=<a
 moz-do-not-send="true" href="mailto:so...@so...">"so...@so..."</a>&gt;<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Example Context:      <o:p></o:p></pre>
  <pre>&lt;pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=<a
 moz-do-not-send="true"
 href="http://www.psidev.info/not_sure_of_url_to_cv.obo"><b><span
 style="color: red;">MailScanner has detected a possible fraud attempt from "www.psidev.info" claiming to be</span></b> "http://www.psidev.info/not_sure_of_url_to_cv.obo"</a>&gt;&lt;/pf:cv&gt;<o:p></o:p></pre>
  <pre>We only want the cv psidev.info when we finally release. Guess it's OK to leave this as it is at the moment.<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Element &lt;AnalysisSoftware&gt;<o:p></o:p></pre>
  <pre>Definition:   A data set containing spectra data (consisting of one or more spectra). <o:p></o:p></pre>
  <pre>Definition looks like a copy and paste of something quite different!<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Element &lt;pf:ContactRole&gt;<o:p></o:p></pre>
  <pre>Definition:   The Contact that provided the document instance. <o:p></o:p></pre>
  <pre>We use the contact role in several different places. Definition needs to be a bit more general? <o:p></o:p></pre>
  <pre>In the example it is for a software vendor.<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Element &lt;pf:Person&gt;<o:p></o:p></pre>
  <pre>Example needs filling out a bit with some fictitious person.<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Element &lt;Peptide&gt;<o:p></o:p></pre>
  <pre>sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence residues, exclusive of the termini masses in Daltons.<o:p></o:p></pre>
  <pre>  <o:p></o:p></pre>
  <p class="MsoNormal">Oh dear. Some of the examples are inclusive of
the termini
masses and any modifications, others are not. In theory, it's possible
to
calculate the mass given the modification delta and the
CTermGain="OH" NTermGain="H" from the enzyme. However,
that's not trivial in a case of multiple enzymes. I'd suggest we change
the
definition to include the termini and mods. Martin (whose examples
followed the
documentation)  may think differently?<o:p></o:p></p>
  <p class="MsoNormal" style="margin-bottom: 12pt;">I aggree: with
termini and
mods. Calculated neutral mass in Da (not m/z), monoisotopic, 6digits
after
unit?<o:p></o:p></p>
  <p class="MsoNormal"><br>
  <br>
Element &lt;Inputs&gt;<br>
Definition:     The inputs to the analyses including the
databases searched and the spectral data <br>
The example shows the input file to the process that created the
analysisXML
document (the Mascot .dat file)<br>
The global definition needs changing. Also, need to add a definition
for
SpectraData.<br>
  <br>
  <br>
Element &lt;DatabaseTranslation&gt;<br>
Could take examples from Mascot_NA_example.axml<br>
  <br>
  <br>
Element &lt;Enzyme&gt;<br>
missedCleavages    xsd:int   
optional    URI of the analysis software e.g. manufacturer's
website<br>
semiSpecific - shouldn't this be a boolean?<br>
  <br>
  <br>
Element &lt;PlusValue&gt;<br>
unitName    xsd:string    -    The
name of the unit.<br>
Shame that it doesn't pull out the allowed CV from the mapping file:<br>
  <br>
&lt;CvTerm termAccession="UO:0000221" useTermName="false"
useTerm="true" termName="dalton"
cvIdentifierRef="UO" /&gt;<br>
&lt;CvTerm termAccession="UO:0000166" useTermName="false"
useTerm="false" termName="parts per notation"
cvIdentifierRef="UO" /&gt;<br>
  <br>
Element &lt;SpectrumIdentificationItem&gt;<br>
Has an attribute of rank and also a CV item. From the minutes here:<br>
  <a moz-do-not-send="true"
 href="http://psidev.info/index.php?q=node/380">http://psidev.info/index.php?q=node/380</a><br>
Looks as though we agreed it should be an attribute and removed from
the CV<br>
  <br>
Cheers,<br>
David<br>
  <br>
Jones, Andy wrote: <o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi all,</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Eric has
re-generated the schema
documentation for us. This is getting fairly close to a version I can
cut and
paste into the spec doc. Let me know if you have any comments,</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Cheers</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch [<a moz-do-not-send="true"
 href="mailto:ede...@sy...">mailto:ede...@sy...</a>]
  <br>
  <b>Sent:</b> 01 December 2008 09:23<br>
  <b>To:</b> Jones, Andy<br>
  <b>Cc:</b> 'Eric Deutsch'<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  </div>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi Andy, sorry for the delay, US holiday over here. You
will find
updated HTML documentation at:</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html">http://www.peptideatlas.org/tmp/AnalysisXML_working.html</a></span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">A version that is suitable
for cut-n-paste
into a word doc is at:</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html">http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html</a></span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">I fixed some of the problems.
The main
problem I still know about is that in the subelement listing, any
subelements
that are double-tall nested substitution grouped elements do not have
their definition
visible. If one clicks on the subelement, the main element does have a
definition. So it’s there, but my program is stymied by the various
levels.
This is fixable, but probably not before submission.</span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">If you send me screen-capture
images to embed
in some elements, that can be done if you like.</span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">If there are still other
outstanding
issues, please let me know</span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">Regards,</span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US">Eric</span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy [<a moz-do-not-send="true"
 href="mailto:And...@li...">mailto:And...@li...</a>]
  <br>
  <b>Sent:</b> Thursday, November 27, 2008 4:56 AM<br>
  <b>To:</b> Eric Deutsch<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi Eric,</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Any
chance you could look at the
generated documentation this week? We’re aiming to submit the specs to
the
document process by Monday...</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Thanks</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch [<a moz-do-not-send="true"
 href="mailto:ede...@sy...">mailto:ede...@sy...</a>]
  <br>
  <b>Sent:</b> 21 November 2008 17:44<br>
  <b>To:</b> Jones, Andy<br>
  <b>Cc:</b> 'Eric Deutsch'<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  </div>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi Andy, yes, I will fix the bugs and regenerate the docs
from the
latest schema and files early next week.</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">I will also have a look at TPP related materials for
AnalysisXML
and get back to you.</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Sorry I’ve missed the calls. That time is very awkward
for me and
I’ve occasionally been confused by Wednesday/Thursday switches.</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Regards,</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Eric</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy [<a moz-do-not-send="true"
 href="mailto:And...@li...">mailto:And...@li...</a>]
  <br>
  <b>Sent:</b> Friday, November 21, 2008 2:09 AM<br>
  <b>To:</b> Eric Deutsch<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi Eric,</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Would you
be able to do a couple
of updates to the auto-generated docs? There’s a couple of errors to
fix.</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">When
there is an instance of:
&lt;xsd:element ref="pf:DatabaseReference" minOccurs="0"&gt;,
would you be able to retrieve the documentation in the table from the
referenced element.</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Also,
when an element is
inherited from, documentation for inherited attributes does not appear
in the
table (e.g. see Specificity rule, no docs for cvRef, unitName etc.) –
unless we
were missing documentation for these attributes when it was last
generated?.</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">There are
also a few instances
of elements imported from the FuGE-light schema which are completely
empty, no
attributes or documentation e.g. Organization or Person.</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">We’re
aiming to submit the specs
to the PSI process by the end of month (i.e. a week on Monday), so if
you would
be able to look at this fairly soon it would be very much appreciated!
Also,
any chance that you can get someone to generate the TPP and SpectraST
examples
at your end. It’s no disaster if we submit to the process without these
but it
would be beneficial.</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Cheers</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy</span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch [<a moz-do-not-send="true"
 href="mailto:ede...@sy...">mailto:ede...@sy...</a>]
  <br>
  <b>Sent:</b> 17 October 2008 07:43<br>
  <b>To:</b> <a moz-do-not-send="true"
 href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> Re: [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  </div>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi everyone, I updated the current draft of the on-line
autogenerated schema docs to the latest svn. The result is at:</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html">http://www.peptideatlas.org/tmp/AnalysisXML_working.html</a></span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">It
looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml
file the
mapping information for SearchType and it seemed to pull it out of the
CV
nicely:</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType">http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType</a></span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">The
autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to
automatically
pull examples out of?</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">Regards,</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">Eric</span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"> </span><o:p></o:p></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy [<a moz-do-not-send="true"
 href="mailto:And...@li...">mailto:And...@li...</a>]
  <br>
  <b>Sent:</b> Monday, October 13, 2008 7:07 AM<br>
  <b>To:</b> <a moz-do-not-send="true"
 href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> [Psidev-pi-dev] Spec doc</span><o:p></o:p></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
  <p class="MsoNormal">Hi all,<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal">A new version of the spec document has been
uploaded by SVN
(in the specification_document directory), and previous versions have
been put
in a subfolder. I think the document is getting there... <o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal">Main tasks still to do:<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">Finish
section on use
cases when we have finally agreed the list online and made all the
example
files.<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">Import some
parts of the
example files to demonstrate a few specific points<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">Import the
autogenerated
documentation<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal">Before we can submit, the main outstanding
issues are:<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">CV - looking
through the
CV there is still a fair bit of work to do, there’s quite a few terms
with
missing or incorrect documentation<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">Mapping file<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;">Finish
example files.<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal">Prior to the call on Thurs, can we have a think
about how we
plan to get the CV into shape and discuss it as a main agenda item...<o:p></o:p></p>
  <p class="MsoNormal"> <o:p></o:p></p>
  <p class="MsoNormal">Also new schema uploaded with a few bits of
improved
documentation.<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" style="margin-left: 18pt;"> <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>
  </div>
  </div>
  </div>
  </div>
  </div>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;">
<hr align="center" size="4" width="90%">

  </pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>-------------------------------------------------------------------------<o:p></o:p></pre>
  <pre>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<o:p></o:p></pre>
  <pre>Build the coolest Linux based applications with Moblin SDK &amp; win great prizes<o:p></o:p></pre>
  <pre>Grand prize is a trip for two to an Open Source event anywhere in the world<o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a><o:p></o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;">
<hr align="center" size="4" width="90%">

  </pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>_______________________________________________<o:p></o:p></pre>
  <pre>Psidev-pi-dev mailing list<o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="mailto:Psi...@li...">Psi...@li...</a><o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev</a><o:p></o:p></pre>
  <pre>  <o:p></o:p></pre>
  <p class="MsoNormal" style="margin-bottom: 12pt;"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"><o:p> </o:p></span></p>
  <pre>-- <o:p></o:p></pre>
  <pre>David Creasy<o:p></o:p></pre>
  <pre>Matrix Science<o:p></o:p></pre>
  <pre>64 Baker Street<o:p></o:p></pre>
  <pre>London W1U 7GB, UK<o:p></o:p></pre>
  <pre>Tel: +44 (0)20 7486 1050<o:p></o:p></pre>
  <pre>Fax: +44 (0)20 7224 1344<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre><a moz-do-not-send="true" href="mailto:dc...@ma...">dc...@ma...</a><o:p></o:p></pre>
  <pre><a moz-do-not-send="true" href="http://www.matrixscience.com">http://www.matrixscience.com</a><o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>Matrix Science Ltd. is registered in England and Wales<o:p></o:p></pre>
  <pre>Company number 3533898<o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;">
<hr align="center" size="4" width="90%">

  </pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>-------------------------------------------------------------------------<o:p></o:p></pre>
  <pre>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<o:p></o:p></pre>
  <pre>Build the coolest Linux based applications with Moblin SDK &amp; win great prizes<o:p></o:p></pre>
  <pre>Grand prize is a trip for two to an Open Source event anywhere in the world<o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a><o:p></o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;">
<hr align="center" size="4" width="90%">

  </pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre style="text-align: center;"><o:p> </o:p></pre>
  <pre><o:p> </o:p></pre>
  <pre>_______________________________________________<o:p></o:p></pre>
  <pre>Psidev-pi-dev mailing list<o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="mailto:Psi...@li...">Psi...@li...</a><o:p></o:p></pre>
  <pre><a moz-do-not-send="true"
 href="https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev">https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev</a><o:p></o:p></pre>
  <pre>  <o:p></o:p></pre>
  </div>
  </div>
  </div>
  <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 &amp; 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&amp;url=/</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>

Re: [Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi all,

 

Jenny has pointed out that the images are missing from the uploaded version,
they seem to be hyperlinked to images stored locally on my machine (which
happened during the conversion from html to word). If anyone knows how to get
around this problem (without manually inserting each image), let me know. 

Cheers

Andy

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 03 December 2008 10:13
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi all,

 

I’ve uploaded a new version of the spec doc, in which I’ve inserted the
auto-generated documentation. There’s still a few things to fix with this (the
schema updates from yesterday have not been incorporated yet) but at this stage
it would be really useful if everyone could take a look and provide feedback
(http://code.google.com/p/psi-pi/source/browse/#svn/trunk/specification_document
).

 

Main questions:

 

-          Are we generally happy with this format?

-          Are there any major omissions?

 

I think we all agree that we want to the this submitted ASAP to the PSI document
process, so if you could get feedback to me this week it would be much
appreciated,

Cheers

Andy

 

 

 

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 02 December 2008 17:36
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi all,

 

New schema uploaded:

 

Various documentation changes, as discussed below.

 

PlusValue / MinusValue now encoded as CVParams

 

Made a change to AnalysisProtocolCollection and AnalysisCollection that
prevented GenericProtocol and GenericProtocolApplication being used – I’ve been
meaning to fix this for a while. It also means the files are now restricted to
containing at most one ProteinDetection and one ProteinDetectionApplication.

 

In the schema, we have some fairly pointless abstract classes AnalysisProtocol
and AnalysisProtocolApplication. They were put in the schema at one stage to
demonstrate how the format should be extended in the future, following this
design pattern (or something like this...). I vote we get rid of them, and write
in the spec document about future extension strategies.

 

Cheers

Andy

 

 

 

 

 

 

 

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 02 December 2008 12:23
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi David,

 

The changes relating the instance docs are coming from the Mascot MS/MS example
so these are for you to fix ;-)

 

Eric, are you able to import certain parts of the instance docs from other
examples. Element <DatabaseTranslation> could take examples from
Mascot_NA_example.axml? 

 

I’ll make the other recommended changes to the XSD documentation (some of these
require a fix to the generating script, which I’ve flagged to Eric separately).

 

Martin, are you happy for us to make the change relating to peptide mass
documentation (see below).

 

>semiSpecific - shouldn't this be a boolean?

 

Agreed, I’ll make this change.

 

><PlusValue>

 

Eric is right to query this part of the schema. In fact, we’ve used the
PropertyValue element only for PlusValue and MinusValue in the entire schema.
Let’s make these CV terms:

 

<pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5”
cvRef="PSI-PI"

unitAccession="UO:0000221" name="dalton" cvRef="UO" />

 

Andreas can you add: “search tolerance plus value” and “search tolerance minus
value” to the CV and mapping file and I’ll change the schema, does this seem
reasonable to everyone…?

 

Getting there…

 

Cheers

Andy

 

 

 

 

From: Pierre-Alain Binz [mailto:pie...@is...] 
Sent: 02 December 2008 11:17
To: David Creasy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi,

David Creasy wrote: 

Hi Andy,

Some minor changes:

From:
<pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person"
email="so...@so..." <mailto:so...@so...> >
to:
<pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person"
email="so...@so..." <mailto:so...@so...> >
 
 
Example Context:      
<pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=MailScanner has detected
a possible fraud attempt from "www.psidev.info" claiming to be
"http://www.psidev.info/not_sure_of_url_to_cv.obo"
<http://www.psidev.info/not_sure_of_url_to_cv.obo> ></pf:cv>
We only want the cv psidev.info when we finally release. Guess it's OK to leave
this as it is at the moment.
 
 
Element <AnalysisSoftware>
Definition:   A data set containing spectra data (consisting of one or more
spectra). 
Definition looks like a copy and paste of something quite different!
 
 
Element <pf:ContactRole>
Definition:   The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be a
bit more general? 
In the example it is for a software vendor.
 
 
 
Element <pf:Person>
Example needs filling out a bit with some fictitious person.
 
 
Element <Peptide>
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence
residues, exclusive of the termini masses in Daltons.
  

Oh dear. Some of the examples are inclusive of the termini masses and any
modifications, others are not. In theory, it's possible to calculate the mass
given the modification delta and the CTermGain="OH" NTermGain="H" from the
enzyme. However, that's not trivial in a case of multiple enzymes. I'd suggest
we change the definition to include the termini and mods. Martin (whose examples
followed the documentation)  may think differently?

I aggree: with termini and mods. Calculated neutral mass in Da (not m/z),
monoisotopic, 6digits after unit?



Element <Inputs>
Definition:     The inputs to the analyses including the databases searched and
the spectral data 
The example shows the input file to the process that created the analysisXML
document (the Mascot .dat file)
The global definition needs changing. Also, need to add a definition for
SpectraData.


Element <DatabaseTranslation>
Could take examples from Mascot_NA_example.axml


Element <Enzyme>
missedCleavages    xsd:int    optional    URI of the analysis software e.g.
manufacturer's website
semiSpecific - shouldn't this be a boolean?


Element <PlusValue>
unitName    xsd:string    -    The name of the unit.
Shame that it doesn't pull out the allowed CV from the mapping file:

<CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true"
termName="dalton" cvIdentifierRef="UO" />
<CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false"
termName="parts per notation" cvIdentifierRef="UO" />

Element <SpectrumIdentificationItem>
Has an attribute of rank and also a CV item. From the minutes here:
http://psidev.info/index.php?q=node/380
Looks as though we agreed it should be an attribute and removed from the CV

Cheers,
David

Jones, Andy wrote: 

Hi all,

Eric has re-generated the schema documentation for us. This is getting fairly
close to a version I can cut and paste into the spec doc. Let me know if you
have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated HTML
documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in the
subelement listing, any subelements that are double-tall nested substitution
grouped elements do not have their definition visible. If one clicks on the
subelement, the main element does have a definition. So it’s there, but my
program is stymied by the various levels. This is fixable, but probably not
before submission.

 

If you send me screen-capture images to embed in some elements, that can be done
if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We’re aiming
to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest schema
and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get back to
you.

 

Sorry I’ve missed the calls. That time is very awkward for me and I’ve
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs? There’s
a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited attributes
does not appear in the table (e.g. see Specificity rule, no docs for cvRef,
unitName etc.) – unless we were missing documentation for these attributes when
it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light schema
which are completely empty, no attributes or documentation e.g. Organization or
Person.

 

We’re aiming to submit the specs to the PSI process by the end of month (i.e. a
week on Monday), so if you would be able to look at this fairly soon it would be
very much appreciated! Also, any chance that you can get someone to generate the
TPP and SpectraST examples at your end. It’s no disaster if we submit to the
process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file the
mapping information for SearchType and it seemed to pull it out of the CV
nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to automatically
pull examples out of?

 

Regards,

Eric

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

Finish section on use cases when we have finally agreed the list online and made
all the example files.

Import some parts of the example files to demonstrate a few specific points

Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

CV - looking through the CV there is still a fair bit of work to do, there’s
quite a few terms with missing or incorrect documentation

Mapping file

Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the CV
into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 
 
 
 
 
 
 


________________________________



 
 
 
 
 
 
 
 
 
-------------------------------------------------------------------------
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-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
 
 
 
 
 
 
 
 
 


________________________________



 
 
 
 
 
 
 
 
 
-------------------------------------------------------------------------
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-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
  

Re: [Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi all,

 

I’ve uploaded a new version of the spec doc, in which I’ve inserted the
auto-generated documentation. There’s still a few things to fix with this (the
schema updates from yesterday have not been incorporated yet) but at this stage
it would be really useful if everyone could take a look and provide feedback
(http://code.google.com/p/psi-pi/source/browse/#svn/trunk/specification_document
).

 

Main questions:

 

-          Are we generally happy with this format?

-          Are there any major omissions?

 

I think we all agree that we want to the this submitted ASAP to the PSI document
process, so if you could get feedback to me this week it would be much
appreciated,

Cheers

Andy

 

 

 

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 02 December 2008 17:36
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi all,

 

New schema uploaded:

 

Various documentation changes, as discussed below.

 

PlusValue / MinusValue now encoded as CVParams

 

Made a change to AnalysisProtocolCollection and AnalysisCollection that
prevented GenericProtocol and GenericProtocolApplication being used – I’ve been
meaning to fix this for a while. It also means the files are now restricted to
containing at most one ProteinDetection and one ProteinDetectionApplication.

 

In the schema, we have some fairly pointless abstract classes AnalysisProtocol
and AnalysisProtocolApplication. They were put in the schema at one stage to
demonstrate how the format should be extended in the future, following this
design pattern (or something like this...). I vote we get rid of them, and write
in the spec document about future extension strategies.

 

Cheers

Andy

 

 

 

 

 

 

 

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 02 December 2008 12:23
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi David,

 

The changes relating the instance docs are coming from the Mascot MS/MS example
so these are for you to fix ;-)

 

Eric, are you able to import certain parts of the instance docs from other
examples. Element <DatabaseTranslation> could take examples from
Mascot_NA_example.axml? 

 

I’ll make the other recommended changes to the XSD documentation (some of these
require a fix to the generating script, which I’ve flagged to Eric separately).

 

Martin, are you happy for us to make the change relating to peptide mass
documentation (see below).

 

>semiSpecific - shouldn't this be a boolean?

 

Agreed, I’ll make this change.

 

><PlusValue>

 

Eric is right to query this part of the schema. In fact, we’ve used the
PropertyValue element only for PlusValue and MinusValue in the entire schema.
Let’s make these CV terms:

 

<pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5”
cvRef="PSI-PI"

unitAccession="UO:0000221" name="dalton" cvRef="UO" />

 

Andreas can you add: “search tolerance plus value” and “search tolerance minus
value” to the CV and mapping file and I’ll change the schema, does this seem
reasonable to everyone…?

 

Getting there…

 

Cheers

Andy

 

 

 

 

From: Pierre-Alain Binz [mailto:pie...@is...] 
Sent: 02 December 2008 11:17
To: David Creasy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi,

David Creasy wrote: 

Hi Andy,

Some minor changes:

From:
<pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person"
email="so...@so..." <mailto:so...@so...> >
to:
<pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person"
email="so...@so..." <mailto:so...@so...> >
 
 
Example Context:      
<pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=MailScanner has detected
a possible fraud attempt from "www.psidev.info" claiming to be
"http://www.psidev.info/not_sure_of_url_to_cv.obo"
<http://www.psidev.info/not_sure_of_url_to_cv.obo> ></pf:cv>
We only want the cv psidev.info when we finally release. Guess it's OK to leave
this as it is at the moment.
 
 
Element <AnalysisSoftware>
Definition:   A data set containing spectra data (consisting of one or more
spectra). 
Definition looks like a copy and paste of something quite different!
 
 
Element <pf:ContactRole>
Definition:   The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be a
bit more general? 
In the example it is for a software vendor.
 
 
 
Element <pf:Person>
Example needs filling out a bit with some fictitious person.
 
 
Element <Peptide>
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence
residues, exclusive of the termini masses in Daltons.
  

Oh dear. Some of the examples are inclusive of the termini masses and any
modifications, others are not. In theory, it's possible to calculate the mass
given the modification delta and the CTermGain="OH" NTermGain="H" from the
enzyme. However, that's not trivial in a case of multiple enzymes. I'd suggest
we change the definition to include the termini and mods. Martin (whose examples
followed the documentation)  may think differently?

I aggree: with termini and mods. Calculated neutral mass in Da (not m/z),
monoisotopic, 6digits after unit?



Element <Inputs>
Definition:     The inputs to the analyses including the databases searched and
the spectral data 
The example shows the input file to the process that created the analysisXML
document (the Mascot .dat file)
The global definition needs changing. Also, need to add a definition for
SpectraData.


Element <DatabaseTranslation>
Could take examples from Mascot_NA_example.axml


Element <Enzyme>
missedCleavages    xsd:int    optional    URI of the analysis software e.g.
manufacturer's website
semiSpecific - shouldn't this be a boolean?


Element <PlusValue>
unitName    xsd:string    -    The name of the unit.
Shame that it doesn't pull out the allowed CV from the mapping file:

<CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true"
termName="dalton" cvIdentifierRef="UO" />
<CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false"
termName="parts per notation" cvIdentifierRef="UO" />

Element <SpectrumIdentificationItem>
Has an attribute of rank and also a CV item. From the minutes here:
http://psidev.info/index.php?q=node/380
Looks as though we agreed it should be an attribute and removed from the CV

Cheers,
David

Jones, Andy wrote: 

Hi all,

Eric has re-generated the schema documentation for us. This is getting fairly
close to a version I can cut and paste into the spec doc. Let me know if you
have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated HTML
documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in the
subelement listing, any subelements that are double-tall nested substitution
grouped elements do not have their definition visible. If one clicks on the
subelement, the main element does have a definition. So it’s there, but my
program is stymied by the various levels. This is fixable, but probably not
before submission.

 

If you send me screen-capture images to embed in some elements, that can be done
if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We’re aiming
to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest schema
and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get back to
you.

 

Sorry I’ve missed the calls. That time is very awkward for me and I’ve
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs? There’s
a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited attributes
does not appear in the table (e.g. see Specificity rule, no docs for cvRef,
unitName etc.) – unless we were missing documentation for these attributes when
it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light schema
which are completely empty, no attributes or documentation e.g. Organization or
Person.

 

We’re aiming to submit the specs to the PSI process by the end of month (i.e. a
week on Monday), so if you would be able to look at this fairly soon it would be
very much appreciated! Also, any chance that you can get someone to generate the
TPP and SpectraST examples at your end. It’s no disaster if we submit to the
process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file the
mapping information for SearchType and it seemed to pull it out of the CV
nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to automatically
pull examples out of?

 

Regards,

Eric

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

Finish section on use cases when we have finally agreed the list online and made
all the example files.

Import some parts of the example files to demonstrate a few specific points

Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

CV - looking through the CV there is still a fair bit of work to do, there’s
quite a few terms with missing or incorrect documentation

Mapping file

Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the CV
into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 
 
 
 
 


________________________________



 
 
 
 
 
 
 
-------------------------------------------------------------------------
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-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
 
 
 
 
 
 
 


________________________________



 
 
 
 
 
 
 
-------------------------------------------------------------------------
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-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
  

Re: [Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi all,

 

New schema uploaded:

 

Various documentation changes, as discussed below.

 

PlusValue / MinusValue now encoded as CVParams

 

Made a change to AnalysisProtocolCollection and AnalysisCollection that
prevented GenericProtocol and GenericProtocolApplication being used – I’ve been
meaning to fix this for a while. It also means the files are now restricted to
containing at most one ProteinDetection and one ProteinDetectionApplication.

 

In the schema, we have some fairly pointless abstract classes AnalysisProtocol
and AnalysisProtocolApplication. They were put in the schema at one stage to
demonstrate how the format should be extended in the future, following this
design pattern (or something like this...). I vote we get rid of them, and write
in the spec document about future extension strategies.

 

Cheers

Andy

 

 

 

 

 

 

 

 

From: Jones, Andy [mailto:And...@li...] 
Sent: 02 December 2008 12:23
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi David,

 

The changes relating the instance docs are coming from the Mascot MS/MS example
so these are for you to fix ;-)

 

Eric, are you able to import certain parts of the instance docs from other
examples. Element <DatabaseTranslation> could take examples from
Mascot_NA_example.axml? 

 

I’ll make the other recommended changes to the XSD documentation (some of these
require a fix to the generating script, which I’ve flagged to Eric separately).

 

Martin, are you happy for us to make the change relating to peptide mass
documentation (see below).

 

>semiSpecific - shouldn't this be a boolean?

 

Agreed, I’ll make this change.

 

><PlusValue>

 

Eric is right to query this part of the schema. In fact, we’ve used the
PropertyValue element only for PlusValue and MinusValue in the entire schema.
Let’s make these CV terms:

 

<pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5”
cvRef="PSI-PI"

unitAccession="UO:0000221" name="dalton" cvRef="UO" />

 

Andreas can you add: “search tolerance plus value” and “search tolerance minus
value” to the CV and mapping file and I’ll change the schema, does this seem
reasonable to everyone…?

 

Getting there…

 

Cheers

Andy

 

 

 

 

From: Pierre-Alain Binz [mailto:pie...@is...] 
Sent: 02 December 2008 11:17
To: David Creasy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi,

David Creasy wrote: 

Hi Andy,

Some minor changes:

From:
<pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person"
email="so...@so..." <mailto:so...@so...> >
to:
<pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person"
email="so...@so..." <mailto:so...@so...> >
 
 
Example Context:      
<pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=MailScanner has detected
a possible fraud attempt from "www.psidev.info" claiming to be
"http://www.psidev.info/not_sure_of_url_to_cv.obo"
<http://www.psidev.info/not_sure_of_url_to_cv.obo> ></pf:cv>
We only want the cv psidev.info when we finally release. Guess it's OK to leave
this as it is at the moment.
 
 
Element <AnalysisSoftware>
Definition:   A data set containing spectra data (consisting of one or more
spectra). 
Definition looks like a copy and paste of something quite different!
 
 
Element <pf:ContactRole>
Definition:   The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be a
bit more general? 
In the example it is for a software vendor.
 
 
 
Element <pf:Person>
Example needs filling out a bit with some fictitious person.
 
 
Element <Peptide>
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence
residues, exclusive of the termini masses in Daltons.
  

Oh dear. Some of the examples are inclusive of the termini masses and any
modifications, others are not. In theory, it's possible to calculate the mass
given the modification delta and the CTermGain="OH" NTermGain="H" from the
enzyme. However, that's not trivial in a case of multiple enzymes. I'd suggest
we change the definition to include the termini and mods. Martin (whose examples
followed the documentation)  may think differently?

I aggree: with termini and mods. Calculated neutral mass in Da (not m/z),
monoisotopic, 6digits after unit?



Element <Inputs>
Definition:     The inputs to the analyses including the databases searched and
the spectral data 
The example shows the input file to the process that created the analysisXML
document (the Mascot .dat file)
The global definition needs changing. Also, need to add a definition for
SpectraData.


Element <DatabaseTranslation>
Could take examples from Mascot_NA_example.axml


Element <Enzyme>
missedCleavages    xsd:int    optional    URI of the analysis software e.g.
manufacturer's website
semiSpecific - shouldn't this be a boolean?


Element <PlusValue>
unitName    xsd:string    -    The name of the unit.
Shame that it doesn't pull out the allowed CV from the mapping file:

<CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true"
termName="dalton" cvIdentifierRef="UO" />
<CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false"
termName="parts per notation" cvIdentifierRef="UO" />

Element <SpectrumIdentificationItem>
Has an attribute of rank and also a CV item. From the minutes here:
http://psidev.info/index.php?q=node/380
Looks as though we agreed it should be an attribute and removed from the CV

Cheers,
David

Jones, Andy wrote: 

Hi all,

Eric has re-generated the schema documentation for us. This is getting fairly
close to a version I can cut and paste into the spec doc. Let me know if you
have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated HTML
documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in the
subelement listing, any subelements that are double-tall nested substitution
grouped elements do not have their definition visible. If one clicks on the
subelement, the main element does have a definition. So it’s there, but my
program is stymied by the various levels. This is fixable, but probably not
before submission.

 

If you send me screen-capture images to embed in some elements, that can be done
if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We’re aiming
to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest schema
and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get back to
you.

 

Sorry I’ve missed the calls. That time is very awkward for me and I’ve
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs? There’s
a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited attributes
does not appear in the table (e.g. see Specificity rule, no docs for cvRef,
unitName etc.) – unless we were missing documentation for these attributes when
it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light schema
which are completely empty, no attributes or documentation e.g. Organization or
Person.

 

We’re aiming to submit the specs to the PSI process by the end of month (i.e. a
week on Monday), so if you would be able to look at this fairly soon it would be
very much appreciated! Also, any chance that you can get someone to generate the
TPP and SpectraST examples at your end. It’s no disaster if we submit to the
process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file the
mapping information for SearchType and it seemed to pull it out of the CV
nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to automatically
pull examples out of?

 

Regards,

Eric

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

Finish section on use cases when we have finally agreed the list online and made
all the example files.

Import some parts of the example files to demonstrate a few specific points

Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

CV - looking through the CV there is still a fair bit of work to do, there’s
quite a few terms with missing or incorrect documentation

Mapping file

Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the CV
into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 
 
 


________________________________



 
 
 
 
 
-------------------------------------------------------------------------
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-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
 
 
 
 
 


________________________________



 
 
 
 
 
-------------------------------------------------------------------------
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-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
  

Re: [Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi David,

 

The changes relating the instance docs are coming from the Mascot MS/MS example
so these are for you to fix ;-)

 

Eric, are you able to import certain parts of the instance docs from other
examples. Element <DatabaseTranslation> could take examples from
Mascot_NA_example.axml? 

 

I’ll make the other recommended changes to the XSD documentation (some of these
require a fix to the generating script, which I’ve flagged to Eric separately).

 

Martin, are you happy for us to make the change relating to peptide mass
documentation (see below).

 

>semiSpecific - shouldn't this be a boolean?

 

Agreed, I’ll make this change.

 

><PlusValue>

 

Eric is right to query this part of the schema. In fact, we’ve used the
PropertyValue element only for PlusValue and MinusValue in the entire schema.
Let’s make these CV terms:

 

<pf:cvParam accession="PI:00999" name="search tolerance plus value" value=”0.5”
cvRef="PSI-PI"

unitAccession="UO:0000221" name="dalton" cvRef="UO" />

 

Andreas can you add: “search tolerance plus value” and “search tolerance minus
value” to the CV and mapping file and I’ll change the schema, does this seem
reasonable to everyone…?

 

Getting there…

 

Cheers

Andy

 

 

 

 

From: Pierre-Alain Binz [mailto:pie...@is...] 
Sent: 02 December 2008 11:17
To: David Creasy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi,

David Creasy wrote: 

Hi Andy,

Some minor changes:

From:
<pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person"
email="so...@so..." <mailto:so...@so...> >
to:
<pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person"
email="so...@so..." <mailto:so...@so...> >
 
 
Example Context:      
<pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=MailScanner has detected
a possible fraud attempt from "www.psidev.info" claiming to be
"http://www.psidev.info/not_sure_of_url_to_cv.obo"
<http://www.psidev.info/not_sure_of_url_to_cv.obo> ></pf:cv>
We only want the cv psidev.info when we finally release. Guess it's OK to leave
this as it is at the moment.
 
 
Element <AnalysisSoftware>
Definition:   A data set containing spectra data (consisting of one or more
spectra). 
Definition looks like a copy and paste of something quite different!
 
 
Element <pf:ContactRole>
Definition:   The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be a
bit more general? 
In the example it is for a software vendor.
 
 
 
Element <pf:Person>
Example needs filling out a bit with some fictitious person.
 
 
Element <Peptide>
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence
residues, exclusive of the termini masses in Daltons.
  

Oh dear. Some of the examples are inclusive of the termini masses and any
modifications, others are not. In theory, it's possible to calculate the mass
given the modification delta and the CTermGain="OH" NTermGain="H" from the
enzyme. However, that's not trivial in a case of multiple enzymes. I'd suggest
we change the definition to include the termini and mods. Martin (whose examples
followed the documentation)  may think differently?

I aggree: with termini and mods. Calculated neutral mass in Da (not m/z),
monoisotopic, 6digits after unit?





Element <Inputs>
Definition:     The inputs to the analyses including the databases searched and
the spectral data 
The example shows the input file to the process that created the analysisXML
document (the Mascot .dat file)
The global definition needs changing. Also, need to add a definition for
SpectraData.


Element <DatabaseTranslation>
Could take examples from Mascot_NA_example.axml


Element <Enzyme>
missedCleavages    xsd:int    optional    URI of the analysis software e.g.
manufacturer's website
semiSpecific - shouldn't this be a boolean?


Element <PlusValue>
unitName    xsd:string    -    The name of the unit.
Shame that it doesn't pull out the allowed CV from the mapping file:

<CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true"
termName="dalton" cvIdentifierRef="UO" />
<CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false"
termName="parts per notation" cvIdentifierRef="UO" />

Element <SpectrumIdentificationItem>
Has an attribute of rank and also a CV item. From the minutes here:
http://psidev.info/index.php?q=node/380
Looks as though we agreed it should be an attribute and removed from the CV

Cheers,
David

Jones, Andy wrote: 

Hi all,

Eric has re-generated the schema documentation for us. This is getting fairly
close to a version I can cut and paste into the spec doc. Let me know if you
have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated HTML
documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in the
subelement listing, any subelements that are double-tall nested substitution
grouped elements do not have their definition visible. If one clicks on the
subelement, the main element does have a definition. So it’s there, but my
program is stymied by the various levels. This is fixable, but probably not
before submission.

 

If you send me screen-capture images to embed in some elements, that can be done
if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We’re aiming
to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest schema
and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get back to
you.

 

Sorry I’ve missed the calls. That time is very awkward for me and I’ve
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs? There’s
a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited attributes
does not appear in the table (e.g. see Specificity rule, no docs for cvRef,
unitName etc.) – unless we were missing documentation for these attributes when
it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light schema
which are completely empty, no attributes or documentation e.g. Organization or
Person.

 

We’re aiming to submit the specs to the PSI process by the end of month (i.e. a
week on Monday), so if you would be able to look at this fairly soon it would be
very much appreciated! Also, any chance that you can get someone to generate the
TPP and SpectraST examples at your end. It’s no disaster if we submit to the
process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file the
mapping information for SearchType and it seemed to pull it out of the CV
nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to automatically
pull examples out of?

 

Regards,

Eric

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

Finish section on use cases when we have finally agreed the list online and made
all the example files.

Import some parts of the example files to demonstrate a few specific points

Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

CV - looking through the CV there is still a fair bit of work to do, there’s
quite a few terms with missing or incorrect documentation

Mapping file

Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the CV
into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 


________________________________



 
 
 
-------------------------------------------------------------------------
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-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
 
 
 


________________________________



 
 
 
-------------------------------------------------------------------------
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-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
  

Re: [Psidev-pi-dev] FW: Spec doc

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

Hi,

David Creasy wrote:
> Hi Andy,
>
> Some minor changes:
> From:
> <pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person" email="so...@so...">
> to:
> <pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person" email="so...@so...">
>
>
> Example Context: 	
> <pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=*MailScanner has detected a possible fraud attempt from "www.psidev.info" claiming to be* "http://www.psidev.info/not_sure_of_url_to_cv.obo"></pf:cv>
> We only want the cv psidev.info when we finally release. Guess it's OK to leave this as it is at the moment.
>
>
> Element <AnalysisSoftware>
> Definition: 	A data set containing spectra data (consisting of one or more spectra). 
> Definition looks like a copy and paste of something quite different!
>
>
> Element <pf:ContactRole>
> Definition: 	The Contact that provided the document instance. 
> We use the contact role in several different places. Definition needs to be a bit more general? 
> In the example it is for a software vendor.
>
>
>
> Element <pf:Person>
> Example needs filling out a bit with some fictitious person.
>
>
> Element <Peptide>
> sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence residues, exclusive of the termini masses in Daltons.
>   
> Oh dear. Some of the examples are inclusive of the termini masses and 
> any modifications, others are not. In theory, it's possible to 
> calculate the mass given the modification delta and the CTermGain="OH" 
> NTermGain="H" from the enzyme. However, that's not trivial in a case 
> of multiple enzymes. I'd suggest we change the definition to include 
> the termini and mods. Martin (whose examples followed the 
> documentation)  may think differently?
I aggree: with termini and mods. Calculated neutral mass in Da (not 
m/z), monoisotopic, 6digits after unit?
>
>
> Element <Inputs>
> Definition:     The inputs to the analyses including the databases 
> searched and the spectral data
> The example shows the input file to the process that created the 
> analysisXML document (the Mascot .dat file)
> The global definition needs changing. Also, need to add a definition 
> for SpectraData.
>
>
> Element <DatabaseTranslation>
> Could take examples from Mascot_NA_example.axml
>
>
> Element <Enzyme>
> missedCleavages    xsd:int    optional    URI of the analysis software 
> e.g. manufacturer's website
> semiSpecific - shouldn't this be a boolean?
>
>
> Element <PlusValue>
> unitName    xsd:string    -    The name of the unit.
> Shame that it doesn't pull out the allowed CV from the mapping file:
>
> <CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true" 
> termName="dalton" cvIdentifierRef="UO" />
> <CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false" 
> termName="parts per notation" cvIdentifierRef="UO" />
>
> Element <SpectrumIdentificationItem>
> Has an attribute of rank and also a CV item. From the minutes here:
> http://psidev.info/index.php?q=node/380
> Looks as though we agreed it should be an attribute and removed from 
> the CV
>
> Cheers,
> David
>
> Jones, Andy wrote:
>>
>> Hi all,
>>
>> Eric has re-generated the schema documentation for us. This is 
>> getting fairly close to a version I can cut and paste into the spec 
>> doc. Let me know if you have any comments,
>>
>> Cheers
>>
>> Andy
>>
>>  
>>
>>  
>>
>> *From:* Eric Deutsch [mailto:ede...@sy...]
>> *Sent:* 01 December 2008 09:23
>> *To:* Jones, Andy
>> *Cc:* 'Eric Deutsch'
>> *Subject:* RE: [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi Andy, sorry for the delay, US holiday over here. You will find 
>> updated HTML documentation at:
>>
>>  
>>
>> http://www.peptideatlas.org/tmp/AnalysisXML_working.html
>>
>>  
>>
>> A version that is suitable for cut-n-paste into a word doc is at:
>>
>>  
>>
>> http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html
>>
>>  
>>
>> I fixed some of the problems. The main problem I still know about is 
>> that in the subelement listing, any subelements that are double-tall 
>> nested substitution grouped elements do not have their definition 
>> visible. If one clicks on the subelement, the main element does have 
>> a definition. So it’s there, but my program is stymied by the various 
>> levels. This is fixable, but probably not before submission.
>>
>>  
>>
>> If you send me screen-capture images to embed in some elements, that 
>> can be done if you like.
>>
>>  
>>
>> If there are still other outstanding issues, please let me know
>>
>>  
>>
>> Regards,
>>
>> Eric
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Jones, Andy [mailto:And...@li...]
>> *Sent:* Thursday, November 27, 2008 4:56 AM
>> *To:* Eric Deutsch
>> *Subject:* RE: [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi Eric,
>>
>>  
>>
>> Any chance you could look at the generated documentation this week? 
>> We’re aiming to submit the specs to the document process by Monday...
>>
>> Thanks
>>
>> Andy
>>
>>  
>>
>> *From:* Eric Deutsch [mailto:ede...@sy...]
>> *Sent:* 21 November 2008 17:44
>> *To:* Jones, Andy
>> *Cc:* 'Eric Deutsch'
>> *Subject:* RE: [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi Andy, yes, I will fix the bugs and regenerate the docs from the 
>> latest schema and files early next week.
>>
>>  
>>
>> I will also have a look at TPP related materials for AnalysisXML and 
>> get back to you.
>>
>>  
>>
>> Sorry I’ve missed the calls. That time is very awkward for me and 
>> I’ve occasionally been confused by Wednesday/Thursday switches.
>>
>>  
>>
>> Regards,
>>
>> Eric
>>
>>  
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Jones, Andy [mailto:And...@li...]
>> *Sent:* Friday, November 21, 2008 2:09 AM
>> *To:* Eric Deutsch
>> *Subject:* RE: [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi Eric,
>>
>>  
>>
>> Would you be able to do a couple of updates to the auto-generated 
>> docs? There’s a couple of errors to fix.
>>
>>  
>>
>> When there is an instance of: <xsd:element ref="pf:DatabaseReference" 
>> minOccurs="0">, would you be able to retrieve the documentation in 
>> the table from the referenced element.
>>
>>  
>>
>> Also, when an element is inherited from, documentation for inherited 
>> attributes does not appear in the table (e.g. see Specificity rule, 
>> no docs for cvRef, unitName etc.) – unless we were missing 
>> documentation for these attributes when it was last generated?.
>>
>>  
>>
>> There are also a few instances of elements imported from the 
>> FuGE-light schema which are completely empty, no attributes or 
>> documentation e.g. Organization or Person.
>>
>>  
>>
>> We’re aiming to submit the specs to the PSI process by the end of 
>> month (i.e. a week on Monday), so if you would be able to look at 
>> this fairly soon it would be very much appreciated! Also, any chance 
>> that you can get someone to generate the TPP and SpectraST examples 
>> at your end. It’s no disaster if we submit to the process without 
>> these but it would be beneficial.
>>
>>  
>>
>> Cheers
>>
>> Andy
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> *From:* Eric Deutsch [mailto:ede...@sy...]
>> *Sent:* 17 October 2008 07:43
>> *To:* psi...@li...
>> *Subject:* Re: [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi everyone, I updated the current draft of the on-line autogenerated 
>> schema docs to the latest svn. The result is at:
>>
>>  
>>
>> http://www.peptideatlas.org/tmp/AnalysisXML_working.html
>>
>>  
>>
>> It looks like the current mapping file is just a template without any 
>> term mappings themselves. Just as a test, I wrote into the 
>> axml-mapping.xml file the mapping information for SearchType and it 
>> seemed to pull it out of the CV nicely:
>>
>>  
>>
>> http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType
>>
>>  
>>
>> The autogeneration pulls examples out of one file. I randomly chose 
>> Mascot_MSMS_example.axml. Is there a better instance document to 
>> automatically pull examples out of?
>>
>>  
>>
>> Regards,
>>
>> Eric
>>
>>  
>>
>>  
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Jones, Andy [mailto:And...@li...]
>> *Sent:* Monday, October 13, 2008 7:07 AM
>> *To:* psi...@li...
>> *Subject:* [Psidev-pi-dev] Spec doc
>>
>>  
>>
>> Hi all,
>>
>>  
>>
>> A new version of the spec document has been uploaded by SVN (in the 
>> specification_document directory), and previous versions have been 
>> put in a subfolder. I think the document is getting there...
>>
>>  
>>
>> Main tasks still to do:
>>
>>  
>>
>> -          Finish section on use cases when we have finally agreed 
>> the list online and made all the example files.
>>
>> -          Import some parts of the example files to demonstrate a 
>> few specific points
>>
>> -          Import the autogenerated documentation
>>
>>  
>>
>> Before we can submit, the main outstanding issues are:
>>
>>  
>>
>> -          CV - looking through the CV there is still a fair bit of 
>> work to do, there’s quite a few terms with missing or incorrect 
>> documentation
>>
>> -          Mapping file
>>
>> -          Finish example files.
>>
>>  
>>
>> Prior to the call on Thurs, can we have a think about how we plan to 
>> get the CV into shape and discuss it as a main agenda item...
>>
>>  
>>
>> Also new schema uploaded with a few bits of improved documentation.
>>
>> Cheers
>>
>> Andy
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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-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
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>   

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[Jones, A. <And...@li...>]

Hi Matt,

For now I've gone with the following documentation in the XSD:

"The locally unique id for the spectrum in the spectra data set specified by
SpectraData_ref. External guidelines are provided on the use of consistent
identifiers for spectra in different external formats."

In the draft of the spec document, I'll add a section in  "Resolved Design and
scope issues" on the discussion of unique identifiers, including documentation
about using nativeID for mzML and systems for identifying spectra in other
formats. Do you know if there is any documentation about the system designed for
mzML?

I don't want to "hard-code" this guideline in the XSD, since I would like to get
a bit more input from mzML developers during the doc process. I looked at the
mzML XSD docs again, and the ID attribute does say: "A unique identifier for
this spectrum. It should be expected that external files may use this identifier
together with the mzML filename or accession to reference a particular
spectrum."

If we hard-code a conflicting guideline in the axml XSD, people will get
confused so I would rather document this in more detail in the spec doc, where
we can actually discuss the reasoning for this.

Cheers
Andy










> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: 01 December 2008 19:44
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> 
> Pfft, I'm such a lazy implementor I wait till the last minute to put my
> output through a schema validator, much less a semantic validator. ;)
> The truth is that spectrum::id was formulated before nativeID and AFAIK
> we kept it so if somebody wants an arbitrary xsd:ID for whatever reason
> they can have it.
> 
> This is a small documentation change indeed, but it's a pretty big
> semantic change (how writers/readers work and how much information they
> expect to have access to). How's this for spectrumID:
> "Uniquely identifies a spectrum in the input spectra using the nativeID
> format defined for that file type. For mzML input, the format is
> inherited from the input and spectrumID will match the nativeID of a
> spectrum in the mzML."
> 
> Thanks,
> -Matt
> 
> 
> Jones, Andy wrote:
> >
> > Okay, maybe I can be persuaded by this argument, since as you say the
> > actual identifier is created by the combination of id + file ref so it
> > is clear that we're referencing the mzML version of the spectrum.
> >
> > I'm still slightly wary that not all implementers will read the
> > documentation and put out files using the semantic validator though.
> > If the nativeID is genuinely always going to be unique within file
> > then fine, but why have the ID attribute at all in mzML...? It sounds
> > like it was created so that there is a guaranteed unique identifier
> > for each spectrum, that can be XSD validated.
> >
> > The bottom line is though that this is a tiny documentation change
> > either way, with pretty small pros/cons! Perhaps we've spent long
> > enough on it :-) I can make this change to the documentation (if mzML
> > input, give nativeID) then we can re-visit the whole identification
> > issue during the doc process. Seem reasonable?
> >
> > cheers
> > Andy
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Matthew Chambers [mailto:mat...@va...]
> > Sent: Mon 01/12/2008 17:39
> > To: psi...@li...
> > Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >
> > As you say, the file URL in the analysisXML header must be combined with
> > the spectrum identifier to link back to the input spectrum. The nativeID
> > works no matter what the format of the input file was. The mzML id only
> > works for mzML input. Consider the following chain of input file
> > processing:
> > file:///raw/source1.raw
> > file:///processed/source1.mzXML
> > file:///searched/source1.analysisXML
> >
> > The analysisXML header would point to file:///processed/source1.mzXML as
> > the input file and would use mzXML's nativeID, which is:
> > "scan=xsd:nonNegativeInteger"
> >
> > Now substitute mzML instead of mzXML. The nativeID can now use the true
> > native format for thermo RAW: "controller=xsd:nonNegativeInteger
> > scan=xsd:positiveInteger"
> >
> > There is no difference in file tracking, it's only the fidelity of the
> > nativeID that has improved. The nativeID works transparently in mzML: if
> > the analysisXML header points to an mzML and uses the nativeID, that's
> > just as effective at finding a spectrum as the arbitrary id. It just so
> > happens that the preserved nativeID format allows machines to easily
> > look up the spectrum in the raw data as well as the processed data
> > despite the fact that - as you say - they're different "objects." As
> > long as your database maintains both a processing prefix/URL as well as
> > the nativeID, it'll be golden.
> >
> >
> > >  If we re-use the native identifier this implies the input to the
> > >  search engine was the mgf file, which was not the case...
> > As above, you must maintain the an identifier to the file that the
> > spectrum identifier pertains to - which explicitly says what the input
> > to the search was. What implication is possible given that information?
> >
> > -Matt
> >
> >
> > Jones, Andy wrote:
> > >  Hi Matt,
> > >
> > >  It's a question of identifying objects as they are traced throughout
> > >  a process. In AnalysisXML we are not representing the spectrum
> > >  object, we are making an explicit reference to the spectrum as it is
> > >  represented in mzML. The nativeID is preserved, since it is
> > >  referenced as the input to the process that converts mgf to mzML.
> > >
> > > > HAVE an id. Consider the pipeline: mgf --> SearchEngine -->
> > > > analysisXML What do you use for spectrumID? :)
> > >
> > >  In this case, we use the identifier as specified by the "native ID"
> > >  system you've defined because the input to the search was the mgf
> > >  spectrum object. I agree that this system looks good and we will use
> > >  it for each of the vendor-specific formats - in effect I want to add
> > >  one more mapping for mzML, mapping to the mzML ID ;-) Remember, we're
> > >  not trying to represent the spectrum in analysisXML, all we are
> > >  saying is what spectrum did the search engine take as input.
> > >
> > >  I view the conversion of an mgf spectrum to an mzML spectrum as a
> > >  process that has changed the spectrum object. As such, the nativeID
> > >  in mzML references the input to the conversion process and the mzML
> > >  ID attribute references the (output) spectrum as it is in the file.
> > >  Correct use of the identifiers maintains this trace.
> > >
> > > > Your database use case cannot use mzML ids because xsd:IDs are
> > > > unique within a file, not across files.
> > >
> > >  This is true but is solved easily by prefixing all identifiers with a
> > >  unique string (e.g. the file URL). The problem is worse for nativeID
> > >  because this cannot be done - the mgf version of the spectrum and the
> > >  mzML version of the spectrum are fundamentally different (possibly
> > >  even have different precisions) so they need different identifiers.
> > >  If we re-use the native identifier this implies the input to the
> > >  search engine was the mgf file, which was not the case...
> > >
> > >  Cheers Andy
> > >
> > >
> > >
> > > > -----Original Message----- From: Matthew Chambers
> > > > [mailto:mat...@va...] Sent: 01 December 2008
> > > > 16:03 To: psi...@li... Subject: Re:
> > > > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > > >
> > > > The nativeID is intended to refer to the closest-to-native format
> > > > that can be interpreted by the machine. In your pipeline, the mgf
> > > > is the closest-to-native format, so yes that nativeID would and
> > > > should be preserved throughout the pipeline.  Your database use
> > > > case cannot use mzML ids because xsd:IDs are unique within a file,
> > > > not across files. You do not have any kind of guarantee that your
> > > > ids will be distinct between two mzML files, not to mention the
> > > > fact that non-mzML files don't even HAVE an id. Consider the
> > > > pipeline: mgf --> SearchEngine --> analysisXML What do you use for
> > > > spectrumID? :)
> > > >
> > > > -Matt
> > > >
> > > >
> > > > Jones, Andy wrote:
> > > >> Hi Matt,
> > > >>
> > > >> Consider the following pipeline mgf --> mzML --> SearchEngine -->
> > > >>  analysisXML
> > > >>
> > > >> Having thought about this some more, I'm fairly sure that we want
> > > >> to reference the ID attribute rather than nativeID. The nativeID
> > > >> is intended to identify the source spectrum prior to conversion
> > > >> to mzML format i.e. it does not strictly identify the data
> > > >> represented in the file. The input to analysisXML is the
> > > >> mzML-formatted spectrum, not the source mgf file. If we reference
> > > >> the nativeID, this implies that the input to the SearchEngine was
> > > >> the mgf representation of the spectrum. It's a minor point that
> > > >> makes no difference for most XML implementations but the mgf
> > > >> formatted spectrum and the mzML formatted spectrum are different
> > > >> objects. If a database implements this, it will be much simpler
> > > >> to have a chain of inputs and outputs with distinct IDs,
> > > >> reflecting the processing that has happened at each stage. >From a
> > > >> database/LIMS or file tracking point of view, this could be
> > > >> significant I think.
> > > >>
> > > >> Cheers Andy
> > > >>> -----Original Message----- From: Matt Chambers
> > > >>> [mailto:mat...@va...] Sent: 01 December 2008
> > > >>>  14:23 To: psi...@li... Subject: Re:
> > > >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > > >>>
> > > >>> Jones, Andy wrote:
> > > >>>> Hi all,
> > > >>>>
> > > >>>> The issues list is getting a bit messy with essentially a
> > > >>>> mailing list discussion so I'll shift the discussion back
> > > >>>> here :-)
> > > >>>>
> > > >>>> There are two points up for discussion.
> > > >>>>
> > > >>>> 1) Use of identifiers for input spectra 2) CV terms shared
> > > >>>> between psi-ms and psi-pi
> > > >>>>
> > > >>>> In terms of 1) I've worked through Matt's argument and I'm in
> > > >>>>  general agreement that we would like to use the same system
> > > >>>> for identifying the input spectrum - these CV terms have only
> > > >>>> been added relatively recently. I did not realise that the
> > > >>>> nativeID attribute had been specified to this level, since
> > > >>>> there is no documentation about this is in the XSD or mzML
> > > >>>> specification document.
> > > >>>>
> > > >>>> I don't think we should change the name of the attribute
> > > >>>> though, since nativeID makes sense for an element called
> > > >>>> <Spectrum> in mzML but not for an element
> > > >>>> <SpectrumIdentificationResult> in analysisXML. For
> > > >>>> referencing mzML spectra, I'm still not sure which attribute
> > > >>>> we should choose to reference since the "true" (and
> > > >>>> guaranteed unique) spectrum identifier in mzML is actually
> > > >>>> the ID attribute. I can envisage a case where instruments
> > > >>>> output mzML directly and the nativeID is not implemented
> > > >>>> sensibly. The xs:ID datatype on "ID" guarantees that these
> > > >>>> will always be unique whatever changes happen to
> > > >>>> documentation in the future or whatever tools are used to
> > > >>>> create the file.
> > > >>> I contest the term "guaranteed unique" since the one doing the
> > > >>> guaranteeing is the schema and there is no guarantee that
> > > >>> somebody runs their output through a schema validator. :) If
> > > >>> you take the validation step to the semantic validator (which
> > > >>> is what the standard demands), the nativeID term is also
> > > >>> guaranteed to be unique (and must be "implemented sensibly"),
> > > >>> and as David suggested earlier, it should be possible to add a
> > > >>> uniqueness constraint to the nativeID attribute in the schema
> > > >>> even though it is xsd:string (but uniqueness is not so helpful
> > > >>> when the actual form of a Thermo RAW id must be:
> > > >>> "controller=xsd:positiveInteger scan=xsd:nonZeroInteger"). The
> > > >>> name of the attribute doesn't bother me, but I don't understand
> > > >>> your reasoning for not changing it. :)
> > > >>>
> > > >>>
> > > >>>> So I agree with Matt but I don't want to change the schema
> > > >>>> :-) I'm happy to add something to the documentation
> > > >>>> specifying how different identifiers should be implemented,
> > > >>>> following the rules in the psi-ms CV.
> > > >>> If the attribute name doesn't change, only the xsd
> > > >>> documentation needs to be updated to reflect which attribute
> > > >>> the spectrumID points to and that it can be used even if the
> > > >>> input spectra file is not mzML!
> > > >>>
> > > >>>
> > > >>>> In terms of 2), we had made a decision in the past that we
> > > >>>> would simply create terms as we need them in PSI-PI, rather
> > > >>>> than worrying if they should be common between psi-ms and
> > > >>>> psi-pi and trying to coordinate updates across groups. If a
> > > >>>> term is present in psi-ms with the exact meaning that we want
> > > >>>> (taking into account its position in the hierarchy), I think
> > > >>>> we should just use it and update the mapping file to
> > > >>>> reference it. Are there many terms from psi-ms that we want
> > > >>>> to use?
> > > >>> It's looking like scan time (aka retention time) will be useful
> > > >>> in analysisXML as an "alternative identifier" for the special
> > > >>> use case of converting existing search results to analysisXML
> > > >>> where a reliable nativeID to the original vendor format has
> > > >>> been lost. Presumably, even in this use case a nativeID could
> > > >>> be provided to point back to a spectrum in the search engine's
> > > >>> immediate spectra input file (i.e. MGF).  If not even that is
> > > >>> possible, either spectrumID has to be optional or the use case
> > > >>> is rather suspect. :)
> > > >>>
> > > >>>
> > > >>> Additionally, if your "spectrumID" attribute matches the
> > > >>> "nativeID" attribute in mzML, the mapping file must require one
> > > >>> of the nativeID format terms in the file header: the specific
> > > >>> place is TBD in analysisXML, in mzML it's mapped to the
> > > >>> fileDescription element. Remember, nativeID is always available
> > > >>> from any input spectra file, so there's no problem requiring it
> > > >>> as long as decent references to the input spectra are
> > > >>> maintained.
> > > >>>
> > > >>> The scan time as an "alternative identifier" issue makes me
> > > >>> wonder if a "scan time native spectrum identifier" term is
> > > >>> called for. It still wouldn't solve all of the problems with
> > > >>> David's use case (i.e. if the MGF was missing RTINSECONDS
> > > >>> attributes), but it seems potentially useful.
> > > >>>
> > > >>> -Matt
> > > >>>
> > > >>>
> > > >>>> I am working on the spec document today and would like to get
> > > >>>> all issues tidied up ASAP... Cheers Andy
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> -----Original Message----- From:
> > > >>>>> cod...@go...
> > > >>>>> [mailto:cod...@go...] Sent: 30 November 2008
> > > >>>>>  19:36 To: psi...@li... Subject:
> > > >>>>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > > >>>>>
> > > >>>>>
> > > >>>>> Comment #56 on issue 42 by matthew....@vanderbilt.edu:
> > > >>>>> Issues with the CV
> > > >>>>> http://code.google.com/p/psi-pi/issues/detail?id=42
> > > >>>>>
> > > >>>>>
> > > >>>>> Yes, I was at that meeting too. :) The one (important, IMO)
> > > >>>>> use case we did not consider at that time is output of
> > > >>>>> analysisXML without a corresponding mzML document. In such
> > > >>>>> a case, the mzML arbitrary id does not exist, but the
> > > >>>>> nativeID does. This fact convinces me that nativeID is a
> > > >>>>> better reference than the arbitrary id.
> > > >>>>>
> > > >>>>> The change of attribute name to nativeID is not so
> > > >>>>> critical, but I think the risk of confusing the spectrumID
> > > >>>>> with the id attribute when it actually points to the
> > > >>>>> nativeID attribute is worse than the risk of confusing the
> > > >>>>> nativeID attribute with some property of the search engine.
> > > >>>>> I think the documentation for the nativeID attribute can
> > > >>>>> easily make it clear what it's supposed to reference,
> > > >>>>> especially since it's on a spectrum-centric element; you
> > > >>>>> can copy it from the mzML schema (although I think this
> > > >>>>> documentation could be improved upon):
> > > >>>>> <xs:documentation>The native identifier for the spectrum,
> > > >>>>> used by the acquisition software.</xs:documentation>
> > > >>>>>
> > > >>>>> It's good to know about the header information. The
> > > >>>>> nativeID (or whatever it's called in analysisXML) format
> > > >>>>> term would go in the spectra input definition as a CV Param
> > > >>>>> required by the mapping file.
> > > >
> > > >
> > -------------------------------------------------------------------------
> > > >  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=/
> > <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> > > > _______________________________________________ Psidev-pi-dev
> > > > mailing list Psi...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> > >
> > >
> > -------------------------------------------------------------------------
> > >  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=/
> > <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> > >  _______________________________________________ Psidev-pi-dev
> mailing
> > >  list Psi...@li...
> > >  https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> > >
> >
> >
> > -------------------------------------------------------------------------
> > 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=/
> > <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> > _______________________________________________
> > Psidev-pi-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> >
> 
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] FW: Spec doc

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

Hi everyone, I have just updated the HTML and plain documentation files
based on what's in SVN right now.

 

I have fixed the missing definition problem.

 

I have added some embedded figures that Any sent.

 

I should mention that I am using Mascot_MSMS_example.axml as the example
template. What my software does is reads one example file and then injects
examples from that file into the documentation. I picked this file somewhat
arbitrarily. If there is a better file, please let me know. The longest file
is not necessarily best. But rather the file that exercises most parts of
the format is best. Anyone have a better suggestion? Maybe I could adjust my
program to read several files and try to automatically pick the "best"
example from any of those files

 

Regarding David's comment about <PlusValue> below.. it seems you currently
have:

  <PlusValue  unitCvRef="UO" unitAccession="UO:0000221" unitName="dalton"
value="0.5" />

If this were:

  <PlusValue>

    <pf:cvParam accession="UO:0000221" name="dalton" value="0.5" cvRef="UO"
/>

  </PlusValue>

 

Then my software would display what you expect. Is there a compelling reason
why you use the former instead of the latter? It would seem that the latter
is more generic from a software-handling perspective.

 

Or, even better, the more mzML style would be:

 

<pf:cvParam accession="PI:00999" name="search window plus value" value="0.5"
cvRef="PSI-PI"

unitAccession="UO:0000221" name="dalton" cvRef="UO" />

 

Just causing trouble.

Eric

 

 

 

  _____  

From: David Creasy [mailto:dc...@ma...] 
Sent: Monday, December 01, 2008 9:41 AM
To: psi...@li...
Subject: Re: [Psidev-pi-dev] FW: Spec doc

 

Hi Andy,

Some minor changes:

From:
<pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person" email=
<mailto:so...@so...> "so...@so...">
to:
<pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person" email=
<mailto:so...@so...> "so...@so...">
 
 
Example Context:      
<pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=
<http://www.psidev.info/not_sure_of_url_to_cv.obo>
"http://www.psidev.info/not_sure_of_url_to_cv.obo"></pf:cv>
We only want the cv psidev.info when we finally release. Guess it's OK to
leave this as it is at the moment.
 
 
Element <AnalysisSoftware>
Definition:   A data set containing spectra data (consisting of one or more
spectra). 
Definition looks like a copy and paste of something quite different!
 
 
Element <pf:ContactRole>
Definition:   The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be
a bit more general? 
In the example it is for a software vendor.
 
 
 
Element <pf:Person>
Example needs filling out a bit with some fictitious person.
 
 
Element <Peptide>
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence
residues, exclusive of the termini masses in Daltons.

Oh dear. Some of the examples are inclusive of the termini masses and any
modifications, others are not. In theory, it's possible to calculate the
mass given the modification delta and the CTermGain="OH" NTermGain="H" from
the enzyme. However, that's not trivial in a case of multiple enzymes. I'd
suggest we change the definition to include the termini and mods. Martin
(whose examples followed the documentation)  may think differently?


Element <Inputs>
Definition:     The inputs to the analyses including the databases searched
and the spectral data 
The example shows the input file to the process that created the analysisXML
document (the Mascot .dat file)
The global definition needs changing. Also, need to add a definition for
SpectraData.


Element <DatabaseTranslation>
Could take examples from Mascot_NA_example.axml


Element <Enzyme>
missedCleavages    xsd:int    optional    URI of the analysis software e.g.
manufacturer's website
semiSpecific - shouldn't this be a boolean?


Element <PlusValue>
unitName    xsd:string    -    The name of the unit.
Shame that it doesn't pull out the allowed CV from the mapping file:

<CvTerm termAccession="UO:0000221" useTermName="false" useTerm="true"
termName="dalton" cvIdentifierRef="UO" />
<CvTerm termAccession="UO:0000166" useTermName="false" useTerm="false"
termName="parts per notation" cvIdentifierRef="UO" />

Element <SpectrumIdentificationItem>
Has an attribute of rank and also a CV item. From the minutes here:
http://psidev.info/index.php?q=node/380
Looks as though we agreed it should be an attribute and removed from the CV

Cheers,
David

Jones, Andy wrote: 

Hi all,

Eric has re-generated the schema documentation for us. This is getting
fairly close to a version I can cut and paste into the spec doc. Let me know
if you have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated
HTML documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in
the subelement listing, any subelements that are double-tall nested
substitution grouped elements do not have their definition visible. If one
clicks on the subelement, the main element does have a definition. So it's
there, but my program is stymied by the various levels. This is fixable, but
probably not before submission.

 

If you send me screen-capture images to embed in some elements, that can be
done if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

  _____  

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We're
aiming to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest
schema and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get
back to you.

 

Sorry I've missed the calls. That time is very awkward for me and I've
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

  _____  

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs?
There's a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited
attributes does not appear in the table (e.g. see Specificity rule, no docs
for cvRef, unitName etc.) - unless we were missing documentation for these
attributes when it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light
schema which are completely empty, no attributes or documentation e.g.
Organization or Person.

 

We're aiming to submit the specs to the PSI process by the end of month
(i.e. a week on Monday), so if you would be able to look at this fairly soon
it would be very much appreciated! Also, any chance that you can get someone
to generate the TPP and SpectraST examples at your end. It's no disaster if
we submit to the process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file
the mapping information for SearchType and it seemed to pull it out of the
CV nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to
automatically pull examples out of?

 

Regards,

Eric

 

 

 

  _____  

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

Finish section on use cases when we have finally agreed the list online and
made all the example files.

Import some parts of the example files to demonstrate a few specific points

Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

CV - looking through the CV there is still a fair bit of work to do, there's
quite a few terms with missing or incorrect documentation

Mapping file

Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the
CV into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

 





  _____  



 
-------------------------------------------------------------------------
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
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
 





  _____  



 
_______________________________________________
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

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Pfft, I'm such a lazy implementor I wait till the last minute to put my 
output through a schema validator, much less a semantic validator. ;) 
The truth is that spectrum::id was formulated before nativeID and AFAIK 
we kept it so if somebody wants an arbitrary xsd:ID for whatever reason 
they can have it.

This is a small documentation change indeed, but it's a pretty big 
semantic change (how writers/readers work and how much information they 
expect to have access to). How's this for spectrumID:
"Uniquely identifies a spectrum in the input spectra using the nativeID 
format defined for that file type. For mzML input, the format is 
inherited from the input and spectrumID will match the nativeID of a 
spectrum in the mzML."

Thanks,
-Matt


Jones, Andy wrote:
>
> Okay, maybe I can be persuaded by this argument, since as you say the 
> actual identifier is created by the combination of id + file ref so it 
> is clear that we're referencing the mzML version of the spectrum.
>
> I'm still slightly wary that not all implementers will read the 
> documentation and put out files using the semantic validator though. 
> If the nativeID is genuinely always going to be unique within file 
> then fine, but why have the ID attribute at all in mzML...? It sounds 
> like it was created so that there is a guaranteed unique identifier 
> for each spectrum, that can be XSD validated.
>
> The bottom line is though that this is a tiny documentation change 
> either way, with pretty small pros/cons! Perhaps we've spent long 
> enough on it :-) I can make this change to the documentation (if mzML 
> input, give nativeID) then we can re-visit the whole identification 
> issue during the doc process. Seem reasonable?
>
> cheers
> Andy
>
>
>
>
>
>
>
> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Mon 01/12/2008 17:39
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
>
> As you say, the file URL in the analysisXML header must be combined with
> the spectrum identifier to link back to the input spectrum. The nativeID
> works no matter what the format of the input file was. The mzML id only
> works for mzML input. Consider the following chain of input file 
> processing:
> file:///raw/source1.raw
> file:///processed/source1.mzXML
> file:///searched/source1.analysisXML
>
> The analysisXML header would point to file:///processed/source1.mzXML as
> the input file and would use mzXML's nativeID, which is:
> "scan=xsd:nonNegativeInteger"
>
> Now substitute mzML instead of mzXML. The nativeID can now use the true
> native format for thermo RAW: "controller=xsd:nonNegativeInteger
> scan=xsd:positiveInteger"
>
> There is no difference in file tracking, it's only the fidelity of the
> nativeID that has improved. The nativeID works transparently in mzML: if
> the analysisXML header points to an mzML and uses the nativeID, that's
> just as effective at finding a spectrum as the arbitrary id. It just so
> happens that the preserved nativeID format allows machines to easily
> look up the spectrum in the raw data as well as the processed data
> despite the fact that - as you say - they're different "objects." As
> long as your database maintains both a processing prefix/URL as well as
> the nativeID, it'll be golden.
>
>
> >  If we re-use the native identifier this implies the input to the
> >  search engine was the mgf file, which was not the case...
> As above, you must maintain the an identifier to the file that the
> spectrum identifier pertains to - which explicitly says what the input
> to the search was. What implication is possible given that information?
>
> -Matt
>
>
> Jones, Andy wrote:
> >  Hi Matt,
> >
> >  It's a question of identifying objects as they are traced throughout
> >  a process. In AnalysisXML we are not representing the spectrum
> >  object, we are making an explicit reference to the spectrum as it is
> >  represented in mzML. The nativeID is preserved, since it is
> >  referenced as the input to the process that converts mgf to mzML.
> >
> > > HAVE an id. Consider the pipeline: mgf --> SearchEngine -->
> > > analysisXML What do you use for spectrumID? :)
> >
> >  In this case, we use the identifier as specified by the "native ID"
> >  system you've defined because the input to the search was the mgf
> >  spectrum object. I agree that this system looks good and we will use
> >  it for each of the vendor-specific formats - in effect I want to add
> >  one more mapping for mzML, mapping to the mzML ID ;-) Remember, we're
> >  not trying to represent the spectrum in analysisXML, all we are
> >  saying is what spectrum did the search engine take as input.
> >
> >  I view the conversion of an mgf spectrum to an mzML spectrum as a
> >  process that has changed the spectrum object. As such, the nativeID
> >  in mzML references the input to the conversion process and the mzML
> >  ID attribute references the (output) spectrum as it is in the file.
> >  Correct use of the identifiers maintains this trace.
> >
> > > Your database use case cannot use mzML ids because xsd:IDs are
> > > unique within a file, not across files.
> >
> >  This is true but is solved easily by prefixing all identifiers with a
> >  unique string (e.g. the file URL). The problem is worse for nativeID
> >  because this cannot be done - the mgf version of the spectrum and the
> >  mzML version of the spectrum are fundamentally different (possibly
> >  even have different precisions) so they need different identifiers.
> >  If we re-use the native identifier this implies the input to the
> >  search engine was the mgf file, which was not the case...
> >
> >  Cheers Andy
> >
> >
> >
> > > -----Original Message----- From: Matthew Chambers
> > > [mailto:mat...@va...] Sent: 01 December 2008
> > > 16:03 To: psi...@li... Subject: Re:
> > > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > >
> > > The nativeID is intended to refer to the closest-to-native format
> > > that can be interpreted by the machine. In your pipeline, the mgf
> > > is the closest-to-native format, so yes that nativeID would and
> > > should be preserved throughout the pipeline.  Your database use
> > > case cannot use mzML ids because xsd:IDs are unique within a file,
> > > not across files. You do not have any kind of guarantee that your
> > > ids will be distinct between two mzML files, not to mention the
> > > fact that non-mzML files don't even HAVE an id. Consider the
> > > pipeline: mgf --> SearchEngine --> analysisXML What do you use for
> > > spectrumID? :)
> > >
> > > -Matt
> > >
> > >
> > > Jones, Andy wrote:
> > >> Hi Matt,
> > >>
> > >> Consider the following pipeline mgf --> mzML --> SearchEngine -->
> > >>  analysisXML
> > >>
> > >> Having thought about this some more, I'm fairly sure that we want
> > >> to reference the ID attribute rather than nativeID. The nativeID
> > >> is intended to identify the source spectrum prior to conversion
> > >> to mzML format i.e. it does not strictly identify the data
> > >> represented in the file. The input to analysisXML is the
> > >> mzML-formatted spectrum, not the source mgf file. If we reference
> > >> the nativeID, this implies that the input to the SearchEngine was
> > >> the mgf representation of the spectrum. It's a minor point that
> > >> makes no difference for most XML implementations but the mgf
> > >> formatted spectrum and the mzML formatted spectrum are different
> > >> objects. If a database implements this, it will be much simpler
> > >> to have a chain of inputs and outputs with distinct IDs,
> > >> reflecting the processing that has happened at each stage. >From a
> > >> database/LIMS or file tracking point of view, this could be
> > >> significant I think.
> > >>
> > >> Cheers Andy
> > >>> -----Original Message----- From: Matt Chambers
> > >>> [mailto:mat...@va...] Sent: 01 December 2008
> > >>>  14:23 To: psi...@li... Subject: Re:
> > >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > >>>
> > >>> Jones, Andy wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> The issues list is getting a bit messy with essentially a
> > >>>> mailing list discussion so I'll shift the discussion back
> > >>>> here :-)
> > >>>>
> > >>>> There are two points up for discussion.
> > >>>>
> > >>>> 1) Use of identifiers for input spectra 2) CV terms shared
> > >>>> between psi-ms and psi-pi
> > >>>>
> > >>>> In terms of 1) I've worked through Matt's argument and I'm in
> > >>>>  general agreement that we would like to use the same system
> > >>>> for identifying the input spectrum - these CV terms have only
> > >>>> been added relatively recently. I did not realise that the
> > >>>> nativeID attribute had been specified to this level, since
> > >>>> there is no documentation about this is in the XSD or mzML
> > >>>> specification document.
> > >>>>
> > >>>> I don't think we should change the name of the attribute
> > >>>> though, since nativeID makes sense for an element called
> > >>>> <Spectrum> in mzML but not for an element
> > >>>> <SpectrumIdentificationResult> in analysisXML. For
> > >>>> referencing mzML spectra, I'm still not sure which attribute
> > >>>> we should choose to reference since the "true" (and
> > >>>> guaranteed unique) spectrum identifier in mzML is actually
> > >>>> the ID attribute. I can envisage a case where instruments
> > >>>> output mzML directly and the nativeID is not implemented
> > >>>> sensibly. The xs:ID datatype on "ID" guarantees that these
> > >>>> will always be unique whatever changes happen to
> > >>>> documentation in the future or whatever tools are used to
> > >>>> create the file.
> > >>> I contest the term "guaranteed unique" since the one doing the
> > >>> guaranteeing is the schema and there is no guarantee that
> > >>> somebody runs their output through a schema validator. :) If
> > >>> you take the validation step to the semantic validator (which
> > >>> is what the standard demands), the nativeID term is also
> > >>> guaranteed to be unique (and must be "implemented sensibly"),
> > >>> and as David suggested earlier, it should be possible to add a
> > >>> uniqueness constraint to the nativeID attribute in the schema
> > >>> even though it is xsd:string (but uniqueness is not so helpful
> > >>> when the actual form of a Thermo RAW id must be:
> > >>> "controller=xsd:positiveInteger scan=xsd:nonZeroInteger"). The
> > >>> name of the attribute doesn't bother me, but I don't understand
> > >>> your reasoning for not changing it. :)
> > >>>
> > >>>
> > >>>> So I agree with Matt but I don't want to change the schema
> > >>>> :-) I'm happy to add something to the documentation
> > >>>> specifying how different identifiers should be implemented,
> > >>>> following the rules in the psi-ms CV.
> > >>> If the attribute name doesn't change, only the xsd
> > >>> documentation needs to be updated to reflect which attribute
> > >>> the spectrumID points to and that it can be used even if the
> > >>> input spectra file is not mzML!
> > >>>
> > >>>
> > >>>> In terms of 2), we had made a decision in the past that we
> > >>>> would simply create terms as we need them in PSI-PI, rather
> > >>>> than worrying if they should be common between psi-ms and
> > >>>> psi-pi and trying to coordinate updates across groups. If a
> > >>>> term is present in psi-ms with the exact meaning that we want
> > >>>> (taking into account its position in the hierarchy), I think
> > >>>> we should just use it and update the mapping file to
> > >>>> reference it. Are there many terms from psi-ms that we want
> > >>>> to use?
> > >>> It's looking like scan time (aka retention time) will be useful
> > >>> in analysisXML as an "alternative identifier" for the special
> > >>> use case of converting existing search results to analysisXML
> > >>> where a reliable nativeID to the original vendor format has
> > >>> been lost. Presumably, even in this use case a nativeID could
> > >>> be provided to point back to a spectrum in the search engine's
> > >>> immediate spectra input file (i.e. MGF).  If not even that is
> > >>> possible, either spectrumID has to be optional or the use case
> > >>> is rather suspect. :)
> > >>>
> > >>>
> > >>> Additionally, if your "spectrumID" attribute matches the
> > >>> "nativeID" attribute in mzML, the mapping file must require one
> > >>> of the nativeID format terms in the file header: the specific
> > >>> place is TBD in analysisXML, in mzML it's mapped to the
> > >>> fileDescription element. Remember, nativeID is always available
> > >>> from any input spectra file, so there's no problem requiring it
> > >>> as long as decent references to the input spectra are
> > >>> maintained.
> > >>>
> > >>> The scan time as an "alternative identifier" issue makes me
> > >>> wonder if a "scan time native spectrum identifier" term is
> > >>> called for. It still wouldn't solve all of the problems with
> > >>> David's use case (i.e. if the MGF was missing RTINSECONDS
> > >>> attributes), but it seems potentially useful.
> > >>>
> > >>> -Matt
> > >>>
> > >>>
> > >>>> I am working on the spec document today and would like to get
> > >>>> all issues tidied up ASAP... Cheers Andy
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -----Original Message----- From:
> > >>>>> cod...@go...
> > >>>>> [mailto:cod...@go...] Sent: 30 November 2008
> > >>>>>  19:36 To: psi...@li... Subject:
> > >>>>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > >>>>>
> > >>>>>
> > >>>>> Comment #56 on issue 42 by matthew....@vanderbilt.edu:
> > >>>>> Issues with the CV
> > >>>>> http://code.google.com/p/psi-pi/issues/detail?id=42
> > >>>>>
> > >>>>>
> > >>>>> Yes, I was at that meeting too. :) The one (important, IMO)
> > >>>>> use case we did not consider at that time is output of
> > >>>>> analysisXML without a corresponding mzML document. In such
> > >>>>> a case, the mzML arbitrary id does not exist, but the
> > >>>>> nativeID does. This fact convinces me that nativeID is a
> > >>>>> better reference than the arbitrary id.
> > >>>>>
> > >>>>> The change of attribute name to nativeID is not so
> > >>>>> critical, but I think the risk of confusing the spectrumID
> > >>>>> with the id attribute when it actually points to the
> > >>>>> nativeID attribute is worse than the risk of confusing the
> > >>>>> nativeID attribute with some property of the search engine.
> > >>>>> I think the documentation for the nativeID attribute can
> > >>>>> easily make it clear what it's supposed to reference,
> > >>>>> especially since it's on a spectrum-centric element; you
> > >>>>> can copy it from the mzML schema (although I think this
> > >>>>> documentation could be improved upon):
> > >>>>> <xs:documentation>The native identifier for the spectrum,
> > >>>>> used by the acquisition software.</xs:documentation>
> > >>>>>
> > >>>>> It's good to know about the header information. The
> > >>>>> nativeID (or whatever it's called in analysisXML) format
> > >>>>> term would go in the spectra input definition as a CV Param
> > >>>>> required by the mapping file.
> > >
> > > 
> -------------------------------------------------------------------------
> > >  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=/ 
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> > > _______________________________________________ Psidev-pi-dev
> > > mailing list Psi...@li...
> > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> >
> >  
> -------------------------------------------------------------------------
> >  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=/ 
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> >  _______________________________________________ Psidev-pi-dev mailing
> >  list Psi...@li...
> >  https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> >
>
>
> -------------------------------------------------------------------------
> 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=/ 
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[Jones, A. <And...@li...>]

Okay, maybe I can be persuaded by this argument, since as you say the actual
identifier is created by the combination of id + file ref so it is clear that
we're referencing the mzML version of the spectrum. 

I'm still slightly wary that not all implementers will read the documentation
and put out files using the semantic validator though. If the nativeID is
genuinely always going to be unique within file then fine, but why have the ID
attribute at all in mzML...? It sounds like it was created so that there is a
guaranteed unique identifier for each spectrum, that can be XSD validated.

The bottom line is though that this is a tiny documentation change either way,
with pretty small pros/cons! Perhaps we've spent long enough on it :-) I can
make this change to the documentation (if mzML input, give nativeID) then we can
re-visit the whole identification issue during the doc process. Seem reasonable?

cheers
Andy







-----Original Message-----
From: Matthew Chambers [mailto:mat...@va...]
Sent: Mon 01/12/2008 17:39
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
 
As you say, the file URL in the analysisXML header must be combined with 
the spectrum identifier to link back to the input spectrum. The nativeID 
works no matter what the format of the input file was. The mzML id only 
works for mzML input. Consider the following chain of input file processing:
file:///raw/source1.raw
file:///processed/source1.mzXML
file:///searched/source1.analysisXML

The analysisXML header would point to file:///processed/source1.mzXML as 
the input file and would use mzXML's nativeID, which is: 
"scan=xsd:nonNegativeInteger"

Now substitute mzML instead of mzXML. The nativeID can now use the true 
native format for thermo RAW: "controller=xsd:nonNegativeInteger 
scan=xsd:positiveInteger"

There is no difference in file tracking, it's only the fidelity of the 
nativeID that has improved. The nativeID works transparently in mzML: if 
the analysisXML header points to an mzML and uses the nativeID, that's 
just as effective at finding a spectrum as the arbitrary id. It just so 
happens that the preserved nativeID format allows machines to easily 
look up the spectrum in the raw data as well as the processed data 
despite the fact that - as you say - they're different "objects." As 
long as your database maintains both a processing prefix/URL as well as 
the nativeID, it'll be golden.


>  If we re-use the native identifier this implies the input to the
>  search engine was the mgf file, which was not the case...
As above, you must maintain the an identifier to the file that the 
spectrum identifier pertains to - which explicitly says what the input 
to the search was. What implication is possible given that information?

-Matt


Jones, Andy wrote:
>  Hi Matt,
>
>  It's a question of identifying objects as they are traced throughout
>  a process. In AnalysisXML we are not representing the spectrum
>  object, we are making an explicit reference to the spectrum as it is
>  represented in mzML. The nativeID is preserved, since it is
>  referenced as the input to the process that converts mgf to mzML.
>
> > HAVE an id. Consider the pipeline: mgf --> SearchEngine -->
> > analysisXML What do you use for spectrumID? :)
>
>  In this case, we use the identifier as specified by the "native ID"
>  system you've defined because the input to the search was the mgf
>  spectrum object. I agree that this system looks good and we will use
>  it for each of the vendor-specific formats - in effect I want to add
>  one more mapping for mzML, mapping to the mzML ID ;-) Remember, we're
>  not trying to represent the spectrum in analysisXML, all we are
>  saying is what spectrum did the search engine take as input.
>
>  I view the conversion of an mgf spectrum to an mzML spectrum as a
>  process that has changed the spectrum object. As such, the nativeID
>  in mzML references the input to the conversion process and the mzML
>  ID attribute references the (output) spectrum as it is in the file.
>  Correct use of the identifiers maintains this trace.
>
> > Your database use case cannot use mzML ids because xsd:IDs are
> > unique within a file, not across files.
>
>  This is true but is solved easily by prefixing all identifiers with a
>  unique string (e.g. the file URL). The problem is worse for nativeID
>  because this cannot be done - the mgf version of the spectrum and the
>  mzML version of the spectrum are fundamentally different (possibly
>  even have different precisions) so they need different identifiers.
>  If we re-use the native identifier this implies the input to the
>  search engine was the mgf file, which was not the case...
>
>  Cheers Andy
>
>
>
> > -----Original Message----- From: Matthew Chambers
> > [mailto:mat...@va...] Sent: 01 December 2008
> > 16:03 To: psi...@li... Subject: Re:
> > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >
> > The nativeID is intended to refer to the closest-to-native format
> > that can be interpreted by the machine. In your pipeline, the mgf
> > is the closest-to-native format, so yes that nativeID would and
> > should be preserved throughout the pipeline.  Your database use
> > case cannot use mzML ids because xsd:IDs are unique within a file,
> > not across files. You do not have any kind of guarantee that your
> > ids will be distinct between two mzML files, not to mention the
> > fact that non-mzML files don't even HAVE an id. Consider the
> > pipeline: mgf --> SearchEngine --> analysisXML What do you use for
> > spectrumID? :)
> >
> > -Matt
> >
> >
> > Jones, Andy wrote:
> >> Hi Matt,
> >>
> >> Consider the following pipeline mgf --> mzML --> SearchEngine -->
> >>  analysisXML
> >>
> >> Having thought about this some more, I'm fairly sure that we want
> >> to reference the ID attribute rather than nativeID. The nativeID
> >> is intended to identify the source spectrum prior to conversion
> >> to mzML format i.e. it does not strictly identify the data
> >> represented in the file. The input to analysisXML is the
> >> mzML-formatted spectrum, not the source mgf file. If we reference
> >> the nativeID, this implies that the input to the SearchEngine was
> >> the mgf representation of the spectrum. It's a minor point that
> >> makes no difference for most XML implementations but the mgf
> >> formatted spectrum and the mzML formatted spectrum are different
> >> objects. If a database implements this, it will be much simpler
> >> to have a chain of inputs and outputs with distinct IDs,
> >> reflecting the processing that has happened at each stage. From a
> >> database/LIMS or file tracking point of view, this could be
> >> significant I think.
> >>
> >> Cheers Andy
> >>> -----Original Message----- From: Matt Chambers
> >>> [mailto:mat...@va...] Sent: 01 December 2008
> >>>  14:23 To: psi...@li... Subject: Re:
> >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >>>
> >>> Jones, Andy wrote:
> >>>> Hi all,
> >>>>
> >>>> The issues list is getting a bit messy with essentially a
> >>>> mailing list discussion so I'll shift the discussion back
> >>>> here :-)
> >>>>
> >>>> There are two points up for discussion.
> >>>>
> >>>> 1) Use of identifiers for input spectra 2) CV terms shared
> >>>> between psi-ms and psi-pi
> >>>>
> >>>> In terms of 1) I've worked through Matt's argument and I'm in
> >>>>  general agreement that we would like to use the same system
> >>>> for identifying the input spectrum - these CV terms have only
> >>>> been added relatively recently. I did not realise that the
> >>>> nativeID attribute had been specified to this level, since
> >>>> there is no documentation about this is in the XSD or mzML
> >>>> specification document.
> >>>>
> >>>> I don't think we should change the name of the attribute
> >>>> though, since nativeID makes sense for an element called
> >>>> <Spectrum> in mzML but not for an element
> >>>> <SpectrumIdentificationResult> in analysisXML. For
> >>>> referencing mzML spectra, I'm still not sure which attribute
> >>>> we should choose to reference since the "true" (and
> >>>> guaranteed unique) spectrum identifier in mzML is actually
> >>>> the ID attribute. I can envisage a case where instruments
> >>>> output mzML directly and the nativeID is not implemented
> >>>> sensibly. The xs:ID datatype on "ID" guarantees that these
> >>>> will always be unique whatever changes happen to
> >>>> documentation in the future or whatever tools are used to
> >>>> create the file.
> >>> I contest the term "guaranteed unique" since the one doing the
> >>> guaranteeing is the schema and there is no guarantee that
> >>> somebody runs their output through a schema validator. :) If
> >>> you take the validation step to the semantic validator (which
> >>> is what the standard demands), the nativeID term is also
> >>> guaranteed to be unique (and must be "implemented sensibly"),
> >>> and as David suggested earlier, it should be possible to add a
> >>> uniqueness constraint to the nativeID attribute in the schema
> >>> even though it is xsd:string (but uniqueness is not so helpful
> >>> when the actual form of a Thermo RAW id must be:
> >>> "controller=xsd:positiveInteger scan=xsd:nonZeroInteger"). The
> >>> name of the attribute doesn't bother me, but I don't understand
> >>> your reasoning for not changing it. :)
> >>>
> >>>
> >>>> So I agree with Matt but I don't want to change the schema
> >>>> :-) I'm happy to add something to the documentation
> >>>> specifying how different identifiers should be implemented,
> >>>> following the rules in the psi-ms CV.
> >>> If the attribute name doesn't change, only the xsd
> >>> documentation needs to be updated to reflect which attribute
> >>> the spectrumID points to and that it can be used even if the
> >>> input spectra file is not mzML!
> >>>
> >>>
> >>>> In terms of 2), we had made a decision in the past that we
> >>>> would simply create terms as we need them in PSI-PI, rather
> >>>> than worrying if they should be common between psi-ms and
> >>>> psi-pi and trying to coordinate updates across groups. If a
> >>>> term is present in psi-ms with the exact meaning that we want
> >>>> (taking into account its position in the hierarchy), I think
> >>>> we should just use it and update the mapping file to
> >>>> reference it. Are there many terms from psi-ms that we want
> >>>> to use?
> >>> It's looking like scan time (aka retention time) will be useful
> >>> in analysisXML as an "alternative identifier" for the special
> >>> use case of converting existing search results to analysisXML
> >>> where a reliable nativeID to the original vendor format has
> >>> been lost. Presumably, even in this use case a nativeID could
> >>> be provided to point back to a spectrum in the search engine's
> >>> immediate spectra input file (i.e. MGF).  If not even that is
> >>> possible, either spectrumID has to be optional or the use case
> >>> is rather suspect. :)
> >>>
> >>>
> >>> Additionally, if your "spectrumID" attribute matches the
> >>> "nativeID" attribute in mzML, the mapping file must require one
> >>> of the nativeID format terms in the file header: the specific
> >>> place is TBD in analysisXML, in mzML it's mapped to the
> >>> fileDescription element. Remember, nativeID is always available
> >>> from any input spectra file, so there's no problem requiring it
> >>> as long as decent references to the input spectra are
> >>> maintained.
> >>>
> >>> The scan time as an "alternative identifier" issue makes me
> >>> wonder if a "scan time native spectrum identifier" term is
> >>> called for. It still wouldn't solve all of the problems with
> >>> David's use case (i.e. if the MGF was missing RTINSECONDS
> >>> attributes), but it seems potentially useful.
> >>>
> >>> -Matt
> >>>
> >>>
> >>>> I am working on the spec document today and would like to get
> >>>> all issues tidied up ASAP... Cheers Andy
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message----- From:
> >>>>> cod...@go...
> >>>>> [mailto:cod...@go...] Sent: 30 November 2008
> >>>>>  19:36 To: psi...@li... Subject:
> >>>>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >>>>>
> >>>>>
> >>>>> Comment #56 on issue 42 by matthew....@vanderbilt.edu:
> >>>>> Issues with the CV
> >>>>> http://code.google.com/p/psi-pi/issues/detail?id=42
> >>>>>
> >>>>>
> >>>>> Yes, I was at that meeting too. :) The one (important, IMO)
> >>>>> use case we did not consider at that time is output of
> >>>>> analysisXML without a corresponding mzML document. In such
> >>>>> a case, the mzML arbitrary id does not exist, but the
> >>>>> nativeID does. This fact convinces me that nativeID is a
> >>>>> better reference than the arbitrary id.
> >>>>>
> >>>>> The change of attribute name to nativeID is not so
> >>>>> critical, but I think the risk of confusing the spectrumID
> >>>>> with the id attribute when it actually points to the
> >>>>> nativeID attribute is worse than the risk of confusing the
> >>>>> nativeID attribute with some property of the search engine.
> >>>>> I think the documentation for the nativeID attribute can
> >>>>> easily make it clear what it's supposed to reference,
> >>>>> especially since it's on a spectrum-centric element; you
> >>>>> can copy it from the mzML schema (although I think this
> >>>>> documentation could be improved upon):
> >>>>> <xs:documentation>The native identifier for the spectrum,
> >>>>> used by the acquisition software.</xs:documentation>
> >>>>>
> >>>>> It's good to know about the header information. The
> >>>>> nativeID (or whatever it's called in analysisXML) format
> >>>>> term would go in the spectra input definition as a CV Param
> >>>>> required by the mapping file.
> >
> > -------------------------------------------------------------------------
> >  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-pi-dev
> > mailing list Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>  -------------------------------------------------------------------------
>  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-pi-dev mailing
>  list Psi...@li...
>  https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>


-------------------------------------------------------------------------
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-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

[Psidev-pi-dev] Issue 44 in psi-pi: Issues with all instance docs

[<cod...@go...>]

Comment #3 on issue 44 by dcreasy: Issues with all instance docs
http://code.google.com/p/psi-pi/issues/detail?id=44

Move rank from being a CV item to an attribute

Remove:
id: PI:00327
name: peptide rank
id: PI:00216
name: sequest:PeptideRank


-- 
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

Re: [Psidev-pi-dev] FW: Spec doc

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Andy,<br>
<br>
Some minor changes:<br>
<pre>From:
&lt;pf:Person id="PERSON_DOC_OWNER" firstName="" lastName="Some Person" email=<a class="moz-txt-link-rfc2396E" href="mailto:so...@so...">"so...@so..."</a>&gt;
to:
&lt;pf:Person id="PERSON_DOC_OWNER" firstName="Some" lastName="Person" email=<a class="moz-txt-link-rfc2396E" href="mailto:so...@so...">"so...@so..."</a>&gt;


Example Context: 	
&lt;pf:cv id="PSI-PI"        fullName="PSI-PI"        URI=<a class="moz-txt-link-rfc2396E" href="http://www.psidev.info/not_sure_of_url_to_cv.obo">"http://www.psidev.info/not_sure_of_url_to_cv.obo"</a>&gt;&lt;/pf:cv&gt;
We only want the cv psidev.info when we finally release. Guess it's OK to leave this as it is at the moment.


Element &lt;AnalysisSoftware&gt;
Definition: 	A data set containing spectra data (consisting of one or more spectra). 
Definition looks like a copy and paste of something quite different!


Element &lt;pf:ContactRole&gt;
Definition: 	The Contact that provided the document instance. 
We use the contact role in several different places. Definition needs to be a bit more general? 
In the example it is for a software vendor.



Element &lt;pf:Person&gt;
Example needs filling out a bit with some fictitious person.


Element &lt;Peptide&gt;
sequenceMass xsd:double - The sum of the unmodified (poly)peptide sequence residues, exclusive of the termini masses in Daltons.
</pre>
Oh dear. Some of the examples are inclusive of the termini masses and
any modifications, others are not. In theory, it's possible to
calculate the mass given the modification delta and the CTermGain="OH"
NTermGain="H" from the enzyme. However, that's not trivial in a case of
multiple enzymes. I'd suggest we change the definition to include the
termini and mods. Martin (whose examples followed the documentation) 
may think differently?<br>
<br>
<br>
Element &lt;Inputs&gt;<br>
Definition:     The inputs to the analyses including the databases
searched and the spectral data <br>
The example shows the input file to the process that created the
analysisXML document (the Mascot .dat file)<br>
The global definition needs changing. Also, need to add a definition
for SpectraData.<br>
<br>
<br>
Element &lt;DatabaseTranslation&gt;<br>
Could take examples from Mascot_NA_example.axml<br>
<br>
<br>
Element &lt;Enzyme&gt;<br>
missedCleavages    xsd:int    optional    URI of the analysis software
e.g. manufacturer's website<br>
semiSpecific - shouldn't this be a boolean?<br>
<br>
<br>
Element &lt;PlusValue&gt;<br>
unitName    xsd:string    -    The name of the unit.<br>
Shame that it doesn't pull out the allowed CV from the mapping file:<br>
<br>
&lt;CvTerm termAccession="UO:0000221" useTermName="false"
useTerm="true" termName="dalton" cvIdentifierRef="UO" /&gt;<br>
&lt;CvTerm termAccession="UO:0000166" useTermName="false"
useTerm="false" termName="parts per notation" cvIdentifierRef="UO" /&gt;<br>
<br>
Element &lt;SpectrumIdentificationItem&gt;<br>
Has an attribute of rank and also a CV item. From the minutes here:<br>
<a class="moz-txt-link-freetext" href="http://psidev.info/index.php?q=node/380">http://psidev.info/index.php?q=node/380</a><br>
Looks as though we agreed it should be an attribute and removed from
the CV<br>
<br>
Cheers,<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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@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:496381059;
	mso-list-type:hybrid;
	mso-list-template-ids:-2021216302 -1877068598 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	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"><span style="color: rgb(31, 73, 125);">Hi all,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Eric has
re-generated the schema
documentation for us. This is getting fairly close to a version I can
cut and
paste into the spec doc. Let me know if you have any comments,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Cheers<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch
[<a class="moz-txt-link-freetext" href="mailto:ede...@sy...">mailto:ede...@sy...</a>] <br>
  <b>Sent:</b> 01 December 2008 09:23<br>
  <b>To:</b> Jones, Andy<br>
  <b>Cc:</b> 'Eric Deutsch'<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc<o:p></o:p></span></p>
  </div>
  </div>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi Andy, sorry for the delay, US holiday over here. You
will find
updated HTML documentation at:<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html">http://www.peptideatlas.org/tmp/AnalysisXML_working.html</a><o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">A version that is suitable
for cut-n-paste
into a word doc is at:</span><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html">http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html</a><o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">I fixed some of the problems.
The main
problem I still know about is that in the subelement listing, any
subelements
that are double-tall nested substitution grouped elements do not have
their
definition visible. If one clicks on the subelement, the main element
does have
a definition. So it’s there, but my program is stymied by the various
levels.
This is fixable, but probably not before submission.<o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">If you send me screen-capture
images to
embed in some elements, that can be done if you like.<o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">If there are still other
outstanding
issues, please let me know<o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">Regards,<o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US">Eric<o:p></o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy [<a class="moz-txt-link-freetext" href="mailto:And...@li...">mailto:And...@li...</a>]
  <br>
  <b>Sent:</b> Thursday, November 27, 2008 4:56 AM<br>
  <b>To:</b> Eric Deutsch<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US"><o:p></o:p></span></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi Eric,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Any
chance you could look at the
generated documentation this week? We’re aiming to submit the specs to
the document
process by Monday...<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Thanks<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch
[<a class="moz-txt-link-freetext" href="mailto:ede...@sy...">mailto:ede...@sy...</a>] <br>
  <b>Sent:</b> 21 November 2008 17:44<br>
  <b>To:</b> Jones, Andy<br>
  <b>Cc:</b> 'Eric Deutsch'<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc<o:p></o:p></span></p>
  </div>
  </div>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi Andy, yes, I will fix the bugs and regenerate the docs
from the
latest schema and files early next week.<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">I will also have a look at TPP related materials for
AnalysisXML
and get back to you.<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Sorry I’ve missed the calls. That time is very awkward
for me and
I’ve occasionally been confused by Wednesday/Thursday switches.<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Regards,<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Eric<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy
[<a class="moz-txt-link-freetext" href="mailto:And...@li...">mailto:And...@li...</a>] <br>
  <b>Sent:</b> Friday, November 21, 2008 2:09 AM<br>
  <b>To:</b> Eric Deutsch<br>
  <b>Subject:</b> RE: [Psidev-pi-dev] Spec doc</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US"><o:p></o:p></span></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Hi Eric,<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Would you
be able to do a couple
of updates to the auto-generated docs? There’s a couple of errors to
fix.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">When
there is an instance of:
&lt;xsd:element ref="pf:DatabaseReference"
minOccurs="0"&gt;, would you be able to retrieve the documentation in
the table from the referenced element.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Also,
when an element is
inherited from, documentation for inherited attributes does not appear
in the
table (e.g. see Specificity rule, no docs for cvRef, unitName etc.) –
unless we
were missing documentation for these attributes when it was last
generated?.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">There are
also a few instances
of elements imported from the FuGE-light schema which are completely
empty, no
attributes or documentation e.g. Organization or Person.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">We’re
aiming to submit the specs
to the PSI process by the end of month (i.e. a week on Monday), so if
you would
be able to look at this fairly soon it would be very much appreciated!
Also,
any chance that you can get someone to generate the TPP and SpectraST
examples
at your end. It’s no disaster if we submit to the process without these
but it
would be beneficial.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Cheers<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">Andy<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div
 style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Eric Deutsch
[<a class="moz-txt-link-freetext" href="mailto:ede...@sy...">mailto:ede...@sy...</a>] <br>
  <b>Sent:</b> 17 October 2008 07:43<br>
  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> Re: [Psidev-pi-dev] Spec doc<o:p></o:p></span></p>
  </div>
  </div>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US">Hi everyone, I updated the current draft of the on-line
autogenerated schema docs to the latest svn. The result is at:<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html">http://www.peptideatlas.org/tmp/AnalysisXML_working.html</a><o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">It
looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml
file the
mapping information for SearchType and it seemed to pull it out of the
CV
nicely:<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><a moz-do-not-send="true"
 href="http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType">http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType</a><o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">The
autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to
automatically
pull examples out of?<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">Regards,<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">Eric<o:p></o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal"><span
 style="font-size: 10pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: navy;"
 lang="EN-US"><o:p> </o:p></span></p>
  <div
 style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
  <div>
  <div class="MsoNormal" style="text-align: center;" align="center"><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US">
  <hr align="center" size="2" width="100%"></span></div>
  <p class="MsoNormal"><b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US">From:</span></b><span
 style="font-size: 10pt; font-family: &quot;Tahoma&quot;,&quot;sans-serif&quot;;"
 lang="EN-US"> Jones, Andy
[<a class="moz-txt-link-freetext" href="mailto:And...@li...">mailto:And...@li...</a>] <br>
  <b>Sent:</b> Monday, October 13, 2008 7:07 AM<br>
  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a><br>
  <b>Subject:</b> [Psidev-pi-dev] Spec doc</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;,&quot;serif&quot;;"
 lang="EN-US"><o:p></o:p></span></p>
  </div>
  <p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
  <p class="MsoNormal">Hi all,<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">A new version of the spec document has been
uploaded by SVN
(in the specification_document directory), and previous versions have
been put
in a subfolder. I think the document is getting there... <o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">Main tasks still to do:<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->Finish section on use cases when we have
finally agreed
the list online and made all the example files.<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->Import some parts of the example files to
demonstrate a
few specific points<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->Import the autogenerated documentation<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">Before we can submit, the main outstanding
issues are:<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->CV - looking through the CV there is
still a fair bit
of work to do, there’s quite a few terms with missing or incorrect
documentation<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->Mapping file<o:p></o:p></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">         
  </span></span><!--[endif]-->Finish example files.<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">Prior to the call on Thurs, can we have a think
about how we
plan to get the CV into shape and discuss it as a main agenda item...<o:p></o:p></p>
  <p class="MsoNormal"><o:p> </o:p></p>
  <p class="MsoNormal">Also new schema uploaded with a few bits of
improved
documentation.<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" style="margin-left: 18pt;"><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>
  </div>
  </div>
  </div>
  </div>
  </div>
  </div>
  <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 &amp; 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&amp;url=/</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>

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

As you say, the file URL in the analysisXML header must be combined with 
the spectrum identifier to link back to the input spectrum. The nativeID 
works no matter what the format of the input file was. The mzML id only 
works for mzML input. Consider the following chain of input file processing:
file:///raw/source1.raw
file:///processed/source1.mzXML
file:///searched/source1.analysisXML

The analysisXML header would point to file:///processed/source1.mzXML as 
the input file and would use mzXML's nativeID, which is: 
"scan=xsd:nonNegativeInteger"

Now substitute mzML instead of mzXML. The nativeID can now use the true 
native format for thermo RAW: "controller=xsd:nonNegativeInteger 
scan=xsd:positiveInteger"

There is no difference in file tracking, it's only the fidelity of the 
nativeID that has improved. The nativeID works transparently in mzML: if 
the analysisXML header points to an mzML and uses the nativeID, that's 
just as effective at finding a spectrum as the arbitrary id. It just so 
happens that the preserved nativeID format allows machines to easily 
look up the spectrum in the raw data as well as the processed data 
despite the fact that - as you say - they're different "objects." As 
long as your database maintains both a processing prefix/URL as well as 
the nativeID, it'll be golden.


>  If we re-use the native identifier this implies the input to the
>  search engine was the mgf file, which was not the case...
As above, you must maintain the an identifier to the file that the 
spectrum identifier pertains to - which explicitly says what the input 
to the search was. What implication is possible given that information?

-Matt


Jones, Andy wrote:
>  Hi Matt,
>
>  It's a question of identifying objects as they are traced throughout
>  a process. In AnalysisXML we are not representing the spectrum
>  object, we are making an explicit reference to the spectrum as it is
>  represented in mzML. The nativeID is preserved, since it is
>  referenced as the input to the process that converts mgf to mzML.
>
> > HAVE an id. Consider the pipeline: mgf --> SearchEngine -->
> > analysisXML What do you use for spectrumID? :)
>
>  In this case, we use the identifier as specified by the "native ID"
>  system you've defined because the input to the search was the mgf
>  spectrum object. I agree that this system looks good and we will use
>  it for each of the vendor-specific formats - in effect I want to add
>  one more mapping for mzML, mapping to the mzML ID ;-) Remember, we're
>  not trying to represent the spectrum in analysisXML, all we are
>  saying is what spectrum did the search engine take as input.
>
>  I view the conversion of an mgf spectrum to an mzML spectrum as a
>  process that has changed the spectrum object. As such, the nativeID
>  in mzML references the input to the conversion process and the mzML
>  ID attribute references the (output) spectrum as it is in the file.
>  Correct use of the identifiers maintains this trace.
>
> > Your database use case cannot use mzML ids because xsd:IDs are
> > unique within a file, not across files.
>
>  This is true but is solved easily by prefixing all identifiers with a
>  unique string (e.g. the file URL). The problem is worse for nativeID
>  because this cannot be done - the mgf version of the spectrum and the
>  mzML version of the spectrum are fundamentally different (possibly
>  even have different precisions) so they need different identifiers.
>  If we re-use the native identifier this implies the input to the
>  search engine was the mgf file, which was not the case...
>
>  Cheers Andy
>
>
>
> > -----Original Message----- From: Matthew Chambers
> > [mailto:mat...@va...] Sent: 01 December 2008
> > 16:03 To: psi...@li... Subject: Re:
> > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >
> > The nativeID is intended to refer to the closest-to-native format
> > that can be interpreted by the machine. In your pipeline, the mgf
> > is the closest-to-native format, so yes that nativeID would and
> > should be preserved throughout the pipeline.  Your database use
> > case cannot use mzML ids because xsd:IDs are unique within a file,
> > not across files. You do not have any kind of guarantee that your
> > ids will be distinct between two mzML files, not to mention the
> > fact that non-mzML files don't even HAVE an id. Consider the
> > pipeline: mgf --> SearchEngine --> analysisXML What do you use for
> > spectrumID? :)
> >
> > -Matt
> >
> >
> > Jones, Andy wrote:
> >> Hi Matt,
> >>
> >> Consider the following pipeline mgf --> mzML --> SearchEngine -->
> >>  analysisXML
> >>
> >> Having thought about this some more, I'm fairly sure that we want
> >> to reference the ID attribute rather than nativeID. The nativeID
> >> is intended to identify the source spectrum prior to conversion
> >> to mzML format i.e. it does not strictly identify the data
> >> represented in the file. The input to analysisXML is the
> >> mzML-formatted spectrum, not the source mgf file. If we reference
> >> the nativeID, this implies that the input to the SearchEngine was
> >> the mgf representation of the spectrum. It's a minor point that
> >> makes no difference for most XML implementations but the mgf
> >> formatted spectrum and the mzML formatted spectrum are different
> >> objects. If a database implements this, it will be much simpler
> >> to have a chain of inputs and outputs with distinct IDs,
> >> reflecting the processing that has happened at each stage. From a
> >> database/LIMS or file tracking point of view, this could be
> >> significant I think.
> >>
> >> Cheers Andy
> >>> -----Original Message----- From: Matt Chambers
> >>> [mailto:mat...@va...] Sent: 01 December 2008
> >>>  14:23 To: psi...@li... Subject: Re:
> >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >>>
> >>> Jones, Andy wrote:
> >>>> Hi all,
> >>>>
> >>>> The issues list is getting a bit messy with essentially a
> >>>> mailing list discussion so I'll shift the discussion back
> >>>> here :-)
> >>>>
> >>>> There are two points up for discussion.
> >>>>
> >>>> 1) Use of identifiers for input spectra 2) CV terms shared
> >>>> between psi-ms and psi-pi
> >>>>
> >>>> In terms of 1) I've worked through Matt's argument and I'm in
> >>>>  general agreement that we would like to use the same system
> >>>> for identifying the input spectrum - these CV terms have only
> >>>> been added relatively recently. I did not realise that the
> >>>> nativeID attribute had been specified to this level, since
> >>>> there is no documentation about this is in the XSD or mzML
> >>>> specification document.
> >>>>
> >>>> I don't think we should change the name of the attribute
> >>>> though, since nativeID makes sense for an element called
> >>>> <Spectrum> in mzML but not for an element
> >>>> <SpectrumIdentificationResult> in analysisXML. For
> >>>> referencing mzML spectra, I'm still not sure which attribute
> >>>> we should choose to reference since the "true" (and
> >>>> guaranteed unique) spectrum identifier in mzML is actually
> >>>> the ID attribute. I can envisage a case where instruments
> >>>> output mzML directly and the nativeID is not implemented
> >>>> sensibly. The xs:ID datatype on "ID" guarantees that these
> >>>> will always be unique whatever changes happen to
> >>>> documentation in the future or whatever tools are used to
> >>>> create the file.
> >>> I contest the term "guaranteed unique" since the one doing the
> >>> guaranteeing is the schema and there is no guarantee that
> >>> somebody runs their output through a schema validator. :) If
> >>> you take the validation step to the semantic validator (which
> >>> is what the standard demands), the nativeID term is also
> >>> guaranteed to be unique (and must be "implemented sensibly"),
> >>> and as David suggested earlier, it should be possible to add a
> >>> uniqueness constraint to the nativeID attribute in the schema
> >>> even though it is xsd:string (but uniqueness is not so helpful
> >>> when the actual form of a Thermo RAW id must be:
> >>> "controller=xsd:positiveInteger scan=xsd:nonZeroInteger"). The
> >>> name of the attribute doesn't bother me, but I don't understand
> >>> your reasoning for not changing it. :)
> >>>
> >>>
> >>>> So I agree with Matt but I don't want to change the schema
> >>>> :-) I'm happy to add something to the documentation
> >>>> specifying how different identifiers should be implemented,
> >>>> following the rules in the psi-ms CV.
> >>> If the attribute name doesn't change, only the xsd
> >>> documentation needs to be updated to reflect which attribute
> >>> the spectrumID points to and that it can be used even if the
> >>> input spectra file is not mzML!
> >>>
> >>>
> >>>> In terms of 2), we had made a decision in the past that we
> >>>> would simply create terms as we need them in PSI-PI, rather
> >>>> than worrying if they should be common between psi-ms and
> >>>> psi-pi and trying to coordinate updates across groups. If a
> >>>> term is present in psi-ms with the exact meaning that we want
> >>>> (taking into account its position in the hierarchy), I think
> >>>> we should just use it and update the mapping file to
> >>>> reference it. Are there many terms from psi-ms that we want
> >>>> to use?
> >>> It's looking like scan time (aka retention time) will be useful
> >>> in analysisXML as an "alternative identifier" for the special
> >>> use case of converting existing search results to analysisXML
> >>> where a reliable nativeID to the original vendor format has
> >>> been lost. Presumably, even in this use case a nativeID could
> >>> be provided to point back to a spectrum in the search engine's
> >>> immediate spectra input file (i.e. MGF).  If not even that is
> >>> possible, either spectrumID has to be optional or the use case
> >>> is rather suspect. :)
> >>>
> >>>
> >>> Additionally, if your "spectrumID" attribute matches the
> >>> "nativeID" attribute in mzML, the mapping file must require one
> >>> of the nativeID format terms in the file header: the specific
> >>> place is TBD in analysisXML, in mzML it's mapped to the
> >>> fileDescription element. Remember, nativeID is always available
> >>> from any input spectra file, so there's no problem requiring it
> >>> as long as decent references to the input spectra are
> >>> maintained.
> >>>
> >>> The scan time as an "alternative identifier" issue makes me
> >>> wonder if a "scan time native spectrum identifier" term is
> >>> called for. It still wouldn't solve all of the problems with
> >>> David's use case (i.e. if the MGF was missing RTINSECONDS
> >>> attributes), but it seems potentially useful.
> >>>
> >>> -Matt
> >>>
> >>>
> >>>> I am working on the spec document today and would like to get
> >>>> all issues tidied up ASAP... Cheers Andy
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message----- From:
> >>>>> cod...@go...
> >>>>> [mailto:cod...@go...] Sent: 30 November 2008
> >>>>>  19:36 To: psi...@li... Subject:
> >>>>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >>>>>
> >>>>>
> >>>>> Comment #56 on issue 42 by matthew....@vanderbilt.edu:
> >>>>> Issues with the CV
> >>>>> http://code.google.com/p/psi-pi/issues/detail?id=42
> >>>>>
> >>>>>
> >>>>> Yes, I was at that meeting too. :) The one (important, IMO)
> >>>>> use case we did not consider at that time is output of
> >>>>> analysisXML without a corresponding mzML document. In such
> >>>>> a case, the mzML arbitrary id does not exist, but the
> >>>>> nativeID does. This fact convinces me that nativeID is a
> >>>>> better reference than the arbitrary id.
> >>>>>
> >>>>> The change of attribute name to nativeID is not so
> >>>>> critical, but I think the risk of confusing the spectrumID
> >>>>> with the id attribute when it actually points to the
> >>>>> nativeID attribute is worse than the risk of confusing the
> >>>>> nativeID attribute with some property of the search engine.
> >>>>> I think the documentation for the nativeID attribute can
> >>>>> easily make it clear what it's supposed to reference,
> >>>>> especially since it's on a spectrum-centric element; you
> >>>>> can copy it from the mzML schema (although I think this
> >>>>> documentation could be improved upon):
> >>>>> <xs:documentation>The native identifier for the spectrum,
> >>>>> used by the acquisition software.</xs:documentation>
> >>>>>
> >>>>> It's good to know about the header information. The
> >>>>> nativeID (or whatever it's called in analysisXML) format
> >>>>> term would go in the spectra input definition as a CV Param
> >>>>> required by the mapping file.
> >
> > -------------------------------------------------------------------------
> >  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-pi-dev
> > mailing list Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>  -------------------------------------------------------------------------
>  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-pi-dev mailing
>  list Psi...@li...
>  https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[Jones, A. <And...@li...>]

Hi Matt,

It's a question of identifying objects as they are traced throughout a process.
In AnalysisXML we are not representing the spectrum object, we are making an
explicit reference to the spectrum as it is represented in mzML. The nativeID is
preserved, since it is referenced as the input to the process that converts mgf
to mzML. 

> HAVE an id. Consider the pipeline: mgf --> SearchEngine --> analysisXML
> What do you use for spectrumID? :)

In this case, we use the identifier as specified by the "native ID" system
you've defined because the input to the search was the mgf spectrum object. I
agree that this system looks good and we will use it for each of the
vendor-specific formats - in effect I want to add one more mapping for mzML,
mapping to the mzML ID ;-) Remember, we're not trying to represent the spectrum
in analysisXML, all we are saying is what spectrum did the search engine take as
input. 

I view the conversion of an mgf spectrum to an mzML spectrum as a process that
has changed the spectrum object. As such, the nativeID in mzML references the
input to the conversion process and the mzML ID attribute references the
(output) spectrum as it is in the file. Correct use of the identifiers maintains
this trace.

> Your database use case cannot use
> mzML ids because xsd:IDs are unique within a file, not across files.

This is true but is solved easily by prefixing all identifiers with a unique
string (e.g. the file URL). The problem is worse for nativeID because this
cannot be done - the mgf version of the spectrum and the mzML version of the
spectrum are fundamentally different (possibly even have different precisions)
so they need different identifiers. If we re-use the native identifier this
implies the input to the search engine was the mgf file, which was not the
case...

Cheers
Andy



> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: 01 December 2008 16:03
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> 
> The nativeID is intended to refer to the closest-to-native format that
> can be interpreted by the machine. In your pipeline, the mgf is the
> closest-to-native format, so yes that nativeID would and should be
> preserved throughout the pipeline.  Your database use case cannot use
> mzML ids because xsd:IDs are unique within a file, not across files. You
> do not have any kind of guarantee that your ids will be distinct between
> two mzML files, not to mention the fact that non-mzML files don't even
> HAVE an id. Consider the pipeline: mgf --> SearchEngine --> analysisXML
> What do you use for spectrumID? :)
> 
> -Matt
> 
> 
> Jones, Andy wrote:
> >  Hi Matt,
> >
> >  Consider the following pipeline mgf --> mzML --> SearchEngine -->
> >  analysisXML
> >
> >  Having thought about this some more, I'm fairly sure that we want to
> >  reference the ID attribute rather than nativeID. The nativeID is
> >  intended to identify the source spectrum prior to conversion to mzML
> >  format i.e. it does not strictly identify the data represented in the
> >  file. The input to analysisXML is the mzML-formatted spectrum, not
> >  the source mgf file. If we reference the nativeID, this implies that
> >  the input to the SearchEngine was the mgf representation of the
> >  spectrum. It's a minor point that makes no difference for most XML
> >  implementations but the mgf formatted spectrum and the mzML formatted
> >  spectrum are different objects. If a database implements this, it
> >  will be much simpler to have a chain of inputs and outputs with
> >  distinct IDs, reflecting the processing that has happened at each
> >  stage. From a database/LIMS or file tracking point of view, this
> >  could be significant I think.
> >
> >  Cheers Andy
> > > -----Original Message----- From: Matt Chambers
> > > [mailto:mat...@va...] Sent: 01 December 2008
> > > 14:23 To: psi...@li... Subject: Re:
> > > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > >
> > > Jones, Andy wrote:
> > >> Hi all,
> > >>
> > >> The issues list is getting a bit messy with essentially a mailing
> > >>  list discussion so I'll shift the discussion back here :-)
> > >>
> > >> There are two points up for discussion.
> > >>
> > >> 1) Use of identifiers for input spectra 2) CV terms shared
> > >> between psi-ms and psi-pi
> > >>
> > >> In terms of 1) I've worked through Matt's argument and I'm in
> > >> general agreement that we would like to use the same system for
> > >> identifying the input spectrum - these CV terms have only been
> > >> added relatively recently. I did not realise that the nativeID
> > >> attribute had been specified to this level, since there is no
> > >> documentation about this is in the XSD or mzML specification
> > >> document.
> > >>
> > >> I don't think we should change the name of the attribute though,
> > >> since nativeID makes sense for an element called <Spectrum> in
> > >> mzML but not for an element <SpectrumIdentificationResult> in
> > >> analysisXML. For referencing mzML spectra, I'm still not sure
> > >> which attribute we should choose to reference since the "true"
> > >> (and guaranteed unique) spectrum identifier in mzML is actually
> > >> the ID attribute. I can envisage a case where instruments output
> > >> mzML directly and the nativeID is not implemented sensibly. The
> > >> xs:ID datatype on "ID" guarantees that these will always be
> > >> unique whatever changes happen to documentation in the future or
> > >> whatever tools are used to create the file.
> > > I contest the term "guaranteed unique" since the one doing the
> > > guaranteeing is the schema and there is no guarantee that somebody
> > > runs their output through a schema validator. :) If you take the
> > > validation step to the semantic validator (which is what the
> > > standard demands), the nativeID term is also guaranteed to be
> > > unique (and must be "implemented sensibly"), and as David suggested
> > > earlier, it should be possible to add a uniqueness constraint to
> > > the nativeID attribute in the schema even though it is xsd:string
> > > (but uniqueness is not so helpful when the actual form of a Thermo
> > > RAW id must be: "controller=xsd:positiveInteger
> > > scan=xsd:nonZeroInteger"). The name of the attribute doesn't bother
> > > me, but I don't understand your reasoning for not changing it. :)
> > >
> > >
> > >> So I agree with Matt but I don't want to change the schema :-)
> > >> I'm happy to add something to the documentation specifying how
> > >> different identifiers should be implemented, following the rules
> > >> in the psi-ms CV.
> > > If the attribute name doesn't change, only the xsd documentation
> > > needs to be updated to reflect which attribute the spectrumID
> > > points to and that it can be used even if the input spectra file is
> > > not mzML!
> > >
> > >
> > >> In terms of 2), we had made a decision in the past that we would
> > >> simply create terms as we need them in PSI-PI, rather than
> > >> worrying if they should be common between psi-ms and psi-pi and
> > >> trying to coordinate updates across groups. If a term is present
> > >> in psi-ms with the exact meaning that we want (taking into
> > >> account its position in the hierarchy), I think we should just
> > >> use it and update the mapping file to reference it. Are there
> > >> many terms from psi-ms that we want to use?
> > > It's looking like scan time (aka retention time) will be useful in
> > > analysisXML as an "alternative identifier" for the special use case
> > > of converting existing search results to analysisXML where a
> > > reliable nativeID to the original vendor format has been lost.
> > > Presumably, even in this use case a nativeID could be provided to
> > > point back to a spectrum in the search engine's immediate spectra
> > > input file (i.e. MGF).  If not even that is possible, either
> > > spectrumID has to be optional or the use case is rather suspect. :)
> > >
> > >
> > > Additionally, if your "spectrumID" attribute matches the "nativeID"
> > >  attribute in mzML, the mapping file must require one of the
> > > nativeID format terms in the file header: the specific place is TBD
> > > in analysisXML, in mzML it's mapped to the fileDescription element.
> > >  Remember, nativeID is always available from any input spectra
> > > file, so there's no problem requiring it as long as decent
> > > references to the input spectra are maintained.
> > >
> > > The scan time as an "alternative identifier" issue makes me wonder
> > > if a "scan time native spectrum identifier" term is called for. It
> > > still wouldn't solve all of the problems with David's use case
> > > (i.e. if the MGF was missing RTINSECONDS attributes), but it seems
> > > potentially useful.
> > >
> > > -Matt
> > >
> > >
> > >> I am working on the spec document today and would like to get all
> > >>  issues tidied up ASAP... Cheers Andy
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>> -----Original Message----- From: cod...@go...
> > >>> [mailto:cod...@go...] Sent: 30 November 2008
> > >>> 19:36 To: psi...@li... Subject:
> > >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> > >>>
> > >>>
> > >>> Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues
> > >>> with the CV http://code.google.com/p/psi-pi/issues/detail?id=42
> > >>>
> > >>>
> > >>> Yes, I was at that meeting too. :) The one (important, IMO) use
> > >>>  case we did not consider at that time is output of analysisXML
> > >>>  without a corresponding mzML document. In such a case, the
> > >>> mzML arbitrary id does not exist, but the nativeID does. This
> > >>> fact convinces me that nativeID is a better reference than the
> > >>> arbitrary id.
> > >>>
> > >>> The change of attribute name to nativeID is not so critical,
> > >>> but I think the risk of confusing the spectrumID with the id
> > >>> attribute when it actually points to the nativeID attribute is
> > >>> worse than the risk of confusing the nativeID attribute with
> > >>> some property of the search engine. I think the documentation
> > >>> for the nativeID attribute can easily make it clear what it's
> > >>> supposed to reference, especially since it's on a
> > >>> spectrum-centric element; you can copy it from the mzML schema
> > >>> (although I think this documentation could be improved upon):
> > >>> <xs:documentation>The native identifier for the spectrum, used
> > >>> by the acquisition software.</xs:documentation>
> > >>>
> > >>> It's good to know about the header information. The nativeID
> > >>> (or whatever it's called in analysisXML) format term would go
> > >>> in the spectra input definition as a CV Param required by the
> > >>> mapping file.
> 
> 
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

The nativeID is intended to refer to the closest-to-native format that 
can be interpreted by the machine. In your pipeline, the mgf is the 
closest-to-native format, so yes that nativeID would and should be 
preserved throughout the pipeline.  Your database use case cannot use 
mzML ids because xsd:IDs are unique within a file, not across files. You 
do not have any kind of guarantee that your ids will be distinct between 
two mzML files, not to mention the fact that non-mzML files don't even 
HAVE an id. Consider the pipeline: mgf --> SearchEngine --> analysisXML
What do you use for spectrumID? :)

-Matt


Jones, Andy wrote:
>  Hi Matt,
>
>  Consider the following pipeline mgf --> mzML --> SearchEngine -->
>  analysisXML
>
>  Having thought about this some more, I'm fairly sure that we want to
>  reference the ID attribute rather than nativeID. The nativeID is
>  intended to identify the source spectrum prior to conversion to mzML
>  format i.e. it does not strictly identify the data represented in the
>  file. The input to analysisXML is the mzML-formatted spectrum, not
>  the source mgf file. If we reference the nativeID, this implies that
>  the input to the SearchEngine was the mgf representation of the
>  spectrum. It's a minor point that makes no difference for most XML
>  implementations but the mgf formatted spectrum and the mzML formatted
>  spectrum are different objects. If a database implements this, it
>  will be much simpler to have a chain of inputs and outputs with
>  distinct IDs, reflecting the processing that has happened at each
>  stage. From a database/LIMS or file tracking point of view, this
>  could be significant I think.
>
>  Cheers Andy
> > -----Original Message----- From: Matt Chambers
> > [mailto:mat...@va...] Sent: 01 December 2008
> > 14:23 To: psi...@li... Subject: Re:
> > [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >
> > Jones, Andy wrote:
> >> Hi all,
> >>
> >> The issues list is getting a bit messy with essentially a mailing
> >>  list discussion so I'll shift the discussion back here :-)
> >>
> >> There are two points up for discussion.
> >>
> >> 1) Use of identifiers for input spectra 2) CV terms shared
> >> between psi-ms and psi-pi
> >>
> >> In terms of 1) I've worked through Matt's argument and I'm in
> >> general agreement that we would like to use the same system for
> >> identifying the input spectrum - these CV terms have only been
> >> added relatively recently. I did not realise that the nativeID
> >> attribute had been specified to this level, since there is no
> >> documentation about this is in the XSD or mzML specification
> >> document.
> >>
> >> I don't think we should change the name of the attribute though,
> >> since nativeID makes sense for an element called <Spectrum> in
> >> mzML but not for an element <SpectrumIdentificationResult> in
> >> analysisXML. For referencing mzML spectra, I'm still not sure
> >> which attribute we should choose to reference since the "true"
> >> (and guaranteed unique) spectrum identifier in mzML is actually
> >> the ID attribute. I can envisage a case where instruments output
> >> mzML directly and the nativeID is not implemented sensibly. The
> >> xs:ID datatype on "ID" guarantees that these will always be
> >> unique whatever changes happen to documentation in the future or
> >> whatever tools are used to create the file.
> > I contest the term "guaranteed unique" since the one doing the
> > guaranteeing is the schema and there is no guarantee that somebody
> > runs their output through a schema validator. :) If you take the
> > validation step to the semantic validator (which is what the
> > standard demands), the nativeID term is also guaranteed to be
> > unique (and must be "implemented sensibly"), and as David suggested
> > earlier, it should be possible to add a uniqueness constraint to
> > the nativeID attribute in the schema even though it is xsd:string
> > (but uniqueness is not so helpful when the actual form of a Thermo
> > RAW id must be: "controller=xsd:positiveInteger
> > scan=xsd:nonZeroInteger"). The name of the attribute doesn't bother
> > me, but I don't understand your reasoning for not changing it. :)
> >
> >
> >> So I agree with Matt but I don't want to change the schema :-)
> >> I'm happy to add something to the documentation specifying how
> >> different identifiers should be implemented, following the rules
> >> in the psi-ms CV.
> > If the attribute name doesn't change, only the xsd documentation
> > needs to be updated to reflect which attribute the spectrumID
> > points to and that it can be used even if the input spectra file is
> > not mzML!
> >
> >
> >> In terms of 2), we had made a decision in the past that we would
> >> simply create terms as we need them in PSI-PI, rather than
> >> worrying if they should be common between psi-ms and psi-pi and
> >> trying to coordinate updates across groups. If a term is present
> >> in psi-ms with the exact meaning that we want (taking into
> >> account its position in the hierarchy), I think we should just
> >> use it and update the mapping file to reference it. Are there
> >> many terms from psi-ms that we want to use?
> > It's looking like scan time (aka retention time) will be useful in
> > analysisXML as an "alternative identifier" for the special use case
> > of converting existing search results to analysisXML where a
> > reliable nativeID to the original vendor format has been lost.
> > Presumably, even in this use case a nativeID could be provided to
> > point back to a spectrum in the search engine's immediate spectra
> > input file (i.e. MGF).  If not even that is possible, either
> > spectrumID has to be optional or the use case is rather suspect. :)
> >
> >
> > Additionally, if your "spectrumID" attribute matches the "nativeID"
> >  attribute in mzML, the mapping file must require one of the
> > nativeID format terms in the file header: the specific place is TBD
> > in analysisXML, in mzML it's mapped to the fileDescription element.
> >  Remember, nativeID is always available from any input spectra
> > file, so there's no problem requiring it as long as decent
> > references to the input spectra are maintained.
> >
> > The scan time as an "alternative identifier" issue makes me wonder
> > if a "scan time native spectrum identifier" term is called for. It
> > still wouldn't solve all of the problems with David's use case
> > (i.e. if the MGF was missing RTINSECONDS attributes), but it seems
> > potentially useful.
> >
> > -Matt
> >
> >
> >> I am working on the spec document today and would like to get all
> >>  issues tidied up ASAP... Cheers Andy
> >>
> >>
> >>
> >>
> >>
> >>
> >>> -----Original Message----- From: cod...@go...
> >>> [mailto:cod...@go...] Sent: 30 November 2008
> >>> 19:36 To: psi...@li... Subject:
> >>> [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> >>>
> >>>
> >>> Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues
> >>> with the CV http://code.google.com/p/psi-pi/issues/detail?id=42
> >>>
> >>>
> >>> Yes, I was at that meeting too. :) The one (important, IMO) use
> >>>  case we did not consider at that time is output of analysisXML
> >>>  without a corresponding mzML document. In such a case, the
> >>> mzML arbitrary id does not exist, but the nativeID does. This
> >>> fact convinces me that nativeID is a better reference than the
> >>> arbitrary id.
> >>>
> >>> The change of attribute name to nativeID is not so critical,
> >>> but I think the risk of confusing the spectrumID with the id
> >>> attribute when it actually points to the nativeID attribute is
> >>> worse than the risk of confusing the nativeID attribute with
> >>> some property of the search engine. I think the documentation
> >>> for the nativeID attribute can easily make it clear what it's
> >>> supposed to reference, especially since it's on a
> >>> spectrum-centric element; you can copy it from the mzML schema
> >>> (although I think this documentation could be improved upon):
> >>> <xs:documentation>The native identifier for the spectrum, used
> >>> by the acquisition software.</xs:documentation>
> >>>
> >>> It's good to know about the header information. The nativeID
> >>> (or whatever it's called in analysisXML) format term would go
> >>> in the spectra input definition as a CV Param required by the
> >>> mapping file.

[Psidev-pi-dev] FW: Spec doc

[Jones, A. <And...@li...>]

Hi all,

Eric has re-generated the schema documentation for us. This is getting fairly
close to a version I can cut and paste into the spec doc. Let me know if you
have any comments,

Cheers

Andy

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 01 December 2008 09:23
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, sorry for the delay, US holiday over here. You will find updated HTML
documentation at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

A version that is suitable for cut-n-paste into a word doc is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working_simple.html

 

I fixed some of the problems. The main problem I still know about is that in the
subelement listing, any subelements that are double-tall nested substitution
grouped elements do not have their definition visible. If one clicks on the
subelement, the main element does have a definition. So it’s there, but my
program is stymied by the various levels. This is fixable, but probably not
before submission.

 

If you send me screen-capture images to embed in some elements, that can be done
if you like.

 

If there are still other outstanding issues, please let me know

 

Regards,

Eric

 

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Thursday, November 27, 2008 4:56 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Any chance you could look at the generated documentation this week? We’re aiming
to submit the specs to the document process by Monday...

Thanks

Andy

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 21 November 2008 17:44
To: Jones, Andy
Cc: 'Eric Deutsch'
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Andy, yes, I will fix the bugs and regenerate the docs from the latest schema
and files early next week.

 

I will also have a look at TPP related materials for AnalysisXML and get back to
you.

 

Sorry I’ve missed the calls. That time is very awkward for me and I’ve
occasionally been confused by Wednesday/Thursday switches.

 

Regards,

Eric

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Friday, November 21, 2008 2:09 AM
To: Eric Deutsch
Subject: RE: [Psidev-pi-dev] Spec doc

 

Hi Eric,

 

Would you be able to do a couple of updates to the auto-generated docs? There’s
a couple of errors to fix.

 

When there is an instance of: <xsd:element ref="pf:DatabaseReference"
minOccurs="0">, would you be able to retrieve the documentation in the table
from the referenced element.

 

Also, when an element is inherited from, documentation for inherited attributes
does not appear in the table (e.g. see Specificity rule, no docs for cvRef,
unitName etc.) – unless we were missing documentation for these attributes when
it was last generated?.

 

There are also a few instances of elements imported from the FuGE-light schema
which are completely empty, no attributes or documentation e.g. Organization or
Person.

 

We’re aiming to submit the specs to the PSI process by the end of month (i.e. a
week on Monday), so if you would be able to look at this fairly soon it would be
very much appreciated! Also, any chance that you can get someone to generate the
TPP and SpectraST examples at your end. It’s no disaster if we submit to the
process without these but it would be beneficial.

 

Cheers

Andy

 

 

 

 

 

 

From: Eric Deutsch [mailto:ede...@sy...] 
Sent: 17 October 2008 07:43
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Spec doc

 

Hi everyone, I updated the current draft of the on-line autogenerated schema
docs to the latest svn. The result is at:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html

 

It looks like the current mapping file is just a template without any term
mappings themselves. Just as a test, I wrote into the axml-mapping.xml file the
mapping information for SearchType and it seemed to pull it out of the CV
nicely:

 

http://www.peptideatlas.org/tmp/AnalysisXML_working.html#SearchType

 

The autogeneration pulls examples out of one file. I randomly chose
Mascot_MSMS_example.axml. Is there a better instance document to automatically
pull examples out of?

 

Regards,

Eric

 

 

 

________________________________

From: Jones, Andy [mailto:And...@li...] 
Sent: Monday, October 13, 2008 7:07 AM
To: psi...@li...
Subject: [Psidev-pi-dev] Spec doc

 

Hi all,

 

A new version of the spec document has been uploaded by SVN (in the
specification_document directory), and previous versions have been put in a
subfolder. I think the document is getting there... 

 

Main tasks still to do:

 

-          Finish section on use cases when we have finally agreed the list
online and made all the example files.

-          Import some parts of the example files to demonstrate a few specific
points

-          Import the autogenerated documentation

 

Before we can submit, the main outstanding issues are:

 

-          CV - looking through the CV there is still a fair bit of work to do,
there’s quite a few terms with missing or incorrect documentation

-          Mapping file

-          Finish example files.

 

Prior to the call on Thurs, can we have a think about how we plan to get the CV
into shape and discuss it as a main agenda item...

 

Also new schema uploaded with a few bits of improved documentation.

Cheers

Andy

 

 

 

 

 

 

 

 

 

 

 

 

 

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[Jones, A. <And...@li...>]

Hi Matt,

Consider the following pipeline mgf --> mzML --> SearchEngine --> analysisXML 

Having thought about this some more, I'm fairly sure that we want to reference
the ID attribute rather than nativeID. The nativeID is intended to identify the
source spectrum prior to conversion to mzML format i.e. it does not strictly
identify the data represented in the file. The input to analysisXML is the
mzML-formatted spectrum, not the source mgf file. If we reference the nativeID,
this implies that the input to the SearchEngine was the mgf representation of
the spectrum. It's a minor point that makes no difference for most XML
implementations but the mgf formatted spectrum and the mzML formatted spectrum
are different objects. If a database implements this, it will be much simpler to
have a chain of inputs and outputs with distinct IDs, reflecting the processing
that has happened at each stage. From a database/LIMS or file tracking point of
view, this could be significant I think.


> If the attribute name doesn't change, only the xsd documentation needs
> to be updated to reflect which attribute the spectrumID points to and
> that it can be used even if the input spectra file is not mzML!

Agreed, the documentation of the attribute does need to be improved. I prefer to
have attribute names that reflect their relationship to the parent element, I
think spectrumID is clear in what it refers to for SpectrumIdentificationResult.

> Additionally, if your "spectrumID" attribute matches the "nativeID"
> attribute in mzML, the mapping file must require one of the nativeID
> format terms in the file header: the specific place is TBD in
> analysisXML, in mzML it's mapped to the fileDescription element.
> Remember, nativeID is always available from any input spectra file, so
> there's no problem requiring it as long as decent references to the
> input spectra are maintained.

I'll take a look at the mzML mapping file and see what we need to do.

Cheers
Andy




> -----Original Message-----
> From: Matt Chambers [mailto:mat...@va...]
> Sent: 01 December 2008 14:23
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> 
> Jones, Andy wrote:
> >  Hi all,
> >
> >  The issues list is getting a bit messy with essentially a mailing
> >  list discussion so I'll shift the discussion back here :-)
> >
> >  There are two points up for discussion.
> >
> >  1) Use of identifiers for input spectra 2) CV terms shared between
> >  psi-ms and psi-pi
> >
> >  In terms of 1) I've worked through Matt's argument and I'm in general
> >  agreement that we would like to use the same system for identifying
> >  the input spectrum - these CV terms have only been added relatively
> >  recently. I did not realise that the nativeID attribute had been
> >  specified to this level, since there is no documentation about this
> >  is in the XSD or mzML specification document.
> >
> >  I don't think we should change the name of the attribute though,
> >  since nativeID makes sense for an element called <Spectrum> in mzML
> >  but not for an element <SpectrumIdentificationResult> in analysisXML.
> >  For referencing mzML spectra, I'm still not sure which attribute we
> >  should choose to reference since the "true" (and guaranteed unique)
> >  spectrum identifier in mzML is actually the ID attribute. I can
> >  envisage a case where instruments output mzML directly and the
> >  nativeID is not implemented sensibly. The xs:ID datatype on "ID"
> >  guarantees that these will always be unique whatever changes happen
> >  to documentation in the future or whatever tools are used to create
> >  the file.
> I contest the term "guaranteed unique" since the one doing the
> guaranteeing is the schema and there is no guarantee that somebody runs
> their output through a schema validator. :) If you take the validation
> step to the semantic validator (which is what the standard demands), the
> nativeID term is also guaranteed to be unique (and must be "implemented
> sensibly"), and as David suggested earlier, it should be possible to add
> a uniqueness constraint to the nativeID attribute in the schema even
> though it is xsd:string (but uniqueness is not so helpful when the
> actual form of a Thermo RAW id must be: "controller=xsd:positiveInteger
> scan=xsd:nonZeroInteger"). The name of the attribute doesn't bother me,
> but I don't understand your reasoning for not changing it. :)
> 
> 
> >  So I agree with Matt but I don't want to change the schema :-) I'm
> >  happy to add something to the documentation specifying how different
> >  identifiers should be implemented, following the rules in the psi-ms
> >  CV.
> If the attribute name doesn't change, only the xsd documentation needs
> to be updated to reflect which attribute the spectrumID points to and
> that it can be used even if the input spectra file is not mzML!
> 
> 
> >  In terms of 2), we had made a decision in the past that we would
> >  simply create terms as we need them in PSI-PI, rather than worrying
> >  if they should be common between psi-ms and psi-pi and trying to
> >  coordinate updates across groups. If a term is present in psi-ms with
> >  the exact meaning that we want (taking into account its position in
> >  the hierarchy), I think we should just use it and update the mapping
> >  file to reference it. Are there many terms from psi-ms that we want
> >  to use?
> It's looking like scan time (aka retention time) will be useful in
> analysisXML as an "alternative identifier" for the special use case of
> converting existing search results to analysisXML where a reliable
> nativeID to the original vendor format has been lost. Presumably, even
> in this use case a nativeID could be provided to point back to a
> spectrum in the search engine's immediate spectra input file (i.e.
> MGF).  If not even that is possible, either spectrumID has to be
> optional or the use case is rather suspect. :)
> 
> Additionally, if your "spectrumID" attribute matches the "nativeID"
> attribute in mzML, the mapping file must require one of the nativeID
> format terms in the file header: the specific place is TBD in
> analysisXML, in mzML it's mapped to the fileDescription element.
> Remember, nativeID is always available from any input spectra file, so
> there's no problem requiring it as long as decent references to the
> input spectra are maintained.
> 
> The scan time as an "alternative identifier" issue makes me wonder if a
> "scan time native spectrum identifier" term is called for. It still
> wouldn't solve all of the problems with David's use case (i.e. if the
> MGF was missing RTINSECONDS attributes), but it seems potentially useful.
> 
> -Matt
> 
> 
> >  I am working on the spec document today and would like to get all
> >  issues tidied up ASAP... Cheers Andy
> >
> >
> >
> >
> >
> >
> > > -----Original Message----- From: cod...@go...
> > > [mailto:cod...@go...] Sent: 30 November 2008 19:36
> > > To: psi...@li... Subject: [Psidev-pi-dev]
> > > Issue 42 in psi-pi: Issues with the CV
> > >
> > >
> > > Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues with
> > > the CV http://code.google.com/p/psi-pi/issues/detail?id=42
> > >
> > > Yes, I was at that meeting too. :) The one (important, IMO) use
> > > case we did not consider at that time is output of analysisXML
> > > without a corresponding mzML document. In such a case, the mzML
> > > arbitrary id does not exist, but the nativeID does. This fact
> > > convinces me that nativeID is a better reference than the arbitrary
> > > id.
> > >
> > > The change of attribute name to nativeID is not so critical, but I
> > > think the risk of confusing the spectrumID with the id attribute
> > > when it actually points to the nativeID attribute is worse than the
> > > risk of confusing the nativeID attribute with some property of the
> > > search engine. I think the documentation for the nativeID attribute
> > > can easily make it clear what it's supposed to reference,
> > > especially since it's on a spectrum-centric element; you can copy
> > > it from the mzML schema (although I think this documentation could
> > > be improved upon): <xs:documentation>The native identifier for the
> > > spectrum, used by the acquisition software.</xs:documentation>
> > >
> > > It's good to know about the header information. The nativeID (or
> > > whatever it's called in analysisXML) format term would go in the
> > > spectra input definition as a CV Param required by the mapping
> > > file.
> >
> 
> 
> 
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Jones, Andy wrote:
>  Hi all,
>
>  The issues list is getting a bit messy with essentially a mailing
>  list discussion so I'll shift the discussion back here :-)
>
>  There are two points up for discussion.
>
>  1) Use of identifiers for input spectra 2) CV terms shared between
>  psi-ms and psi-pi
>
>  In terms of 1) I've worked through Matt's argument and I'm in general
>  agreement that we would like to use the same system for identifying
>  the input spectrum - these CV terms have only been added relatively
>  recently. I did not realise that the nativeID attribute had been
>  specified to this level, since there is no documentation about this
>  is in the XSD or mzML specification document.
>
>  I don't think we should change the name of the attribute though,
>  since nativeID makes sense for an element called <Spectrum> in mzML
>  but not for an element <SpectrumIdentificationResult> in analysisXML.
>  For referencing mzML spectra, I'm still not sure which attribute we
>  should choose to reference since the "true" (and guaranteed unique)
>  spectrum identifier in mzML is actually the ID attribute. I can
>  envisage a case where instruments output mzML directly and the
>  nativeID is not implemented sensibly. The xs:ID datatype on "ID"
>  guarantees that these will always be unique whatever changes happen
>  to documentation in the future or whatever tools are used to create
>  the file.
I contest the term "guaranteed unique" since the one doing the 
guaranteeing is the schema and there is no guarantee that somebody runs 
their output through a schema validator. :) If you take the validation 
step to the semantic validator (which is what the standard demands), the 
nativeID term is also guaranteed to be unique (and must be "implemented 
sensibly"), and as David suggested earlier, it should be possible to add 
a uniqueness constraint to the nativeID attribute in the schema even 
though it is xsd:string (but uniqueness is not so helpful when the 
actual form of a Thermo RAW id must be: "controller=xsd:positiveInteger 
scan=xsd:nonZeroInteger"). The name of the attribute doesn't bother me, 
but I don't understand your reasoning for not changing it. :)


>  So I agree with Matt but I don't want to change the schema :-) I'm
>  happy to add something to the documentation specifying how different
>  identifiers should be implemented, following the rules in the psi-ms
>  CV.
If the attribute name doesn't change, only the xsd documentation needs 
to be updated to reflect which attribute the spectrumID points to and 
that it can be used even if the input spectra file is not mzML!


>  In terms of 2), we had made a decision in the past that we would
>  simply create terms as we need them in PSI-PI, rather than worrying
>  if they should be common between psi-ms and psi-pi and trying to
>  coordinate updates across groups. If a term is present in psi-ms with
>  the exact meaning that we want (taking into account its position in
>  the hierarchy), I think we should just use it and update the mapping
>  file to reference it. Are there many terms from psi-ms that we want
>  to use?
It's looking like scan time (aka retention time) will be useful in 
analysisXML as an "alternative identifier" for the special use case of 
converting existing search results to analysisXML where a reliable 
nativeID to the original vendor format has been lost. Presumably, even 
in this use case a nativeID could be provided to point back to a 
spectrum in the search engine's immediate spectra input file (i.e. 
MGF).  If not even that is possible, either spectrumID has to be 
optional or the use case is rather suspect. :)

Additionally, if your "spectrumID" attribute matches the "nativeID" 
attribute in mzML, the mapping file must require one of the nativeID 
format terms in the file header: the specific place is TBD in 
analysisXML, in mzML it's mapped to the fileDescription element. 
Remember, nativeID is always available from any input spectra file, so 
there's no problem requiring it as long as decent references to the 
input spectra are maintained.

The scan time as an "alternative identifier" issue makes me wonder if a 
"scan time native spectrum identifier" term is called for. It still 
wouldn't solve all of the problems with David's use case (i.e. if the 
MGF was missing RTINSECONDS attributes), but it seems potentially useful.

-Matt


>  I am working on the spec document today and would like to get all
>  issues tidied up ASAP... Cheers Andy
>
>
>
>
>
>
> > -----Original Message----- From: cod...@go...
> > [mailto:cod...@go...] Sent: 30 November 2008 19:36
> > To: psi...@li... Subject: [Psidev-pi-dev]
> > Issue 42 in psi-pi: Issues with the CV
> >
> >
> > Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues with
> > the CV http://code.google.com/p/psi-pi/issues/detail?id=42
> >
> > Yes, I was at that meeting too. :) The one (important, IMO) use
> > case we did not consider at that time is output of analysisXML
> > without a corresponding mzML document. In such a case, the mzML
> > arbitrary id does not exist, but the nativeID does. This fact
> > convinces me that nativeID is a better reference than the arbitrary
> > id.
> >
> > The change of attribute name to nativeID is not so critical, but I
> > think the risk of confusing the spectrumID with the id attribute
> > when it actually points to the nativeID attribute is worse than the
> > risk of confusing the nativeID attribute with some property of the
> > search engine. I think the documentation for the nativeID attribute
> > can easily make it clear what it's supposed to reference,
> > especially since it's on a spectrum-centric element; you can copy
> > it from the mzML schema (although I think this documentation could
> > be improved upon): <xs:documentation>The native identifier for the
> > spectrum, used by the acquisition software.</xs:documentation>
> >
> > It's good to know about the header information. The nativeID (or
> > whatever it's called in analysisXML) format term would go in the
> > spectra input definition as a CV Param required by the mapping
> > file.
>

Re: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[Jones, A. <And...@li...>]

Hi all,

The issues list is getting a bit messy with essentially a mailing list
discussion so I'll shift the discussion back here :-)

There are two points up for discussion.

1) Use of identifiers for input spectra
2) CV terms shared between psi-ms and psi-pi

> Comment 54  by matthew....@vanderbilt.edu, Nov 28 (2 days ago)

> Both a & b to emphasize the fact that the nativeID is defined no matter what
the
>format of the source file is. Also, just like mzML, you would define that
format at
>the top of the file, although it doesn't appear there is an analysisXML
equivalent to
>"fileContent/fileDescription" in mzML. The nativeID formats are defined in the
mzML
>CV and the terms map to that top header to define the nativeID format for every
>spectrum in the file: see CV terms starting at MS:1000767
>in
>http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/controlledV
ocabulary/psi-ms.obo

In terms of 1) I've worked through Matt's argument and I'm in general agreement
that we would like to use the same system for identifying the input spectrum -
these CV terms have only been added relatively recently. I did not realise that
the nativeID attribute had been specified to this level, since there is no
documentation about this is in the XSD or mzML specification document.

I don't think we should change the name of the attribute though, since nativeID
makes sense for an element called <Spectrum> in mzML but not for an element
<SpectrumIdentificationResult> in analysisXML. For referencing mzML spectra, I'm
still not sure which attribute we should choose to reference since the "true"
(and guaranteed unique) spectrum identifier in mzML is actually the ID
attribute. I can envisage a case where instruments output mzML directly and the
nativeID is not implemented sensibly. The xs:ID datatype on "ID" guarantees that
these will always be unique whatever changes happen to documentation in the
future or whatever tools are used to create the file.

So I agree with Matt but I don't want to change the schema :-) I'm happy to add
something to the documentation specifying how different identifiers should be
implemented, following the rules in the psi-ms CV.

In terms of 2), we had made a decision in the past that we would simply create
terms as we need them in PSI-PI, rather than worrying if they should be common
between psi-ms and psi-pi and trying to coordinate updates across groups. If a
term is present in psi-ms with the exact meaning that we want (taking into
account its position in the hierarchy), I think we should just use it and update
the mapping file to reference it. Are there many terms from psi-ms that we want
to use?

I am working on the spec document today and would like to get all issues tidied
up ASAP... 
Cheers
Andy






> -----Original Message-----
> From: cod...@go... [mailto:cod...@go...]
> Sent: 30 November 2008 19:36
> To: psi...@li...
> Subject: [Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV
> 
> 
> Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
> http://code.google.com/p/psi-pi/issues/detail?id=42
> 
> Yes, I was at that meeting too. :) The one (important, IMO) use case we did
> not
> consider at that time is output of analysisXML without a corresponding mzML
> document.
> In such a case, the mzML arbitrary id does not exist, but the nativeID
> does. This
> fact convinces me that nativeID is a better reference than the arbitrary id.
> 
> The change of attribute name to nativeID is not so critical, but I think
> the risk of
> confusing the spectrumID with the id attribute when it actually points to
> the
> nativeID attribute is worse than the risk of confusing the nativeID
> attribute with
> some property of the search engine. I think the documentation for the
> nativeID
> attribute can easily make it clear what it's supposed to reference,
> especially since
> it's on a spectrum-centric element; you can copy it from the mzML schema
> (although I
> think this documentation could be improved upon):
> <xs:documentation>The native identifier for the spectrum, used by the
> acquisition
> software.</xs:documentation>
> 
> It's good to know about the header information. The nativeID (or whatever
> it's called
> in analysisXML) format term would go in the spectra input definition as a
> CV Param
> required by the mapping file.
> 
> --
> 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
> 
> -------------------------------------------------------------------------
> 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-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[<cod...@go...>]

Comment #56 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Yes, I was at that meeting too. :) The one (important, IMO) use case we did  
not
consider at that time is output of analysisXML without a corresponding mzML  
document.
In such a case, the mzML arbitrary id does not exist, but the nativeID  
does. This
fact convinces me that nativeID is a better reference than the arbitrary id.

The change of attribute name to nativeID is not so critical, but I think  
the risk of
confusing the spectrumID with the id attribute when it actually points to  
the
nativeID attribute is worse than the risk of confusing the nativeID  
attribute with
some property of the search engine. I think the documentation for the  
nativeID
attribute can easily make it clear what it's supposed to reference,  
especially since
it's on a spectrum-centric element; you can copy it from the mzML schema  
(although I
think this documentation could be improved upon):
<xs:documentation>The native identifier for the spectrum, used by the  
acquisition
software.</xs:documentation>

It's good to know about the header information. The nativeID (or whatever  
it's called
in analysisXML) format term would go in the spectra input definition as a  
CV Param
required by the mapping file.

-- 
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