psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] Call for nominations for PSI-MS Chair

[Randy J. <rkj...@in...>]

Are there any other nominations - there is a PSI-SG conference call tomorrow
(11am EST/4pm GMT), please forward your nominations for discussion.
 
Thanks,
Randy

  _____  

From: Randy Julian [mailto:rj...@pu...] 
Sent: Friday, November 24, 2006 9:29 AM
To: 'psi...@li...'
Cc: 'ru...@sy...'; 'hh...@eb...'; 'chr...@eb...';
'no...@cs...'; 'k.s...@bi...'; 'or...@eb...';
'lu...@eb...'; 'pie...@is...';
'Sey...@ap...'; 'joh...@eb...';
'an...@ma...'; 'dc...@ma...'; 'Andy Jones'
Subject: Call for nominations for PSI-MS Chair


The PSI-MS Working Group is seeking nominations for the group co-chair
beginning in 2007.  The group is current co-chaired by Randy Julian and
Pierre-Alain Binz.  Starting in 2007 Randy will focus on the PSI Steering
Group and developing the standards document process.    The role of WG chair
is described in the PSI management documents:
 
http://psidev.sourceforge.net/docstore/download.php?id=58 (Overview)
 
http://psidev.sourceforge.net/docstore/download.php?id=56 (Management)
http://psidev.sourceforge.net/docstore/download.php?id=57 (Structure)
 
Anyone who is actively engaged in the PSI-MS working group who would like to
contribute their leadership to the MS initiative should contact a Steering
Group member.  Nominations will be accepted from the PSI-MS-WG and a final
selection will be made by the PSI-SG.
 
PSI-SG:
Ruedi Aebersold (ru...@sy...)
Henning Hermjakob (hh...@eb...)
Randy Julian (rj...@pu...)
Chris Taylor (chr...@eb...)
Norman Paton (no...@cs...)
Katherine Lilley (k.s...@bi...)
Sandra Orchard (or...@eb...)
Luisa Montecchi (lu...@eb...)
Pierre-Alain Binz (pie...@is...)
Sean Seymour (Sey...@ap...)
John Garavelli (joh...@eb...)
Angel Pizzaro (an...@ma...)
David Creasy (dc...@ma...)
Andy Jones (aj...@cs...)

[Psidev-ms-dev] Call for nominations for PSI-MS Chair

[Randy J. <rj...@pu...>]

The PSI-MS Working Group is seeking nominations for the group co-chair
beginning in 2007.  The group is current co-chaired by Randy Julian and
Pierre-Alain Binz.  Starting in 2007 Randy will focus on the PSI Steering
Group and developing the standards document process.    The role of WG chair
is described in the PSI management documents:
 
http://psidev.sourceforge.net/docstore/download.php?id=58 (Overview)
 
http://psidev.sourceforge.net/docstore/download.php?id=56 (Management)
http://psidev.sourceforge.net/docstore/download.php?id=57 (Structure)
 
Anyone who is actively engaged in the PSI-MS working group who would like to
contribute their leadership to the MS initiative should contact a Steering
Group member.  Nominations will be accepted from the PSI-MS-WG and a final
selection will be made by the PSI-SG.
 
PSI-SG:
Ruedi Aebersold (ru...@sy...)
Henning Hermjakob (hh...@eb...)
Randy Julian (rj...@pu...)
Chris Taylor (chr...@eb...)
Norman Paton (no...@cs...)
Katherine Lilley (k.s...@bi...)
Sandra Orchard (or...@eb...)
Luisa Montecchi (lu...@eb...)
Pierre-Alain Binz (pie...@is...)
Sean Seymour (Sey...@ap...)
John Garavelli (joh...@eb...)
Angel Pizzaro (an...@ma...)
David Creasy (dc...@ma...)
Andy Jones (aj...@cs...)

[Psidev-ms-dev] draft schema and sample instance for merged MS interchange format

[Kent L. <knl...@in...>]

On November 13th and 14th, a working meeting was held at the ISB in Seattle
to further the end of year goal of releasing (more accurately getting
formally into the review phase) an MS interchange format that represents the
unification of mzData and mzXML.  The meeting was a useful and productive
one, and thanks go out to those that contributed.  This new format is not
only a merger, but encompasses significant improvements beyond the two
existing formats.  Links to draft schemas and a sample instance can be found
at the bottom of this e-mail.  They are undocumented at the time of this
writing, but this will change in the near term.  In parallel with the XML
format, a new version of the MS controlled vocabulary is being finalized for
concurrent availability.  The new XML format makes heavy use of controlled
vocabulary to annotate its more flexible structure.

 

More detail is forthcoming, but this early peak into the merged format
should be a useful artifact to those interested in the upcoming standard.

 

Regards,

 

Kent Laursen

 

 

The schema download link

http://psidev.sourceforge.net/docstore/download.php?id=119

 

The index schema download link

http://psidev.sourceforge.net/docstore/download.php?
<http://psidev.sourceforge.net/docstore/download.php?&id=120> &id=120

 

The sample instance document link

http://psidev.sourceforge.net/docstore/download.php?
<http://psidev.sourceforge.net/docstore/download.php?&id=121> &id=121

 

 

[Psidev-ms-dev] bruker data format to mzXML

[Rodrigo A. <r....@er...>]

Dear colleagues,

I want to convert FTMS bruker data format into mzXML data but i was not 
able to do it with compassXport. Does anyone know other softwares or 
maybe can help me with this. Thank you.

Best regards,

Rodrigo Alves

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Pierre-Alain B. <pie...@is...>]

Thanks Randy for these precisions.
This tells me that we really need a god sample of use cases. Eric has a 
number of high-level descriptions that we have prepared during one of 
the sessions in Washington (this was done by Jim, Sean, Ronan, myself 
and a couple of others I am sorry to have not in mind right now).
For each of them, It would be nice to think at generating 1) a more 
formal list of these usecases in the documentation of the standard and 
2) a number of typical instanciations.
Maybe in Seattle these usecases can be listed again and "checked" if 
considered or not during these 2 days.

Pierre-Alain


Randy Julian wrote:

>Hi everyone,
>
>Short version:
>
>This is confusing and we need to deal with it directly in the CV.  Below is
>a long discussion - the short version is that 1000038/1000039 are meant to
>be relative acquisition times which in chromatography system would be
>'retention time' but this is not true for non-chromatography systems, so we
>need to clean up the nomenclature.
>
>Long version:
>
>There are two terms in the CV which are meant to represent relative
>acquitisiton time from the start of overall acquisition process.  The data
>type is expected to be a floating point number - not a date/time stamp.
>
>As such, it is ideally suited (and intentionally designed) to hold a
>retention time.  However, since 'retention time' is not globally applicable
>to all separation methods, and since not all flow-based methods or
>sequential acquisition methods involve separation at all (flow-injection,
>etc.), then calling this term 'retention time' was overly specific.
>
>For MALDI system where multiple spectra would be collected from a single
>spot, the idea of recoring the time from the first spectrum acquired for a
>spot seemed to match this defintion of acquisition time, and since mzData
>1.05 files cannot handle multiple samples, then each spot on the plate would
>get it's own mzData file whose admin description could include creation
>dates and times.
>
>As for the precise meaning of a relative acquisition time (in minutes or
>seconds), we are somewhat at the mercy of the base acquisition system.
>
>There are two time-frames which need be considered: analyzer time, and
>flow-system time.
>
>A typical analyzer takes some finite time to perform a single acquisition.
>Most systems combine multiple low-level acquisitions into a single reported
>acquisition (like most ion traps and TOF systems).  Some systems record the
>time representing the start of an atomic operation which results in the
>production of a single reported spectrum.  Other systems record the
>concluding time of the spectrum.
>
>It is not usually critical to determine if the time indicated is at the
>start of the spectrum scan, or the end, since it is a very short time in
>almost all systems and is consistently done within individual analyzers.
>
>For most systems used in protoemics, there flow-system time is a completely
>different thing.  In data-dependent acquisitions, there can be large
>variations is the cycle-time of the instrument, so there will usually not be
>a 'sampling frequency' in the usual sense - although you can configure
>experiments so have s fixed sampling frequency.
>
>This means that the acquisition time marks the time from the start of the
>acquisition at which the particular spectrum is recorded.  If several
>spectra are combined then you are working in flow-system time, and there are
>several ways to describe what has been done.
>
>The very best way to handle this is to use the
>'acqSpecification/acquisition' elements to record exactly which acquisitions
>are combined - including their acquisition times.
>
>As for the acquitision time of the combined spectrum, it is then possible to
>indicate either the start of the sequence, or, if you are processing
>chromatographic peaks, you can record a peak parameter like the apex time,
>or the centroid of the peak (which is what most chromatographers think of as
>'retention time').
>
>This suggests that we should have new CV terms to allow the specification of
>'retention time' from the chromatographic point of view, and perhaps clean
>up the nomenclature to specify that 1000038/1000039 are relative acquisition
>times.  We should also consider adding a true datetime stamp CV term which
>could be used to store a timestamp for the sample - especially if we move to
>allowing multiple samples in a single file (proposed for dataXML).
>
>Suggestions about additions/changes to the CV?
>
>Randy
>
>-----Original Message-----
>From: psi...@li...
>[mailto:psi...@li...] On Behalf Of David
>Creasy
>Sent: Thursday, November 09, 2006 11:23 AM
>To: len...@eb...
>Cc: psi...@li...
>Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology
>
>Hi Lennart,
>The intention was certainly that these are for the retention time, but I 
>can't see any documentation that confirms this.  Certainly Mascot 
>Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter, 
>Bioworks and the Insilicos viewer all assume that this is the case.
>
>Best regards,
>David
>
>
>
>Lennart Martens wrote:
>  
>
>>Hi Kent,
>>
>>
>>Thanks for pointing that out, but I had seen these myself and assumed 
>>that they were used to document the actual acquisition time during which 
>>the final spectrum was acquired (the final spectrum represented in the 
>>mzData binary arrays is thus a summation over all the individual 
>>detector recordings during that time slot).
>>
>>As such, I would expect this value to be either constant (I guess most 
>>mass specs do not allow dynamic setting of this value, but I could be 
>>wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in 
>>the seconds field, say, would therefore probably lead to confusion?
>>
>>
>>Cheers,
>>
>>lnnrt.
>>
>>Kent Laursen wrote:
>>    
>>
>>>Hi Lennart,
>>>
>>>There is not currently a term labeled retention time in the MS CV.  The
>>>current terms for the purpose are:
>>>
>>>[Term]
>>>id: PSI:1000038
>>>name: Time In Minutes
>>>def: "Acquisition time in minutes." [PSI:GPS]
>>>is_a: PSI:1000460 ! Unit
>>>relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>>
>>>[Term]
>>>id: PSI:1000039
>>>name: Time In Seconds
>>>def: "Acquisition time in seconds." [PSI:GPS]
>>>is_a: PSI:1000460 ! Unit
>>>relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>>
>>>Regards,
>>>
>>>Kent
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: psi...@li... [mailto:psidev-ms-dev-
>>>>bo...@li...] On Behalf Of Lennart Martens
>>>>Sent: Thursday, November 09, 2006 9:27 AM
>>>>To: psi...@li...
>>>>Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>I am processing some mzXML files into mzData for insertion into the
>>>>PRIDE database, and I can't seem to find an ontology term for 'retention
>>>>time' in the PSI-MS ontology.
>>>>
>>>>If there is one, and I just can't find it for some silly reason, please
>>>>let me know.
>>>>
>>>>If there isn't any, could this be added? It seems like a sensible thing
>>>>as it is a common enough piece of data.
>>>>
>>>>
>>>>Thanks in advance,
>>>>
>>>>
>>>>lnnrt.
>>>>
>>>>
>>>>        
>>>>
>-------------------------------------------------------------------------
>  
>
>>>>Using Tomcat but need to do more? Need to support web services,
>>>>        
>>>>
>security?
>  
>
>>>>Get stuff done quickly with pre-integrated technology to make your job
>>>>easier
>>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache
>>>>        
>>>>
>Geronimo
>  
>
>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>>_______________________________________________
>>>>Psidev-ms-dev mailing list
>>>>Psi...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>>        
>>>>
>
>  
>

-- 
--
 Dr. Pierre-Alain Binz
 Swiss Institute of Bioinformatics
 Proteome Informatics Group
 1, Rue Michel Servet
 CH-1211 Geneve 4
 Switzerland
 - - - - - - - - - - - - - - - - -
 Tel: +41-22-379 50 50
 Fax: +41-22-379 58 58
 Pie...@is...
 http://www.expasy.org/people/Pierre-Alain.Binz.html

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Randy J. <rkj...@in...>]

Hi Susan,

This direct infusion experiment is exactly why the 'acquisition time'
parameter in not called 'retention time'.

The individual acquisition time would start at 0 and depending on the
acquisition rate of your instrument (~ms to ~sec), the relative acquisition
time is recorded (probably as 'time in minutes') for the duration of the
infusion.

Thanks for your note - it helps to see the various ways instrumental methods
are set up.

Randy

-----Original Message-----
From: Susan M. Kennedy [mailto:Sus...@Da...] 
Sent: Saturday, November 11, 2006 10:37 PM
To: rkj...@in...
Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

Hi All
I'm not exactly sure how this fits into this discussion, but I think it is
pertinent.  We use infusion with gas phase fractionation which does not take
place in a chromatographic time frame.  Specifically we infuse a sample for
a
specific period of time (i.e. 8min) during which time the Mass Spec is
program
to only consider a specific set of ions(i.e. mz 350-450) for MSMS for a set
amount of time (ie1minMZ 450-550) and so forth up to 8min.  This is our
protocol
for routine protein ID of gel slices.

Feel free to email me if you need anymore detail

Thanks,
Susan

Susan M Kennedy
Asst. Manager for Protein Services
MB & Proteomic Core Facility

sm...@da...
http://www.dartmouth.edu/~mbcf/


--- You wrote:
Hi everyone,

Short version:

This is confusing and we need to deal with it directly in the CV.  Below is
a long discussion - the short version is that 1000038/1000039 are meant to
be relative acquisition times which in chromatography system would be
'retention time' but this is not true for non-chromatography systems, so we
need to clean up the nomenclature.

Long version:

There are two terms in the CV which are meant to represent relative
acquitisiton time from the start of overall acquisition process.  The data
type is expected to be a floating point number - not a date/time stamp.

As such, it is ideally suited (and intentionally designed) to hold a
retention time.  However, since 'retention time' is not globally applicable
to all separation methods, and since not all flow-based methods or
sequential acquisition methods involve separation at all (flow-injection,
etc.), then calling this term 'retention time' was overly specific.

For MALDI system where multiple spectra would be collected from a single
spot, the idea of recoring the time from the first spectrum acquired for a
spot seemed to match this defintion of acquisition time, and since mzData
1.05 files cannot handle multiple samples, then each spot on the plate would
get it's own mzData file whose admin description could include creation
dates and times.

As for the precise meaning of a relative acquisition time (in minutes or
seconds), we are somewhat at the mercy of the base acquisition system.

There are two time-frames which need be considered: analyzer time, and
flow-system time.

A typical analyzer takes some finite time to perform a single acquisition.
Most systems combine multiple low-level acquisitions into a single reported
acquisition (like most ion traps and TOF systems).  Some systems record the
time representing the start of an atomic operation which results in the
production of a single reported spectrum.  Other systems record the
concluding time of the spectrum.

It is not usually critical to determine if the time indicated is at the
start of the spectrum scan, or the end, since it is a very short time in
almost all systems and is consistently done within individual analyzers.

For most systems used in protoemics, there flow-system time is a completely
different thing.  In data-dependent acquisitions, there can be large
variations is the cycle-time of the instrument, so there will usually not be
a 'sampling frequency' in the usual sense - although you can configure
experiments so have s fixed sampling frequency.

This means that the acquisition time marks the time from the start of the
acquisition at which the particular spectrum is recorded.  If several
spectra are combined then you are working in flow-system time, and there are
several ways to describe what has been done.

The very best way to handle this is to use the
'acqSpecification/acquisition' elements to record exactly which acquisitions
are combined - including their acquisition times.

As for the acquitision time of the combined spectrum, it is then possible to
indicate either the start of the sequence, or, if you are processing
chromatographic peaks, you can record a peak parameter like the apex time,
or the centroid of the peak (which is what most chromatographers think of as
'retention time').

This suggests that we should have new CV terms to allow the specification of
'retention time' from the chromatographic point of view, and perhaps clean
up the nomenclature to specify that 1000038/1000039 are relative acquisition
times.  We should also consider adding a true datetime stamp CV term which
could be used to store a timestamp for the sample - especially if we move to
allowing multiple samples in a single file (proposed for dataXML).

Suggestions about additions/changes to the CV?

Randy
--- end of quote ---

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Randy J. <rkj...@in...>]

Hi everyone,

Short version:

This is confusing and we need to deal with it directly in the CV.  Below is
a long discussion - the short version is that 1000038/1000039 are meant to
be relative acquisition times which in chromatography system would be
'retention time' but this is not true for non-chromatography systems, so we
need to clean up the nomenclature.

Long version:

There are two terms in the CV which are meant to represent relative
acquitisiton time from the start of overall acquisition process.  The data
type is expected to be a floating point number - not a date/time stamp.

As such, it is ideally suited (and intentionally designed) to hold a
retention time.  However, since 'retention time' is not globally applicable
to all separation methods, and since not all flow-based methods or
sequential acquisition methods involve separation at all (flow-injection,
etc.), then calling this term 'retention time' was overly specific.

For MALDI system where multiple spectra would be collected from a single
spot, the idea of recoring the time from the first spectrum acquired for a
spot seemed to match this defintion of acquisition time, and since mzData
1.05 files cannot handle multiple samples, then each spot on the plate would
get it's own mzData file whose admin description could include creation
dates and times.

As for the precise meaning of a relative acquisition time (in minutes or
seconds), we are somewhat at the mercy of the base acquisition system.

There are two time-frames which need be considered: analyzer time, and
flow-system time.

A typical analyzer takes some finite time to perform a single acquisition.
Most systems combine multiple low-level acquisitions into a single reported
acquisition (like most ion traps and TOF systems).  Some systems record the
time representing the start of an atomic operation which results in the
production of a single reported spectrum.  Other systems record the
concluding time of the spectrum.

It is not usually critical to determine if the time indicated is at the
start of the spectrum scan, or the end, since it is a very short time in
almost all systems and is consistently done within individual analyzers.

For most systems used in protoemics, there flow-system time is a completely
different thing.  In data-dependent acquisitions, there can be large
variations is the cycle-time of the instrument, so there will usually not be
a 'sampling frequency' in the usual sense - although you can configure
experiments so have s fixed sampling frequency.

This means that the acquisition time marks the time from the start of the
acquisition at which the particular spectrum is recorded.  If several
spectra are combined then you are working in flow-system time, and there are
several ways to describe what has been done.

The very best way to handle this is to use the
'acqSpecification/acquisition' elements to record exactly which acquisitions
are combined - including their acquisition times.

As for the acquitision time of the combined spectrum, it is then possible to
indicate either the start of the sequence, or, if you are processing
chromatographic peaks, you can record a peak parameter like the apex time,
or the centroid of the peak (which is what most chromatographers think of as
'retention time').

This suggests that we should have new CV terms to allow the specification of
'retention time' from the chromatographic point of view, and perhaps clean
up the nomenclature to specify that 1000038/1000039 are relative acquisition
times.  We should also consider adding a true datetime stamp CV term which
could be used to store a timestamp for the sample - especially if we move to
allowing multiple samples in a single file (proposed for dataXML).

Suggestions about additions/changes to the CV?

Randy

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of David
Creasy
Sent: Thursday, November 09, 2006 11:23 AM
To: len...@eb...
Cc: psi...@li...
Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

Hi Lennart,
The intention was certainly that these are for the retention time, but I 
can't see any documentation that confirms this.  Certainly Mascot 
Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter, 
Bioworks and the Insilicos viewer all assume that this is the case.

Best regards,
David



Lennart Martens wrote:
> Hi Kent,
> 
> 
> Thanks for pointing that out, but I had seen these myself and assumed 
> that they were used to document the actual acquisition time during which 
> the final spectrum was acquired (the final spectrum represented in the 
> mzData binary arrays is thus a summation over all the individual 
> detector recordings during that time slot).
> 
> As such, I would expect this value to be either constant (I guess most 
> mass specs do not allow dynamic setting of this value, but I could be 
> wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in 
> the seconds field, say, would therefore probably lead to confusion?
> 
> 
> Cheers,
> 
> lnnrt.
> 
> Kent Laursen wrote:
>> Hi Lennart,
>>
>> There is not currently a term labeled retention time in the MS CV.  The
>> current terms for the purpose are:
>>
>> [Term]
>> id: PSI:1000038
>> name: Time In Minutes
>> def: "Acquisition time in minutes." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> [Term]
>> id: PSI:1000039
>> name: Time In Seconds
>> def: "Acquisition time in seconds." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> Regards,
>>
>> Kent
>>
>>> -----Original Message-----
>>> From: psi...@li... [mailto:psidev-ms-dev-
>>> bo...@li...] On Behalf Of Lennart Martens
>>> Sent: Thursday, November 09, 2006 9:27 AM
>>> To: psi...@li...
>>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>>
>>> Hi,
>>>
>>>
>>>
>>> I am processing some mzXML files into mzData for insertion into the
>>> PRIDE database, and I can't seem to find an ontology term for 'retention
>>> time' in the PSI-MS ontology.
>>>
>>> If there is one, and I just can't find it for some silly reason, please
>>> let me know.
>>>
>>> If there isn't any, could this be added? It seems like a sensible thing
>>> as it is a common enough piece of data.
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> lnnrt.
>>>
>>>
-------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services,
security?
>>> Get stuff done quickly with pre-integrated technology to make your job
>>> easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

*** please note change of address ***

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Kent L. <knl...@in...>]

Sir,

I thank you for your quasi-intentional review of the MS-CV, and agree with
your points:

-Don't redefine a term that can be re-used from a shared CV
-Avoid obfuscating a terms meaning through inappropriate contextualization

As you know, part of this is just the inevitable and necessary cleanup that
occurs as the different standards working groups interoperate with greater
earnest.

Please keep the observations and corrections coming; more perspectives lead
to better factoring of domain concepts in the various CV's and ontologies.

As a side note, we are hoping/expecting that MS CV will be registered and
posted on the OBO site prior to next weeks meeting.

Regards,

Kent


> -----Original Message-----
> From: psi...@li... [mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of frank gibson
> Sent: Friday, November 10, 2006 4:42 AM
> To: David Creasy; len...@eb...
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology
> 
> Hi
> 
> 
> I don't mean to review the MS-CV but......
> Just as a side issue to this thread you should be looking to use the
> PATO units ontology now instead of creating your own.
> http://obo.cvs.sourceforge.net/obo/obo/ontology/phenotype/
> Any missing term or request should be sent to
> obo...@li....
> 
> As a result, the defintion of "Time in minutes" (The term itself should
> probably just be "minutes") should be something like the "measure of
> time represented in minutes", not Acquisition time. Please ensure you
> remove context of use from the semantic meaning of the term.
> 
> Cheers
> Frank
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of David
> Creasy
> Sent: Thursday, November 09, 2006 4:23 PM
> To: len...@eb...
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology
> 
> Hi Lennart,
> The intention was certainly that these are for the retention time, but I
> can't see any documentation that confirms this.  Certainly Mascot
> Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter,
> Bioworks and the Insilicos viewer all assume that this is the case.
> 
> Best regards,
> David
> 
> 
> 
> Lennart Martens wrote:
> > Hi Kent,
> >
> >
> > Thanks for pointing that out, but I had seen these myself and assumed
> > that they were used to document the actual acquisition time during
> > which the final spectrum was acquired (the final spectrum represented
> > in the mzData binary arrays is thus a summation over all the
> > individual detector recordings during that time slot).
> >
> > As such, I would expect this value to be either constant (I guess most
> 
> > mass specs do not allow dynamic setting of this value, but I could be
> > wrong) and certainly small (say from 0.5 to 8 seconds). Having '900'
> > in the seconds field, say, would therefore probably lead to confusion?
> >
> >
> > Cheers,
> >
> > lnnrt.
> >
> > Kent Laursen wrote:
> >> Hi Lennart,
> >>
> >> There is not currently a term labeled retention time in the MS CV.
> >> The current terms for the purpose are:
> >>
> >> [Term]
> >> id: PSI:1000038
> >> name: Time In Minutes
> >> def: "Acquisition time in minutes." [PSI:GPS]
> >> is_a: PSI:1000460 ! Unit
> >> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> >>
> >> [Term]
> >> id: PSI:1000039
> >> name: Time In Seconds
> >> def: "Acquisition time in seconds." [PSI:GPS]
> >> is_a: PSI:1000460 ! Unit
> >> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> >>
> >> Regards,
> >>
> >> Kent
> >>
> >>> -----Original Message-----
> >>> From: psi...@li...
> >>> [mailto:psidev-ms-dev- bo...@li...] On Behalf Of
> >>> Lennart Martens
> >>> Sent: Thursday, November 09, 2006 9:27 AM
> >>> To: psi...@li...
> >>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
> >>>
> >>> Hi,
> >>>
> >>>
> >>>
> >>> I am processing some mzXML files into mzData for insertion into the
> >>> PRIDE database, and I can't seem to find an ontology term for
> >>> 'retention time' in the PSI-MS ontology.
> >>>
> >>> If there is one, and I just can't find it for some silly reason,
> >>> please let me know.
> >>>
> >>> If there isn't any, could this be added? It seems like a sensible
> >>> thing as it is a common enough piece of data.
> >>>
> >>>
> >>> Thanks in advance,
> >>>
> >>>
> >>> lnnrt.
> >>>
> >>> --------------------------------------------------------------------
> >>> ----- Using Tomcat but need to do more? Need to support web
> >>> services, security?
> >>> Get stuff done quickly with pre-integrated technology to make your
> >>> job easier Download IBM WebSphere Application Server v.1.0.1 based
> >>> on Apache Geronimo
> >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=12
> >>> 1642 _______________________________________________
> >>> Psidev-ms-dev mailing list
> >>> Psi...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >
> 
> --
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
> 
> dc...@ma...
> http://www.matrixscience.com
> 
> *** please note change of address ***
> 
> ------------------------------------------------------------------------
> -
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[frank g. <Fra...@ne...>]

Hi


I don't mean to review the MS-CV but......
Just as a side issue to this thread you should be looking to use the
PATO units ontology now instead of creating your own.
http://obo.cvs.sourceforge.net/obo/obo/ontology/phenotype/
Any missing term or request should be sent to
obo...@li....

As a result, the defintion of "Time in minutes" (The term itself should
probably just be "minutes") should be something like the "measure of
time represented in minutes", not Acquisition time. Please ensure you
remove context of use from the semantic meaning of the term.

Cheers
Frank =20

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of David
Creasy
Sent: Thursday, November 09, 2006 4:23 PM
To: len...@eb...
Cc: psi...@li...
Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

Hi Lennart,
The intention was certainly that these are for the retention time, but I
can't see any documentation that confirms this.  Certainly Mascot
Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter,
Bioworks and the Insilicos viewer all assume that this is the case.

Best regards,
David



Lennart Martens wrote:
> Hi Kent,
>=20
>=20
> Thanks for pointing that out, but I had seen these myself and assumed=20
> that they were used to document the actual acquisition time during=20
> which the final spectrum was acquired (the final spectrum represented=20
> in the mzData binary arrays is thus a summation over all the=20
> individual detector recordings during that time slot).
>=20
> As such, I would expect this value to be either constant (I guess most

> mass specs do not allow dynamic setting of this value, but I could be
> wrong) and certainly small (say from 0.5 to 8 seconds). Having '900'=20
> in the seconds field, say, would therefore probably lead to confusion?
>=20
>=20
> Cheers,
>=20
> lnnrt.
>=20
> Kent Laursen wrote:
>> Hi Lennart,
>>
>> There is not currently a term labeled retention time in the MS CV. =20
>> The current terms for the purpose are:
>>
>> [Term]
>> id: PSI:1000038
>> name: Time In Minutes
>> def: "Acquisition time in minutes." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> [Term]
>> id: PSI:1000039
>> name: Time In Seconds
>> def: "Acquisition time in seconds." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> Regards,
>>
>> Kent
>>
>>> -----Original Message-----
>>> From: psi...@li...=20
>>> [mailto:psidev-ms-dev- bo...@li...] On Behalf Of=20
>>> Lennart Martens
>>> Sent: Thursday, November 09, 2006 9:27 AM
>>> To: psi...@li...
>>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>>
>>> Hi,
>>>
>>>
>>>
>>> I am processing some mzXML files into mzData for insertion into the=20
>>> PRIDE database, and I can't seem to find an ontology term for=20
>>> 'retention time' in the PSI-MS ontology.
>>>
>>> If there is one, and I just can't find it for some silly reason,=20
>>> please let me know.
>>>
>>> If there isn't any, could this be added? It seems like a sensible=20
>>> thing as it is a common enough piece of data.
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> lnnrt.
>>>
>>> --------------------------------------------------------------------
>>> ----- Using Tomcat but need to do more? Need to support web=20
>>> services, security?
>>> Get stuff done quickly with pre-integrated technology to make your=20
>>> job easier Download IBM WebSphere Application Server v.1.0.1 based=20
>>> on Apache Geronimo
>>> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
12
>>> 1642 _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>=20

--
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

*** please note change of address ***

------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[David C. <dc...@ma...>]

Hi Lennart,
The intention was certainly that these are for the retention time, but I 
can't see any documentation that confirms this.  Certainly Mascot 
Distiller, Mascot, Bruker CompassXport, the Sciex wiff converter, 
Bioworks and the Insilicos viewer all assume that this is the case.

Best regards,
David



Lennart Martens wrote:
> Hi Kent,
> 
> 
> Thanks for pointing that out, but I had seen these myself and assumed 
> that they were used to document the actual acquisition time during which 
> the final spectrum was acquired (the final spectrum represented in the 
> mzData binary arrays is thus a summation over all the individual 
> detector recordings during that time slot).
> 
> As such, I would expect this value to be either constant (I guess most 
> mass specs do not allow dynamic setting of this value, but I could be 
> wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in 
> the seconds field, say, would therefore probably lead to confusion?
> 
> 
> Cheers,
> 
> lnnrt.
> 
> Kent Laursen wrote:
>> Hi Lennart,
>>
>> There is not currently a term labeled retention time in the MS CV.  The
>> current terms for the purpose are:
>>
>> [Term]
>> id: PSI:1000038
>> name: Time In Minutes
>> def: "Acquisition time in minutes." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> [Term]
>> id: PSI:1000039
>> name: Time In Seconds
>> def: "Acquisition time in seconds." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> Regards,
>>
>> Kent
>>
>>> -----Original Message-----
>>> From: psi...@li... [mailto:psidev-ms-dev-
>>> bo...@li...] On Behalf Of Lennart Martens
>>> Sent: Thursday, November 09, 2006 9:27 AM
>>> To: psi...@li...
>>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>>
>>> Hi,
>>>
>>>
>>>
>>> I am processing some mzXML files into mzData for insertion into the
>>> PRIDE database, and I can't seem to find an ontology term for 'retention
>>> time' in the PSI-MS ontology.
>>>
>>> If there is one, and I just can't find it for some silly reason, please
>>> let me know.
>>>
>>> If there isn't any, could this be added? It seems like a sensible thing
>>> as it is a common enough piece of data.
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> lnnrt.
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job
>>> easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

dc...@ma...
http://www.matrixscience.com

*** please note change of address ***

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Kent L. <knl...@in...>]

Hi Lennart,

Retention time is a chromatography term.  If you are referring to the time
between mass spectrum acquisitions, this can be computed by subtracting
consecutive absolute acquisition times.  However, these time intervals are
not necessarily identical/constant, so it is more precise to do the math on
acquisition times.

As far as I know, there is not a term for what you are describing.  Since it
would be useful to add this term to MS CV (time in between mass spec scans,
so to speak) you can email this request to Trish.  Perhaps something like
duty cycle would fit nicely with instrument description.

FYI, the upcoming merger will address separation as pragmatically necessary.

Regards,

Kent

> -----Original Message-----
> From: Lennart Martens [mailto:len...@eb...]
> Sent: Thursday, November 09, 2006 10:37 AM
> To: Kent Laursen; psi...@li...
> Subject: Re: [Psidev-ms-dev] Retention time in PSI-MS ontology
> 
> Hi Kent,
> 
> 
> Thanks for pointing that out, but I had seen these myself and assumed
> that they were used to document the actual acquisition time during which
> the final spectrum was acquired (the final spectrum represented in the
> mzData binary arrays is thus a summation over all the individual
> detector recordings during that time slot).
> 
> As such, I would expect this value to be either constant (I guess most
> mass specs do not allow dynamic setting of this value, but I could be
> wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in
> the seconds field, say, would therefore probably lead to confusion?
> 
> 
> Cheers,
> 
> lnnrt.
> 
> Kent Laursen wrote:
> > Hi Lennart,
> >
> > There is not currently a term labeled retention time in the MS CV.  The
> > current terms for the purpose are:
> >
> > [Term]
> > id: PSI:1000038
> > name: Time In Minutes
> > def: "Acquisition time in minutes." [PSI:GPS]
> > is_a: PSI:1000460 ! Unit
> > relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> >
> > [Term]
> > id: PSI:1000039
> > name: Time In Seconds
> > def: "Acquisition time in seconds." [PSI:GPS]
> > is_a: PSI:1000460 ! Unit
> > relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> >
> > Regards,
> >
> > Kent
> >
> >> -----Original Message-----
> >> From: psi...@li... [mailto:psidev-ms-
> dev-
> >> bo...@li...] On Behalf Of Lennart Martens
> >> Sent: Thursday, November 09, 2006 9:27 AM
> >> To: psi...@li...
> >> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
> >>
> >> Hi,
> >>
> >>
> >>
> >> I am processing some mzXML files into mzData for insertion into the
> >> PRIDE database, and I can't seem to find an ontology term for
> 'retention
> >> time' in the PSI-MS ontology.
> >>
> >> If there is one, and I just can't find it for some silly reason, please
> >> let me know.
> >>
> >> If there isn't any, could this be added? It seems like a sensible thing
> >> as it is a common enough piece of data.
> >>
> >>
> >> Thanks in advance,
> >>
> >>
> >> lnnrt.
> >>
> >> -----------------------------------------------------------------------
> --
> >> Using Tomcat but need to do more? Need to support web services,
> security?
> >> Get stuff done quickly with pre-integrated technology to make your job
> >> easier
> >> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> >> http://sel.as-
> us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> >
> 
> --
> Dr. Lennart Martens
> 
> Senior Software Developer
> Proteomics Services
> Sequence Database Group
> EMBL-European Bioinformatics Institute
> Wellcome Trust Genome Campus
> Hinxton
> Cambridge
> CB10 1SD
> United Kingdom
> 
> Tel.:  +44 (0)1223 492 610 (Direct Line)
> Fax:  +44 (0)1223 494 484
> Skype: lennart_martens

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

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

Hi,

A related issue is for the case of peak lists which have been generated 
from the combination of several scans. The 'TimeInMinutes' for these is 
obviously also a range of time. I've solved this by just putting the 
start acquisition time of the first spectrum in the range, but one could 
of course as well put the average time.  The same question appears as 
Lennart writes for individual scans if one want to be exact: is it the 
start time, or average, or end time of the scan which should be in the 
field? Is there any consensus opinion on which should be written, and is 
it documented somewhere?
I don't think this is very important for peak lists since there are 
references to all the scans in the raw file that were combined in the 
form of a list of acquisition-acqNumbers, but if mzData is to represent 
raw data it could become important for LC-MS alignment etc.

Regards

Fredrik Levander


Lennart Martens wrote:
> Hi Kent,
>
>
> Thanks for pointing that out, but I had seen these myself and assumed 
> that they were used to document the actual acquisition time during which 
> the final spectrum was acquired (the final spectrum represented in the 
> mzData binary arrays is thus a summation over all the individual 
> detector recordings during that time slot).
>
> As such, I would expect this value to be either constant (I guess most 
> mass specs do not allow dynamic setting of this value, but I could be 
> wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in 
> the seconds field, say, would therefore probably lead to confusion?
>
>
> Cheers,
>
> lnnrt.
>
> Kent Laursen wrote:
>   
>> Hi Lennart,
>>
>> There is not currently a term labeled retention time in the MS CV.  The
>> current terms for the purpose are:
>>
>> [Term]
>> id: PSI:1000038
>> name: Time In Minutes
>> def: "Acquisition time in minutes." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> [Term]
>> id: PSI:1000039
>> name: Time In Seconds
>> def: "Acquisition time in seconds." [PSI:GPS]
>> is_a: PSI:1000460 ! Unit
>> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
>>
>> Regards,
>>
>> Kent
>>
>>     
>>> -----Original Message-----
>>> From: psi...@li... [mailto:psidev-ms-dev-
>>> bo...@li...] On Behalf Of Lennart Martens
>>> Sent: Thursday, November 09, 2006 9:27 AM
>>> To: psi...@li...
>>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>>
>>> Hi,
>>>
>>>
>>>
>>> I am processing some mzXML files into mzData for insertion into the
>>> PRIDE database, and I can't seem to find an ontology term for 'retention
>>> time' in the PSI-MS ontology.
>>>
>>> If there is one, and I just can't find it for some silly reason, please
>>> let me know.
>>>
>>> If there isn't any, could this be added? It seems like a sensible thing
>>> as it is a common enough piece of data.
>>>
>>>
>>> Thanks in advance,
>>>
>>>
>>> lnnrt.
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job
>>> easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Psidev-ms-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>       
>>     
>
>   

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

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

Hi Kent,


Thanks for pointing that out, but I had seen these myself and assumed 
that they were used to document the actual acquisition time during which 
the final spectrum was acquired (the final spectrum represented in the 
mzData binary arrays is thus a summation over all the individual 
detector recordings during that time slot).

As such, I would expect this value to be either constant (I guess most 
mass specs do not allow dynamic setting of this value, but I could be 
wrong) and certainly small (say from 0.5 to 8 seconds). Having '900' in 
the seconds field, say, would therefore probably lead to confusion?


Cheers,

lnnrt.

Kent Laursen wrote:
> Hi Lennart,
> 
> There is not currently a term labeled retention time in the MS CV.  The
> current terms for the purpose are:
> 
> [Term]
> id: PSI:1000038
> name: Time In Minutes
> def: "Acquisition time in minutes." [PSI:GPS]
> is_a: PSI:1000460 ! Unit
> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> 
> [Term]
> id: PSI:1000039
> name: Time In Seconds
> def: "Acquisition time in seconds." [PSI:GPS]
> is_a: PSI:1000460 ! Unit
> relationship: part_of PSI:1000459 ! Spectrum Instrument Description
> 
> Regards,
> 
> Kent
> 
>> -----Original Message-----
>> From: psi...@li... [mailto:psidev-ms-dev-
>> bo...@li...] On Behalf Of Lennart Martens
>> Sent: Thursday, November 09, 2006 9:27 AM
>> To: psi...@li...
>> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
>>
>> Hi,
>>
>>
>>
>> I am processing some mzXML files into mzData for insertion into the
>> PRIDE database, and I can't seem to find an ontology term for 'retention
>> time' in the PSI-MS ontology.
>>
>> If there is one, and I just can't find it for some silly reason, please
>> let me know.
>>
>> If there isn't any, could this be added? It seems like a sensible thing
>> as it is a common enough piece of data.
>>
>>
>> Thanks in advance,
>>
>>
>> lnnrt.
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 

-- 
Dr. Lennart Martens

Senior Software Developer
Proteomics Services
Sequence Database Group
EMBL-European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton
Cambridge
CB10 1SD
United Kingdom

Tel.:  +44 (0)1223 492 610 (Direct Line)
Fax:  +44 (0)1223 494 484
Skype: lennart_martens

Re: [Psidev-ms-dev] Retention time in PSI-MS ontology

[Kent L. <knl...@in...>]

Hi Lennart,

There is not currently a term labeled retention time in the MS CV.  The
current terms for the purpose are:

[Term]
id: PSI:1000038
name: Time In Minutes
def: "Acquisition time in minutes." [PSI:GPS]
is_a: PSI:1000460 ! Unit
relationship: part_of PSI:1000459 ! Spectrum Instrument Description

[Term]
id: PSI:1000039
name: Time In Seconds
def: "Acquisition time in seconds." [PSI:GPS]
is_a: PSI:1000460 ! Unit
relationship: part_of PSI:1000459 ! Spectrum Instrument Description

Regards,

Kent

> -----Original Message-----
> From: psi...@li... [mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Lennart Martens
> Sent: Thursday, November 09, 2006 9:27 AM
> To: psi...@li...
> Subject: [Psidev-ms-dev] Retention time in PSI-MS ontology
> 
> Hi,
> 
> 
> 
> I am processing some mzXML files into mzData for insertion into the
> PRIDE database, and I can't seem to find an ontology term for 'retention
> time' in the PSI-MS ontology.
> 
> If there is one, and I just can't find it for some silly reason, please
> let me know.
> 
> If there isn't any, could this be added? It seems like a sensible thing
> as it is a common enough piece of data.
> 
> 
> Thanks in advance,
> 
> 
> lnnrt.
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Retention time in PSI-MS ontology

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

Hi,



I am processing some mzXML files into mzData for insertion into the 
PRIDE database, and I can't seem to find an ontology term for 'retention 
time' in the PSI-MS ontology.

If there is one, and I just can't find it for some silly reason, please 
let me know.

If there isn't any, could this be added? It seems like a sensible thing 
as it is a common enough piece of data.


Thanks in advance,


lnnrt.

Re: [Psidev-ms-dev] Need help with mzData converter ...

[Simon A. <sim...@bb...>]

On 23 Oct 2006, at 17:10, Pancerella, Carmen M wrote:

> Hi.
>
> I'm looking for a converter that converts from mzData into either a  
> text or CSV representation.  I'd prefer open source source code, as  
> I want to use this in a project that we're doing.
What information are you looking to extract from the mzData?  Being  
XML mzData files are already text (albeit structured text).  Trying  
to make a more plain text format which kept all of the information in  
the original file would end up being a mess.

We've written an opensource mzData viewer which parses the XML files  
and extracts out the core data.  Maybe some of the classes in there  
would help you get started? Adding a text output to it wouldn't be  
hard.  You can find it at: http://www.bioinformatics.bbsrc.ac.uk/ 
projects/mzviewer/

Simon.

[Psidev-ms-dev] Need help with mzData converter ...

[Alexandre M. <ol...@ge...>]

Hi

go 4 a try at http://insilicospectro.vital-it.ch/cgis.html

If it fit your needs, you also install it locally and have it directly
scripted.
It's perl, opensource, and should work more or less on any decent OS.

please let us know if you have any trouble

regards
Alex

[sorry for the duplicate if any]

Pancerella, Carmen M wrote:
>
> Hi.
>
> I'm looking for a converter that converts from mzData into either a
> text or CSV representation.  I'd prefer open source source code, as I
> want to use this in a project that we're doing. 
>
> thanks.
> Carmen
>
>

-- 
Alexandre Masselot, phD
Senior bioinformatician
www.genebio.com
voice: +41 22 702 99 00

[Psidev-ms-dev] Need help with mzData converter ...

[Pancerella, C. M <ca...@sa...>]

Hi.

I'm looking for a converter that converts from mzData into either a text =
or CSV representation.  I'd prefer open source source code, as I want to =
use this in a project that we're doing. =20

thanks.
Carmen

Carmen Pancerella, PhD
Advanced Software Research & Development
Sandia National Laboratories
P.O. Box 969, Mailstop 9152
Livermore, CA 94551-0969
=20
Fax: (508) 300-8815
Phone: (617) 630-0316
=20
ca...@sa...

[Psidev-ms-dev] Thermo RAW to mzData converter?

[Johannes G. <gra...@bi...>]

Hello,

I was wondering, whether there's a converter around to create mzData =
from Thermo's RAW?

Thanks for any hints, Joh

Re: [Psidev-ms-dev] Psidev-ms-dev Digest, Vol 5, Issue 4

[Jayson F. <jfa...@um...>]

Could I get a copy of the "see attached straw man diagram images and XML 
Schema". They aren't attached in the digest e-mail.

Thanks,
Jayson Falkner
jfa...@um...

psi...@li... wrote:
> Send Psidev-ms-dev mailing list submissions to
> 	psi...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> or, via email, send a message with subject or body 'help' to
> 	psi...@li...
> 
> You can reach the person managing the list at
> 	psi...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Psidev-ms-dev digest..."
> 
> 
> Today's Topics:
> 
>    1. 2006-10-03 (Kent Laursen)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 11 Oct 2006 13:19:15 -0400
> From: "Kent Laursen" <knl...@in...>
> Subject: [Psidev-ms-dev] 2006-10-03
> To: <psi...@li...>
> Message-ID: <000601c6ed59$60ec77e0$8b01050a@chinook>
> Content-Type: text/plain; charset="us-ascii"
> 
> The conference call minutes for the PSI-MS October 3, 2006 call have been
> posted.  The link to the download is:
> 
>  
> 
> http://psidev.sourceforge.net/docstore/download.php?sess=0
> <http://psidev.sourceforge.net/docstore/download.php?sess=0&id=116> &id=116
> 
>  
> 
>  
> 
> Regards,
> 
>  
> 
> Kent
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://sourceforge.net/mailarchive/forum.php?forum=psidev-ms-dev/attachments/20061011/a38105ba/attachment.html 
> 
> ------------------------------
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> ------------------------------
> 
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 
> End of Psidev-ms-dev Digest, Vol 5, Issue 4
> *******************************************
> 
> 

[Psidev-ms-dev] 2006-10-03

[Kent L. <knl...@in...>]

The conference call minutes for the PSI-MS October 3, 2006 call have been
posted.  The link to the download is:

 

http://psidev.sourceforge.net/docstore/download.php?sess=0
<http://psidev.sourceforge.net/docstore/download.php?sess=0&id=116> &id=116

 

 

Regards,

 

Kent

 

Re: [Psidev-ms-dev] FW: Why base64?

[Tom B. <tb...@um...>]

The comment was made this morning (fourth paragraph below):

       > If the cost is a little more code in the parser
       > to deal with one more 'choice' element (of which
       > we have many), then that seems small  . . .

To the contrary:  a more important cost will be many applications 
which say they 'support' the mzData standard, but handle only one 
or other of the two alternate data representations.  This has the 
potential for confusion among developers and users about what it 
means to support the standard.  In an ideal world, all applications 
would support both  . . .  but in practice I fear that developers 
will implement only the branch they need.

To me, the central question is one of community sociology:  will 
it be clearer to the community to describe mzData as one standard 
containing alternatives -- or as two separate and possibly 
interoperable standards with separate names ?  I think this is 
more important than the technical issues.

I am extremely apprehensive about allowing alternate representations 
for the same information in a single standard.  The value of having 
a standard data exchange format is to give each user the confidence 
that what is in a file, or what are the capabilities of an application 
are what he or she expects -- without checking in detail and without 
special-casing the data files from different sources.  Simplicity 
and uniformity are key.  With the greatest respect for all of the 
contributors, especially Randy Julian, I have to agree with Brian 
Pratt and Angel Pizarro on this point:  to have ambiguity in the 
mzData standard at the level of allowing two alternate representations 
for the same information is effectively not to have a standard.

Tom Blackwell
University of Michigan Bioinformatics
Ann Arbor, Michigan

    (I have appended Brian Pratt's and Lewis Geer's contributions
     from this morning below Randy Julian's email.)


On Fri, 6 Oct 2006, Randy Julian wrote:

> In the mass spectrometry community there is a long history of building 
> spectral databases which benefit from direct readability.
>
> Historically these have been plain ASCII representations including things 
> like JCAMP-DX, etc.  I think this list would agree that it would be better 
> to use a HUPO format if for a peptide database.  mzData could provide 
> desirable additional instrument parameter information and provide a 
> consistent mechanism for dealing with MS data across the proteomics 
> community.  To choose a numeric representation which causes groups like the 
> NIST to use another format to receive and deliver data would be a loss.
>
> Instrument vendors are now providing exports to mzData, and I think it is 
> critical that these exports be usable to submit data to mass spectral 
> databases like those used by the MS community for years.
>
> If the cost is a little more code in the parser to deal with one more 
> 'choice' element (of which we have many), then that seems small compared to 
> the consequence of the NIST not being able to use the standard to deliver 
> results to the community and thus requiring us to have a completely 
> difference parser to read yet another MS format.
>
> Randy
>
> ===
>
> Steve wrote:
>
> ...
> 
> In our library, for example, we want the users to see the values that we 
> put there, so we use ASCII. It would be very desirable for us if the same 
> were offered in the XML's - otherwise we will have to go non-standard.
> ...
>
> -Steve Stein
>
> ===
>
> Later Mike wrote:
>
> that touches on this issue.  Also, an example on that page suggests 
> another possibility for the encoding of peaklists that I prefer to 
> those discussed so far:
>
> <peaklist>
>  <peak mz="234.56" i="789" />
>  <peak mz="3456.43" i="2" />
>  <peak mz="3457.22" i="234" />
> </peaklist>
>
> This would have the virtue of being highly accessible to eyeball and 
> quick-and-dirty scripts as well.  It would also clearly compress well. 
> And it keeps the peak data within the realm of XML.  It would be 
> conceivable, I think, to use XSLT to create a table of peak data or 
> even an SVG image of the spectrum, for example, since everything would 
> be living in XML-land.
>
>
>> ...A standard that provides n>1 ways 
>> to state the same thing is n times as difficult to implement and maintain, 
>> which reduces vendor enthusiasm by a factor of n (squared?), which hinders 
>> widespread adoption. ...
>
>
> I generally agree with this, and in particular, I suspect that if the 
> specification allowed both representations, possibly most vendors 
> would only produce base64 output.  For this reason, if the textual 
> representation is preferred, maybe the base64 alternative should be 
> deprecated and marked for removal in a future version.
>
> However, I think that there is still an advantage to having the 
> textual alternative in the specification, even if instrument vendors 
> never produce it.  It would allow those of us who prefer the textual 
> format to do convert to it in a standard way, in a way that 
> coordinates with the mzData standard.
>
>

> From bri...@in... Fri Oct  6 11:18:17 2006

> If one were to pursue the ASCII course then the structured approach Mike 
> presents is clearly the way to go.  I still think it doesn't scale well, 
> though, and can't imagine the mass spec vendors actually writing such files.

> To those on the thread saying "if there is a need for an eyeballable format, 
> let it be part of this standard instead of Yet Another standard", I heartily 
> agree.  But when we talk of using XSLT to make peak tables, etc, well heck, 
> that's just more software translation and isn't really eyeballing, so why 
> mess with another format?

> But...

> It becomes apparent (or am I just slow to catch on?) that we may be 
> discussing two different ideas - I think Mike thinks of a "peak" as a 
> postprocessed idea, something coming out of a peak picking algorithm, 
> while others of us think of a "peak" as an m/z pair in an unprocessed 
> raw mass spec output (not deconvoluted, deisotoped, denoised, 
> de-anything-ed).  Both are of interest, of course, but the latter isn't 
> really amenable to an ASCII representation due to its sheer bulk. 
> So maybe what we should be looking at is two different data elements, 
> each with its own represetation - and ASCII is arguably the right one 
> for a postprocessed peak pick list.

> - Brian

> -----Original Message-----
> From: psi...@li... 
> [mailto:psi...@li...] On 
> Behalf Of Mike Coleman
> Sent: Thursday, October 05, 2006 11:48 PM
> To: bri...@in...
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] FW: Why base64?
> 
> On 10/5/06, Brian Pratt <bri...@in...> wrote:
> >...the unsuitability of XML for eyeballing what is essentially
> columnar data, ...
> 
> I do think "eyeballability" is important, but I also feel uneasy
> placing the key spectrum data beyond the reach of XML in an XML
> spectrum format.  In essence, in the current version the XML encodes
> spectrum metadata--the peaks themselves become an afterthought, hidden
> away in a relatively inaccessible appendix.
> 
> This would be easier to justify if this were image data, for which
> there is no reasonable textual representation.  But in this case there
> is a trivial representation, and the code to read and write it is
> probably simpler than for the base64-encoded case.
> 
> There's some discussion here
>
>     http://c2.com/cgi/wiki?IsolateEachDatum
> 
> that touches on this issue.  Also, an example on that page suggests
> another possibility for the encoding of peaklists that I prefer to
> those discussed so far:
> 
> <peaklist>
>   <peak mz="234.56" i="789" />
>   <peak mz="3456.43" i="2" />
>   <peak mz="3457.22" i="234" />
> </peaklist>
> 
> This would have the virtue of being highly accessible to eyeball and
> quick-and-dirty scripts as well.  It would also clearly compress well.
>  And it keeps the peak data within the realm of XML.  It would be
> conceivable, I think, to use XSLT to create a table of peak data or
> even an SVG image of the spectrum, for example, since everything would
> be living in XML-land.
> 
> > ...A standard that provides n>1 ways
> > to state the same thing is n times as difficult to 
> implement and maintain,
> > which reduces vendor enthusiasm by a factor of n 
> (squared?), which hinders
> > widespread adoption. ...
> 
> I generally agree with this, and in particular, I suspect that if the
> specification allowed both representations, possibly most vendors
> would only produce base64 output.  For this reason, if the textual
> representation is preferred, maybe the base64 alternative should be
> deprecated and marked for removal in a future version.
> 
> However, I think that there is still an advantage to having the
> textual alternative in the specification, even if instrument vendors
> never produce it.  It would allow those of us who prefer the textual
> format to do convert to it in a standard way, in a way that
> coordinates with the mzData standard.
> 
> Mike
> 
> --------------------------------------------------------------


>From le...@nc... Fri Oct  6 10:28:08 2006
Date: Fri, 6 Oct 2006 10:27:46 -0400
From: "Geer, Lewis (NIH/NLM/NCBI) [E]" <le...@nc...>
To: psi...@li...
Subject: Re: [Psidev-ms-dev] FW:  Why base64?

Hi,

I guess the general experience at NCBI is to make standards as flexible
as possible while making them as explicit, easy to read, and validatible
as possible.  The pain of having multiple representations within the
same standard is much less than the pain of having multiple standards,
which can happen if a particular standard is too rigid.

The "easy to read" requirement means by both machine and human -- human
readable probably being the most important because of all of the endless
debugging required when reading and writing files.  It seems much more
fun writing new applications than dealing with import/export code!

Lewis

Re: [Psidev-ms-dev] FW: Why base64?

[Brian P. <bri...@in...>]

If one were to pursue the ASCII course then the structured approach Mike presents is clearly the way to go.  I still think it
doesn't scale well, though, and can't imagine the mass spec vendors actually writing such files.

To those on the thread saying "if there is a need for an eyeballable format, let it be part of this standard instead of Yet Another
standard", I heartily agree.  But when we talk of using XSLT to make peak tables, etc, well heck, that's just more software
translation and isn't really eyeballing, so why mess with another format?

But...

It becomes apparent (or am I just slow to catch on?) that we may be discussing two different ideas - I think Mike thinks of a "peak"
as a postprocessed idea, something coming out of a peak picking algorithm, while others of us think of a "peak" as an m/z pair in an
unprocessed raw mass spec output (not deconvoluted, deisotoped, denoised, de-anything-ed).  Both are of interest, of course, but the
latter isn't really amenable to an ASCII representation due to its sheer bulk.  So maybe what we should be looking at is two
different data elements, each with its own represetation - and ASCII is arguably the right one for a postprocessed peak pick list.

- Brian


> -----Original Message-----
> From: psi...@li... 
> [mailto:psi...@li...] On 
> Behalf Of Mike Coleman
> Sent: Thursday, October 05, 2006 11:48 PM
> To: bri...@in...
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] FW: Why base64?
> 
> On 10/5/06, Brian Pratt <bri...@in...> wrote:
> >...the unsuitability of XML for eyeballing what is essentially
> columnar data, ...
> 
> I do think "eyeballability" is important, but I also feel uneasy
> placing the key spectrum data beyond the reach of XML in an XML
> spectrum format.  In essence, in the current version the XML encodes
> spectrum metadata--the peaks themselves become an afterthought, hidden
> away in a relatively inaccessible appendix.
> 
> This would be easier to justify if this were image data, for which
> there is no reasonable textual representation.  But in this case there
> is a trivial representation, and the code to read and write it is
> probably simpler than for the base64-encoded case.
> 
> There's some discussion here
> 
>     http://c2.com/cgi/wiki?IsolateEachDatum
> 
> that touches on this issue.  Also, an example on that page suggests
> another possibility for the encoding of peaklists that I prefer to
> those discussed so far:
> 
> <peaklist>
>   <peak mz="234.56" i="789" />
>   <peak mz="3456.43" i="2" />
>   <peak mz="3457.22" i="234" />
> </peaklist>
> 
> This would have the virtue of being highly accessible to eyeball and
> quick-and-dirty scripts as well.  It would also clearly compress well.
>  And it keeps the peak data within the realm of XML.  It would be
> conceivable, I think, to use XSLT to create a table of peak data or
> even an SVG image of the spectrum, for example, since everything would
> be living in XML-land.
> 
> 
> > ...A standard that provides n>1 ways
> > to state the same thing is n times as difficult to 
> implement and maintain,
> > which reduces vendor enthusiasm by a factor of n 
> (squared?), which hinders
> > widespread adoption. ...
> 
> I generally agree with this, and in particular, I suspect that if the
> specification allowed both representations, possibly most vendors
> would only produce base64 output.  For this reason, if the textual
> representation is preferred, maybe the base64 alternative should be
> deprecated and marked for removal in a future version.
> 
> However, I think that there is still an advantage to having the
> textual alternative in the specification, even if instrument vendors
> never produce it.  It would allow those of us who prefer the textual
> format to do convert to it in a standard way, in a way that
> coordinates with the mzData standard.
> 
> Mike
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys -- and 
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] FW: Why base64?

[Talapady N B. <bh...@ni...>]

Hi,
I fully agree. Rigid standards usually stay only on 'paper' and they foster
chaos. 'import/export' codes are the breading grounds for multiple
standards.
Best regards,
T N Bhat

----- Original Message ----- 
From: "Geer, Lewis (NIH/NLM/NCBI) [E]" <le...@nc...>
To: <psi...@li...>
Sent: Friday, October 06, 2006 10:27 AM
Subject: Re: [Psidev-ms-dev] FW: Why base64?


> Hi,
>
> I guess the general experience at NCBI is to make standards as flexible
> as possible while making them as explicit, easy to read, and validatible
> as possible.  The pain of having multiple representations within the
> same standard is much less than the pain of having multiple standards,
> which can happen if a particular standard is too rigid.
>
> The "easy to read" requirement means by both machine and human -- human
> readable probably being the most important because of all of the endless
> debugging required when reading and writing files.  It seems much more
> fun writing new applications than dealing with import/export code!
>
> Lewis
>
> -----Original Message-----
> From: Angel Pizarro [mailto:an...@ma...]
> Sent: Thursday, October 05, 2006 3:17 PM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] FW: Why base64?
>
>
> I have to second Brian on this one. From the operational and reporting
> requirements, having both ascii and binary representations just adds
> confusion. Better to address the problem of perceived complexity and
> general usage through tool development efforts.
>
> Also, this case:
> > It is the simple case of 'represent a single tandem MS spectrum of a
> > single peptide at only the precision of the m/z calibration' that is
> > harder than it needs to be with the current representation.
> >
> is not used outside of post analysis verification of the spectra (e.g.
> was the assignement of spectra valid, where the right peaks used for
> quant, etc.) Very low-throughput and NOT viewed outside of the analysis
> context.
>
> This is just my perception though, so if someone has an example please
> speak up.
>
> angel
>
>
> Brian Pratt wrote:
> > I'm strongly opposed to the change.  In addtion to the previously
> > discussed concerns about accuracy and the fundamental pointlessness
> > due to the unsuitability of XML for eyeballing what is essentially
> > columnar data, there's an additional and perhaps deeper practical
> concern:
> >
> > A data exchange standard that provides many ways to express the same
> > idea is headed for the rocks.  Vendors will tend to implement only the
>
> > parts of the standard that interest them and the ecosystem quickly
> > breaks down (I speak from experience with interchange standards in the
>
> > internet security and circuit board manufacturing software industries,
>
> > it's a phenomenon not peculiar to any one field of endeavor).  A
> > standard that provides n>1 ways to state the same thing is n times as
> > difficult to implement and maintain, which reduces vendor enthusiasm
> > by a factor of n (squared?), which hinders widespread adoption.
> >
> > As we sometimes say in the States, "If it ain't broke, don't fix it."
> >
> > Brian Pratt
> >
> >
> >
> ------------------------------------------------------------------------
> >     *From:* psi...@li...
> >     [mailto:psi...@li...] *On Behalf Of
> >     *Pierre-Alain Binz
> >     *Sent:* Thursday, October 05, 2006 5:10 AM
> >     *To:* Randy Julian
> >     *Cc:* psi...@li...
> >     *Subject:* Re: [Psidev-ms-dev] FW: Why base64?
> >
> >     I am for the possibility to represent a spectrum/peaklist/even
> >     chromatogram in more than one manner ONLY if these representations
> >     are easy and straighforward to generate and to parse AND if there
> >     is a good (or better blocking) reason to do so. We need to avoid
> >     optional things that make any implementation subject to
> >     interpretation and missunderstanding.
> >     So yes only if the two formats are strictly and clearly described
> >     and discriminated (specification issue)
> >
> >     Pierre-Alain
> >
> >     Randy Julian wrote:
> >>     There was concern in the NBT review of the mzData manuscript that
> the format
> >>     was not able specifically designed for either quantitation or
> 'raw' data.
> >>     Quite the opposite is true - it handles these better than it
> handles a 'peak
> >>     list'.
> >>
> >>     Given the broad scope we are going for, I think mzData 2.0 needs
> to cover
> >>     both of Mike's suggestions.
> >>
> >>     The representation should allow an ASCII list representation,
> _and_ a base64
> >>     list option.  Within each of these, the _desired_ precision
> should be used.
> >>     If you want to make some kind of 21CFR11 claim regarding GLP or
> GCP for
> >>     clinical data (metabolites, proteins or biomarker analyses) then
> the ability
> >>     to represent 'raw' data is critical and part of the current
> >> design.
> >>
> >>     It is the simple case of 'represent a single tandem MS spectrum
> of a single
> >>     peptide at only the precision of the m/z calibration' that is
> harder than it
> >>     needs to be with the current representation.
> >>
> >>     During the Washington PSI meeting a proposal was made to
> re-introduce the
> >>     ASCII data representation that was dropped at the PSI meeting in
> Nice.  What
> >>     does everyone think of this idea?
> >>
> >>     Randy
> >>
> >>     -----Original Message-----
> >>     From: psi...@li...
> >>     [mailto:psi...@li...] On Behalf Of
> Mike
> >>     Coleman
> >>     Sent: Wednesday, October 04, 2006 3:13 PM
> >>     To: Angel Pizarro
> >>     Cc: Psi...@li...
> >>     Subject: Re: [Psidev-ms-dev] Why base64?
> >>
> >>     [This message seems to have been bounced by Sourceforge, so I'm
> >>     resending it.  I'm sorry to see that apparently they are having
> >>     serious email problems these days.  See today's Slashdot article
> at
> >>     http://it.slashdot.org/article.pl?sid=06/10/04/1324214.
> (Apparently
> >>     the problem isn't limited to email coming from gmail accounts.) ]
> >>
> >>     On 9/28/06, Mike Coleman <tu...@gm...> wrote:
> >>
> >>>     Makes sense.  To put it in other words, there are two questions
> >>> here:
> >>>
> >>>     1.  Are the values represented as base64-encoded bitstrings or
> >>> as ASCII
> >>>
> >>     text?
> >>
> >>>     2.  Should the values be rounded to the precision of the
> instrument
> >>>     (probably plus a digit, etc.), or should an arbitrary number of
> >>>     figures be used?  Again, this isn't about losing information, as
> we're
> >>>     only discussing rounding away noise.
> >>>
> >>>     These two questions are entirely orthogonal, as far as I can
> see, and
> >>>     it would be possible to allow both options for both questions,
> if this
> >>>     were seen as being worthwhile.  The one interaction is that if
> you use
> >>>     the ASCII text encoding, rounding the figures will make the
> mzData
> >>>     file smaller.
> >>>
> >>>     Regarding ambiguity, the ASCII text representation would allow
> >>>     differing whitespace (which produce no semantic difference).  I
> guess
> >>>     the base64 encoding also allows differing surrounding
> >>> whitespace.
> >>>
> >>>     With respect to the base64 encoding, one corner case comes to
> mind.
> >>>     Are special IEEE values like NaN, the infinities, negative zero,
> etc.,
> >>>     allowed?  If so, what should the interpretation be?
> >>>
> >>>     Mike
> >>>
> >>>
> >>>     The example code I mentioned:
> >>>
> >>>     /* gcc -g -O2 -ffloat-store -o ieee-test ieee-test.c */
> >>>
> >>>     /* strtof is GNU/C99 */
> >>>     #define _GNU_SOURCE
> >>>
> >>>     #include <assert.h>
> >>>     #include <errno.h>
> >>>     #include <limits.h>
> >>>     #include <stdio.h>
> >>>     #include <stdlib.h>
> >>>
> >>>
> >>>     union bits {
> >>>       unsigned int u;
> >>>       float f;
> >>>     };
> >>>
> >>>
> >>>     int
> >>>     main() {
> >>>       unsigned int i;
> >>>       union bits x, x2;
> >>>       int zeros_seen = 0;
> >>>
> >>>       assert(sizeof x.u == sizeof x.f);
> >>>       assert(&x.u == &x.f);
> >>>
> >>>
> >>>
> >>>       for (i=0; ; i++) {
> >>>         char buf[128];
> >>>
> >>>         if (i == 0)
> >>>           if (++zeros_seen > 1)
> >>>             break;
> >>>
> >>>     #if 0
> >>>         if (!(i % 100000))
> >>>           putc('.', stderr);
> >>>     #endif
> >>>
> >>>         x.u = i;
> >>>         if (x.f != x.f)
> >>>           continue;                 /* skip error values */
> >>>
> >>>         sprintf(buf, "%.8e", x.f);
> >>>
> >>>         errno = 0;
> >>>         x2.f = strtof(buf, 0);
> >>>         if (errno == ERANGE) {
> >>>           printf("strtof error for %s\n", buf);
> >>>           continue;
> >>>         }
> >>>
> >>>         if (x2.u != x.u)
> >>>           printf("bit difference for %s (%u != %u)\n", buf, x2.u,
> x.u);
> >>>       }
> >>>     }
> >>>
> >>>
> >>
> >>
> ------------------------------------------------------------------------
> -
> >>     Take Surveys. Earn Cash. Influence the Future of IT
> >>     Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> >>     opinions on IT & business topics through brief surveys -- and
> earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> >>     _______________________________________________
> >>     Psidev-ms-dev mailing list
> >>     Psi...@li...
> >>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>
> >>
> ------------------------------------------------------------------------
> -
> >>     Take Surveys. Earn Cash. Influence the Future of IT
> >>     Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> >>     opinions on IT & business topics through brief surveys -- and
> earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> >>     _______________________________________________
> >>     Psidev-ms-dev mailing list
> >>     Psi...@li...
> >>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>
> >
> >     -- 
> >     --
> >      Dr. Pierre-Alain Binz
> >      Swiss Institute of Bioinformatics
> >      Proteome Informatics Group
> >      1, Rue Michel Servet
> >      CH-1211 Geneve 4
> >      Switzerland
> >      - - - - - - - - - - - - - - - - -
> >      Tel: +41-22-379 50 50
> >      Fax: +41-22-379 58 58
> >      Pie...@is...
> >      http://www.expasy.org/people/Pierre-Alain.Binz.html
> >
> > ----------------------------------------------------------------------
> > --
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > opinions on IT & business topics through brief surveys -- and earn
> cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Psidev-ms-dev mailing list Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
>
> -- 
> Angel Pizarro
> Director, Bioinformatics Facility
> Institute for Translational Medicine and Therapeutics University of
> Pennsylvania 806 BRB II/III 421 Curie Blvd. Philadelphia, PA 19104-6160
>
> P: 215-573-3736
> F: 215-573-9004
> E: an...@ma...
>
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

Re: [Psidev-ms-dev] FW: Why base64?

[Geer, L. \(NIH/NLM/NCBI\) [E] <le...@nc...>]

Hi,

I guess the general experience at NCBI is to make standards as flexible
as possible while making them as explicit, easy to read, and validatible
as possible.  The pain of having multiple representations within the
same standard is much less than the pain of having multiple standards,
which can happen if a particular standard is too rigid. =20

The "easy to read" requirement means by both machine and human -- human
readable probably being the most important because of all of the endless
debugging required when reading and writing files.  It seems much more
fun writing new applications than dealing with import/export code!

Lewis

-----Original Message-----
From: Angel Pizarro [mailto:an...@ma...]=20
Sent: Thursday, October 05, 2006 3:17 PM
To: psi...@li...
Subject: Re: [Psidev-ms-dev] FW: Why base64?


I have to second Brian on this one. From the operational and reporting=20
requirements, having both ascii and binary representations just adds=20
confusion. Better to address the problem of perceived complexity and=20
general usage through tool development efforts.

Also, this case:
> It is the simple case of 'represent a single tandem MS spectrum of a=20
> single peptide at only the precision of the m/z calibration' that is=20
> harder than it needs to be with the current representation.
>  =20
is not used outside of post analysis verification of the spectra (e.g.=20
was the assignement of spectra valid, where the right peaks used for=20
quant, etc.) Very low-throughput and NOT viewed outside of the analysis=20
context.

This is just my perception though, so if someone has an example please=20
speak up.

angel


Brian Pratt wrote:
> I'm strongly opposed to the change.  In addtion to the previously
> discussed concerns about accuracy and the fundamental pointlessness=20
> due to the unsuitability of XML for eyeballing what is essentially=20
> columnar data, there's an additional and perhaps deeper practical
concern:
> =20
> A data exchange standard that provides many ways to express the same
> idea is headed for the rocks.  Vendors will tend to implement only the

> parts of the standard that interest them and the ecosystem quickly=20
> breaks down (I speak from experience with interchange standards in the

> internet security and circuit board manufacturing software industries,

> it's a phenomenon not peculiar to any one field of endeavor).  A=20
> standard that provides n>1 ways to state the same thing is n times as=20
> difficult to implement and maintain, which reduces vendor enthusiasm=20
> by a factor of n (squared?), which hinders widespread adoption.
> =20
> As we sometimes say in the States, "If it ain't broke, don't fix it."
> =20
> Brian Pratt
> =20
>
>
------------------------------------------------------------------------
>     *From:* psi...@li...
>     [mailto:psi...@li...] *On Behalf Of
>     *Pierre-Alain Binz
>     *Sent:* Thursday, October 05, 2006 5:10 AM
>     *To:* Randy Julian
>     *Cc:* psi...@li...
>     *Subject:* Re: [Psidev-ms-dev] FW: Why base64?
>
>     I am for the possibility to represent a spectrum/peaklist/even
>     chromatogram in more than one manner ONLY if these representations
>     are easy and straighforward to generate and to parse AND if there
>     is a good (or better blocking) reason to do so. We need to avoid
>     optional things that make any implementation subject to
>     interpretation and missunderstanding.
>     So yes only if the two formats are strictly and clearly described
>     and discriminated (specification issue)
>
>     Pierre-Alain
>
>     Randy Julian wrote:
>>     There was concern in the NBT review of the mzData manuscript that
the format
>>     was not able specifically designed for either quantitation or
'raw' data.
>>     Quite the opposite is true - it handles these better than it
handles a 'peak
>>     list'.
>>
>>     Given the broad scope we are going for, I think mzData 2.0 needs
to cover
>>     both of Mike's suggestions.
>>
>>     The representation should allow an ASCII list representation,
_and_ a base64
>>     list option.  Within each of these, the _desired_ precision
should be used.
>>     If you want to make some kind of 21CFR11 claim regarding GLP or
GCP for
>>     clinical data (metabolites, proteins or biomarker analyses) then
the ability
>>     to represent 'raw' data is critical and part of the current=20
>> design.
>>
>>     It is the simple case of 'represent a single tandem MS spectrum
of a single
>>     peptide at only the precision of the m/z calibration' that is
harder than it
>>     needs to be with the current representation.
>>
>>     During the Washington PSI meeting a proposal was made to
re-introduce the
>>     ASCII data representation that was dropped at the PSI meeting in
Nice.  What
>>     does everyone think of this idea?
>>
>>     Randy
>>
>>     -----Original Message-----
>>     From: psi...@li...
>>     [mailto:psi...@li...] On Behalf Of
Mike
>>     Coleman
>>     Sent: Wednesday, October 04, 2006 3:13 PM
>>     To: Angel Pizarro
>>     Cc: Psi...@li...
>>     Subject: Re: [Psidev-ms-dev] Why base64?
>>
>>     [This message seems to have been bounced by Sourceforge, so I'm
>>     resending it.  I'm sorry to see that apparently they are having
>>     serious email problems these days.  See today's Slashdot article
at
>>     http://it.slashdot.org/article.pl?sid=3D06/10/04/1324214.
(Apparently
>>     the problem isn't limited to email coming from gmail accounts.) ]
>>
>>     On 9/28/06, Mike Coleman <tu...@gm...> wrote:
>>      =20
>>>     Makes sense.  To put it in other words, there are two questions=20
>>> here:
>>>
>>>     1.  Are the values represented as base64-encoded bitstrings or=20
>>> as ASCII
>>>        =20
>>     text?
>>      =20
>>>     2.  Should the values be rounded to the precision of the
instrument
>>>     (probably plus a digit, etc.), or should an arbitrary number of
>>>     figures be used?  Again, this isn't about losing information, as
we're
>>>     only discussing rounding away noise.
>>>
>>>     These two questions are entirely orthogonal, as far as I can
see, and
>>>     it would be possible to allow both options for both questions,
if this
>>>     were seen as being worthwhile.  The one interaction is that if
you use
>>>     the ASCII text encoding, rounding the figures will make the
mzData
>>>     file smaller.
>>>
>>>     Regarding ambiguity, the ASCII text representation would allow
>>>     differing whitespace (which produce no semantic difference).  I
guess
>>>     the base64 encoding also allows differing surrounding=20
>>> whitespace.
>>>
>>>     With respect to the base64 encoding, one corner case comes to
mind.
>>>     Are special IEEE values like NaN, the infinities, negative zero,
etc.,
>>>     allowed?  If so, what should the interpretation be?
>>>
>>>     Mike
>>>
>>>
>>>     The example code I mentioned:
>>>
>>>     /* gcc -g -O2 -ffloat-store -o ieee-test ieee-test.c */
>>>
>>>     /* strtof is GNU/C99 */
>>>     #define _GNU_SOURCE
>>>
>>>     #include <assert.h>
>>>     #include <errno.h>
>>>     #include <limits.h>
>>>     #include <stdio.h>
>>>     #include <stdlib.h>
>>>
>>>
>>>     union bits {
>>>       unsigned int u;
>>>       float f;
>>>     };
>>>
>>>
>>>     int
>>>     main() {
>>>       unsigned int i;
>>>       union bits x, x2;
>>>       int zeros_seen =3D 0;
>>>
>>>       assert(sizeof x.u =3D=3D sizeof x.f);
>>>       assert(&x.u =3D=3D &x.f);
>>>
>>>
>>>
>>>       for (i=3D0; ; i++) {
>>>         char buf[128];
>>>
>>>         if (i =3D=3D 0)
>>>           if (++zeros_seen > 1)
>>>             break;
>>>
>>>     #if 0
>>>         if (!(i % 100000))
>>>           putc('.', stderr);
>>>     #endif
>>>
>>>         x.u =3D i;
>>>         if (x.f !=3D x.f)
>>>           continue;                 /* skip error values */
>>>
>>>         sprintf(buf, "%.8e", x.f);
>>>
>>>         errno =3D 0;
>>>         x2.f =3D strtof(buf, 0);
>>>         if (errno =3D=3D ERANGE) {
>>>           printf("strtof error for %s\n", buf);
>>>           continue;
>>>         }
>>>
>>>         if (x2.u !=3D x.u)
>>>           printf("bit difference for %s (%u !=3D %u)\n", buf, x2.u,
x.u);
>>>       }
>>>     }
>>>
>>>        =20
>>
>>
------------------------------------------------------------------------
-
>>     Take Surveys. Earn Cash. Influence the Future of IT
>>     Join SourceForge.net's Techsay panel and you'll get the chance to
share your
>>     opinions on IT & business topics through brief surveys -- and
earn cash
>>
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
>>     _______________________________________________
>>     Psidev-ms-dev mailing list
>>     Psi...@li...
>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>>
------------------------------------------------------------------------
-
>>     Take Surveys. Earn Cash. Influence the Future of IT
>>     Join SourceForge.net's Techsay panel and you'll get the chance to
share your
>>     opinions on IT & business topics through brief surveys -- and
earn cash
>>
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
>>     _______________________________________________
>>     Psidev-ms-dev mailing list
>>     Psi...@li...
>>     https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>      =20
>
>     --=20
>     --
>      Dr. Pierre-Alain Binz
>      Swiss Institute of Bioinformatics
>      Proteome Informatics Group
>      1, Rue Michel Servet
>      CH-1211 Geneve 4
>      Switzerland
>      - - - - - - - - - - - - - - - - -
>      Tel: +41-22-379 50 50
>      Fax: +41-22-379 58 58
>      Pie...@is...
>      http://www.expasy.org/people/Pierre-Alain.Binz.html
>
> ----------------------------------------------------------------------
> --
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share your
> opinions on IT & business topics through brief surveys -- and earn
cash
>
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
>
------------------------------------------------------------------------
>
> _______________________________________________
> Psidev-ms-dev mailing list Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>  =20

--=20
Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics University of
Pennsylvania 806 BRB II/III 421 Curie Blvd. Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004
E: an...@ma...


------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev