POOLE entity graph

POOLE stores entities rather than rows of data: a person, an organisation, an object such as a facility or a camera, a location, and an event, with typed relations between them. Feeds write into it — hazard events, disaster records, public-order incidents, news coverage, ports, airports, maritime zones and administrative regions.

The point is not a graph for its own sake. It is that an earthquake, the organisation that responds to it, the port inside the affected radius and the reporting about it are held as one connected set instead of four unrelated records in four systems with no way to travel between them.

• Person — officials, office holders and other named individuals, with the relations that place them.
• Organisation — institutions and bodies, including the units that sit inside them.
• Object — facilities, ports, camera sites and other physical things the platform tracks.
• Location — administrative regions, ports, airports and waterway boundaries, at the level an incident is reported.
• Event — hazard, disaster and incident records, with their date and place attached.

The same place is named differently across sources: with and without a prefix, misspelled in a news feed, written in an older spelling. The graph resolves names against a canonical index built from authoritative location sources — normalising the string first, then falling back to a similarity match against the index, with a blocklist that rejects candidates which are not places at all.

Resolution is the step that keeps the graph honest. A name that resolves successfully attaches to the entity that already exists, and only a genuinely new name creates a new record, so the graph grows with coverage rather than with duplicates.

• Canonical identity — every resolved entity keeps a canonical identifier, and other sources point at it.
• Similarity fallback — unresolved names are matched against the index by string similarity above a configured threshold.
• Blocklist — candidates that are not place names are rejected before they can become entities.
• Administrative coverage — provinces, regencies and districts are registered as locations.
• Proximity queries — entities within a radius of a point are found by distance, which is how 'what is near this event' is answered.

Any event view can be read through the graph: the related entities grouped by type, with the relations that connect them. From a disaster record you reach the organisations that respond, the facilities and ports inside its radius, the administrative area that contains it, and the coverage written about it.

Search runs the other way as well. An entity can be opened directly and walked outwards through its relations, which answers a question like 'what else involves this organisation' without a query language and without leaving the map.

A point on a map is a fact; the graph is how that fact connects to the people, places and reporting around it.

Scheduled sync jobs move data into the graph: locations from administrative regions, ports, airports, maritime zones and camera sites; events from hazard, disaster and incident records; persons and organisations from public institutional and leadership data; and the entity mentions extracted from every enriched article. Each job runs on its own schedule rather than being triggered by hand, so the graph keeps pace with the feeds even when nobody is watching it.

Ingestion is incremental and repeatable, so a source that updates many times over a day adds relations rather than duplicates. New entity types can be registered without disturbing the ones already in use, which is what lets the graph grow with the platform instead of being rebuilt around it.

• Locations — administrative regions down to district level, plus ports, airports and waterway boundaries.
• Events — hazard, disaster and incident records promoted into event entities with their date and place.
• Persons and organisations — built from public institutional and leadership records, linked to the places they relate to.
• Media entities — names extracted during article enrichment, promoted to canonical entities instead of staying as flat text.

Duplicates are the natural failure mode of any graph built from many feeds, so the platform treats them as a maintenance task rather than an accident. Every entity carries its source, a canonical identifier and the relations it participates in, and a mistaken duplicate can be merged into the record it should have joined.

Because the merges are recorded, the graph can be audited after the fact: an entity's history shows what was attached to it, and a resolved name can be traced back through the source that produced it. That audit trail is what separates a maintained graph from an accumulation of records.

The graph is built from sources that are public or supplied by the operator, and it inherits their limits: a place that is not in the reference data cannot be resolved to one, and a feed that never publishes coordinates cannot contribute geography. Those are boundaries rather than defects, and the platform reports them instead of papering over them.

Resolution thresholds are configured rather than hidden, so a stricter setting produces fewer, cleaner matches and a looser one catches more spellings at the cost of more review. That choice belongs to the operator, and it is visible in the configuration rather than buried in the code.