psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] ProteoWizard 1.0 released

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

Hi all,

 

I'm happy to announce the official release of ProteoWizard, available on
SourceForge under the Apache license.

 

Codebase is available through public subversion, and the first source
and binary (Windows and Linux i386) packages are available for download.


 

The binary tools packages may be of interest to this group of mzML
enthusiasts:

 

msconvert: converts RAW -> mzML <-> mzXML, (and more vendor formats
hopefully soon with the help of Matt Chambers!)

 

msaccess:  extracts spectrum data & metadata, selected ion
chromatograms, pseudo-2D-gel image generation

                  (works on RAW/mzML/mzXML equally well, except no RAW
on Linux)

 

Here's the website:

http://proteowizard.sourceforge.net

 

I'll be presenting a poster about ProteoWizard this Tuesday at US HUPO
-- I'd love to meet any of you who will be there!

 

 

Darren

 

 

 

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

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

Re: [Psidev-ms-dev] Proteomics results validation

[Chris T. <chr...@eb...>]

Hiya.

[I've cc'd this to the PSI mass spec group also.]

I've set up small meetings at ASMS before, perhaps you could 
cause this meeting to occur?

People love "doctor's surgeries" at these sort of meetings 
(sounds less formal and more open than a 'workshop' -- 'dumb' 
questions welcome iyswim) -- if you can find a friendly interest 
group head (probably the Computer Applications IG?) and get them 
to informally sponsor a request for a room and stuff, and 
outline the plan (experts on a panel answer questions like those 
you hint at, with lots of free discussion in a relaxed 
atmosphere [so time it for after ppl have had some free beer]) 
I'm sure they'd go for it -- especially this far out. They may 
even promote it (it is, after all, a guaranteed success if 
promoted and if the panel is reasonable which shouldn't be hard 
at ASMS). Getting an interest group head to sponsor will help a lot.

Anyway just thoughts -- ignore at will.

Cheers, Chris.


DaGue, Beverly B. wrote:
> Is there an interest group that meets at the ASMS meeting to discuss
> these issues of data validation, reverse sequence searches, etc.?   
> 
>  
> 
> Beverly DaGue
> 
> Senior Research Chemist
> 
> Charles W. Gehrke Proteomics Center
> 
> 212 Life Sciences Center
> 
> 1201 East Rollins Road
> 
> University of Missouri
> 
> Columbia, MO 65211-7310
> 
> 573-882-5481
> 
> ----------------------------~~~-----------------------------
> The views and ideas posted on the ABRF Electronic Discussion List are those of the participants and no responsibility can be taken by the ABRF.
> To unsubscribe yourself from this mailing list, send a blank email to: <lis...@li...>
> To change the address at which you receive the ABRF List just "unsubscribe" using the old email account  and "subscribe" using the new email account.
> To post anonymously, send a message to omb...@ab.... 
> Please do not set "autoresponders" to reply to this list.  A better solution is to "suspend" your subscription when you leave and "unsuspend" when you return.
> For these and other list commands, send a blank email to:  <lis...@li...>
> For posting guidelines and other information see our web site at http://www.abrf.org/index.cfm/page/discList/ListServe.htm
> For archives of this discussion group, see http://abrf.org/index.cfm/list.home
> Note that attachments will not be delivered for reasons of security and bandwidth.
> For questions and problems, please send a message to lis...@li...
> You are currently subscribed as: chr...@eb...
> ----------------------------~~~-----------------------------
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

[Psidev-ms-dev] [Fwd: Proteomics results validation]

[Chris T. <chr...@eb...>]

Hiya.

Not everyone on here is on the ABRF list, so I thought it might 
be worth forwarding this question.

Cheers, Chris.


-------- Original Message --------
Subject: Proteomics results validation
Date: Wed, 12 Mar 2008 12:30:42 -0500
From: DaGue, Beverly B. <da...@mi...>
Reply-To: ABRF Discussion List <AB...@li...>


Is there an interest group that meets at the ASMS meeting to 
discuss these issues of data validation, reverse sequence 
searches, etc.?



Beverly DaGue
Senior Research Chemist
Charles W. Gehrke Proteomics Center
212 Life Sciences Center
1201 East Rollins Road
University of Missouri
Columbia, MO 65211-7310
573-882-5481

----------------------------~~~-----------------------------
The views and ideas posted on the ABRF Electronic Discussion 
List are those of the participants and no responsibility can be 
taken by the ABRF.
To unsubscribe yourself from this mailing list, send a blank 
email to: <lis...@li...>
To change the address at which you receive the ABRF List just 
"unsubscribe" using the old email account  and "subscribe" using 
the new email account.
To post anonymously, send a message to omb...@ab....
Please do not set "autoresponders" to reply to this list.  A 
better solution is to "suspend" your subscription when you leave 
and "unsuspend" when you return.
For these and other list commands, send a blank email to: 
<lis...@li...>
For posting guidelines and other information see our web site at 
http://www.abrf.org/index.cfm/page/discList/ListServe.htm
For archives of this discussion group, see 
http://abrf.org/index.cfm/list.home
Note that attachments will not be delivered for reasons of 
security and bandwidth.
For questions and problems, please send a message to 
lis...@li...
You are currently subscribed as: chr...@eb...
----------------------------~~~-----------------------------


-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

[Psidev-ms-dev] 41 days until the PSI Spring Meeting in Toledo, Registration is open

[Juan P. A. <jp...@pr...>]

Dear Friends,

Sorry if you get multiple posts, and please distribute to people who 
might be interested.

The HUPO-PSI Spring Meeting 2008  is quickly approaching, register now!

Come and join us April 23-25th, 2008, at  Hotel Beatriz Toledo in 
Toledo, Spain for the Spring Meeting 2008 of the HUPO
Proteomics Standards Initiative.

A unique opportunity to participate in the development of current 
standards in Proteomics.

The PSI working groups are targeting to discuss and deliver a number of 
standards, including (not exhaustively)
- Adaptation of MI XML format to new data types
- PSICQUIC definition
- mzML stable format (merging mzData and mzXML)
- Controlled Vocabularies for a number of PSI modules and the PSI Beta 
Validator framework presentation,
- MIAPE documentation for still remaining modules
- and much more



Detailed information and registration form can be found at
http://www.psidev.info/index.php?q=node/305


Looking forward to seeing you in Toledo,


 From the meeting organization committee and the PSI Steering Group

Juan Pablo Albar


-- 
Dr. Juan Pablo Albar
ProteoRed, Coordinator
Centro Nacional de Biotecnología/CSIC
UAM Campus Cantoblanco
Darwin, 3
Madrid E-28049 Spain

http://www.proteored.org/
Telf  (+34) 91585-4668
Fax  (+34) 91585-4506

Re: [Psidev-ms-dev] NativeID quotation style and charge state cardinality (was: PSI-MSSWG call in 8 hr)

[Coleman, M. <MK...@St...>]

Matthew Chambers:

> >>>     "run1,2",3,4

> >> %22run1%2C2%22,3,4

> >> """foo""" (the implicit rule being
> >> that a pair of "

> > A point of confusion here is that the quoting within
> "run1,2" is operating at a different level than the XML
> quoting.  Perhaps the simplest regime would be to simply
> specify '\"' for '"' and '\\' for '\'.  Ugly, but everyone
> would be familiar with it (from C, sh, etc), and I think it
> won't collide with XML escaping.

> " and ' cannot appear in an XML file except as quotes for
> attributes. So
> it would have to be "\"". "\\" would still work to escape
> backslash, but I think sticking with the XML way of escaping things is
> more consistent. I doubt everyone will be familiar with the C-style
> escape convention, even if it's shared by some *nix shells. I think
> Windows does use "" to escape quotes, I'm not sure though.

I was referring, with my examples, to the inner-level of quoting.  There's so much going on here that it's difficult to even talk about, I think.  Working from the inside out:

1.  I can have a particular "run name" within the comma-separated list.  For example:

    run"with"bizarre"name

2.  Within the list, this might look like

    run"with"biz,arre"name,another"biz,arre"name"<

except that that won't work as is, because we can't tell the commas in the names from the commas separating the names.  We need to escape the commas within names somehow, together with escaping for the escaping, so that we will still be able to form names that ultimately contain any character sequence.

It seems like there are two basic approaches here: (a) use an XML-ish escape mechanism, or (b) use something completely different.  For (b) I'll use the C-ish backslash idea.

I'm in favor of (b) because (a) will make everyone's head explode.  (Note that (a) is *not* straight XML escaping--it can't be.  Rather, it'll have to be a matter of running the string in question through XML (or XML-ish) escape interpretation a second time.)

Assuming (b), we might have

        "run\"with\"biz,arre\"name","another\"biz,arre\"name"<"

or

    'run"with"biz,arre"name','another"biz,arre"name"<'

if we decide that this comma-separated format can also use single-quotes instead of double quotes (as XML and Python do).  Note carefully, however, that none of this is yet XML!  We're still "inside".

3.  Moving outward with the first of those two, now we will XML-escape it, so that it is a valid XML attribute:

    <yyy zzz="run\&quot;with\&quot;biz,arre\&quot;name&quot;,&quot;another\&quot;biz,arre\&quot;name&quot;&lt;">

That's not enough, though, because we "captured" that string '&quot;&lt;' that looks like XML, but is actually part of the name.  We have to be sure to escape the ampersands, too:

    <yyy zzz="run\&quot;with\&quot;biz,arre\&quot;name&quot;,&quot;another\&quot;biz,arre\&quot;name&amp;quot;&amp;lt;">

This is indeed pretty awful, but it's difficult to see what would be better.  If you want to try (a) above (which is I think what you mean when you say "stick with the XML way of quoting"), I'd be curious to see that worked out in the same way.  If it's going into the standard, I definitely think that an example like this should be worked to make sure that everyone understands how things are supposed to work.


What leaps out at me is how ugly and complex this is.  (It also reminds me of why I don't like XML.)  Hopefully most mzML producers will not generate stuff like this, but every consumer will need to correctly interpret it.  The chances that everyone will be able to implement this stuff correctly seem very low.

I think that an XML person would look at this and say that all of this is a sign that the whole inner structure of this comma separated list is too complex and needs to be broken out with something like

    <yyy>
        <zzzlist>
            <zzz>
                run"with"biz,arre"name
            </zzz>
            <zzz>
                another"biz,arre"name&quot;quot;&quot;lt;
            </zzz>
        </zzzlist>
        ...

I don't necessarily agree with that, but I do think that we're kind of torturing XML by trying to squeeze all of that information into one attribute value.

Another alternative that I think should be seriously considered is to just give up and restrict run names to a small set of characters like

    letters (upper and lower)
    digits
    these four characters: .-_:

or perhaps a subset of these--that is, roughly the characters used in identifiers in typical programming languages.  Would this be a terrible hardship?

Mike

[Psidev-ms-dev] ABI 4000 series data conversion to mzML

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

Hi all,

This message is a request to any subscribers to this group that have 
access to an ABI 4000 series instrument with its corresponding (Oracle?) 
database. I am wondering how conversion from such instruments will be 
handled with mzML since it is conceivable that the conversion will not 
happen from a source FILE, merely a "source" (in this case, a database). 
I am not aware of provisions in mzML to handle a data source like this 
and as I understand it, the conversion from database to file that 
currently exists is quite ugly (lots of T2D files).

Thanks for any responses,
-Matt

Re: [Psidev-ms-dev] NativeID quotation style and charge state cardinality (was: PSI-MSSWG call in 8 hr)

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

Coleman, Michael wrote:
>> From: psi...@li...
>> [mailto:psi...@li...] On
>> Behalf Of Matthew Chambers
>>     
>>>     "run1,2",3,4
>>>       
>> Good catch about the double quote character,
>> though. We should allow for it, but I don't know how to escape it!
>> Perhaps we should URL encode the string components instead of using
>> XML-escaped double quotes? So the last example would be:
>> %22run1%2C2%22,3,4
>>
>> That looks awful, but otherwise the string "foo" (including the quotes
>> as part of the string) would have to be encoded like
>> """foo""" (the implicit rule being that a pair of
>> " should be treated as a double-escaped quotation, i.e. it's part
>> of the id string instead of delimiting the string itself.
>>     
> A point of confusion here is that the quoting within "run1,2" is operating at a different level than the XML quoting.  Perhaps the simplest regime would be to simply specify '\"' for '"' and '\\' for '\'.  Ugly, but everyone would be familiar with it (from C, sh, etc), and I think it won't collide with XML escaping.
>
> (The "" for " thing reminds me of VMS.  Does Windows do this, too?)
>   
" and ' cannot appear in an XML file except as quotes for attributes. So 
it would have to be "\"". "\\" would still work to escape 
backslash, but I think sticking with the XML way of escaping things is 
more consistent. I doubt everyone will be familiar with the C-style 
escape convention, even if it's shared by some *nix shells. I think 
Windows does use "" to escape quotes, I'm not sure though.

I'm not married to the weird convention that I suggested though. In 
fact, since I currently only expect that strings in nativeIDs will be 
for exporting ABI 4000 series data, and that comes from a database 
instead of a file, there are other issues surrounding that. I will start 
a thread asking for some example ABI series data.


>> If the "possible charge state" element
>> is used, there must be at least two proposed possible charge states or
>> else it makes no sense to qualify the charge state assessment with the
>> word "possible."
>>     
> I guess I'm overthinking this one.  The thing I was wondering about was whether it would be useful/necessary to be able to distinguish between "I think the charge of this spectrum is +1, but it might be something else" versus "I'm sure that the charge of this spectrum is +1".
>   
If a file writer wants to convey the semantics of "I think the charge of 
this spectrum is +1, but it might be something else," then I think they 
should include the "something else" in the list of possible/probable 
charge states. The only other reasonable alternative I can see is to 
always treat it like a list and give each charge a probability (which I 
expect is what Darren's group would like to see. :) )

-Matt

Re: [Psidev-ms-dev] conversion between to mzDATA standards

[Marc S. <st...@in...>]

Hi Pau,
> there is some tool (for linux) or guide to convert from one format 
> (UTF-8) to the other (ISO-8859-1)
There is no way to convert between different character encodings in 
OpenMS. I do not no any other tool either.

- Marc

Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

[Coleman, M. <MK...@St...>]

> From: psi...@li...
> [mailto:psi...@li...] On
> Behalf Of Matthew Chambers
> >
> >     "run1,2",3,4
> >
> Good catch about the double quote character,
> though. We should allow for it, but I don't know how to escape it!
> Perhaps we should URL encode the string components instead of using
> XML-escaped double quotes? So the last example would be:
> %22run1%2C2%22,3,4
>
> That looks awful, but otherwise the string "foo" (including the quotes
> as part of the string) would have to be encoded like
> """foo""" (the implicit rule being that a pair of
> " should be treated as a double-escaped quotation, i.e. it's part
> of the id string instead of delimiting the string itself.


A point of confusion here is that the quoting within "run1,2" is operating at a different level than the XML quoting.  Perhaps the simplest regime would be to simply specify '\"' for '"' and '\\' for '\'.  Ugly, but everyone would be familiar with it (from C, sh, etc), and I think it won't collide with XML escaping.

(The "" for " thing reminds me of VMS.  Does Windows do this, too?)


> If the "possible charge state" element
> is used, there must be at least two proposed possible charge states or
> else it makes no sense to qualify the charge state assessment with the
> word "possible."

I guess I'm overthinking this one.  The thing I was wondering about was whether it would be useful/necessary to be able to distinguish between "I think the charge of this spectrum is +1, but it might be something else" versus "I'm sure that the charge of this spectrum is +1".


--Mike

Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

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

Hi Michael,

Coleman, Michael wrote:
>>  nativeID="19"
>>  nativeID="2,6,5"
>>  nativeID="run1,3,4"
>>  nativeID=""run1,2",3,4"
>>     
> I don't understand what the meaning would be in these four cases.  The fourth would seem to be
>
>     "run1,2",3,4
>
> Is this just covering a corner case to show that the value of 'nativeID' is a comma-separated list of items, each of which can include commas if quoted?  (and if so, can an item also include a double-quote character?)
>   
Yes, it is covering that case, although I don't know if I would call it 
a corner case. I think strings inside native IDs are moderately likely 
(for example, for IDs from ABI's 4000 series instruments), and they 
might contain commas. Good catch about the double quote character, 
though. We should allow for it, but I don't know how to escape it! 
Perhaps we should URL encode the string components instead of using 
XML-escaped double quotes? So the last example would be:
%22run1%2C2%22,3,4

That looks awful, but otherwise the string "foo" (including the quotes 
as part of the string) would have to be encoded like 
"""foo""" (the implicit rule being that a pair of 
" should be treated as a double-escaped quotation, i.e. it's part 
of the id string instead of delimiting the string itself.


>>  - 0-1 "charge state"
>>  XOR
>>  - 2-N "possible charge state"
>>     
>
> By specifying "2-N", it seems like you're implicitly saying that by declaring that +2 or +3 is "possible" that all other charges are not possible.
>
> The alternative would be to specify "1-N", in which case +1 could mean "I think the charge is +1, but it might be something else".  Unless this interpretation is ruled out, it seems like "1-N" ought to be specified.
>   
I'm not sure if you're confused about the meaning of 2-N in this case or 
if I'm confused about your meaning. The 2-N means the number of elements 
of that type that there can be. If the "possible charge state" element 
is used, there must be at least two proposed possible charge states or 
else it makes no sense to qualify the charge state assessment with the 
word "possible." In any case, if "possible charge state" was 1-N, it 
would be confusing for implementors as to which one to use when they are 
trying to figure out what to write. However, perhaps we should rename 
the term "probable charge state" since technically any charge state is 
possible? :)


>>  Index should be *complete* so it could be used for a list of items to seek to
>>     
>
> Might also specify that it's one-to-one: that is, every index entry must actually point to one spectrum (that is actually present in the file).  Is it specified that the order of the index entries is the same as the order of the spectra in the file?
>   
I think both these things are already specified. If not, I agree that 
they should be.

-Matt

Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

[Coleman, M. <MK...@St...>]

>  nativeID="19"
>  nativeID="2,6,5"
>  nativeID="run1,3,4"
>  nativeID=""run1,2",3,4"

I don't understand what the meaning would be in these four cases.  The fourth would seem to be

    "run1,2",3,4

Is this just covering a corner case to show that the value of 'nativeID' is a comma-separated list of items, each of which can include commas if quoted?  (and if so, can an item also include a double-quote character?)


>  - 0-1 "charge state"
>  XOR
>  - 2-N "possible charge state"

By specifying "2-N", it seems like you're implicitly saying that by declaring that +2 or +3 is "possible" that all other charges are not possible.

The alternative would be to specify "1-N", in which case +1 could mean "I think the charge is +1, but it might be something else".  Unless this interpretation is ruled out, it seems like "1-N" ought to be specified.


>  Index should be *complete* so it could be used for a list of items to seek to

Might also specify that it's one-to-one: that is, every index entry must actually point to one spectrum (that is actually present in the file).  Is it specified that the order of the index entries is the same as the order of the spectra in the file?

Mike

Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

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

Not just 'number' since in <acquisition>?

Fredrik
>
>  
>
> - agreed change acqNumber to acquisitionNumber
>
>  
>

[Psidev-ms-dev] conversion between to mzDATA standards

[Pau M. M. T. <pa...@gm...>]

Hi

 I'm working in a bioinformatics group building up a server for a ms/ms
experiments,  until now or data that we receive is in the format


<?xml version="1.0" encoding="UTF-8"?>
<mzData version="1.05" accessionNumber="psi-ms:12345"  xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">

and I we need to convert into

<?xml version="1.0" encoding="ISO-8859-1"?>
<mzData version="1.05" accessionNumber="" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="
http://psidev.sourceforge.net/ms/xml/mzdata/mzdata.xsd">

there is some tool (for linux) or guide to convert from one format (UTF-8)
to the other (ISO-8859-1)

thanks

pau






-- 
Pau Marc Muñoz Torres

Laboratori de Biologia Computacional
Institut de  Biotecnologia   i Biomedicina Vicent
Villar
Universitat Autonoma de Barcelona
E-08193 Bellaterra (Barcelona)

telèfon: 93 5812807
Email : pau...@bi...

Re: [Psidev-ms-dev] PSI-MSSWG call in 8 hr

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

Hi everyone, here are my notes from the telecon. Thank you for your
participation. Please let me know if I forgot/misunderstood anything:

 

Meeting minutes 2008-03-04 9:00am PST

 

Present: Darren, Jim, Matt, Lennart, Josh, Eric

 

- Eric's most recent nativeID proposal is accepted except for the format
of the value, which should be:

  nativeID="19"

  nativeID="2,6,5"

  nativeID="run1,3,4"

  nativeID=""run1,2",3,4"

 

- possible charge state suggestion is fine with folks:

  - 0-1 "charge state"

  XOR

  - 2-N "possible charge state"

 

- Come up with an example of how we want summed spectra to look:

- one file that includes original scan and a summed spectrum

 

- in old mzXML, we can have different start_scan and end_scan. How do we
encode that?

 

- defaultArrayLength proposal is fine

 

- Jim has some examples of files with PDA data

  He will come up some examples of this

  Perhaps encoded as the MS spectrum as usual <spectrum index="27"
nativeID="19"> and then another

  <spectrum index="28" nativeID="PDA19"> with a spectrum type "PDA
spectrum"

 

- Jim will also come up MALDI data examples for us

 

- agreed that we rename selectionWindow to scanWindow as this is a
misnomer

- add optionally to <ionSelection>, all 2 new cvParams "selection window
m/z lower limit"

  and "selection window m/z upper limit" for the *true* fragmentation
selection window start and stop

 

- agreed change acqNumber to acquisitionNumber

 

- What to do with msLevel?

  agreed make it a cvParam next to spectrum type instead of a attribute
of <spectrum>

  because for example a PDA spectrum will have no msLevel

 

- state that index should be for seeking rather than cataloguing.

  So no msLevel in the index

  Index should be *complete* so it could be used for a list of items to
seek to

  but should contain only identifiers, not attributes/metadata

  - Start a thread on this to discuss more

 

- Matt will send <chromatogram> example since he is working on these now

 

- Next meeting indeed March 25 as on schedule.  This is *3* weeks from
now, because of US HUPO

- Maybe a few of us could meet and chat at US HUPO although unlikely
anything official.

 

 

 

 

 

________________________________

From: Eric Deutsch 
Sent: Tuesday, March 04, 2008 1:08 AM
To: 'Mass spectrometry standard development'
Cc: Eric Deutsch
Subject: PSI-MSSWG call in 8 hr

 

Hi everyone, here is a reminder of the call coming up in 8 hr. Dial-in
information is:

 

+ Germany: 08001012079

+ Switzerland: 0800000860

+ UK: 08081095644

+ USA: 1-866-314-3683

+ Generic international: +44 2083222500 (UK number)

access code: 297427

 

The agenda will be to discuss all the items that have come up recently.
I list them as:

 

- Latest nativeScanReference proposal

- using defaultArrayLength attribute in <spectrum> but allow override in
binaryDataArray

- Allow new "possible charge state" term in <ionSelection> multiple
times

- Frederick suggestion that selectionWindow should really be scanWindow.
selectionWindow is something different, and by the way, where is it, we
really need that, too.

- MS^E example

- msLevel

- chromatograms

 

The schedule is still:

 

Schedule:

-----------------------

Jan 25: mzML reviews returned. Official community review complete.

Feb  5: mzML telecon 9:00am PST

Feb 19: mzML telecon 9:00am PST

Mar  4: mzML telecon 9:00am PST

Mar 17: US HUPO meeting 

Mar 25: mzML telecon 9:00am PST

Apr  8: mzML telecon 9:00am PST

Apr 23: PSI meeting in Toledo

May

Jun 1-5: ASMS - Must be done and advertising it here!

 

 

 

 

 

Re: [Psidev-ms-dev] cvParam for mass analyzer in <scan>

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

That's a good point, Rune.

Using a virtual instrument for each possible combination of variables
won't scale well -- you would have to create an <instrument> and a
unique <instrument> 'id' for each combination of components that can
vary on your instrument.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Rune
Schjellerup Philosof
Sent: Tuesday, March 04, 2008 2:03 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] cvParam for mass analyzer in <scan>

This isn't only relevant for the analyzers.
Each of the components an instrument have more than one of, should be 
referred to from each scan.
For instance, I normally have a lockspray source for calibration.

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

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

Re: [Psidev-ms-dev] Unique scan numbers

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

>Are we converging on this?

That looks good to me.

Darren

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

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

Re: [Psidev-ms-dev] Unique scan numbers

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

Hi everyone, I then revise my previous pseudo XML to:

  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099580" name="Masswolf format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="C2F4S6" nativeID="C2F4S6">
  </spectrum>

  <offset index="18" id="S19" nativeID="C2F4S6">1234</offset>

For Thermo, we would have:

  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099581" name="Thermo format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="S19" nativeID="19">
  </spectrum>

  <offset index="18" id="S19" nativeID="19">1234</offset>

Are we converging on this?


-----------

Thread summary:

- Rune asks what would happen for combined spectra?
- Fredrik says that in that case, there would be not <scan> element
anyway, just an acquisitionList
- and Rune adds that then nativeScanReference would be left out of the
index
- Or Fredrik offers that you could keep nativeScanReference pointing to
the first scan
- Fredrik asks how it would be to force a naming convention for spectrum
ids?
  e.g. S1F1C1 would mean scan1, function 1, cycle 1, while S1 just means
scan 1
- Darren suggests that nativeID would be an attribute of <spectrum> not
scan
  This nativeID can refer to a scan number or to acquisition numbers
- Darren also strongly favors a zero-based index instead of a 1-based
index
- Matt suggests a metaspectrum
- Fredrik  counters that metaspectrum is not needed. Just:
  <acquisition number="1" externalSpectrumRef="S1F1"
sourceFileRef="SF1"/>
  where SF1 is a MassLynx raw data folder.
  If SF1 is an mzML file and the same convention was used for the
spectrum 
  id as for the externalSpectrumRef, we could easily retrieve the native
scan.
- Eric revises:
  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099580" name="Masswolf format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="C2F4S6" nativeID="C2F4S6">
  </spectrum>

  <offset index="18" id="S19" nativeID="C2F4S6">1234</offset>

For Thermo, we would have:

  <nativeScanRefFormat>
    <cvParam cvLabel="MS" accession="MS:1099581" name="Thermo format
nativeScanReference"/>
  </nativeScanRefFormat>

  <spectrum index="18" id="S19" nativeID="19">
  </spectrum>

  <offset index="18" id="S19" nativeID="19">1234</offset>


> -----Original Message-----
> From: psi...@li...
[mailto:psidev-ms-dev-
> bo...@li...] On Behalf Of Fredrik Levander
> Sent: Tuesday, March 04, 2008 7:12 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] Unique scan numbers
> 
> As I get it nativeID is the about the same as what we currently have
in
> acquistion number + spectrumRef + sourceFileId
> (or number + externalSpectrumID + sourceFileId), if the source file is
a
> vendor raw data file. If the source file is a mzML file, the
> externalSpectrumRef would equal the spectrum id in that file. If the
> spectrum id could be parsed to get native scan id everything is there
to
> get the native scan.
> 
> <acquisition number="1" externalSpectrumRef="S1F1"
sourceFileRef="SF1"/>
> 
> where SF1 is a MassLynx raw data folder.
> 
> If SF1 is an mzML file and the same convention was used for the
spectrum
> id as for the externalSpectrumRef, we could easily retrieve the native
> scan.
> 
> The question is what to put into spectrum id if the spectrum (or
> probably peak list) is a combination of spectra. It could be the first
> external spectrum id in the acquisitionList plus maybe a letter to
> indicate combination.
> I see no need to further complicate things by introducing a
> <metaspectrum> or similar though, the current <spectrum> works fine
for
> both single scans or combined spectra.
> 
> Fredrik
> 
> Matt Chambers wrote:
> > That's an interesting edge case for the nativeID. I am inclined to
> > suggest that the nativeID be put in the acquisition, or that
spectral
> > combination be rethought entirely. Since a combined spectrum is
> > essentially a "meta-spectrum" and not a real spectrum (at least I
would
> > think about it that way), we could use a separate element entirely
to
> > encode combinations. The combinations themselves would not have any
of
> > the normal attributes or cvParams of a <spectrum>, just a list of
> > references to the actual <spectrum> elements elsewhere in the file.
This
> > would be a better way in terms of avoiding (meta)data loss.  It
would be
> > reasonable to allow the <metaspectrum> or <combined_spectrum> to
have
> > binaryDataArrays containing the combined data, though, since that
would
> > take the most time to regenerate. But if the spectra are combined
before
> > putting them in the file, you lose the data from the individual
> > acquisitions.
> >
> > -Matt
> >
> >
> > Rune Schjellerup Philosof wrote:
> >
> >> Eric Deutsch wrote:
> >>
> >>
> >>> So it seems like the final suggestion is something like:
> >>>   <spectrum index="18" id="S2,4,6" >
> >>>     <scan nativeScanReference="2,4,6">
> >>>     </scan>
> >>>   </spectrum>
> >>>
> >>>
> >>>
> >> that would be
> >> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
> >>
> >> This would work for cases when each spectrum refers to a single
native
> scan.
> >> But aren't there support for having a spectrum that is for instance
a
> >> combination of several native scans?
> >>
> >> [Term]
> >> id: MS:1000570
> >> name: spectra combination
> >> def: "Method used to combine the mass spectra." [PSI:MS]
> >> relationship: part_of MS:1000442 ! spectrum
> >>
> >>
> >> What to do in this case?
> >>
> >>
> >> --
> >> Rune
> >>
> >
> >
> >
------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Psidev-ms-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> 
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] Unique scan numbers

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

As I get it nativeID is the about the same as what we currently have in 
acquistion number + spectrumRef + sourceFileId
(or number + externalSpectrumID + sourceFileId), if the source file is a 
vendor raw data file. If the source file is a mzML file, the 
externalSpectrumRef would equal the spectrum id in that file. If the 
spectrum id could be parsed to get native scan id everything is there to 
get the native scan.

<acquisition number="1" externalSpectrumRef="S1F1" sourceFileRef="SF1"/>

where SF1 is a MassLynx raw data folder.

If SF1 is an mzML file and the same convention was used for the spectrum 
id as for the externalSpectrumRef, we could easily retrieve the native scan.

The question is what to put into spectrum id if the spectrum (or 
probably peak list) is a combination of spectra. It could be the first 
external spectrum id in the acquisitionList plus maybe a letter to 
indicate combination.
I see no need to further complicate things by introducing a 
<metaspectrum> or similar though, the current <spectrum> works fine for 
both single scans or combined spectra.

Fredrik

Matt Chambers wrote:
> That's an interesting edge case for the nativeID. I am inclined to 
> suggest that the nativeID be put in the acquisition, or that spectral 
> combination be rethought entirely. Since a combined spectrum is 
> essentially a "meta-spectrum" and not a real spectrum (at least I would 
> think about it that way), we could use a separate element entirely to 
> encode combinations. The combinations themselves would not have any of 
> the normal attributes or cvParams of a <spectrum>, just a list of 
> references to the actual <spectrum> elements elsewhere in the file. This 
> would be a better way in terms of avoiding (meta)data loss.  It would be 
> reasonable to allow the <metaspectrum> or <combined_spectrum> to have 
> binaryDataArrays containing the combined data, though, since that would 
> take the most time to regenerate. But if the spectra are combined before 
> putting them in the file, you lose the data from the individual 
> acquisitions.
>
> -Matt
>
>
> Rune Schjellerup Philosof wrote:
>   
>> Eric Deutsch wrote:
>>   
>>     
>>> So it seems like the final suggestion is something like:
>>>   <spectrum index="18" id="S2,4,6" >
>>>     <scan nativeScanReference="2,4,6">
>>>     </scan>
>>>   </spectrum>
>>>   
>>>     
>>>       
>> that would be
>> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
>>
>> This would work for cases when each spectrum refers to a single native scan.
>> But aren't there support for having a spectrum that is for instance a 
>> combination of several native scans?
>>
>> [Term]
>> id: MS:1000570
>> name: spectra combination
>> def: "Method used to combine the mass spectra." [PSI:MS]
>> relationship: part_of MS:1000442 ! spectrum
>>
>>
>> What to do in this case?
>>
>>
>> --
>> Rune
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Unique scan numbers

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

That's an interesting edge case for the nativeID. I am inclined to 
suggest that the nativeID be put in the acquisition, or that spectral 
combination be rethought entirely. Since a combined spectrum is 
essentially a "meta-spectrum" and not a real spectrum (at least I would 
think about it that way), we could use a separate element entirely to 
encode combinations. The combinations themselves would not have any of 
the normal attributes or cvParams of a <spectrum>, just a list of 
references to the actual <spectrum> elements elsewhere in the file. This 
would be a better way in terms of avoiding (meta)data loss.  It would be 
reasonable to allow the <metaspectrum> or <combined_spectrum> to have 
binaryDataArrays containing the combined data, though, since that would 
take the most time to regenerate. But if the spectra are combined before 
putting them in the file, you lose the data from the individual 
acquisitions.

-Matt


Rune Schjellerup Philosof wrote:
> Eric Deutsch wrote:
>   
>> So it seems like the final suggestion is something like:
>>   <spectrum index="18" id="S2,4,6" >
>>     <scan nativeScanReference="2,4,6">
>>     </scan>
>>   </spectrum>
>>   
>>     
>
> that would be
> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
>
> This would work for cases when each spectrum refers to a single native scan.
> But aren't there support for having a spectrum that is for instance a 
> combination of several native scans?
>
> [Term]
> id: MS:1000570
> name: spectra combination
> def: "Method used to combine the mass spectra." [PSI:MS]
> relationship: part_of MS:1000442 ! spectrum
>
>
> What to do in this case?
>
>
> --
> Rune

Re: [Psidev-ms-dev] Unique scan numbers

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

Hi all,

I believe that we (Matt, Josh, and I) were thinking of 'nativeID' as an attribute of <spectrum>, not <scan>, since that is what the <offset> refers to:

<spectrum index=0 id="S19" nativeID="19">

<offset id="S19" nativeID="19">1234</offset>

This nativeID can refer to a scan number (which can even be a cvParam in <scan>), or to acquisition numbers, depending on where the data array is coming from.

I think Fredrik's idea of establishing a standard format with regex checking is a good one.

I also think it's a bad idea to have the <spectrum> 'index' attribute be anything other than a zero-based index, and not just because it would offend my sense of computational morality ;)  Having a 1-based index will definitely cause some bugs at some point in some software in the future, not to mention the grief it will cause the poor grad student who overlooks this fact and is up into the night debugging some script...  I don't have any love for the traditional scan number, and 'nativeID' is enough backward compatibility for me.


Darren

Re: [Psidev-ms-dev] DTA to mzML conversion

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

I think this a reasonable solution. Only minor objection is that 'charge 
state' is to some degree  'possible charge state' in many cases, and it 
will be up to implementers to decide which term to use in the case where 
there is just one value to report. But this is maybe even a nice feature 
to be able to flag that the charge state determination was not certain. 
This 'possible charge state' term seems much better than stating that a 
peak has two charge states, which just feels wrong (if there is not two 
overlapping peaks).

Just wanted to comment on this since I cannot make the telecon tonight 
(or this morning).

Fredrik

Eric Deutsch wrote:
> Okay, I think it is quite reasonable to support this then.  So currently
> we have:
>
> <ionSelection>
>   <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
> value="445.34"/>
>   <cvParam cvLabel="MS" accession="MS:1000041" name="charge state"
> value="2"/>
> </ionSelection>
>
> Or 
>
> <ionSelection>
>   <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
> value="445.34"/>
> </ionSelection>
>
> How about we support this:
>
> <ionSelection>
>   <cvParam cvLabel="MS" accession="MS:1000040" name="m/z"
> value="445.34"/>
>   <cvParam cvLabel="MS" accession="MS:100xxxx" name="possible charge
> state" value="2"/>
>   <cvParam cvLabel="MS" accession="MS:100xxxx" name="possible charge
> state" value="3"/>
> </ionSelection>
>
> So this means adding a term for a possible charge state instead of a
> known charge state and then allowing multiple cvParams.
>
> I would say the validation rule is that only 0-1 "charge state" is
> allowed, or alternatively 0-N "multiple charge state" is allowed.
>
> Seem okay?
>
> Thanks,
> Eric
>
>   

Re: [Psidev-ms-dev] Unique scan numbers

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

I've just followed this thread briefly since I have no intention to 
generate these index files, so I should probably just keep quiet. 
Anyway, how would it be to enforce a naming convention for spectrum ids 
so that the native scans can be extracted in the case when there is just 
one scan as the source for the spectrum? I think this is what Matt 
proposes, and it seems fine to me. That way there is no need to change 
the main schema or idx. The spectrum id could be regex checked and 
that's all. For example: S1F1C1 would mean scan1, function 1, cycle 1, 
while S1 just means scan 1. One could add a regex check to the main 
schema for the spectrum id, for example "S[0-9]+(F[0-9])?" for scan and 
optional function. I am not a regex expert, but I am sure someone could 
come up with a regex which is at least rather future safe for native 
scan references, and which allows some local variants to encode other 
information in the spectrum ID. This could also be used for the 
acquisition external spectrum id ref.

Regards

Fredrik

Re: [Psidev-ms-dev] Unique scan numbers

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

Either that, or keep nativeScanReference pointing to the first 
acquisition in the acquisitionList. I just think that it would get 
unnecessarily complex to reference all native scans from the index in 
such a file, but that's just my opinion.

Fredrik

Rune Schjellerup Philosof wrote:
> And in the index you would of course have to leave out the
>
> nativeScanReference attribute
>
> --
> Rune
>
> Fredrik Levander wrote:
>   
>> Hi Rune,
>>
>> In this case you will not have a <scan> element, or at least not the 
>> nativeScanReference, but rather an acquisitionList with acquisitions. 
>> Each of the acquisitions will have a scan reference, which is either a 
>> reference to an mzML scan, or to a vendor raw data file scan, if I get 
>> it right.
>>
>> Regards
>>
>> Fredrik
>>
>> Rune Schjellerup Philosof wrote:
>>   
>>     
>>> Eric Deutsch wrote:
>>>   
>>>     
>>>       
>>>> So it seems like the final suggestion is something like:
>>>>   <spectrum index="18" id="S2,4,6" >
>>>>     <scan nativeScanReference="2,4,6">
>>>>     </scan>
>>>>   </spectrum>
>>>>   
>>>>     
>>>>       
>>>>         
>>> that would be
>>> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
>>>
>>> This would work for cases when each spectrum refers to a single native scan.
>>> But aren't there support for having a spectrum that is for instance a 
>>> combination of several native scans?
>>>
>>> [Term]
>>> id: MS:1000570
>>> name: spectra combination
>>> def: "Method used to combine the mass spectra." [PSI:MS]
>>> relationship: part_of MS:1000442 ! spectrum
>>>
>>>
>>> What to do in this case?
>>>
>>>
>>> --
>>> Rune
>>>     
>>>       
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>   

Re: [Psidev-ms-dev] Unique scan numbers

[Rune S. P. <ru...@ph...>]

And in the index you would of course have to leave out the

nativeScanReference attribute

--
Rune

Fredrik Levander wrote:
> Hi Rune,
>
> In this case you will not have a <scan> element, or at least not the 
> nativeScanReference, but rather an acquisitionList with acquisitions. 
> Each of the acquisitions will have a scan reference, which is either a 
> reference to an mzML scan, or to a vendor raw data file scan, if I get 
> it right.
>
> Regards
>
> Fredrik
>
> Rune Schjellerup Philosof wrote:
>   
>> Eric Deutsch wrote:
>>   
>>     
>>> So it seems like the final suggestion is something like:
>>>   <spectrum index="18" id="S2,4,6" >
>>>     <scan nativeScanReference="2,4,6">
>>>     </scan>
>>>   </spectrum>
>>>   
>>>     
>>>       
>> that would be
>> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
>>
>> This would work for cases when each spectrum refers to a single native scan.
>> But aren't there support for having a spectrum that is for instance a 
>> combination of several native scans?
>>
>> [Term]
>> id: MS:1000570
>> name: spectra combination
>> def: "Method used to combine the mass spectra." [PSI:MS]
>> relationship: part_of MS:1000442 ! spectrum
>>
>>
>> What to do in this case?
>>
>>
>> --
>> Rune
>>     

Re: [Psidev-ms-dev] Unique scan numbers

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

Hi Rune,

In this case you will not have a <scan> element, or at least not the 
nativeScanReference, but rather an acquisitionList with acquisitions. 
Each of the acquisitions will have a scan reference, which is either a 
reference to an mzML scan, or to a vendor raw data file scan, if I get 
it right.

Regards

Fredrik

Rune Schjellerup Philosof wrote:
> Eric Deutsch wrote:
>   
>> So it seems like the final suggestion is something like:
>>   <spectrum index="18" id="S2,4,6" >
>>     <scan nativeScanReference="2,4,6">
>>     </scan>
>>   </spectrum>
>>   
>>     
>
> that would be
> <spectrum><spectrumDescription><scan nativeScanReference="2,4,6">
>
> This would work for cases when each spectrum refers to a single native scan.
> But aren't there support for having a spectrum that is for instance a 
> combination of several native scans?
>
> [Term]
> id: MS:1000570
> name: spectra combination
> def: "Method used to combine the mass spectra." [PSI:MS]
> relationship: part_of MS:1000442 ! spectrum
>
>
> What to do in this case?
>
>
> --
> Rune
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>