Open caodac opened 4 years ago
This requires explanation. Whenever a SubstanceReference is used, the intent is that it behaves something like a "stub" for a full record. That is, the JSON portion of a SubstanceReference
could theoretically be replaced with the JSON for a full substance, therefore embedding the definition of the linked record into one "portable" JSON. This has never been done in practice outside of scripts/forms that create the JSON, but it could be done in the future for exchange.
The field "substanceClass" ends up describing what kind of substance is being contained. Here are the common values:
Substance Class | Meaning |
---|---|
chemical | a chemical substance is described. Expect a "structure" JSON component |
protein | a protein substance is described. Expect a "protein" JSON component |
reference | a substance reference is described, expect a "refuuid" and optional "refPname" and "approvalID" which can be used to look up the full definition of the substance within the database |
mention | a substance mention is described. This is like a "reference", but may not have a valid "refuuid" to an existing substance in the database, but only a valid "refPname" or "approvalID" for abstract linking. That is, it may just be a reference to an abstract concept of a substance which is not currently housed in the same database. |
In practice, the only 2 values that the database will have for a substanceClass in the substance reference table would be reference
or mention
. However, if a JSON was received which instead had a substanceClass
of chemical
embedded where a substanceReference was common, this would signal that this "inner" record should be registered first and then the "outer" record should be registered pointing to the inner one as a "reference" substanceClass substanceReference.
The
SubstanceClass
always has"reference"
as the value forsubstanceClass
. This field is annotated withJSONConstants.ENUM_REFERENCE
in the fileix/ginas/models/v1/SubstanceReference.java
. This looks wrong.