Closed mbaudis closed 3 years ago
Apart from the criteria of longer names in bodies and shorter in query string, not limiting to symbols was on purpose, given my ignorance on how much we could/should enforce using just the symbols. Could we? Having the opinion of the community would be interesting.
geneId
(s
) would be shorter & more permissive but may be problematic itself - I'd rather have something like this using ontologyTerm
objects for scoping (again, not totally opposed).
However, the geneSymbol
is in line with the current description for gene
:
"description": "Gene symbol following the HGNC (https://www.genenames.org) nomenclature.",
And I don't by into the length argument since
So 6 characters more isn't really an issue, given the can of worms opened by something like gene
.
@mbaudis @antbro manuel.rueda@crg.eu Skipping the GET length thingy... could we enforce using only gene symbols? or would this fireback with complaints from implementers?
IMU, according to the GA4GH Beacon call this week, geneId
and geneIds
are preferable as we should not stick to HGVS gene symbols.
I'll update the genomicVariation
files to reflect that.
The change will be reflected in an incoming PR.
The models contain various parameters which in essence refer to a gene symbol/name, e.g.
geneIds
https://github.com/ga4gh-beacon/beacon-v2-Models/blob/5136123994e19c505ef1c6360369c38b8fcc3af9/BEACON-V2-draft4-Model/genomicVariations/defaultSchema.json#L141gene
(explicitly referencing a gene symbol) https://github.com/ga4gh-beacon/beacon-v2-Models/blob/5136123994e19c505ef1c6360369c38b8fcc3af9/BEACON-V2-draft4-Model/genomicVariations/requestParameters.json#L59 https://github.com/ga4gh-beacon/beacon-v2-Models/blob/5136123994e19c505ef1c6360369c38b8fcc3af9/BEACON-V2-draft4-Model/genomicVariations/endpoints.json#L310... (other instances?).
I propose to use
geneSymbol
andgeneSymbols
throughout (or alternativelygeneId
|geneIds
, if other identifiers would be permitted ... but IMO not). Solelygene
is too fuzzy.