Issue Title
Inverting relationship for registering identifier prefixes
Issue Type
Process Improvement
Problem Statement
Currently we have a situation when products want to use the prefix mechanism such as VRS and refget, where their specifications have said what those prefixes are and then use TASC to indicate that prefix is now reserved. In the last discussions within refget sequence collections, the group felt this relationship should be switched around with the idea that specs do not get to reserve the prefix in their spec, that it is done here and referred back to.
The improvement would be better oversight of what "things" are being assigned prefixes but also allows the specs to say "use what TASC says for this concept identity". It seemed this is a better way for it to work
Scope Validation
Knowing what we can and should assign prefixes is difficult to understand. Especially as they only have meaning if they have become registered. Moving this into TASC means
- There is better oversight of what is given prefixes
- Why they've been given one
- It is at the right level of granularity
- Promotes better interoperability as the pathway for using these checksum identifiers with prefixes (though not exclusively for them) becomes clearer
Proposed Solution(s)
We would recommend the current system is expanded in scope with additional oversight back into TASC. When a prefix recommendation is received it is presented to TASC and then approved. Not a lot is different to how we manage this now.
Estimated Effort Level
Low (1-2 months, minimal resources)
Success Criteria
To measure success I would expect
- Registration of prefixes remains easy to accomplish
- An increase in the number of prefixes (assuming products need them)
How will this issue aid GA4GH harmonization?
The problem the prefixes is trying to solve is how can you tell what kind of typed identifier you are working with. Especially when the underlying character set and length of the identifier is the same. There is no way to know if one checksum derived ID is a VRS or a refget ID. Harmonisation at this level means a global GA4GH resolver, or similar bound resolver, knows what "thing" they have.
Additional context
Please provide any additional pieces of information you feel is relevant to this issue
Work Streams Raising This Issue
Other Groups Raising This Issue
No response
Work Streams That Will Be Impacted
Other Groups That Will Be Impacted
No response
Key Stakeholders to Consult
TASC but also VRS maintainers as the way this would work since they are the only other group that has used these prefixes. To note VRS was the first one to create the concept
Products affected
Please list them here. It does not need to be exhaustive
Additional Context
No response
Priority Level
Low (can be addressed in normal course of work)
Additional Tags
Issue Title
Inverting relationship for registering identifier prefixes
Issue Type
Process Improvement
Problem Statement
Currently we have a situation when products want to use the prefix mechanism such as VRS and refget, where their specifications have said what those prefixes are and then use TASC to indicate that prefix is now reserved. In the last discussions within refget sequence collections, the group felt this relationship should be switched around with the idea that specs do not get to reserve the prefix in their spec, that it is done here and referred back to.
The improvement would be better oversight of what "things" are being assigned prefixes but also allows the specs to say "use what TASC says for this concept identity". It seemed this is a better way for it to work
Scope Validation
Knowing what we can and should assign prefixes is difficult to understand. Especially as they only have meaning if they have become registered. Moving this into TASC means
Proposed Solution(s)
We would recommend the current system is expanded in scope with additional oversight back into TASC. When a prefix recommendation is received it is presented to TASC and then approved. Not a lot is different to how we manage this now.
Estimated Effort Level
Low (1-2 months, minimal resources)
Success Criteria
To measure success I would expect
How will this issue aid GA4GH harmonization?
The problem the prefixes is trying to solve is how can you tell what kind of typed identifier you are working with. Especially when the underlying character set and length of the identifier is the same. There is no way to know if one checksum derived ID is a VRS or a refget ID. Harmonisation at this level means a global GA4GH resolver, or similar bound resolver, knows what "thing" they have.
Additional context
Please provide any additional pieces of information you feel is relevant to this issue
Work Streams Raising This Issue
Other Groups Raising This Issue
No response
Work Streams That Will Be Impacted
Other Groups That Will Be Impacted
No response
Key Stakeholders to Consult
TASC but also VRS maintainers as the way this would work since they are the only other group that has used these prefixes. To note VRS was the first one to create the concept
Products affected
Please list them here. It does not need to be exhaustive
Additional Context
No response
Priority Level
Low (can be addressed in normal course of work)
Additional Tags