Issue in insdc.gca namespace record

[andrewyatz]

Hi there

I've noted an issue in the insdc.gca namespace which I believe will cause certain identifiers to be unresolvable. The identifier pattern is currently ^GC[AF]_[0-9]{9}\.[0-9]+$ and permits two types of genome identifier to be resolved

1. GCAs - The INSDC accession for a genome (available from ENA and Genbank/NCBI)
2. GCFs - The RefSeq accession for a genome (available only from RefSeq/NCBI)

The latest release of the human assembly GRCh38.p14 (hg38) has the GCA GCA_000001405.29 and GCF GCF_000001405.40. The first will resolve correctly in identifiers.org (to ENA) but the second will resolve to an invalid URL.

I believe the following could happen to resolve this:

1. The pattern for insdc.gca is altered to ^GCA_[0-9]{9}\.[0-9]+$
2. A separate namespace is created for GCFs e.g. refseq.gcf or ncbi.gcf is created with the pattern GCF_[0-9]{9}\.[0-9]+$ and a resolver provider going to a URL such as https://www.ncbi.nlm.nih.gov/datasets/genome/GCF_000001405.40

Any help would be appreciated

[renatocjn]

Hello,

Thank you for bringing this to our attention.

I will have to investigate a bit on this. We had issues with ENA before where an entry took a while to be available even if available in NCBI. So this may be just a matter of time until it shows in ENA. If this is the the case, we might make NCBI primary so that all resolutions go there, until we can discuss the issue with the ENA team.

Your proposal could work but we might not want to simply remove GCF resolution from the insdc.gca namespace because others may have used links to those. Changing the pattern would break those references.

For the moment, please use the ncbi provider code to always resolve to ncbi. Your link would be http://identifiers.org/ncbi/insdc.gca:GCF_000001405.40

I will get back to you on that.

[andrewyatz]

Thanks for the consideration and suggestions around how to mitigate the issue too. Really useful. The main point I do want to make though is GCF accessions are not part of the INSDC collaboration exchange so I do think their inclusion in the record/pattern is a mistake. But considering the above URL example of using an alternative provider code I can also see why that would be an issue too.

Thank you

[renatocjn]

Sorry for the delay. I had a look and spoke with my colleague about it and you are correct. We will be creating a new namespace as you recommended before. Thank you for bringing this up to us.

[renatocjn]

Done, Please have a look and let me know if there is anything else that should be changed insdc.gca and insdc.gcf

[andrewyatz]

Thank you for reviewing this and thank you for the progress and changes.

I have a couple of points to make but nothing major:

• The GCF extension is not part of insdc to my knowledge and limited to just NCBI but I'm not sure if that should influence the prefix or not i.e. ncbi.gcf vs. insdc.gcf. Just raising the question not suggesting going one way or the other
• The description of GCF says The scope of the genome collections database does not extend to viruses, viroids and bacteriophage. yet there are viral genomes with a GCF such as SARS-CoV-2. The same is true of GCAs see their SARS-CoV-2 record. I can't say anything about viroids or bacteriophage though.

[renatocjn]

Good points.

• I will try to ask ENA if GCFs are part of INSDC just in case.
• I will update the description of the gcf namespace.

[renatocjn]

Hello @andrewyatz I spoke with Henning and we decided to change the prefix of the new namespace to refseq.gcf We generally advise against changing prefixes but since it is unrelated to insdc and it is a very new namespace, it shouldn't be that big of a deal. It was also my mistake since I missed the last part of your original message where you proposed the prefix name.

[cthoyt]

FYI renaming caused issues in the Bioregistry since we import Identifiers.org on a daily basis

[andrewyatz]

Many thanks @renatocjn I appreciate the work you've done here and also apologise @cthoyt for the knock on effects this has had

[renatocjn]

Yes. Sorry @cthoyt, it was my fault for not paying enough attention when reading his original message. Hopefully, it wasn't too difficult of an issue.