Closed mbrush closed 2 months ago
I'm fine with this upgrade as it still allows the implementers the ability to deviate if/when their codes are not representable as CURIEs (which will definitely happen).
@mbrush I'm not sure if this needs further discussion/consideration. I believe you and I agreed that this is a fine recommendation. Since you updated the Coding.code
description to reflect this preference. I believe this is all set. Please reopen if desired and state what is left to do if anything.
This issue pertains to the proposal for updating the Coding definition in PR #17 .
As presently written, the definition of Coding and its properties are a bit too minimal IMO, and would benefit from a little implementation guidance. PR #17 aims to provide this - with inspiration taken from FHIR Coding spec (link), and from Bob's initial stab at a data type spec for GA4GH (link).
In short, the proposed enhancements give more guidance around acceptable and preferred form/syntax for specifying a code, and a code system. This guidance is still quite permissive (e.g. recommends but does not require the
system
be entered as a uri/url, and that thecode
to be represented as a CURIE where possible). As the model matures we can apply tighter constraints on certain fields/values if we choose to. We can also define clear conventions around the use of CURIEs here and in other elements of the model. But for now I think the minimal recommendations provide din PR #17 are useful and sufficient.An example of how I envision a well-formed Coding object looking is below (it holds a code from the Contributor Role Ontology as the value of a
Contribution.activity
attribute).:But as noted, the draft in PR #17 allows for cases where the code is not a CURIE (can be anything, e.g.
AFR
), and the system does not have a proper uri/url (e.g. "Gnomad-Defined Race Codes").