26.06 release now live!

News and Announcements Releases
1

We have just released the latest update to the Open Targets Platform — 26.06.

Key stats

Metric Count
Targets 78,691
Diseases/phenotypes 47,080
Drugs/Clinical candidates 22,407
Variants 7,538,243
Evidence 42,394,639
Associations 17,199,165

Number of credible sets

Metric Count
GWAS 1,474,648
eQTL 1,349,418
tuQTL 384,849
sQTL 223,500
sceQTL 52,738
pQTL 33,718

Number of unique studies in GWAS credible sets: 54,495
Number of unique biosampleIDs (number of tissues/cell types) from molQTLs: 98

Evidence metrics for this release

For more details and numbers, read the 26.06 blog post.

2 Likes
2

Hi all,

Thanks to all for the 26.06 release, always a highlight of the year!

There is a data quality issue in two OpenTargets parquet datasets where null bytes (\x00) are embedded within disease name strings. This causes problems downstream (eg, when loading the data into PostgreSQL, as PostgreSQL does not allow null bytes (\u0000) in text or jsonb columns, leading to load failures).

The first affected dataset is the clinicalTrial dataset, specifically the file clinical_report.parquet. The issue appears in the diseases column, which contains a list of structs, and more precisely in the diseaseFromSource field. In total, six rows are affected. The corrupted values include examples such as “S\u0000e9zary syndrome” and “s\u0000zary syndrome,” which should both read “Sézary syndrome,” as well as “Sj\u0000f6gren’s syndrome,” which should be “Sjögren’s syndrome.” There is also one extreme case where a single “s” is followed by hundreds of null bytes.

The second affected dataset is evidenceClinicalPrecedence, where the issue occurs in a parquet part file. Here, the problem is in the top-level diseaseFromSource string column. Twelve rows are affected, all containing the corrupted value “s\u0000zary syndrome.”

The root cause appears to be a character encoding issue affecting accented characters such as “é” (U+00E9) and “ö” (U+00F6). These characters are normally encoded in UTF-8 as multi-byte sequences (for example, “é” as 0xC3 0xA9). In the affected data, the leading byte seems to have been lost and replaced with a null byte, resulting in sequences like \x00\xA9. This suggests a faulty charset conversion or improper handling of UTF-8 encoding during data processing.

Perhaps something to fix in the background with some targeted edits.

Best,

F

3

Hi @flo,

Thank you for reporting this. Another user has also reported the issue, and Irene has posted an answer in that thread: Weird characters in compound synonym - #2 by irene

The issue stems from our LLM extraction input data, and we will prepare a fix for our next release that patches the intended characters from the corrupted escape sequences.

Sorry for the inconvenience!

4

Thanks for the update folks! I was curious about how an “interaction” is defined between the cis and trans gene when including the trans-pQTL CS to the L2G score of the cis gene?

Edit: I see the documentation here ( Locus-to-Gene (L2G) | Open Targets Platform Documentation ) so I was just wondering what the curated data bases were?