Re: [Psidev-ms-dev] attributes vs cvParams

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

> -----Original Message-----
> From: psi...@li... [mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Joshua Tasman
> Sent: Wednesday, August 08, 2007 1:58 PM
> To: psi...@li...
> Subject: [Psidev-ms-dev] attributes vs cvParams
> 
> Hi all,
> 
> Actually, I agree that we'd be better served if more structure was
> applied at the xml schema level, but since design decisions have already
> been made and it seems we're past the point of changing them, I think we
> should stick to a consistent flavor.

I'm not terribly concerned about flavor of the XML I consume, but I don't
feel strongly one way or the other about most of the cvParam/schema issues.
I do feel strongly that parsers should not be required to look at the CV to
get basic meaning out of the file.


> I'd propose finding most instances in the schema where attributes and
> values are defined by the xml schema and replacing them with cvParams.
> If we're reliant on the OBO, let's completely get away from any parsing
> of human-readable elements.  In the OBO, we already have inconsistent
> capitalization for source file types: "mzData File" vs "wiff file".
> Let's simplify things and rely on the nice clean accession.
> 
>  From a look through the instance document, some examples:
> 
> I'd like to see soureFileType as a sub cvParam with a specific accession
> reference, vs attribute:
> <sourceFile id="1" sourceFileName="tiny1.RAW"
> sourceFileLocation="file://F:/data/Exp01" sourceFileType="Xcalibur RAW
> file">
I'm happy with:
<sourceFile id="1" sourceFileName="tiny1.RAW"
sourceFileLocation="file://F:/data/Exp01">
   <cvParam cvLabel="MS" accession="MS:xxxxxxx" name="Source file type"
value="Xcalibur RAW file" />
</sourceFile>

This must be accompanied by adding specific valid values to the ontology,
not just unique accession numbers.

I am not happy with:
<sourceFile id="1" sourceFileName="tiny1.RAW"
sourceFileLocation="file://F:/data/Exp01">
   <cvParam cvLabel="MS" accession="MS:xxxxxxx" name="Xcalibur RAW file"
value="" />
</sourceFile>

The idea of values being represented as unique accession numbers is against
common sense and possibly carcinogenic. ;)

> contactInfo could use value'd cvParams for name, institution, etc, or
> any other added features like email, phone, etc.
> 
> fileChecksum's type should be a cv accession, instead of:
> <fileChecksum type="Sha1">
What exactly are you suggesting here?
<fileChecksum
accession="MS:xx(sha1)xx">71be39fb2700ab2f3c8b2234b91274968b6899b1</fileChec
ksum>
Or
<fileChecksum>71be39fb2700ab2f3c8b2234b91274968b6899b1<cvParam cvLabel="MS"
accession="MS:xx(checksumType)xx" name="Checksum type" value="Sha1"
/></fileChecksum> <!-- ewwww -->
Or
<fileChecksum>71be39fb2700ab2f3c8b2234b91274968b6899b1<cvParam cvLabel="MS"
accession="MS:xx(sha1)xx" name="Sha1" value="" /></fileChecksum><!-- double
ewww! -->

I don't think any of these is better than leaving it as an attribute (and
possibly giving the checksum type attribute a schema type instead of putting
it in the ontology.  I don't think the cvParam paradigm works well on
elements which only have text nodes for children or which have no children
at all.

> In spectrum, spectrumType should be an cvParam, not attribute:
> <spectrum id="S19" scanNumber="19" spectrumType="MSn" msLevel="1">
I agree with this one.

> In binaryDataArray, attributes compressionType and dataType should be
> cvParams:
> <binaryDataArray dataType="64-bit float" compressionType="none"
> arrayLength="43" encodedLength="5000" dataProcessingRef="Xcalibur
> Processing">
I agree with this as well.

-Matt