Entity Linking and Knowledge Graph Construction › From Links to a Knowledge Graph

Linked arguments give a relation extractor candidate endpoints; they do not turn a sentence into a verified fact. Graph construction adds choices about identity, relations, validation, and storage. Consistent IDs let assertions from different documents join, while source records let a consumer inspect how each assertion arose.

A graph construction project should decide which of the following it needs:

• Nodes with stable identity. The entity mercury_planet must be one node, referenced consistently across documents, not a new node per mention.
• Edges with a schema. This project can use a controlled relation vocabulary: orbits, is_capital_of, member_of. Free-text relation labels alone do not specify validation constraints or equivalence rules.
• Types or a class hierarchy when the application needs type-aware retrieval or inference. A hierarchy alone does not infer geographic containment without the relevant relations and rules.
• Provenance fields chosen for the application, such as a source document, supporting span, extractor version, and extraction time.
• Temporal scope for relations that change, such as (X, ceo_of, Y), including a representation for unknown or open-ended bounds.
• Confidence or evidence counts when they support review or fusion. Repeated copies of one source are not independent corroboration. A count alone does not establish which conflicting assertion is correct.

These choices support different operations. Stable identifiers support joins, but do not automatically prevent duplicates. A controlled relation vocabulary reduces predicate variation; application validation rules can detect incompatible records. Provenance supports tracing assertions, temporal scope supports date-aware queries, and scores can prioritize review. None of these is a guarantee of correctness, and a class hierarchy or a confidence field is not a defining requirement for every knowledge graph.

Two data models worth distinguishing are RDF and property graphs.

An RDF 1.1 graph is a set of subject-predicate-object triples. Subjects can be IRIs or blank nodes; predicates are IRIs; objects can be IRIs, blank nodes, or literals. In the following illustrative triples all three positions use prefixed IRIs. Here ex: abbreviates the example namespace https://example.org/.

@prefix ex: <https://example.org/> .

ex:mercury_planet ex:orbits ex:sun .
ex:amman ex:is_capital_of ex:jordan_country .

An RDF dataset contains a default graph and zero or more named graphs (W3C RDF 1.1 Concepts, 2014). An application can group assertions by source or context using graph names, but must define what that grouping means. Statement-level metadata can instead use a statement resource, including RDF 1.1 reification. Reifying a triple describes it; it does not by itself assert the described triple. SPARQL provides standardized graph queries, including a federation extension, but we do not implement that query language in the toy store below.

Property graphs attach properties to vertices and edges, so an application can store source and score fields directly on an edge. They are not an area without standards: ISO/IEC 39075:2024 defines GQL data structures and operations for property graphs. An application still needs to choose its entity identifiers, source policy, and domain ontology. Interoperability in either model still requires agreement about those meanings.

Choose a representation according to the required interchange formats, query behavior, inference rules, and update workflow. RDF and a property graph can both carry provenance when it is modeled explicitly. A data-model label alone does not establish faster queries, better identity resolution, or more trustworthy assertions.

A realistic construction pipeline looks like this:

1. Ingest documents and record source metadata (URL, retrieval time, license).
2. Segment and parse into sentences and structured blocks.
3. Detect mentions, retrieve and rank KB candidates, and record separate NIL predictions or abstentions.
4. Extract relations with patterns, classifiers, or an LLM, conditioned on the linked entity types.
5. Canonicalize arguments to nodes under an explicit merge policy, including local nodes for justified out-of-KB referents.
6. Validate against schema constraints: type checking, cardinality, domain/range restrictions.
7. Compare candidates with existing content, retaining conflicts that the fusion policy cannot justify resolving.
8. Store surviving assertions with the provenance captured during ingestion and extraction.

Capture provenance when candidates are created and preserve it through validation and fusion; do not wait until the last step to reconstruct missing evidence. Linking, canonicalization, and fusion errors require different repairs. Evaluate each with appropriate labeled cases as well as testing the complete pipeline.

Entity linking maps text mentions to KB entries. Entity resolution identifies records or nodes that refer to the same entity; a later merge policy decides how to combine their fields and identifiers. Resolution can use names, attributes, graph neighborhoods, and source documents when those are retained. Its available context depends on the record schema and retained evidence; record matching need not discard the source text.

The mechanics are similar to linking but operate on records rather than mentions:

• Blocking. All-pairs comparison of $n$ records requires $n(n-1)/2$ unordered pairs. At one million records, that is 499,999,500,000 pairs. When that cost exceeds the available budget, blocking can retrieve a smaller candidate set using keys such as normalized names, identifiers, or neighbors.
• Pairwise matching. Score each candidate pair with string similarity (Jaro-Winkler, token-set ratio), attribute agreement, and neighborhood overlap. Then classify match/non-match.
• Clustering. Decide which candidate records belong to one entity. Connected components enforce a transitive grouping; a clustering objective can instead penalize inconsistent pair decisions. Choose a representative only after deciding membership.

Blocking trades candidate coverage against comparison cost. A pair excluded by every retrieval or blocking route will not reach the pairwise matcher. Candidate keys can use name tokens, identifiers, or neighbors, but their usefulness depends on missingness, name collisions, and graph errors. Measure candidate-pair recall on labeled duplicates rather than assuming one kind of key is best.

A pairwise classifier can say that A matches B and B matches C while rejecting A-C. Connected components merge all three because a path connects them. One alternative is a clustering objective that penalizes both joining dissimilar records and separating similar ones; this still depends on the quality of the pairwise evidence and its optimization. Choosing a canonical representative happens after deciding cluster membership. It does not repair a mistaken cluster.

owl:sameAs is appropriate when identity is the intended, justified claim. A custom property does not become weaker merely because it has another name: specify its semantics and the reasoning rules that use it. Likewise, recording a canonical ID can cause an application to merge records, so that decision also needs evidence and a reversible history.