Required updates to kraken2-to-mag-features

[misialq]

Flagstaff, we have a problem. @bokulich-lab/moshpit-team

When working on the tests for the "final" Kraken2 PR (#38) I had an awful realization. We discussed how the kraken2-to-mag-features would generate a FeatureData[Taxonomy] artifact mapping MAG ids to taxa - unfortunately, that's not what is happening. As a single MAG is a FASTA file containing a collection of contigs, Kraken2 classifies each contig and not the entire MAG. In effect, the hits table (aka Kraken2 output) contains contig IDs and not MAG IDs. In a short discussion with @nbokulich today we were trying to come up with a solution to this issue and what we would like to propose is the following:

1. we create an additional output out of the binning action: a ContigMap which maps contigs to respective MAGs (or vice-versa)
2. we adapt the classify-kraken2 action to accept FeatureData[MAG] rather than SampleData[MAGs] so that we classify the dereplicated MAGs (I think we discussed doing this anyways)
3. the classify-kraken2 action then outputs FeatureData[KrakenReport] and FeatureData[KrakenOutput] for those
4. we use those two as inputs to kraken2-to-mag-features, together with the ContigMap from the binning step - this does the selection as it was written in the original PR but we add a small step at the end to perform an LCA selection to assign a single taxon to a single MAG - we can then output the same artifacts as originally designed and desired

Some thoughts:

• I think at this point it would really be easier if we gave the bins some unique IDs - here are some options that came to mind:
  • generate a hash based on the actual sequences (expensive)
  • use some shorter unique ID (not sequence-based), maybe something like https://github.com/skorokithakis/shortuuid?
  • assign some arbitrary IDs?
• Not to keep all this work in one PR, I'd suggest we wrap up the open one but disable the kraken2-to-mag-features action until everything else is ready

What do y'all think, does this make sense? I'm including a quick sketch of what this could look like after those updates:

If everyone is ok with that, I would create some issues for all those things and work on those. Thanks!

[ebolyen]

Hey @misialq,

I think this makes a lot of sense (I like the diagram), and I can see how kraken really wouldn't treat the reads any differently from the contigs here, so of course we would end up with the contig ids rather than MAG ids 🤦‍♂️

I'm definitely in support of a contig-map kind of artifact as well, and think people are likely to ask for it anyhow as binning is probably going to feel mysterious to many.

Regarding the unique IDs, does the bin de-replicator solve this at all?

[nbokulich]

Regarding the unique IDs, does the bin de-replicator solve this at all?

good call. We discussed using q2-sourmash for dereplication, in which case we are already making a sketch of the full sequence. The mash sketches are too long to use as an ID (and anyway I think sourmash sketches are not a fixed length). Maybe for the unique derep IDs we could take an md5 hash of the mash sketch? Is that a totally stupid idea?

for undereplicated MAGs I like the sound of shortuuid. Would this confuse users, though?

[gregcaporaso]

This all makes perfect sense in hindsight! And I like your plan. Just some minor questions/comments:

1. 👍 The ContigMap idea makes a lot of sense, and seems analogous to the QIIME 1 OTU map, which we've been talking about possibly needing to revive. If we were aligning with that idea, that would map a MAG id to the contig ids that were binned to it. (And worth throwing out there now: would it be worth making this more generic, e.g., FeatureMap? That could also map, say, pathway ids to read or contig ids that were assigned to that pathway, or taxon labels to read or contig ids that were assigned that taxonomy.)
2. 👍 Would it still take the other SampleData input types (i.e., would read classification change)? In that case we'd sometimes be getting FeatureData back as output and other times be getting SampleData back as output. Seems like a non-issue for the type map, but is that conceptually weird? We could start with this and then reassess if it feels wrong.
3. 👍
4. 👍 Just curious - do you see the assignments generally aligning with one another within the bins?

For the un-dereplicated MAGs, my vote would be for regular V4 uuids since our users are already used to looking at those and they're pretty easily recognized. For dereplicated MAGs, my vote would be to use ids generated by the dereplicator, if it does that and approach for generating the ids is reasonable, and V4 uuids if not.

I notice in the ContigMap diagram you have sample information - is that needed? (The note next to it suggests maybe not, but not sure if that note is in reference to the ContigMap.)

Not to keep all this work in one PR, I'd suggest we wrap up the open one but disable the kraken2-to-mag-features action until everything else is ready

Agreed.

Thanks for all the work on this everyone!

[misialq]

Thanks for inputs, everyone!

On ContigMap/FeatureMap (point 1):

• now that you mentioned it, I guess we could introduce a more generic type. For our specific use case, would you envision this as something like FeatureMap[MAGtoContigs] or rather just FeatureMap?
• sample IDs would not be needed if we use unique MAG IDs - sorry for the confusion (I thought of that after I sketched the table in the picture 😅)

On SampleData vs. FeatureData as inputs to classify-kraken2 (point 2):

• my thinking was we would replace SampleData[MAG] with FeatureData[MAG] so you are right, the outputs would differ for reads and MAGs (as we would keep the reads input as-is) but that would be handled by a TypeMap; I thought it kinda made sense as we do consider MAGs as features (particularly when they come from dereplication)

On assignment consistency (point 4):

• I have not explicitly tried to assess that, particularly because the datasets I'm using during development are more of the "toy" kind... but that is an absolutely interesting question so I will be paying attention to this when working on the implementations discussed above and can report back later

On MAG IDs - the way I imagined this was the following:

• we assign unique IDs before dereplication (I like the idea of V4 UUID as it probably gives us enough of a uniqueness guarantee)
• we do the dereplication: no new IDs are generated as all the dereplication does is to find a representative MAG without modifying its actual contents (so not exactly the same as denoising for 16S; at least in the implementation that we would go for initially)
• we can keep using the original IDs and perhaps just prune the table to only include the ones that are left after dereplicating

Does that makes sense?

[gregcaporaso]

For our specific use case, would you envision this as something like FeatureMap[MAGtoContigs] or rather just FeatureMap?

I think the former, but I could probably be convinced otherwise. I think it comes down to whether there are things we'd do with one subtype that would be fundamentally flawed operations with a different subtype. That seems like it is probably the case for FeatureMap[MAGtoContigs] versus (say) FeatureMap[PathwaytoReads].

we do consider MAGs as features (particularly when they come from dereplication)

I also think this makes sense. It's actually the SampleData route that feels more strange to me, but I think that's b/c of my background with amplicon analysis. I think we should run with this as you laid out.

assignment consistency

Makes sense - the skeptic in me feels like we're going to have a reasonable amount of inconsistency, but we'll see how it goes and that could ultimately be very helpful information for assessing confidence in MAG taxonomy assignment.

we can keep using the original IDs

As long as we're just selecting a representative MAG, that sounds perfect. If the MAG bins are modified in anyway in this process, I think assigning a new V4 UUID (and outputting FeatureMap[MAGtoMAGs]?) is the right approach.

Thanks @misialq! This all feels very intuitive to me!

[misialq]

Agreed on all accounts - I'll create some issues next week and start working on those then :)

[misialq]

Hey @bokulich-lab/moshpit-team,

little update: I've got the first two PRs ready:

• ENH: add FeatureMap[MAGtoContigs] types and formats q2-types-genomics#48: FeatureMap[MAGtoContigs] formats/types
• ENH: output a contig map during binning; rename MAGs using UUIDs #48: update to binning introducing the contig map output and MAG UUIDs

Anyone wants to have a look?

[gregcaporaso]

hey @misialq, sorry for the slow reply! I should be able to take a look at both tomorrow.