mwalzer / psi-pi

Automatically exported from code.google.com/p/psi-pi
0 stars 0 forks source link

"root" / "actual" / "last" analysis #16

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We all agree, that AnalysisXML is for data exchange and results reporting.
To report evidence of the results we reference or give intermediate results
(i.e. spectra, if peptides are reported; or peptides, if proteins are
reported).

We discussed in Hinxton, that we may mark the "root" / "actual" / "last"
analysis, that means, the one which is NOT intermediate. We rejected such
an attribute, because an algorithm can reconstruct this information.

Meanwhile I think, that we need it (e.g. as an attribute or sub-element of
"AnalysisXML" or "analysisCollection"), because it may be complicated to
reconstruct it; AND: in case of having more than one "non-intermediate"
analyses (schema-valid, but in my opinion not intended), such a field
identifies the actual analysis reported by the XML.

Original issue reported on code.google.com by eisena...@googlemail.com on 30 Apr 2008 at 1:02

GoogleCodeExporter commented 9 years ago

Original comment by eisena...@googlemail.com on 2 May 2008 at 10:40

GoogleCodeExporter commented 9 years ago
slides explaining this:
http://code.google.com/p/psi-pi/source/browse/trunk/examples/schema_usecase_exam
ples/analysis_tree.ppt

Original comment by eisena...@googlemail.com on 29 May 2008 at 8:23

GoogleCodeExporter commented 9 years ago
Trying to summarize discussion on mailing list:

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)

Original comment by eisena...@googlemail.com on 29 May 2008 at 8:24

GoogleCodeExporter commented 9 years ago
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… ;-)

Original comment by eisena...@googlemail.com on 29 May 2008 at 8:24

GoogleCodeExporter commented 9 years ago
Agreement (TeleCon 5/29/2008): limit to 0 or 1 ProteinDetection elements under
AnalysisCollection

Original comment by eisena...@googlemail.com on 29 May 2008 at 4:05

GoogleCodeExporter commented 9 years ago

Original comment by eisena...@googlemail.com on 29 May 2008 at 4:06

GoogleCodeExporter commented 9 years ago
Schema forces the cardinality of ProteinDetection results to 1.

Original comment by eisena...@googlemail.com on 5 Jun 2008 at 2:18