Issue in Poseidon_IDs of `2025_Amjadi_NorthernIran`

[TCLamnidis]

I think there is something wrong with the Poseidon IDs used in 2025_Amjadi_NorthernIran.

The genetic IDs used in the paper correspond to the information found in the Alternative_IDs column of the janno file.

This is a problem because the information in the Poseidon_ID column actually refers to the Sequencing_ID found in Supplementary table S4.

It seems like data from the same individuals are kept as separate entities in the package. For example, individual IRN23 in the paper corresponds to Sequencing_IDs IRNGC23W, and IRN2GC23W in S4. However, in the package, those two IDs appear as separate individuals.

Note that the contributors have diligently noted the two IDs as being same_as in the Relationship columns, but that does not match the paper, where the data are presumably merged into one individual labelled IRN23.

[TCLamnidis]

I only realised this when trying to coalesce the jannos in the PCA and PMA, to find out that their IDs did not match and did not have a one-to-one relationship.

[nevrome]

I see. This was submitted and reviewed in #277, and finally merged with #286. Pinging @Tlkhi and @smpeltola to discuss the issue.

I guess there are multiple ways to address this. We could add the missing merged individual to the existing package. Or entirely replace the genotype data generated by @Tlkhi with the SNP-incomplete author-provided ones he has also obtained. There the samples would probably be merged.

Do you have concrete suggestions?

And a question for clarification: Do the Poseidon_IDs have to be adjusted for all samples, or does this only concern the split ones?

[TCLamnidis]

Using the generated genotypes would also be fine, so long as the data from the same individuals get merged first, to match the dataset used by the authors (presumably).

As for your question:
To match the IDs in the paper, all IDs would have to be swapped (imo), but it is only a problem with the underlying data in the cases where one multiple Sequencing_IDs get merged together.

[Tlkhi]

Some individuals have been sequenced using different methods
IRN2GC23W and IRNGC23W are two separately sequenced samples of the individual IRN23

IRN2GC23W was sequenced using TwistAncientDNA
IRNGC23W was sequenced using ArborComplete (if I recall correctly)

[Tlkhi]

Note that the authors did not merge these differently sequenced samples

To verify this, you can download the official dataset from the following link and check the .ind file:
https://agi.abtk.hu/images/Amjadi_NatureSciRep_20250513.zip

[TCLamnidis]

But, for instance, in S4 I also see that the ID IRN2GC23W exists as both Arbor and Twist capture. 🤔

Rows 5 AND 19

[Tlkhi]

Right - Just checked again
IRN2GC24W and IRN2GC23W
But maybe it’s a mistake by the authors? I’m not really sure

Maybe you can judge based on the instrument models they used?:
TwistAncientDNA – Illumina NovaSeq X Plus
Arbor – Illumina NovaSeq 6000

[TCLamnidis]

It is hard to know what the right course of action is, without the author's "insider knowledge".
I am not sure using the sequencer model as an identifier of data type is the way to go, unless we get confirmation from the authors that that makes sense to do.

At the same time, I do understand why you might want to keep Twist and Arbor data separate, particularly if the authors did so as well.
A middle-of-the-way solution would be to include multiple versions of each individual, one Twist, one Arbor, and one with both. Those could be denoted using suffixes in the Poseidon_ID. Though I know @nevrome is not a fan of those suffixes.

Another solution would be to mirror in the PMA the package state in the PCA. The SSF would then need changing to use the IRNGC34W nomenclature instead of IRN34, the recipe updated, and the data reprocessed. With such an approach, the goal is to have some consistency between the Poseidon archives.

[Tlkhi]

I can ask Yusuf about this issue. I think @nevrome should rethink about suffixes, because there are several reasons:

1. It is not appropriate to merge differently sequenced samples (unless the authors of the paper have applied both methods on the same samples), as this can lead to bias and other issues

2. Keeping them separated is more useful and helpful, providing greater clarity for users also

I think sooner or later you will add the suffixes, but it would be better to add them sooner rather than later

[nevrome]

I was never against suffixes to meaningfully distinguish samples or processing entities. I'm only against suffixes to systematically store information that should instead be stored in well-specified variables.

The "middle-of-the-way solution" proposed by @TCLamnidis does sound most future-proof to me. And I would leave it entirely up to you, @Tlkhi, to come up with meaningful Poseidon_ID suffixes for these three versions of the same sample. Of course only if you're willing to look into the matter once more.

[Tlkhi]

I agree, the middle-of-the-way solution suggested by @TCLamnidis does sound like the most future-proof approach

For Twist - TW
For Arbor - AR