I hope to invest some time in the coming weeks to read more about the mzML and mzIdentML regarding the feature matching. This is build in, although I don't know the details. I think this is something that should be considered before tackling things purely from R in the frame of our discussions.

Laurent, do you know what governs the choice of number for the acquisitionNum in the mzR header()?

As some of the native ID formats contains multiple integer values this is important to ensure correct indexing. Examples from the psi-ms.obo:

A complicated case:

id: MS:1000770
name: WIFF nativeID format
def: "sample=xsd:nonNegativeInteger period=xsd:nonNegativeInteger cycle=xsd:nonNegativeInteger experiment=xsd:nonNegativeInteger." [PSI:MS]
is_a: MS:1000767 ! native spectrum identifier format

A simple case

id: MS:1000772
name: Bruker BAF nativeID format
def: "scan=xsd:nonNegativeInteger." [PSI:MS]
is_a: MS:1000767 ! native spectrum identifier format

If we can get the mzR mapping I think a simple lookup table with the name of the IDFormats as keys and a regular expression that extracts the correct number from the spectrumID column in the mzIDpsm class as value would do the trick.

Then we could have:

require(stringr)
getConverter <- function(nativeID) {
 if (nativeID %in% names(lookup)) {
  regexp <- lookup[nativeID]
 } else {
  regexp <- nativeID
 }
 return(
  function(spectrumID) {
   str_extract(spectrumID, regexp)
  }
 )
}

which would easily allows us to add to the known cases, and let a user specify their own regular expressions if they are working with an esoteric ms data format.

I have thought about this and I actually think this should have a separate package instead of being incorporated into mzR or mzID. Both of these package are parsers and shouldn't come with so much else additional cruft, and certainly not depend on each other. It should be perfectly legal to only have mzID if the interest is only in evaluating search results...

I'm thinking a new package that defines how the two different objects work together would make sense, as there could also be standard plotting methods for the objects and combinations of the objects there; something that doesn't fit into a parser, but still general enough for a lot of people to want...

Anyway - this is just a start of a possibly long discussion on the subject, and as there is no code yet it is still a moot point : )