Re: [Psidev-ms-dev] Notes from today's PEFF call

[Juan A. V. <ju...@eb...>]

Hi Eric,

Thanks for taking care of this. 

About the remaining issue related to modifications, for reading software (as usual I am biased in that direction) it would be definitely easier to deal with modifications encoded by CVparams (differentiate between the 2 options (PSI-MOD and/or UniMod) or not is secondary in my opinion, I can accommodate to Eric’s approach for differentiating between all of them) or "free text” (e.g. “phospho-") in a different way. For instance, for reading properly files with custom modifications, there must be extra custom file to know what the modifications really are.

The final decision here will be probably used as well for the proBAM format (for proteogenomics)  since it does not make sense to use different approaches for these text-based formats, so we are not only talking about this particular case (PEFF). 

But I understand that this is not the main priority for others. So, I don’t want to delay the discussion and if the majority thinks that it is better to go for the opposite approach, let’s do that instead of spending much more time discussing about it.

Cheers,

Juan



> On 20 Oct 2015, at 22:55, Eric Deutsch <ede...@sy...> wrote:
> 
> Hi everyone, due to vacations and HUPO and other things, PEFF progress ground to a halt over the last few months, but with renewed vigor from HUPO, let’s see if we can get this finished! So, where we left off: I sent around a Doodle poll and we voted on various implementation options:
> http://doodle.com/e37uwaa83mzgshtn <http://doodle.com/e37uwaa83mzgshtn>
>  
> There was a clear winner on most of the decisions and I have gone with these for the moment. This leaves only the decision on whether to combine or separate \ModResPsi, \ModResUnimod, and \ModRes. I thought that keeping them separate would quite simplify things for parsers, but I was in the minority. Combining them all got the most support, but just barely. Considering the small-number statistics, it is really more of a 3-way tie within the uncertainties.. a change of one vote could have changed things considerably. So it is difficult to find the clear winner. Perhaps Pierre-Alain, Juanan , and I will settle this via an arm-wrestling contest. Or if anyone else would like to add their thumb to the Doodle scale at this late time, go for it. Or perhaps the first person to actually create a full implementation takes the day.
>  
> Please find attached the latest PEFF specification. I have updated it based on the winning decisions. The 3 ModRes terms remain as they were, still separated for now. Let’s see if we can make a decision and create some sample files and validators/parsers/writers.
>  
> Thanks,
> Eric
>  
>  
>  
>  
> From: Eric Deutsch [mailto:ede...@sy... <mailto:ede...@sy...>] 
> Sent: Thursday, July 02, 2015 10:22 AM
> To: Mass spectrometry standard development; psi...@li... <mailto:psi...@li...>
> Cc: Eric Deutsch
> Subject: Notes from today's PEFF call
>  
> Hi everyone, here are my notes from today’s PEFF call:
>  
> Present: Juanan, Pierre-Alain, Karl, Eric, Lydie, Harald, Simon, 
>  
> Agenda:
> - Dilemma 1: \Variant or \VariantSimple
> + No strong feeling. Try a Doodle vote
>  
> - Dilemma 2: Modify \Variant* keys with a further category
> + Opposing views on whether this should be here. Keep it simple, or allow some added tags
> + Lydie says they would rather have two PEFF files, one for gold level data, one for silver level, for example
> + Suggest that maybe each item could have an optional tag, e.g. instead of (223|A), allow (223|A|dbSNP)
> + Something like this implicitly already exists: the ability to create another key that allows, e.g., a free-text label
> + i.e. someone can create (using existing infrastructure) \VariantSimpleTagged=(223|A|neXtProt_dbSNP)(225|T|Specimen1)…
> + Try a poll
>  
> - Dilemma 3:
> + Juanan advocates combining them
> + General agreement of combination
> + But then reconsidered later after discussing next 
>  
> - What about \ModRes? Okay as implemented? Combine with the previous as well?
> + Many opinions both ways and more
> + Also a suggestion of \ModRes for both PSI-MOD and Unimod and then \ModResCustom for other things
> + Would we save space by putting the names in the header?
> + Eric advocates that keeping them all separate as currently done makes it easier for readers. Explicit keys makes it easier for reader to know what to expect, rather than expending code trying to determine what kind of information is present
> + Easy consensus did not come. Try a vote and pick a way
> + For voting: yes, no, doesn’t matter
>  
> - Custom key definitions
> + Did not have time to discuss this
> + Request that Pierre-Alain (and anyone else) follow up on the email Eric sent, and insert it into the spec doc
> + And then hold a slot for discussion on this on the next call
>  
> Eugene's comments:
> 1) Bigger picture and longevity - will the current format stand the test
> of time - proteoforms come to mind and future advances in MS etc.
> + Full proteoforms seems easily supported with the current structure with separate entries. Variants would be the actual PTMs for a given proteoform.
> + May require a few additional terms, but the structure seems fine
> + If there are some specific use cases, this would be helpful
>  
> 2) Do we have anyone representing NCBI/Refseq - if not what can we do
> about it. What about Ensembl, Eupathdb etc. - these are all well utilised
> resources especially EupathDB for those folks working with pathogens and
> mass spec.
> + We should make an effort. If they don’t participate now, they will be targeted as reviewers ;-)
>  
> 3) Has anyone approached Juergen Cox or someone on his team to become
> involved considering Maxquant usage in the proteomics community?
> + Emanuele has shown him the specification
>  
> + Ended here.
> + Eric will send out a Doodle poll to try voting on some items
> + Eric will send a poll to pick a date for the next call
>  
>  
> - Review examples of PEFF files
> - Review PEFF-supporting software
> - Central location for all supporting documentation
>  
>  
>  
> <PEFF.1.0.draft16.docx>------------------------------------------------------------------------------
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li... <mailto:Psi...@li...>
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev <https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev>