psidev-pi-dev — General Development List for Proteomics Informatics

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[andrewrobertjones <not...@gi...>]

It would probably make sense to revisit what mzTab is trying to do overall. Is it now a flattened encoding of everything possible in mzIdentML or mzQuantML, or is it accepted that this is an intentionally lossy encoding that is useful for visualisation (and stats?)? 

Julian's suggestion of having a column (presumably not row) for group_ID is one way that this could work - going further down the road of mzTab being a full encoding of the information, but this would not work well for quantitative data - unless null values were placed throughout for every group members other than the group leader/representative protein. To me, one of the most useful cases for mzTab is being able to download or exchange quant data in this format, and load it straight into R. For this to work, all the extra info about group members is largely irrelevant.


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214712703

[Psidev-pi-dev] [HUPO-PSI/mzIdentML] Remove the value requirement for CV terms used to indicate data type for a list (#7)

[Harald B. <not...@gi...>]

At the meeting we agreed to remove the value requirement from the following MS:1001221 (fragmentation information) child terms:
   - MS:1001226 (product ion intensity)
   - MS:1002225 (average product ion intensity)
   - MS:1002226 (product ion intensity standard deviation)
   - MS:1000904 (product ion m/z delta)

The reason being that these terms are used as to describe the data type in mzid files as part of the FragmentationTable element and can thus have no value in this setup.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/7

[Psidev-pi-dev] [HUPO-PSI/mzIdentML] Validator: null pointer for missing version number in the cvList (#6)

[Harald B. <not...@gi...>]

I get the following null pointer when trying to run the validator on the PeptideShaker 1.2 example file:

```
Exception in thread "Thread-4" java.lang.NullPointerException
        at psidev.psi.pi.validator.objectrules.CvListObjectRule.check(CvListObjectRule.java:77)
        at psidev.psi.pi.validator.objectrules.CvListObjectRule.check(CvListObjectRule.java:21)
        at psidev.psi.pi.validator.MzIdentMLValidator.validate(MzIdentMLValidator.java:864)
        at psidev.psi.pi.validator.MzIdentMLValidator.checkElementObjectRule(MzIdentMLValidator.java:823)
        at psidev.psi.pi.validator.MzIdentMLValidator.applyObjectRules(MzIdentMLValidator.java:676)
        at psidev.psi.pi.validator.MzIdentMLValidator.doValidationWork(MzIdentMLValidator.java:447)
        at psidev.psi.pi.validator.MzIdentMLValidator.startValidation(MzIdentMLValidator.java:417)
        at psidev.psi.pi.validator.MzIdentMLValidatorGUI$4.construct(MzIdentMLValidatorGUI.java:675)
        at psidev.psi.pi.validator.swingworker.SwingWorker$2.run(SwingWorker.java:147)
        at java.lang.Thread.run(Unknown Source)
```

The problem seems to be that the validator requires a version number for the elements in the cvList, but as far as I can tell the version number is not mandatory here?

I think it can all be easily fixed by checking if the versions number is not null before using the version object?

@germa Can you take a look at this one?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/6

Re: [Psidev-pi-dev] [HUPO-PSI/mzIdentML] Multiple search engine encoding (#5)

[Julian U. <not...@gi...>]

I would vote for removing the intermediate lists as well.

We could introduce an optional field (probably in Inputs?), which links to the intermediate mzId files and facilitates keeping track of the way the final list was calculated. Thus, uploading the final mzId and the intermediates to PRIDE etc. would still show the whole workflow. At least, given you know the software that did it.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/5#issuecomment-214701345

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[Julian U. <not...@gi...>]

My obvious suggestion would be to get rid of the mandatory unicity for the "protein accession" column and support always protein groups. Meaning the introduction of another mandatory row with a unique  "group id". At the same time it could be possible to remove "protein accession" and leave only "Ambiguity members". Unless, the proteins in "Ambiguity members" are allowed to be some kind of "sub-proteins" having less evidence and not equal accessions only.

On the other hand: I always considered mzTab as a very simplified (though a bit standardised) format for reports which would be better - and more thouroughly - encoded in mzIdentML. Therefore, i thought mzTab would only give an overview, not the whole truth.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214699479

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[Yasset Perez-R. <not...@gi...>]

@andrewrobertjones this are two different things, if is 
> bad encoding if they wish to (same as in mzIdentML).
then is not mztab compliant

If is posible by the schema, the the reader software should read everything and figure out what type of experiment it is, sometime would be "guess". 


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214688794

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[andrewrobertjones <not...@gi...>]

@ypriverol I agree that restricting the format would be a good thing, although I can't envisage how this could be enforced, since anyone can make up a bad encoding if they wish to (same as in mzIdentML).
However, it is quite to write a clear guideline that the protein section is for protein groups only, and that only those entities with independent evidence (e.g. under rules of parsimony) should be reported on a new line. 

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214686489

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[Yasset Perez-R. <not...@gi...>]

@andrewrobertjones @mvaudel 

The current implementation of mzTab we RECOMMEND the the proteins group should be reported in this way:

Protein Accession    .... Ambiguity members 
Protein 1                   .... Protein 2, Protein 3. .

Protein Accession field MUST be unique and this is the only constrains we made in the format. Then a writer can just give us a file like:

 1 - Software writers also report Protein 2, Protein 3..because the file format allow that. Including all the
      nice information about those proteins scores, sequences, ranks, etc. Then the reader should figure 
      it out whats going on in the file, example: 
      Protein Accession    .... Ambiguity members  opt_global_cv_MS:1001301_protein_rank
      Protein 1                   .... Protein 2, Protein 3                              1
      Protein 2                   ....                NULL                                     2
      Protein 3                   ....                NULL                                     3

Then, readers and community in general needs to know what the writers was proposing and also open the field to represent the protein inference information. 

If we keep the current specification, we need to restrict this cases, because then would be imposible to handle the files, unless we add CVTerms to verbose all possible combinations.  

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214684066

Re: [Psidev-pi-dev] [HUPO-PSI/mzIdentML] Proteogenomics encoding (#4)

[andrewrobertjones <not...@gi...>]

Hi @ypriverol These are the start positions within exons. This peptide is mapped across a splice junction, so there is the start point within the first exon, then start position within exon 2. I have added the explanation of the encoding to the spec doc.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/4#issuecomment-214672102

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[andrewrobertjones <not...@gi...>]

Certainly for reporting quant data, it is essential that you keep one row per protein group in mzTab, otherwise it ruins downstream statistical processing. If same-set or subset proteins are reported on different lines, the quant data will be repeated, leading to incorrect downstream processing and results.

Even for ident data, I think it is better to keep one row per protein group. It is then completely obvious - how many proteins have been identified? Count the rows. This was a mistake we made in mzid 1.1 of not making the distinction between protein accessions and protein groups sufficiently clear. This is an opportunity to get it right for mzTab, so we shouldn't bend the encoding to fit in with one particular software's preferred way of exporting their data.

If you really want to report extra detail about group members, I would recommend keeping a single row (for ident and quant), but then adding a complicated cell at the end contain key-value pairs for all the extra data.




---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214670405

Re: [Psidev-pi-dev] [HUPO-PSI/mzIdentML] Multiple search engine encoding (#5)

[andrewrobertjones <not...@gi...>]

Hi @smdb21 The point of the change is to prevent the encoding you are describing - although I realise some people may not like it, hence it needs discussion. I am pushing the concept that a "valid" mzIdentML 1.2 file contains only "final" results. This means that if there are multiple SILists, the parser MUST process them with no exceptions. 

As further rationale  - in our pipelines (and presumably many others), we create 6-10 intermediate mzIdentML files from processing via various steps. We discard all the intermediate files before sending to PRIDE or another data consumer. The results from individual search engines prior to combining are an example of an intermediate file. A piece of reading software should (in my opinion) not have to do the work of figuring out the ranked PSMs for a given spectrum. If different SILists contain the same spectrum, then it places work on the reading software to make a judgement. 
Given that mzid 1.2 has already got pretty complicated to implement, I am arguing that this is a simplification worth having. 
Happy to revert the decision if there is general feeling that this is a crucial feature to support

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/5#issuecomment-214667096

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[Marc V. <not...@gi...>]

@ypriverol I would recommend having the protein group unique, not the representative/anchor/leading protein.

@julianu If you have one peptide shared between protein A and B, and another shared between B and C, you have two protein groups AB and BC. If B is most likely there, it will be the representative/anchor/leading protein of both groups. Accession list is definitely what you want to have as identifier but having representative/anchor/leading proteins are very helpful for the readability :)

Hope this helps!

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214657691

Re: [Psidev-pi-dev] [HUPO-PSI/mzTab] Protein group (#20)

[Yasset Perez-R. <not...@gi...>]

Ideas?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzTab/issues/20#issuecomment-214448011

[Psidev-pi-dev] mzid 1.2 developments

[Jones, A. <And...@li...>]

Hi all,

Various issues and items on mzid 1.2 are being discussed on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues. We haven't found a way to ping this email list with those discussions so please follow them there, and comment. If you need a login, Yasset can do it for you: yp...@eb...<mailto:yp...@eb...>. I would like to get all issues closed off soon.

There will be a call this coming Thurs, but the focus will be cross-linking. We will follow up on other issues next week (by email or finding a call slot)

Best wishes
Andy

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Alexander L. <le...@im...>]

Dear all,

I think it makes most sense to discuss any remaining issues during the 
conference call next week. Many items have already been addressed by 
Lutz and/or Andy, therefore I will refrain from adding more comments to 
the e-mail threads.

I will be able to join the conference call next Thursday.


Best regards,

Alexander




Robert Chalkley schrieb:
>
>> Could everyone interested reply with regards to having a call next 
>> Thursday (28^th April) at 4pm UK time, 5pm Europe, 8am California: 
>> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160428T1500. 
>> If not, please let me know other slots you’re available, or I can 
>> setup a doodle poll if needed. Particularly it would be useful if 
>> Robert, Lutz and Alexander can join at the same time.
>>
> I can make a conference call at that time.
>
> Robert
> -- 
> Robert Chalkley PhD
> Adjunct Associate Professor
> Genentech Hall, N474A
> Tel: 415 476 5189
> Fax: 415 502 1655
>
> NIGMS Mass Spectrometry Facility
> University of California San Francisco
> 600 16th Street,
> Genentech Hall, suite N472A
> San Francisco, CA 94143-2240
>
>
>

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Robert C. <cha...@cg...>]

> Could everyone interested reply with regards to having a call next 
> Thursday (28^th April) at 4pm UK time, 5pm Europe, 8am California: 
> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160428T1500. If 
> not, please let me know other slots you’re available, or I can setup a 
> doodle poll if needed. Particularly it would be useful if Robert, Lutz 
> and Alexander can join at the same time.
>
I can make a conference call at that time.

Robert

-- 
Robert Chalkley PhD
Adjunct Associate Professor
Genentech Hall, N474A
Tel: 415 476 5189
Fax: 415 502 1655

NIGMS Mass Spectrometry Facility
University of California San Francisco
600 16th Street,
Genentech Hall, suite N472A
San Francisco, CA 94143-2240

Re: [Psidev-pi-dev] short examples for different cross-linker peptide combinations

[Lutz F. <lfi...@st...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[Psidev-pi-dev] GitHub issue tracker

[Jones, A. <And...@li...>]

Hi all,

For the final push to get mzid 1.2 finished, I think we need to use an issue tracker. I see Yasset has posted my To Do list here: https://github.com/HUPO-PSI/mzIdentML/issues. I haven't used GitHub issue tracker before, but I assume it is similar to what we had before in Google Code, please correct me if there are any special quirks or features I should know about.

I will start adding structured issues, that we can tick off as they are solved. Please all use this, adding your own issues here or comments. If you need a login for the project, please contact Yasset yp...@eb...<mailto:yp...@eb...>

Thanks
Andy

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Jones, A. <And...@li...>]

Hi Lutz,

I presume these messages are in response to things in the minutes? Elien did a fantastic job taking minutes for us (many thanks again for this!), but they were circulated before I had a chance to make some edits and clarifications.

Your comments are generally sensible, so for now, I wouldn’t take that version of the minutes to be a final record of discussions. I will write up all the final outcomes in the spec doc.

Hopefully later today.

Could everyone interested reply with regards to having a call next Thursday (28th April) at 4pm UK time, 5pm Europe, 8am California: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160428T1500. If not, please let me know other slots you’re available, or I can setup a doodle poll if needed. Particularly it would be useful if Robert, Lutz and Alexander can join at the same time.

Best wishes
Andy

From: Lutz Fischer [mailto:lfi...@st...]
Sent: 20 April 2016 16:14
To: Elien Vandermarliere <Eli...@UG...>; Jones, Andy <jo...@li...>; tobias <to...@eb...>
Cc: eug...@tu...; le...@im...; Sule Yilmaz <Sul...@UG...>; Robert Chalkley <cha...@cg...>; Juan Antonio Vizcaino <ju...@eb...>; Yasset Perez-Riverol <yp...@eb...>; psi...@li...; Juri Rappsilber <jur...@ed...>
Subject: Re: Cross-linking discussions at PSI meeting

Hi

I have some quest to the summary document:
Homodimers:
    what do these have to do with loop links?
    Why no modification on one peptide - it should still have the zero mass receiver modification. Not every homodimer links exactly the same residue in both peptides...

Seems like residue pair information and protein pair information are to be stored.
- Is this optional?
- how are these to be stored?

Cross-links with DNA or RNA:
- stored as modification sounds rather insuficient to me. It works if you only look at short DNA or RNA stretches and you don't care about the identification and localisation of the DNS/RNA.
- what speaks against storing the DNA/RNA sequence as separate entity?
- the only thing I can see is the name of the xml-entities (e.g. peptide/peptideevidence).
- can we live with storing general sequence information in these?

Cross-linker into Unimod:
- we would need to store the different reaction specificities. That would possibly require a change to the unimod stores modifications
-Just looked at the unimod website maybe it can be handled with new classifications for specificity::
 - site1, site2, site3, ....
 - (will unimod support my pentameric example? - different mail)
 - is there a distinction between natural and induced cross-links (e.g. disulfide vs BS3)

Sorry for not being there and now possibly asking obvious/discarded questions...

Lutz


On 20/04/16 08:09, Elien Vandermarliere wrote:
Dear all

In attachment is the summary of the session on crosslinking.

Elien

Elien Vandermarliere, Dr
VIB Medical Biotechnology Center, Ugent
UGent faculteit Geneeskunde en Gezondheidswetenschappen
Albert Baertsoenkaai 3
B-9000 Gent
BELGIUM

Tel. +32 9 264 9359
Fax +32 9 264 9490
www.ugent.be<http://www.ugent.be>
www.vib.be<http://www.vib.be>

From: Jones, Andy [mailto:And...@li...]
Sent: dinsdag 19 april 2016 16:56
To: tobias
Cc: eug...@tu...<mailto:eug...@tu...>; le...@im...<mailto:le...@im...>; Sule Yilmaz; ju...@ed...<mailto:ju...@ed...>; Elien Vandermarliere; Lutz Fischer; Robert Chalkley; Juan Antonio Vizcaino; Yasset Perez-Riverol; psi...@li...<mailto:psi...@li...>
Subject: Cross-linking discussions at PSI meeting

Hi all,

This email is addressed to those who participated in the XL session at PSI today, plus Lutz and Robert (and plus Yasset for GitHub issues). Please forward this on to others who should be consulted. I have also copied to the PSI-PI list.

The major outcomes from today are as follows:

1. General agreement that we are nearly there with the mzid 1.2 encoding of XL info.
2. Plan for Lutz to maintain (via mzIdentML GitHub for example), a separate CV of crosslinker reagents, based off the attached sheet (converted to CSV format, with unique IDs per row e.g. XL:0001, XL:0002, more discussion needed to finalise format)
3. Some additions to mzid 1.2 to cover:
- cases of combined evidence from multiple input spectra (L v H isotopes; ETD+HCD; MS3 etc) to make an identification (not post-processing but intrinsic to the ID mechanism)
- Adding protein-level interaction evidence
- Re-using additions already proposed in mzid 1.2 for mod or XL localization ambiguity
4. No major interest at this stage to encode XL info in mztab, we may do this at our side following same model as mzid 1.2
5. Plan for wider project over medium to long term to write a cross-linking standards paper, including mzid 1.2 plus a minimum reporting guidelines doc (Juri / Alexander to progress this), with wider authorship
6. We will role these changes into mzid 1.2 specifications, and publish that paper separately (submitted in the short term). For those that contribute example files or major input of the specs, I will invite to join the author list of that paper.

I have started to write this up in the mzid 1.2 specification document (attached here and committed to our GitHub) - see pages 20-23), and an XML snippet for how the protein interaction part will look.

ACTION items:

- We discussed Lutz updating the xi export examples to include protein interaction scores, following our proposed spec
- Alexander and Eugen to update the examples exported from OpenMS and add to the mzid GitHub (please email Yasset - cc'd to get write access to the GitHub)
- Ideally, would be great if the Edinburgh visualisation software could read the mzid 1.2 files to see if all info is really covered
- Andy to continue cleaning and updating specification document

I would like to propose a conference call to progress this for 4pm UK/5pm Europe on Thurs 28th April - please reply to let me know if you can make it.

best wishes
Andy






--

Lutz Fischer

lfi...@st...<mailto:lfi...@st...>

+44 131 6517057

Re: [Psidev-pi-dev] short examples for different cross-linker peptide combinations

[Jones, A. <And...@li...>]

More answers in-line:

From: Lutz Fischer [mailto:lfi...@st...]
Sent: 20 April 2016 16:13
To: Elien Vandermarliere <Eli...@UG...>; Jones, Andy <jo...@li...>; tobias <to...@eb...>
Cc: eug...@tu...; le...@im...; Sule Yilmaz <Sul...@UG...>; Robert Chalkley <cha...@cg...>; Juan Antonio Vizcaino <ju...@eb...>; Yasset Perez-Riverol <yp...@eb...>; psi...@li...; Juri Rappsilber <jur...@ed...>
Subject: short examples for different cross-linker peptide combinations


Hi

I attached some example representations of different cross-linked peptide configuration - as image and xml examples. One thing that I realised we probably need to change the description and the possibly validator a bit. If we want to have anything else then "two peptides, one cross-linker" then the current wording in the draft is not really working (the blue box under 5.3.5) - it enforces two peptides and two spectrumidentificationitems. I think the only rule I would see is that for each donor-modification has to be at least one zero-mass receptor modification.

Okay – if the validator is enforcing only case 1, then this is not correct. Have you tried some of the other examples – do they fail validation? I certainly intended that cases 1-4 would be completely standardly supported.

I can see that case 5 is potentially representable but would break the one donor – one receiver rule (per pair of Modification elements), which works for cases 1-4. Is such an example realistic at the present time?

I don’t fully understand what you are showing in Case 6, and quite possibly this would break some other part of mzIdentML. Again, is this a realistic case we need to support now?
Best wishes
Andy



A loop link has only one peptide - other structures would need more peptide.

But otherwise I think we can represent basically anything I could think of right now.

I have 5 examples.
1) standard cross-link - two peptides, one cross-linker
2) loop link - one peptide, one cross-linker
then the more fancy examples start
3) two peptides two cross-linker
4) three peptides two cross-linker
5) a very fancy pentameric cross-linker
    - its just an example to show we can represent other things then dimeric cross-linker
6) 4 chains with 16 disulfid bounds
    - I thing three years ago at the PSI-meeting somebody had the question whether antibodies would be representable - so we can say yes

Some examples are a bit far fetched - but I think it is worthwhile having these as a reference. At some point people will look for other things then "2 peptides, one cross-linker". E.g. try to record an anti-body.

Any comments/corrections are welcome.

Lutz

On 20/04/16 08:09, Elien Vandermarliere wrote:
Dear all

In attachment is the summary of the session on crosslinking.

Elien

Elien Vandermarliere, Dr
VIB Medical Biotechnology Center, Ugent
UGent faculteit Geneeskunde en Gezondheidswetenschappen
Albert Baertsoenkaai 3
B-9000 Gent
BELGIUM

Tel. +32 9 264 9359
Fax +32 9 264 9490
www.ugent.be<http://www.ugent.be>
www.vib.be<http://www.vib.be>

From: Jones, Andy [mailto:And...@li...]
Sent: dinsdag 19 april 2016 16:56
To: tobias
Cc: eug...@tu...<mailto:eug...@tu...>; le...@im...<mailto:le...@im...>; Sule Yilmaz; ju...@ed...<mailto:ju...@ed...>; Elien Vandermarliere; Lutz Fischer; Robert Chalkley; Juan Antonio Vizcaino; Yasset Perez-Riverol; psi...@li...<mailto:psi...@li...>
Subject: Cross-linking discussions at PSI meeting

Hi all,

This email is addressed to those who participated in the XL session at PSI today, plus Lutz and Robert (and plus Yasset for GitHub issues). Please forward this on to others who should be consulted. I have also copied to the PSI-PI list.

The major outcomes from today are as follows:

1. General agreement that we are nearly there with the mzid 1.2 encoding of XL info.
2. Plan for Lutz to maintain (via mzIdentML GitHub for example), a separate CV of crosslinker reagents, based off the attached sheet (converted to CSV format, with unique IDs per row e.g. XL:0001, XL:0002, more discussion needed to finalise format)
3. Some additions to mzid 1.2 to cover:
- cases of combined evidence from multiple input spectra (L v H isotopes; ETD+HCD; MS3 etc) to make an identification (not post-processing but intrinsic to the ID mechanism)
- Adding protein-level interaction evidence
- Re-using additions already proposed in mzid 1.2 for mod or XL localization ambiguity
4. No major interest at this stage to encode XL info in mztab, we may do this at our side following same model as mzid 1.2
5. Plan for wider project over medium to long term to write a cross-linking standards paper, including mzid 1.2 plus a minimum reporting guidelines doc (Juri / Alexander to progress this), with wider authorship
6. We will role these changes into mzid 1.2 specifications, and publish that paper separately (submitted in the short term). For those that contribute example files or major input of the specs, I will invite to join the author list of that paper.

I have started to write this up in the mzid 1.2 specification document (attached here and committed to our GitHub) - see pages 20-23), and an XML snippet for how the protein interaction part will look.

ACTION items:

- We discussed Lutz updating the xi export examples to include protein interaction scores, following our proposed spec
- Alexander and Eugen to update the examples exported from OpenMS and add to the mzid GitHub (please email Yasset - cc'd to get write access to the GitHub)
- Ideally, would be great if the Edinburgh visualisation software could read the mzid 1.2 files to see if all info is really covered
- Andy to continue cleaning and updating specification document

I would like to propose a conference call to progress this for 4pm UK/5pm Europe on Thurs 28th April - please reply to let me know if you can make it.

best wishes
Andy






--

Lutz Fischer

lfi...@st...<mailto:lfi...@st...>

+44 131 6517057

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Jones, A. <And...@li...>]

Hi all,

Thanks for your comments, some responses in line:

From: Robert Chalkley [mailto:cha...@cg...]
Sent: 20 April 2016 18:13
To: Elien Vandermarliere <Eli...@UG...>; Jones, Andy <jo...@li...>; tobias <to...@eb...>
Cc: eug...@tu...; le...@im...; Sule Yilmaz <Sul...@UG...>; ju...@ed...; Lutz Fischer <lfi...@st...>; Juan Antonio Vizcaino <ju...@eb...>; Yasset Perez-Riverol <yp...@eb...>; psi...@li...
Subject: Re: Cross-linking discussions at PSI meeting

All,

Thank you Eilen for the notes on the session: it looks like you had a fairly productive discussion.  Sorry I could not be there: I had to teach yesterday.

Some comments:

ms-3 data: each spectrum is going to be identified as a linear peptide with a modification.  I believe Thermo are going to market the DSSO cross-linker, which produces two different potential modifications (the cross-linker can cleave in two different locations).  Hence, you would need to store which modification was found on which peptide, and then maintain the association between two MS3 spectra to infer the original cross-linked product.

I think the model we developed does most, if not all of this. One can build an identification from a set of spectra (rather than just one as before), and maintain links to the two peptides and modifications identified.

Scores:  I think it is very important to allow storing of scores for each peptide separately, because as I have published, when you work with complex mixtures the reliability of your overall result is basically determined by how reliable the less confident of the two peptide identifications is (one of the two peptides is normally identified with at least an order of magnitude higher confidence than the other).

Yes, this can certainly be done. At the moment, we don’t have this shown in an example file, but I will make sure to have a clear note to this effect in the specifications.


Post-processing:  I would assume this would just consist of another score: analogous to how people may use Peptide Prophet or Percolator to add another score on top of the original search engine result.

Yes this can be done to add new PSM-level or peptide-level scores (or XL-peptide pair scores in this case)

Dead-end/monolinks and Unimod: Several of these are already in there with the prefix ‘Xlink:…’.  I previously tried to have a discussion about whether dead-end modifications or true cross-links should use this prefix, but there was no agreement.  To some extent I think it boils down to whether Unimod should even try to capture true cross-link modifications.  If the answer is ‘no’, then we can use the Xlink: for the dead-end, and we just need to add a few more terms to Unimod.

We took the decision for now to build a new CV containing both the XL reagents/mods and dead-ends, so it is comprehensive. I agree that the dead-ends could be put into Unimod if they are happy for more additions. Longer term, I would like both types of terms in Unimod. Juri has taken an Action Item to discuss with John Cottrell.
More to follow in response to other emails.
Best wishes
Andy



Fragment ions:  There are plenty of regular b and y ions. Theoretically, half the fragments don’t contain the second peptide; in practice it is more than that because you mostly see the smaller fragments.  Also, software that identifies cross-links as linear peptides with mass modifications will report b and y ions containing the second peptide.

Cross-linking to DNA/RNA: I agree that this should be treated as regular peptide modifications analogous to glycosylation: no attempt is made to determine the sequence of the RNA/DNA, and in all these studies the RNA/DNA is digested down to only two or three residues, so there will be a manageable number of modification compositions that need to be listed.

DSS/BS3: PSI-MOD made the decision to make all modifications product-centered; e.g. oxidation (M) and oxidation (P); one is an oxidation reaction; the other is a differently synthesized amino acid (hydroxyproline).  The search engine software can mistake these two, so the ambiguity should be captured in the results.  I see no reason why someone couldn’t do a crosslinking experiment where they added both DSS and BS3 to try to get cross-linking of more types of proteins.  The results would not be able to distinguish which reagent formed each crosslink.  If one used reagent-centered names how would the results be reported?

Visualization of data: MS-Viewer could be used to display identification results, but we have no immediate plans to support mzIdentML 1.2 for cross-linking.  However, if a mzTab equivalent was produced we would work to quickly support it.

Lutz’s cross-link examples:  We have to remember mzIdentML is storing the results from a database search engine.  There is no software out there that tries to identify 4 and 5 (we have a hard enough time identifying 1!).  In the antibody example this is not going to be identified by MSMS analysis; this would be inferred purely by mass and knowing the protein sequence of the antibody you are studying.  It is unlikely that software would be able to identify 3 either, because if there are two cross-links then most peptide backbone cleavages will not produce a fragment.  We only should worry about 1 and 2.

Robert
On 4/20/2016 12:09 AM, Elien Vandermarliere wrote:
Dear all

In attachment is the summary of the session on crosslinking.

Elien

Elien Vandermarliere, Dr
VIB Medical Biotechnology Center, Ugent
UGent faculteit Geneeskunde en Gezondheidswetenschappen
Albert Baertsoenkaai 3
B-9000 Gent
BELGIUM

Tel. +32 9 264 9359
Fax +32 9 264 9490
www.ugent.be<http://www.ugent.be>
www.vib.be<http://www.vib.be>

From: Jones, Andy [mailto:And...@li...]
Sent: dinsdag 19 april 2016 16:56
To: tobias
Cc: eug...@tu...<mailto:eug...@tu...>; le...@im...<mailto:le...@im...>; Sule Yilmaz; ju...@ed...<mailto:ju...@ed...>; Elien Vandermarliere; Lutz Fischer; Robert Chalkley; Juan Antonio Vizcaino; Yasset Perez-Riverol; psi...@li...<mailto:psi...@li...>
Subject: Cross-linking discussions at PSI meeting

Hi all,

This email is addressed to those who participated in the XL session at PSI today, plus Lutz and Robert (and plus Yasset for GitHub issues). Please forward this on to others who should be consulted. I have also copied to the PSI-PI list.

The major outcomes from today are as follows:

1. General agreement that we are nearly there with the mzid 1.2 encoding of XL info.
2. Plan for Lutz to maintain (via mzIdentML GitHub for example), a separate CV of crosslinker reagents, based off the attached sheet (converted to CSV format, with unique IDs per row e.g. XL:0001, XL:0002, more discussion needed to finalise format)
3. Some additions to mzid 1.2 to cover:
- cases of combined evidence from multiple input spectra (L v H isotopes; ETD+HCD; MS3 etc) to make an identification (not post-processing but intrinsic to the ID mechanism)
- Adding protein-level interaction evidence
- Re-using additions already proposed in mzid 1.2 for mod or XL localization ambiguity
4. No major interest at this stage to encode XL info in mztab, we may do this at our side following same model as mzid 1.2
5. Plan for wider project over medium to long term to write a cross-linking standards paper, including mzid 1.2 plus a minimum reporting guidelines doc (Juri / Alexander to progress this), with wider authorship
6. We will role these changes into mzid 1.2 specifications, and publish that paper separately (submitted in the short term). For those that contribute example files or major input of the specs, I will invite to join the author list of that paper.

I have started to write this up in the mzid 1.2 specification document (attached here and committed to our GitHub) - see pages 20-23), and an XML snippet for how the protein interaction part will look.

ACTION items:

- We discussed Lutz updating the xi export examples to include protein interaction scores, following our proposed spec
- Alexander and Eugen to update the examples exported from OpenMS and add to the mzid GitHub (please email Yasset - cc'd to get write access to the GitHub)
- Ideally, would be great if the Edinburgh visualisation software could read the mzid 1.2 files to see if all info is really covered
- Andy to continue cleaning and updating specification document

I would like to propose a conference call to progress this for 4pm UK/5pm Europe on Thurs 28th April - please reply to let me know if you can make it.

best wishes
Andy





--

Robert Chalkley PhD

Adjunct Associate Professor

Genentech Hall, N474A

Tel: 415 476 5189

Fax: 415 502 1655



NIGMS Mass Spectrometry Facility

University of California San Francisco

600 16th Street,

Genentech Hall, suite N472A

San Francisco, CA 94143-2240

[Psidev-pi-dev] mailing list

[Nick Vincent-M. <nic...@pr...>]

Greetings,

We received an email from this list, but it came to our catch all (wild 
card) email address: *@proteomesoftware.com. This means that whoever 
signed up to be on this list is no longer with us, and the email address 
used is invalid.

Can you assist me in removing our domain from this list? We aren't 
interested in receiving these emails. If someone with a valid email 
address from our organization wants to sign up, they can at their own 
convenience.

Best,

-- 
Nick Vincent-Maloney
IT Operations Manager

800-944-6027
www.proteomesoftware.com

1340 SW Bertha Blvd, Suite 10
Portland, Oregon 97129

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Lutz F. <lfi...@st...>]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [Psidev-pi-dev] Cross-linking discussions at PSI meeting

[Robert C. <cha...@cg...>]

All,

Thank you Eilen for the notes on the session: it looks like you had a 
fairly productive discussion.  Sorry I could not be there: I had to 
teach yesterday.

Some comments:

ms-3 data: each spectrum is going to be identified as a linear peptide 
with a modification.  I believe Thermo are going to market the DSSO 
cross-linker, which produces two different potential modifications (the 
cross-linker can cleave in two different locations).  Hence, you would 
need to store which modification was found on which peptide, and then 
maintain the association between two MS3 spectra to infer the original 
cross-linked product.

Scores:  I think it is very important to allow storing of scores for 
each peptide separately, because as I have published, when you work with 
complex mixtures the reliability of your overall result is basically 
determined by how reliable the less confident of the two peptide 
identifications is (one of the two peptides is normally identified with 
at least an order of magnitude higher confidence than the other).

Post-processing:  I would assume this would just consist of another 
score: analogous to how people may use Peptide Prophet or Percolator to 
add another score on top of the original search engine result.

Dead-end/monolinks and Unimod: Several of these are already in there 
with the prefix ‘Xlink:…’.  I previously tried to have a discussion 
about whether dead-end modifications or true cross-links should use this 
prefix, but there was no agreement.  To some extent I think it boils 
down to whether Unimod should even try to capture true cross-link 
modifications.  If the answer is ‘no’, then we can use the Xlink: for 
the dead-end, and we just need to add a few more terms to Unimod.

Fragment ions:  There are plenty of regular b and y ions. Theoretically, 
half the fragments don’t contain the second peptide; in practice it is 
more than that because you mostly see the smaller fragments.  Also, 
software that identifies cross-links as linear peptides with mass 
modifications will report b and y ions containing the second peptide.

Cross-linking to DNA/RNA: I agree that this should be treated as regular 
peptide modifications analogous to glycosylation: no attempt is made to 
determine the sequence of the RNA/DNA, and in all these studies the 
RNA/DNA is digested down to only two or three residues, so there will be 
a manageable number of modification compositions that need to be listed.

DSS/BS3: PSI-MOD made the decision to make all modifications 
product-centered; e.g. oxidation (M) and oxidation (P); one is an 
oxidation reaction; the other is a differently synthesized amino acid 
(hydroxyproline).  The search engine software can mistake these two, so 
the ambiguity should be captured in the results.  I see no reason why 
someone couldn’t do a crosslinking experiment where they added both DSS 
and BS3 to try to get cross-linking of more types of proteins.  The 
results would not be able to distinguish which reagent formed each 
crosslink.  If one used reagent-centered names how would the results be 
reported?

Visualization of data: MS-Viewer could be used to display identification 
results, but we have no immediate plans to support mzIdentML 1.2 for 
cross-linking.  However, if a mzTab equivalent was produced we would 
work to quickly support it.

Lutz’s cross-link examples:  We have to remember mzIdentML is storing 
the results from a database search engine.  There is no software out 
there that tries to identify 4 and 5 (we have a hard enough time 
identifying 1!).  In the antibody example this is not going to be 
identified by MSMS analysis; this would be inferred purely by mass and 
knowing the protein sequence of the antibody you are studying.  It is 
unlikely that software would be able to identify 3 either, because if 
there are two cross-links then most peptide backbone cleavages will not 
produce a fragment.  We only should worry about 1 and 2.

Robert

On 4/20/2016 12:09 AM, Elien Vandermarliere wrote:
>
> Dear all
>
> In attachment is the summary of the session on crosslinking.
>
> Elien
>
> Elien Vandermarliere, Dr
>
> /VIB Medical Biotechnology Center, Ugent/
>
> /UGent faculteit Geneeskunde en Gezondheidswetenschappen/
>
> /Albert Baertsoenkaai 3/
>
> /B-9000 Gent/
>
> /BELGIUM/
>
> //
>
> /Tel. +32 9 264 9359/
>
> /Fax +32 9 264 9490/
>
> /www.ugent.be/
>
> /www.vib.be/
>
> *From:*Jones, Andy [mailto:And...@li...]
> *Sent:* dinsdag 19 april 2016 16:56
> *To:* tobias
> *Cc:* eug...@tu...; le...@im...; Sule 
> Yilmaz; ju...@ed...; Elien Vandermarliere; Lutz Fischer; Robert 
> Chalkley; Juan Antonio Vizcaino; Yasset Perez-Riverol; 
> psi...@li...
> *Subject:* Cross-linking discussions at PSI meeting
>
> Hi all,
>
> This email is addressed to those who participated in the XL session at 
> PSI today, plus Lutz and Robert (and plus Yasset for GitHub issues). 
> Please forward this on to others who should be consulted. I have also 
> copied to the PSI-PI list.
>
> The major outcomes from today are as follows:
>
> 1. General agreement that we are nearly there with the mzid 1.2 
> encoding of XL info.
> 2. Plan for Lutz to maintain (via mzIdentML GitHub for example), a 
> separate CV of crosslinker reagents, based off the attached sheet 
> (converted to CSV format, with unique IDs per row e.g. XL:0001, 
> XL:0002, more discussion needed to finalise format)
> 3. Some additions to mzid 1.2 to cover:
> - cases of combined evidence from multiple input spectra (L v H 
> isotopes; ETD+HCD; MS3 etc) to make an identification (not 
> post-processing but intrinsic to the ID mechanism)
> - Adding protein-level interaction evidence
> - Re-using additions already proposed in mzid 1.2 for mod or XL 
> localization ambiguity
> 4. No major interest at this stage to encode XL info in mztab, we may 
> do this at our side following same model as mzid 1.2
> 5. Plan for wider project over medium to long term to write a 
> cross-linking standards paper, including mzid 1.2 plus a minimum 
> reporting guidelines doc (Juri / Alexander to progress this), with 
> wider authorship
> 6. We will role these changes into mzid 1.2 specifications, and 
> publish that paper separately (submitted in the short term). For those 
> that contribute example files or major input of the specs, I will 
> invite to join the author list of that paper.
>
> I have started to write this up in the mzid 1.2 specification document 
> (attached here and committed to our GitHub) - see pages 20-23), and an 
> XML snippet for how the protein interaction part will look.
>
> ACTION items:
>
> - We discussed Lutz updating the xi export examples to include protein 
> interaction scores, following our proposed spec
> - Alexander and Eugen to update the examples exported from OpenMS and 
> add to the mzid GitHub (please email Yasset - cc'd to get write access 
> to the GitHub)
> - Ideally, would be great if the Edinburgh visualisation software 
> could read the mzid 1.2 files to see if all info is really covered
> - Andy to continue cleaning and updating specification document
>
> I would like to propose a conference call to progress this for *4pm 
> UK/5pm Europe on Thurs 28th April* - please reply to let me know if 
> you can make it.
>
> best wishes
> Andy
>

-- 
Robert Chalkley PhD
Adjunct Associate Professor
Genentech Hall, N474A
Tel: 415 476 5189
Fax: 415 502 1655

NIGMS Mass Spectrometry Facility
University of California San Francisco
600 16th Street,
Genentech Hall, suite N472A
San Francisco, CA 94143-2240

Re: [Psidev-pi-dev] mzid 1.2 to do list

[Harald B. <Har...@ui...>]

Hi all,

Some additional comments after checking the PeptideShaker mzid 1.2 
example file with the current validator:

1) At the meeting we agreed to remove the value requirement from the 
following MS:1001221 (fragmentation information) child terms:
    - MS:1001226 (product ion intensity)
    - MS:1002225 (average product ion intensity)
    - MS:1002226 (product ion intensity standard deviation)
    - MS:1000904 (product ion m/z delta)

The reason being that these terms are used as to describe the data type 
in mzid files as part of the FragmentationTable element and can thus 
have no value in this setup.

2) MS:1002404 (count of identified proteins) is _not_ a child of 
MS:1001184 (search statistics)? Should it not be?

3) MS:1002567 (phosphoRS score threshold) and MS:1002557 (D-Score 
threshold) ought to be anticipated terms under Threshold under 
SpectrumIdentificationProtocol?

4) MS:1002497 (group PSMs by sequence with modifications) (and the other 
new related terms) ought to be anticipated terms under 
AdditionalSearchParams?

5) MS:1000894 (retention time) ought to be anticipated terms under 
SpectrumIdentificationResult?

6) MS:1002471, MS:1002470 and MS:1002542 ought to be anticipated terms 
under ProteinAmbiguityGroup?

7) What is the intended use of MS:1001239 (frag: immonium ion)? How can 
this be used to annotate immonium ions on specific amino acids?

Here's what we currently do using the outdated PRIDE CV terms:

<IonType charge="1" index="4 5">
    <FragmentArray measure_ref="Measure_MZ" values="120.0808411"/>
    <FragmentArray measure_ref="Measure_Int" values="14483.125"/>
    <FragmentArray measure_ref="Measure_Error" 
values="6.53397579810644E-5"/>
    <cvParam cvRef="PRIDE" accession="PRIDE:0000244" name="immonium F"/>
</IonType>

How would the same be done with MS:1001239 (frag: immonium ion)?

8) Why is the following not allowed?

"MS:1001969" name="phosphoRS score" 
value="1:1.0468246849444967E-8:4:false"

Is scientific annotation not supported?

Full error:
"The regular expression in SpectrumIdentificationItem (id='SII_4070_1') 
element at 
/MzIdentML/DataCollection/AnalysisData/SpectrumIdentificationList/SpectrumIdentificationResult/SpectrumIdentificationItem/cvParam 
('phosphoRS score') is not valid."

9) It seems to be mandatory to add MS:1002507 (modification 
rescoring:false localization rate) (or any of its child terms, of which 
there are none btw) when including MS:1002491 (modification localization 
scoring) in the AdditionalSearchParams list.

This means that terms such as MS:1001969 (phosphoRS score), MS:1002536 
(D-Score), MS:1002550 (peptide:phosphoRS score and MS:1002553 
(peptide:D-Score) (and others) cannot be used for the PTM rescoring.

I think that either these terms have to be children of MS:1002507 
(modification rescoring:false localization rate) or the mandatory term 
when using modification rescoring ought to be MS:1002505 (regular 
expression for modification localization scoring) or one of its 
children?

Best regards,
Harald





Den 2016-04-20 13:46, skrev Jones, Andy:
> Hi all,
> 
>  Various items from the sessions this morning in Gent:
> 
>  1. mzid 1.2 validator not easy to locate on GitHub - Gerhard, are you
> able to make this prominently available as a build under a "Downloads"
> webpage on Githut. Apparently, it is fairly easy to build end user
> web-pages on GitHub - Tobias has experience of this.
> 
>  2. There are various bugs in the validator - if you have identified
> one, please make sure to email it to Gerhard to fix
> 
>  3. Eric has taken an action item to do some CV tidying, particularly
> around scores for PSMs, PTM, peptides, proteins and protein groups
> 
>  4. We need ~11 new CV terms, as detailed in Table 2 of the spec doc
> (just pushed to GitHub) for combined spectra as input to searches
> 
>  5. Term MS:102499 peptide level score should be deprecated as this
> was never intended to go in the CV - Gerhard, can you do this please
> 
>  6. Terms starting "group PSMs by..." are under the wrong parent. They
> should be under a new parent term called "identification parameters",
> and a new link added to the mapping file for
> "AdditionalSearchParameters" allowing the child terms of this term to
> be used i.e. these terms are intended to be used in this part of the
> Protocol.
> 
>  7. These terms: de novo, proteogenomics spectral need an extra parent
> term: special processing (MS:1002489), so they trigger special
> behaviour of the validator.
> 
>  Please add to this list with things I missed,
>  best wishes
>  Andy
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications 
> Manager
> Applications Manager provides deep performance insights into multiple 
> tiers of
> your business applications. It resolves application problems quickly 
> and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> 
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev