New linked sequence type

[colinvwood]

Description

Add a new LinkedDNA type that is to FeatureData[LinkedSequence] what skbio.DNA is to FeatureData[Sequence].

AI Disclosure

• NO AI USED.
• AI USED.

AI Usage Details

Codex wrote the three tests.

[colinvwood]

@ebolyen

I chose not to inherit from skbio.DNA because it signs us up for too many things that we don't want to be signed up for, like translation.

I removed all functionality related to gaps because the space character is added as a gap character but does not share the same interpretation as other gap characters. If we want to think closely now or later about how to support those methods we can, but I don't think the inherited implementations are going to be the right choice.

[ebolyen]

Any reason not to let " " act as non-canonical base/residue in the class? i.e. it isn't a gap, and then we let everything else work normally.

[nbokulich]

thanks @colinvwood ! yeah makes sense that translation should not be inherited.

would it be possible to add a transformer from DNAFASTAFormat --> LinkedDNAFASTAFormat?

[colinvwood]

Any reason not to let " " act as non-canonical base/residue in the class? i.e. it isn't a gap, and then we let everything else work normally.

I'm not sure what you mean by "non-canonical base", but a base needs to be one of three things: a definite character, a degenerate character, or a gap character. It's of course not a degenerate character. If we make it a definite character instead of a gap character, then all sorts of other stuff would be broken (e.g. definite(), nondegenerates(), gc_content()).

Making an exception for the space character and just adding it to the alphabet without classifying it as one of those three categories seems like a bad idea because the alphabet is defined as the union of those three character sets, so who knows what would break if we did that.

If we really want we could make a new category (delimiter_chars or something) and then update everything in the inheritance chain that needs to be aware of it, but I'm not sure how much work that'll be.

[colinvwood]

thanks @colinvwood ! yeah makes sense that translation should not be inherited.

would it be possible to add a transformer from DNAFASTAFormat --> LinkedDNAFASTAFormat?

Sure. Just to confirm, you didn't have any actual data transformation in mind, just want to change the type?

[nbokulich]

Just to confirm, you didn't have any actual data transformation in mind, just want to change the type?

I am trying to find a unified view type for FeatureData[Sequence] and FeatureData[LinkedSequence] that is not a DNAiterator. It seems like LinkedDNAFASTAFormat would be the most permissive format to accept both... technically maybe we should have something like a super generic FASTAFormat.

This is needed for the classify-sklearn action in q2-feature-classifier, which cannot use DNAiterator because the iterator needs to be generated a few times.

[colinvwood]

I am trying to find a unified view type for FeatureData[Sequence] and FeatureData[LinkedSequence] that is not a DNAiterator. It seems like LinkedDNAFASTAFormat would be the most permissive format to accept both... technically maybe we should have something like a super generic FASTAFormat.

Were you thinking of using the LinkedDNAFASTAFormat directly, i.e. as the actual view in that action? That seems like possibly a pain to work with. We already have a FASTAFormat and could make both DNAFASTAFormat and LinkedDNAFASTAFormat transform to it. What would be missing is any validation of the alphabet of the sequences contained in it. If that's not a concern, and you think it wouldn't be too unergonomic to work with as a view, I can add those transformers.

[nbokulich]

hey @colinvwood , transformers to FASTAFormat would be perfect in that case. Thanks!