Suggestions for schema updates

[GoogleCodeExporter]

- PRIMARY KEY constraint for SpectraData/@id
- FOREIGN KEY constraint for SpectrumIdentificationResult/@SpectraData_ref
- FOREIGN KEY constraint for
AnalysisCollection/SpectrumIdentification/InputSpectra/@SpectraData_ref

Original issue reported on code.google.com by eisena...@googlemail.com on 16 Nov 2009 at 2:36

[GoogleCodeExporter]

Additional items discussed on the call 13/01/2011:

Pros and cons of current schema for Peptide, PeptideEvidence, PeptideHypothesis

Current schema does not enforce Peptide to be unique, hence space savings are 
generally not made and file consumer cannot process Peptide elements knowing 
how they are used (they do not even have to be used by SII).

PeptideEvidence is slightly confused as it models all mappings between a given 
peptide sequence and protein sequences, but it resides within SII. It could 
potentially reside with Peptide (but it has the attribute missedCleavage, which 
is specific to the SII). Overall, can we simplify / improve this model?

ProteinDetectionHypothesis maps via PeptideHypothesis to PeptideEvidence. If a 
protein has been identified by 1000s of peptide-spectrum matches, they would 
all need to be listed here. 

Is mzIdentML feasible for MudPIT files? 

Could we re-factor so that there are potentially big space savings if the same 
peptide is identified 1000s of times?

What structure are we planning to reference back to from mzQuantML for 
quantified peptides - SIIs, Peptide?, something else?

Original comment by a...@cuckundoorecords.com on 13 Jan 2011 at 5:41

[GoogleCodeExporter]

First topic of this issue ("comment 0") about PRIMARY KEY and FOREIGN KEY 
constraints is solved.

Original comment by eisena...@googlemail.com on 3 Apr 2011 at 2:36

[GoogleCodeExporter]

comment 1 is discussed in an own issue, so this issue is closed

Original comment by eisena...@googlemail.com on 3 Apr 2011 at 2:38

• Changed state: Fixed