Knowledge Graph & Research KM Pattern Catalog

Purpose

This pattern catalog shows practical graph patterns, canonical entity schemas, common queries, and integration ideas you can use to make research knowledge discoverable, reusable, and auditable across projects, labs, ELNs, LIMS, and knowledge-management systems (KMS).

Why a knowledge graph for research KM?

Research work often spans experiments, samples, protocols, datasets, instruments, analyses, and people. A knowledge graph lets you represent these items as connected entities instead of isolated documents. That connectivity makes it easier to:

• Find related experiments and reuse protocols.
• Trace dataset provenance and reproduce results.
• Answer cross-project questions (e.g., which protocols produced datasets of a given quality?).
• Index and enrich unstructured notes by linking them to canonical entities.

Canonical entities & suggested attributes

Start with a small, stable set of entity types and key properties. Below are pragmatic starting schemas; adapt them to your domain.

Experiment

• id (stable URI)
• title, description, hypothesis
• startDate, endDate, status
• protocolRef (link to Protocol)
• sampleRefs (links to Sample)
• datasetRefs (links to Dataset)
• ownerRef (Researcher)

Sample

• id, sampleType, source, collectionDate
• preparationMethod, storageLocation
• derivedFrom (link to parent sample)

Protocol

• id, title, version
• steps (structured or linked content)
• inputs (materials, instruments)
• owners, approvalStatus

Dataset

• id (URI), title, format, size
• checksum, storageLocation
• derivedFrom (Experiment, Sample), analysisRefs

Researcher (Person)

• id (ORCID preferred), name, role, contact
• affiliation, projects

Instrument / Result / Publication / Project

Include lightweight versions of these where useful. Keep schemas focused on discoverability and linking.

Small JSON-LD example (how entities link)

{
  "@context": {
    "ex": "http://example.org/",
    "schema": "http://schema.org/"
  },
  "@id": "http://example.org/experiment/EXP-001",
  "@type": "ex:Experiment",
  "schema:name": "Cell growth under condition X",
  "ex:hasProtocol": { "@id": "http://example.org/protocol/PROTO-21" },
  "ex:hasSample": [ { "@id": "http://example.org/sample/SMP-42" } ],
  "ex:hasDataset": [ { "@id": "http://example.org/dataset/DS-9001" } ],
  "schema:author": { "@id": "https://orcid.org/0000-0002-XXXX-XXXX" }
}

Common queries & use-cases

Below are practical examples you can run against a graph store (SPARQL) or property graph (Cypher). Use them to build search UIs, dashboards, and audits.

Find all experiments by a researcher (SPARQL)

SELECT ?exp ?title WHERE {
  ?exp a ex:Experiment ; schema:author  ; schema:name ?title .
}

Find datasets derived from samples of type X (Cypher)

MATCH (s:Sample {sampleType: 'serum'})<-[:USES_SAMPLE]-(e:Experiment)-[:GENERATED]->(d:Dataset)
RETURN distinct d

Audit: protocols used across projects

Query which protocols and versions are in use and list experiments that reference outdated protocol versions — useful for quality and reproducibility checks.

Search & UI patterns

• Entity-centric pages: show an Experiment page that aggregates protocol, datasets, sample lineage, and related publications.
• Graph-based discovery UI: let users expand neighbor nodes (e.g., click a protocol to reveal all experiments using it).
• Faceted search: combine full-text indexing (KMS) with graph facets (sampleType, protocol version, owner).

Integration patterns with ELN / LIMS / KMS

Practical patterns that preserve source-of-truth while enabling graph linking:

1. Metadata push: ELN/LIMS emit canonical metadata records (as JSON-LD or minimal JSON) to a graph ingestion API; record the source and original URL so users can navigate back to the ELN entry.
2. Link-first pattern: Keep primary content in ELN/LIMS; store stable URIs and essential metadata in the graph to enable cross-system queries and discovery.
3. Event-driven sync: Use audit events (experiment created/updated) to update the graph incrementally rather than bulk loads.
4. Index enrichment: Use the graph to enrich KMS search results with linked entities, improving relevance and surfacing hidden connections.

Governance & practical conventions

• Use stable URIs for entities; include source system and identifier.
• Reuse established vocabularies where possible (PROV-O for provenance, schema.org for people/publications, DCAT for datasets). Consider domain ontologies relevant to your discipline.
• Capture version and approval status for protocols.
• Log provenance: who added the link, when, and from which system.
• Define access control: graph nodes may reference sensitive data; don't expose storageLocation or raw links unless authorization permits it.

Adoption checklist (minimum viable graph)

1. Map 5–10 key entity types and required fields with your team.
2. Create stable ID/URI conventions and a minimal context (JSON-LD context or property map).
3. Ingest a pilot dataset from an ELN or LIMS (10–50 experiments) and build 3 representative queries.
4. Expose an entity page and one graph-driven discovery view for users to test.
5. Iterate schema, add provenance, and identify integration gaps.

Common pitfalls to avoid

• Trying to model everything up-front—start small and evolve the ontology.
• Tightly coupling the graph schema to a single ELN's internal model—prefer stable, minimal crosswalks.
• Omitting provenance and versioning; they are essential for reproducibility.

Next steps & resources

Recommended next steps: prototype a small graph; add a search UI that combines full-text and graph facets; run a reproducibility query that traces dataset provenance back to raw samples and protocol versions.

Ontologies and standards to consider: PROV-O, schema.org, DCAT, OBO Foundry ontologies (discipline dependent), and any ELN/LIMS export schemas your vendors provide.

How this catalog can grow

This reference is intentionally pragmatic—your team can extend it with concrete schema files (JSON-LD contexts), SPARQL/Cypher query libraries, ingestion templates for specific ELNs/LIMS, and interactive templates for creating entity records. Consider packaging these as a reusable domain or toolkit so other teams can acquire and tailor them.