Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type attribute

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

Except for the wormy cvParam format issue, I like:

<softwareList count="1">
  <software id="Xcalibur">
    <softwareParam cvLabel="MS" accession="MS:1000532" name="Xcalibur" version="2.0.5"/>
  </software>
</softwareList>
<dataProcessingList count="1">
  <dataProcessing id="Xcalibur Processing" softwareRef="Xcalibur">
    <processingMethod order="1">
	<cvParam cvLabel="MS" accession="MS:1000xxx" name="data acquisition" value=""/>
	<cvParam cvLabel="MS" accession="MS:1000033" name="deisotoping" value="false"/>
	<cvParam cvLabel="MS" accession="MS:1000034" name="charge deconvolution" value="false"/>
	<cvParam cvLabel="MS" accession="MS:1000035" name="peak picking" value="true"/>
    </processingMethod>
  </dataProcessing>
</dataProcessingList>

The softwareList seems to behave just like an index. I like it better 
than the mzXML equivlanet which seems to not allow for the fact that the 
same software can be used for multiple types of data processing. Even if 
it turns out that the mzML data processing list is backward compatible 
with the mzXML data processing list, it cannot be expected that any 
given mzML will be able to be converted to mzXML and back again without 
any loss of information. Only in certain limited uses would that be 
possible.

-Matt


Eric Deutsch wrote:
> Hi Darren, in order to close this thread, would you provide a compelling
> example of what you'd like to see?
>
> One thing we'd like to avoid is having "more than one way to do it". I'm
> slightly nervous that allowing this capability would allow one to
> annotate the function of some software in two different ways.  So now we
> have in our examples:
>
> <softwareList count="1">
>   <software id="Xcalibur">
>     <softwareParam cvLabel="MS" accession="MS:1000532" name="Xcalibur"
> version="2.0.5"/>
>   </software>
> </softwareList>
> <dataProcessingList count="1">
>   <dataProcessing id="Xcalibur Processing" softwareRef="Xcalibur">
>     <processingMethod order="1">
> 	<cvParam cvLabel="MS" accession="MS:1000033" name="deisotoping"
> value="false"/>
> 	<cvParam cvLabel="MS" accession="MS:1000034" name="charge
> deconvolution" value="false"/>
> 	<cvParam cvLabel="MS" accession="MS:1000035" name="peak picking"
> value="true"/>
>     </processingMethod>
>   </dataProcessing>
> </dataProcessingList>
>
> What would you like to see transformed from mzXML:
> <software type="acquisition"
>           name="Xcalibur"
>        version="1.3 alpha 8"/>
> ?
>
> Maybe:
>
> <softwareList count="1">
>   <software id="Xcalibur">
>     <softwareParam cvLabel="MS" accession="MS:1000532" name="Xcalibur"
> version="2.0.5"/>
>   </software>
> </softwareList>
> <dataProcessingList count="1">
>   <dataProcessing id="Xcalibur Processing" softwareRef="Xcalibur">
>     <processingMethod order="1">
> 	<cvParam cvLabel="MS" accession="MS:100xxxx" name="data
> acquisition" value="false"/>
>     </processingMethod>
>   </dataProcessing>
> </dataProcessingList>
>
>
> Thanks,
> Eric
>
>
>
>
>
>   
>> -----Original Message-----
>> From: psi...@li...
>>     
> [mailto:psidev-ms-dev-
>   
>> bo...@li...] On Behalf Of Darren Kessner
>> Sent: Tuesday, February 19, 2008 7:35 AM
>> To: Mass spectrometry standard development
>> Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
>>     
> attribute
>   
>> Actually, my comment about dataProcessing was limited to the uses of
>>     
> the
>   
>> software during processing.
>>
>> I think the addition of the cvParam for the general software type is
>> useful (and in fact I'm using it in the latest msdata code).  If
>>     
> nothing
>   
>> else, it provides for a much more straightfoward translation from
>> mzXML.  Without it, encoding the mzXML software type is much more
>> awkward.
>>
>>
>> Darren
>>
>>
>> On Tue, 19 Feb 2008 4:20 am, Lennart Martens wrote:
>>     
>>> Hi Eric, hi PSI MS Enthousiast,
>>>
>>>
>>>       
>>>>  I read that this discussion was deemed moot. Play-by-play below.
>>>>  Lennart, should we remove your new cvParam entry location to
>>>>         
> remove
>   
>>>>  temptation to use it, or leave it in?
>>>>         
>>> I'll schedule it for removal, and will do so in the version I'll try
>>>       
> to
>   
>>> build after the phone con tonight (or this morning :)).
>>>
>>>
>>> Cheers,
>>>
>>> lnnrt.
>>>
>>>
>>>       
> ------------------------------------------------------------------------
>   
>> -
>>     
>>> 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
>>>       
>> Darren
>>
>>
>>     
> ------------------------------------------------------------------------
> -
>   
>> 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
>>     
>
> -------------------------------------------------------------------------
> 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
>
>