I spend a lot of my time arguing that the API economy has a reuse problem. Every team rebuilds the same bounding box parameter, the same pagination scheme, the same error object, the same link relation, slightly differently, forever. We talk about it constantly and we almost never ship the thing that would actually fix it: a shared, machine-readable, testable register of the pieces everybody keeps rebuilding. So I went digging through OGC’s Location Building Blocks this week, and the geospatial community has quietly built exactly that register while the rest of us were still writing blog posts about wanting one.
The framing they lead with is the one I have been making for years, right down to the example. Everybody who has ever handled a bounding box has had to decide the coordinate order, which corners to use, and how to carry the coordinate reference system, and everybody has decided slightly differently. OGC’s answer is not another 400-page document telling you the right way. It is a building block, a small, self-contained, testable interface component that you can adopt directly. A block can be a whole API standard, a single part of one, or something as granular as the bbox parameter or a datatype. “Let’s not reinvent the wheel” is their actual pitch, and they backed it with infrastructure instead of a slogan.
What makes this worth paying attention to is not the idea, it is the packaging. Each building block is a folder with a bblock.json metadata file that declares its identity, dependencies, and status, a JSON Schema that defines the content model, a JSON-LD context that gives the schema semantic meaning, worked examples, and test cases. Then a postprocessing pipeline validates all of it, unit-tests the validation, checks the examples against the schema, verifies rules and constraints through the semantic annotations, and even tests transformations and alignments to other specifications. A block that depends on another block inherits its rules. Every entry in the register carries whether its validation passed. This is what reuse looks like when you take it seriously: not a wiki of recommendations, but a CI pipeline that refuses to publish a component that does not hold together.
And it is genuinely a register, in the sense I keep insisting APIs need. There is a machine-readable index at the center of it, where each block has a stable dotted identifier like ogc.geo.common.data_types.bounding_box, a maturity level, links to its YAML and JSON schema, its source schema, its JSON-LD context, human documentation, and its dependency graph. It is discoverable by a human in a browser and by a machine over HTTP with equal ease. Better still, the design explicitly supports federation, so a local register in one domain can be transparently composed with others. That federation model is the part most people will underestimate, and it is the part that matters most, because it means this pattern is not a geospatial trick. It is a template any domain could stand up for its own building blocks and then wire into everyone else’s.
The part I keep coming back to is the JSON-LD context on every block, because that is what makes this legible to an agent instead of just to a developer. A bare JSON Schema tells a machine the shape of a bounding box, that it has four numbers and maybe a CRS. The semantic uplift tells it the meaning, that these numbers are a spatial extent, that this field is a coordinate reference system with a known identity, that this component is the same concept as one defined in another specification. That is the difference between an agent that can validate a payload and an agent that can actually reason about it, compose it with something else, and know when two APIs are talking about the same thing under different field names. Most of the API descriptions an agent encounters today carry no meaning at all, so the agent guesses from field names and prose, and guessing is where agents get things quietly wrong. A registered, semantically-uplifted building block is a piece an agent can pick up and trust.
Follow that thread and the register stops being documentation and becomes a supply of assembly parts an agent can build from. Because each block is tested, carries its dependencies, declares whether its validation passed, and states its own meaning, an agent does not have to reverse-engineer intent from a PDF or a naming convention. It can discover a block over HTTP, resolve its dependency graph, read its context to understand what it is, check the examples, and assemble a correct interface out of components that were proven to hold together before it ever arrived. This is the machine-readable, agent-native surface I keep telling standards bodies they need, except OGC did not bolt it on as an afterthought. It fell out of the packaging, because a block that is validated and semantically annotated for a human pipeline is, without any extra work, a block an agent can consume.
This lands right in the middle of the work I care about most. The API Commons reusability tooling I have been building is trying to measure exactly the duplication that OGC’s register is trying to prevent, and a canonical set of building blocks is the missing yardstick to measure reuse against rather than just spotting duplication after the fact. On the discovery side, this is APIs.json thinking applied one level down: OGC indexes the reusable interior components of APIs, where APIs.json indexes the APIs and their artifacts, and the two are complementary halves of the same discoverability problem. The JSON-LD semantic uplift maps cleanly onto the vocabulary work I have been doing, because meaning that lives in the component travels with it into every register that federates it. And the whole validated-or-it-does-not-publish discipline is the governance toolchain argument I keep making, just aimed at components instead of whole descriptions.
The potential here, for me and for anyone serious about API reuse, is to stop treating OGC Building Blocks as a geospatial curiosity and start treating it as a proven reference implementation of a pattern the broader API space badly needs. Imagine a payments building blocks register, a healthcare one, a government one, each with its own bbox-equivalent primitives packaged with schema, context, examples, and tests, each federated so a component defined once is discoverable everywhere. Imagine apis.io indexing building blocks as a first-class artifact type alongside OpenAPI, AsyncAPI, and Arazzo. Imagine a reuse score that grades an API by how much of it is assembled from registered, tested components versus reinvented from scratch. And imagine an agent that no longer has to guess what an API means, because it can assemble against federated registers of semantically-annotated components that each declare their own meaning and prove their own validity before it ever makes a call. None of that requires inventing anything new. OGC already shipped the blueprint, and it works. The rest of us just have to notice, and then do the unglamorous work of building the registers for the domains we care about, which happens to be exactly the kind of discovery and standards work I do all day.
