Request for URI Support to Preserve Semantics in FHIR Translation

[SalemBajjali]

Hi VRS Team,

I'm currently working on translating VRS Alleles into the FHIR Allele Profile and wanted to raise an issue involving the loss of semantic precision during the translation process.

Issue
VRS fields such as name, digest, and others carry well-defined and distinct semantic meanings. However, when translating into FHIR, many of these fields are mapped into a flat structure like fhir.identifier.Identifier.value, which strips away the original meaning and origin of each field.

Example FHIR representation:

"identifier": [
{ "value": “vsrs_name_value },
{ "value": “vrs_digest_value” }
]

This flattens distinct VRS attributes into a generic list of values, making it difficult for downstream systems to determine whether a given value is a computed identifier, symbolic name, or another VRS-specific concept.

Proposed Solution
To address this, we propose using fhir.identifier.system, which is a URI data type, to capture the semantic role of each identifier. This approach would require standardized URIs that uniquely identify specific VRS fields.

Request
Would the VRS team be open to defining and maintaining a set of standardized URIs for key VRS attributes? This would help enable accurate and semantically translations of VRS concepts into FHIR.

Looping in @rrfreimuth

[Mrinal-Thomas-Epic]

This is an interesting idea Salem. I wonder if we can use a JSON pointer with the id already attached to each JSON schema. For example for adjacency, https://w3id.org/ga4gh/schema/vrs/2.0.1/json/Adjacency#properties/digest

[rrfreimuth]

I think this is pretty close, Mrinal. The example defines the class, whereas we really need to define the property. For example, we would need unique URIs for both id and name. If we could take this and strip it down to a single property, that might work.

Thinking out loud. Important defining elements for this purpose include class $id and $title, and property name (although everything listed could be included in case it is needed for other use cases). The product (VRS) and version (2.0.1) could be captured separately if desired (e.g., a schema element at the same level as class and property). I'm flexible on the structure, just showing containment the way I think about it.

{
   "class": {
     "$id": "https://w3id.org/ga4gh/schema/vrs/2.0.1/json/Adjacency",
     "title": "Adjacency",
     "type": "object",
     "maturity": "trial use",
     "ga4gh": {
        "prefix": "AJ",
        "inherent": [
           "adjoinedSequences",
           "linker",
           "type"
        ]
     },
     "description": "The `Adjacency` class represents the adjoining of the end of a sequence with the beginning of an adjacent sequence, potentially with an intervening linker sequence.",
   },
   "property": {
      "name": "id",
      "type": "string",
      "description": "The 'logical' identifier of the Entity in the system of record, e.g. a UUID.  This 'id' is unique within a given system, but may or may not be globally unique outside the system. It is used within a system to reference an object from another.",
      "$comment": "Note that it is common for implementers to create their own internal logical ids - typically a serially or randomly generated value like a UUID that is assigned to the data object as it is created in a system. But an implementer may choose to re-use an existing, globally unique id from an external system or authority for this purpose (e.g. an HGNC id for a Gene object) - as long as it is unique within the implementing system, and can be used to reference the identified object in this context."
    },
}

[SalemBajjali]

Thanks both — this discussion has been really helpful.

As a starting point, I’ll apply the JSON Pointer approach that @Mrinal-Thomas-Epic suggested (e.g., #properties/digest) as a working draft for referencing specific fields. It seems like a useful way to keep the original meaning of each field while we continue exploring URI conventions.

While looking through the vrs/json directory, I didn’t see a schema file specifically for extensions — it’s possible I overlooked it. Should it exist? I noticed that the expression schema is available and can be referenced (e.g., via #properties/propertyName), but I didn’t find an equivalent for extensions.

[SalemBajjali]

^ Disregard my earlier comment about extensions — @korikuzma pointed out that extensions are defined in gks-core:
https://github.com/ga4gh/gks-core/blob/1.0/schema/gks-core/json/Extension