Why four kinds#
A knowledge graph built by agents from thousands of web pages lives or dies on consistency. Let a model invent entity types and one page yields a company, the next an organisation, the third a firm — and nothing downstream can be queried. Nolvin fixes the vocabulary at four kinds and gives each kind a shape.
The POLE model — Person, Object, Location, Event — comes from policing and intelligence analysis, where it has long been used to link who, what, where and when. The same four questions describe a conference circuit, a local industry, an investor network or a cultural scene. Nolvin applies them to the open web.
The four kinds and their facets#
Every entity has a name, a kind, a description written in the domain's language, an optional canonical URL, aliases, and a facet: the structured fields that fit its kind.
| Kind | What it covers | Facet fields | What the facet enables |
|---|---|---|---|
| person | Founders, teachers, investors, artists, speakers — people who act in the domain | role, aliases | People search, “who does what” |
| object | Organizations, companies, funds, programmes, products, courses, publications | category, identifier | Catalog-style filtering |
| location | Venues, offices, retreat centres, cities, regions | lat, lng, address | Geospatial queries and GeoJSON maps |
| event | Festivals, workshops, conferences, funding rounds, exhibitions — anything dated | starts_at, ends_at | Timelines and date-range filters |
Facets are filled only with what a page states. The extraction agent is told never to guess coordinates or dates; locations without coordinates are geocoded from their address in a separate, deterministic step.
Projections: every kind on a timeline and a map#
Events are the graph's temporal backbone and Locations its spatial one. Every other kind projects onto them through its relationships:
- A person appears on the timeline through the events they organize, teach or take part in.
- An event appears on the map through the location it is held at.
- An object — an organization — gets both: its events on a timeline, its offices and venues on a map.
The API exposes this directly: GET …/timeline?entity_id= and GET …/geo.geojson?entity_id= work for any entity, and the domain-wide timeline and map carry each item's connected entities. See Querying the graph.
Canonical relations#
Free-text predicates make edges unqueryable — one early graph held invested_in, invests_in and funded_by for the same fact, across 268 distinct predicates. Nolvin stores every edge under one of 15 canonical predicates with a canonical direction, and keeps the source's own wording as raw_relation.
| Predicate | Typical direction |
|---|---|
works_at | person → object |
leads | person → object or event |
founded | person or object → object |
member_of | person or object → object |
part_of | object → object, event → event, location → location |
located_at | anything → location |
organizes | object or person → event |
teaches | person → event or object (courses, workshops) |
participates_in | person or object → event |
invested_in | object or person → object |
partner_of | object ↔ object |
owns | object or person → object or location |
operates | object or person → object or location |
offers | object or person → object (programme, course, product) |
related_to | fallback when nothing more specific fits |
Synonyms in English and Swedish (employed_by, hosted_by, grundade …) are mapped in code, including direction: “organized by” becomes organizes with source and target swapped.
Custom attributes#
Some domains need a field the facets do not have. Ask for “locations, contact info, descriptions” in the autopilot prompt and the brief declares custom attributes — email and phone — on the domain. Up to six per domain, each tied to the kinds it applies to.
Contact details are exactly what a language model invents, so attribute values are kept only when they appear verbatim on the page the model read, and only when they have the right shape for their key: an email must look like an email, a phone number must have at least seven digits. Values are returned on the entity and in exports.
Provenance on every fact#
Every entity and relationship records which page produced it and a short verbatim snippet supporting it. A graph you cannot audit is a graph you cannot trust; provenance is also what keeps it current. When a page stops mentioning an entity, the page's support is withdrawn; an entity with no remaining support is marked, and removed after 21 days unless a source mentions it again.
An example neighborhood#
From the tantric events in Sweden graph: a festival (event) with dates, located_at a retreat centre (location) with an address, organizes-linked to the association that runs it (object), and the teachers (person) who teaches its workshops — each edge quoting the programme page it came from. Ask for that festival's neighborhood and you get the organizer's other events on a timeline and every venue on a map.
Questions#
What does POLE stand for?
POLE stands for Person, Object, Location, Event — the four kinds of entity every Nolvin knowledge graph is built from. Organizations, products, programmes and funds are Objects; venues, offices and cities are Locations; anything with a date worth putting on a timeline is an Event.
Where does the POLE model come from?
POLE is a long-standing data model in policing and intelligence analysis, where investigators link people, objects, locations and events to see how a case fits together. Nolvin applies the same four kinds to open-web knowledge: the model is small enough for a language model to apply consistently, and general enough to describe almost any domain.
Can I use my own ontology instead of POLE?
Yes. POLE is the default, but a domain's ontology is configurable through the API. Most domains keep POLE and add custom attributes for the fields they need, which keeps timeline and map projections working.
Why not a free-form knowledge graph with any entity type?
Free-form types fragment: the same thing gets typed as company, organization, firm and business on different pages, and nothing can be queried reliably. Four kinds with per-kind facets give every entity a predictable shape — dates on events, coordinates on locations, roles on people — which is what makes timelines, maps and filters possible.
How are relationships between entities named?
Every edge is stored under one of 15 canonical predicates (works_at, leads, founded, member_of, part_of, located_at, organizes, teaches, participates_in, invested_in, partner_of, owns, operates, offers, related_to) with a canonical direction. The wording the source used is kept alongside as the raw relation.
How do I know where a fact came from?
Every entity and relationship carries provenance: the page that produced it and a short verbatim quote from that page. The entity detail endpoint returns up to 50 provenance rows, newest first.