What is an Ontology? Definition, Parts, Spatial Ontologies

An ontology is a formal model of a domain. It names the kinds of things the domain contains, their properties, and how they relate, precisely enough for software to check data against it. A spatial ontology adds location: each thing's shape, the coordinate system that places it on Earth, and relations such as contains, touches, and located in. This article tests a claim: for AI agents on the physical world, the useful ontology computes relations from geometry and records each one's confidence and provenance (how it was made).

Key takeaways

• An ontology defines classes, properties, relations, and rules for a domain, so people and software use the same meanings.
• A taxonomy is a hierarchy. An ontology adds other relations and logic. A knowledge graph is the data organized by an ontology.
• A spatial ontology adds each thing's shape, its coordinate system, relations such as contains and touches, scale, and time.
• Well-known ontologies include the Gene Ontology, schema.org, the Financial Industry Business Ontology (FIBO) for finance, and SNOMED CT, the Systematized Nomenclature of Medicine Clinical Terms, for medicine.

What is an ontology?

In philosophy, ontology is the branch of metaphysics that studies what exists. Computer science borrowed the term for a model you can write down and share. Tom Gruber's widely cited 1993 definition calls it an "explicit specification of a conceptualization" (his page about the definition of ontology). Later work added "shared", meaning a community agrees on it, and "formal", meaning a machine can parse it.

Stanford's Ontology Development 101 guide, by Natalya Noy and Deborah McGuinness, gives the working definition. An ontology is a formal explicit description of the concepts in a domain (classes), the properties of each concept (slots), and restrictions on those properties (facets).

Why ontology is back in AI

Language models were trained on text, documents, databases, and the internet. They have no built-in agreement about what an "asset", a "site", or a "customer" means in a given company. A data ontology supplies it by defining each business concept once and linking it to the tables that hold its data. Microsoft describes the ontology item in Fabric IQ as a shared, machine-understandable representation of a business. It is bound to enterprise data, so people, applications, and AI agents use the same vocabulary. Palantir uses the word in the same sense for the ontology layer of its Foundry platform.

Ontology examples

Widely used ontologies include:

• Gene Ontology: describes what genes and gene products do in three linked ontologies, molecular function, biological process, and cellular component. Michael Ashburner and the Gene Ontology Consortium introduced it in Gene Ontology: tool for the unification of biology (Nature Genetics, 2000) as a shared vocabulary for all eukaryotes.
• schema.org: a vocabulary of types such as Person, Place, Event, and Product that websites use to mark up their pages. Bing, Google, and Yahoo! launched it in June 2011, and Yandex joined that November (Schema.org: Evolution of Structured Data on the Web, Communications of the ACM).
• FIBO: the Financial Industry Business Ontology, published by the Enterprise Data Management (EDM) Council. It is written in OWL, the Web Ontology Language, in the OWL 2 DL (description logic) profile. It defines financial instruments, legal entities, and contracts and how they relate.
• SNOMED CT: a clinical terminology maintained by SNOMED International. Its concepts sit in an "is a" hierarchy and carry defining attributes: viral pneumonia has a causative agent of virus and a finding site of lung.

Geographic examples include GeoNames and the Open Geospatial Consortium (OGC) standard GeoSPARQL.

The parts of an ontology

Classes

Classes are the kinds of things in the domain: Place, Building, Address, Road segment, Administrative division. Classes form hierarchies. A Bakery is a subclass of Place, so every bakery is also a place.

Properties and relations

Datatype properties attach values, such as a building's height in meters. Object properties connect two things, such as located_in from a Place to a Building. Each relation has a domain, the class it starts from, and a range, the class it points to. Software uses them to catch data that makes no sense.

Individuals

Individuals, or instances, are the actual things: the San Francisco Ferry Building, a specific bakery, a specific street address. They live in the data, typed by the ontology's classes.

Axioms and rules

Axioms state what must be true. Two classes can be disjoint (nothing is both a road and a building). A relation can be transitive: if a bakery is inside the Ferry Building and the Ferry Building is inside San Francisco, the bakery is inside San Francisco. A reasoner, software that applies axioms, checks that data is consistent and derives facts that were never written down.

Ontology engineering

Ontology engineering is the work of designing, building, and maintaining an ontology. Ontology Development 101 treats it as an iterative process. There is no one correct way to model a domain, and the first version almost always needs revision once people use it. The guide lays out seven steps:

1. Determine the domain and scope. Write competency questions: the questions the ontology must be able to answer.
2. Consider reusing existing ontologies.
3. List the important terms in the domain.
4. Define the classes and the class hierarchy. Work top down from general classes, bottom up from specific ones, or both.
5. Define the properties of each class, which the guide calls slots.
6. Define the facets of each slot: its value type, its allowed values, and how many values it can hold (its cardinality).
7. Create instances.

How ontologies are written

The World Wide Web Consortium (W3C) standards stack is the common format:

• Resource Description Framework (RDF) stores facts as subject, predicate, object triples.
• RDF Schema adds classes, subclasses, domains, and ranges.
• OWL 2, a W3C Recommendation (second edition, 2012), adds richer logic such as disjointness, cardinality, and property characteristics.
• SPARQL (SPARQL Protocol and RDF Query Language) queries RDF data.

The Wherobots graph below stores an ontology as typed tables and edge lists in a lakehouse.

Ontology vs taxonomy vs schema vs knowledge graph

	Taxonomy	Schema	Ontology	Knowledge graph
What it holds	A hierarchy of terms	Table or document structure	Classes, relations, properties, rules	Entities and links (instance data)
Relations	Broader and narrower only	Foreign keys	Any named relation	Edges typed by the ontology
Meaning and inference	Little	Storage constraints	Logic a reasoner can use	Inherits the ontology's meaning
Typical technology	Category lists, SKOS (Simple Knowledge Organization System)	SQL DDL (data definition language), JSON Schema	RDF, OWL, typed edge tables	Graph databases, edge tables
Spatial example	Building, then Commercial, then Office	A buildings table with a geometry column	Place located_in Building	Acme Bread Company located_in Ferry Building

A semantic layer, a business intelligence term, overlaps with an ontology: both name business concepts consistently. A semantic layer usually centers on metrics and joins for reporting.

What makes an ontology spatial?

A general ontology can say that a store is in a city. A spatial ontology also says where, with what geometry and coordinate system, and how the store relates to everything around it.

Geometry as a first-class concept

OGC GeoSPARQL defines an RDF vocabulary for geospatial data and an extension to SPARQL for querying it. Its core separates a Feature (the thing, such as a building) from its Geometry (the shape). Properties such as geo:hasGeometry, geo:hasCentroid, and geo:hasBoundingBox link the two. One feature can have several geometries, such as a point and a footprint. The current version, GeoSPARQL 1.1, was published on 29 January 2024.

Topological relations

GeoSPARQL includes the Simple Features, Egenhofer, and Region Connection Calculus (RCC8) families of relations between shapes and states how they correspond:

• Simple Features relations: equals, disjoint, intersects, touches, crosses, within, contains, and overlaps. These are the same predicates a spatial join uses in SQL, such as ST_Contains and ST_Intersects.
• Egenhofer relations: based on Max Egenhofer's intersection models, which compare the interiors, boundaries, and exteriors of two geometries. The Dimensionally Extended 9-Intersection Model (DE-9IM) is what ST_Relate returns.
• RCC8: the Region Connection Calculus (Randell, Cui, and Cohn, 1992) defines eight relations between regions, from disconnected to non-tangential proper part (one region inside another without touching its edge). Its composition table lists which relations can hold between A and C given the relations from A to B and from B to C.

GeoSPARQL's query rewrite extension computes a relation such as geo:sfIntersects from the two features' geometries. Nobody has to store the relation as a fact.

Coordinates, scale, and time

A geometry has no location without a coordinate reference system (CRS). GeoSPARQL stores a shape as well-known text (WKT), which can start with a CRS identifier. When it does not, GeoSPARQL 1.1 assumes CRS84, the identifier for longitude and latitude on WGS 84, the World Geodetic System 1984. An ontology handles scale with several geometries per feature and with containment hierarchies. Overture's divisions theme runs from country down to microhood, each division inside its parent. GeoNames models the same hierarchy with parentFeature. Time matters because buildings are demolished and boundaries redrawn. W3C OWL-Time lets each fact carry the period when it was true.

Stable identity with Overture's Global Entity Reference System

Relations stay joinable across datasets when each dataset refers to the same thing by the same ID. Overture's Global Entity Reference System (GERS) assigns a stable identifier to each feature in its reference map. Anyone who matches their data to a feature once can join on the identifier afterward. Wherobots shows how in How to use GERS IDs in Wherobots.

Why spatial ontologies matter for AI agents

Language models encode a great deal of geographic knowledge. The GeoLLM paper (ICLR 2024) found that naively querying language models using geographic coordinates alone is ineffective. An agent working on the physical world needs entities with types, stable IDs, geometry, and explicit relations it can query. A spatial ontology and its knowledge graph provide them.

Spatial knowledge graphs and Graph RAG

Knowledge graphs built from text capture what someone wrote. Many physical-world relations, such as which buildings sit inside a flood zone, must be computed from geometry, as a spatial knowledge graph does. Each spatial predicate in a spatial join produces a typed relation: ST_Contains gives located_in, ST_Touches gives adjacent_to, and ST_DWithin or ST_KNN gives near. Wherobots describes the approach in Spatial Graph RAG for the physical world. Graph RAG (retrieval-augmented generation over a graph) passes the part of the graph matching a question to a model as context.

Conflation is deciding which records in different datasets describe the same thing. The Overture Maps Foundation calls the cost of redoing it in every project the "conflation tax". In Grounding AI and LLMs with Overture's cross-theme knowledge graph, it describes ORATOR, a prototype built by Overture member Wherobots. ORATOR follows the principle that geometry is the foreign key: records are linked by where their shapes sit. Its choices on confidence, provenance, and inherited relations suit any spatial ontology:

• Confidence on every edge. Strict containment scores 1.0 and weaker spatial evidence scores lower. Address linking runs containment and street-name matching first at 1.0, then a proximity fallback scored 0.6 to 0.95.
• Provenance on every edge, so a model can trace why two entities were connected.
• Inherited relations. A place inherits the road access of the building that contains it. This cut San Francisco access edges from a possible 610,000 to about 172,000.

Ontologies in Wherobots

Wherobots publishes the ORATOR prototype graph in its open data catalog as wherobots_open_data.spatial_knowledge_graph. It has node and edge tables for San Francisco (nodes_sf, edges_sf) and Manhattan (nodes_manhattan, edges_manhattan). Nodes taken from Overture use GERS IDs, so they join back to Overture data in the Havasu catalog. The San Francisco tables hold 170,965 buildings, 55,134 places, 387,872 addresses, 83,765 road connectors, and 102 divisions. They also hold 16,151 snap points: points on road segments where the graph attaches a building's road access, with IDs assigned when the graph was built.

The queries below read two Havasu tables:

Source	Rows	What the queries read
nodes_sf	713,989 nodes	id, type, name, category of buildings, places, and snap points (the SQL reads it as buildings b and as places p)
edges_sf	5,403,778 edges	src, dst, type, and properties of located_in and access edges

A query in Wherobots returns the main relations and the node types each connects. This is the ontology's domain and range, read from the data:

Relation	From	To	Edges
has_address	Building	Address	387,826
near	Building	Building	301,433
access	Building	Snap point	144,320
located_in	Place	Building	54,675
has_address	Place	Address	53,308
road	Connector	Connector	48,800
same_as	Place	Place	11,839
contains	Division	Address, building, connector, place	4,330,832

A two-hop question shows why typed relations help. This query finds the San Francisco Ferry Building and counts the places located in it, by category:

SELECT p.category, COUNT(*) AS places
FROM wherobots_open_data.spatial_knowledge_graph.nodes_sf b
JOIN wherobots_open_data.spatial_knowledge_graph.edges_sf e
  ON e.dst = b.id AND e.type = 'located_in'
JOIN wherobots_open_data.spatial_knowledge_graph.nodes_sf p
  ON p.id = e.src AND p.type = 'place'
WHERE b.type = 'building' AND b.name = 'San Francisco Ferry Building'
GROUP BY p.category
ORDER BY places DESC
LIMIT 5

category	places
bakery	8
farmers_market	7
(none)	5
coffee_shop	5
food_truck	4

The building has 112 places. Each edge records its method and confidence in a properties column, such as {"method":"proximity","confidence":0.956}. Of these, 86 fall inside the building polygon (confidence 1.0) and 26 were matched by proximity (0.554 to 1.0). Across San Francisco, 36,351 located_in edges come from containment and 18,324 from proximity.

Each extra hop in SQL adds another join. GraphFrames, the DataFrame-based graph library for Apache Spark, writes multi-hop questions as path patterns, called motifs. It runs in the same Wherobots session as the SQL that built the graph. The tables already use the column names GraphFrames expects, id on nodes and src and dst on edges, so they load without renaming:

from graphframes import GraphFrame
from pyspark.sql import functions as F
from sedona.spark import SedonaContext

config = SedonaContext.builder().getOrCreate()
sedona = SedonaContext.create(config)

skg = "wherobots_open_data.spatial_knowledge_graph"
g = GraphFrame(sedona.table(f"{skg}.nodes_sf"), sedona.table(f"{skg}.edges_sf"))

# One hop: places located in the Ferry Building, by category
ferry = g.find("(p)-[e]->(b)").filter(
    "e.type = 'located_in' AND b.name = 'San Francisco Ferry Building'"
)
ferry.groupBy("p.category").count().orderBy(F.desc("count")).show(5)

# Two hops: from each place, through its building, to the road network
reach = g.find("(p)-[e1]->(b); (b)-[e2]->(s)").filter(
    "e1.type = 'located_in' AND e2.type = 'access' "
    "AND b.name = 'San Francisco Ferry Building'"
)
reach.groupBy("s.id").count().show()  # one snap point, 112 paths

The motif (p)-[e1]->(b); (b)-[e2]->(s) reads as the question itself: a place located in a building that has road access. All 112 Ferry Building places resolve to the same snap point, about 60 meters away on a primary road. This is ORATOR's inherited access applied in a query.

To build a graph for another area, compute the same edges from Overture tables with the spatial joins listed earlier. Take containment from the divisions hierarchy, which the wkls library for global administrative boundaries looks up by name. With the Wherobots Model Context Protocol (MCP) server, an AI coding tool can find these tables in the catalog and run traversals in plain language.

Graphs, spatial analysis, and ontology research

Much of geospatial analysis computes over a graph of neighbors. A spatial ontology gives that graph typed nodes and named relations.

Spatial statistics run on neighbor graphs

Tobler's first law of geography (1970) says that near things are more related than distant things. Spatial statistics apply it with a spatial weights matrix, which records which observations count as neighbors and how strongly. That matrix is the adjacency matrix of a graph, a table of which nodes link to which. Rook contiguity links polygons that share an edge. Queen contiguity adds those that share a corner. Distance bands link everything within a threshold. K-nearest neighbors links each point to its closest k.

Moran's I (1950) and Geary's C (1954) measure spatial autocorrelation over that graph, meaning how much neighbors resemble each other. Luc Anselin's Local Indicators of Spatial Association (1995) compute one value per node from its neighbors. Hot spot and outlier maps are made this way. Spatial regression models put the same matrix inside a regression. The libpysal Graph class of PySAL, the Python Spatial Analysis Library, encodes spatial weights matrices. In Wherobots, ST_BinaryDistanceBandColumn and ST_WeightedDistanceBandColumn build distance band neighbor lists, and ST_GLocal computes Getis-Ord Gi and Gi* hot spot statistics over them.

Graph queries with spatial predicates

Many questions about a graph with locations mix a traversal with a spatial filter, such as which entities linked to a building lie within a region. Graph databases are built for traversals and spatial databases for spatial filters. Running both efficiently in one query is hard. Yuhan Sun and Mohamed Sarwat at Arizona State University's Data Systems Lab study that gap:

• GeoReach (2016) answers whether a vertex can reach any vertex inside a region, using a compact summary of the area each vertex can reach.
• GeoExpand (GeoInformatica, 2019) adds a spatially pruned expansion operator to the Neo4j graph database.
• Riso-Tree (ACM Transactions on Spatial Algorithms and Systems, 2021) indexes the spatial entities in a graph database. Queries that combine graph patterns and spatial filters can then skip paths early. It was evaluated on Wikidata.
• Spindra (Sun, Jia Yu, and Sarwat, ICDE 2019) packages these ideas as a geographic knowledge graph management system with a map interface.

Computing spatial relations at scale

Every edge in a graph like ORATOR comes from a spatial join, and San Francisco alone has 4,330,832 contains edges. Jia Yu, Jinxuan Wu, and Mohamed Sarwat introduced GeoSpark (ACM SIGSPATIAL 2015). Yu, Zongsi Zhang, and Sarwat described its spatial partitioning, indexing, and spatial join design in Spatial data management in Apache Spark (GeoInformatica, 2019). GeoSpark became Apache Sedona, and Yu and Sarwat went on to found Wherobots. The distributed spatial joins that produce ORATOR's edges come from that work.

Roads are graphs

Road networks are the most studied spatial graphs. Marc Barthélemy's review Spatial networks (Physics Reports, 2011) describes them as close to planar: few roads cross without an intersection. Porta, Crucitti, and Latora's primal approach (2006) measures centrality with intersections as nodes and street segments as edges. Geoff Boeing's OSMnx builds these graphs from OpenStreetMap.

Network distance often differs from map distance. Okabe and Sugihara's Spatial Analysis Along Networks (Wiley, 2012) adapts density and clustering statistics to road distance. An isochrone is the area reachable within a travel time, and Wherobots computes it with ST_Isochrone. In the ORATOR graph, the access edges to snap points connect the place graph to the road graph.

Grids are graphs too

Discrete global grids turn the planet into a graph of cells. In H3, gridDisk returns every cell within k steps, and gridDistance returns the number of steps between two cells. Wherobots exposes these as ST_H3KRing and ST_H3CellDistance. Cells also work as a shared join key. KnowWhereGraph precomputes topological relations between its features and S2 cells to integrate data.

Conflation is a graph problem

Conflation can run on a graph. Records become nodes. Candidate matches, scored by distance, name, and category, become edges. Connected components, the groups of nodes linked by any path, then gather the records that refer to one place. He, Li, and Zhang (2024) fuse semantic and spatial signals for this matching. GraphFrames provides connected components at Spark scale. Wherobots adds spatial versions such as ST_IntersectsCC and ST_DWithinCC. The San Francisco graph's 11,839 same_as edges are candidate links of this kind, for a conflation step to confirm or reject.

Machine learning on spatial graphs

Graph neural networks compute a vector for each node from its neighbors, which suits spatial data. Li and colleagues' DCRNN (2018), a diffusion convolutional recurrent neural network, forecasts traffic on graphs of road sensors. So does Yu, Yin, and Zhu's STGCN (2018), a spatio-temporal graph convolutional network. Google reported estimated time of arrival (ETA) prediction with graph neural networks in production in Google Maps (CIKM 2021). Knowledge graph embeddings, vectors that stand for each entity, can include location too. A location-aware knowledge graph embedding model called SE-KGE (Mai and colleagues, 2020) encodes each entity's location and extent for geographic question answering. Janowicz and colleagues call this direction spatially explicit AI.

Geographic knowledge graphs

ORATOR joins a line of geographic knowledge graphs, including YAGO2 (Yet Another Great Ontology, version 2), WorldKG (built from OpenStreetMap), KnowWhereGraph, and UUKG for urban prediction tasks.

Conclusions

The San Francisco graph shows what an ontology for physical-world data needs beyond classes. It needs relations computed from geometry, each with a method and confidence, stable IDs, and tables that both SQL and graph queries read.

1. Use an ontology when software must check relations and rules. A taxonomy cannot say that a place is located in a building. A knowledge graph holds the ontology's instances.
2. A spatial ontology computes its relations with spatial predicates such as ST_Contains and ST_DWithin. The Ferry Building's 112 located_in edges came from 86 containment and 26 proximity matches.
3. A spatial ontology needs a method and confidence on every relation. A query can separate San Francisco's 36,351 containment and 18,324 proximity located_in edges only because each edge records it.
4. A spatial ontology needs stable identifiers such as GERS IDs, so nodes join back to the full feature tables.
5. An ontology can live in a lakehouse as typed tables with id, src, and dst columns, queried one hop in SQL and many hops as GraphFrames motifs.
6. A spatial ontology should treat proximity and same_as edges as candidates for a conflation step to confirm or reject. The queries report confidence but no reference labels, so this article does not measure their precision.

Related terms

• Spatial join: the operation that computes spatial relations between datasets
• Coordinate reference system: what gives a geometry its location
• Physical AI: AI grounded in real places and objects
• Context engine: where an ontology meets the data behind AI context
• Geospatial AI: models and agents that work with geospatial data
• Geospatial data: the data a spatial ontology describes
• Point of interest (POI) data: the places that fill a spatial knowledge graph
• Building footprint: the geometry behind the building nodes
• H3: the hexagonal grid whose cells form a graph

Read more from Wherobots

• Spatial Graph RAG for the physical world
• From concept to prototype: grounding AI and LLMs with Overture's cross-theme knowledge graph (Overture Maps Foundation)
• Advancing the integration of map data via Overture's Global Entity Reference System and Wherobots
• Introducing developer tools that let AI build with physical world data

Query the spatial knowledge graph with a Wherobots free trial at cloud.wherobots.com.