Add SC as Sequence collection prefix

[tcezard]

No description provided.

[mbaudis]

Is the 2 letter prefix a preferred format? Otherwise I'd go for SQC (apologies if I have missed provenance/discussions). There might be other Sx coming up etc.

[andrewyatz]

Alongside @ahwagner and @larrybabb I'm another approver on this based on the maintainers file

[tcezard]

Just wanted to Ping this PR. After discussion in our meeting we're happy with either SC or SQC. Happy for you to advise.

[ahwagner]

Either makes sense, SQC is nice for its extension from SQ for sequences.

[mbaudis]

+1 (SQC)

[rrfreimuth]

Either makes sense, SQC is nice for its extension from SQ for sequences.

Agree with the desire to maintain consistency by extending the existing SQ

[jmarshall]

Is there a proposal (e.g., a PR) in your repository adding a mention of using this namespace? (Similar perhaps to the one in refget.)

As an observer outside the refget/seqcol core, it seems to me that seqcol is something of a partner to refget sequences but is not meaningfully an extension to it. So I don't see that SQC is inherently better than SC.

Note for example that SAM tags are limited to two characters, so when seqcol pointers are added to SAM et al (cf samtools/hts-specs#824) it will be with a two-character tag which will surely be SC. So there would be a small advantage to the GA4GH prefix being aligned with that.

After discussion in our meeting we're happy with either SC or SQC. Happy for you to advise.

Have your deliberations been captured in minutes or as an ADR? I think it would be important to know what the specification's authors consider the pros and cons of the two options to be.

[larrybabb]

I believe these namespace acronyms could grow such that we will hit collisions or suboptimal acronyms that get a bit more difficult to correlate to the class of objects they represent. I believe the important aspect of this is that we keep these acronyms to 2 or 3 letters (no numbers? I assume) and do not exceed that length. I envision these working similarly to airport codes or stock symbols. The first to "grab" a code gets it - full stop, no changing over time. Future proofing is a bit futile although looking across what we currently know and making some rational choice based on the current plans is reasonable. It should become less important about how closely it correlates to a given association between the products or classes and more about having a name that may be slightly easier to recognize. We should not put much more baggage or requirement on it than that IMO.

If these somewhat loose set of naming principles work we should probably refine and add them to the readme or somewhere to help others as they partake in requesting new namespace codes.