I have seen in the q2 library classifier section that the latest Silva 138 classifier was trained in 2024-05-30 using Silva 138.1 release (looked it up in the provenance tab). Is there an update of this classifier to the latest Silva release 138.2 (SSU Ref NR 99; release date 2024-07-11 ) scheduled?
But also poke around a little bit on that site as there are lots of options. @silva-team is now building and distributing QIIME 2 classifiers on their own, and there are lots of options. We plan to update the Library to point to this new resource shortly.
I'm not sure I understand this comment. This is still the most recent version of sklearn that QIIME 2 uses, so these classifiers work with the most recent version of QIIME 2. Let us know if you run into any issues.
I have learned in the past years that scikit-learn version used for a classifier has to match a with the q2 release used for the analyses. If I remember correctly, scikit-learn changed from q2-2024.2 to q2-2025.5 from 0.24.1 to the current 1.4.2. @colinbrislawn is providing similar info with the UNITE10 classifiers via the âconda env pinâ link on github/unite-train, and you are doing the same on the new q2 library classifier page by sorting classifiers to the appropriate q2 release.
But the Silva built classifiers are (not yet) there and I wanted to make sure that the classifier built by silva team is also using the scikit-learn version of the recent q2 releases since q2-2024.5 (I am not a programmer, and I was not aware of the current version of scikit-learn). Therefore, I looked it up the provenance info of the classifier.
A short info: I got the following error message due to the used archive version 7.
SILVA138.2_SSURef_NR99_uniform_classifier_V4-515f-806r.qza was created by 'QIIME 2025.7.0'. The currently installed framework cannot interpret archive version '7.0'.
I have seen this in other situations but I was able to use q2-2025.4 with this classifier without any issues.
I did not yet install more recent q2-releases since I am using q2-gemelli and q2-qurro in q2-2025.4; I did not had the chance to install and test these third-party plugins there.
If you arenât able to install gemelli and qurro in a more recent version (and do let us know, we should probably pester some folks), then you can try the following:
First qiime tools extract the classifier (or just unzip the qza) and then import the resulting data/ directory again inside your older distribution (for qurro and gemelli). You shouldnât need to specify the format (only the type). If in doubt, the details in metadata.yaml will be the same as you need for the import.
You will lose provenance, but it will let you carry on without any further issue (as the sklearn versions match).
In particular, qurro installation displays this info:
added / updated specs:
- qurro
The following packages will be downloaded:
package | build
---------------------------|-----------------
certifi-2026.1.4 | pyhd8ed1ab_0 147 KB conda-forge
qurro-0.9.0 | pyhd8ed1ab_2 440 KB conda-forge
------------------------------------------------------------
Total: 588 KB
The following NEW packages will be INSTALLED:
qurro conda-forge/noarch::qurro-0.9.0-pyhd8ed1ab_2
The following packages will be UPDATED:
ca-certificates 2025.10.5-hbd8a1cb_0 --> 2026.1.4-hbd8a1cb_0
certifi 2025.10.5-pyhd8ed1ab_0 --> 2026.1.4-pyhd8ed1ab_0
openssl 3.5.4-h26f9b46_0 --> 3.6.1-h35e630c_1
The following packages will be SUPERSEDED by a higher-priority channel:
iow pypi/pypi::iow-1.0.7-pypi_0 --> bioconda/linux-64::iow-1.0.5-py310hc31ed2c_5
Here, iow is downgraded again to 1.0.5, but I do a second pip install iow==1.0.7 and it seems to work.
I did not export and re-import some data as suggested, since I do use provenance intensively when writing manuscripts (replay-provenance) and I would like to keep my own workflow simple, e.g. without ex-/importing steps.
I can well imagine how complex qiime2 has become, and versioning is certainly a huge challenge. However, if I could use external plugins without workarounds, it would give me more confidence that incompatible dependencies would not be introduced.
A big thank you to everyone in the qiime2 team, both immediate and extended, for this great tool.
I have used the uniform silva 138.2-V4 classifiers (built by SILVA team: uuid:"ee876dd6-edfa-4c81-b0a4-a885b9b4acd1") and extracted taxonomy stats from my own analysis by q2 rescript evaluate-taxonomy together with the GG2-V4 (for comparison) and previous Silva 138.2-V4 classifier trained by myself.
With the uniform silva 138.2-V4 classifier (SILVA138.2-V4-pre) , I observe the same number of features classified at depth 6 (genus) and 7 (species), see the horizontal line. However, the SILVA team did not include species labels at the q2 rescript parse-silva-taxonomy step (as recommended), but the (default) rank handles were used down to species level in the downstream q2 rescript dereplicate step.
I built my own classifier (SILVA138.2-V4-own) a while ago, following the q2 rescript tutorial in the q2 forum with q2 rescript get-silva-data and did include species labels (to see species annotation, even when we do not use them) and the default rank handles in the dereplicate step. The number of features ending at level 7 goes considerably down (as expected).
Is the same number of features classified at L6 and L7 in the pretrained classifier simply due to the fact that there are no species labels present in this classifier, and the number is propagated from L6 to L7? Or should this line go town to â0â as every L7 is empty (all features are ending with â;s__â when the genus is not empty)?
Would you recommend to use rank handles only down to âgenusâ if the âinclude species labels:falseâ option has been choosen before?
Yes. If you do not actually have valid species-level information (e.g., only propagated genus or empty species labels), then the species-level information is not going to be meaningful.