I searched the community first and only found an older thread about the previous expressions structure (/t/graphql-query-for-expression-data/1840), which predates
this change — so I’m opening a new topic.
On data version 26.06, the GraphQL field target.expressions returns an empty list
for every gene I’ve tried — including ubiquitously-expressed housekeeping genes such
as GAPDH (ENSG00000111640) and ACTB (ENSG00000075624) — consistently across repeated
calls. The new field target.baselineExpression, by contrast, returns populated
per-biosample data (GTEx bulk and Tabula Sapiens single-cell, TPM summary stats) for
the same genes. My reproducer query and screenshots are below.
I also notice that target.expressions is still present in the schema and is not
marked as deprecated (isDeprecated: false, deprecationReason: null), and its
description still refers to Expression Atlas and the Human Protein Atlas — the older
sources.
A few questions:
Is target.expressions intentionally retired in 26.06 in favour of target.baselineExpression?
Will expressions be formally deprecated/removed, or is the empty result
temporary?
Is baselineExpression the recommended field for baseline RNA/protein expression
going forward?
{
meta { dataVersion { year month } }
target(ensemblId: "ENSG00000111640") { # GAPDH (housekeeping; swap any ENSG id)
approvedSymbol
expressions { tissue { id label } } # OLD field — now returns []
baselineExpression(page: { index: 0, size: 3 }) { # NEW field (26.06)
rows {
tissueBiosample { biosampleId biosampleName }
median min q1 q3 max unit datasourceId
}
}
}
}
Yes target.expression has been intentionally retired in place of target.baselineExpression
expressions will be deprecated/removed
Yes baselineExpression is the recommended field for baseline RNA/protein expression going forwards
We have replaced the old expression with baseline expression for a few reasons but we aware there may be some teething issues with replacing a dataset like this so if you spot anything that looks amiss, please feel free to let us know. We are confident that this new dataset will be better for most usecases.
Thanks for the clear and quick confirmation — that fully answers our questions.
For context, we ran into this while adapting the gget library’s opentargets
interface to the API, which is how we spotted it. Since the data model changed
(per-tissue RNA z-score → per-biosample TPM at tissue/cell-type level), it isn’t a
drop-in swap for our existing output, so we’ll discuss internally how best to adopt baselineExpression — and we’ll flag anything that looks amiss with the new dataset.
@elarwei, I understand we are not making your life easy with these changes in the API schema.
Deprecating endpoints with notice periods might be beyond our reach, but would it be helpful to have the changes in schemas (both data and API) documented in the Release notes?
Hi @ochoa — thanks, and honestly no worries; the change makes sense, and the quick confirmation here was exactly what we needed.
Yes, documenting schema changes in the release notes would be really helpful for downstream tools like gget. In our case the field returned an empty list rather than an error, so it took us a bit of digging to realise the change was intentional rather than a transient data issue. A brief note on such changes — ideally covering both API updates (e.g. expressions → baselineExpression) and data-model shifts (per-tissue RNA z-score → per-biosample TPM) — would make it easy for integrators to adapt quickly.
On our side we’ve already repointed gget’s opentargets expression interface to baselineExpression, so we’re all set — this is really just a suggestion for smoothing future releases. Thanks again for being so responsive!
