SCHOLARLY KNOWLEDGE GRAPH · RESEARCH KNOWLEDGE GRAPH · OPENALEX · OPENAIRE GRAPH · ORKG · SEMANTIC SCHOLAR · DOI · ORCID · ROR · SEMANTIC SEARCH · GRAPHRAG · AI RESEARCH RETRIEVAL

How Scholarly Knowledge Graphs Work

Scholarly knowledge graphs and research knowledge graphs are becoming core infrastructure for modern research discovery because the scholarly record is no longer usefully understood as a shelf of independent documents. OpenAlex, the OpenAIRE Graph, the Open Research Knowledge Graph (ORKG), Semantic Scholar, Crossref, DataCite, OpenCitations, DOI, ORCID and ROR all participate in a larger movement toward connected scholarly metadata: works linked to authors, organisations, funders, projects, datasets, software, citations, topics, versions, corrections and evidence. The practical goal is not fashionable graph technology. It is to make research identity, research discovery, citation networks, semantic search, provenance and AI research retrieval more accurate, inspectable and reusable.

A scholarly knowledge graph represents research as entities and typed relationships rather than as isolated PDFs. A paper can be a node connected by authored by to an ORCID-identified researcher, by affiliated with to a ROR-identified organisation, by cites to earlier DOI-identified works, by funded by to a funder, by uses dataset to a DataCite DOI, by is version of to a preprint, and by corrected by or retracted by to a later publication state. Once those links are machine-readable, the system can support literature search, knowledge graph analytics, bibliometrics, systematic reviews, research assessment, semantic scholarly search, graph traversal, multi-hop reasoning and GraphRAG without pretending that a language model’s fluent answer is itself the evidence.

In 2026 the leading infrastructures already reveal different versions of this theory. OpenAlex describes itself as a connected map of the global research system, with more than 320 million works and over 120 million disambiguated authors in its current documentation. OpenAIRE Graph v11.4 connects roughly 390 million research products across publications, datasets, software and other outputs, with people, organisations, funders, grants and projects. ORKG goes deeper into semantic research contributions and comparisons rather than stopping at document-level metadata. Semantic Scholar exposes an academic graph of papers, authors, citations and embeddings. Together with Crossref, DataCite, ORCID, ROR and OpenCitations, these systems show the same strategic direction: scholarly communication is shifting from document retrieval toward an interconnected, provenance-aware knowledge graph that both people and AI systems can navigate.

A scholarly knowledge graph becomes valuable when it can answer not only “What papers mention this?” but also “What is connected, why is it connected, which version is current, where did the link come from, and can I return to the evidence?”

50-second router: where to enter this article

• I only want the concept: read Sections 1–12.
• I build research databases or repositories: read Sections 13–68 and 164–195.
• I use OpenAlex, OpenAIRE, ORKG or Semantic Scholar: read Sections 69–88.
• I care about literature search and bibliometrics: read Sections 89–113.
• I build AI research assistants or GraphRAG: read Sections 114–132.
• I care about provenance, corrections and trust: read Sections 133–163.
• I want applied design cases: read Sections 222–233.

The short answer

RESEARCH OBJECTS
  → IDENTIFY ENTITIES
  → NORMALISE METADATA
  → RESOLVE PEOPLE / ORGANISATIONS / WORKS
  → LINK WITH PERSISTENT IDENTIFIERS
  → ADD TYPED RELATIONSHIPS
  → PRESERVE PROVENANCE
  → DEDUPLICATE WITHOUT ERASING HISTORY
  → CLASSIFY TOPICS / METHODS / CLAIMS
  → VERSION THE GRAPH
  → INDEX FOR KEYWORD + VECTOR + GRAPH SEARCH
  → RETRIEVE EVIDENCE CHAINS
  → CHECK CURRENT STATUS / CORRECTIONS
  → ANSWER WITH SOURCE RETURN PATHS
  → FEEDBACK CORRECTIONS INTO THE GRAPH

Part I — What a scholarly knowledge graph actually is

1. The graph starts where the document model becomes insufficient

The conventional scholarly unit is the document: article, book, chapter, report, thesis, dataset record or conference paper. Documents remain essential because they carry complete arguments, methods, tables, figures and rhetorical context. The problem is that most research questions do not stop at one document. A researcher wants to know which papers share a method, which datasets support which claims, whether two authors with similar names are the same person, which studies come from the same trial, what later work contradicted an earlier finding, which institution produced the evidence, and whether the cited paper was subsequently corrected.

A document database can answer some of these questions by adding fields and indexes. A knowledge graph makes the relationships themselves first-class objects. That shift matters because the edges often carry as much meaning as the nodes. “Paper A” is not only a title and abstract. It is authored by people, published in a venue, affiliated with organisations, funded by grants, cites prior work, uses data, extends methods and may later be corrected by another object. The graph is a model of these relationships, not a replacement for the underlying publications.

2. A node is an entity the system has decided to treat as identifiable

Typical scholarly graph nodes include works, people, organisations, sources or venues, publishers, funders, grants, research projects, datasets, software, instruments, samples, topics, concepts, methods and claims. The exact node types depend on the graph’s purpose. OpenAlex focuses heavily on entities needed to map the research system at large scale. OpenAIRE connects research products to projects, organisations and funding. ORKG focuses more explicitly on structured research contributions that make papers comparable. A domain graph in biomedicine may include genes, diseases and compounds. A materials-science graph may include materials, properties and synthesis conditions.

The first design question is therefore not “Which graph database should we use?” It is “Which things must remain distinguishable for the reader job we are trying to perform?” If a graph is built for author disambiguation, people and affiliations matter enormously. If it is built for evidence synthesis, study identity, interventions, outcomes and effect estimates may matter more. If it is built for research administration, projects, funders, organisations and outputs become central. Good graph design starts with entity boundaries before software.

3. An edge is a claim about a relationship

An edge can say that one work cites another, that a person authored a work, that a person was affiliated with an institution, that a dataset is used by a paper, or that one version supersedes another. Even the apparently simple edge authored by carries a claim that can be wrong. A name can be misparsed. An author profile can be overmerged. A contribution can be attributed to the wrong person. The edge therefore deserves provenance: where did the relationship come from, when was it observed, which source asserted it and how confident is the system?

This is one of the deepest differences between a toy graph and a scholarly graph. In a toy graph, edges are facts because the developer typed them. In a real scholarly graph, many edges are deposited, extracted, inferred, matched, enriched or corrected over time. Some are directly asserted by publishers. Some are imported from authoritative registries. Some are generated by machine learning. Some are derived from full text. A trustworthy graph records enough origin to distinguish these evidence classes.

4. Typed relationships turn a network into knowledge

A plain network can say that A is connected to B. A knowledge graph should say how. “Cites” differs from “is version of”; “affiliated with” differs from “funded by”; “uses dataset” differs from “is derived from”; “corrected by” differs from “retracted by”. Typed edges let people and machines interpret direction, meaning and consequences.

The type also determines valid reasoning. If Paper A cites Paper B and Paper B cites Paper C, it does not follow that A directly cites C. If Dataset D is version of Dataset C, users may legitimately traverse from one to the other when seeking lineage. If Article X is retracted by Notice Y, retrieval systems should propagate that status differently from an ordinary citation. Graph reasoning is therefore governed by relation semantics, not merely by connectivity.

5. The simplest representation is a triple

SUBJECT        PREDICATE          OBJECT
Paper A        authoredBy         Researcher B
Researcher B   affiliatedWith     University C
Paper A        cites              Paper D
Paper A        usesDataset        Dataset E
Dataset E      isVersionOf        Dataset F

This subject–predicate–object form is easy to understand and underlies RDF-style knowledge representation. It makes relationships explicit and portable. But real scholarly systems often need more than three fields. A relationship may have a date, source, confidence score, evidence document, role, sequence, temporal interval or correction state. This can be represented through richer RDF patterns, named graphs, reification, edge properties in a property graph, or a separate provenance model.

The engineering representation is less important than the semantic discipline. If the system cannot tell whether an edge was publisher-deposited, model-inferred or manually curated, the graph may be convenient to query while remaining unsafe to trust.

6. A property graph and an RDF graph solve overlapping problems differently

Property graphs typically model nodes and relationships that can both carry properties. They fit graph databases and traversal languages such as Cypher naturally. RDF represents knowledge as triples and is closely associated with linked data, semantic-web standards and SPARQL. Both can represent scholarly knowledge. Neither is automatically more truthful.

The choice depends on interoperability, query style, ontology requirements, graph scale and existing infrastructure. A public scholarly infrastructure may value standards-based linked data because independent systems need to exchange meaning. An internal research product may prefer a property graph for efficient traversal and developer familiarity. Some systems maintain one canonical representation and derive another for specific applications. The design test is not ideology; it is whether identity, semantics, provenance, updates and export remain reliable.

7. An ontology says what kinds of things and relations the graph understands

An ontology or schema defines the conceptual grammar. Can a Person author a Work? Can an Organisation fund a Project? Can a Dataset support a Claim? Can a CorrectionNotice update an Article? Which relation types are reciprocal? Which entities can have temporal boundaries? Which identifiers are valid?

Without such rules, the graph becomes a bag of ad hoc predicates. One source says memberOf, another says affiliatedWith, another says institution, and a fourth encodes the same idea as an untyped string. Ontology work is the unglamorous discipline that makes cross-source meaning possible. It also determines what the graph cannot represent. A schema designed only for publications and authors will struggle to express experimental protocols, evidence claims or causal relationships later.

8. Schema breadth and semantic depth trade against one another

Large scholarly graphs can cover hundreds of millions of documents when they focus on relatively stable entities and relations: works, authors, venues, affiliations, funders, topics and citations. Deep semantic graphs that extract research questions, methods, populations, variables, measurements and findings are much harder to build consistently at that scale.

A 2026 systematic review of scholarly knowledge graphs described this as a breadth–depth problem: inter-paper graphs excel at mapping relationships among papers, while intra-paper graphs attempt to represent the rich semantic structure inside papers. The most promising direction is hybrid and multi-granular. In practical terms, the graph should be broad enough to navigate the scholarly world and deep enough, where needed, to compare the scientific content rather than merely the bibliographic shells.

9. Inter-paper graphs map the scholarly ecosystem

An inter-paper graph connects publications through citations, shared authors, institutions, venues, topics, funders and other metadata. OpenAlex, OpenAIRE, Semantic Scholar and OpenCitations all support important parts of this layer. These graphs are powerful for discovery, bibliometrics, field mapping, author networks, institution analysis and citation traversal.

Their limitation is that they can know a great deal about the fact that Paper A and Paper B are related while knowing little about the precise scientific claim on which they disagree. A citation edge does not encode whether the citing paper supports, disputes, extends or merely mentions the cited paper. Topic similarity does not encode method differences. Document-level graphs create extraordinary navigation but only partial scientific semantics.

10. Intra-paper graphs attempt to represent the science inside the paper

An intra-paper graph can represent research questions, hypotheses, methods, materials, populations, interventions, variables, outcomes, effect estimates and conclusions. This is where ORKG’s philosophy becomes especially interesting: comparisons can organise structured research contributions around a research problem so papers can be compared property by property rather than only ranked as search results.

The challenge is extraction quality. Scientific language is nuanced. Methods are distributed across sections and supplements. One sentence can contain qualifiers that reverse a claim. Numerical results depend on units, denominators and statistical context. Deep semantic extraction therefore needs domain schemas, evidence spans, confidence and human correction. It can be transformative, but it must not turn a probabilistic extraction into an unqualified fact.

11. A scholarly knowledge graph is not a knowledge base of eternal truths

Science changes. Publications conflict. Findings fail to replicate. Definitions shift. Organisations merge. Author profiles are corrected. Articles are retracted. Datasets receive new versions. A graph representing scholarship should therefore preserve disagreement and history rather than attempting to collapse everything into one current answer.

The right mental model is an evidence graph, not a truth table. Nodes and relations should tell us who asserted what, when, in which publication state, with what method and from which source. A downstream system can then evaluate reliability for a particular task. If the graph tries to decide once and for all that “X causes Y”, it silently takes on the hardest epistemic problem in science. Better infrastructure keeps the claims and their evidence distinguishable.

12. The central proposition: graphs manufacture navigable continuity

The scholarly record is full of variance: name variants, duplicate records, changing URLs, different versions, conflicting vocabularies and distributed repositories. A well-governed knowledge graph constrains that variance by keeping identities stable and relationships explicit.

This is why graph infrastructure matters beyond computer science. It manufactures a more reliable future state of the record. A researcher searching five years later should still be able to find the work, distinguish the author, recognise the institution, trace the dataset, see the correction and understand which version was used. That continuity is the product.

Part II — Identity: the floor under the graph

13. Graph quality begins with persistent identity

Every graph edge assumes its endpoints are correctly identified. If “J. Lee” is attached to the wrong person, authorship, affiliation, citation and institutional metrics can all become corrupted. If a journal article and its preprint are treated as two independent studies, a systematic review can double-count evidence. If two institution names are incorrectly merged, national or institutional research analyses become distorted.

Persistent identifiers reduce this ambiguity. DOI identifies research objects within the DOI infrastructure. ORCID identifies researchers. ROR identifies research organisations. DataCite and Crossref carry many of these identifiers through scholarly metadata. The graph still needs reconciliation when identifiers are missing, but PID coverage changes identity resolution from pure inference to evidence-backed matching.

14. DOI gives works stable identity across moving locations

A DOI is not merely a convenient link. It separates object identity from the current URL. Publishers can migrate platforms, repositories can change hosts, and landing pages can move while the DOI remains the stable reference.

For knowledge graphs, DOI is a powerful join key. Crossref, DataCite, OpenAlex, OpenAIRE, OpenCitations and many other systems use DOI to reconcile records that originated independently. DOI does not guarantee quality or peer review. It solves a narrower but foundational problem: which object are we talking about?

15. ORCID makes person identity explicit

Names are poor primary keys. Researchers publish with initials, diacritics, transliterations, surname changes and inconsistent middle names. Common names can belong to thousands of people. ORCID gives a researcher a persistent identifier that can travel through submission, funding, institutional and repository workflows.

In a scholarly graph, authenticated ORCID links are stronger identity evidence than name similarity alone. The best systems still preserve provenance: whether the ORCID came directly from an authenticated workflow, a publisher deposit, a registry record or an enrichment algorithm. “Has an ORCID-looking string” and “the person authenticated this ORCID” are not equivalent trust states.

16. ROR turns organisations into resolvable entities

Institution names are even messier than person names. Universities appear as acronyms, translated names, departments, hospitals, institutes and parent organisations. ROR provides open, community-curated persistent identifiers for organisations involved in research and funding, with metadata that can be reused under CC0.

In September 2026, Crossref began matching funder names in deposited metadata to ROR IDs when an identifier was missing. That current example shows what graph enrichment really means: a free-text organisation string becomes a typed link to a governed entity. Crossref’s published evaluation of the matching strategy reported very high precision but lower recall, a reminder that enrichment should prefer leaving some strings unmatched over confidently attaching the wrong organisation.

17. Platform IDs and community PIDs should not be confused

OpenAlex assigns its own IDs to works, authors, sources and institutions because it needs stable internal graph entities even when no external PID exists. Its current documentation explicitly describes these as native entities containing OpenAlex judgement about real-world boundaries. Institutions, however, are grounded in ROR.

This distinction matters. An OpenAlex author ID is a platform-level identity produced through disambiguation. An ORCID iD is a researcher identifier maintained through the ORCID ecosystem. They can and should be linked, but they are not interchangeable evidence. A robust graph can hold both: one for the platform entity, one for the authoritative external identity where available.

18. Missing PIDs turn entity resolution into probabilistic inference

When a record lacks ORCID, DOI or ROR, systems rely on combinations of names, titles, co-authors, affiliations, dates, topics, references and other signals. OpenAlex’s author disambiguation, for example, weighs name, co-author, affiliation, topic, citation and ORCID evidence.

This can work remarkably well at scale, but the graph should remember that the identity was inferred. Confidence, correction workflows and merge/split history matter. A platform that exposes one clean author profile while hiding the probability and correction path risks turning convenience into false certainty.

19. Overmerging and undermerging are opposite identity failures

Overmerge means records from different real-world entities are combined. Two researchers named Wei Zhang become one profile. Undermerge means one real-world entity is split across multiple profiles. Neither error is harmless.

Overmerge contaminates a profile with work that does not belong. Undermerge fragments credit and makes collaboration or impact look smaller. The preferred error direction can depend on the use case. For high-stakes attribution, conservative matching may be safer. For exploratory discovery, broader clustering may be acceptable if uncertainty remains visible. One global threshold cannot serve every task.

20. Work deduplication is not merely duplicate deletion

Open scholarly graphs ingest the same publication from Crossref, PubMed, repositories, publisher sites and other sources. Deduplication decides whether those records describe one scholarly work or several.

The difficult cases are legitimate versions. A preprint, accepted manuscript, version of record and corrected version may share title and authors while representing distinct publication states. The graph needs a model that can say “these records belong to one conceptual research contribution” while preserving their different identities, dates and trust states. Blind deduplication destroys version history; no deduplication inflates counts and fragments metadata.

21. OpenAIRE shows why graph versioning must include deduplication logic

OpenAIRE’s 2026 changelog is unusually instructive because it treats graph construction as a versioned pipeline. In v11.4 it introduced group-split conditions to prevent certain repository records from being incorrectly merged into duplicate groups and improved project-product relation mapping when DOI identifiers were involved.

That is not cosmetic maintenance. Changing deduplication changes graph topology. Node counts, relationships, project outputs and downstream statistics can all move. A research graph should therefore version not only data snapshots but the logic that produces them.

22. Organisation history is temporal identity

Institutions rename, merge, split and close. A paper published in 1998 should preserve the institution that existed in 1998 while allowing users to discover the current successor.

This requires temporal and lineage relationships rather than rewriting the past. ROR is useful precisely because it treats organisation curation as a continuing process. A graph that simply replaces all historical labels with the latest organisation name may improve present-day aggregation while falsifying historical affiliation.

23. People also have temporal relationships

A researcher can move from NUS to NTU to another institution. Affiliations belong to time intervals or publication events, not to the person forever. OpenAlex’s author profiles derive affiliation histories from the author’s works, which is useful but also reveals a model assumption: the profile reflects observed publication affiliations rather than an employment registry.

When graphs answer “Where does this researcher work?” they should distinguish “affiliated on recent publications”, “current verified employment” and “historical affiliation”. A simple edge without time or provenance collapses these meanings.

24. Topics are also model outputs, not eternal identities

OpenAlex currently uses a hierarchy of domains, fields, subfields and roughly 4,500 topics, with topic assignments inferred by machine learning from work text. That makes topics useful graph entities, but they are categorisation outputs rather than author-declared facts.

Topic models change as taxonomies, embeddings and classification pipelines improve. A graph should preserve the version of the classifier or taxonomy when topic membership affects evaluation. Otherwise a researcher’s historical topic profile may appear to change even though the underlying works did not.

25. Identity resolution should be reversible

Every merge decision should have a path to correction. If two author profiles were combined incorrectly, the system should be able to split them. If a funder name was matched to the wrong ROR record, the enrichment layer should be replaceable. Crossref’s September 2026 funder-matching rollout explicitly notes the importance of being able to remove or replace incorrect matches.

Reversibility is a core trust property. Machine learning can scale matching, but irreversible inference turns model errors into institutional facts. The graph should remember how an entity was formed well enough to unwind a bad decision.

Part III — Relations: turning records into a research network

26. Authorship is a relation with order and role

“Author A wrote Paper B” sounds simple until large-team science appears. Author order can carry field-specific meaning. Consortium authorship can involve thousands of contributors. CRediT roles may distinguish conceptualisation, software, data curation, supervision and writing. Corresponding-author status can matter operationally.

A knowledge graph can preserve richer authorship than a plain many-to-many table: position, corresponding status, ORCID, institutional affiliation at publication time and contribution roles. This becomes valuable for responsible research assessment because publication count alone cannot represent who actually did what.

27. Citation edges are abundant and semantically thin

A citation edge says one work references another. It usually does not say why. The citing work may rely on the method, disagree with the result, mention historical context or criticise the earlier paper.

OpenCitations’ July 2026 open index contains more than 2.5 billion citation links, illustrating the extraordinary scale available for graph analysis. Yet the relation remains semantically thin unless context is added. Citation-context extraction and citation-intent classification can enrich the edge, but those are additional modelled claims that need provenance and confidence.

28. Funding edges connect science to its resource history

Funding acknowledgements let graphs connect papers and datasets to grants and funders. This supports funder reporting, portfolio analysis, conflict transparency and research-policy studies.

The hard part is normalisation. Funder names are messy, multilingual and inconsistently entered. Crossref’s move toward ROR matching is important because an identifier transforms “National Research Foundation Singapore”, an acronym or a variant into a resolvable organisation node. The graph can then aggregate outputs without fragile string matching.

29. Dataset relations make evidence chains inspectable

A paper may analyse a dataset deposited elsewhere. The dataset may itself derive from raw data or a prior version. If these links are expressed through persistent identifiers and typed relations, a reader can move from conclusion to underlying evidence.

DataCite’s PID Graph model is built around this idea: DOI metadata connect resources to other DOI-identified objects and outward to PIDs such as ORCID and ROR. The graph is not an optional visualisation; it is the accumulated result of connection metadata deposited across research workflows.

30. Software relations expose computational dependencies

Modern research can depend critically on software versions, packages and analysis pipelines. A paper may be reproducible only with a specific code release. Treating software as a first-class research object allows the graph to capture uses software, is documented by, is version of and produces dataset relations.

This is where document-only scholarly databases become insufficient. The scientific result may be distributed across paper, repository, code, environment and data. A knowledge graph can keep the pieces connected without pretending they are one file.

31. Project relations capture the activity behind outputs

Research outputs are produced by activities that span time. Projects involve people, organisations, grants, instruments, datasets and publications. OpenAIRE makes funded projects important graph entities. RAiD and other project-identity initiatives attempt to give research activities stable identifiers.

The project node helps answer questions a paper-centric graph cannot: Which outputs came from this programme? Which people collaborated across the project? Which datasets were created before the final article? What happened to the project after funding ended? Research is an activity system before it is a publication list.

32. Version relations preserve scholarly chronology

Preprints, accepted manuscripts and versions of record can coexist. Corrections and updated datasets add further states. A graph should link these explicitly so users do not count them as independent evidence or retrieve an outdated version unknowingly.

Version relations also support time-aware AI retrieval. A model should not merge conclusions from version 1 and version 3 into a synthetic paper that never existed. It should know which state it used and whether a later state superseded it.

33. Correction and retraction edges are trust-critical

A retraction notice is not just another citing document. It changes the reliability state of the target article. A correction notice may update a figure or conclusion while preserving the rest of the work. Expressions of concern represent unresolved risk.

Knowledge graphs should model these relations with explicit semantics and high retrieval priority. A research assistant that retrieves a retracted article because its embedding is relevant but fails to traverse the retraction edge has performed technically impressive retrieval and epistemically poor research.

34. Topic relations provide aboutness, not proof

Topic edges let users explore fields, cluster literatures and filter results. They can be derived from controlled vocabularies, author keywords, journal classifications or machine-learning models.

Because the method matters, graphs should not treat every topic assignment as equivalent. A MeSH term manually or algorithmically assigned under NLM rules differs from an embedding-based topic prediction. Both can be useful. Provenance tells the user how much interpretive weight to place on the edge.

35. Semantic contribution relations go below the document level

To compare scientific results directly, graphs need relations such as uses method, studies population, measures outcome, reports effect and supports claim. ORKG comparisons point toward this deeper representation by organising contributions around research questions and comparable properties.

This is the frontier where knowledge-graph construction becomes knowledge extraction. The edge is no longer copied from bibliographic metadata; it is interpreted from scientific text. That increases both usefulness and epistemic risk. Every extracted relation should ideally retain the source passage that justifies it.

36. Evidence spans should be attached to deep semantic edges

If a graph asserts that a trial reported a 17% relative reduction in an outcome, the user should be able to return to the table, sentence or structured result from which that relation was extracted.

This creates an evidence receipt. It also allows correction when extraction is wrong. A semantic graph without evidence spans may be easy to query but difficult to audit. The deeper the graph goes into scientific claims, the more important the return path becomes.

37. Negative and contradictory relations deserve representation

Science is not a graph in which every edge expresses positive agreement. Studies fail to replicate. Methods disagree. Results differ by population. A graph designed only to accumulate supportive relations can manufacture false consensus.

Contradiction is not necessarily a binary edge either. Two studies may differ because of dose, measurement, sample, context or statistical power. Deep scholarly graphs should model comparison conditions, not simply label one paper “contradicts” another. This is another reason claim-level representation needs domain-specific semantics.

38. Temporal relations let the graph answer “when?”

Affiliations, project membership, funding periods, software versions and publication states all change through time. Temporal attributes or relations let the graph distinguish “was affiliated with” from “is currently affiliated with”.

Temporal modelling also prevents hindsight errors. A systematic review performed in 2022 should be able to reconstruct the evidence available in 2022, even if later corrections or publications changed the present graph. Current truth and historical state are different query modes.

39. Confidence belongs on inferred edges

A publisher-deposited DOI relation and an LLM-extracted claim relation should not carry identical epistemic status. Confidence can be represented numerically, categorically or through provenance classes.

The important design rule is that uncertainty must not disappear when data are rendered as a graph. A crisp line between two nodes can visually imply certainty even when the edge came from a model with 82% precision. Interfaces should communicate inferred, verified and disputed states differently.

40. Relation provenance can be more valuable than relation confidence

A single model confidence score can be hard to interpret across relation types. Provenance answers more concrete questions: Which source supplied this edge? Was it deposited by a publisher? Extracted from full text? Matched by Crossref? Curated by a human? Imported from ROR?

With provenance, downstream users can decide how much confidence is appropriate for their task. A bibliometric dashboard may accept automated affiliation matching. A legal or clinical decision may require direct source verification. The graph can support both if it preserves origin.

41. Edge direction is not a cosmetic choice

“A cites B” and “B is cited by A” describe the same relation from opposite directions, but query engines and data models need a canonical representation to avoid duplicate or inconsistent edges.

OpenAIRE’s 2026 graph cleanup illustrates why this matters: it removed redundant IsCitedBy relations in favour of direct Cites edges, changing billions of stored links without changing the underlying scholarly reality. Graph design is partly about choosing canonical directions that simplify traversal and maintenance.

42. High-degree nodes can distort traversal

Some authors, venues, topics and methods connect to enormous numbers of works. These hub nodes are useful but can dominate graph algorithms. A random walk can drift toward generic high-degree nodes instead of the evidence chain that answers the question.

This problem has become especially visible in GraphRAG research. Recent 2026 work describes a “static graph fallacy” in which query-independent transition weights can send retrieval toward hubs before critical evidence is reached. The lesson applies beyond AI: graph centrality is not the same as relevance.

43. Graphs need relation governance, not merely relation volume

A graph with ten billion weakly defined edges can be less useful than a smaller graph with clear semantics, provenance and correction. Connection count is not graph quality.

Every relation family should answer four questions: What does the edge mean? Where did it come from? How can it be corrected? What reasoning is allowed over it? These four questions create the bridge from data integration to trustworthy knowledge infrastructure.

Part IV — How scholarly knowledge graphs are built

44. Graph construction is a pipeline, not a one-time import

Research data arrive continuously. Crossref deposits change. ORCID records update. ROR releases new organisation data. Journals publish new articles. Repositories expose new preprints. Retractions appear. A knowledge graph is therefore a living data pipeline.

A typical production architecture includes source acquisition, schema mapping, identifier normalisation, deduplication, entity resolution, relation building, topic or semantic enrichment, provenance attachment, quality validation, graph storage, search indexing, snapshot publication and incremental updates. Each stage can introduce errors. Treating the graph as a single database hides where quality actually lives.

45. Source selection determines the graph’s universe

OpenAlex draws from Crossref, DataCite, PubMed, repositories and other feeds. OpenAIRE aggregates trusted research sources including journal, repository, PID and open-science infrastructures. Semantic Scholar has its own ingestion and enrichment pipeline. Domain graphs may depend on curated disciplinary repositories.

The graph cannot represent what its sources never see. Coverage choices shape language, geography, disciplines, document types and publication models. A builder should publish a source inventory and coverage statement so users understand the boundary of the graph before interpreting absence as nonexistence.

46. Source authority is relation-specific

No single source is authoritative for everything. ORCID is strong for researcher identity. ROR is strong for organisation identity. Crossref and DataCite are strong for registered DOI metadata. Publishers are strong for article titles and current publication status. Repositories may be strong for open full-text locations.

A robust graph uses field-level source precedence rather than a simplistic source ranking. The “best source” for a DOI title may not be the best source for an author’s current affiliation. Data integration should reflect ownership of facts.

47. Ingestion should preserve the original record

Before normalising a source record, retain enough of the original to audit later transformations. If a publisher supplied “National Univ. Singapore” and the graph maps it to a ROR ID, the original string should remain recoverable.

This raw layer is essential when matching algorithms change. Without it, the graph cannot be rebuilt under improved logic. Provenance begins before cleaning.

48. Normalisation makes heterogeneous records comparable

Dates, names, identifiers, language codes, licence labels, work types and publication states arrive in different formats. Normalisation maps them into a common schema without erasing source-specific meaning.

The danger is over-normalisation. A graph that maps every “conference paper”, “proceedings article” and “extended abstract” to one generic type may simplify queries while hiding meaningful distinctions. The common schema should preserve enough original granularity to answer the intended research questions.

49. Identifier normalisation should happen early

DOIs appear as bare strings, URLs, upper-case variants and malformed references. ORCID and ROR can likewise appear with prefixes or formatting differences. Early canonicalisation reduces duplicate entities and improves matching.

Canonicalisation is not validation. A string can match DOI syntax and still point to the wrong work. The graph should resolve or verify identifiers against the appropriate infrastructure where accuracy matters.

50. Record linkage begins with strong keys and falls back to weak signals

A DOI match is often a strong signal that two records represent the same work. Without DOI, the system may compare title, author, year, journal, pages and abstract. The model can use fuzzy string similarity or machine learning.

The important operational design is tiered evidence. Strong PID match can produce high-confidence merge. Partial metadata match may produce candidate merge requiring more signals. Ambiguous cases should remain separate until confidence improves. Overmerge is harder to detect than undermerge because it silently contaminates a node.

51. Entity resolution should produce explanations

A useful matcher can explain why it linked two records: identical DOI; high title similarity; same authors; same year; same venue; consistent ORCID. This is more actionable than a black-box score of 0.93.

Explanations help curators review edge cases and help engineers diagnose model drift. They also make automated graph enrichment compatible with auditability: every consequential merge can return to the signals that justified it.

52. Deduplication needs negative evidence

Two records with the same title may still be distinct conference and journal versions. Two authors with the same name may work in different countries and topics. Entity resolution improves when it can use evidence that objects are not the same.

Negative signals include conflicting ORCID iDs, incompatible dates, mutually exclusive affiliations or clearly different abstracts. A mature matcher learns both what similarity means and what contradiction means.

53. Full-text mining adds relations unavailable in metadata

Bibliographic records usually do not contain the complete citation context, method details, dataset mentions or software dependencies. Full-text processing can extract additional relations.

OpenAIRE describes full-text mining and enrichment as part of its pipeline. OpenAlex can use open full text to help build citation information and other signals. The trade-off is availability: closed articles may not expose full text to the same pipeline, producing uneven semantic depth across the graph.

54. Citation extraction is both parsing and matching

First the system identifies references inside a document or deposited reference list. Then it attempts to match each reference to a known work. Citation graphs therefore inherit errors from both extraction and entity resolution.

A malformed reference can fail to match. An ambiguous title can match the wrong work. This is why citation count is not an elementary fact. It is the output of a graph-construction pipeline.

55. Topic classification is an enrichment layer

Text classifiers can assign works to topics, fields, SDGs, keywords or custom taxonomies. OpenAlex’s current system, for example, predicts topics from work text and aggregates those labels to authors, institutions and sources.

Classification expands discovery but should remain distinct from deposited metadata. An author’s declared keywords and a model-predicted topic are different evidence classes. Graph schemas should preserve that distinction.

56. Embeddings create a parallel semantic geometry

A vector embedding maps text into a numerical space where semantically similar documents are near one another. Semantic Scholar exposes SPECTER-family embeddings through its API; OpenAlex currently offers semantic search over work representations.

Vectors and graphs solve different problems. The vector can say two papers are semantically similar even when no explicit edge exists. The graph can say one paper cites another or uses its dataset even when their language differs. Modern research discovery increasingly combines both.

57. Semantic search is not the same as graph search

OpenAlex’s current semantic search embeds the title and abstract of works into a 1,024-dimensional vector space and retrieves works close to the query by cosine similarity. This is meaning-based retrieval, not graph traversal.

Graph search instead follows explicit relationships: authored by, cited by, affiliated with, funded by. A strong research tool may begin with semantic similarity and then expand through graph edges to recover related evidence. Mixing the two without distinguishing them makes system behaviour difficult to audit.

58. Relation extraction turns prose into graph edges

Deep scholarly graphs use named-entity recognition, relation extraction, table parsing and increasingly LLM-based information extraction to identify methods, materials, outcomes and claims.

The extraction model needs a target schema. Without one, generated relation labels proliferate uncontrollably. The system also needs evidence spans and validation because the model can hallucinate relations that sound plausible but are not supported by the source.

59. LLM extraction is powerful because scholarly text is structurally difficult

Scientific claims cross sentence boundaries, use domain terminology and often depend on tables or supplements. LLMs can interpret context more flexibly than rule-based systems.

The same flexibility creates risk. An LLM may normalise an ambiguous statement into an overconfident edge. A trustworthy pipeline should constrain output to a schema, require citations to source spans, validate units and entities, and route uncertain extractions for review.

60. Human curation should target the graph’s highest-value uncertainty

No large graph can be manually curated edge by edge. Human effort should focus on entities and relations where errors are consequential or where model confidence is low.

Active-learning strategies can surface ambiguous matches. Community correction can improve profiles. Domain experts can curate ontologies and gold-standard relations. The goal is not human versus machine; it is to spend human judgement where it changes graph reliability most.

61. Quality assurance should be built into each pipeline stage

Ingestion checks schema validity. Identifier checks measure PID coverage. Deduplication QA measures overmerge and undermerge. Entity-resolution QA measures precision and recall. Relation-extraction QA measures edge accuracy. Provenance QA checks whether every inferred edge has source evidence. Freshness QA checks update lag.

A single “graph accuracy” metric is too crude. The graph is a manufacturing pipeline with different defect classes.

62. Snapshotting makes large graphs reproducible

If a bibliometric study queries a live graph today and another team repeats it six months later, the underlying records may have changed. Reproducible research therefore benefits from dated graph snapshots.

OpenAlex provides downloadable snapshots and documents incremental updates. OpenAIRE version numbers its graph and pipeline. OpenCitations publishes dated data dumps. These practices turn a living graph into a citeable analytical state.

63. Incremental updates require stable internal identity

Rebuilding hundreds of millions of nodes from scratch every day is inefficient. Graph systems ingest new and changed records incrementally.

This only works if entity identity is stable enough to determine whether an incoming record updates an existing node, creates a new node or changes a relation. Stable IDs are therefore operational infrastructure for streaming graph maintenance.

64. Deletion and merge logs are part of graph history

Sometimes a platform discovers that two internal entities should be merged or that a record should no longer exist as an independent node. Downstream users need a way to update local copies.

OpenAlex’s snapshot documentation now includes deletion tracking for works. This kind of event log prevents external systems from accumulating orphaned identities after the canonical graph changes.

65. Graph construction needs lineage for derived fields

A citation count is derived from citation edges. An h-index is derived from a set of works and counts. An author’s topic profile is derived from linked works and topic assignments. These are not primitive fields.

When derived values are stored for speed, the graph should know which underlying records generated them and when they were last recomputed. Otherwise cached statistics can silently diverge from the current graph.

66. A graph release should publish what changed

OpenAIRE’s semantic versioning model is instructive: major versions correspond to data-model changes, minor versions to pipeline or major source changes, and patch versions to graph data updates.

A change log lets users decide whether an analytical result needs to be recomputed. A graph is infrastructure; infrastructure changes should have release notes.

67. Open licensing changes who can build on the graph

OpenAlex releases its data under CC0. ROR is CC0. Crossref exposes most deposited metadata for broad reuse. OpenAIRE makes graph data openly available. OpenCitations publishes open citation data.

Open licensing allows universities, startups, libraries and researchers to build alternative discovery tools, audit coverage and reproduce metrics. It also reduces single-vendor dependence. Openness does not guarantee neutrality or perfect data, but it makes the machinery more inspectable.

68. Closed graphs can still be useful but require stronger trust in the operator

Commercial scholarly databases can provide high-quality curation, proprietary full text, specialised metrics and service guarantees. The trade-off is that external researchers may not be able to inspect the complete data model, reproduce the graph or redistribute the underlying records.

The right question is not “open good, closed bad”. It is whether the graph’s governance, provenance and reproducibility are appropriate for the decision being made. High-stakes research assessment should know exactly which source universe and matching rules produced its numbers.

Part V — Four important graph philosophies: OpenAlex, OpenAIRE, ORKG and Semantic Scholar

69. OpenAlex is a map of the research system

OpenAlex’s current documentation describes works as the central entity connecting authors, sources, institutions, topics, funders and citations. As checked on 17 September 2026, its documentation reports roughly 327 million works, 127 million disambiguated authors, around 256,000 sources and about 136,000 institutions.

The scale makes OpenAlex useful for discovery, bibliometrics, institutional analysis and graph-based exploration. Its model is broad rather than deeply claim-semantic. It knows a great deal about who, where, when, topic and citation structure across the scholarly ecosystem.

70. OpenAlex is partly a graph of curated sources and partly a graph of inferred identities

Works arrive from Crossref, DataCite, PubMed, repositories and other sources. OpenAlex decides whether records match existing works, builds author profiles by disambiguation, maps affiliations to ROR-backed institutions and classifies works into topics.

This means OpenAlex is not a passive mirror. It is an active integration model. Its own IDs encode platform judgements about entity boundaries. That is a strength—without those judgements the graph would remain fragmented—but it also means downstream users should understand which fields are source facts and which are OpenAlex constructions.

71. OpenAlex is unusually transparent about how it is built

Its help centre documents work matching, author disambiguation, affiliation matching, topic assignment, citation building, repository ingestion and known limitations. This matters because graph users can reason about failure modes instead of treating API output as ground truth.

Transparency of the pipeline is itself a research feature. It lets meta-researchers distinguish “OpenAlex observed this field” from “OpenAlex inferred this entity”.

72. OpenAlex semantic search adds a vector layer above the graph

OpenAlex now supports semantic search that embeds a query and compares it against work representations. This is useful when terminology differs: a concept can be retrieved because its meaning is similar even if the exact words are absent.

Semantic search should be understood as another retrieval surface over the graph, not as a replacement for explicit relations. A query can find semantically similar papers; graph traversal can then move through citations, authors, institutions or funders to build an evidence neighbourhood.

73. OpenAIRE Graph is built around open-science context

The OpenAIRE Graph aggregates publications, datasets, software and other research products and links them to organisations, funders, funding streams, projects, communities and data sources. It is designed not only for discovery but also monitoring and assessment in the open-science ecosystem.

OpenAIRE explicitly frames the graph as a public and transparent good. That governance position shapes the design: provenance, interoperability, open APIs and connections to repositories are central, not optional exports.

74. OpenAIRE’s scale is now genuinely multi-object

OpenAIRE v11.4, released at the end of August 2026, reports roughly 390 million research products, including about 238 million publications, 108 million datasets, close to one million software records and more than 42 million other research products.

This mix matters. A graph with one hundred million datasets is not merely a paper index. It can represent research output beyond articles and connect open-science objects into the same discovery environment.

75. OpenAIRE’s new person nodes show graph models are evolving

In 2026 OpenAIRE added Persons as dedicated graph nodes, enabling direct exploration of researchers alongside their works, collaborations, affiliations and funded projects.

This is a useful example of schema evolution. Earlier author information can exist as attributes on research products; later the graph promotes people into first-class entities because new user jobs require traversing them directly.

76. OpenAIRE treats deduplication and enrichment as visible engineering

Its changelog documents relation cleanups, deduplication improvements, source refreshes and PID coverage. Users can see that the graph is a constructed release, not a timeless database.

This is the standard scholarly graphs should aspire to: if graph topology changes because the pipeline changed, the release should say so.

77. ORKG asks a deeper question: what did the papers actually contribute?

Bibliographic graphs help find papers. ORKG’s central idea is to structure scholarly contributions so researchers can compare works around a research question. Its comparison feature organises contributions in table-like views across comparable properties.

This moves the graph inside the document. Instead of only representing “Paper A cites Paper B”, the graph can represent that Paper A used Method M, Dataset D and Metric X and reported Result R. This makes literature synthesis more direct, but it also makes extraction and ontology quality much more demanding.

78. ORKG exposes the limits of PDF-centred science communication

A PDF is designed for human reading, not for comparing hundreds of experiments property by property. Scientists repeatedly extract the same information from prose into spreadsheets for reviews.

ORKG’s theory is that at least some of that knowledge should be represented in reusable structured form. The graph becomes a shared intermediate layer between individual papers and later synthesis.

79. Semantic Scholar combines graph retrieval with representation learning

Semantic Scholar’s Academic Graph API exposes paper and author data, citations, references, venues and SPECTER-family embeddings. This makes it useful not only as a search engine but as an API for graph and semantic applications.

The combination is important. Citation edges capture explicit scholarly relationships. Embeddings capture semantic similarity. A system can retrieve papers that are conceptually related even without direct citations, then use the citation graph to inspect intellectual ancestry and influence.

80. The four systems are complementary rather than interchangeable

System	Strongest mental model	Typical strength
OpenAlex	Map of the global research system	Broad entity graph, open APIs, bibliometrics, semantic search
OpenAIRE Graph	Open-science research graph	Outputs + projects + funders + repositories + monitoring
ORKG	Structured research contributions	Research questions, comparisons, semantic contribution structure
Semantic Scholar	AI-assisted scholarly discovery graph	Papers, authors, citations, semantic representations

A mature research tool may use several infrastructures. The important thing is not to merge their data blindly. Each graph has entity definitions, source policies and inference layers that should remain traceable.

Part VI — Crossref, DataCite, ROR and OpenCitations: the connective tissue

81. Crossref is a metadata nexus, not merely a DOI lookup service

Crossref’s REST API exposes metadata deposited by publishing members and trusted sources: titles, authors, dates, funding, licences, abstracts, ORCID iDs, ROR IDs and post-publication updates.

Because so many scholarly platforms reuse this metadata, Crossref acts as connective tissue across the graph ecosystem. One publisher deposit can feed discovery tools, bibliometric systems, library services and open scholarly graphs.

82. Crossref’s Research Nexus vision is explicitly graph-shaped

Crossref increasingly frames scholarly metadata as a network of connections among research outputs, people, organisations and funding. Its current funder-to-ROR matching work is a practical example.

The deeper lesson is that metadata can be enriched after initial publication. A graph is not limited to what the publisher knew or deposited on day one. Trusted enrichment layers can add missing identifiers while preserving provenance and correction.

83. DataCite’s PID Graph connects more than papers

DataCite DOI metadata commonly describe datasets, software, samples and other research resources. RelatedIdentifier, creator, contributor and organisation fields connect those resources to DOI, ORCID, ROR and other PIDs.

DataCite explicitly describes the resulting network as the PID Graph. This model is crucial because science increasingly depends on objects that traditional publication indexes treated as supplementary.

84. OpenCitations makes citation edges reusable as open infrastructure

OpenCitations publishes open bibliographic and citation data. Its July 2026 citation dump contains more than 2.5 billion citation links, while OpenCitations Meta contains bibliographic entities and provenance.

This decouples citation analysis from closed citation indexes. Researchers can build reproducible citation graphs, while still recognising that source coverage and matching quality differ across infrastructures.

85. ROR makes organisation edges interoperable

ROR’s data are CC0, community curated and designed for integration into scholarly infrastructure. Crossref, DataCite and ORCID support ROR IDs, making the organisation node portable across systems.

This is what interoperability looks like at graph scale: a ROR ID can mean the same organisation in a journal submission system, a DOI record, a repository and a bibliometric graph.

86. The graph gets stronger when identifiers are captured upstream

Asking an author to choose an organisation from a ROR-backed typeahead during manuscript submission is better than trying to infer the institution from free text years later.

Aries Editorial Manager added ROR support for funder identifiers in September 2026, showing how identity is moving earlier into publication workflows. Upstream capture reduces ambiguity downstream.

87. Metadata enrichment should never erase the deposited value

If Crossref matches an unstructured funder string to a ROR ID, the graph should retain both the original string and the added identifier with provenance.

This allows future correction and lets researchers analyse both publisher behaviour and enriched graph behaviour. Enrichment is an interpretation layer, not permission to rewrite source history.

88. Open scholarly graphs are becoming an ecosystem of graphs

There is no single global scholarly knowledge graph. Instead there are interoperating registries, metadata services, citation graphs, repositories, domain knowledge graphs and discovery engines.

The strategic opportunity is federation through persistent identifiers and open standards. A university does not need to copy all global knowledge into one proprietary database if it can resolve authoritative entities and relationships across services.

Part VII — Search, traversal and research discovery

89. Keyword search asks whether text matches a query

Traditional search finds terms in title, abstract, full text or metadata. It is excellent when vocabulary is known and exact phrasing matters.

Its limitation is vocabulary mismatch. A researcher can ask about “drug toxicity prediction” while relevant papers use “QSAR” or “computational toxicology”. Semantic search can bridge that language gap; graph search can bridge relationship gaps.

90. Semantic search asks which works mean something similar

Embedding-based retrieval represents text numerically and retrieves nearby works. It can find conceptually related material without exact keyword overlap.

The weakness is explainability. Semantic similarity does not tell the user which scholarly relation connects two papers. It can also return works that feel topically similar but are methodologically irrelevant. Semantic search is a candidate generator, not an evidence judgement.

91. Graph traversal asks what is connected by explicit relations

From one paper, traverse backward to references, forward to citing works, sideways to co-authors, outward to datasets, upward to institutions or funders, and through versions to the current publication state.

This is powerful because each move is interpretable. “Recommended because Paper A cites Paper B” is a clearer relation than “recommended because their vector embeddings are close”.

92. Hybrid retrieval combines lexical, vector and graph evidence

QUERY
  → KEYWORD SEARCH for exact terminology
  → SEMANTIC SEARCH for conceptual similarity
  → GRAPH EXPANSION for citations / authors / projects / data
  → FILTER by date / type / status / field
  → RERANK by query relevance
  → VERIFY provenance and publication state
  → RETURN evidence

Each layer repairs a weakness in another. Exact search protects names and phrases. Semantic search repairs vocabulary mismatch. Graph traversal repairs relation blindness. Status verification repairs stale trust.

93. Citation chaining is graph traversal humans already understand

Researchers have long used backward and forward citation searching. A knowledge graph makes this operation computationally explicit and scalable.

Graph traversal can extend citation chaining to datasets, software, projects and people. The intellectual practice is familiar; the infrastructure makes more relation types available.

94. Path queries answer multi-hop questions

Consider: “Which Singapore institutions produced open datasets associated with papers on battery materials funded by a particular programme?” A relational database can answer this with joins. A graph expresses it naturally as a path across organisations, works, topics, funders and datasets.

The graph advantage grows when users do not know in advance which intermediate entity types matter. Exploratory traversal can reveal the route while the query is being formed.

95. Shortest path is not necessarily best evidence path

Graph algorithms often optimise hop count. Research reasoning cares about provenance, relation type, time and reliability.

A two-hop path through a generic topic node may be less meaningful than a four-hop path through a shared dataset and method. Evidence-aware traversal should score paths semantically, not merely geometrically.

96. Centrality reveals structure, not truth

Degree centrality, PageRank and related measures identify nodes that occupy influential structural positions. They are useful for mapping fields and discovering hubs.

A central paper can be famous because it is foundational, controversial or repeatedly criticised. Graph importance is not methodological validity. The same warning applies to highly connected authors and institutions.

97. Community detection reveals intellectual neighbourhoods

Citation and co-authorship graphs can be partitioned into clusters that correspond roughly to research communities or themes.

Clusters are algorithmic constructs. Their boundaries depend on resolution parameters, edge weighting and graph coverage. A field can look more fragmented or more unified depending on the community-detection method.

98. Graph neighbourhoods can improve literature review recall

Once several eligible papers are known, a system can expand through shared citations, authors, datasets and semantic similarity to identify candidates missed by keyword search.

This should supplement, not secretly replace, a reproducible database strategy when the review claims systematic completeness. Graph discovery is powerful precisely because it adds routes beyond the original query.

99. Graph discovery can expose hidden families of reports from one study

One clinical study may generate a protocol, conference abstract, trial-registry record, primary publication and follow-up paper. Graph relations can help cluster these reports around one study or project.

This reduces double counting in evidence synthesis and makes research chronology easier to understand.

100. Researcher discovery becomes more precise with identity graphs

Searching for a common surname can produce thousands of false matches. ORCID and disambiguated author entities let tools retrieve a coherent body of work.

The graph can then answer richer questions: collaborators, institutions, topics, grants and datasets. People become traversable research entities rather than strings in bylines.

101. Organisation discovery becomes historically aware

A graph grounded in ROR and historical relations can aggregate work across name variants while preserving predecessor and successor organisations.

This matters for long-horizon institutional analysis. Without identity lineage, a university rename can look like a sudden birth of a new research institution.

102. Topic exploration should show the taxonomy and the evidence

A topic node can gather works, authors and institutions. Users should be able to see whether the topic came from an established taxonomy, a machine classifier or a user-defined collection.

Otherwise “papers about AI ethics” may hide a classification decision the user cannot evaluate.

103. Discovery should support graph-to-document return

A graph view is excellent for navigation, but the final evidence remains in documents, datasets and other research objects.

Every discovery interface should make it easy to return from node or edge to the canonical object. The graph is a map; the map should not become a substitute for reading the terrain.

104. Discovery should also support document-to-graph expansion

From any article, the reader should be able to open the surrounding neighbourhood: references, citing works, authors, affiliations, datasets, project, funding, related versions and correction status.

This creates a two-way interface between long-form scholarly argument and structured context.

105. A knowledge graph should help the user know when to stop

Graph exploration can become infinite. Every node leads to more nodes. Good tools provide bounded views: top neighbours by relation type, time window, field, project, confidence or relevance.

The user needs enough expansion to answer the question, not a visual spectacle of the entire scholarly universe.

Part VIII — Bibliometrics and research assessment on top of the graph

106. Bibliometrics is graph analytics with institutional consequences

Citation counts, co-authorship networks, h-index values, institutional output and field-normalised metrics are computed from graph structure.

This means every metric inherits graph coverage, identity resolution and citation matching. A wrong author merge changes h-index. Missing citations change journal metrics. Incorrect organisation mapping changes university output. Graph QA is therefore upstream of research assessment.

107. The graph makes metric receipts possible

Instead of presenting “1,438 citations” as an unexplained number, a responsible system can preserve the exact set of citing edges, snapshot date, database coverage and exclusion rules.

The number becomes auditable. This aligns with responsible research-assessment principles: quantitative indicators should support rather than replace qualitative judgement, and the underlying data should be transparent enough to challenge.

108. Graph coverage bias becomes metric bias

If a graph covers English-language journals better than regional books, its metrics will favour fields and geographies represented in that coverage.

No statistical normalisation can recover research objects the graph never ingested. Coverage analysis belongs before ranking.

109. Identity errors amplify at aggregation level

One misassigned paper may barely affect a global corpus but materially affect a small department, early-career researcher or grant review.

The closer the decision comes to a person, the higher the data-quality standard should become. Large-scale graph convenience should not become individual-level false precision.

110. Graph analytics can reveal collaboration without measuring contribution quality

Co-authorship edges can show hubs, international partnerships and interdisciplinary bridges.

Network centrality does not tell us whether the person’s contribution was conceptual, technical, supervisory or minimal. Contribution statements and qualitative evidence remain necessary.

111. Topic graphs can measure portfolio shape

Institutions can use topic assignments to analyse concentration, diversification and emerging areas.

But if topics are model-generated, portfolio changes can reflect classifier changes as well as research changes. Assessment pipelines should version the taxonomy and model.

112. Funding graphs enable outcome tracing

When grants, projects, organisations and outputs are connected, funders can trace publications, datasets and software associated with programmes.

This is valuable for accountability but must avoid naïve causality. A funded paper may have multiple grants; a grant’s value may appear in infrastructure, people or negative results not captured by citation counts.

113. Research assessment should preserve the graph beneath the dashboard

Dashboards compress. Knowledge graphs expand. The responsible design keeps both: a concise indicator for overview and a traversable evidence graph underneath.

A reviewer can see the number, then inspect the works, contribution roles, field context, open outputs and corrections. Compression remains reversible.

Part IX — AI research retrieval and GraphRAG

114. RAG begins with a simple idea: retrieve before generating

Retrieval-augmented generation gives a language model access to external evidence at inference time. Instead of relying only on model memory, the system retrieves relevant material and uses it to ground the answer.

Traditional RAG often retrieves text chunks by vector similarity. This improves freshness and domain grounding but can miss relationships that are distributed across documents. GraphRAG adds structure to retrieval.

115. GraphRAG retrieves connected evidence rather than isolated chunks

A query about a researcher’s contribution might require their identity, paper, dataset, institution and later correction. No single chunk contains the entire chain.

Graph retrieval can expand from recognised entities through typed relations, gather the connected documents, and return an evidence neighbourhood to the language model.

116. Scholarly GraphRAG has a natural advantage: the domain already has PIDs

Many enterprise GraphRAG systems must invent entity identity from unstructured documents. Scholarly infrastructure already has DOI, ORCID, ROR, PMID and other identifiers.

This means a research assistant can ground entity resolution in external registries instead of relying entirely on LLM extraction. The more PIDs flow through publishing workflows, the stronger the GraphRAG foundation becomes.

117. The first GraphRAG step should be query decomposition

A complex research question may contain entities, concepts, time constraints, relation requirements and evidence-quality conditions.

QUERY
  → identify entities
  → identify concepts
  → identify requested relation/path
  → identify date / geography / field constraints
  → identify evidence standard
  → choose lexical / vector / graph retrieval plan

This prevents the system from blindly expanding a graph when simple exact retrieval would be better.

118. Entity linking should precede graph expansion

If the query mentions “Michael Jordan”, the system must know whether the user means a researcher, athlete or another person. In scholarly retrieval, common names, institutions and acronyms create the same problem.

Resolve to ORCID, ROR, DOI or graph IDs where possible. Expansion from the wrong node produces coherent but irrelevant evidence.

119. Graph expansion needs relation budgets

Every node can connect to thousands or millions of neighbours. Naïve breadth-first expansion explodes.

A retrieval plan should specify relation types, hop count, temporal bounds, confidence thresholds and maximum candidates. The budget is query dependent. A literature-review question may follow citations; a funding question may follow project and organisation edges instead.

120. Static traversal weights can create hub drift

Recent 2026 ACL research has highlighted a “static graph fallacy”: graph-retrieval methods can use fixed transition probabilities that ignore the query, allowing high-degree hubs to divert walks away from the critical evidence chain.

The practical lesson is simple. Edge usefulness depends on the question. An affiliation edge can be essential for an institutional query and irrelevant for a methods query. Retrieval weights should be context aware.

121. Missing edges are a fundamental GraphRAG limitation

Knowledge graphs are incomplete. A study may use software without citing it formally. A dataset relation may be absent. A funder may be unnormalised.

2026 benchmark work on KG-RAG under incomplete knowledge shows that systems can struggle when necessary relations are missing and may fall back on internal model memory. A GraphRAG answer should therefore distinguish “the graph does not contain this relation” from “the relation does not exist in reality”.

122. GraphRAG should combine graph retrieval with text retrieval

Explicit graph edges provide structure. Text chunks contain nuance and evidence not yet encoded as relations. A hybrid system uses the graph to select documents and paths, then reads the source text.

This preserves the best division of labour: graph for identity and relationship; text for full scientific meaning.

123. Vector retrieval can repair missing explicit edges

If two papers are semantically related but do not cite each other, embeddings can retrieve them as candidates. The graph can then provide surrounding context.

This creates a three-layer retrieval stack: lexical precision, vector similarity and graph relationships. Each should remain visible enough for debugging.

124. Graph communities can support global summarisation

GraphRAG systems often cluster nodes into communities and generate summaries at multiple levels. This can help answer broad questions about a corpus without reading every document at query time.

The danger is summary drift. If a community summary contains an extraction error, that error can influence many later answers. Community summaries should retain links to their member evidence and be invalidated when the graph changes materially.

125. Hierarchical graph retrieval trades detail for scalability

Recent GraphRAG research uses topic or tag hierarchies to organise large graphs, reducing retrieval cost and supporting broad reasoning.

Hierarchy creates its own assumptions. If a paper is assigned to the wrong topic branch, the search space can exclude the correct evidence before fine-grained retrieval begins. High-level routing should therefore allow cross-branch recovery.

126. GraphRAG retrieval should return paths, not only passages

A useful answer can show: Query entity → Paper A → cites Paper B → uses Dataset C → corrected by Notice D.

This path is an explanation of retrieval. It gives the user something stronger than a list of citations: a reason why the sources were assembled together.

127. Path explanations are not proof of reasoning correctness

A model can present a plausible graph path and still infer the wrong conclusion from it. The path explains retrieval, not necessarily inference.

Evaluation should therefore separate retrieval accuracy, path completeness, source validity and answer correctness.

128. GraphRAG should resolve publication status before generation

After candidate sources are retrieved, check whether they are corrected, retracted, superseded or merely preprints.

Status filtering after generation is too late. The model may already have anchored its narrative around compromised evidence. Publication-state resolution belongs inside retrieval.

129. Evidence quality should influence reranking

Relevance alone should not determine final context. A highly similar conference abstract may be weaker evidence than a full peer-reviewed study. A retracted article should not outrank a current replication because its embedding is closer to the query.

Reranking can incorporate relevance, publication state, source type, evidence hierarchy, recency and graph provenance depending on the task.

130. GraphRAG needs contradiction retrieval

A system that only retrieves papers near the most prominent answer creates confirmation bias. Research assistants should deliberately retrieve contradicting or boundary evidence when the question is contested.

Graph structure can help by finding citing works that critique the seed paper, failed replications, corrections or alternative methods. Contradiction is a retrieval objective, not merely an afterthought.

131. GraphRAG should know when graph evidence is insufficient

If the requested relation is missing, confidence should fall. The system can broaden to semantic search, full-text search or another graph rather than fabricate the missing edge.

“I cannot establish this relation from the available graph” is often the correct answer. A retrieval system becomes trustworthy partly by recognising its own coverage boundary.

132. The ideal scholarly AI answer contains an evidence path

ANSWER
  → claim 1 → source work → exact version → evidence passage
  → claim 2 → source work → dataset relation → provenance
  → disagreement → conflicting works → reason for difference
  → current status → correction / retraction check
  → graph path explaining discovery
  → uncertainty / missing relation disclosed

This is not merely citation decoration. It is a compact proof of retrieval discipline.

Part X — Provenance, time and correction

133. Provenance answers “Why does this edge exist?”

For every important node property or relation, a graph should be able to say where it came from. Publisher deposit? Repository metadata? ORCID? ROR? Full-text extraction? Human curator? Machine inference?

Provenance turns graph output from assertion into inspectable evidence. It also lets downstream systems apply different trust policies.

134. Provenance has at least four layers

• Source provenance: which external source supplied the record.
• Transformation provenance: which normalisation or matching pipeline changed it.
• Temporal provenance: when the relation was observed or valid.
• Agent provenance: which person, organisation or model asserted or curated it.

High-trust scholarly graphs should preserve enough of all four for consequential relations.

135. A graph can be correct today and historically misleading

Suppose an institution changed its name in 2025. Updating every old affiliation edge to the new name makes the current graph tidy but rewrites history.

Temporal knowledge graphs distinguish entity identity from time-specific labels and relations. Scholarly history requires both present resolution and historical state.

136. Corrections should be additive where possible

When metadata were wrong, preserve the correction event rather than silently overwriting without trace. The current view can display the corrected value while the provenance ledger retains the earlier state.

This is especially important when downstream analyses may have used the earlier graph version.

137. Retraction is a status transition, not a node deletion

A retracted paper still existed, was cited and may have influenced later work. Removing it from the graph destroys history.

The node should remain resolvable with a clear retracted state and links to the notice. Retrieval systems can then exclude or downrank it for evidentiary use while preserving it for history and integrity research.

138. Graph freshness is relation-specific

A journal title may change rarely. Citation edges arrive continuously. Author affiliations change periodically. Retractions need urgent propagation.

One global “last updated” timestamp is not enough. Critical relation families should have freshness objectives appropriate to their risk.

139. Correction propagation latency is a measurable quality metric

How long after a publisher marks an article retracted does the status appear in the graph? How long before a ROR correction reaches downstream affiliation analysis?

These delays can be measured. A high-quality scholarly graph should publish or internally monitor them.

140. Graph releases should support time-travel analysis

Researchers studying the history of science may need the graph as it existed at a particular time. Policy evaluators may need to reproduce an analysis run under an earlier snapshot.

Snapshot archives, versioned exports or event logs enable this. Live-only graphs sacrifice reproducibility for convenience.

141. Confidence should change when evidence changes

An inferred author match may later receive an authenticated ORCID, increasing confidence. A relation may be contradicted by a curator correction, decreasing confidence.

Confidence should be derived from current evidence and provenance, not permanently assigned at first ingestion.

142. Provenance graphs can themselves become large

If every edge stores every source event, the provenance layer can rival the primary graph in size.

Systems need practical granularity: full event history for high-risk relations, source-level provenance for common metadata, and compressed audit records where detailed replay is unnecessary. Trust requires enough provenance, not infinite metadata.

143. Provenance should remain queryable

Storing provenance in log files nobody can access does not help users. APIs and interfaces should make it possible to ask which source contributed a field or edge.

This is particularly important for AI systems. The retriever should be able to prefer publisher-deposited status over a stale third-party copy.

144. Provenance enables source-specific repair

If an incorrect affiliation came from one repository feed, the graph can repair that contribution without discarding independent evidence from Crossref or ORCID.

Without provenance, correction becomes destructive because the system cannot separate sources.

145. Graph governance decides who may correct what

Can researchers edit their own profile? Can institutions correct affiliations? Can publishers update title metadata? Can anyone propose a ROR update? Which changes require evidence?

These are governance questions, not database questions. Trustworthy graph infrastructure publishes correction routes and authority boundaries.

146. Community curation works best with evidence requirements

Open contribution can improve coverage but also invite error or manipulation. ROR’s community curation requires evidence that an organisation is involved in research and processes requests through a transparent workflow.

The principle generalises: community correction should be easy enough to use and strict enough to preserve identity quality.

147. A graph should distinguish source correction from graph correction

If Crossref metadata are wrong, fixing the local graph may repair one application while the bad source record continues to propagate elsewhere.

High-quality workflows route corrections back to the canonical source when possible, then ingest the corrected source. Local overrides can bridge the delay but should not become permanent forks without explanation.

148. Knowledge graphs need incident response

A pipeline bug can overmerge thousands of authors or misclassify millions of works. The response should resemble production incident management: detect, stop propagation, estimate blast radius, repair, publish change notes, recompute derived metrics and notify downstream users if necessary.

At scholarly scale, data quality failures are infrastructure incidents.

149. Data-quality monitoring should look for distribution shifts

Sudden jumps in average authors per work, missing DOI rates, citation edge counts or topic distributions can signal an ingestion or mapping problem.

Monitoring does not need to know the exact error in advance. Statistical changes can tell the team where to investigate.

150. Provenance is what allows the graph to admit uncertainty without collapsing

Users sometimes fear that exposing uncertainty will make a system look weak. The opposite is true in scholarly infrastructure.

A graph that says “this affiliation was inferred from a noisy string with moderate confidence” is more trustworthy than one that presents the same inference as unquestionable fact. Provenance turns uncertainty into manageable information.

151. The graph should preserve disagreement among sources

Two sources may report different publication dates, author lists or affiliations. The graph can select a preferred canonical value while retaining the conflicting evidence.

This allows later correction and lets domain-specific applications apply their own precedence rules. Forced early consensus can erase useful signals.

152. A trust layer should be non-compensatory

Beautiful visualisation cannot compensate for broken identity. A billion edges cannot compensate for missing provenance. Powerful semantic search cannot compensate for unpropagated retractions.

IDENTITY FAILS → HOLD MERGE
PROVENANCE FAILS → LOWER TRUST
VERSION STATE UNKNOWN → DO NOT CLAIM CURRENT
RETRACTION CHECK FAILS → DO NOT TREAT AS CLEAN EVIDENCE
EDGE EXTRACTION UNSUPPORTED → DO NOT PROMOTE TO FACT
NO OTHER STRENGTH OVERRIDES THE FAILED GATE

153. Trust is an architectural property

A graph is trustworthy when its design makes error visible, repairable and bounded. Trust does not come from claiming the dataset is authoritative.

Persistent identity, source ownership, provenance, versioning, correction paths and transparent model limits are the architecture of trust.

Part XI — Bias, incompleteness and what the graph cannot see

154. Absence from the graph is not absence from scholarship

Local reports, books, non-English literature, grey literature and older works may be underrepresented depending on source coverage.

Users should interpret “no result” as “no result in this graph under this query”, not “no such research exists”.

155. Citation-rich fields are easier to graph than citation-poor forms of knowledge

Journal science produces dense metadata and citation links. Tacit knowledge, field notes, local policy evidence and creative scholarship may not.

Graph visibility can become a hidden hierarchy of what counts as research unless systems deliberately include diverse output types.

156. English-language dominance becomes graph dominance

When ingestion, embeddings and entity-resolution models perform best on English metadata, multilingual scholarship can receive weaker identity and topic coverage.

The bias may then be amplified by search ranking and AI retrieval. Multilingual labels, alternate names and regionally diverse sources are therefore infrastructure requirements, not merely interface features.

157. Open full text creates semantic-depth inequality

Open articles can be mined for methods, citations and claims more deeply than closed articles when licences or access prevent full-text processing.

A graph may therefore look semantically richer around open-access literature. Users should know whether missing relations reflect science or access constraints.

158. Popularity can feed itself through graph-based ranking

Highly cited works rank highly, receive more visibility and may then attract more citations. Prestigious institutions and central authors can gain similar advantages.

Graph algorithms should distinguish discovery convenience from normative judgement. Centrality is a useful navigation signal, not a universal measure of quality.

159. Ontologies encode cultural and disciplinary choices

Which entity types exist? Which relations are named? Which research outputs count? These are not purely technical decisions.

A biomedical ontology and a humanities ontology organise evidence differently. A global scholarly graph should avoid assuming one field’s conceptual structure is universal.

160. Incompleteness should be measured by relation family

A graph may have excellent DOI coverage and poor dataset links, strong English titles and weak affiliation identifiers, complete citation edges for recent journals and sparse book coverage.

Publishing one global completeness percentage hides where the graph is safe to use. Coverage dashboards should break down by entity, relation, field, year, language and geography.

161. Confidence can be asymmetric across the same edge type

An affiliation from an authenticated ORCID record may be stronger than one inferred from an OCR-damaged PDF. Both are “affiliated with” edges.

Applications should be able to filter relations by provenance or confidence rather than treating all edges of one type equally.

162. Graph visualisations can create false authority

A neat network diagram makes relationships feel concrete. Curved lines and clusters can hide uncertainty, missing nodes and algorithmic choices.

Good visualisations expose filters, relation meanings, time windows and source coverage. The picture should invite interrogation rather than awe.

163. The graph is a model of the record, not the record itself

Every graph compresses. It chooses which entities to represent, which relations to keep and which ambiguities to resolve.

The disciplined user always remembers that the original paper, dataset or registry remains the source to which consequential claims should return.

Part XII — How to build and evaluate a trustworthy scholarly knowledge graph

164. Start with the reader job, not the database technology

Write down the questions the graph must answer. Literature discovery? Research assessment? Dataset provenance? Institutional reporting? Claim comparison? AI retrieval?

The user job determines node types, relations, freshness, depth and quality thresholds. A graph built “because graphs are useful” accumulates data without owning a clear function.

165. Define the canonical entity model

• Which entity types exist?
• Which persistent identifiers are canonical?
• Which platform IDs are internal?
• What creates a new entity versus a new version?
• How are merges and splits recorded?
• Which entities require temporal states?

These decisions should be documented before ingestion scale makes them expensive to change.

166. Define relation semantics before relation extraction

Write a relation dictionary: source type, target type, direction, meaning, allowed evidence sources, temporal behaviour, confidence requirements and valid reasoning.

This prevents an LLM or ingestion team from inventing near-duplicate predicates such as uses, employs, applies and utilises without semantic discipline.

167. Build a source authority matrix

Field	Preferred authority	Fallback
Researcher identity	Authenticated ORCID	Platform disambiguation
Organisation identity	ROR	Normalised text + review
DOI work metadata	Crossref/DataCite + publisher	Repository/index
Retraction status	Publisher/Crossref trusted update	Secondary integrity sources
Open location	Publisher/repository evidence	OA aggregators
Topic	Declared/controlled vocabulary	Model prediction

The matrix makes conflict resolution predictable rather than ad hoc.

168. Keep raw, normalised and enriched layers separate

RAW SOURCE RECORD
  → NORMALISED RECORD
  → RESOLVED ENTITY
  → ENRICHED RELATIONS
  → DERIVED METRICS / SUMMARIES

Each layer should be reproducible from the previous one. This allows algorithm upgrades without losing source history.

169. Measure identity quality directly

• Work duplicate rate.
• Author overmerge rate.
• Author undermerge rate.
• ORCID coverage and authentication rate.
• ROR coverage for affiliations and funders.
• PID conflict rate.
• Version-collapse error rate.

Identity is the floor. If these metrics are poor, downstream graph analytics should carry explicit warnings.

170. Measure relation quality by relation family

• Citation-match precision and recall.
• Affiliation-match precision and recall.
• Funding-link precision.
• Dataset-link coverage.
• Version-link accuracy.
• Correction/retraction propagation latency.
• Claim-extraction precision with evidence spans.

A graph can be excellent for citations and weak for grants. Report both rather than averaging them into one quality score.

171. Measure coverage across populations, not only globally

Break coverage down by year, discipline, language, country, publisher type, open-access status and document type.

A global graph can look comprehensive while leaving particular research communities nearly invisible.

172. Measure freshness as an operational SLO

Define service-level objectives for high-risk updates. Retractions may need faster propagation than historical affiliation corrections. New publications may have a different ingestion target from funder enrichment.

Freshness becomes measurable infrastructure performance rather than a vague promise.

173. Evaluate retrieval separately from generation

• Did the system retrieve the needed nodes?
• Did it retrieve the correct edges?
• Was the evidence chain complete?
• Were compromised sources detected?
• Did the answer accurately synthesise what was retrieved?

A language model can produce a correct answer from poor retrieval by relying on memory, or a wrong answer from perfect retrieval by reasoning badly. Evaluation should not collapse the stages.

174. Build adversarial graph tests

Test common-name authors, institution renames, duplicate DOIs, preprint/version pairs, retracted papers, multilingual affiliations, high-degree hubs and missing-edge queries.

Adversarial examples reveal whether the graph is robust where ordinary benchmarks are too clean.

175. Test incomplete-knowledge reasoning explicitly

Remove necessary edges and see whether GraphRAG admits uncertainty or hallucinates the missing relation.

Recent KG-RAG research shows that incompleteness is a serious failure mode. A production scholarly assistant should be evaluated under missing knowledge, not only perfect benchmark graphs.

176. Test graph update behaviour

Add a correction, split an author, merge duplicate works or update a ROR record. Verify that indexes, caches, embeddings, derived metrics and summaries update consistently.

A graph that is accurate only immediately after a full rebuild is not a production graph.

177. Preserve reproducible graph snapshots for published analyses

If a paper, dashboard or policy report depends on the graph, record the snapshot or query date, graph version, API parameters and code.

The graph is living data; the analysis needs a frozen receipt.

178. Publish a graph card

GRAPH CARD

Purpose:
Entity types:
Relation types:
Primary sources:
Coverage dates:
Languages:
PID support:
Deduplication method:
Entity-resolution method:
Semantic enrichment models:
Provenance model:
Correction routes:
Snapshot/version policy:
Known coverage gaps:
Known failure modes:
Licence:
API / download access:

A graph card gives users a compact answer to “What exactly am I trusting?”

179. Publish change receipts for major pipeline changes

If author disambiguation changes, tell users. If topic taxonomy changes, tell users. If citation extraction changes, tell users.

Derived research metrics can move after pipeline changes even when the underlying scholarship did not. Change receipts protect interpretability.

180. The graph should support challenge and repair

Researchers should be able to report wrongly assigned works. Organisations should be able to request registry corrections. Publishers should update metadata. Curators should review disputed semantic relations.

A graph without correction channels will become stale regardless of how sophisticated its initial construction was.

Part XIII — Failure library

Failure	What breaks	Repair
Name used as identity	People or organisations merge incorrectly	Use PIDs and reversible disambiguation
URL used as identity	Platform migration breaks continuity	Use persistent identifiers and resolvers
Preprint and article silently merged	Version history disappears	Link versions without collapsing states
Same work duplicated	Citation and output counts inflate	PID-first deduplication with metadata fallback
Inferred edge shown as fact	Model uncertainty disappears	Store provenance and confidence
Topic model treated as ontology truth	Classification becomes invisible judgement	Expose model/taxonomy version
Retraction edge missing	Compromised source remains clean evidence	Status resolution before retrieval
Graph snapshot not recorded	Analysis cannot be reproduced	Version and snapshot every consequential analysis
High-degree hub dominates traversal	Graph retrieval drifts	Query-aware edge weighting and budgets
Missing edge interpreted as false relation	Incompleteness becomes negative evidence	Model coverage and uncertainty explicitly
LLM extraction lacks evidence span	Semantic graph cannot be audited	Attach source passage and validation
GraphRAG retrieves relevance only	Weak or retracted evidence dominates	Rerank by status and evidence quality
Community summary becomes stale	Old graph state shapes new answers	Invalidate derived summaries after material updates
One global quality score	Strong and weak relation families are hidden	Measure quality by entity and relation type
Open graph assumed unbiased	Coverage bias remains invisible	Audit language, geography, field and document type

181. Failure analysis should drive graph design

Instead of asking only “What can the graph do?”, ask “How can this relation be wrong?” For every entity and edge, imagine the mistaken merge, stale state, wrong version, missing provenance and adversarial query.

This creates a failure library before incidents occur. The library can become test cases, monitoring rules and interface warnings.

182. The most dangerous errors are plausible

A broken DOI is obvious. A wrong author merge involving two researchers in the same field can look perfectly plausible. An LLM-extracted claim that slightly overstates the paper can sound better than the source.

Quality systems should focus especially on plausible wrongness because users are least likely to challenge it.

183. The graph should fail soft rather than fail confident

When identity is ambiguous, return candidates. When a relation is inferred weakly, label it. When evidence is missing, say so.

False certainty is more damaging than an explicit unknown in research infrastructure.

Part XIV — A practical architecture for an AI-ready scholarly graph

184. Layer 1: authoritative identity

• DOI and other work PIDs.
• ORCID for people.
• ROR for organisations and funders.
• Domain identifiers such as PMID, trial IDs and accessions.
• Internal graph IDs only where external PIDs do not exist.

This layer should be conservative. Bad identity poisons every layer above it.

185. Layer 2: source-preserving metadata

Ingest publisher, registry, repository and funder metadata while keeping source provenance. Normalise into a common schema without discarding original values.

This layer supports rebuilds and correction when matching logic improves.

186. Layer 3: entity resolution and canonicalisation

Resolve records to canonical graph entities with tiered evidence. Persist match explanations, model version and confidence.

Allow merge and split operations to be reversed.

187. Layer 4: explicit relations

Build citation, authorship, affiliation, funding, version, dataset and software relations from structured sources first.

Structured deposits generally provide stronger evidence than extraction from prose and should be preferred where available.

188. Layer 5: semantic enrichment

Add topics, concepts, methods, claims and other extracted structure. Keep model-generated edges distinguishable from deposited relations.

Attach evidence spans for claim-level extraction.

189. Layer 6: lexical and vector indexes

Build exact text search and semantic vector search alongside the graph database.

Do not force every retrieval problem through graph traversal when keyword or vector search is more appropriate.

190. Layer 7: graph analytics and derived features

Compute citation counts, centrality, communities, topic profiles and other derived signals with explicit snapshot dates.

Derived features should always be reproducible from the underlying graph version.

191. Layer 8: provenance and trust policy

Define source precedence, confidence classes, publication-status handling and edge-eligibility rules for high-stakes retrieval.

This layer prevents the application from treating all graph content as equally authoritative.

192. Layer 9: retrieval planner

The planner decides whether a query requires exact lookup, semantic search, graph expansion, citation traversal or a combination.

It also sets hop budgets, relation filters and temporal constraints.

193. Layer 10: evidence assembler

The assembler gathers canonical source records, full-text passages, graph paths and current publication status into an evidence packet.

The language model should receive the packet, not a vague heap of semantically similar chunks.

194. Layer 11: generator with citation discipline

The generator writes from retrieved evidence, distinguishes source facts from inference and attaches citations to the claims they support.

Where evidence conflicts, the answer should preserve disagreement instead of averaging it into one voice.

195. Layer 12: feedback and correction

User-reported identity errors, broken links, missing corrections and extraction problems should enter a triage queue.

Graph improvement becomes a closed loop rather than a periodic rebuild.

Part XV — Evaluation gym: tests a serious graph should pass

196. The same-name researcher test

Find two researchers with the same or nearly identical name in the same field. Verify that work, affiliations and ORCID links remain separate.

This tests overmerge resistance.

197. The changed-name researcher test

Use a researcher who has published under several name forms. Verify that legitimate works remain connected without relying only on name string equality.

This tests undermerge resistance.

198. The institution-rename test

Query historical publications before and after an organisation rename or merger. Verify that the graph preserves historical labels while linking lineage correctly.

This tests temporal organisation identity.

199. The preprint-to-version-of-record test

Find a paper with preprint and journal versions. Verify distinct version nodes or locations, proper links and no duplicate study counting.

This tests version semantics.

200. The retraction test

Retrieve a retracted article by title and by semantic similarity. Verify that the status is visible before the answer generation stage.

This tests trust propagation.

201. The missing-edge test

Remove or withhold a relation necessary to answer a multi-hop query. Verify that the AI system lowers confidence or broadens retrieval instead of hallucinating the link.

This tests incompleteness awareness.

202. The hub-drift test

Create a query where the correct path passes near a very high-degree generic node. Verify that query-aware retrieval reaches the evidence rather than getting absorbed by the hub.

This tests context-sensitive traversal.

203. The multilingual affiliation test

Use organisation names in different languages and transliterations. Verify ROR or other authoritative organisation mapping where appropriate.

This tests global entity resolution.

204. The contradictory-evidence test

Use a research question with well-known conflicting findings. Verify that retrieval includes major disagreement rather than only the most cited side.

This tests confirmation-bias resistance.

205. The graph-version reproducibility test

Run the same analytical query against two graph snapshots. Explain which differences come from new scholarship and which come from pipeline changes.

This tests release transparency.

Part XVI — Practical checklists

206. Researcher checklist

• Maintain an ORCID iD and authenticate it in submission systems.
• Use stable DOI links in citations.
• Check that affiliations map to the correct ROR organisation where systems support it.
• Deposit datasets and software with persistent identifiers where appropriate.
• Link outputs to grants and projects.
• Check preprint/version relationships.
• Correct wrongly assigned works in major scholarly graphs.
• Verify retraction and correction status before relying on pivotal evidence.
• Do not treat citation count or graph centrality as quality.
• Record the graph/database and date when using metrics.

207. Librarian and information-specialist checklist

• Teach users the difference between document search, semantic search and graph traversal.
• Explain which PIDs identify works, people and organisations.
• Audit repository metadata for DOI, ORCID and ROR coverage.
• Preserve version relationships.
• Use graph sources as supplements to database searching, not invisible replacements.
• Document source coverage and graph snapshot dates in research support.
• Route metadata corrections back to canonical sources where possible.

208. Publisher checklist

• Capture authenticated ORCID iDs.
• Capture ROR IDs for affiliations and funders.
• Deposit complete DOI metadata.
• Deposit reference lists.
• Link datasets, software, preprints and supplementary material.
• Maintain Crossmark or equivalent update relationships.
• Propagate corrections and retractions to metadata services.
• Keep landing pages resolvable.
• Preserve provenance when enriching metadata.

209. Research-graph builder checklist

• Define reader job and graph scope.
• Publish entity and relation schema.
• Prioritise authoritative PIDs.
• Keep raw source records.
• Make deduplication reversible.
• Version matching models.
• Attach provenance to every inferred edge.
• Audit coverage by field, language and geography.
• Publish dated snapshots.
• Track correction propagation latency.
• Maintain merge/split logs.
• Publish known failure modes.

210. AI research-assistant checklist

• Resolve entities before expanding the graph.
• Use query-aware relation weights.
• Combine lexical, semantic and graph retrieval.
• Return to full-text evidence after graph selection.
• Check version and retraction state before generation.
• Retrieve contradictory evidence deliberately.
• Expose graph paths where useful.
• Separate retrieved facts from model inference.
• Admit missing-edge uncertainty.
• Cite the evidence packet, not the graph visualisation.

211. Research-assessment checklist

• Name the graph/database used.
• Record snapshot date.
• Audit author and organisation identity.
• Check field and document-type coverage.
• Inspect retracted-work handling.
• Do not assign journal-level prestige to article quality.
• Use graph metrics as contextual evidence rather than automatic verdicts.
• Allow researchers to correct factual graph errors before consequential decisions.

Part XVII — The deeper model

212. A scholarly knowledge graph is a memory system for relationships

Books and papers preserve statements. Graphs preserve relations among statements, people, institutions and objects. That relational memory becomes more important as the literature grows beyond human reading capacity.

The graph does not replace durable documents. It gives them navigable context.

213. The graph is also a manufacturing system for future retrieval

Every identifier captured correctly today reduces ambiguity tomorrow. Every dataset relation deposited today makes future replication easier. Every correction relation propagated today prevents an AI system from treating obsolete evidence as current.

Graph construction manufactures future discoverability and future auditability.

214. The graph turns research from archive into infrastructure

An archive preserves what happened. A knowledge graph lets systems compute over what happened: find paths, aggregate portfolios, detect connections, retrieve evidence and update trust states.

The scholarly record becomes not merely stored knowledge but operable knowledge.

215. The graph creates a new responsibility: machine-legible truth claims

When a human reads a paper, ambiguity is visible in prose. When software converts the sentence into a graph edge, the ambiguity can disappear.

Builders must therefore preserve qualifiers, confidence and provenance so machine readability does not become machine overstatement.

216. The future scholarly graph will be multi-granular

The emerging design is not a choice between bibliographic graphs and deep semantic graphs. It is layers: global document identity, people and institutions; research-object links; topic and method structure; claim-level evidence where the domain can support it.

Broad navigation and deep comparison should coexist without forcing every paper into the same semantic depth.

217. The future graph will be hybrid: symbolic plus vector

Explicit edges provide explainable structure. Embeddings provide semantic flexibility. Full text provides nuance. Language models provide synthesis.

The strongest research systems will combine all four while keeping the role of each layer visible.

218. The future graph will be temporal

Research is not one frozen state. Future graphs will increasingly answer both “What is currently believed or indexed?” and “What did the evidence graph look like at this earlier date?”

Temporal provenance is essential for research history, reproducibility and policy evaluation.

219. The future graph will be correction-aware by default

Retractions, corrections, dataset updates and organisation changes should propagate through graph relationships automatically.

A knowledge system that knows relationships but not current status is structurally incomplete.

220. The future graph should not become one global gatekeeper

A single universal scholarly graph would concentrate enormous power over what counts as a work, author, institution, topic and citation.

Interoperable open graphs, registries and domain infrastructures create healthier pluralism. Persistent identifiers let these systems connect without requiring one organisation to own the entire scholarly world.

221. Why scholarly knowledge graphs matter to civilisation

Civilisation has spent centuries building durable intelligence: archives, libraries, journals, catalogues, indexes and databases. Each invention increased the distance across which knowledge could survive and the speed at which it could be found.

Scholarly knowledge graphs are the next connective layer. They do not make us wiser automatically. They make the accumulated record more navigable by preserving identity and relation: who created what, who funded it, what it cites, which data support it, which version is current, what later work disagreed, and whether a correction changed its status.

This becomes critical in an AI age. A language model can generate a confident paragraph in seconds. The scarce resource is no longer fluent wording. It is trustworthy return paths. The graph matters because it can give an answer a route back through identities, relationships and evidence to the scholarly objects from which the answer was built.

Part XVIII — Applied design cases: what the theory looks like in practice

222. Case 1: building a graph for a systematic review

A systematic-review graph should not begin with citation centrality. Its primary entities are studies, reports, interventions or exposures, populations, outcomes, risk-of-bias assessments and data extracts. Publications become evidence containers connected to one underlying study where appropriate. Trial-registry records, protocols, preprints and final papers should be linked as versions or reports of the same research activity rather than counted independently.

The graph can then support study-family detection, backward and forward citation chasing, duplicate identification and contradiction retrieval. Crucially, inclusion and exclusion decisions remain review decisions, not graph edges inferred solely from similarity. The graph helps the reviewers see the evidence landscape; it does not silently rewrite eligibility criteria.

223. Case 2: building a graph for a university research office

A university graph needs authoritative people, organisation, grant and output identity. ORCID should anchor researchers; ROR should anchor the institution and external partners; DOI and repository PIDs should anchor outputs. Internal HR or grant identifiers can be linked rather than exposed as universal scholarly IDs.

The office can then answer portfolio questions: Which projects produced datasets? Which grants supported open-access outputs? Which departments collaborate internationally? Where are affiliation strings failing to map? The graph should preserve time because employment and organisational structure change. It should also separate administrative completeness from research quality: a perfectly connected output is not automatically excellent scholarship.

224. Case 3: building a graph for a journal publisher

A publisher has an unusually authoritative view of manuscript versions, authorship order, peer-review events, corrections, retractions and final publication metadata. Its graph should capture authenticated ORCID iDs, ROR-based affiliations and funders, DOI relationships, reference lists, data availability links and update notices at production time.

The key advantage is upstream capture. Every identifier recorded correctly before publication reduces downstream matching. The publisher can also maintain a precise version and correction graph: submitted manuscript → accepted manuscript → version of record → correction or retraction state. That graph can then propagate outward through Crossref and other infrastructures.

225. Case 4: building a graph for an AI research assistant

An AI assistant needs fewer graph edges than a global bibliographic service but higher query-time discipline. It should resolve the user’s named entities, retrieve candidate works through lexical and semantic search, expand only the relation types relevant to the question, check publication state, obtain source passages and build an evidence packet before generation.

The graph should not be used as a giant prompt. It should be used as a routing and verification layer. For a question about the effect of a method, author affiliation edges may be irrelevant; for a question about an institution’s research, they become essential. Query-aware traversal prevents the graph from overwhelming the model with structurally nearby but evidentially weak information.

226. Case 5: building a graph for research integrity monitoring

An integrity graph prioritises publication states, versions, notices, duplicated images or text signals, common datasets, author relationships and corrections. It should ingest retraction and correction metadata quickly and connect notices to every known version or repository copy.

The graph can help detect clusters worth investigation—unusual citation patterns, repeated image relationships, redundant publications—but signals must remain signals. Network proximity cannot establish misconduct. The graph routes qualified humans toward evidence and preserves the audit trail of what was observed.

227. Case 6: building a graph for a national research ecosystem

A national graph needs to connect universities, public research institutes, funders, grants, outputs, patents, datasets, software and international collaborators without reducing national research value to citation counts. ROR and ORCID provide globally interoperable anchors, while local project and grant identifiers preserve national programme structure.

For Singapore, such a graph could support questions about collaboration across universities and A*STAR institutes, open-science outputs, domain strengths and translation pathways. The design must preserve local relevance: nationally important work can have modest global citation volume. The graph should make mission-specific outcomes visible instead of allowing international journal coverage to define national value by default.

228. Case 7: building a graph for a fast-moving scientific field

Fields such as generative AI, pandemic research or battery materials evolve faster than conventional review cycles. The graph must ingest preprints, conference papers, repositories and journal versions quickly, while making review state and version identity obvious.

Freshness and correction latency become more important than perfectly curated historical coverage. Alerts can track new works and citation links, semantic search can detect terminology shifts, and graph traversal can identify emerging clusters. The price of speed is that uncertainty must be more visible, not less.

229. Case 8: building a graph for humanities scholarship

A humanities graph cannot simply copy a biomedical data model. Books, chapters, archival sources, editions, translations, people, places, events and interpretive traditions may matter more than datasets and trials. Citation practices are slower and less uniform; monographs carry more weight; historical identity and provenance are central.

The graph should therefore model editions, source documents, historical entities and interpretive relations appropriate to the discipline. This case demonstrates a general principle: scholarly knowledge graph architecture must follow the epistemology of the field rather than force every discipline into article-centric science infrastructure.

230. Case 9: building a graph for scientific software and reproducibility

Software-heavy research needs release-level identity, dependencies, execution environments, datasets, workflows and papers. A Git repository URL is not enough because branches and files change. Archived releases or DOIs create citeable states.

The graph can connect Paper → Analysis Workflow → Software Version → Dependency → Dataset Version. Reproducibility becomes a path reconstruction problem. When an old dependency disappears or a dataset is corrected, the graph can show exactly which publications may be affected.

231. Case 10: building a graph for evidence-to-policy pathways

Policy impact is poorly represented by citation graphs alone. A policy graph may need research outputs, reviews, guidelines, consultation documents, agencies, committees, regulations and implementation reports. The relation “cited by policy document” is useful but still insufficient because evidence may influence a decision indirectly.

The graph can at least preserve traceable pathways: study → systematic review → guideline → policy. It should avoid claiming causal impact simply because a path exists. Influence is a substantive interpretation requiring documentary evidence.

232. Case 11: building a graph for education and public learning

A learning graph needs a bridge between scholarly objects and concepts understandable to students. It can connect a concept to foundational papers, current reviews, datasets, historical milestones, examples and prerequisite concepts.

The risk is educational simplification turning into false certainty. A public-facing graph should preserve the route back to expert sources and indicate when a concept is contested. The graph becomes an explanatory map without pretending that the map replaces disciplinary depth.

233. Case 12: knowing when not to build a knowledge graph

A graph is not automatically the right architecture. If the user job is simple full-text search over a small, stable corpus, a relational database plus search index may be cheaper and clearer. If relationships are shallow and rarely traversed, graph infrastructure can add operational complexity without user value.

Build a graph when identity, multi-hop relationships, provenance, versioning or cross-object traversal are central to the problem. Do not build one merely because graph visualisations look sophisticated. The best architecture is the simplest system that preserves the relations the reader truly needs.

The future of research retrieval is not a machine that knows everything. It is a machine that can show how it knows, what it cannot see, which version it used, and where a human can inspect the evidence.

Authority routes and current infrastructure

• OpenAlex: Data Reference
• OpenAlex: How the Graph Is Built
• OpenAlex: Semantic Search
• OpenAIRE Graph Documentation
• OpenAIRE Graph Version History and Changelog
• Open Research Knowledge Graph: ORKG Overview and Comparisons
• Semantic Scholar Academic Graph API
• Crossref REST API
• Crossref: ROR Funder Matching, September 2026
• DataCite: Connection Metadata and PID Graph
• DataCite: PID Graph Services
• ORCID
• Research Organization Registry
• OpenCitations Data and Citation Graph Downloads
• Scholarly Knowledge Graphs Through Structuring Scholarly Communication: Review
• Requirements for an Open Research Knowledge Graph
• Mapping Scholarly Knowledge: 2026 Systematic Review of Knowledge Graphs for Academic Papers
• Knowledge Graphs in AI for Science: 2026 Survey
• What Breaks Knowledge Graph-based RAG? 2026 Benchmark Study
• Context-Aware Traversal for Graph-based RAG, ACL 2026
• Hierarchical Knowledge Graphs for GraphRAG, ACL 2026

Continue the Archives and Publishing / Research Infrastructure series

• How Persistent Scholarly Identifiers Work
• How Scholarly Indexing Works
• How Literature Search and Research Discovery Work
• How Bibliometrics and Responsible Research Assessment Work
• How Citations, References and Scholarly Linking Work
• How Preprints and Research Repositories Work
• How Research Integrity and Publication Ethics Work
• Editorial Publishing House | The eduKate Publishing House

Publication safeguards: evidence, authority, ownership, rights, privacy, protection, release, provenance, model-limit, freshness, correction and archive gates.

World Return: When a scholarly knowledge graph gives you a clean node or a beautiful path, ask what had to be inferred to create it. Resolve the identities. Inspect the relation type. Check the graph version. Follow the provenance. Verify the publication state. Then return to the paper, dataset or registry that makes the edge defensible. The graph is most intelligent when it makes that return easier.

Research route: Return to the Research Collections Directory for connected guides on evidence, methods, discovery and scholarly systems.