Hi Mike,

That looks pretty straightforward. There's be a little work handling the .gz* business, and the scan location column values (not saying this is problematic in this case, but it's often where things get tricky). Otherwise pretty straightforward, I think. It looks like you're the developer, so you could actually take a run at this yourself if you wanted, with our help.

Best,

Brian Pratt

I would be happy to try and contribute, if you could provide some guidance!

Probably the best bang for your buck would be creating a .pepXML output - that would get you into Skyline and a number of other packages as well. And you wouldn't have to spelunk into our codebase. :)

Another standard format option is mzIndentML, which is arguably the modern standard to replace pepXML. If you have a look at the web page where we have detailed what is currently supported:

https://skyline.ms/wiki/home/software/Skyline/page.view?name=building_spectral_libraries

You can see that ByOnic, MSGF+, PeptideShaker, and Scaffold all support mzIdentML. Though, certainly a lot more support PepXML. Once you have either, we would still need to make a minor modification to our scoring lists to recognize Sage as a valid score provider. And then we could add a line for you to the page linked to above.

Thanks for your interest in integrating with Skyline.

Unfortunately, supporting mzIdentML is not trivial (~900 lines of code). I would strongly prefer to avoid supporting any XML based formats if possible (instead preferring to support modern data storage formats like parquet that can be dropped into the existing scientific software stack [e.g. pandas, polars]), given that we frequently use Sage for searching >100s of files at once and the resulting XML based file formats are space hogs.

It seems like MaxQuant, X!Tandem, Mascot, Proteome Discoverer have their native output formats supported, presumably this is also acceptable for Sage?

Certainly doable, yes.

Typically, the search results files are not big compared with the data files. I am not a huge fan of the proliferation of TSV formats. Yes, it seems people have an easier time writing them than any form of standardized XML, but it does get a bit tricky for us trying to recognize them all by they columns they contain. MaxQuant is different because it uses a clear filename, msms.txt. The others you list are XML, DAT, and SQLite with the extension pdResult.

Luckily, Sage also uses a clear filename, "results.sage.tsv". I also write a JSON file containing the engine version, search params, input files, and output file locations, e.g.

{
  "version": "0.13.0",
  "database": {
    "enzyme": {
      "missed_cleavages": 1,
      "min_len": 7,
      "max_len": 40,
      "cleave_at": "KR",
      "restrict": "P",
      "c_terminal": true
    },
    "static_mods": {
      "C": 57.0215
    },
    "variable_mods": {
      "M": [
        15.994
      ]
    },
    "fasta": "fasta/human_yeast.fasta"
  },
  "precursor_tol": {
    "da": [
      -2.0,
      2.0
    ]
  },
  "fragment_tol": {
    "ppm": [
      -50.0,
      50.0
    ]
  }
  "deisotope": true,
  "chimera": true,
  "wide_window": true,
  "min_peaks": 15,
  "max_peaks": 250,
  "max_fragment_charge": 2,
  "min_matched_peaks": 2,
  "report_psms": 4,
  "predict_rt": true,
  "mzml_paths": [
    "path/A1.mzML.gz",
   "..."
  ],
  "output_paths": [
    "PRM/results.sage.pin",
    "PRM/results.sage.tsv",
    "PRM/results.json"
  ]
}

What's the best way to get started on this?

I still think your best plan would be mzIdentML, but if we're not going that route then you'll want to get the Skyline and BiblioSpec code from GitHub and look at how we handle the other formats you mentioned.

That's a fairly steep hill to climb, though. We can probably help you with this after ASMS (or if it's me personally, not until the end of June due to travel plans).