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

[Psidev-pi-dev] Issue 51 in psi-pi: Issues with the spec doc

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

Comment #2 on issue 51 by javizca74: Issues with the spec doc
http://code.google.com/p/psi-pi/issues/detail?id=51

After a first look, I would change the following:

- "Cosmetic change": the tables in the spec doc for elements 6.7
(SequenceCollection)and 6.15 (DBSequence) need to be resized in order to  
fit in the page.
- In point 7.3, the example must be updated in order to change the  
translation frames
to include now 1,2,3,-1,-2,-3.
- I would add Florian Reisinger from the PRIDE team, to the list of  
acknowledgements,
since he contributed to the new schema.


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

[Psidev-pi-dev] Issue 51 in psi-pi: Issues with the spec doc

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

Comment #1 on issue 51 by andrewrobertjones: Issues with the spec doc
http://code.google.com/p/psi-pi/issues/detail?id=51

- Remove all intances of "pf:"

- Change "-" to optional for attributes as requested by a reviewer

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

[Psidev-pi-dev] Spec doc

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

Hi all,

The draft of the specification document has been re-generated and is in the SVN and directly linked here:

http://code.google.com/p/psi-pi/source/browse/trunk/specification_document/mzIdentML_releaseCandidate1.doc

I'm hoping to submit this to the doc process by the end of Friday so can everyone review this carefully. I've picked up one or two things in the auto-generation process that need to be fixed (e.g. remove "pf:" throughout), but I think we can fix these with find and replace.

I don't have much time to look at this for a couple of days but I thought I'd get it out now to give everyone as much time as possible for review. Please send minor fixes to me directly or issues for discussion can be posted in a new issue: http://code.google.com/p/psi-pi/issues/detail?id=51

Cheers
Andy

[Psidev-pi-dev] Issue 51 in psi-pi: Issues with the spec doc

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

Status: Accepted
Owner: andrewrobertjones
Labels: Type-Defect Priority-Medium

New issue 51 by andrewrobertjones: Issues with the spec doc
http://code.google.com/p/psi-pi/issues/detail?id=51

Drop any issues with the spec doc in here



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

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

Comment #20 on issue 49 by dcreasy: Issues / schema updates prior to  
version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Yes, I think you are right. I hadn't realised that it was possible to  
provide the
<DBSequence> without having a related <ProteinDetectionHypothesis>

However, we can't make PeptideEvidence 1..many because of denovo.
I'll update the Mascot examples at some point, but agree that we should  
leave the
schema the same.

Phew!



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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

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

Comment #19 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

I think this relates to how Mascot views junk matches and protein hits  
rather than a
flaw in the schema. The PeptideEvidence elements only relate where the  
peptide
sequence came from in a peptide-spectrum match (it must have come from at  
least one
Protein sequence) - it says nothing about protein identity or otherwise.  
Mascot says
junk matches don't relate to a Protein - this is okay, you just don't  
output anything
for them in ProteinDetectionList. I think the PeptideEvidence link to  
DBSequence
should be provided for every single SII - and perhaps we should make the  
cardinality
1..many to enforce this?

To avoid too much file bloat, I would suggest not proving the <seq>  
attribute on
DBSequence for junk matches. Or am I missing something?



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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

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

Comment #18 on issue 49 by dcreasy: Issues / schema updates prior to  
version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Sorry, this is not good timing...
We currently have:

<SpectrumIdentificationResult ... >
   <SpectrumIdentificationItem  ... >
     <PeptideEvidence isDecoy="true" DBSequence_Ref="XYZ">

In the existing examples of using decoy, where each  
<SpectrumIdentificationItem>
always has a <PeptideEvidence> this works just fine.

The Mascot examples (which don't currently have a decoy search example)  
show the
possibility of saving all matches to spectra, enabling further statistical  
analysis
of the results. This is done by saving a <SpectrumIdentificationItem>  
without
<PeptideEvidence> for 'junk' matches. However, without the  
<PeptideEvidence> element,
there is no way to know if the match was to a decoy sequence. I think that  
the
isDecoy should be an attribute of <SpectrumIdentificationItem> or possibly  
<Peptide>.
Without this change, I think this means we can't fulfil use case #4 without  
huge file
bloat. Too late to change???

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

[Psidev-pi-dev] Minutes from Phone Conference (July 16)

[Juan A. V. <ju...@eb...>]

Hi all,

Minutes from yesterday's phone conference can be found here:

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

Cheers,

Juan Antonio

Re: [Psidev-pi-dev] has_regexp vs. cleavage agent definition

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

I can live with the has_regexp relationship, I just think it's 
unnecessarily awkward. OBO Edit 2.0 does not complain about non-URI 
characters in xref. Perhaps it did in earlier beta versions, but not the 
release version.

Thanks,
Matt


Andreas Bertsch wrote:
> Hi Matt,
>
>> Maybe a compromise by putting the regex in a xref like the value-type:
>> [Term]
>> id: MS:1001303
>> name: Arg-C
>> def: "Cleaves c-terminal to arginine except when the c-terminal residue
>> is proline." [PSI-PI]
>> is_a: MS:1001045 ! cleavage agent name
>> xref: regex-rule:"(?<=R)(?!P)"
>
>
> The problem is that OBO edit expects only URI characters in xref 
> statements (issue 30 discusses that). We decided on the todays PI 
> phone conference not to change the CV, because the current solution is 
> working quite well.
>
> One thing to mention. The regular expression terms cannot be used 
> directly in mzIdentML instances. They are associated using the 
> has_regexp relationship with the terms specifying the protease. I 
> think the handling of these terms must be implemented more or less 
> additionally, so think it is not a too big problem having these terms 
> not properly named in your enumeration.
>
> Can you live with that?
>
> Cheers,
> 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] has_regexp vs. cleavage agent definition

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

Hi Matt,

> Maybe a compromise by putting the regex in a xref like the value-type:
> [Term]
> id: MS:1001303
> name: Arg-C
> def: "Cleaves c-terminal to arginine except when the c-terminal  
> residue
> is proline." [PSI-PI]
> is_a: MS:1001045 ! cleavage agent name
> xref: regex-rule:"(?<=R)(?!P)"


The problem is that OBO edit expects only URI characters in xref  
statements (issue 30 discusses that). We decided on the todays PI  
phone conference not to change the CV, because the current solution is  
working quite well.

One thing to mention. The regular expression terms cannot be used  
directly in mzIdentML instances. They are associated using the  
has_regexp relationship with the terms specifying the protease. I  
think the handling of these terms must be implemented more or less  
additionally, so think it is not a too big problem having these terms  
not properly named in your enumeration.

Can you live with that?

Cheers,
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] Conference call

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

I altered this text to the following:

“If a secondary scoring scheme is used to weigh evidence for peptide-spectrum matches according to the search engines that have identified them, any consensus or composite scores should be assigned to each <SpectrumIdentificationItem> within parallel lists.”

From: Jones, Andy [mailto:And...@li...]
Sent: 16 July 2009 14:57
To: 'psi...@li...'
Subject: Re: [Psidev-pi-dev] Conference call

Some additional things to discuss on the call.


-          Regex issue identified by Matt – (although since this will not affect instance docs, it is not essential we resolve this prior to submitting the spec docs)


-          I propose to add the following text to the spec doc for the section on Multiple Search engines:

“If a secondary scoring scheme is used to weigh evidence for peptide-spectrum matches according to the search engines that have identified them, a valid alternative encoding is as follows. The analysis with multiple search engines should be represented as one <SpectrumIdentification> producing a single <SpectrumIdentificationList>.  Each <SpectrumIdentificationItem> should have any composite scores or scores output by single search engines encoded as instances of <cvParam>.”

With the current example instances we have no way of representing composite scores for peptide-spectrum matches made by multiple search engines (this is what my FDR-based software does and Scaffold I guess). I will produce an instance example at some stage.

Does anyone have a version of XMLSpy to regenerate the schema images?

Cheers
Andy







From: Jones, Andy [mailto:And...@li...]
Sent: 15 July 2009 15:28
To: 'psi...@li...'
Subject: [Psidev-pi-dev] Conference call

Hi all,

There will be an mzIdentML conference call tomorrow (16th July) at 4pm UK time: http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=7&year=2009&hour=16&min=0&sec=0&p1=136.

Agenda:


 1.  Review minutes from last week: http://www.psidev.info/index.php?q=node/432
 2.  Review issues list: http://code.google.com/p/psi-pi/issues/list and aim to close all these issues!

I’m hoping the call will be fairly brief since there don’t seem to have been any major issues since last week. Let me know if there is anything else we should specifically look at before submitting to the process. I am hoping to regenerate the spec doc this week but probably won’t have a draft to circulate until Fri.
Cheers
Andy

Dial in details:

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)

access code: 297427

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

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

Comment #17 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Made a change to the schema to add a version attribute to element  
mzIdentML. This is
fixed with a regex, currently accepting 0.9.X. On release, this will change  
to 1.0.X



--
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] Conference call

[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">
Can we also discuss version numbers - see recent MS group discussion
with title: [Psidev-ms-dev] MzML version<br>
<br>
Jones, Andy wrote:
<blockquote
 cite="mid:C44...@ST..."
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 12 (filtered medium)">
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
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:589659638;
	mso-list-template-ids:569307336;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:922879050;
	mso-list-type:hybrid;
	mso-list-template-ids:48419664 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:1267497305;
	mso-list-type:hybrid;
	mso-list-template-ids:94153424 -1978903658 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l2: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";}
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);">Some
additional things to
discuss on the call.<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="color: rgb(31, 73, 125);"><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></span><!--[endif]--><span
 style="color: rgb(31, 73, 125);">Regex issue
identified by Matt – (although since this will not affect instance
docs, it is
not essential we resolve this prior to submitting the spec docs)<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <p class="MsoListParagraph" style="text-indent: -18pt;"><!--[if !supportLists]--><span
 style="color: rgb(31, 73, 125);"><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></span><!--[endif]--><span
 style="color: rgb(31, 73, 125);">I propose to add the
following text to the spec doc for the section on Multiple Search
engines:<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);">“If a
secondary scoring scheme
is used to weigh evidence for peptide-spectrum matches according to the
search
engines that have identified them, a valid alternative encoding is as
follows.
The analysis with multiple search engines should be represented as one
&lt;SpectrumIdentification&gt; producing a single
&lt;SpectrumIdentificationList&gt;.  Each
&lt;SpectrumIdentificationItem&gt;
should have any composite scores or scores output by single search
engines
encoded as instances of &lt;cvParam&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);">With the
current example instances
we have no way of representing composite scores for peptide-spectrum
matches
made by multiple search engines (this is what my FDR-based software
does and
Scaffold I guess). I will produce an instance example at some stage. <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);">Does
anyone have a version of
XMLSpy to regenerate the schema images?<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>
  <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"> Jones, Andy
[<a class="moz-txt-link-freetext" href="mailto:And...@li...">mailto:And...@li...</a>] <br>
  <b>Sent:</b> 15 July 2009 15:28<br>
  <b>To:</b> '<a class="moz-txt-link-abbreviated" href="mailto:psi...@li...">psi...@li...</a>'<br>
  <b>Subject:</b> [Psidev-pi-dev] Conference call<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 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);">There
will be an mzIdentML
conference call tomorrow (16<sup>th</sup> July) at 4pm UK time: <a
 moz-do-not-send="true"
 href="http://www.timeanddate.com/worldclock/fixedtime.html?day=15&amp;month=7&amp;year=2009&amp;hour=16&amp;min=0&amp;sec=0&amp;p1=136">http://www.timeanddate.com/worldclock/fixedtime.html?day=15&amp;month=7&amp;year=2009&amp;hour=16&amp;min=0&amp;sec=0&amp;p1=136</a>.
  <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);">Agenda:<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);"><o:p> </o:p></span></p>
  <ol style="margin-top: 0cm;" start="1" type="1">
    <li class="MsoNormal" style="color: rgb(31, 73, 125);">Review
minutes from last week: <a moz-do-not-send="true"
 href="http://www.psidev.info/index.php?q=node/432">http://www.psidev.info/index.php?q=node/432</a>
      <o:p></o:p></li>
    <li class="MsoNormal" style="color: rgb(31, 73, 125);">Review
issues list: <a moz-do-not-send="true"
 href="http://code.google.com/p/psi-pi/issues/list">http://code.google.com/p/psi-pi/issues/list</a>
and aim to close all these issues!<o:p></o:p></li>
  </ol>
  <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’m
hoping the call will be
fairly brief since there don’t seem to have been any major issues since
last
week. Let me know if there is anything else we should specifically look
at
before submitting to the process. I am hoping to regenerate the spec
doc this
week but probably won’t have a draft to circulate until Fri.<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);">Dial in
details:<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);">+
Germany: 08001012079<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">+
Switzerland: 0800000860<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">+ UK:
08081095644<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">+ USA:
1-866-314-3683<o:p></o:p></span></p>
  <p class="MsoNormal"><span style="color: rgb(31, 73, 125);">+ Generic
international: +44
2083222500 (UK number)<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);">access
code: 297427<o:p></o:p></span></p>
  </div>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/Challenge">http://p.sf.net/sfu/Challenge</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] Conference call

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

Some additional things to discuss on the call.


-          Regex issue identified by Matt – (although since this will not affect instance docs, it is not essential we resolve this prior to submitting the spec docs)


-          I propose to add the following text to the spec doc for the section on Multiple Search engines:

“If a secondary scoring scheme is used to weigh evidence for peptide-spectrum matches according to the search engines that have identified them, a valid alternative encoding is as follows. The analysis with multiple search engines should be represented as one <SpectrumIdentification> producing a single <SpectrumIdentificationList>.  Each <SpectrumIdentificationItem> should have any composite scores or scores output by single search engines encoded as instances of <cvParam>.”

With the current example instances we have no way of representing composite scores for peptide-spectrum matches made by multiple search engines (this is what my FDR-based software does and Scaffold I guess). I will produce an instance example at some stage.

Does anyone have a version of XMLSpy to regenerate the schema images?

Cheers
Andy







From: Jones, Andy [mailto:And...@li...]
Sent: 15 July 2009 15:28
To: 'psi...@li...'
Subject: [Psidev-pi-dev] Conference call

Hi all,

There will be an mzIdentML conference call tomorrow (16th July) at 4pm UK time: http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=7&year=2009&hour=16&min=0&sec=0&p1=136.

Agenda:


 1.  Review minutes from last week: http://www.psidev.info/index.php?q=node/432
 2.  Review issues list: http://code.google.com/p/psi-pi/issues/list and aim to close all these issues!

I’m hoping the call will be fairly brief since there don’t seem to have been any major issues since last week. Let me know if there is anything else we should specifically look at before submitting to the process. I am hoping to regenerate the spec doc this week but probably won’t have a draft to circulate until Fri.
Cheers
Andy

Dial in details:

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)

access code: 297427

[Psidev-pi-dev] Conference call

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

Hi all,

There will be an mzIdentML conference call tomorrow (16th July) at 4pm UK time: http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=7&year=2009&hour=16&min=0&sec=0&p1=136.

Agenda:


 1.  Review minutes from last week: http://www.psidev.info/index.php?q=node/432
 2.  Review issues list: http://code.google.com/p/psi-pi/issues/list and aim to close all these issues!

I’m hoping the call will be fairly brief since there don’t seem to have been any major issues since last week. Let me know if there is anything else we should specifically look at before submitting to the process. I am hoping to regenerate the spec doc this week but probably won’t have a draft to circulate until Fri.
Cheers
Andy

Dial in details:

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)

access code: 297427

Re: [Psidev-pi-dev] has_regexp vs. cleavage agent definition

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

Yes, I did have trouble getting the following definition to show up in 
OBO-Edit 2.0-beta53:

[Term]
id: MS:1001251
name: Trypsin
def: "(?<=[KR])(?!P)" [PSI-PI]
is_a: MS:1001045 ! cleavage agent name

But I upgraded to the release build of OBO-Edit 2 and it is working as 
expected. I'm pretty sure characters in quoted strings don't need to be 
escaped except for \" and \\. Our CV is blatantly violating the OBO 
escape characters: http://www.geneontology.org/GO.format.obo-1_2.shtml#S.1.5
OBO-Edit accepts it because it assumes that "Some tag values may contain 
unescaped colons, brackets, quotes, etc., that have meaning in decoding 
the tag value." But clearly the regex is just a literal string, not 
anything to be parsed specially.

Putting the regex in the definition would make it much simpler to access 
for a CV parser. But a drawback would be the definition couldn't easily 
be used for a real English definition of the cleavage agent rules (e.g. 
"Trypsin cleaves C-terminal to lysine or arginine except when the 
C-terminal residue is proline.") , which would be appropriate in the CV 
for people who can't read regexes, which sadly is most people. ;) Mixing 
the machine readable regex with the human readable in a single 
definition would be ugly.

Maybe a compromise by putting the regex in a xref like the value-type:
[Term]
id: MS:1001303
name: Arg-C
def: "Cleaves c-terminal to arginine except when the c-terminal residue 
is proline." [PSI-PI]
is_a: MS:1001045 ! cleavage agent name
xref: regex-rule:"(?<=R)(?!P)"

-Matt


Andreas Bertsch wrote:
> Hi Matt,
>
>   
>> I like that the regular expressions are defined in the CV, but I'd  
>> like
>> to know if there's a compelling reason that they are given as separate
>> terms instead of machine-readable definitions of the cleavage agents?
>> For example, I'd like to see:
>> [Term]
>> id: MS:1001251
>> name: Trypsin
>> def: "(?<=[KR])(?!P)" [PSI-PI]
>> is_a: MS:1001045 ! cleavage agent name
>>
>> Perhaps there is some convenience to the has_regexp semantics that I
>> haven't considered. I notice there was a discussion last November "CV:
>> regexp for default enzymes" but it didn't consider things from the CV
>> user's angle.
>>
>> To put this into context, ProteoWizard turns the entire CV into a
>> hard-coded enumeration to reduce CV errors due to typos. Since regexes
>> have lots of symbols that can't be put in most languages' syntax,  
>> these
>> terms look very odd and are useless to us by themselves since the
>> important information is lost by conversion to identifier-friendly
>> characters:
>> MS______FYWL______P_ = 1001332,
>> MS_____M_ = 1001333,
>> MS______D_______D__ = 1001334,
>> MS_____K_____P_ = 1001335,
>> MS_____K_ = 1001336,
>> MS______FL__ = 1001337,
>> MS______FYWLKR______P_ = 1001338,
>> MS______KR__ = 1001339,
>> MS______BDEZ______P_ = 1001340,
>> MS______EZ______P_ = 1001341,
>>
>> I doubt pwiz will be the only effort that turns the CV into an
>> enumeration either, since it allows accessing the terms by
>> human-readable name without resorting to slow and error-prone strings.
>>     
>
> You meant thread http://code.google.com/p/psi-pi/issues/detail?id=30 ?  
> I think the main reason for that decision was that there was no other  
> way to keep the CV readable with OBOEdit and compatible with the OBO  
> format. As far as I remember it, the problem was the '!' the in the  
> stanza. Somehow OBOEdit stumbled over that.
>
> Can you think of an easy solution? So far, changes have very little  
> impact on our instance documents (if the ids and the names of the  
> enzyme terms stay).
>
> Cheers,
> A.
>
>   

Re: [Psidev-pi-dev] has_regexp vs. cleavage agent definition

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

Hi Matt,

> I like that the regular expressions are defined in the CV, but I'd  
> like
> to know if there's a compelling reason that they are given as separate
> terms instead of machine-readable definitions of the cleavage agents?
> For example, I'd like to see:
> [Term]
> id: MS:1001251
> name: Trypsin
> def: "(?<=[KR])(?!P)" [PSI-PI]
> is_a: MS:1001045 ! cleavage agent name
>
> Perhaps there is some convenience to the has_regexp semantics that I
> haven't considered. I notice there was a discussion last November "CV:
> regexp for default enzymes" but it didn't consider things from the CV
> user's angle.
>
> To put this into context, ProteoWizard turns the entire CV into a
> hard-coded enumeration to reduce CV errors due to typos. Since regexes
> have lots of symbols that can't be put in most languages' syntax,  
> these
> terms look very odd and are useless to us by themselves since the
> important information is lost by conversion to identifier-friendly
> characters:
> MS______FYWL______P_ = 1001332,
> MS_____M_ = 1001333,
> MS______D_______D__ = 1001334,
> MS_____K_____P_ = 1001335,
> MS_____K_ = 1001336,
> MS______FL__ = 1001337,
> MS______FYWLKR______P_ = 1001338,
> MS______KR__ = 1001339,
> MS______BDEZ______P_ = 1001340,
> MS______EZ______P_ = 1001341,
>
> I doubt pwiz will be the only effort that turns the CV into an
> enumeration either, since it allows accessing the terms by
> human-readable name without resorting to slow and error-prone strings.

You meant thread http://code.google.com/p/psi-pi/issues/detail?id=30 ?  
I think the main reason for that decision was that there was no other  
way to keep the CV readable with OBOEdit and compatible with the OBO  
format. As far as I remember it, the problem was the '!' the in the  
stanza. Somehow OBOEdit stumbled over that.

Can you think of an easy solution? So far, changes have very little  
impact on our instance documents (if the ids and the names of the  
enzyme terms stay).

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

[Psidev-pi-dev] has_regexp vs. cleavage agent definition

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

Hi all,

I like that the regular expressions are defined in the CV, but I'd like 
to know if there's a compelling reason that they are given as separate 
terms instead of machine-readable definitions of the cleavage agents? 
For example, I'd like to see:
[Term]
id: MS:1001251
name: Trypsin
def: "(?<=[KR])(?!P)" [PSI-PI]
is_a: MS:1001045 ! cleavage agent name

Perhaps there is some convenience to the has_regexp semantics that I 
haven't considered. I notice there was a discussion last November "CV: 
regexp for default enzymes" but it didn't consider things from the CV 
user's angle.

To put this into context, ProteoWizard turns the entire CV into a 
hard-coded enumeration to reduce CV errors due to typos. Since regexes 
have lots of symbols that can't be put in most languages' syntax, these 
terms look very odd and are useless to us by themselves since the 
important information is lost by conversion to identifier-friendly 
characters:
MS______FYWL______P_ = 1001332,
MS_____M_ = 1001333,
MS______D_______D__ = 1001334,
MS_____K_____P_ = 1001335,
MS_____K_ = 1001336,
MS______FL__ = 1001337,
MS______FYWLKR______P_ = 1001338,
MS______KR__ = 1001339,
MS______BDEZ______P_ = 1001340,
MS______EZ______P_ = 1001341,

I doubt pwiz will be the only effort that turns the CV into an 
enumeration either, since it allows accessing the terms by 
human-readable name without resorting to slow and error-prone strings.

Thanks,
-Matt

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

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

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

Regarding comment 21. We agreed at telecon to keep it simple and go for  
approach
number 1, with the option of *additionally* using approach #3 for more  
complex cases.
Changes made to Mascot examples which use MS:1000336" name="neutral loss"

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

[Psidev-pi-dev] Minutes from Phone Conference (July 9)

[Juan A. V. <ju...@eb...>]

Hi all,

Minutes from today's phone conference can be found here:

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

Cheers,

Juan Antonio




Juan Antonio Vizcaíno, Ph.D.
EMBL European Bioinformatics Institute
Proteomics Services Team, PANDA Group
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD
Tel: +44 (0) 1223 492 686
Fax: +44 (0) 1223 494 468
Skype: javizca

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

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

Comment #16 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Updated schema:

Added documentation for neutral loss within Modification.

Changed data type for frame attribute to only allow -3 -2 -1 1 2 3 and for  
frames to
allow a list of these

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

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

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

Comment #95 on issue 42 by andrewrobertjones: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

These are all fairly minor so can probably be fixed without discussion

1. I think this term need a unit: e.g.
relationship: has_units UO:0000221 ! dalton
relationship: has_units UO:0000222 ! kilodalton

[Term]
id: MS:1001361
name: alternate mass
def: "List of masses a non-standard letter code is replaced with." [PSI:PI]
xref: value-type:xsd\:double "The allowed value-type for this CV term."
is_a: MS:1001359 ! ambiguous residues

2. I don't see the point of this term:

[Term]
id: MS:1001057
name: tolerance on types
def: "Tolerance on types." [PSI:PI]
is_a: MS:1001055 ! modification parameters

3. Most of the children of quantification have errors (missing data  
type/unit) but we
can probably leave these for now:

[Term]
id: MS:1001129
name: quantification information
def: "Quantification information." [PSI:PI]
relationship: part_of MS:1001000 ! spectrum interpretation


4. This term needs a datatype (xref: value-type:xsd\:string "The allowed  
value-type
for this CV term.")

[Term]
id: MS:1001051
name: multiple enzyme combination rules
def: "Description of multiple enzyme digestion protocol, if any." [PSI:PI]
is_a: MS:1001044 ! cleavage agent details

5. This term and related terms need units e.g.
relationship: has_units UO:0000221 ! dalton
relationship: has_units UO:0000222 ! kilodalton

[Term]
id: MS:1001201
name: DB MW filter maximum
xref: value-type:xsd\:double "The allowed value-type for this CV term."
is_a: MS:1001512 ! Sequence database filters


6. This term needs a URI datatype? (xsd:anyURI)

[Term]
id: MS:1001014
name: database local file path
def: "Local file path of the search database from the search engine's point  
of view."
[PSI:PI]
is_a: MS:1001011 ! search database details


7. Add date type to this (xsd:dateTime)

[Term]
id: MS:1001017
name: database release date
def: "Release date of the search database." [PSI:PI]
is_a: MS:1001011 ! search database details

8. Change string datatype to URI?

[Term]
id: MS:1001015
name: database original uri
def: "URI, from where the search database was originally downloaded."  
[PSI:PI]
xref: value-type:xsd\:string "The allowed value-type for this CV term."
is_a: MS:1001011 ! search database details


9. Needs a string datatype:

[Term]
id: MS:1001016
name: database version
def: "Version of the search database ." [PSI:PI]
is_a: MS:1001011 ! search database details

10. this needs a datatype (not exactly sure if an int or a string?):

[Term]
id: MS:1001024
name: translation frame
def: "The translated open reading frames from a nucleotide database  
considered in the
search (range: 1-6)." [PSI:PI]
is_a: MS:1001011 ! search database details



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

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

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

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

Need to change:

<cv id="UNIMOD" URI="http://www.unimod.org/xml/unimod.xml">
to
<cv id="UNIMOD" URI="http://www.unimod.org/obo/unimod.obo">

(Done for all Mascot examples)

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

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

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

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

No, I don't think anything is lost. It's more that the <Peptide> is just  
about the
peptide sequence and any modified residues rather than about how it  
fragmented.
However, it's obviously simpler to use option #1. Both options just require  
one new
CV term.

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

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

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

Comment #94 on issue 42 by javizca74: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Some ion types are missing in the CV. We have added to the PRIDE CV, in  
order to
provide fragment ion annotation.

- At the moment there are no -H2O and -NH3 ions for ions c, x and z.
- The same above for precursor ion.
- We have also found that mascot reports the specific type of immonium ion:

immonium A
immonium C
immonium D
immonium E
immonium F
immonium H
immonium I
immonium K
immonium L
immonium M
immonium N
immonium P
immonium Q
immonium R
immonium S
immonium T
immonium V
immonium W
immonium Y


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