{"id":11832,"date":"2024-10-21T13:47:42","date_gmt":"2024-10-21T12:47:42","guid":{"rendered":"https:\/\/www.blopig.com\/blog\/?p=11832"},"modified":"2025-10-03T23:05:23","modified_gmt":"2025-10-03T22:05:23","slug":"the-xchem-trove-of-protein-small-molecules-structures-not-in-the-pdb","status":"publish","type":"post","link":"https:\/\/www.blopig.com\/blog\/2024\/10\/the-xchem-trove-of-protein-small-molecules-structures-not-in-the-pdb\/","title":{"rendered":"The XChem trove of protein\u2013small-molecules structures not in the PDB"},"content":{"rendered":"
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

The XChem facility at Diamond Light Source<\/a> is truly impressive feat of automation in fragment-based drug discovery, where visitors comes clutching a styrofoam ice box teeming with apo-form protein crystals, which the shifter soaks with compounds from one or more fragment libraries and a robot at the i04-1 beamline kindly processes each of the thousands of crystal-laden pins, while the visitor enjoys the excellent food in the Diamond canteen (R22). I would especially recommend the jambalaya. Following data collection, the magic of data processing happens: the PanDDA method<\/a> is used to find partial occupancy in the density, which is processed semi-automatedly and most open targets are uploaded in the Fragalysis web app<\/a> allowing the ligand binding to be studied and further compounds elaborated. This collection of targets bound to hundreds of small molecules is a true treasure trove of data as many have yet to be deposited in the PDB, making it a perfect test set for algorithm design: fragments are notorious fickle to model and deep learning models cannot cheat by remembering these from the protein database.<\/p>\n\n\n\n\n\n\n\n

API<\/h2>\n\n\n\n

This is not a guide to using Fragalysis programmatically, but simply a guide to downloading all the data<\/strong>.<\/p>\n\n\n\n

The API root in Fragalysis is https:\/\/fragalysis.diamond.ac.uk\/api\/<\/a>.
Interactions with the Fragalysis database are via Django and thanks to Swagger (now OpenAPI) definitions the endpoints are auto-documented as HTML when viewed in a browser (which does a GET<\/code> request with content-type<\/code> set as application\/xml<\/code> in the header<\/code>). The JSON responses follow the paginated response convention of a dictionary of count<\/code>, next<\/code>, previous<\/code> and results<\/code>, where the latter is a list of entries requested.<\/p>\n\n\n\n

There was<\/em> a Python SDK to access fragalysis<\/a> that was called Fragalysis-API. It was a tad clunky due to its all-in-one nature \u2014backend and frontend, deposition and retrieval. So I (Matteo) had made a simpler SDK<\/a>, but that may no longer functional in the future as something better will be made at some point. However, the principle is the same. Each target of \/targets<\/code> has an associated \/media<\/code> route (under the value value zip_archive<\/code><\/strong>), with all the files.<\/p>\n\n\n\n

import requests\nimport pandas as pd\n    \ndef retrieve_targets(url: str) -> pd.DataFrame:\n    response: requests.Response = requests.get(url)\n    response.raise_for_status() # beware this only raises for non 200 codes,\n    # ... i.e. 404 or 503, whereas permissions errors might not present the typical response status\n    paginated_response: dict = response.json()\n    assert 'error' not in paginated_response, paginated_response\n    return pd.DataFrame(paginated_response['results'])<\/pre>\n\n\n\n
There are URLs:<\/p>\n\n\n\n