Ontology / Knowledge Graph
This page explains a second way to read the OpenIM model — not as a list of business capabilities, but as a map of things and the named connections between them. A few words are used a specific way below: entity, relationship, graph, and agent. Each one is defined the first time it appears, so no earlier knowledge of any of them is assumed.
What the map is
Start with an everyday road map. A road map shows places — towns, junctions — and the roads that connect them, and every road is labelled with where it leads. The OpenIM knowledge graph does the same thing for the investment world the model describes.
The "places" are called entities: a fund, a manager, a holding (a position an investor owns), an instrument (a tradeable or investable asset), a document, and every other thing the model keeps track of. The "roads" are called relationships: named, one-directional links that say how one entity connects to another. Three examples, in plain sentences:
- A fund is managed by a manager.
- A holding is a position in an instrument, and sits in a portfolio.
- A document has a subject: the entity it concerns.
Put the entities and their named relationships together and you get a graph: a network in which every entity is a point (called a node) and every relationship is a line between two points (called an edge), and every edge carries a label naming the connection it represents.
Why build this as a graph, alongside the capability breakdown that is the rest of this site? Because a computer program acting on someone's behalf — an agent — often has to answer a question by following a chain of connections rather than by reading one document start to finish. "Which manager runs the fund that holds this instrument?" is answered by walking three named links backwards: instrument → holding → fund → manager. A graph is a shape a program can walk one link at a time, the same way a person might follow a paper trail by hand.
The relation vocabulary: named links, and their inverses
Every relationship in the graph has two parts: a direction — which entity
it starts at, and which it points to — and a name that reads like a verb,
written in capitals (MANAGES, IN_PORTFOLIO, HAS_SUBJECT).
Because a named relationship only points one way, the model also gives every relationship a
named inverse: the same connection, read backwards. This matters because an
agent might arrive at either end of a connection first, and it needs to walk that connection
in whichever direction it is standing, without working out the reverse meaning from scratch
each time.
A short illustrative sample — the complete vocabulary ships in the graph description, linked below.
| Forward relationship | Reads as | Inverse relationship | Reads as |
|---|---|---|---|
MANAGES (Manager → Fund) | a manager manages a fund | MANAGED_BY (Fund → Manager) | a fund is managed by a manager |
IN_PORTFOLIO (Holding → Portfolio) | a holding sits in a portfolio | PORTFOLIO_INCLUDES (Portfolio → Holding) | a portfolio includes a holding |
POSITION_IN (Holding → Instrument) | a holding is a position in an instrument | HAS_POSITION (Instrument → Holding) | an instrument has a position held against it |
HAS_SUBJECT (Document → Entity) | a document's subject is the entity it concerns | SUBJECT_OF (Entity → Document) | an entity is the subject of a document |
A small example, drawn as a graph
The sentences above, drawn as a picture. Each box is an entity, each labelled arrow is a named relationship pointing from its start to its end.
The whole graph, explorable
The picture above shows six entities. The full model has many more, and every one of them — with every named relationship — is in the viewer below. It reads the same published graph the downloads at the bottom of this page contain (the RDF/XML export), so what you explore here is exactly what a program would load. Drag to pan, scroll to zoom, click an entity or a relationship to see its details.
The viewer is the embeddable component of the open-source Ontology Playground project (MIT licence), served from this site with no external requests.
The graph description: what an agent reads before it queries
Before an agent writes a single query against the graph, it needs to know what is there to ask about. That is what the graph description export is for: a short, machine-readable file that lists every entity type, every named relationship together with its inverse, and one plain sentence of what each one means. Reading it takes an agent a fraction of a second and tells it exactly which named links exist, so it never has to guess at a relationship's name or invent one that is not actually in the model.
The graph itself is published in several interchangeable formats, so it can be loaded into whichever tool an agent (or a person) already has to hand — a CSV table, a ready-to-run openCypher script, a SQL/PGQ or ISO GQL script, or a loader built for a specific database. Every format below describes exactly the same entities and the same named relationships.
Every graph download
- Nodes (CSV)
- Edges (CSV)
- openCypher script
- SQL/PGQ script
- ISO GQL script
- Graph description (JSON)
- Neo4j import — nodes (CSV)
- Neo4j import — edges (CSV)
- Snowflake script
Each link opens the matching card on the exports page, with a plain description of the format and what you would use it for.