psidev-ms-dev

[Psidev-ms-dev] mzXML software::type attribute

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

Please excuse me if this has been discussed before.  

 

In mzXML, the <software> element is encoded as follows:

    <software type="acquisition"

                   name="Xcalibur"

                   version="1.3 alpha 8"/>

 

In mzML, we have:

    <software id="Xcalibur">

        <softwareParam cvLabel="MS" accession="MS:1000532"
name="Xcalibur" version="2.0.5"/>

    </software>

 

Note that the name and version are encodable, but there is no convenient
place to save the "type" attribute, since the <software> element does
not have <cvParam> or <userParam> sub-elements.

 

Currently this causes a loss of this info when converting mzXML->mzML.  

 

If there is a good place to put this attribute, the conversion mzXML ->
mzML -> mzXML will be doable with no loss of information.  (I think this
is the last missing piece).  Or perhaps it's no great loss?  I don't
have a strong attachment to this attribute -- just thought it would be
nice to be able to get the same mzXML after converting to and from
mzML...

 

Thoughts?

 

 

Darren

 

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

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

[Lennart M. <len...@eb...>]

Hi Darren, hi PSI-MS enthousiasts,


I have included the ability to use cvParams in the 'software' element in 
a new schema iteration as per your suggestion.
Find it here:

http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd


I have also included an example instance document that is valid against 
this schema (do note that it currently uses a made-up CV term for the 
software type). Note that this example instance also has the binary 
array thingie at software level, and is essentially a hack of tiny1.
Find it here:

http://www.ebi.ac.uk/~lmartens/mzML/20080214_example_mzML0.99.9_SNAPSHOT.mzML

Sorry for the convoluted filenames, but it'll help keep things clear and 
separated, and somewhat archived.

One more note: if we get a consensus for this approach, we should 
probably extend the CV as well, so I'm already making a note about 
potentially including software types in a dedicated branch in the CV -- 
tentatively, of course.


Cheers,

lnnrt.

Kessner, Darren E. wrote:
> Hi all,
> 
>  
> 
> Please excuse me if this has been discussed before. 
> 
>  
> 
> In mzXML, the <software> element is encoded as follows:
> 
>     <software type="acquisition"
> 
>                    name="Xcalibur"
> 
>                    version="1.3 alpha 8"/>
> 
>  
> 
> In mzML, we have:
> 
>     <software id="Xcalibur">
> 
>         <softwareParam cvLabel="MS" accession="MS:1000532" 
> name="Xcalibur" version="2.0.5"/>
> 
>     </software>
> 
>  
> 
> Note that the name and version are encodable, but there is no convenient 
> place to save the "type" attribute, since the <software> element does 
> not have <cvParam> or <userParam> sub-elements.
> 
>  
> 
> Currently this causes a loss of this info when converting mzXML->mzML. 
> 
>  
> 
> If there is a good place to put this attribute, the conversion mzXML -> 
> mzML -> mzXML will be doable with no loss of information.  (I think this 
> is the last missing piece).  Or perhaps it's no great loss?  I don't 
> have a strong attachment to this attribute -- just thought it would be 
> nice to be able to get the same mzXML after converting to and from mzML...
> 
>  
> 
> Thoughts?
> 
>  
> 
>  
> 
> Darren
> 
>  
> 
>  
> 
>  
> 
> Darren Kessner
> 
> Scientific Programmer
> 
> Dar...@cs... <mailto:Dar...@cs...>
> 
> 310-423-9538
> 
>  
> 
> Spielberg Family Center for Applied Proteomics
> 
> Cedars-Sinai Medical Center
> 
> http://www.sfcap.cshs.org/
> 
>  
> 
>  
> 
> IMPORTANT WARNING: This message is intended for the use of the person or 
> entity to which it is addressed and may contain information that is 
> privileged and confidential, the disclosure of which is governed by
> applicable law. If the reader of this message is not the intended 
> recipient, or the employee or agent responsible for delivering it to the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this information is STRICTLY PROHIBITED.
> 
> If you have received this message in error, please notify us immediately
> by calling (310) 423-6428 and destroy the related message. Thank You for 
> your cooperation.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

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

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

I would have thought the ontology entry for XCalibur would have qualified it
as acquisition software (e.g. this should have been encoded into the CV
element and hence referencing the accession MS:1000532 would suffice to
identify it as acquisition software.)
-angel

On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens <len...@eb...>
wrote:

> Hi Darren, hi PSI-MS enthousiasts,
>
>
> I have included the ability to use cvParams in the 'software' element in
> a new schema iteration as per your suggestion.
> Find it here:
>
> http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>
> Kessner, Darren E. wrote:
> > Hi all,
> >
> >
> >
> > Please excuse me if this has been discussed before.
> >
> >
> >
> > In mzXML, the <software> element is encoded as follows:
> >
> >     <software type="acquisition"
> >
> >                    name="Xcalibur"
> >
> >                    version="1.3 alpha 8"/>
> >
> >
> >
> > In mzML, we have:
> >
> >     <software id="Xcalibur">
> >
> >         <softwareParam cvLabel="MS" accession="MS:1000532"
> > name="Xcalibur" version="2.0.5"/>
> >
> >     </software>
> >
> >
> >
> > Note that the name and version are encodable, but there is no convenient
> > place to save the "type" attribute, since the <software> element does
> > not have <cvParam> or <userParam> sub-elements.
> >
> >
>
>

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

[Lennart M. <len...@eb...>]

Hi Angel,


> I would have thought the ontology entry for XCalibur would have 
> qualified it as acquisition software (e.g. this should have been encoded 
> into the CV element and hence referencing the accession MS:1000532 would 
> suffice to identify it as acquisition software.)

Seems like a very reasonable suggestion to me. Currently not implemented 
in the CV, but I'll make another tentative note on CV development.

One thing that I just thought of: what if a piece of software can 
perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
-- doable in the CV through simple multi-parenting), but is used in only 
one capacity (say 'acquisition') while another piece of software is used 
for the other functionality (e.g., I used 'Mascot Distiller' for 
'peakpicking').

Do we want to keep track of such things, and is this possibly an 
argument against CV encoding here?


Cheers,

lnnrt.

> 
> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
> <len...@eb... <mailto:len...@eb...>> wrote:
> 
>     Hi Darren, hi PSI-MS enthousiasts,
> 
> 
>     I have included the ability to use cvParams in the 'software' element in
>     a new schema iteration as per your suggestion.
>     Find it here:
> 
>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
> 
>     Kessner, Darren E. wrote:
>      > Hi all,
>      >
>      >
>      >
>      > Please excuse me if this has been discussed before.
>      >
>      >
>      >
>      > In mzXML, the <software> element is encoded as follows:
>      >
>      >     <software type="acquisition"
>      >
>      >                    name="Xcalibur"
>      >
>      >                    version="1.3 alpha 8"/>
>      >
>      >
>      >
>      > In mzML, we have:
>      >
>      >     <software id="Xcalibur">
>      >
>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>      > name="Xcalibur" version="2.0.5"/>
>      >
>      >     </software>
>      >
>      >
>      >
>      > Note that the name and version are encodable, but there is no
>     convenient
>      > place to save the "type" attribute, since the <software> element does
>      > not have <cvParam> or <userParam> sub-elements.

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

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

On Thu, Feb 14, 2008 at 10:50 AM, Lennart Martens <len...@eb...>
wrote:

> Hi Angel,
>
>
> > I would have thought the ontology entry for XCalibur would have
> > qualified it as acquisition software (e.g. this should have been encoded
> > into the CV element and hence referencing the accession MS:1000532 would
> > suffice to identify it as acquisition software.)
>
> Seems like a very reasonable suggestion to me. Currently not implemented
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can
> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking'
> -- doable in the CV through simple multi-parenting), but is used in only
> one capacity (say 'acquisition') while another piece of software is used
> for the other functionality (e.g., I used 'Mascot Distiller' for
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an
> argument against CV encoding here?
>

meh... As long as it fulfills the role in the from where it is referenced, I
see no problem with software that has multiple functionality.

-angel

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

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

I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
or suite of applications, it's not a single program. It could be called 
once for instrument control (acquisition) and another time for peak 
picking & export to XML (currently only mzData). There may be other 
processing options in the future. It probably either needs more than one 
entry in the CV (one per application in the Xcalibur suite) or we need a 
separate group of CV terms to annotate software purpose. The former 
route would probably be more CV-friendly and intuitive. The latter route 
would require all the semantic logic about which software CV terms are 
able to be used for which purpose to be in the validator or in client 
software, a bad idea IMO.

-Matt


Lennart Martens wrote:
> Hi Angel,
>
>
>   
>> I would have thought the ontology entry for XCalibur would have 
>> qualified it as acquisition software (e.g. this should have been encoded 
>> into the CV element and hence referencing the accession MS:1000532 would 
>> suffice to identify it as acquisition software.)
>>     
>
> Seems like a very reasonable suggestion to me. Currently not implemented 
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can 
> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
> -- doable in the CV through simple multi-parenting), but is used in only 
> one capacity (say 'acquisition') while another piece of software is used 
> for the other functionality (e.g., I used 'Mascot Distiller' for 
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an 
> argument against CV encoding here?
>
>
> Cheers,
>
> lnnrt.
>
>   
>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>> <len...@eb... <mailto:len...@eb...>> wrote:
>>
>>     Hi Darren, hi PSI-MS enthousiasts,
>>
>>
>>     I have included the ability to use cvParams in the 'software' element in
>>     a new schema iteration as per your suggestion.
>>     Find it here:
>>
>>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>
>>     Kessner, Darren E. wrote:
>>      > Hi all,
>>      >
>>      >
>>      >
>>      > Please excuse me if this has been discussed before.
>>      >
>>      >
>>      >
>>      > In mzXML, the <software> element is encoded as follows:
>>      >
>>      >     <software type="acquisition"
>>      >
>>      >                    name="Xcalibur"
>>      >
>>      >                    version="1.3 alpha 8"/>
>>      >
>>      >
>>      >
>>      > In mzML, we have:
>>      >
>>      >     <software id="Xcalibur">
>>      >
>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>      > name="Xcalibur" version="2.0.5"/>
>>      >
>>      >     </software>
>>      >
>>      >
>>      >
>>      > Note that the name and version are encodable, but there is no
>>     convenient
>>      > place to save the "type" attribute, since the <software> element does
>>      > not have <cvParam> or <userParam> sub-elements.
>>     
>
>
> -------------------------------------------------------------------------
> 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
>
>   

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

[Kessner, D. E. <Dar...@cs...>]

Thanks for adding that, Lennart.  I like the idea of cvParams to
annotate what the software did to create the file.

One use case that we have is a conversion (say RAW -> mzML) by a single
program with various modules that may be turned on or off (centroiding,
peak picking, recalibration, precursor recalculation, etc.).  I think it
is very useful to record which of these modules was used during the
creation of the mzML file. 

Another thing from a maintainability perspective:  software will add
functionality as it grows, so I don't think it's a good idea to
pigeon-hole it via parenting in the CV.  It will be much more convenient
to add cvParam annotations for future versions of the software than to
request a CV change.  In fact, changing the CV parents may be valid for
a new version of a program, but then may be incorrect/misleading when an
old version is used.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, February 14, 2008 8:15 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute

I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
or suite of applications, it's not a single program. It could be called 
once for instrument control (acquisition) and another time for peak 
picking & export to XML (currently only mzData). There may be other 
processing options in the future. It probably either needs more than one

entry in the CV (one per application in the Xcalibur suite) or we need a

separate group of CV terms to annotate software purpose. The former 
route would probably be more CV-friendly and intuitive. The latter route

would require all the semantic logic about which software CV terms are 
able to be used for which purpose to be in the validator or in client 
software, a bad idea IMO.

-Matt


Lennart Martens wrote:
> Hi Angel,
>
>
>   
>> I would have thought the ontology entry for XCalibur would have 
>> qualified it as acquisition software (e.g. this should have been
encoded 
>> into the CV element and hence referencing the accession MS:1000532
would 
>> suffice to identify it as acquisition software.)
>>     
>
> Seems like a very reasonable suggestion to me. Currently not
implemented 
> in the CV, but I'll make another tentative note on CV development.
>
> One thing that I just thought of: what if a piece of software can 
> perform multiple functions (i.e.: 'acquisition' as well as
'peakpicking' 
> -- doable in the CV through simple multi-parenting), but is used in
only 
> one capacity (say 'acquisition') while another piece of software is
used 
> for the other functionality (e.g., I used 'Mascot Distiller' for 
> 'peakpicking').
>
> Do we want to keep track of such things, and is this possibly an 
> argument against CV encoding here?
>
>
> Cheers,
>
> lnnrt.
>
>   
>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>> <len...@eb... <mailto:len...@eb...>> wrote:
>>
>>     Hi Darren, hi PSI-MS enthousiasts,
>>
>>
>>     I have included the ability to use cvParams in the 'software'
element in
>>     a new schema iteration as per your suggestion.
>>     Find it here:
>>
>>
http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>
<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>
>>     Kessner, Darren E. wrote:
>>      > Hi all,
>>      >
>>      >
>>      >
>>      > Please excuse me if this has been discussed before.
>>      >
>>      >
>>      >
>>      > In mzXML, the <software> element is encoded as follows:
>>      >
>>      >     <software type="acquisition"
>>      >
>>      >                    name="Xcalibur"
>>      >
>>      >                    version="1.3 alpha 8"/>
>>      >
>>      >
>>      >
>>      > In mzML, we have:
>>      >
>>      >     <software id="Xcalibur">
>>      >
>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>      > name="Xcalibur" version="2.0.5"/>
>>      >
>>      >     </software>
>>      >
>>      >
>>      >
>>      > Note that the name and version are encodable, but there is no
>>     convenient
>>      > place to save the "type" attribute, since the <software>
element does
>>      > not have <cvParam> or <userParam> sub-elements.
>>     
>
>
>
------------------------------------------------------------------------
-
> 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
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

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

[Fredrik L. <Fre...@im...>]

Isn't the actual usage of the software described under dataProcessing? 
If the same software suite was used for two processing steps it can be 
defined using two separate dataProcessing elements. I think what Angel 
proposes should work out fine. Ok, there may be some ambiguities s for 
converting mzML to mzXML if a piece of software belongs to several 
software types categories, but apart from that I see no problem. Maybe a 
CV term for 'data acquisition' could be added as a MS:1000543 ( data 
processing action), though? Or doesn't data acquisition qualify as 
'processing'?

Fredrik

Matthew Chambers skrev:
> I share your concern Lennart. AFAIK, Xcalibur is the name of a library 
> or suite of applications, it's not a single program. It could be called 
> once for instrument control (acquisition) and another time for peak 
> picking & export to XML (currently only mzData). There may be other 
> processing options in the future. It probably either needs more than one 
> entry in the CV (one per application in the Xcalibur suite) or we need a 
> separate group of CV terms to annotate software purpose. The former 
> route would probably be more CV-friendly and intuitive. The latter route 
> would require all the semantic logic about which software CV terms are 
> able to be used for which purpose to be in the validator or in client 
> software, a bad idea IMO.
>
> -Matt
>
>
> Lennart Martens wrote:
>   
>> Hi Angel,
>>
>>
>>   
>>     
>>> I would have thought the ontology entry for XCalibur would have 
>>> qualified it as acquisition software (e.g. this should have been encoded 
>>> into the CV element and hence referencing the accession MS:1000532 would 
>>> suffice to identify it as acquisition software.)
>>>     
>>>       
>> Seems like a very reasonable suggestion to me. Currently not implemented 
>> in the CV, but I'll make another tentative note on CV development.
>>
>> One thing that I just thought of: what if a piece of software can 
>> perform multiple functions (i.e.: 'acquisition' as well as 'peakpicking' 
>> -- doable in the CV through simple multi-parenting), but is used in only 
>> one capacity (say 'acquisition') while another piece of software is used 
>> for the other functionality (e.g., I used 'Mascot Distiller' for 
>> 'peakpicking').
>>
>> Do we want to keep track of such things, and is this possibly an 
>> argument against CV encoding here?
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>>   
>>     
>>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>>> <len...@eb... <mailto:len...@eb...>> wrote:
>>>
>>>     Hi Darren, hi PSI-MS enthousiasts,
>>>
>>>
>>>     I have included the ability to use cvParams in the 'software' element in
>>>     a new schema iteration as per your suggestion.
>>>     Find it here:
>>>
>>>     http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>>     <http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>>
>>>     Kessner, Darren E. wrote:
>>>      > Hi all,
>>>      >
>>>      >
>>>      >
>>>      > Please excuse me if this has been discussed before.
>>>      >
>>>      >
>>>      >
>>>      > In mzXML, the <software> element is encoded as follows:
>>>      >
>>>      >     <software type="acquisition"
>>>      >
>>>      >                    name="Xcalibur"
>>>      >
>>>      >                    version="1.3 alpha 8"/>
>>>      >
>>>      >
>>>      >
>>>      > In mzML, we have:
>>>      >
>>>      >     <software id="Xcalibur">
>>>      >
>>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>>      > name="Xcalibur" version="2.0.5"/>
>>>      >
>>>      >     </software>
>>>      >
>>>      >
>>>      >
>>>      > Note that the name and version are encodable, but there is no
>>>     convenient
>>>      > place to save the "type" attribute, since the <software> element does
>>>      > not have <cvParam> or <userParam> sub-elements.
>>>     
>>>       
>> -------------------------------------------------------------------------
>> 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
>   

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

[Kessner, D. E. <Dar...@cs...>]

Thank you for pointing that out, Fredrik.  Please ignore my last post.

A couple of general CV terms for "type" should be fine.  Everything I
was talking about should go in <dataProcessing>.



Darren


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Fredrik Levander
Sent: Thursday, February 14, 2008 9:36 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute

Isn't the actual usage of the software described under dataProcessing? 
If the same software suite was used for two processing steps it can be 
defined using two separate dataProcessing elements. I think what Angel 
proposes should work out fine. Ok, there may be some ambiguities s for 
converting mzML to mzXML if a piece of software belongs to several 
software types categories, but apart from that I see no problem. Maybe a

CV term for 'data acquisition' could be added as a MS:1000543 ( data 
processing action), though? Or doesn't data acquisition qualify as 
'processing'?

Fredrik

Matthew Chambers skrev:
> I share your concern Lennart. AFAIK, Xcalibur is the name of a library

> or suite of applications, it's not a single program. It could be
called 
> once for instrument control (acquisition) and another time for peak 
> picking & export to XML (currently only mzData). There may be other 
> processing options in the future. It probably either needs more than
one 
> entry in the CV (one per application in the Xcalibur suite) or we need
a 
> separate group of CV terms to annotate software purpose. The former 
> route would probably be more CV-friendly and intuitive. The latter
route 
> would require all the semantic logic about which software CV terms are

> able to be used for which purpose to be in the validator or in client 
> software, a bad idea IMO.
>
> -Matt
>
>
> Lennart Martens wrote:
>   
>> Hi Angel,
>>
>>
>>   
>>     
>>> I would have thought the ontology entry for XCalibur would have 
>>> qualified it as acquisition software (e.g. this should have been
encoded 
>>> into the CV element and hence referencing the accession MS:1000532
would 
>>> suffice to identify it as acquisition software.)
>>>     
>>>       
>> Seems like a very reasonable suggestion to me. Currently not
implemented 
>> in the CV, but I'll make another tentative note on CV development.
>>
>> One thing that I just thought of: what if a piece of software can 
>> perform multiple functions (i.e.: 'acquisition' as well as
'peakpicking' 
>> -- doable in the CV through simple multi-parenting), but is used in
only 
>> one capacity (say 'acquisition') while another piece of software is
used 
>> for the other functionality (e.g., I used 'Mascot Distiller' for 
>> 'peakpicking').
>>
>> Do we want to keep track of such things, and is this possibly an 
>> argument against CV encoding here?
>>
>>
>> Cheers,
>>
>> lnnrt.
>>
>>   
>>     
>>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens 
>>> <len...@eb... <mailto:len...@eb...>>
wrote:
>>>
>>>     Hi Darren, hi PSI-MS enthousiasts,
>>>
>>>
>>>     I have included the ability to use cvParams in the 'software'
element in
>>>     a new schema iteration as per your suggestion.
>>>     Find it here:
>>>
>>>
http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
>>>
<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
>>>
>>>     Kessner, Darren E. wrote:
>>>      > Hi all,
>>>      >
>>>      >
>>>      >
>>>      > Please excuse me if this has been discussed before.
>>>      >
>>>      >
>>>      >
>>>      > In mzXML, the <software> element is encoded as follows:
>>>      >
>>>      >     <software type="acquisition"
>>>      >
>>>      >                    name="Xcalibur"
>>>      >
>>>      >                    version="1.3 alpha 8"/>
>>>      >
>>>      >
>>>      >
>>>      > In mzML, we have:
>>>      >
>>>      >     <software id="Xcalibur">
>>>      >
>>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
>>>      > name="Xcalibur" version="2.0.5"/>
>>>      >
>>>      >     </software>
>>>      >
>>>      >
>>>      >
>>>      > Note that the name and version are encodable, but there is no
>>>     convenient
>>>      > place to save the "type" attribute, since the <software>
element does
>>>      > not have <cvParam> or <userParam> sub-elements.
>>>     
>>>       
>>
------------------------------------------------------------------------
-
>> 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
>   

------------------------------------------------------------------------
-
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
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by
applicable law.  If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED.

If you have received this message in error, please notify us immediately
by calling (310) 423-6428 and destroy the related message.  Thank You for your cooperation.

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

[Eric D. <ede...@sy...>]

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?


Software type discussion:
- Darren points out that mzXML: <software type="acquisition" can no
longer be encoded
- Lennart adds an allowable cvParam within <software> which can specify
a software type
- Angel suggests the CV/ontology should be used to fix this with
somthing like "Xcalibur" is_a "acquisition software"
- Lennart points out that some software might have different functions
or be of different type in different contexts
- Lennart goes on to say that the CV term could have multiple parents
then
- Angel agrees that's fine
- Matt says that "Xcalibur" is a good example of a multi-function
software
- Matt suggests more than one CV entry for each applicaiton in the
Xcalibur suite
- Or, Matt suggests, have a separate set of entries for software type
and then complex validator logis (which he labels bad)
- Darren says that controlling function in the CV not a good idea. Likes
Lennart's cvParam mechanism
- Fredrik says that softwares are referenced by a dataProcessing and you
can decribe how the software was used there
- Darren concurs that Fredrik is right and this discussion is moot



> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Kessner, Darren E.
> Sent: Thursday, February 14, 2008 9:55 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
attribute
> 
> Thank you for pointing that out, Fredrik.  Please ignore my last post.
> 
> A couple of general CV terms for "type" should be fine.  Everything I
> was talking about should go in <dataProcessing>.
> 
> 
> 
> Darren
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of
> Fredrik Levander
> Sent: Thursday, February 14, 2008 9:36 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.9 SNAPSHOT software::type
> attribute
> 
> Isn't the actual usage of the software described under dataProcessing?
> If the same software suite was used for two processing steps it can be
> defined using two separate dataProcessing elements. I think what Angel
> proposes should work out fine. Ok, there may be some ambiguities s for
> converting mzML to mzXML if a piece of software belongs to several
> software types categories, but apart from that I see no problem. Maybe
a
> 
> CV term for 'data acquisition' could be added as a MS:1000543 ( data
> processing action), though? Or doesn't data acquisition qualify as
> 'processing'?
> 
> Fredrik
> 
> Matthew Chambers skrev:
> > I share your concern Lennart. AFAIK, Xcalibur is the name of a
library
> 
> > or suite of applications, it's not a single program. It could be
> called
> > once for instrument control (acquisition) and another time for peak
> > picking & export to XML (currently only mzData). There may be other
> > processing options in the future. It probably either needs more than
> one
> > entry in the CV (one per application in the Xcalibur suite) or we
need
> a
> > separate group of CV terms to annotate software purpose. The former
> > route would probably be more CV-friendly and intuitive. The latter
> route
> > would require all the semantic logic about which software CV terms
are
> 
> > able to be used for which purpose to be in the validator or in
client
> > software, a bad idea IMO.
> >
> > -Matt
> >
> >
> > Lennart Martens wrote:
> >
> >> Hi Angel,
> >>
> >>
> >>
> >>
> >>> I would have thought the ontology entry for XCalibur would have
> >>> qualified it as acquisition software (e.g. this should have been
> encoded
> >>> into the CV element and hence referencing the accession MS:1000532
> would
> >>> suffice to identify it as acquisition software.)
> >>>
> >>>
> >> Seems like a very reasonable suggestion to me. Currently not
> implemented
> >> in the CV, but I'll make another tentative note on CV development.
> >>
> >> One thing that I just thought of: what if a piece of software can
> >> perform multiple functions (i.e.: 'acquisition' as well as
> 'peakpicking'
> >> -- doable in the CV through simple multi-parenting), but is used in
> only
> >> one capacity (say 'acquisition') while another piece of software is
> used
> >> for the other functionality (e.g., I used 'Mascot Distiller' for
> >> 'peakpicking').
> >>
> >> Do we want to keep track of such things, and is this possibly an
> >> argument against CV encoding here?
> >>
> >>
> >> Cheers,
> >>
> >> lnnrt.
> >>
> >>
> >>
> >>> On Thu, Feb 14, 2008 at 6:21 AM, Lennart Martens
> >>> <len...@eb... <mailto:len...@eb...>>
> wrote:
> >>>
> >>>     Hi Darren, hi PSI-MS enthousiasts,
> >>>
> >>>
> >>>     I have included the ability to use cvParams in the 'software'
> element in
> >>>     a new schema iteration as per your suggestion.
> >>>     Find it here:
> >>>
> >>>
> http://www.ebi.ac.uk/~lmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd
> >>>
>
<http://www.ebi.ac.uk/%7Elmartens/mzML/20080214_mzML0.99.9_SNAPSHOT.xsd>
> >>>
> >>>     Kessner, Darren E. wrote:
> >>>      > Hi all,
> >>>      >
> >>>      >
> >>>      >
> >>>      > Please excuse me if this has been discussed before.
> >>>      >
> >>>      >
> >>>      >
> >>>      > In mzXML, the <software> element is encoded as follows:
> >>>      >
> >>>      >     <software type="acquisition"
> >>>      >
> >>>      >                    name="Xcalibur"
> >>>      >
> >>>      >                    version="1.3 alpha 8"/>
> >>>      >
> >>>      >
> >>>      >
> >>>      > In mzML, we have:
> >>>      >
> >>>      >     <software id="Xcalibur">
> >>>      >
> >>>      >         <softwareParam cvLabel="MS" accession="MS:1000532"
> >>>      > name="Xcalibur" version="2.0.5"/>
> >>>      >
> >>>      >     </software>
> >>>      >
> >>>      >
> >>>      >
> >>>      > Note that the name and version are encodable, but there is
no
> >>>     convenient
> >>>      > place to save the "type" attribute, since the <software>
> element does
> >>>      > not have <cvParam> or <userParam> sub-elements.
> >>>
> >>>
> >>
>
------------------------------------------------------------------------
> -
> >> 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
> >
> 
>
------------------------------------------------------------------------
> -
> 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
> IMPORTANT WARNING: This message is intended for the use of the person
or
> entity to which it is addressed and may contain information that is
> privileged and confidential, the disclosure of which is governed by
> applicable law.  If the reader of this message is not the intended
> recipient, or the employee or agent responsible for delivering it to
the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this information is STRICTLY PROHIBITED.
> 
> If you have received this message in error, please notify us
immediately
> by calling (310) 423-6428 and destroy the related message.  Thank You
for
> your cooperation.
> 
>
------------------------------------------------------------------------
-
> 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

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

[Lennart M. <len...@eb...>]

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.

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

[Darren K. <dke...@ya...>]

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

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

[Darren K. <dar...@cs...>]

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

Darren

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

[Eric D. <ede...@sy...>]

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

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

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

[Darren K. <dke...@ya...>]

Yes, Eric & Matt -- I agree that this is the right way to do it.

No change needed to spec.  Possible change to the CV, if we want CV 
terms to represent "general software category", with "data acquisition", 
"format conversion".  This might be useful to the human reader, probably 
less so for a parser...


Darren



Matthew Chambers wrote:
> 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
>>
>>   
>>     
>
> -------------------------------------------------------------------------
> 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
>