« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 07 — Financial Knowledge Graphs: FIBO, RDF/OWL, SHACL & SPARQL

Answers this JD line: "knowledge graph integration (FIBO, OWL, SHACL, SPARQL)" · "knowledge graphs (FIBO, RDF, OWL, SHACL, Neo4j, Apache Jena)".

Why this phase exists

Vector retrieval finds text that resembles your question. A great many of a bank's questions are not about resemblance at all:

"Which of our counterparties are ultimately controlled by an entity on the sanctions list?" "Which obligations does this master agreement create, and which of them are collateralized?" "If this legal entity defaults, which exposures are affected, at what depth?"

Those are structural questions. No amount of embedding similarity answers them, because the answer is a path through relationships, not a passage of text. That is what a knowledge graph is for, and it is why the JD names it alongside vectors rather than instead of them.

The second reason this phase exists is shared meaning. A bank has four systems that each call something a "counterparty" and mean four different things. FIBO — the EDM Council's OWL ontology of financial concepts — exists so that "legal entity", "obligation", "control" and "agreement" have definitions that survive crossing a system boundary. An agent platform that grounds answers in the bank's data needs that vocabulary, or it will confidently join two things that should never have been joined.

And the third: validation. OWL cannot tell you that a record is missing an LEI, because OWL is open-world — what is not stated is unknown, not false. SHACL is the closed-world validator that answers the question a bank actually asks: does this record conform to the shape we require? Knowing why both exist is the interview question.

Concept map

  • RDF: everything is a triple (subject, predicate, object); IRIs, literals, CURIEs; why a global identifier scheme is the whole point.
  • Triple stores: Apache Jena · Neo4j (as an LPG, or with RDF via n10s); RDF vs labelled property graph and when each fits.
  • RDFS and OWL 2: classes, subClassOf, domain/range; then inverse, transitive, symmetric properties, cardinality, disjointness, equivalence.
  • Entailment: what is derived rather than stated — and why a materialized inference set needs a refresh strategy.
  • The open-world assumption, and the precise reason it makes OWL unusable as a validator.
  • SHACL: node and property shapes, minCount/maxCount, datatype, pattern, value ranges; the validation report as an artifact.
  • SPARQL: basic graph patterns, joins as shared variables, OPTIONAL, FILTER, property paths (^, +, /) — which is how "ultimately controlled by" is expressed in one line.
  • FIBO: the module structure (Foundations, Business Entities, Financial Business & Commerce, Indices & Indicators, Loans, Securities, Derivatives); how to use a standard ontology without adopting all of it.
  • Graph-grounded retrieval: neighbourhood expansion, path-constrained retrieval, and using the graph to select what goes into a prompt rather than to answer directly.
  • Ontology governance: who may extend it, how versions are released, and how downstream queries survive a change.

The lab

LabYou buildProves you understand
01 — A Financial Knowledge Graph From Scratchan in-memory RDF triple store with IRI/CURIE handling; an RDFS + OWL subset reasoner (subclass, subproperty, domain/range, inverse, transitive) with materialized entailment; a SHACL validator producing a real validation report; a SPARQL BGP engine with joins, OPTIONAL, FILTER and transitive property paths; a small FIBO-shaped ontology of legal entities, control relationships, agreements and obligations; and graph-grounded retrieval that answers an ultimate-ownership question a vector index cannotthat a knowledge graph is a reasoning substrate, not a database with arrows — and that OWL infers while SHACL validates, which is why a bank needs both

Test contract: a transitive controls chain of depth 4 is entailed; a record missing a required LEI is a SHACL violation and not an OWL error; a SPARQL property path finds ultimate ownership through intermediaries; and adding an unrelated triple never changes an existing answer (monotonicity). 61 tests, all green.

Deliverables checklist

  • Lab 01 green under LAB_MODULE=solution pytest and under your own lab.py.
  • You can state the open-world assumption and why it forces SHACL to exist.
  • You can write a SPARQL query with a property path for transitive ownership.
  • You can explain RDF vs LPG and pick one for a stated requirement.
  • You can describe what FIBO gives you that your own schema does not.
  • You can name three questions a graph answers that a vector index cannot.
  • You can describe how graph context is injected into a prompt without exploding the budget.
  • You can state an ontology change-management process.

Key takeaways

  • Vectors find similar text; graphs answer structural questions. They are complements, and the interesting designs use the graph to choose the text.
  • OWL infers, SHACL validates. Confusing them is the standard mistake, and it comes from the open-world assumption.
  • FIBO is shared meaning, not a schema. Adopt the parts that cross boundaries.
  • Property paths are the feature. "Ultimately controlled by" in one line is why this technology is in the JD.
  • Entailment needs a refresh strategy. Materialized inference is a cache, with all that implies.
  • An ungoverned ontology becomes a second, worse schema within a year.