From 5b47a87236b304317ad1964d7a81c0a1f48f7a5a Mon Sep 17 00:00:00 2001 From: Michael Baudis <675030+mbaudis@users.noreply.github.com> Date: Sat, 17 Jun 2023 17:42:10 -0700 Subject: [PATCH 1/8] Update entryTypeDefinition.yaml The parameter descriptions in the EntryTypeDefinitions schema seem somewhat hard to parse and potentially misleading - this is a go at cleaning them up a bit. --- .../configuration/entryTypeDefinition.yaml | 51 +++++++++---------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/framework/src/configuration/entryTypeDefinition.yaml b/framework/src/configuration/entryTypeDefinition.yaml index 99f3ef974..4ca04013f 100644 --- a/framework/src/configuration/entryTypeDefinition.yaml +++ b/framework/src/configuration/entryTypeDefinition.yaml @@ -1,23 +1,22 @@ $schema: https://json-schema.org/draft/2020-12/schema title: '' -description: "Definition of an element or entry type including the Beacon v2 required\ - \ and suggested attributes. This schema purpose is to describe each type of entities\ - \ included in a Beacon, hence Beacon clients could have some metadata about such\ - \ entities.\n\nThe `id` attribute is the key that should be used in other parts\ - \ of the Beacon Model to allow Beacon clients to identify the different parts (e.g.\ - \ endpoints, filteringTerms, request parameters, etc.) that fully describe an entry\ - \ type." +description: >- + Definition of an element or entity, to describe each type of entity included in + a beacon. + The `id` attribute is the key that should be used in other parts of the data model + to allow Beacon clients to identify the different parts (e.g. endpoints, filteringTerms, + request parameters, etc.) that relvant for an entity. type: object -$comment: 'TO DO: The tagged parts should reference to `common/ontologizedElement.json`. - But that configuration fails to validate. Further investigation is required, but - should not affect the resulting schema.' properties: $schema: $ref: ../common/beaconCommonComponents.yaml#/definitions/$schema id: - $comments: ++++++ THIS IS THE START OF THE ontologized element ++++++ type: string description: A (unique) identifier of the element. + examples: + - biosample + - individual + - dataset name: type: string description: A distinctive name for the element. @@ -26,7 +25,6 @@ properties: description: A textual description for the element. ontologyTermForThisType: $ref: ../common/ontologyTerm.yaml - $comments: ++++++ THIS IS THE END OF THE ontologized element ++++++ partOfSpecification: description: This is label to group together entry types that are part of the same specification. @@ -42,25 +40,26 @@ properties: items: $ref: ../common/referenceToAnSchema.yaml aCollectionOf: - description: If the entry type is a collection of other entry types, (e.g. a Dataset - is a collection of Records), then this attribute must list the entry types that - could be included. One collection type could be defined as included more than - one entry type (e.g. a Dataset could include Individuals or Genomic Variants), - in such cases the entries are alternative, meaning that a given instance of - this entry type could be of only one of the types (e.g. a given Dataset contains - Individuals, while another Dataset could contain Genomic Variants, but not both - at once). + description: >- + If the entry type is a collection of other entities, (e.g. a Dataset + is a collection of Records), then this attribute must list the entities that + can be included. One _collection_ can include more than one entity + (e.g. a Dataset in teh Beacon cdefault model could include Individuals, Biosamples, + GenomicVariations, Analyses amnd Runs). In such cases in each individual + response (e.g. `resultSetsResponse` of collections of type "dataset") will + contain entries of a single entity type (e.g. biosamples) even if a dataset + may contain records of multiple types. includedConcepts: type: array $ref: ../common/basicElement.yaml filteringTerms: - description: Reference to the file with the list of filtering terms that could - be used to filter this concept in this instance of Beacon. The referenced file - could be used to populate the `filteringTerms`endpoint. Having it independently - should allow for updating the list of accepted filtering terms when it is necessary. + description: >- + Reference to the list of filtering terms that could be used to filter records + of this entity in this beacon. type: string - $comment: "TO DO: Double-check the proper way of referencing a path or relative\ - \ path. 'format: uri' is throwing validation errors for relative file paths" + $comment: >- + TO DO: Evaluate switch this to `url` or a more specific way for allowing + URLs and local file paths (is this necessary?). nonFilteredQueriesAllowed: $ref: ../common/beaconCommonComponents.yaml#/definitions/NonFilteredQueriesAllowed required: From 6aeb06ffebea6284c7b57f569b981bd08d4a081c Mon Sep 17 00:00:00 2001 From: Michael Baudis <675030+mbaudis@users.noreply.github.com> Date: Mon, 19 Jun 2023 13:11:35 +0200 Subject: [PATCH 2/8] Update entryTypeDefinition.json --- .../json/configuration/entryTypeDefinition.json | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/framework/json/configuration/entryTypeDefinition.json b/framework/json/configuration/entryTypeDefinition.json index 434bebcf6..13c094cc1 100644 --- a/framework/json/configuration/entryTypeDefinition.json +++ b/framework/json/configuration/entryTypeDefinition.json @@ -1,14 +1,13 @@ { - "$comment": "TO DO: The tagged parts should reference to `common/ontologizedElement.json`. But that configuration fails to validate. Further investigation is required, but should not affect the resulting schema.", "$schema": "https://json-schema.org/draft/2020-12/schema", "additionalProperties": true, - "description": "Definition of an element or entry type including the Beacon v2 required and suggested attributes. This schema purpose is to describe each type of entities included in a Beacon, hence Beacon clients could have some metadata about such entities.\n\nThe `id` attribute is the key that should be used in other parts of the Beacon Model to allow Beacon clients to identify the different parts (e.g. endpoints, filteringTerms, request parameters, etc.) that fully describe an entry type.", + "description": "Definition of an element or entity, to describe each type of entity included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filteringTerms, request parameters, etc.) that relvant for an entity.", "properties": { "$schema": { "$ref": "../common/beaconCommonComponents.json#/definitions/$schema" }, "aCollectionOf": { - "description": "If the entry type is a collection of other entry types, (e.g. a Dataset is a collection of Records), then this attribute must list the entry types that could be included. One collection type could be defined as included more than one entry type (e.g. a Dataset could include Individuals or Genomic Variants), in such cases the entries are alternative, meaning that a given instance of this entry type could be of only one of the types (e.g. a given Dataset contains Individuals, while another Dataset could contain Genomic Variants, but not both at once).", + "description": "If the entry type is a collection of other entities, (e.g. a Dataset is a collection of Records), then this attribute must list the entities that can be included. One _collection_ can include more than one entity (e.g. a Dataset in teh Beacon cdefault model could include Individuals, Biosamples, GenomicVariations, Analyses amnd Runs). In such cases in each individual response (e.g. `resultSetsResponse` of collections of type \"dataset\") will contain entries of a single entity type (e.g. biosamples) even if a dataset may contain records of multiple types.", "includedConcepts": { "$ref": "../common/basicElement.json", "type": "array" @@ -30,13 +29,17 @@ "type": "string" }, "filteringTerms": { - "$comment": "TO DO: Double-check the proper way of referencing a path or relative path. 'format: uri' is throwing validation errors for relative file paths", - "description": "Reference to the file with the list of filtering terms that could be used to filter this concept in this instance of Beacon. The referenced file could be used to populate the `filteringTerms`endpoint. Having it independently should allow for updating the list of accepted filtering terms when it is necessary.", + "$comment": "TO DO: Evaluate switch this to `url` or a more specific way for allowing URLs and local file paths (is this necessary?).", + "description": "Reference to the list of filtering terms that could be used to filter records of this entity in this beacon.", "type": "string" }, "id": { - "$comments": "++++++ THIS IS THE START OF THE ontologized element ++++++", "description": "A (unique) identifier of the element.", + "examples": [ + "biosample", + "individual", + "dataset" + ], "type": "string" }, "name": { @@ -47,7 +50,6 @@ "$ref": "../common/beaconCommonComponents.json#/definitions/NonFilteredQueriesAllowed" }, "ontologyTermForThisType": { - "$comments": "++++++ THIS IS THE END OF THE ontologized element ++++++", "$ref": "../common/ontologyTerm.json" }, "partOfSpecification": { From d3f7a9262e0b93d1e562f6fd2979d04cca1b941d Mon Sep 17 00:00:00 2001 From: Michael Baudis <675030+mbaudis@users.noreply.github.com> Date: Mon, 19 Jun 2023 13:26:37 +0200 Subject: [PATCH 3/8] removed ontologyTermForThisType requirement It is not clear how to use ontologyTermForThisType w/o examples (i.e. terms for biosample, individual... - added some but incomplete...) and there is also a logical duplication having a "unique" id and an ontology term. Overall this should be clarified but the current modification seems (a) sensible (step). --- .../json/configuration/entryTypeDefinition.json | 17 +++++++++++++---- .../src/configuration/entryTypeDefinition.yaml | 12 ++++++++---- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/framework/json/configuration/entryTypeDefinition.json b/framework/json/configuration/entryTypeDefinition.json index 13c094cc1..400fdb004 100644 --- a/framework/json/configuration/entryTypeDefinition.json +++ b/framework/json/configuration/entryTypeDefinition.json @@ -1,7 +1,7 @@ { "$schema": "https://json-schema.org/draft/2020-12/schema", "additionalProperties": true, - "description": "Definition of an element or entity, to describe each type of entity included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filteringTerms, request parameters, etc.) that relvant for an entity.", + "description": "Definition of an element or entity, to describe each type of entity included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering terms, request parameters, etc.) that are relvant for an entity.", "properties": { "$schema": { "$ref": "../common/beaconCommonComponents.json#/definitions/$schema" @@ -34,7 +34,7 @@ "type": "string" }, "id": { - "description": "A (unique) identifier of the element.", + "description": "A unique identifier of the element.", "examples": [ "biosample", "individual", @@ -50,7 +50,17 @@ "$ref": "../common/beaconCommonComponents.json#/definitions/NonFilteredQueriesAllowed" }, "ontologyTermForThisType": { - "$ref": "../common/ontologyTerm.json" + "$ref": "../common/ontologyTerm.json", + "examples": [ + { + "id": "EFO:0000542", + "label": "individual" + }, + { + "id": "OBI:0000747", + "label": "material sample" + } + ] }, "partOfSpecification": { "description": "This is label to group together entry types that are part of the same specification.", @@ -61,7 +71,6 @@ "required": [ "id", "name", - "ontologyTermForThisType", "partOfSpecification", "defaultSchema" ], diff --git a/framework/src/configuration/entryTypeDefinition.yaml b/framework/src/configuration/entryTypeDefinition.yaml index 4ca04013f..a101afe75 100644 --- a/framework/src/configuration/entryTypeDefinition.yaml +++ b/framework/src/configuration/entryTypeDefinition.yaml @@ -4,15 +4,15 @@ description: >- Definition of an element or entity, to describe each type of entity included in a beacon. The `id` attribute is the key that should be used in other parts of the data model - to allow Beacon clients to identify the different parts (e.g. endpoints, filteringTerms, - request parameters, etc.) that relvant for an entity. + to allow Beacon clients to identify the different parts (e.g. endpoints, filtering + terms, request parameters, etc.) that are relvant for an entity. type: object properties: $schema: $ref: ../common/beaconCommonComponents.yaml#/definitions/$schema id: type: string - description: A (unique) identifier of the element. + description: A unique identifier of the element. examples: - biosample - individual @@ -25,6 +25,11 @@ properties: description: A textual description for the element. ontologyTermForThisType: $ref: ../common/ontologyTerm.yaml + examples: + - id: EFO:0000542 + label: individual + - id: OBI:0000747 + label: material sample partOfSpecification: description: This is label to group together entry types that are part of the same specification. @@ -65,7 +70,6 @@ properties: required: - id - name - - ontologyTermForThisType - partOfSpecification - defaultSchema additionalProperties: true From dd943aece56a0f814cc1af4272da306e39344c8d Mon Sep 17 00:00:00 2001 From: Michael Baudis <675030+mbaudis@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:43:28 +0200 Subject: [PATCH 4/8] entry type as default instead entity --- .../json/configuration/entryTypeDefinition.json | 6 +++--- framework/src/configuration/entryTypeDefinition.yaml | 12 ++++++------ 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/framework/json/configuration/entryTypeDefinition.json b/framework/json/configuration/entryTypeDefinition.json index 400fdb004..b20352764 100644 --- a/framework/json/configuration/entryTypeDefinition.json +++ b/framework/json/configuration/entryTypeDefinition.json @@ -1,13 +1,13 @@ { "$schema": "https://json-schema.org/draft/2020-12/schema", "additionalProperties": true, - "description": "Definition of an element or entity, to describe each type of entity included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering terms, request parameters, etc.) that are relvant for an entity.", + "description": "Definition of an element or entry type, to describe each type of entry type included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering terms, request parameters, etc.) that are relvant for an entry type.", "properties": { "$schema": { "$ref": "../common/beaconCommonComponents.json#/definitions/$schema" }, "aCollectionOf": { - "description": "If the entry type is a collection of other entities, (e.g. a Dataset is a collection of Records), then this attribute must list the entities that can be included. One _collection_ can include more than one entity (e.g. a Dataset in teh Beacon cdefault model could include Individuals, Biosamples, GenomicVariations, Analyses amnd Runs). In such cases in each individual response (e.g. `resultSetsResponse` of collections of type \"dataset\") will contain entries of a single entity type (e.g. biosamples) even if a dataset may contain records of multiple types.", + "description": "If the entry type is a collection of other entities, (e.g. a Dataset is a collection of Records), then this attribute must list the entities that can be included. One _collection_ can include more than one entry type (e.g. a Dataset in teh Beacon cdefault model could include Individuals, Biosamples, GenomicVariations, Analyses amnd Runs). In such cases in each individual response (e.g. `resultSetsResponse` of collections of type \"dataset\") will contain entries of a single entry type (e.g. biosamples) even if a dataset may contain records of multiple types.", "includedConcepts": { "$ref": "../common/basicElement.json", "type": "array" @@ -30,7 +30,7 @@ }, "filteringTerms": { "$comment": "TO DO: Evaluate switch this to `url` or a more specific way for allowing URLs and local file paths (is this necessary?).", - "description": "Reference to the list of filtering terms that could be used to filter records of this entity in this beacon.", + "description": "Reference to the list of filtering terms that could be used to filter records of this entry type in this beacon.", "type": "string" }, "id": { diff --git a/framework/src/configuration/entryTypeDefinition.yaml b/framework/src/configuration/entryTypeDefinition.yaml index a101afe75..136c2980a 100644 --- a/framework/src/configuration/entryTypeDefinition.yaml +++ b/framework/src/configuration/entryTypeDefinition.yaml @@ -1,11 +1,11 @@ $schema: https://json-schema.org/draft/2020-12/schema title: '' description: >- - Definition of an element or entity, to describe each type of entity included in - a beacon. + Definition of an element or entry type, to describe each type of entry type included + in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering - terms, request parameters, etc.) that are relvant for an entity. + terms, request parameters, etc.) that are relvant for an entry type. type: object properties: $schema: @@ -48,11 +48,11 @@ properties: description: >- If the entry type is a collection of other entities, (e.g. a Dataset is a collection of Records), then this attribute must list the entities that - can be included. One _collection_ can include more than one entity + can be included. One _collection_ can include more than one entry type (e.g. a Dataset in teh Beacon cdefault model could include Individuals, Biosamples, GenomicVariations, Analyses amnd Runs). In such cases in each individual response (e.g. `resultSetsResponse` of collections of type "dataset") will - contain entries of a single entity type (e.g. biosamples) even if a dataset + contain entries of a single entry type (e.g. biosamples) even if a dataset may contain records of multiple types. includedConcepts: type: array @@ -60,7 +60,7 @@ properties: filteringTerms: description: >- Reference to the list of filtering terms that could be used to filter records - of this entity in this beacon. + of this entry type in this beacon. type: string $comment: >- TO DO: Evaluate switch this to `url` or a more specific way for allowing From 94b789198ec296830c67877097c0c828eef77e30 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oriol=20L=C3=B3pez-Doriga?= Date: Tue, 20 Jun 2023 16:46:19 +0200 Subject: [PATCH 5/8] update entryType description --- framework/json/configuration/entryTypeDefinition.json | 2 +- framework/src/configuration/entryTypeDefinition.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/framework/json/configuration/entryTypeDefinition.json b/framework/json/configuration/entryTypeDefinition.json index b20352764..27d425770 100644 --- a/framework/json/configuration/entryTypeDefinition.json +++ b/framework/json/configuration/entryTypeDefinition.json @@ -1,7 +1,7 @@ { "$schema": "https://json-schema.org/draft/2020-12/schema", "additionalProperties": true, - "description": "Definition of an element or entry type, to describe each type of entry type included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering terms, request parameters, etc.) that are relvant for an entry type.", + "description": "Definition of an element or scope of the element, to describe each type of entry type included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering terms, request parameters, etc.) that are relvant for an entry type.", "properties": { "$schema": { "$ref": "../common/beaconCommonComponents.json#/definitions/$schema" diff --git a/framework/src/configuration/entryTypeDefinition.yaml b/framework/src/configuration/entryTypeDefinition.yaml index 136c2980a..61916df7e 100644 --- a/framework/src/configuration/entryTypeDefinition.yaml +++ b/framework/src/configuration/entryTypeDefinition.yaml @@ -1,7 +1,7 @@ $schema: https://json-schema.org/draft/2020-12/schema title: '' description: >- - Definition of an element or entry type, to describe each type of entry type included + Definition of an element or scope of the element, to describe each type of entry type included in a beacon. The `id` attribute is the key that should be used in other parts of the data model to allow Beacon clients to identify the different parts (e.g. endpoints, filtering From cb3b2ff3c80f80a7f012914efe33a7ac306f7cc5 Mon Sep 17 00:00:00 2001 From: redmitry Date: Tue, 5 Sep 2023 15:11:08 +0200 Subject: [PATCH 6/8] for templates the format must be "uri-template". --- framework/json/configuration/beaconMapSchema.json | 6 +++--- framework/src/configuration/beaconMapSchema.yaml | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/framework/json/configuration/beaconMapSchema.json b/framework/json/configuration/beaconMapSchema.json index b5335e28b..47fec6701 100644 --- a/framework/json/configuration/beaconMapSchema.json +++ b/framework/json/configuration/beaconMapSchema.json @@ -18,7 +18,7 @@ }, "filteringTermsUrl": { "description": "Optional. Returns the list of filtering terms that could be applied to this entry type. It is added here for convenience of the Beacon clients, so they don't need to parse the OpenAPI endpoints definition to get that endpoint. Also, in very simple Beacons, that endpoint could be the one of the few implemented, together with \u00b4rootUrl` and \u00b4singleEntryUrl`, in which case the whole map of endpoints is found in the current Map.", - "format": "uri", + "format": "uri-template", "type": "string" }, "openAPIEndpointsDefinition": { @@ -32,7 +32,7 @@ }, "singleEntryUrl": { "description": "Optional, but recommended. Returns only one instance of this entry, identified by an `id`. It is added here for convenience of the Beacon clients, so they don't need to parse the OpenAPI endpoints definition to get that base endpoint. Also, in very simple Beacons, that endpoint could be the only one implemented, together with \u00b4rootUrl`, in which case the whole map of endpoints is found in the current Map.", - "format": "uri", + "format": "uri-template", "type": "string" } }, @@ -50,7 +50,7 @@ }, "url": { "description": "Endpoint URL", - "format": "uri", + "format": "uri-template", "type": "string" } }, diff --git a/framework/src/configuration/beaconMapSchema.yaml b/framework/src/configuration/beaconMapSchema.yaml index ce1cff2c2..83170dab6 100644 --- a/framework/src/configuration/beaconMapSchema.yaml +++ b/framework/src/configuration/beaconMapSchema.yaml @@ -46,7 +46,7 @@ definitions: be the only one implemented, together with ´rootUrl`, in which case the whole map of endpoints is found in the current Map. type: string - format: uri + format: uri-template filteringTermsUrl: description: Optional. Returns the list of filtering terms that could be applied to this entry type. It is added here for convenience of the Beacon clients, @@ -55,7 +55,7 @@ definitions: the few implemented, together with ´rootUrl` and ´singleEntryUrl`, in which case the whole map of endpoints is found in the current Map. type: string - format: uri + format: uri-template endpoints: description: Optional. A list describing additional endpoints implemented by this Beacon instance for that entry type. Additional details on the endpoint @@ -74,7 +74,7 @@ definitions: url: description: Endpoint URL type: string - format: uri + format: uri-template returnedEntryType: description: Which entry type is returned by querying this endpoint. It MUST match one of the entry types defined in the Beacon configuration file (`beaconConfiguration.json`). From c634b81c6c012c0d2973fcf256df762c5fbb0516 Mon Sep 17 00:00:00 2001 From: Michael Baudis Date: Sat, 16 Nov 2024 09:08:49 +0900 Subject: [PATCH 7/8] VRS references from 1.2 => 1.3 The Beacon schema for genomic allows 3 options: * VRS MolecularVariation * VRS SystemicVariation * Beacon LegacyVariation (which adopts the VRS location object but uses separate definitions otherwise) Unfortunately, during Beacon v2 approval only VRS 1.2. was available and then explicitly referenced in the schema. It fast superseded by 1.3 which allows a *much* better definition of "Systemic Variations" such as CNV. This PR changes all VRS references from 1.2 => 1.3 and should be very welcome to implementers (1.3. has been the longstanding standard now until the future 2.x is out; in fact, the `bycon` based implementations such as progenetix.org have been using it for their Beacons for ~2years). --- bin/beacon_yaml2md.pl | 4 ++-- bin/deref_schemas/obj/CopyNumber.yaml | 2 +- docs/schemas-md/obj/CopyNumber.md | 2 +- .../genomicVariations/defaultSchema.json | 8 ++++---- .../genomicVariations/defaultSchema.yaml | 8 ++++---- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/bin/beacon_yaml2md.pl b/bin/beacon_yaml2md.pl index 9fc75fe5d..1285de4de 100755 --- a/bin/beacon_yaml2md.pl +++ b/bin/beacon_yaml2md.pl @@ -729,9 +729,9 @@ sub add_properties_vrs { my ( $property, $data ) = @_; my %url = ( 'SequenceExpression' => -'https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/', +'https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/', 'CopyNumber' => -'https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/' +'https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/' ); if ( exists $url{$property} ) { $data->{properties} = diff --git a/bin/deref_schemas/obj/CopyNumber.yaml b/bin/deref_schemas/obj/CopyNumber.yaml index 37906e038..ec96fa12b 100644 --- a/bin/deref_schemas/obj/CopyNumber.yaml +++ b/bin/deref_schemas/obj/CopyNumber.yaml @@ -1,4 +1,4 @@ --- CopyNumber: - properties: '[VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/CopyNumber)' + properties: '[VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/CopyNumber)' type: allOf diff --git a/docs/schemas-md/obj/CopyNumber.md b/docs/schemas-md/obj/CopyNumber.md index 88e7a5ee7..e55d7cca3 100644 --- a/docs/schemas-md/obj/CopyNumber.md +++ b/docs/schemas-md/obj/CopyNumber.md @@ -1,3 +1,3 @@ |Term | Description | Type | Properties | Example | Enum| | ---| ---| ---| ---| ---| --- | -| CopyNumber | NA | allOf | [VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/CopyNumber) | NA | NA| +| CopyNumber | NA | allOf | [VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/CopyNumber) | NA | NA| diff --git a/models/json/beacon-v2-default-model/genomicVariations/defaultSchema.json b/models/json/beacon-v2-default-model/genomicVariations/defaultSchema.json index 394bef5c4..19d42db14 100644 --- a/models/json/beacon-v2-default-model/genomicVariations/defaultSchema.json +++ b/models/json/beacon-v2-default-model/genomicVariations/defaultSchema.json @@ -1,5 +1,5 @@ { - "$comment": "version: ga4gh-beacon-variant-v2.0.0", + "$comment": "version: ga4gh-beacon-variant-v2.1.0", "$defs": { "CaseLevelVariant": { "description": "", @@ -272,7 +272,7 @@ "type": "string" }, "location": { - "$ref": "https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/Location" + "$ref": "https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/Location" }, "referenceBases": { "description": "Reference bases for this variant (starting from `start`). * Accepted values: IUPAC codes for nucleotides (e.g. `https://www.bioinformatics.org/sms/iupac.html`). * N is a wildcard, that denotes the position of any base, and can be used\n as a standalone base of any type or within a partially known sequence.\n* an *empty value* is used in the case of insertions with the maximally\n trimmed, inserted sequence being indicated in `AlternateBases`.", @@ -557,10 +557,10 @@ "variation": { "oneOf": [ { - "$ref": "https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/MolecularVariation" + "$ref": "https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/MolecularVariation" }, { - "$ref": "https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/SystemicVariation" + "$ref": "https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/SystemicVariation" }, { "$ref": "#/$defs/LegacyVariation" diff --git a/models/src/beacon-v2-default-model/genomicVariations/defaultSchema.yaml b/models/src/beacon-v2-default-model/genomicVariations/defaultSchema.yaml index b5e5cc9ec..df68f4d7d 100644 --- a/models/src/beacon-v2-default-model/genomicVariations/defaultSchema.yaml +++ b/models/src/beacon-v2-default-model/genomicVariations/defaultSchema.yaml @@ -1,6 +1,6 @@ $schema: https://json-schema.org/draft/2020-12/schema title: Genomic Variation -$comment: 'version: ga4gh-beacon-variant-v2.0.0' +$comment: 'version: ga4gh-beacon-variant-v2.1.0' description: >- Schema for a genomic variant entry. type: object @@ -10,8 +10,8 @@ required: properties: variation: oneOf: - - $ref: https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/MolecularVariation - - $ref: https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/SystemicVariation + - $ref: https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/MolecularVariation + - $ref: https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/SystemicVariation - $ref: '#/$defs/LegacyVariation' variantInternalId: description: >- @@ -51,7 +51,7 @@ $defs: - location properties: location: - $ref: https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/Location + $ref: https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/Location variantType: description: >- The `variantType` declares the nature of the variation in relation From b1f81dcf9e280f79e3db5050a623bbb2bbd4addb Mon Sep 17 00:00:00 2001 From: Michael Baudis Date: Sat, 16 Nov 2024 09:22:14 +0900 Subject: [PATCH 8/8] removing the schema deparser changes The `beacon_yaml2md.pl` doc generator contains hard coded definitions to VRS 1.2 `CopyNumber` which doesn't exist in 1.3. This should be fixed separately, possibly w/ revision of the schema documentation method/engine. --- bin/beacon_yaml2md.pl | 4 ++-- bin/deref_schemas/obj/CopyNumber.yaml | 2 +- docs/schemas-md/obj/CopyNumber.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/bin/beacon_yaml2md.pl b/bin/beacon_yaml2md.pl index 1285de4de..9fc75fe5d 100755 --- a/bin/beacon_yaml2md.pl +++ b/bin/beacon_yaml2md.pl @@ -729,9 +729,9 @@ sub add_properties_vrs { my ( $property, $data ) = @_; my %url = ( 'SequenceExpression' => -'https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/', +'https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/', 'CopyNumber' => -'https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/' +'https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/' ); if ( exists $url{$property} ) { $data->{properties} = diff --git a/bin/deref_schemas/obj/CopyNumber.yaml b/bin/deref_schemas/obj/CopyNumber.yaml index ec96fa12b..37906e038 100644 --- a/bin/deref_schemas/obj/CopyNumber.yaml +++ b/bin/deref_schemas/obj/CopyNumber.yaml @@ -1,4 +1,4 @@ --- CopyNumber: - properties: '[VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/CopyNumber)' + properties: '[VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/CopyNumber)' type: allOf diff --git a/docs/schemas-md/obj/CopyNumber.md b/docs/schemas-md/obj/CopyNumber.md index e55d7cca3..88e7a5ee7 100644 --- a/docs/schemas-md/obj/CopyNumber.md +++ b/docs/schemas-md/obj/CopyNumber.md @@ -1,3 +1,3 @@ |Term | Description | Type | Properties | Example | Enum| | ---| ---| ---| ---| ---| --- | -| CopyNumber | NA | allOf | [VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.3/vrs.json#/definitions/CopyNumber) | NA | NA| +| CopyNumber | NA | allOf | [VRS definition for CopyNumber](https://w3id.org/ga4gh/schema/vrs/1.2/vrs.json#/definitions/CopyNumber) | NA | NA|