GA4GH Namespace policy

[ahwagner]

Problem Statement

The VRS standard submitted a proposal to the GA4GH Steering Committee to approve the use of the ga4gh namespace for VRS computed identifier CURIEs. This was approved by the Steering Committee, with the understanding that a governance mechanism would be established for object identifiers under this namespace once an appropriate technical committee was established (TASC).

VRS is preparing to release new data type prefixes under the ga4gh namespace as part of its upcoming minor version releases. We intend to move forward with these as scheduled until a formal mechanism for registering / requesting identifier prefixes is created.

Impact of alignment between standards

Due to the organization-level namespacing, any CURIEs generated under this namespace should have a consistent meaning across products. If two standards (e.g. refget and VRS) develop identifiers with similar prefixes or inconsistent structures under the ga4gh namespace, interoperability between resources implementing multiple GA4GH products expecting ga4gh CURIEs will fail.

Background research and landscape analysis

We have worked to create an identifier scheme that has been reviewed and approved by unanimous vote of the GA4GH Steering Committee.

We have established several type prefixes already, with more that will be generated over the next year as we iteratively expand VRS.

This has direct relevance to the DRS, VRS, and refget standards, and likely others down the road.

Proposed solution

The VRS Project Maintainers are granted authority to build additional type prefixes under the ga4gh namespace without external review, so long as those identifiers begin with V, (e.g. VS for VariationSet, VA for Allele, VH for Haplotype). Data type prefixes outside of this scope must be reviewed and approved by TASC before implementation. Similar project-level subdomains could be approved and allocated by TASC for other standards as needed.

In addition, a TASC-maintained public registry of type prefixes (approved, reserved, and pending) should be provided for quick reference by product developers and implementers.

[rrfreimuth]

There are several items underlying this proposal that TASC must address:

1. Determine the scope of prefixes within the ga4gh namespace. Specifically, should a prefix be established independently by a GA4GH product (irrespective of similar prefixes or entities used in other products) or should prefixes describe entities that may be used across products?
   • If two products reference a common object (e.g., sequence), should both products use the same prefix for that object?
   • If the same prefix is used by two products to describe a common entity (e.g., sequence), are the products required to use the same structure and semantics for that entity?
2. Determine whether naming conventions should be established for prefixes.
   • It is natural to choose prefixes that contain some semantic meaning, as they are often abbreviations of the entities they describe (e.g., VRS uses SQ for sequence).
   • Should there be ga4gh-wide conventions for prefix length or substructure (e.g., OID-like subdomains using the first letter to indicate product or work space)?
3. Establish governance process for approval of prefixes.
   • Should prefixes be approved by a project team, sponsoring work space, TASC, and/or Steering Committee?
   • Should prefixes be assigned on a “first come, first served” basis, or chosen in an open process that includes potential future users of the prefix?

I will add my own thoughts to these issues when TASC brings the issue Under Discussion.

[rrfreimuth]

Since this issue is on the agenda for Monday, I'm adding some thoughts here. Numbers correspond to the points I listed earlier in this thread.

1. I think prefixes should be scoped beyond a single product, and should instead roughly reflect the type of entity they name. Products and organizational structures (e.g., work spaces) change over time, whereas prefixes and the entities they describe should be constant. This means if two products refer to the same type of entity (i.e., implement the same object), they should use the same prefix. A corollary is that each prefix should be associated with a defined entity type (object) so its use is consistent across products.

2. I think we need to establish some minimal conventions, and we should try to avoid embedding too much meaning in what are essentially business identifiers.

3. I think we need a short process to assign prefixes. As an example:
   a. Sponsoring team submits to TASC a request, which includes the proposed prefix and its corresponding entity. The latter includes a description and a reference to the object in a spec or GA4GH object repository (e.g., SchemaBlocks). This could require no more than a few sentences of description and cross-references.
   b. TASC reviews the proposal, checking for overlap with any existing or similar elements
   c. TASC announces the proposal to all project teams, which have 1 week to declare interest; non-response is taken to mean assent
   d. Discussion as needed among project team representatives, if needed, to achieve consensus
   e. TASC reviews and approves the final proposal

[jaeddy]

Do we need conventions/governance beyond "register the proposed namespace in identifiers.org"? It seems like that would handle most use cases in terms of exposing existing, related products and avoiding duplication in prefixes.

Where TASC could add value is by aggregating namespaces in identifiers.org that are specific to or being used by GA4GH — just to have a more constrained search scope. Something similar to this for ServiceInfo could be sufficient.

[jaeddy]

In terms of structure for a registry/catalog, here's an example for an identifiers.org namespace object (as returned by the registry API) (cc @rishidev):

    "namespaces" : [ {
      "prefix" : "3dmet",
      "mirId" : "MIR:00000066",
      "name" : "3DMET",
      "pattern" : "^B\\d{5}$",
      "description" : "3DMET is a database collecting three-dimensional structures of natural metabolites.",
      "created" : "2019-06-11T14:15:50.652+0000",
      "modified" : "2019-06-11T14:15:50.652+0000",
      "deprecated" : false,
      "deprecationDate" : null,
      "sampleId" : "B00162",
      "namespaceEmbeddedInLui" : false,
      "_links" : {
        "self" : {
          "href" : "https://registry.api.identifiers.org/restApi/namespaces/230"
        },
        "namespace" : {
          "href" : "https://registry.api.identifiers.org/restApi/namespaces/230"
        },
        "contactPerson" : {
          "href" : "https://registry.api.identifiers.org/restApi/namespaces/230/contactPerson"
        }
      }
    },

[ahwagner]

I agree with registering at identifiers.org. This was a recommended registry in the above mentioned presentation that was reviewed and approved by the Steering Committee. However, I think that I'm not understanding how registering at identifiers.org will resolve the issue presented here.

To clarify the problem statement, ga4gh is the prefix that would be registered, and the type prefixes (e.g. VA) should not be confused with CURIE prefixes (e.g. ga4gh). You can read more about rationale for why we want a unified namespace / CURIE prefix in the above-linked documents.

[mamanambiya]

I agree with registering at identifiers.org. This was a recommended registry in the above mentioned presentation that was reviewed and approved by the Steering Committee. However, I think that I'm not understanding how registering at identifiers.org will resolve the issue presented here.

To clarify the problem statement, ga4gh is the prefix that would be registered, and the type prefixes (e.g. VA) should not be confused with CURIE prefixes (e.g. ga4gh). You can read more about rationale for why we want a unified namespace / CURIE prefix in the above-linked documents.

So @ahwagner in ga4gh:VA.56789zyxwv for example, is the prefix VA simply referring to the type of entity or rather to a product? In other words is the prefix agnostic of a product or WS? So that an exisitng prefix could be used by different groups/teams when proposing identifiers of the same type?

[ahwagner]

So @ahwagner in ga4gh:VA.56789zyxwv for example, is the prefix VA simply referring to the type of entity or rather to a product? In other words is the prefix agnostic of a product or WS?

Yes. For example, the VA refers to an identifier describing a VRS Allele. VRS also uses the SQ type prefix for Sequence identifiers, which may also be generated by another group, such as the refget standard. @andrewyatz may have more to say on the plans for using these type prefixes in refget.

[ahwagner]

So that an exisitng prefix could be used by different groups/teams when proposing identifiers of the same type?

The idea would be that groups could reuse identifiers–but I think that it is important to clarify that once a type prefix is assigned, new groups should not be proposing / TASC should not be approving overloaded use of that prefix.

[mellybelly]

Please ensure that multiple designated resolvers are utilized. I recommend N2T as the second one (though there are a number of options). It would also be terrific if all prefixes could be registered in prefix commons. https://github.com/prefixcommons

[mellybelly]

@cmungall @jmcmurry @deepakunni3 might have suggestions too

[rrfreimuth]

It appears there may be some confusion/conflation of the various topics in this issue. I apologize for not catching that earlier and providing clarification. To recap:

The CURIE syntax that was previously approved is of the following format: namespace:type.id, where namespace (aka CURIE prefix) is "ga4gh", type is an abbreviation (aka "type prefix" or "prefix"), and id is the identifier. The type prefix is intended to give the consumer an idea of what type of entity the id references.

The VR Spec has defined several type prefixes already, including SQ for "sequence", VA for "allele", and VT for "text" (meaning variation represented as unstructured text).

The proposal by the VRS team is reposted here for convenience:

The VRS Project Maintainers are granted authority to build additional type prefixes under the ga4gh namespace without external review, so long as those identifiers begin with V, (e.g. VS for VariationSet, VA for Allele, VH for Haplotype). Data type prefixes outside of this scope must be reviewed and approved by TASC before implementation. Similar project-level subdomains could be approved and allocated by TASC for other standards as needed.

In addition, a TASC-maintained public registry of type prefixes (approved, reserved, and pending) should be provided for quick reference by product developers and implementers.

Since the type prefixes are unique within the ga4gh namespace, any project that defines a type prefix (e.g., VS, VA, VH, SQ, VT) is reserving that prefix across the entire organization. The reuse of type prefixes should be encouraged, but if two projects use the same prefix for different types of entities, confusion will abound.

In my post earlier in this thread I provided 3 opinions. I will summarize all 3 here and add a fourth that was mentioned by others.

1. Type prefixes (e.g., VA, SQ) should represent entities and their naming should be independent of a particular product; the former are constant, the latter change. Prefixes must be defined well so they can be re-used appropriately across products.

2. Naming conventions are fine, but we should avoid embedding too much meaning in business identifiers.

3. TASC needs a short process to review and approve proposed type prefixes. A suggestion for this is in my previous post.

4. All GA4GH-approved type prefixes should be registered at identifiers.org and/or similar registries.

[jaeddy]

I think I'm more or less on board with the conventions that @rrfreimuth and @ahwagner are proposing above, with the caveat that I don't think ga4gh is a logical/meaningful namespace (or prefix). I would argue that 'GA4GH' (an SDO) as a namespace is analogous to iso: or w3c:, etc. (which, to my knowledge, are not used in most contexts).

The actual namespace/standard in question here is the Variant Representation Specification (VRS). Thus, I would argue that the prefix should be vrs: OR for the sake of uniqueness (and also compliant with identifiers.org conventions), ga4gh.vrs:.

The end result being something along the lines of...

"sequence_id": "ga4gh.vrs:SQ._0wi-qoDrvram155UmcSC-zA5ZK4fpLT"

There probably isn't a huge value-add with the ga4gh.<standard> syntax in terms of avoiding collisions — i.e., there probably won't be a ga4gh.wes: SQ... or ga4gh.duo:SQ — but it definitely provides greater transparency and clarifies provenance.

To @rrfreimuth's point (4): the above still wouldn't establish a convention for registering type prefixes, but more so GA4GH standard prefixes. I think, to some extent, this is where the work @jb-adams is doing on the service-registry API/portal comes into play... but probably still needs some more thought.

[jaeddy]

Examples for reference: