Knowledge graphs & research KM patterns — starter design

Why a research knowledge graph?

Research groups lose time when insights, methods, and data are isolated in files, papers, or people’s heads. A lightweight knowledge graph links publications, datasets, experiments, people, protocols, and instruments so you can answer questions like “who used this protocol?”, “which datasets support that claim?”, or “what experiments referenced this reagent?”

Design goals

• Make assets discoverable across projects, teams, and tools.
• Preserve provenance so claims and lineage are auditable and reproducible.
• Use stable identifiers that interoperate with external systems (DOI, ORCID) and internal registries (sample IDs, instrument IDs).
• Be incrementally adoptable: start small, scale to more node types and integrations.

Core entity types and suggested properties

These are minimal starter properties — adapt to your domain and systems.

• Publication: title, authors, DOI, venue, pub_date, abstract, version, related_experiments.
• Dataset: title, dataset_id (DOI or internal), description, schema_summary, checksum, storage_location, generated_by_experiment.
• Experiment: experiment_id, title, start_date, end_date, protocol_id, datasets_generated, responsible_people, status, lab_location.
• Person: name, ORCID, affiliation, roles (PI, technician), contact, expertise_tags.
• Protocol: protocol_id, title, version, steps_summary, reagents_list, equipment_required, linked_documents.
• Instrument / Resource: instrument_id, model, serial, maintenance_records, location.
• Sample / Specimen: sample_id, biosource, collection_date, storage_conditions, aliquot_relationships.

Relationship patterns (examples)

• (Person)-[:AUTHORED]->(Publication)
• (Experiment)-[:GENERATED]->(Dataset)
• (Experiment)-[:USED_PROTOCOL]->(Protocol)
• (Dataset)-[:USED_IN]->(Experiment)
• (Publication)-[:CITES|REFERENCES]->(Publication)
• (Dataset)-[:DERIVED_FROM]->(Dataset)
• (Sample)-[:PART_OF]->(Experiment)
• (Instrument)-[:USED_IN]->(Experiment)

Provenance: capture what matters

Provenance is essential to trust and reuse. Track:

• who (agent) performed or recorded an action (person, group, service)
• what (entity) was created, modified, or used (data, sample, protocol)
• when (timestamp) the event happened
• how (activity) including protocol version, instrument settings, software versions
• source (source_document or external_identifier) and versioning

Consider adopting W3C PROV concepts (entity, activity, agent) to structure provenance fields.

Identifier strategy

Use resolvable, stable identifiers when possible. Examples and guidance:

• Publications: DOI
• People: ORCID
• Datasets: DOI (DataCite) or internal persistent IDs with resolver
• Experiments / Samples / Instruments: UUIDs or prefixed local IDs (e.g., LAB123:EXP:00045) and map them to global IDs when available
• Protocols: persistent protocol IDs and versioning (protocol_v1, protocol_v2)

Record both the canonical external identifier (when present) and any local identifiers to avoid ambiguity during migrations and integrations.

Search & discovery integration

Make the graph useful via two complementary surfaces:

1. Full-text & faceted search: index key text fields (titles, abstracts, tags) plus structured facets (entity type, date range, authors, instrument). Allow filtering results by provenance (e.g., only datasets from experiments with protocol v2).
2. Graph exploration: provide a graph browser to traverse relationships (e.g., show which datasets a person produced, which publications cite those datasets, and which protocols were used).

Integrations: connect the graph to your KMS, LIMS, ELN, dashboards, and catalogues so entries created in those systems automatically surface in searches and graph views.

Starter queries and use-cases

Example search questions the graph should answer:

• Which experiments used protocol X version Y?
• Which datasets were generated by experiments supervised by Dr. Z?
• Find publications that reference a given dataset or sample.

Example Cypher-like pattern (illustrative):

(Person)-[:AUTHORED]->(Publication)
(Experiment)-[:GENERATED]->(Dataset)
MATCH (p:Person {name: 'Dr Z'})-[:RESPONSIBLE_FOR]->(e:Experiment)-[:GENERATED]->(d:Dataset) RETURN e,d

Governance, curation, and onboarding

• Define ownership for entity types (who can add/approve protocol versions, who curates sample registries).
• Set minimal required metadata for ingestion (e.g., every dataset must have checksum, storage_location, and dataset_id).
• Provide templates and intake forms for adding new experiments, datasets, and protocols to keep records consistent.
• Document typical workflows so new staff can find prior experiments, reproduce analyses, and avoid reinventing work.

Implementation checklist (pilot to scale)

1. Choose a storage model (property graph like Neo4j or RDF triple store) based on existing skills and integrations.
2. Pilot with a limited scope: one lab, a subset of entity types (Publication, Experiment, Dataset, Person, Protocol).
3. Create ingestion scripts or forms to capture metadata from ELN, LIMS, and publication feeds (Crossref, DataCite).
4. Implement a basic search UI with facets and a simple graph explorer for the pilot users.
5. Collect feedback, refine taxonomies, expand entity types, and add provenance depth as needed.

Risks and common pitfalls

• Trying to model everything at once — prefer incremental rollout.
• Poor or inconsistent identifiers — hammer out mapping rules early.
• Ignoring governance — without ownership, data quality degrades.

Next steps

1. Create a one-page entity schema and identifier policy for your pilot group.
2. Build a small sample graph with 10–50 nodes and use it to validate common queries and UIs.
3. Define minimal ingestion workflows from your ELN/LIMS and a policy for capturing provenance.

This starter design preserves the original intent while adding concrete entity schemas, relationship patterns, provenance guidance, search-integration points, implementation steps, and governance notes to make the graph practical and adoptable.