ProForma parser / convert annotation style

[guideflandre]

Hi @lgatto @sgibb ,

I have created a ProForma parser/annotation style converter between 3 different annotation styles: delta mass, unimod name and unimod id. All three styles can be retrieved from the modifications dataframe in the unimod package.

This converter can be found here under the name convertAnnotation.R.

By itself, I find the convert already very useful. But ideally, I would like to implement it into calculateFragments from the PSMatch package. This way, calculateFragments could have as input positional modifications with different annotation styles. If needed, more style parsers could be added but I believe these 3 are the most prominent ones. (the positional modifications refer to this PR in PSMatch).

This implementation however, would not be user-friendly as unimod is not part of Bioconductor and users would need to install it from github in order to use calculateFragments.

One solution would be to transfer the relevant code (modifications dataframe, convertAnnotation function) from the unimod package to PSMatch. I'm curious to know if you think this is a good approach or if you have other ideas in mind.

Either way, I can create a PR for this converter in unimod if that is of interest to you.

[lgatto]

This implementation however, would not be user-friendly as unimod is not part of Bioconductor and users would need to install it from github in order to use calculateFragments.

The issue is not user-friendliness. It is as simple to install a package from Github than it is from Bioconductor using BiocManager::install(). The problem is that Bioconductor packages can only depend on Bioconductor or CRAN packages.

@sgibb - should be consider submitting unimod to Bioconductor? Or merge it with PSMatch?

[lgatto]

Personally, I think prefer to keep the packages separate.

[lgatto]

@guideflandre - yes please, open an PR so we can merge this into unimod.

[lgatto]

One point is the use of camelCase and snake_case. We then to use the format, in line with Bioconductor, but here, you mix both: convertAnnotation()and convert_to, delta_mass, unimod_id. I would suggest to be consistent and keep camelCase.

[sgibb]

@guideflandre Thanks for this great input! I would prefer to add this functionality to the unimod package as well (and finally release it on Bioconductor).

[lgatto]

Hi @guideflandre - I'm looking at the convertAnnotation() function in your fork. Some questions:

• what are these aliases convertStyle and unimodStyle? I don't see them appearing anywhere else, so how could a user search for them?
• Could you add links to the unimod function/dataframe in ?convertAnnotation(), for context. Same in the warning messages, to help the user debugging when a name or unimod id isn't recognised.

> convertAnnotation("M[OXidation]PEPTIDE", convert_to = "delta_mass")
[1] "M[OXidation]PEPTIDE"
Warning message:
In .convertModificationFormat(mod_content = mod_content, input_type = input_type,  :
  Could not find Unimod entry for modification OXidation
> convertAnnotation("M[UNIMOD:abc]PEPTIDE", convert_to = "unimod_id")
[1] "M[UNIMOD:abc]PEPTIDE"
Warning message:
In .convertModificationFormat(mod_content = mod_content, input_type = input_type,  :
  Could not find Unimod entry for modification UNIMOD:abc

[lgatto]

@guideflandre Thanks for this great input! I would prefer to add this functionality to the unimod package as well (and finally release it on Bioconductor).

What about the name of the package - is unimod still the most appropriate, if we anticipate possible expansions into other notations?

[guideflandre]

• what are these aliases convertStyle and unimodStyle? I don't see them appearing anywhere else, so how could a user search for them?

No use for those indeed !

• Could you add links to the unimod function/dataframe in ?convertAnnotation(), for context. Same in the warning messages, to help the user debugging when a name or unimod id isn't recognised.

I added a reference to ?modifications.

What about the name of the package - is unimod still the most appropriate, if we anticipate possible expansions into other #9?

Indeed if the idea is to have a package as some sort of parser or where the focus lies on modifications, "unimod" might be too restrictive.