Open Knowledge Graphs: A Search Engine for Ontologies, Controlled Vocabularies, and Semantic Web Tools

A daily-refreshed catalog of knowledge graph resources built on Wikidata

Open Knowledge Graphs (OKG) is a small project with a simple bet: the semantic web already has a lot of good stuff in it, and the main problem is finding what works.

If you want to build a knowledge graph, one of your goals is probably alignment. The first thing you should do, then, is build upon what’s already out there and align with an existing ontology or vocabulary. Many of these ontologies, taxonomies, and vocabularies are well designed and actively maintained.

Discovering them is surprisingly difficult.

OKG tries to fix that. Today (March 2026), OKG indexes:

• 1,803 ontologies/vocabularies
• 165 semantic web software tools
• 660 indexed pages

Here are the links to the site, the API, and the source code in GitHub.

• Website: https://openknowledgegraphs.com/
• API: https://api.openknowledgegraphs.com/
• Source code: https://github.com/SteveHedden/open-knowledge-graphs

There’s already community interest — someone has already built an MCP server for OKG.

Knowledge graphs are structured representations of entities and the relationships between them. Here’s a post I wrote recently defining knowledge graphs and what they’re good for.

The primary reasons I love them are:

1. They have many applications: You can use them for search and retrieval; discovery and design; reuse and repurposing; decision support; recommendation and personalization; and governance, traceability and regulatory compliance.
2. They are both orthogonal and complementary to the AI that is ubiquitous today: Modern AI systems (especially generative models) are predictive, probabilistic, and unexplainable. KGs are rules based, deterministic, and traceable.
3. They are founded and largely based on open standards: Knowledge graphs are intimately connected to the semantic web. The semantic web was the original vision for the world wide web, where humans and machines consume and contribute to the web, to enhance our collective knowledge.

Why does OKG exist?

• It is hard to find these resources: If you want to find semantic web tech or prebuilt knowledge graph resources like ontologies or controlled vocabularies, good luck. Wikidata is the best resource I found, which is why OKG is built on their data.
• We should build on what works: As AI makes it easier to create ontologies and vocabularies, let’s build on what’s already been built. AI can build you a taxonomy from scratch about any topic and probably do a pretty good job. It will get better in the future. But it would do an even better job if it looked at an existing taxonomy in the same domain. And maybe, it wouldn’t need to build one at all and you could just use one that already exists.
• As generation becomes effortless, coordination becomes more important: As AI makes it easier to generate resources from scratch, the ability to discover, coordinate, share, align, and collaborate becomes even more important, even if it is AI doing the discovery and coordination.
• Knowledge graphs are meant to expand knowledge: The vision of the semantic web is that we consume and contribute. If you find the off-the-shelf taxonomy had most of what you wanted but you improved it, you can write that back to the web for others to learn from. Rather than every agent building the same taxonomy, we can learn from each other.

Principles

• Surface knowledge that already exists instead of creating new lists
• Structure the catalog itself as a graph
• Rank resources using objective metadata signals
• Provide API access so agents can query it directly

What is OKG?

The idea is simple. A list of all existing ontologies, taxonomies and other controlled vocabularies (glossaries, dictionaries, etc.) as well as semantic web software like visualization and creation tools.

This list already exists, in a way, in Wikidata. Wikidata is the sister of Wikipedia and it is the largest free and open knowledge graph. It has over 120 million data entities that anyone can edit. It is a graph which means you query it using SPARQL. Here is the SPARQL query service.

SELECT ?item ?itemLabel WHERE {
  ?item wdt:P31 wd:Q324254 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

This query finds all entities (think pages in Wikipedia) that are instances of “ontology.” In other words, all ontologies. It returns over 500 entries. You can do the same for “controlled vocabularies” or “semantic web software.” “Controlled vocabulary” is a broad term that covers glossaries, thesauri, cadastres, and many others. Taxonomies are not subclasses of ontologies or controlled vocabularies in Wikidata.

Data model

Using the inherent structure in Wikidata, we can build a model of these resources:

Ontologies
Taxonomies
Semantic Software
Controlled Vocabularies
-- Thesaurus
-- Glossaries
-- Cadastres

The structure above is the structure of the core ontology of OKG. These classes are populated by instances of each. We categorize all entities listed as instances of semantic web software in Wikidata as instances of semantic web software in OKG. We categorize all entities listed in Wikidata as instances of ontology as instances of ontology in OKG. I categorize everything else, including taxonomies, as instances of controlled vocabularies. In other words, I mirror the structure of Wikidata as much as possible, except where it makes it more complicated than necessary.

Regular updates

OKG runs queries daily to update the data and stores the results as TTL files. These TTL files are converted to JSON to display on the webpage. Both the TTL files and the JSON files are available for direct download as well.

Data enrichment

The only data enrichment I do at this point is categorizing the ontologies and vocabularies by topic. There are about 1,800 resources and listing them in one long list is a bit overwhelming. I added a filter at the top for topic so users can navigate to their domain more easily. I used an LLM to categorize each vocabulary using its title and description.

Sorting by quality / relevant

The resources are sorted by quality. To measure quality of vocabularies, I use the following properties: description, official webpage, and license. For software, I also use description and license, but I also sort by the date of their latest release. The theory is that software that is regularly updated is more relevant; some repositories haven’t been updated in years.

API

The API queries against the underlying JSON data directly and a JSON is returned. I’ve enabled semantic search so the user doesn’t need to know the exact name of the resource. For example, if you search for “movies,” my Film Club Knowledge Graph will be returned.

SEO

The primary use case is to help people or agents build a knowledge graph or some part of one by building on what already exists. If an agent knows OKG exists, then it will likely find the API itself and find a related resource to use as a starting point. But how will an agent know about OKG in the first place? If an agent tries to build on something that already exists, it will likely start with a web search. If OKG never appears, it is unlikely that it will be used.

To improve search results, I’ve put structured data in the HTML of the landing page according to Google’s guiding principles. For resources that have good documentation (a description, license, official webpage), I have given them their own HTML page so they can be indexed by Google as well. There are about 660 resources that are documented well enough that they get their own page. This HTML, will, of course, point back to the original Wikidata page and their official web site.

Next steps

Here are some more immediate next steps that could make OKG even better.

• Improve underlying Wikidata data: OKG is only as useful as the underlying data and the only way to improve that is to update Wikidata directly. I have created a list of data improvements as issues in the GitHub repo here. Some basic cleaning tasks are: better descriptions, adding homepage URLs, remove or replace broken URLs, and add creator. Wikidata supports bot editing, so you can even use your favorite agent to help clean up and enrich the data. I have made a list of issues in the GitHub repo for anyone who wants to help.
• Integration with agents: Possible integrations: LangChain tools, LlamaIndex retrievers, MCP server, OpenAPI tool for AI agents. This way, an agent could ask, “Find an ontology about biodiversity with an open license,” and automatically retrieve one. An MCP server has already been built by Arthur Sarazin.
• Quality signals and trust metrics: Right now, we rank resources using metadata fields. Additional signals could include: citation count, number of downstream projects using the ontology, GitHub activity, last update date of vocabulary. We could create a “trust score” or “maturity score” for each resource. These metrics must remain objective and as unbiased as possible, however.
• Identify the format of resources: for the ontologies and vocabularies that have links to their underlying code (often in GitHub) the formats are all over the place. Having descriptions of the format or language would help (RDFS, SKOS, OWL, SHACL, etc.).
• Expanding beyond ontologies, controlled vocabs, and software: Right now OKG focuses on vocabularies and software. We could include datasets that use those vocabularies, examples of knowledge graphs built with them, links to SPARQL endpoints.

Related ideas

Here are some other ideas that align with the principles behind OKG and could help us improve the project over time.

• Tools for building knowledge graphs using AI: If the overall goal is to use resources found in OKG to construct a graph, then we need more tools to support this. Some tools already use AI to automatically generate graph structures, but they typically start from scratch. Instead, they should first search OKG for existing ontologies and vocabularies in the domain. They could then use Wikidata to infer additional structure and relationships. In many cases, the ontology of the graph may already exist implicitly in Wikidata itself. OKG simply surfaces and organizes those resources so they can be reused.
• Publish-back pipeline: After you build a graph using existing vocabularies and extend them, we need a tool that helps you publish the new terms back as a proper vocabulary — with documentation, a namespace, and a Wikidata entry.
• Ontology diff/changelog tool: Track how ontologies evolve over time. When a vocabulary updates, show what changed (new classes, deprecated terms, renamed properties). Useful for anyone depending on an external ontology.
• Knowledge graph starter kits: Pre-built templates that combine a domain ontology from OKG with a schema and sample data. “Start a finance knowledge graph” pulls in FIBO (Financial Industry Business Ontology) + a basic graph structure + example triples for entities like counterparties, instruments, and transactions.
• Vocabulary recommendation engine — “I’m building a graph about X” → here are the 3 ontologies you should combine, where they overlap, and what you may still need to define.
• Graph alignment and mapping: Different vocabularies often overlap but use different terms. We could detect overlapping concepts or terms between vocabularies and suggest mappings.

Conclusion

As systems get better at building ontologies and knowledge graphs, the gap isn’t in generation — it’s in discovery and coordination. If an agent can discover a well-maintained vocabulary before building one from scratch, everyone benefits. The catalog, the API, the individual pages indexed by Google — they’re all just ways to make that discovery happen. If you work with ontologies, vocabularies, or knowledge graphs, take a look, and if you find something missing or broken, fix it in Wikidata.