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

Re: [Psidev-pi-dev] (no subject)

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

Hi Pierre-Alain, 

 

We already have a separate mechanism for reporting mods found (1):

 

<Peptide identifier="3_1">

  <Modification location="5">

     <pf:cvParam accession="MOD:00412" name="Oxidation (M)" cvRef="PSI-MOD"/>

 

 

The discussion here is about how to record the mods searched for (2). I’ll put out a schema proposal later today but the basic idea is to encode whether a search mod is fixed/variable, with the option for adding cvParams to encode more complex rules. We also plan to encode the modification mass used by the search engine, since it might not be the exact value that is encoded in the cv.

 

Cheers

Andy

 

 

 

 

 

From: psi...@li... [mailto:psi...@li...] On Behalf Of Pierre-Alain Binz
Sent: 01 June 2008 19:57
To: Martin Eisenacher
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] (no subject)

 

Hi all,
I'm not sure about the goal here. Is it 
1) to encode actual modifications found in the identified peptides / molecules
2) to encode the rules that the search engines are using 

In the case of 1) I do not see for instance the reason for the "variable/fixed" item
In the case of 2) It looks difficult to encode all, as tools will even implement those rules in very different manner (things like maximal number of occurences per peptide, or more non-explicit searches like the error-tolerant search button in Mascot, or the default list of mods in Paragon / Modiro etc)

Maybe we should do both, but in different manners.

Please clarify here...
Pierre-Alain

Martin Eisenacher wrote: 

Hi from Bochum!
 
Find attached a schema draft of a
<ModificationParams> element with
example.
It is for the description of
modification parameters of a search
engine.
 
Most characteristics of a modification
(like formula or mass shift) are part
of the PSI-MOD CV (obo cross
references).
 
Idea: attributes sensitivity
(fixed/variable), masstype (mono/avg)
and 
origins (to specify modification sites
explicitely);
elements othersensitivity and
othermasstype for extensions or special
cases (e.g. phenyx' tolerance on
fixed/variable type).
 
To discuss: a special "neutral loss"
element.
 
  Bye
    Martin
  
 


________________________________



 
<?xml version="1.0" encoding="UTF-8"?>
<!--W3C Schema generated by XMLSpy v2007 sp1 (http://www.altova.com)-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <http://www.w3.org/2001/XMLSchema> >
       <xs:complexType name="cvParamType" abstract="false">
              <xs:attribute name="cvRef" type="xs:string" use="required">
              </xs:attribute>
              <xs:attribute name="accession" type="xs:string" use="required">
              </xs:attribute>
              <xs:attribute name="value" type="xs:string">
              </xs:attribute>
              <xs:attribute name="name" type="xs:string" use="required">
              </xs:attribute>
              <xs:attribute name="unitAccession" type="xs:string">
              </xs:attribute>
              <xs:attribute name="unitName" type="xs:string">
              </xs:attribute>
       </xs:complexType>
       <xs:element name="cvParam" type="cvParamType" abstract="false"/>
       <xs:element name="othersensitivity">
              <xs:annotation>
                      <xs:documentation>Specify extensions to "fixed" and "variable" or specify other sensitivities (using CV).</xs:documentation>
              </xs:annotation>
              <xs:complexType>
                      <xs:sequence>
                              <xs:element ref="cvParam"/>
                      </xs:sequence>
              </xs:complexType>
       </xs:element>
       <xs:element name="othermasstype">
              <xs:annotation>
                      <xs:documentation>Specify extensions to "monoisotopic" or "averageisotopic" or specify other mass types (using CV).</xs:documentation>
              </xs:annotation>
              <xs:complexType>
                      <xs:sequence>
                              <xs:element ref="cvParam"/>
                      </xs:sequence>
              </xs:complexType>
       </xs:element>
       <xs:element name="oneModificationParam">
              <xs:annotation>
                      <xs:documentation>Details of one modification parameter (most characteristics contained in PSI-MOD CV !).</xs:documentation>
              </xs:annotation>
              <xs:complexType>
                      <xs:sequence>
                              <xs:element ref="cvParam"/>
                              <xs:element ref="othersensitivity" minOccurs="0"/>
                              <xs:element ref="othermasstype" minOccurs="0"/>
                      </xs:sequence>
                      <xs:attribute name="identifier" use="required">
                              <xs:simpleType>
                                     <xs:restriction base="xs:string">
                                      </xs:restriction>
                              </xs:simpleType>
                      </xs:attribute>
                      <xs:attribute name="sensitivity" use="required">
                              <xs:annotation>
                                     <xs:documentation>Specify whether modification occurs always ("fixed") or sometimes ("variable"). If "other", sub-element othersensitivity must be present.</xs:documentation>
                              </xs:annotation>
                              <xs:simpleType>
                                     <xs:restriction base="xs:string">
                                             <xs:enumeration value="fixed"/>
                                             <xs:enumeration value="variable"/>
                                             <xs:enumeration value="other"/>
                                      </xs:restriction>
                              </xs:simpleType>
                      </xs:attribute>
                      <xs:attribute name="masstype" use="required">
                              <xs:annotation>
                                     <xs:documentation>Specify whether mass type is monoisotopic or avergaeisotopic. If "other", sub-element othermasstype must be present.</xs:documentation>
                              </xs:annotation>
                              <xs:simpleType>
                                     <xs:restriction base="xs:string">
                                             <xs:enumeration value="monoisotopic"/>
                                             <xs:enumeration value="averageisotopic"/>
                                             <xs:enumeration value="other"/>
                                     </xs:restriction>
                              </xs:simpleType>
                      </xs:attribute>
                      <xs:attribute name="origins" use="optional">
                              <xs:annotation>
                                     <xs:documentation>Possible sites (amino acids).</xs:documentation>
                              </xs:annotation>
                              <xs:simpleType>
                                     <xs:restriction base="xs:string"/>
                              </xs:simpleType>
                      </xs:attribute>
              </xs:complexType>
       </xs:element>
       <xs:element name="ModificationParamsExamples">
              <xs:complexType>
                      <xs:sequence>
                              <xs:element ref="ModificationParams"/>
                      </xs:sequence>
              </xs:complexType>
       </xs:element>
       <xs:element name="ModificationParams">
              <xs:annotation>
                      <xs:documentation>Set of all modification parameters used for a spectrum search.</xs:documentation>
              </xs:annotation>
              <xs:complexType>
                      <xs:sequence>
                              <xs:element ref="oneModificationParam" maxOccurs="unbounded"/>
                      </xs:sequence>
              </xs:complexType>
       </xs:element>
</xs:schema>
  
 


________________________________



 
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2007 sp1 (http://www.altova.com) by eisenach (MPC) -->
<ModificationParamsExamples xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <http://www.w3.org/2001/XMLSchema-instance>  xsi:noNamespaceSchemaLocation=".\modifications_temp.xsd">
       <ModificationParams>
              <oneModificationParam identifier="Oxidation_M_NL80" sensitivity="variable" masstype="monoisotopic">
                      <cvParam accession="MOD:00768" name="methionine oxidation with neutral loss of 80 Da" cvRef="PSI-MOD"/>
              </oneModificationParam>
              <oneModificationParam identifier="Oxidation_M_NL64" sensitivity="variable" masstype="monoisotopic">
                      <cvParam accession="MOD:00935" name="methionine oxidation with neutral loss of 64 Da" cvRef="PSI-MOD"/>
              </oneModificationParam>
              <oneModificationParam identifier="Carbamido" sensitivity="fixed" masstype="monoisotopic" origins="C"> <!-- MOD:00397 has possible origins H, K, C, E, D -->
                      <cvParam accession="MOD:00397" name="iodoacetamide derivative" cvRef="PSI-MOD"/>
              </oneModificationParam>
              <oneModificationParam identifier="Phospho_S" sensitivity="fixed" masstype="monoisotopic">
                      <cvParam accession="MOD:00046" name="O-phosphorylated L-serine" cvRef="PSI-MOD"/>
              </oneModificationParam>
              <oneModificationParam identifier="Phospho_T" sensitivity="fixed" masstype="monoisotopic">
                      <cvParam accession="MOD:00047" name="O-phosphorylated L-threonine" cvRef="PSI-MOD"/>
              </oneModificationParam>
              <oneModificationParam identifier="Phospho_Y" sensitivity="fixed" masstype="monoisotopic">
                      <cvParam accession="MOD:00048" name="O4'-phosphorylated L-tyrosine" cvRef="PSI-MOD"/>
              </oneModificationParam>
       <!-- example for "other" elements: phenyx -->
              <oneModificationParam identifier="Fantasy" sensitivity="fixed" masstype="averageisotopic" >
                      <cvParam accession="" name="Fantasy" cvRef="PSI-MOD"/>
                      <othersensitivity>
                              <cvParam accession="" name="phenyx-tolerance" cvRef="PSI-MOD" value="n-1"/>
                      </othersensitivity>
                      <othermasstype>
                              <cvParam accession="" name="SomethingVerySpecial" cvRef="PSI-MOD"  value="" unitAccession="" unitName=""/>
                      </othermasstype>
              </oneModificationParam>
       </ModificationParams>
</ModificationParamsExamples>
  
 


________________________________



 
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
 


________________________________



 
_______________________________________________
Psidev-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
  

Re: [Psidev-pi-dev] (no subject)

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

Hi all,
I'm not sure about the goal here. Is it
1) to encode actual modifications found in the identified peptides / 
molecules
2) to encode the rules that the search engines are using

In the case of 1) I do not see for instance the reason for the 
"variable/fixed" item
In the case of 2) It looks difficult to encode all, as tools will even 
implement those rules in very different manner (things like maximal 
number of occurences per peptide, or more non-explicit searches like the 
error-tolerant search button in Mascot, or the default list of mods in 
Paragon / Modiro etc)

Maybe we should do both, but in different manners.

Please clarify here...
Pierre-Alain

Martin Eisenacher wrote:
> Hi from Bochum!
>
> Find attached a schema draft of a
> <ModificationParams> element with
> example.
> It is for the description of
> modification parameters of a search
> engine.
>
> Most characteristics of a modification
> (like formula or mass shift) are part
> of the PSI-MOD CV (obo cross
> references).
>
> Idea: attributes sensitivity
> (fixed/variable), masstype (mono/avg)
> and 
> origins (to specify modification sites
> explicitely);
> elements othersensitivity and
> othermasstype for extensions or special
> cases (e.g. phenyx' tolerance on
> fixed/variable type).
>
> To discuss: a special "neutral loss"
> element.
>
>   Bye
>     Martin
>   
> ------------------------------------------------------------------------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!--W3C Schema generated by XMLSpy v2007 sp1 (http://www.altova.com)-->
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> 	<xs:complexType name="cvParamType" abstract="false">
> 		<xs:attribute name="cvRef" type="xs:string" use="required">
> 		</xs:attribute>
> 		<xs:attribute name="accession" type="xs:string" use="required">
> 		</xs:attribute>
> 		<xs:attribute name="value" type="xs:string">
> 		</xs:attribute>
> 		<xs:attribute name="name" type="xs:string" use="required">
> 		</xs:attribute>
> 		<xs:attribute name="unitAccession" type="xs:string">
> 		</xs:attribute>
> 		<xs:attribute name="unitName" type="xs:string">
> 		</xs:attribute>
> 	</xs:complexType>
> 	<xs:element name="cvParam" type="cvParamType" abstract="false"/>
> 	<xs:element name="othersensitivity">
> 		<xs:annotation>
> 			<xs:documentation>Specify extensions to "fixed" and "variable" or specify other sensitivities (using CV).</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element ref="cvParam"/>
> 			</xs:sequence>
> 		</xs:complexType>
> 	</xs:element>
> 	<xs:element name="othermasstype">
> 		<xs:annotation>
> 			<xs:documentation>Specify extensions to "monoisotopic" or "averageisotopic" or specify other mass types (using CV).</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element ref="cvParam"/>
> 			</xs:sequence>
> 		</xs:complexType>
> 	</xs:element>
> 	<xs:element name="oneModificationParam">
> 		<xs:annotation>
> 			<xs:documentation>Details of one modification parameter (most characteristics contained in PSI-MOD CV !).</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element ref="cvParam"/>
> 				<xs:element ref="othersensitivity" minOccurs="0"/>
> 				<xs:element ref="othermasstype" minOccurs="0"/>
> 			</xs:sequence>
> 			<xs:attribute name="identifier" use="required">
> 				<xs:simpleType>
> 					<xs:restriction base="xs:string">
> 					</xs:restriction>
> 				</xs:simpleType>
> 			</xs:attribute>
> 			<xs:attribute name="sensitivity" use="required">
> 				<xs:annotation>
> 					<xs:documentation>Specify whether modification occurs always ("fixed") or sometimes ("variable"). If "other", sub-element othersensitivity must be present.</xs:documentation>
> 				</xs:annotation>
> 				<xs:simpleType>
> 					<xs:restriction base="xs:string">
> 						<xs:enumeration value="fixed"/>
> 						<xs:enumeration value="variable"/>
> 						<xs:enumeration value="other"/>
> 					</xs:restriction>
> 				</xs:simpleType>
> 			</xs:attribute>
> 			<xs:attribute name="masstype" use="required">
> 				<xs:annotation>
> 					<xs:documentation>Specify whether mass type is monoisotopic or avergaeisotopic. If "other", sub-element othermasstype must be present.</xs:documentation>
> 				</xs:annotation>
> 				<xs:simpleType>
> 					<xs:restriction base="xs:string">
> 						<xs:enumeration value="monoisotopic"/>
> 						<xs:enumeration value="averageisotopic"/>
> 						<xs:enumeration value="other"/>
> 					</xs:restriction>
> 				</xs:simpleType>
> 			</xs:attribute>
> 			<xs:attribute name="origins" use="optional">
> 				<xs:annotation>
> 					<xs:documentation>Possible sites (amino acids).</xs:documentation>
> 				</xs:annotation>
> 				<xs:simpleType>
> 					<xs:restriction base="xs:string"/>
> 				</xs:simpleType>
> 			</xs:attribute>
> 		</xs:complexType>
> 	</xs:element>
> 	<xs:element name="ModificationParamsExamples">
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element ref="ModificationParams"/>
> 			</xs:sequence>
> 		</xs:complexType>
> 	</xs:element>
> 	<xs:element name="ModificationParams">
> 		<xs:annotation>
> 			<xs:documentation>Set of all modification parameters used for a spectrum search.</xs:documentation>
> 		</xs:annotation>
> 		<xs:complexType>
> 			<xs:sequence>
> 				<xs:element ref="oneModificationParam" maxOccurs="unbounded"/>
> 			</xs:sequence>
> 		</xs:complexType>
> 	</xs:element>
> </xs:schema>
>   
> ------------------------------------------------------------------------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- edited with XMLSpy v2007 sp1 (http://www.altova.com) by eisenach (MPC) -->
> <ModificationParamsExamples xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=".\modifications_temp.xsd">
> 	<ModificationParams>
> 		<oneModificationParam identifier="Oxidation_M_NL80" sensitivity="variable" masstype="monoisotopic">
> 			<cvParam accession="MOD:00768" name="methionine oxidation with neutral loss of 80 Da" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 		<oneModificationParam identifier="Oxidation_M_NL64" sensitivity="variable" masstype="monoisotopic">
> 			<cvParam accession="MOD:00935" name="methionine oxidation with neutral loss of 64 Da" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 		<oneModificationParam identifier="Carbamido" sensitivity="fixed" masstype="monoisotopic" origins="C"> <!-- MOD:00397 has possible origins H, K, C, E, D -->
> 			<cvParam accession="MOD:00397" name="iodoacetamide derivative" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 		<oneModificationParam identifier="Phospho_S" sensitivity="fixed" masstype="monoisotopic">
> 			<cvParam accession="MOD:00046" name="O-phosphorylated L-serine" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 		<oneModificationParam identifier="Phospho_T" sensitivity="fixed" masstype="monoisotopic">
> 			<cvParam accession="MOD:00047" name="O-phosphorylated L-threonine" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 		<oneModificationParam identifier="Phospho_Y" sensitivity="fixed" masstype="monoisotopic">
> 			<cvParam accession="MOD:00048" name="O4'-phosphorylated L-tyrosine" cvRef="PSI-MOD"/>
> 		</oneModificationParam>
> 	<!-- example for "other" elements: phenyx -->
> 		<oneModificationParam identifier="Fantasy" sensitivity="fixed" masstype="averageisotopic" >
> 			<cvParam accession="" name="Fantasy" cvRef="PSI-MOD"/>
> 			<othersensitivity>
> 				<cvParam accession="" name="phenyx-tolerance" cvRef="PSI-MOD" value="n-1"/>
> 			</othersensitivity>
> 			<othermasstype>
> 				<cvParam accession="" name="SomethingVerySpecial" cvRef="PSI-MOD"  value="" unitAccession="" unitName=""/>
> 			</othermasstype>
> 		</oneModificationParam>
> 	</ModificationParams>
> </ModificationParamsExamples>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>   

[Psidev-pi-dev] Vacancy: editor required for the Proteomics Informatics group

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

Hi all,

We have a requirement for an editor for the Proteomics Informatics 
group. The editor is responsible for checking that the documentation 
etc. is suitable and sufficient to be put through the PSI document 
process. There has been one nomination for this: Martin Eisenacher

If anybody else would like to be considered for the role, please contact 
me off list by end of Wednesday 4th June. (dc...@ma...)


Org chart is here:
http://psidev.info/index.php?q=node/202

Thanks,

David

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

[Psidev-pi-dev] Minutes, Teleconference 29 May 2008

[Phil J. @ E. <pj...@eb...>]

Hi,

Please find the minutes for this teleconference here:

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

Could attendees please check these minutes - they can be modified in place
if you log in first.

best regards,

Phil.

-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones

[Psidev-pi-dev] (no subject)

[Martin E. <mar...@ru...>]

Hi from Bochum!

Find attached a schema draft of a
<ModificationParams> element with
example.
It is for the description of
modification parameters of a search
engine.

Most characteristics of a modification
(like formula or mass shift) are part
of the PSI-MOD CV (obo cross
references).

Idea: attributes sensitivity
(fixed/variable), masstype (mono/avg)
and 
origins (to specify modification sites
explicitely);
elements othersensitivity and
othermasstype for extensions or special
cases (e.g. phenyx' tolerance on
fixed/variable type).

To discuss: a special "neutral loss"
element.

  Bye
    Martin

[Psidev-pi-dev] PSI-PI Working group conference call on Thursday 28th May at 4:00pm UK time

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

Hi everyone,

There will be an AnalysisXML working group conference call tomorrow 
(Thursday) at:
http://www.timeanddate.com/worldclock/fixedtime.html?day=28&month=5&year=2008&hour=16&min=0&sec=0&p1=136

Minutes of last meeting at:

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


Latest schema etc. at:
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/


Agenda:
1. Review minutes of last meeting

2. Issue numbers 26(+5), 24,
http://code.google.com/p/psi-pi/issues/list

2. Continue with review of the Excel spreadsheet to decide what needs to
be attributes and what needs to be CV. The spreadsheet has been updated
since the last meeting:

http://code.google.com/p/psi-pi/source/browse/trunk/cv/search_engine_outputs_2008May28.xls

You may want to download and have this available for the teleconference.


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

access code: 297427

-- 
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] analysis tree

[Martin E. <mar...@ru...>]

OK, difficult to track this discussion.
 
Summary:
1. longer chain of analyses (as
discussed by Andy): not modeled, all
okay
2. data filtering issue (my use case:
quality assessment): its parameters and
results are currently modeled "next to"
peptide and protein detection (I will
start a discussion on that later, when
my use case is assembled ;-) )
3. tree-like structure of (protein)
analyses: is currently possible, makes
sense (Angel) / no sense (Andy)
 
My opinion:
I (of course) do not insist on an
"actual analysis" attribute;
I can imagine two possibilities:
i) problem could be ignored in the
schema and judged later by a "semantic
validator" as "wrong"; 
ii) if we generally want to forbid that,
we could allow zero or one ProteinDetect
under AnalysisCollection.
 
With ii) we can have EITHER one spectrum
ident OR many spectrum idents OR one
spectrum ident and one protein detect OR
many spectrum idents and one protein
detect.
 
That is "a bit" workflow, but without
tree-like protein analyses. I would
prefer that to the file solution
suggested by Angel,
because ontologies, databases, samples,
. are not doubled and we have less
problems with moving results
(partial file copy or uploading into
database).
 
My intuition is, that quantification
fits into that suggestion, but that is
no argument at the moment. ;-)
 
Bye
   Martin
 
 
 
Von:
psi...@li...urceforge.
net
[mailto:psi...@li...ur
ceforge.net] Im Auftrag von Angel
Pizarro
Gesendet: Wednesday, May 28, 2008 2:43
PM
An: Jones, Andy
Cc: psi...@li...
Betreff: Re: [Psidev-pi-dev] analysis
tree
 
On Wed, May 28, 2008 at 7:33 AM, Jones,
Andy <And...@li...>
wrote:
No I mean that there should be a generic
DataFiltering protocol to define
arbitrary data filtering operations. And
yes, we need some examples of this for
the CV and schema.
 
But then this gets back to the problem
that Martin highlighted of having
multiple peptide and protein sets within
one file...
 
PeptideSet1 --> DataFiltering -->
PeptideSet2
PeptideSet2 --> ProteinDetection -->
ProteinSet1
ProteinSet1 --> DataFiltering -->
ProteinSet2 
 
Where ProteinSet2 is the "final"
results...
 
Simply reconstructing this graph states
what most would call "final" is
ProteinSet2. Martin's example was more
ambiguous:

PeptideSet1 -> ProteinDetection1 ->
ProteinSet1
PeptideSet1 -> ProteinDetection2 ->
ProteinSet2

Reconstructing this graph would in no
way tell you what the author of the file
meant to be their canonical result.
There is no amount of  schema or CV
encoding that will automatically
disambiguate this for all cases, other
than a simple label which Martin
proposes. Frankly I think that while it
would "work" it is not such a good idea
to create a set schema element to
essentially encourage bad encoding of
results. 

BTW, FuGE has the same issue. All the
results are valid results and can stand
on their own. Ultimately it is the
consumer  that will determine what to
label as "final".
 
A way to get rid of all of these issues
from axml is to move it even closer to
mzML and not encode any workflow. A file
would restrict itself to just a single
node of a workflow that references into
some input file. E.g. (nodes are
individual files):
 
mzML1 -> axml1 (peptide ids : mascot)
mzML1 -> axml2 (peptide ids : sequest)
axml1 -> axml3 (protein determination :
mascot)
[axml1, axm2] -> axml5 (peptide
determination : peptideprophet)
axml5 -> axml6 (protein determination :
proteinprophet)
 etc. etc.
 
In this case the final result is a file
and as such unambiguously encoded. 
 
-angel
 

Re: [Psidev-pi-dev] analysis tree

[Angel P. <an...@ma...>]

On Wed, May 28, 2008 at 7:33 AM, Jones, Andy <And...@li...>
wrote:

>  No I mean that there should be a generic DataFiltering protocol to define
> arbitrary data filtering operations. And yes, we need some examples of this
> for the CV and schema.
>
>
>
> But then this gets back to the problem that Martin highlighted of having
> multiple peptide and protein sets within one file...
>
>
>
> PeptideSet1 à DataFiltering à PeptideSet2
>
> PeptideSet2 à ProteinDetection à ProteinSet1
>
> ProteinSet1 à DataFiltering à ProteinSet2
>

>
> Where ProteinSet2 is the "final" results...
>
>
>
Simply reconstructing this graph states what most would call "final" is
ProteinSet2. Martin's example was more ambiguous:

PeptideSet1 -> ProteinDetection1 -> ProteinSet1
PeptideSet1 -> ProteinDetection2 -> ProteinSet2

Reconstructing this graph would in no way tell you what the author of
the file meant to be their canonical result. There is no amount of
 schema or CV encoding that will automatically disambiguate this for all
cases, other than a simple label which Martin proposes. Frankly I think that
while it would "work" it is not such a good idea to create a set schema
element to essentially encourage bad encoding of results.

BTW, FuGE has the same issue. All the results are valid results and
can stand on their own. Ultimately it is the consumer
 that will determine what to label as "final".

A way to get rid of all of these issues from axml is to move it even closer
to mzML and not encode any workflow. A file would restrict itself to just a
single node of a workflow that references into some input file. E.g. (nodes
are individual files):

mzML1 -> axml1 (peptide ids : mascot)
mzML1 -> axml2 (peptide ids : sequest)
axml1 -> axml3 (protein determination : mascot)
[axml1, axm2] -> axml5 (peptide determination : peptideprophet)
axml5 -> axml6 (protein determination : proteinprophet)
 etc. etc.

In this case the final result is a file and as such unambiguously encoded.

-angel

Re: [Psidev-pi-dev] analysis tree

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

No I mean that there should be a generic DataFiltering protocol to define arbitrary data filtering operations. And yes, we need some examples of this for the CV and schema.

 

But then this gets back to the problem that Martin highlighted of having multiple peptide and protein sets within one file...

 

PeptideSet1 à DataFiltering à PeptideSet2

PeptideSet2 à ProteinDetection à ProteinSet1

ProteinSet1 à DataFiltering à ProteinSet2

 

Where ProteinSet2 is the “final” results...

 

 

 

From: an...@it... [mailto:an...@it...] On Behalf Of Angel Pizarro
Sent: 28 May 2008 12:30
To: Jones, Andy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] analysis tree

 

 

On Wed, May 28, 2008 at 7:25 AM, Jones, Andy <And...@li...> wrote:

I do ;-)  and am right there with you. Although to get at the question of user-defined thresholding, that in itself is an analysis, and should be communicated as such in the protocol + params.

 

You mean peptide thresholding in the SpectrumIdentificationProtocol and protein thresholding in the ProteinDetectionProtocol? If so, we need examples of how this can be done using cvParams...

No I mean that there should be a generic DataFiltering protocol to define arbitrary data filtering operations. And yes, we need some examples of this for the CV and schema. 
-angel 
 

	 

	 

	 

	 

	From: an...@it... [mailto:an...@it...] On Behalf Of Angel Pizarro
	Sent: 28 May 2008 12:17
	To: Jones, Andy

	
	Cc: psi...@li...
	Subject: Re: [Psidev-pi-dev] analysis tree

	 

	On Wed, May 28, 2008 at 7:11 AM, Jones, Andy <And...@li...> wrote:

		 

		Therefore, my vote is that we only support use case 1. This means that if someone wants to communicate a complete set of possible peptide / proteins (including decoys / likely false positives), it can be done, but this would be a separate file from their "final result set".

		 

		Does everyone see what I'm getting at...?

	
	I do ;-)  and am right there with you. Although to get at the question of user-defined thresholding, that in itself is an analysis, and should be communicated as such in the protocol + params. 
	
	-angel  

		 

		Cheers

		Andy

		 

		 

		 

		 

		 

		 

		 

		From: psi...@li... [mailto:psi...@li...] On Behalf Of Angel Pizarro
		Sent: 27 May 2008 16:53
		To: Martin Eisenacher
		Cc: psi...@li...
		Subject: Re: [Psidev-pi-dev] analysis tree

		 

		Still don't agree with this. In your last slide, both of the protein determinations are the result IMHO. 

		 

		If you want to highlight one or the other as "The Result" , create a file w/ just that analysis.

		 

		-angel

		 

		 

		On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <mar...@ru...> wrote:

		Dear colleagues!
		
		In the last Telecon I tried(!) to
		argument for an attribute marking the
		"actual" analysis of an AnalysisXML
		file.
		
		We agreed to let me assemble some
		descriptive slides (attached).
		
		I hope, with them my point gets more
		clear. I think it is not
		only a philosophical question, because
		it has consequences for programming,
		tools and databases...
		
		 Bye
		  Martin
		
		-------------------------------------------------------------------------
		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2008.
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________
		Psidev-pi-dev mailing list
		Psi...@li...
		https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

		
		
		
		-- 
		Angel Pizarro
		Director, ITMAT Bioinformatics Facility
		806 Biological Research Building
		421 Curie Blvd.
		Philadelphia, PA 19104-6160
		215-573-3736 

		
		-------------------------------------------------------------------------
		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2008.
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		_______________________________________________
		Psidev-pi-dev mailing list
		Psi...@li...
		https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

	
	
	
	-- 
	Angel Pizarro
	Director, ITMAT Bioinformatics Facility
	806 Biological Research Building
	421 Curie Blvd.
	Philadelphia, PA 19104-6160
	215-573-3736 




-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736 

Re: [Psidev-pi-dev] analysis tree

[Angel P. <an...@ma...>]

On Wed, May 28, 2008 at 7:25 AM, Jones, Andy <And...@li...>
wrote:

>  I do ;-)  and am right there with you. Although to get at the question of
> user-defined thresholding, that in itself is an analysis, and should be
> communicated as such in the protocol + params.
>
>
>
> You mean peptide thresholding in the SpectrumIdentificationProtocol and
> protein thresholding in the ProteinDetectionProtocol? If so, we need
> examples of how this can be done using cvParams...
>
> No I mean that there should be a generic DataFiltering protocol to define
arbitrary data filtering operations. And yes, we need some examples of this
for the CV and schema.
-angel


>
>
>
>
>
>
>
>
> *From:* an...@it... [mailto:an...@it...] *On Behalf Of
> *Angel Pizarro
> *Sent:* 28 May 2008 12:17
> *To:* Jones, Andy
>
> *Cc:* psi...@li...
> *Subject:* Re: [Psidev-pi-dev] analysis tree
>
>
>
> On Wed, May 28, 2008 at 7:11 AM, Jones, Andy <And...@li...>
> wrote:
>
>
>
> Therefore, my vote is that we only support use case 1. This means that if
> someone wants to communicate a complete set of possible peptide / proteins
> (including decoys / likely false positives), it can be done, but this would
> be a separate file from their "final result set".
>
>
>
> Does everyone see what I'm getting at...?
>
>
> I do ;-)  and am right there with you. Although to get at the question of
> user-defined thresholding, that in itself is an analysis, and should be
> communicated as such in the protocol + params.
>
> -angel
>
>
>
> Cheers
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* psi...@li... [mailto:
> psi...@li...] *On Behalf Of *Angel Pizarro
> *Sent:* 27 May 2008 16:53
> *To:* Martin Eisenacher
> *Cc:* psi...@li...
> *Subject:* Re: [Psidev-pi-dev] analysis tree
>
>
>
> Still don't agree with this. In your last slide, both of the protein
> determinations are the result IMHO.
>
>
>
> If you want to highlight one or the other as "The Result" , create a file
> w/ just that analysis.
>
>
>
> -angel
>
>
>
>
>
> On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <
> mar...@ru...> wrote:
>
> Dear colleagues!
>
> In the last Telecon I tried(!) to
> argument for an attribute marking the
> "actual" analysis of an AnalysisXML
> file.
>
> We agreed to let me assemble some
> descriptive slides (attached).
>
> I hope, with them my point gets more
> clear. I think it is not
> only a philosophical question, because
> it has consequences for programming,
> tools and databases...
>
>  Bye
>   Martin
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>
>
>
> --
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
> 806 Biological Research Building
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
> 215-573-3736
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>
>
>
> --
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
> 806 Biological Research Building
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
> 215-573-3736
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-pi-dev] analysis tree

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

I do ;-)  and am right there with you. Although to get at the question of user-defined thresholding, that in itself is an analysis, and should be communicated as such in the protocol + params.

 

You mean peptide thresholding in the SpectrumIdentificationProtocol and protein thresholding in the ProteinDetectionProtocol? If so, we need examples of how this can be done using cvParams...

 

 

 

 

From: an...@it... [mailto:an...@it...] On Behalf Of Angel Pizarro
Sent: 28 May 2008 12:17
To: Jones, Andy
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] analysis tree

 

On Wed, May 28, 2008 at 7:11 AM, Jones, Andy <And...@li...> wrote:

	 

	Therefore, my vote is that we only support use case 1. This means that if someone wants to communicate a complete set of possible peptide / proteins (including decoys / likely false positives), it can be done, but this would be a separate file from their "final result set".

	 

	Does everyone see what I'm getting at...?


I do ;-)  and am right there with you. Although to get at the question of user-defined thresholding, that in itself is an analysis, and should be communicated as such in the protocol + params. 

-angel  

	 

	Cheers

	Andy

	 

	 

	 

	 

	 

	 

	 

	From: psi...@li... [mailto:psi...@li...] On Behalf Of Angel Pizarro
	Sent: 27 May 2008 16:53
	To: Martin Eisenacher
	Cc: psi...@li...
	Subject: Re: [Psidev-pi-dev] analysis tree

	 

	Still don't agree with this. In your last slide, both of the protein determinations are the result IMHO. 

	 

	If you want to highlight one or the other as "The Result" , create a file w/ just that analysis.

	 

	-angel

	 

	 

	On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <mar...@ru...> wrote:

	Dear colleagues!
	
	In the last Telecon I tried(!) to
	argument for an attribute marking the
	"actual" analysis of an AnalysisXML
	file.
	
	We agreed to let me assemble some
	descriptive slides (attached).
	
	I hope, with them my point gets more
	clear. I think it is not
	only a philosophical question, because
	it has consequences for programming,
	tools and databases...
	
	 Bye
	  Martin
	
	-------------------------------------------------------------------------
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2008.
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________
	Psidev-pi-dev mailing list
	Psi...@li...
	https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

	
	
	
	-- 
	Angel Pizarro
	Director, ITMAT Bioinformatics Facility
	806 Biological Research Building
	421 Curie Blvd.
	Philadelphia, PA 19104-6160
	215-573-3736 

	
	-------------------------------------------------------------------------
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2008.
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________
	Psidev-pi-dev mailing list
	Psi...@li...
	https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev




-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736 

Re: [Psidev-pi-dev] analysis tree

[Angel P. <an...@ma...>]

On Wed, May 28, 2008 at 7:11 AM, Jones, Andy <And...@li...>
wrote:

>
> Therefore, my vote is that we only support use case 1. This means that if
> someone wants to communicate a complete set of possible peptide / proteins
> (including decoys / likely false positives), it can be done, but this would
> be a separate file from their "final result set".
>
>
>
> Does everyone see what I'm getting at...?
>
>
I do ;-)  and am right there with you. Although to get at the question of
user-defined thresholding, that in itself is an analysis, and should be
communicated as such in the protocol + params.

-angel

>
>
> Cheers
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* psi...@li... [mailto:
> psi...@li...] *On Behalf Of *Angel Pizarro
> *Sent:* 27 May 2008 16:53
> *To:* Martin Eisenacher
> *Cc:* psi...@li...
> *Subject:* Re: [Psidev-pi-dev] analysis tree
>
>
>
> Still don't agree with this. In your last slide, both of the protein
> determinations are the result IMHO.
>
>
>
> If you want to highlight one or the other as "The Result" , create a file
> w/ just that analysis.
>
>
>
> -angel
>
>
>
>
>
> On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <
> mar...@ru...> wrote:
>
> Dear colleagues!
>
> In the last Telecon I tried(!) to
> argument for an attribute marking the
> "actual" analysis of an AnalysisXML
> file.
>
> We agreed to let me assemble some
> descriptive slides (attached).
>
> I hope, with them my point gets more
> clear. I think it is not
> only a philosophical question, because
> it has consequences for programming,
> tools and databases...
>
>  Bye
>   Martin
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>
>
>
> --
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
> 806 Biological Research Building
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
> 215-573-3736
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>


-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-pi-dev] analysis tree

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

Hi Martin,

 

Thanks for your slides clarifying this issue. I think I tend to agree with Angel that the final result (on slide 4) is just ProteinDetection 2, what other purpose does ProteinDetection 1 serve in the file? 

 

The only use case I can come up with if ProteinDetection 1 is an intermediate set from on which some additional processing happens? However, I don’t see that we actually have a protocol structure defined in which this could be described, i.e. ProteinSet1 à ProtocolApp àProteinSet2

 

If we take this to the logical conclusion, perhaps we should restrict an AnalysisXML file to containing only 1 (or 0) ProteinDetectionLists...?

 

There is a related point that I don’t think we have addressed completely yet, which is:

“What set of peptides / proteins does the creator of the file consider to be acceptable i.e. correct according to their threshold”

 

As an example, given a protein hypothesis, it might be acceptable to report all the peptides that can be matched to this protein, even if some of the peptide identifications are very weak. Similarly, only by including a long list of proteins (e.g. including decoy proteins), can certain protein scores be calculated. 

 

So are we suggesting:

 

1)      The file contains the peptides and proteins that the file producer considers correct i.e. above a threshold

2)      Do we need to give a mechanism for reporting as much as they like (e.g. all peptides and proteins that could be correct) with a flag for saying – I consider these to be correct and, for example, you should only load these into a database...

 

I think supporting use case 2 is actually very difficult because communicating a threshold is not simple - thresholds can be set on peptides, proteins, protein ambiguity groups, with interrelations between these e.g. ProteinProphet alters peptide probabilities based on protein level evidence. 

 

Therefore, my vote is that we only support use case 1. This means that if someone wants to communicate a complete set of possible peptide / proteins (including decoys / likely false positives), it can be done, but this would be a separate file from their “final result set”.

 

Does everyone see what I’m getting at...?

 

Cheers

Andy

 

 

 

 

 

 

 

From: psi...@li... [mailto:psi...@li...] On Behalf Of Angel Pizarro
Sent: 27 May 2008 16:53
To: Martin Eisenacher
Cc: psi...@li...
Subject: Re: [Psidev-pi-dev] analysis tree

 

Still don't agree with this. In your last slide, both of the protein determinations are the result IMHO. 

 

If you want to highlight one or the other as "The Result" , create a file w/ just that analysis.

 

-angel

 

 

On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <mar...@ru...> wrote:

Dear colleagues!

In the last Telecon I tried(!) to
argument for an attribute marking the
"actual" analysis of an AnalysisXML
file.

We agreed to let me assemble some
descriptive slides (attached).

I hope, with them my point gets more
clear. I think it is not
only a philosophical question, because
it has consequences for programming,
tools and databases...

 Bye
  Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-pi-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev




-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736 

[Psidev-pi-dev] Issues List

[Angel P. <an...@ma...>]

A friendly reminder for folks to check out and comment on issues in the
issues list. We need feedback in order to progress!

http://code.google.com/p/psi-pi/issues/list
Thanks
-angel

-- 
Angel Pizarro

Re: [Psidev-pi-dev] analysis tree

[Angel P. <an...@ma...>]

Still don't agree with this. In your last slide, both of the protein
determinations are the result IMHO.
If you want to highlight one or the other as "The Result" , create a file w/
just that analysis.

-angel

On Tue, May 27, 2008 at 11:42 AM, Martin Eisenacher <
mar...@ru...> wrote:

> Dear colleagues!
>
> In the last Telecon I tried(!) to
> argument for an attribute marking the
> "actual" analysis of an AnalysisXML
> file.
>
> We agreed to let me assemble some
> descriptive slides (attached).
>
> I hope, with them my point gets more
> clear. I think it is not
> only a philosophical question, because
> it has consequences for programming,
> tools and databases...
>
>  Bye
>    Martin
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>
>


-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

[Psidev-pi-dev] analysis tree

[Martin E. <mar...@ru...>]

Dear colleagues!

In the last Telecon I tried(!) to
argument for an attribute marking the
"actual" analysis of an AnalysisXML
file.

We agreed to let me assemble some
descriptive slides (attached).

I hope, with them my point gets more
clear. I think it is not
only a philosophical question, because
it has consequences for programming,
tools and databases...

  Bye
   Martin

[Psidev-pi-dev] description of cleavage enzyme

[Martin E. <mar...@ru...>]

Hi!

Currently we are discussing how to
describe search engine parameters
(schema attributes, elements, CV
params).

To describe the behavior of a cleavage
enzyme (spectrum identification via
database search) we shall discuss the
attached schema with examples, derived
from the Excel spreadsheet
http://code.google.com/p/psi-pi/source/b
rowse/trunk/cv/search_engine_outputs_200
8May19.xls and phenyx / insilicospectro
(Pierre-Alains Mail 5/21/2008). See
schema annotations for further
explanation.

Instead of the <site> element the schema
allows a <siteregexp> element, allowing
a short description of complex cleavage
rules.

Bye
  Martin


Trypsin:
	<cleavageEnzymes>
		<oneCleavageEnzyme
identifier="Trypsin_(KR_noP)">
	
<cleavageEnzymeNames>
				<cvParam
accession="PSI-PI:000XXX" name="Trypsin"
cvRef="PSI-PI"/>
	
</cleavageEnzymeNames>
			<site
cleavPattern="K"
adjacentPatternBlocking="P"
terminus="C"/>
			<site
cleavPattern="R"
adjacentPatternBlocking="P"
terminus="C"/>
	
<CTermGain>OH</CTermGain>
	
<NTermGain>H</NTermGain>
		</oneCleavageEnzyme>
	</cleavageEnzymes>



Complex unrealistic example to show
different possibilities of cleavPattern,
cleavSite, terminus, minSpacing,
missedcleavages:
	<cleavageEnzymes>
		<oneCleavageEnzyme
identifier="Fantasy">
	
<cleavageEnzymeNames>
				<cvParam
accession="PSI-PI:000XX1" name="Fantasy"
cvRef="PSI-PI"/>
				<cvParam
accession="PSI-PI:000XX2"
name="Fantasy_synonym" cvRef="PSI-PI"/>
	
</cleavageEnzymeNames>
			<site
cleavPattern="EISI" terminus="C"/> <!--
cleave after each EISI -->
			<site
cleavPattern="SIKI" terminus="N"
minSpacing="6"/> <!-- cleave before each
SIKI; between two cleavage sites at
least 6 amino acids -->
			<site
cleavPattern="DEQQD" cleavSite="DEQQD"
terminus="C"/> <!-- cleave after each
DEQQD -->
			<site
cleavPattern="LEQ" cleavSite=""
terminus="C"/> <!-- cleave after each
LEQ -->
			<site
cleavPattern="DET" cleavSite=""
terminus="N"/> <!-- cleave before each
DET -->
			<site
cleavPattern="DQTD" cleavSite="DQT"
terminus="C"/> <!-- recognize DGTD,
cleave after the DQT of it -->
			<site
cleavPattern="ELPD" cleavSite="E"
terminus="N"/> <!-- semantic error,
because terminus must be C, if cleavSite
is given! -->
	
<CTermGain>OH</CTermGain>
	
<NTermGain>H</NTermGain>
		</oneCleavageEnzyme>
		<oneCleavageEnzyme
identifier="Trypsin">
	
<cleavageEnzymeNames>
				<cvParam
accession="PSI-PI:000456" name="Trypsin"
cvRef="PSI-PI"/>
	
</cleavageEnzymeNames>
				<site
cleavPattern="K" terminus="C"
adjacentPatternBlocking="P"/>
				<site
cleavPattern="R" terminus="C"
adjacentPatternBlocking="P"/>
	
<CTermGain>OH</CTermGain>
	
<NTermGain>H</NTermGain>
		</oneCleavageEnzyme>
	</cleavageEnzymes>

[Psidev-pi-dev] Fwd: xml keys

[Angel P. <an...@ma...>]

Forwarding to proper list. Also putting in issue tracker

---------- Forwarded message ----------
From: Angel Pizarro <an...@ma...>
Date: Wed, May 21, 2008 at 11:37 AM
Subject: xml keys
To: psi...@li...


FYI here is an excerpt from another XML schema that defines an XML
Key, as well as a reference and unique constraints on those keys:

               <xs:key name="PEOPLE_PK">
                       <xs:selector
xpath="sis:Personnel_Roster/sis:Investigator/sis:Commons_Username"/>
                       <xs:field xpath="."/>
               </xs:key>
               <xs:keyref name="MENTOR_NOT_IN_ROSTER_FK"
refer="sis:PEOPLE_PK">
                       <xs:selector
xpath="sis:Personnel_Roster/*/sis:Mentor_Commons_Username"/>
                       <xs:field xpath="."/>
               </xs:keyref>
               < xs:keyref name="PI_NOT_IN_ROSTER_FK" refer="sis:PEOPLE_PK">
                       <xs:selector xpath="sis:Grant_Info"/>
                       <xs:field xpath="sis:PI_Commons_Username"/>
               </xs:keyref>
               <xs:unique name="PUBLICATION_NOT_UNIQ_UK">
                       <xs:selector
xpath="sis:Publications/sis:Publication"/>
                       <xs:field xpath="sis:PubMed_ID"/>
               </xs:unique>
               <xs:unique
name="COMMONS_USERNAME_NOT_UNIQ_IN_PERSONNEL_ROSTER">
                       <xs:selector
xpath="sis:Personnel_Roster/*/sis:Commons_Username"/>
                       <xs:field xpath="."/>
               </xs:unique>

-angel



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

[Psidev-pi-dev] Change to cvParam and userParam in MzML 0.99.12 schema

[Phil J. @ E. <pj...@eb...>]

Hi,

Just a heads-up that the mzML developers have just modified the cvParam &
userParam element design, with the addition of a reference to the unit CV.
(See mail below).  Presumably we will include this change in analysisXML
too.

Best regards,

Phil.

---------- Forwarded message ----------
From: Matthew Chambers <mat...@va...>
Date: 2008/5/22
Subject: [Psidev-ms-dev] MzML 0.99.12 schema update
To: Mass spectrometry standard development <
psi...@li...>


- added unitCvRef to cvParam and userParam
- added sourceFileRef, externalNativeID, and externalSpectrumID to
PrecursorType

-Matt

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev



-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 21st May at 4:00pm UK time

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

Hi Angel,

Angel Pizarro wrote:
> On Tue, May 20, 2008 at 6:14 AM, David Creasy <dc...@ma... 
> <mailto:dc...@ma...>> wrote:
> 
>     Agenda:
>     1. Review protein grouping example at:
> 
>     http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working19May/F001350.xml
> 
> 
> Several issues with this example. First listed peptides are duplicated 
> in places. Simple to edit the example to fix this.
Ah yes, thank-you. This is generated by a script, so I'll just change 
the script to not output duplicates...

However, there will be more peptides because, for the prophets and 
Scaffold, they need to see a larger number of hits (and misses!) to get 
stats.

> 
> Second the "identifier" attribute (in the FuGE sense) should be as close 
> to a GUID as possible, allowing references from other documents (or into 
> this document) using solely the identifier.  "3_1" does not do this. 
> Also there are other places in the document where the same string is 
> used to identify different object types. 
Yes, I agree and I'll change this - maybe by adding a prefix for the 
different 'types' if that sounds reasonable?

> 
> Choices are to fix this in the examples and make this clear to the 
> world, or encode this usage more forcefully within the schema.
Not sure how we'd enforce in the schema? Maybe discuss at the telecon?

(btw, Last week, we decided that meaningful names weren't important for 
the IDs)

David
> 
> -angel

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

[Psidev-pi-dev] FW: Minutes?

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

This structure looks good to me. I’ve forwarded to the PSI list.

Andy

 

From: phi...@go... [mailto:phi...@go...] On Behalf Of Phil Jones @ EBI
Sent: 21 May 2008 12:29
To: Jones, Andy; David Creasy; Martin Eisenacher; Angel Pizarro; Sean L Seymour
Subject: Re: Minutes?

 

Hi,

OK, so the example in the minutes was a little off the top of my head.  Having thought a little more carefully about it, how about something like this (The example is silly, but perhaps it scales well and is easy to understand?):

<filters>
    <filter>
        <filterType>
            <cvParam accession="PI:000NNN" name="taxonomy-filter" cvRef="PSI-PI" value=""/>
        </filterType>
        <include>
            <cvParam accession="9606" name="Homo sapiens" cvRef="NEWT"/>
            <cvParam accession="9031" name="Gallus gallus" cvRef="NEWT"/>
        </include>
        <exclude>
            <cvParam accession="10088" name="Mus" cvRef="NEWT"/>
        </exclude>
    </filter>
<filters>

best regards,

Phil.

PS - We seem to be in the habit of ignoring the mailing list for these discussions?




2008/5/21 Jones, Andy <And...@li...>:

Something like this I think

 

    <Filters>
          <Filter>
            <_role>
                  <pf:cvParam accession="PI:00015" name="inclusive" cvRef="PSI-PI" value=""/>


            </_role>
            <_filterValue>
             <pf:cvParam accession="PI:00015" name="database taxonomy filter" cvRef="PSI-PI" value="All entries"/>

            </_filterValue>
          </Filter>
        </Filters>

 

 

 

From: David Creasy [mailto:dc...@ma...] 
Sent: 21 May 2008 12:13
To: Phil Jones @ EBI
Cc: Jones, Andy; Martin Eisenacher; Angel Pizarro; Sean L Seymour
Subject: Re: Minutes?

 

Phil,

>From the minutes (and now in the schema), I don't understand how to use

<Filters>
     <Filter>
         <Role> <CvParam....> </Role>
         <Values / Options??> <CvParam/> <CvParam/> </Values>
     </Filter>
</Filters>


In the example file I've put up, I probably don't have what you intended:
        <Filters>
          <Filter>
            <_role>
              <pf:cvParam accession="PI:00015" name="database taxonomy filter" cvRef="PSI-PI" value="All entries"/>
            </_role>
            <_filterValue>
              <pf:cvParam accession="" name="" cvRef=""/>
            </_filterValue>
          </Filter>
        </Filters>

Can you give an example. (I recollect the requirement for include and exclude lists)

Thanks,
David

Jones, Andy wrote: 

Okay, done it's posted here: http://code.google.com/p/psi-pi/source/browse/trunk/schema/InheritedFromFuGE.xls

 

And I've added a link in the related issue (19) in the issues list,

Cheers

Andy

 

 

From: phi...@go... [mailto:phi...@go...] On Behalf Of Phil Jones @ EBI
Sent: 21 May 2008 11:57
To: Jones, Andy
Cc: Martin Eisenacher; David Creasy; Angel Pizarro; Sean L Seymour
Subject: Re: Minutes?

 

Hi Andy,

I would suggest sticking it into the SVN repository and linking to the head version from the PSI-PI pages so that the link will always point to the latest version.

Best regards,

Phil.

2008/5/21 Jones, Andy <And...@li...>:

Hi all,

 

I've created an Excel file showing for each of the global element in the current schema what is inherited from FuGE (attached). It would be useful to spend a few minutes of the call discussing it. It's not obvious to me where I can post this on the PSI-PI site, I don't seem to be able to attach a file to a specific issue – any ideas?

Cheers

Andy

 

 

From: Martin Eisenacher [mailto:mar...@ru...] 
Sent: 21 May 2008 08:40
To: Jones, Andy; 'David Creasy'
Cc: 'Angel Pizarro'; 'Phil Jones @ EBI'; 'Sean L Seymour'
Subject: AW: Minutes?

 

I vote for dropping the „_something" style. 

Everytime I saw a PSI newby (but knowing XML) looking at an AnalysisXML use case, he/she was confused, whether the "_"

is coding something.

 

Bye

   Martin

 

 

Von: Jones, Andy [mailto:And...@li...] 

Gesendet: Monday, May 19, 2008 5:57 PM
An: David Creasy

Cc: Angel Pizarro; Phil Jones @ EBI; Martin Eisenacher; Sean L Seymour

Betreff: RE: Minutes?

 

I think I've made all the changes (and one or two related changes on cardinalities etc.). I haven't had time to go through the whole schema checking all cardinalities so you'll likely find a few more than are not right. Feel free to mail me any more changes – it's v easy to do!

 

> Also,  <_analysisSoftwares> can only have one software package.
and maybe it should be AnalysisSoftwareList?

 

I've made this change although we should take a systematic decision about naming. There is a FuGE-related reason for having the "_something" style names in that in the object model these were derived from associations between UML classes, whereas all other XML elements were derived from a UML class itself. Given that the model is getting further away from being a true FuGE extension (and is unlikely to be able to make use of any FuGE related software) we can probably get rid of all the "_something" style names.

 

Cheers

Andy

 

 

From: David Creasy [mailto:dc...@ma...] 
Sent: 19 May 2008 16:00
To: Jones, Andy
Cc: Angel Pizarro; Phil Jones @ EBI; Martin Eisenacher; Sean L Seymour
Subject: Re: Minutes?

 

Also,  <_analysisSoftwares> can only have one software package.
and maybe it should be AnalysisSoftwareList?

<SpectrumIdentificationProtocol  Software_ref 
   should be:
<SpectrumIdentificationProtocol  AnalysisSoftware_ref 


(Sorry, I'll shut up soon!)



David Creasy wrote: 

Thanks. 

Also, can only have one cvparam inside each PeptideEvidence. Not sure if this is intentional, and I can't currently think why you might want more...

Jones, Andy wrote: 

I'll try get a new version out by the end of the day to fix these...

cheers

Andy

 

 

From: David Creasy [mailto:dc...@ma...] 
Sent: 19 May 2008 14:34
To: Jones, Andy
Cc: Angel Pizarro; Phil Jones @ EBI; Martin Eisenacher; Sean L Seymour
Subject: Re: Minutes?

 

Thanks Andy,

I no longer seem to be able to have  a ProteinDetectionList and a SpectrumIdentificationList in the same AnalysisXML document. Have I misunderstood something? This is no good:
  <AnalysisData>
    <SpectrumIdentificationList identifier="Peptides">
      ...
    <.SpectrumIdentificationList>
    <ProteinDetectionList ...?
      ...
    </ProteinDetectionList>
  </AnalysisData>

And how do I add two ontologies: psi-pi and mod?

And a couple of minor points:
ProtocolDetectionResultSet_ref should be ProteinDetectionResultSet_ref ?

-          Changed "Sets" to "Lists" 
But missed a couple of references:
SpectrumIdentificationSet_ref
ProtocolDetectionResultSet_ref


Thanks,
David

Jones, Andy wrote: 

Ok new version of the schema attached with changes from yesterday's call.

 

Main changes:

 

Some changes to the collection classes reachable from the AnalysisXML root element

"DataCollection" à "_dataCollection"  which has specific references to types of data e.g. InputFile, SpectralData and AnalysisResults; this prevents general FuGE classes for Internal and ExternalData from being used and makes it simpler to understand where particular data files should be specified

Added _analysisSampleCollection with reference to FuGE GenericMaterial. We should test if this work for representing samples, otherwise we can build our own extension of Material

Added a new extension of Software which allows Customizations to be specified reachable from _analysisSoftwares (can we change this to _analysisSoftware?)

We should discuss the order of the collection classes – we can shift these around if a more logical order is preferred?

Extended SearchDatabase with the attributes / elements discussed on the call

Adapted Protein grouping as discussed

Username / email etc has not been added. This can be done with the FuGE Provider type which is already referenced. We can change this to the mzML specification if preferred?

Changed "Sets" to "Lists"

FeatureSet is still in the schema for now but not reachable from the root i.e. it can't make it into an instance document. I can get rid of completely if we want.

 

I've attached a (mainly) auto-generated XML annotated with a few notes to demonstrate the main changes. Let me know if there's any problems. Likely to be a few mistakes with cardinalities etc.

Cheers

Andy

 

From: an...@it... [mailto:an...@it...] On Behalf Of Angel Pizarro
Sent: 16 May 2008 14:39
To: Phil Jones @ EBI
Cc: Jones, Andy; David Creasy; Martin Eisenacher; Sean L Seymour
Subject: Re: Minutes?

 

This is the structure (copied from openms) for identifying feature sets for quantification experiments. Not needed for v1 if indeed there will not be quantification there. -angel

On Fri, May 16, 2008 at 9:35 AM, Phil Jones @ EBI <pj...@eb...> wrote:

Hi Andy,

This was an attempt to implement a general solution for quantitation, based upon the existing schema used by the openMS team.  I suspect that it can be removed for the moment while we work on a robust solution.  (Feature / convex hull is the concept that Andreas Bertsch described in his presentation at Toledo).

best regards,

Phil.

2008/5/16 Jones, Andy <And...@li...>:

	 

	I'm doing a bit more of a thorough job tidying up the schema and re-arranging a few things to make it a bit simpler to understand and navigate.

	 

	Anyone have any ideas what FeatureSet is? 

	 

	<FeatureSet>

	                <Feature>

	                                <ConvexHull>

	                                <CoordinatePoint>

	 

	Is any of this required?!

	 

	Cheers

	Andy

	 

	From: David Creasy [mailto:dc...@ma...] 

	Sent: 15 May 2008 14:28

	To: Jones, Andy
	Cc: Martin Eisenacher; Phil Jones @ EBI; Sean L Seymour
	Subject: Re: Minutes?

	 

	Hi All,
	
	
	Jones, Andy wrote: 

	Hi all

	 

	The mandatory association _types was an error in the FuGE light schema (it should have been optional), now fixed (new version to come).

	 

	<pf:_types>

	            <pf:cvParam accession="DP:4" name="" cvRef="PSI-PI"/>

	 

	The purpose of the _types association was to give the type of Protocol/Software/Equipment, however this may be confusing and used incorrectly – as in the example so perhaps it should be removed altogether from FuGE light. These parameters should be _searchParams I think?

	I'm confused...
	
	

	 

	 

	 

	<ProteinDetectionResult identifier="1" Sequence_ref="HSP7D_MANSE">

	            <ProteinDetectionHypothesis identifier="pgroup1_pdir1_pep1" Peptide_ref="put reference to peptide ID here" start="160" end="171" post="K" pre="I">

	                        <_peptideEvidence>

	 

	I agree that the current schema may be incorrect, but I think it should be:

	 

	<ProteinDetectionResult identifier="1" Sequence_ref="HSP7D_MANSE">

	 

	                <ProteinDetectionHypothesis identifier="pgroup1_pdir1_pep1" start="160" end="171" post="K" pre="I">

	                        <_peptideEvidence Peptide_ref = "3_1"/>

	                        <_peptideEvidence Peptide_ref = "4_1"/>

	 

	 

	So... 

	ProteinDetectionResult is a group of related proteins that cannot be unambiguously differentiated

	ProteinDetectionHypothesis is an individual proteins

	_peptideEvidence is the list of associations to individual peptides on which this hypothesis is based. It cannot be an attribute of ProteinDetectionHypothesis because multiple are required.

	Yes, I think this is correct. Certainly agrees with Seans' proposal:
	http://code.google.com/p/psi-pi/source/browse/trunk/examples/Use_case_Toledo_grouping_alt1_Sean.xml
	
	

	 

	Are we happy with these names, they are not very clear about the purpose of the element?

	I'm not so sure about the names either... maybe discuss at the conference call.
	
	
	

	 

	If we agree on this, I'll send out a new schema shortly?

	Yes please.
	
	

	Cheers

	Andy

	 

	 

	 

	 

	 

	 

	 

	From: Martin Eisenacher [mailto:mar...@ru...] 
	Sent: 15 May 2008 10:35
	To: 'Andy Jones'; 'David Creasy'; 'Phil Jones @ EBI'; 'Sean L Seymour'
	Subject: AW: Minutes?

	 

	Hi Andy, hi all!

	Thanks again for your schema work!

	Attached the Toledo use case corrected for the 14Mayworking schema.

	 

	Some remarks:

	pf:cvParam directly under <ProteinDetectionResultSet>: make it  optional?

	Directly under <SpectrumIdentificationProtocol>: pf:ContactRole and pf:_types look a little bit funny. Replace by pf:cvParam? Or make optional?

	<pf:ContactRole Contact_ref="">

	          <pf:_role cvParam_ref=""></pf:_role>

	</pf:ContactRole>

	<pf:_types>

	          <pf:cvParam accession="DP:4" name="" cvRef="PSI-PI"/>

	 

	 

	Andy: > As I understand it, the protein grouping works as is, with no change, correct?

	 

	I think there is one level lost from Seans original idea. The current schema lists the proteins (ProteinDetectionResult)
	and the Peptides (ProteinDetectionHypothesis).

	 

	As I understood, Sean wanted protein groups (ProteinDetectionResult) with concrete Accessions (isoforms) (ProteinDetectionHypothesis) with their corresponding
	Peptide Evidences (PeptideEvidence). For that we need a good use case as discussed earlier.

	 

	Independent from what we decide to do, the current schema is somewhat funny, because it enforces having _peptideEvidence elements with SpectrumIdentificationRef elements under

	the ProteinDetectionHypothesis element:

	<ProteinDetectionResultSet identifier="Proteins1">

	          <ProteinDetectionResult identifier="1" Sequence_ref="HSP7D_MANSE">

	                      <ProteinDetectionHypothesis identifier="pgroup1_pdir1_pep1" Peptide_ref="put reference to peptide ID here" start="160" end="171" post="K" pre="I">

	<_peptideEvidence>

	                                  <!-- DELETE? reference to peptide done with attribute! From THERE ref to spectrum-->

	                                             <SpectrumIdentificationItem_ref/>

	                                  </_peptideEvidence>

	 

	I think, the Peptide_ref attribute is sufficient, from there the spectrum is refrenced.

	 

	  Bye from Bochum

	    Martin

	 

	 

	 

	Von: Jones, Andy [mailto:And...@li...] 
	Gesendet: Wednesday, May 14, 2008 6:17 PM
	An: David Creasy; Sean L Seymour; Martin Eisenacher
	Cc: Phil Jones @ EBI
	Betreff: RE: Minutes?

	 

	Hi all,

	New version of the schema attached. Can you have a quick sanity check before posting on the list for discussion tomorrow. A few minor changes to FuGElight as well so a new schema for that is attached as well,

	Cheers

	Andy

	 

	 

	 

	 

	From: David Creasy [mailto:dc...@ma...] 
	Sent: 14 May 2008 15:17
	To: Jones, Andy; Sean L Seymour; Martin Eisenacher
	Cc: Phil Jones @ EBI
	Subject: Re: Minutes?

	 

	Andy,
	
	I'm not sure whether the minutes are sufficient for you to produce another rev. of the schema?
	For the protein grouping, I think that assuming we go with Sean's proposal we don't need to make any further changes?
	
	David
	
	
	Phil Jones @ EBI wrote: 

	Hi David,
	
	Sorry about the delay - please find them pasted below.  I will get these on to the web site this afternoon.
	
	Best regards,
	
	Phil.
	
	
	Attendees:
	
	Phil Jones
	Andy Jones
	Andreas Bertsch
	David Creasy
	Martin Eisenacher
	Julian Selley
	Jennifer Siepen
	Pierre-Alain Binz
	
	Angel sends his apologies.
	
	Minutes:
	
	1. Going through schema changes
	
	Martin has completed an updated example document.  Some comments:
	
	This new document fits the use cases described in Toledo.  Mostly changes of element names.  Currently missing is the new level required for protein ambiguity.

	*	Do we still want DeterminationResultSet?
	*	Some CV params were added 
	*	Still need a reference from the DeterminationResultSet to the Molecule.

	Andy - to follow FuGE rules, need to follow a convention to know what a ref is referring to.  The convention in FuGE is Name-of-element_ref.  It was agreed that this should be used in the existing schema.
	
	Do we need a convention for the actual identifier?  In FuGE - can be anything, as difficult to enforce.  Will stick with this policy for analysisXML.
	
	How is ambiguity encoded?  Move ProteinDetectionResult one level deeper?
	
	Explanation of requirement:  Two proteins, three peptides in common, but one different.  While the grouping may be achievable based upon references, this grouping captures associations determined by a specific algorithm.  Andy suggested that the grouping could be separated out into another data structure, that was referenced from the individual protein identifications.
	
	The final decision on this will be deferred until Sean is available - does the peptide evidence change if the grouping is done differently?
	
	Action: David to check with Sean.
	
	Example XML file has an error - the ProteinDetectionHypothesis should be PolyPeptideEvidence in file Use_case_Toledo_wo_grouping_working7May.xml.
	
	Andy: Extra classes.  Renamed elements, and already abstract classes present.  e.g. AnalysisResult - changed to AnalyteDetection. This would then be the extension point. Andy suggested the additional abstract layer should remain as an explicit extension point for future analyses.
	
	
	Going through issue list:
	
	Issue of attributes vs. elements.  Keep as current.
	
	Protein Sequence should perhaps be an element as it can be very long.  Element name 'Seq' to allow for both nucleic acid and protein sequences.
	
	Question - moving values from the CV to the schema?  David reminded the group of the original suggestion that anything that is present in two or more search engines should be in the schema. 
	
	Specific terms:
	
	Taxonomy filter
	
	Number of sequences searched - move into the schema, make optional.
	
	Mass tolerance?
	
	MIAPE requirements as candidates?  Many of these things still need CV to name them.   
	
	Pierre-Alain to send around the current version of the MIAPE documents to look for candidate data items that should be explicitly in the schema.
	
	Spectrum Reference - DONE.
	
	Martin / David to look at the current changes to mzML to ensure that spectrum refs are consistent with the latest version.
	
	Issues of cardinality.  (optional or not?)
	
	Action: Andy will reflect any agreed changes in the schema.
	
	Quality assessment analysis is missing from the list of use cases.  Need to be able to see the quality assessment e.g. false discovery rate, so this can be changed to modify the result list.  (i.e. search of randomised database.)  Input parameters are the pattern for the false proteins and the false discovery rate threshold, then report the rank of the proteins and their local false discovery estimations.  However, this could go into the normal parameters for the protein identification.
	
	Next PSI meeting at 16:00 (London time) 15 May, 2008. 

	 

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

	 

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




-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones 




-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736 

 

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

 

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

 

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




-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones 

 

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




-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones 

[Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 21st May at 4:00pm UK time

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

Hi everyone,

There will be an AnalysisXML working group conference call tomorrow 
(Wednesday, not Thursday) at:
http://www.timeanddate.com/worldclock/fixedtime.html?day=21&month=5&year=2008&hour=16&min=0&sec=0&p1=136

Agenda:
1. Review protein grouping example at:
 
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working19May/F001350.xml

which was generated from:
http://www.matrixscience.com/cgi/master_results.pl?file=../data/20080520/FInAmic.dat&_showsubsets=1


schema at:
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working19May/AnalysisXML_working19May.xsd
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working19May/FuGElight19May.xsd

Is this finally OK?
Worth searching on 'TODO' in the example document.


2. Continue with review of the Excel spreadsheet to decide what needs to 
be attributes and what needs to be CV. The spreadsheet has been updated 
since the last meeting:

http://code.google.com/p/psi-pi/source/browse/trunk/cv/search_engine_outputs_2008May19.xls

You may want to download and have this available for the teleconference.

3. If time, continue working through the current issues list at:
http://code.google.com/p/psi-pi/issues/list


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

access code: 297427

-- 
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] PSI-PI Working group conference call on Thursday 15th May at 4:00pm UK time

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

Minutes for the conference call (thanks Phil) are now available at:
http://www.psidev.info/index.php?q=node/325

Next call will be on Wednesday (rather than Thursday) next week:
http://www.timeanddate.com/worldclock/fixedtime.html?day=21&month=5&year=2008&hour=16&min=0&sec=0&p1=136 


Main item will be to continue going through the spreadsheet.


David Creasy wrote:
> Hi everyone,
> 
> There will be an AnalysisXML working group conference call tomorrow at:
> http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=5&year=2008&hour=16&min=0&sec=0&p1=136 
> 
> 
> Agenda:
> 1. Any volunteers from people going to the HUPO Congress in Amsterdam to 
> give a short presentation on AnalysisXML at the PSI plenary?
> 
> 2. Review of the Excel spreadsheet to decide what needs to be attributes 
> and what needs to be CV. The spreadsheet and .obo file are available here:
> 
> http://code.google.com/p/psi-pi/source/browse/trunk/cv/search_engine_outputs_2007Apr24.xls 
> 
> http://code.google.com/p/psi-pi/source/browse/trunk/cv/psi-pi.obo
> 
> 3. Working through the current issues list at:
> http://code.google.com/p/psi-pi/issues/list
> 
> 
> + Germany: 08001012079
> + Switzerland: 0800000860
> + UK: 08081095644
> + USA: 1-866-314-3683
> + Generic international: +44 2083222500 (UK number)
> 
> access code: 297427
> 

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

[Psidev-pi-dev] Minutes of PSI-PI Working group conference call on Thursday 15th May at 4:00pm UK time

[Phil J. @ E. <pj...@eb...>]

The minutes for today's PSI-PI Teleconference can be found at:

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

Best regards,

Phil.
-- 
Phil Jones
Senior Software Engineer
PRIDE Project Team
PANDA Group, EMBL-EBI
Wellcome Trust Genome Campus
Hinxton, Cambridge, CB10 1SD
UK.

Work phone: +44 1223 492610
Skype: philip-jones

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Thursday 15th May at 4:00pm UK time

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

Additional agenda item:
Anyone going to ASMS? - if so, we should arrange a time to meet

Thanks to Andy and Martin, there's a new schema and example file at:

http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working15May/AnalysisXML_working15May.xsd
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working15May/FuGElight15May.xsd
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_examples/working15May/Use_case_Toledo_working15May.xml

David

David Creasy wrote:
> Hi everyone,
>
> There will be an AnalysisXML working group conference call tomorrow at:
> http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=5&year=2008&hour=16&min=0&sec=0&p1=136 
>
>
> Agenda:
> 1. Any volunteers from people going to the HUPO Congress in Amsterdam 
> to give a short presentation on AnalysisXML at the PSI plenary?
>
> 2. Review of the Excel spreadsheet to decide what needs to be 
> attributes and what needs to be CV. The spreadsheet and .obo file are 
> available here:
>
> http://code.google.com/p/psi-pi/source/browse/trunk/cv/search_engine_outputs_2007Apr24.xls 
>
> http://code.google.com/p/psi-pi/source/browse/trunk/cv/psi-pi.obo
>
> 3. Working through the current issues list at:
> http://code.google.com/p/psi-pi/issues/list
>
>
> + Germany: 08001012079
> + Switzerland: 0800000860
> + UK: 08081095644
> + USA: 1-866-314-3683
> + Generic international: +44 2083222500 (UK number)
>
> access code: 297427
>

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