Refine and finalize metadata and CV terms

[ypriverol]

The current msp and other spectral library formats only capture the metadata around each entry in the library (cluster, consensus spectra, peptides, small molecules), but not the way the spectral library has been generated. We need to define a general metadata section at the beginning this metadata. Similar to mztab, I think would be great to have something like:

The MTD version is helping the readers to know that this is a metadata field. The second column is the Key of the metadata attribute and the third is the value of the metadata field.

The following fields can be reused from mzTab:

MTD   mzL-version	1.0.0      
MTD   title  Spectral Library Human from Peptide Atlas 
MTD   id     PXL00000001 
MTD   description Some description that can be used for example in the web about the library
MTD   instrument [MS, MS:1000703, LTQ Orbitrap,]
MTD   instrument [MS, MS:1000008, Velos Orbitrap,]

Can we add to this issue all the fields we think are interesting or important to trace?

[ypriverol]

My list of attributes to define at the level of the library, I will add an * if I think is mandatory.

• title*: title to be used by Visualization components
• description*: to be used by visualization components and for search purpose
• id*: Unique identifier across resources of ProteomeXchange for example.
• instruments: A list of instruments included in the library. Here, we can be RECOMMENDED this as optional and only will be provided if the library is filtered by an instrument. I think peptide atlas release instrument-based library, but pride no.
• modifications: A list of modifications included in the library. Similar to the instrument list we RECOMMENDED to add the modifications only if the library is dedicated/filtered by modified peptides. You can have one or more peptides modifications.
• Fragmentation mode: Again a list of fragmentation modes if the library has been build for a specific type.
• contacts: Contact names for the person or resources that have developed the library.
• Comments: General comments about the library similar to mztab and other file formats.

[schymane]

I'm not sure this is the right place for this comment but note NIST have the MSP but also the SDF format that stores their spectral information (I do not see this mentioned here yet) - although MSP seems to be the more common exchange one, the SDF has the advantage that the full structure AND the spectrum can be in it ... and this paper is a great example of using SDF to do NMR exchange:
https://onlinelibrary.wiley.com/doi/abs/10.1002/mrc.4737

[rsalek]

Might be better to keep SDF - structure - separate as it should cover both proteomics and metabolomics or other maybe potentially other MS based applications

[schymane]

See parallel conversation for similar comments! MassBank/MassBank-web#110
I am missing background to the discussions here for sure; have plenty of thoughts for small molecule side but not much idea of how proteomics handles this.

[mwang87]

I'm not sure if this is addressed in the Massbank format or other formats, but one things we try to track on the GNPS side is the provenance filename and scan number of where the reference spectrum came from. Though, its not perfect in the record and maybe it is more appropriate to be tracked externally (which is done at GNPS) and those records are referenced through an accession number.

[ypriverol]

@mwang87 this issue is to capture what we are planning to trace for the complete spectral library not for the individual spectra. I have created another issue for the individual spectra an cluster #9

[henryhlam]

Let's make the largest list possible first (with each field marked as required/optional) and we can whittle it down. Maybe it is easier to edit a Google Doc together?

My quick thoughts below.

At library level, we need:

Format version (e.g. mzl 1.0)

A universal library identifier (similar to the universal spectrum identifier) e.g. mzlib:PXL0000100:NIST_cow_2018)

Publisher/source, including Contact (e.g. NIST)

Publishing date (or library version or serial number)

Library name/descriptor

Software generating the library and version

Organisms (do we need this? if yes, have to allow more multiple organisms, or none at all)

All Modifications (do we need this at the library level? probably only necessary to define special mods not already in PSI-MOD or UNIMOD, or to shorten the tags in each library entry by defining them here)

Instrumentation/Fragmentation (similar. We need this at spectrum level anyway, as many libraries contain mixture of spectra from different instruments. Do we need it here?)

Comments

Provenance
(From my experience, it is often necessary to modify/merge/filter libraries to create new custom ones. It would be nice to have a place to keep track of what has been done to the library. (e.g. This library is created from the NIST 2014 one by filtering for all tryptic peptides, and merged it with a decoy library...) This can be put into the Comments field, but it may be useful to have a separate "Provenance" field.)

For spectrum level, it is a lot more complicated. Maybe we should have a separate thread/doc for this.

[schymane]

Re: organisms - it should be designed flexibly to allow extra metadata, but not be too biologically focused, for instance. There are a lot of people who use spectral libraries who do not have any organism context. The MassBank requirement for a "natural / not natural" tag has caused many headaches for us environmental people because we never have the context (caffeine is eg a natural product but for us a chemical found in the environment) and such classifications are extremely hard to auto-classify from the wrong context... (ie please do not force people to provide information they may not have and force them instead to fill in "something" that is likely incorrect just to fill a field). On Sun, Apr 22, 2018 at 9:36 AM +0200, "henryhlam" <notifications@github.com<mailto:notifications@github.com>> wrote: Let's make the largest list possible first (with each field marked as required/optional) and we can whittle it down. Maybe it is easier to edit a Google Doc together? My quick thoughts below. At library level, we need: Format version (e.g. mzl 1.0) A universal library identifier (similar to the universal spectrum identifier) e.g. mzlib:PXL0000100:NIST_cow_2018) Publisher/source, including Contact (e.g. NIST) Publishing date (or library version or serial number) Library name/descriptor Software generating the library and version Organisms (do we need this? if yes, have to allow more multiple organisms, or none at all) All Modifications (do we need this at the library level? probably only necessary to define special mods not already in PSI-MOD or UNIMOD, or to shorten the tags in each library entry by defining them here) Instrumentation/Fragmentation (similar. We need this at spectrum level anyway, as many libraries contain mixture of spectra from different instruments. Do we need it here?) Comments Provenance (From my experience, it is often necessary to modify/merge/filter libraries to create new custom ones. It would be nice to have a place to keep track of what has been done to the library. (e.g. This library is created from the NIST 2014 one by filtering for all tryptic peptides, and merged it with a decoy library...) This can be put into the Comments field, but it may be useful to have a separate "Provenance" field.) For spectrum level, it is a lot more complicated. Maybe we should have a separate thread/doc for this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#7 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD4a_cyQU8frF-C_rK0_4eWDHcQGJ2C3ks5trDMEgaJpZM4TcduF>.

[ypriverol]

The google document is this one:
https://docs.google.com/document/d/1LgSGtR_t5IcUS9rV7YtsLveDVX9X8KsOpU-5NJ4vuYI/edit?usp=sharing

This issue is to discuss the metadata at the level of the library, we have another issue #9 to discuss the metadata to the individual spectra

[schymane]

My comment stands for both the individual spectrum and library level ... many spectral libraries will likewise not come from an organism ... although some may and in this case it would be valuable information to be captured. A more generic description may be more flexible?
I added some comments to the doc.

[ypriverol]

@schymane The idea of the organisms, instruments, and modifications at the library metadata is for dedicated libraries where for example you the library has been created/filtered for those properties. If is not the case, then those properties should be captured at the spectrum level because it can be huge the number of species, instruments and especially modifications in one library.