Tag: AI

We could use a semantic layer for our Snowflake database, and maybe a context layer for some AI agents. There are three different disciplines all chasing roughly the same goal, which is to provide AI with background knowledge about the business. Today, I will provide a brief survey of the field, so you can decide which one(s) you need.

1. Semantic layers
2. Context engineering
3. Ontologies and graphs

Semantic Layer

Snowflake calls them semantic views. A complete set of semantic views makes up a semantic layer. The word “semantic,” of course, means that the layer contains meaning instead of mere syntax. Syntax is what a data element looks like in the schema. Semantics is what it means. As a Linguistics grad, I still have my textbook on (natural language) Syntax and Semantics.

CREATE OR REPLACE SEMANTIC VIEW sales_rev_analysis 
TABLES (
  orders AS source.orders,
  customers AS source.customers
) 
RELATIONSHIPS (
  o_to_c AS orders (cust_id) REFERENCES customers (id)
) 
FACTS (
  orders.total_price AS amount
) 
DIMENSIONS (
  customers.region,
  orders.order_date
) 
METRICS (
  total_revenue AS SUM(amount)
);

It’s reasonable to call this a “layer,” in the architectural sense, because it sits between the AI model and the database. Extending SQL DDL to include AI artifacts reminds me a lot of Google’s BQML. Note how the Snowflake example enforces Kimball’s modeling style.

Apart from Snowflake, any database-linked metadata, like E-R diagrams, catalogs, and data dictionaries can serve as a semantic layer – as long as they’re accessible to the AI model. If you’re a Sigma-heavy Snowflake shop like ours, Sigma will consume your Snowflake definitions automatically.

If you prefer your semantics as YAML code, dbt does that. Everybody in the analytics space has their own approach to semantic data, leading to the Open Semantic Interchange, which is meant to be the lingua franca among them.

Context Engineering

To understand the importance of context engineering, you need to understand how context works. An LLM doesn’t keep mental track of the conversation the way you and I do. Each turn of the dialogue must feed the entire context window through the LLM again. The longer the context, the less likely the model’s response will be on point.

Running a company is just context engineering internally – Shopify CEO Tobi Lutke

As Andrej Karpathy explains here, this has led to a “thick layer of non-trivial software” to maintain succinct context. You want to spawn a new agent, for instance, with only the context for a specific task – undiluted by the broader context – and you might even wish to arm it with specific skills.

Skills allow AI agents to maintain succinct context by progressively pulling in text (as markdown and YAML) only as needed for the task at hand. This is also a great way to provide business knowledge. Don’t let the simplicity fool you – give your context files the same governance and security that you would any sensitive code.

The Karpathy post is part of a dialogue, including Shopify CEO Tobi Lutke, on the importance of documenting business context. Fortunately, markdown is readable by humans, too. Am I the first cynic to note that we never got this kind of documentation until AI came along?

Knowledge Ontology

Jessica Talisman makes the case for formal representation of knowledge using tools like OWL and RDF. This is about specifying knowledge in the abstract, which will be familiar to designers of OO class models. Her examples are large bodies of knowledge, abstract in the sense that they transcend an individual business.

This is probably overkill for my Snowflake use case, but I can see where it would be useful for, say, Palantir. It’s too bad the term “knowledge engineering” has been co-opted because, of the three disciplines, this one seems the most technical – and they had it first.

Palantir Ontology

Ontology is also a “layer” at Palantir, analogous to the application layer in a software stack. Palantir CEO Alex Karp says that the client’s value-added knowledge belongs in an explicit ontology layer instead of handing it off to an AI model controlled by a third party.

Karp argues that if you hand your business data and context to an AI vendor, you risk transferring your company’s “alpha” to a third party. Palantir’s solution is to confine this knowledge in the ontology layer, where it can be executed using any model.

The alternative to this approach is “sovereign” AI, which means that the model is private, either to the vendor, or to the business itself. This doesn’t mean that you have to become a frontier AI lab. It just means that you acquire the initial weights and then train it for your application.

Conclusion

My knock on ontology is that it strikes me as terribly effortful. It seems that every time we try to “help” AI, with prompts and orchestrators and harnesses, AI turns around and renders our help obsolete.

I remember researcher Douglas Lenat trying to code all background knowledge, like “if an item is in a box, and the box is in a room, then the item is also in the room.” Sound ontological? Lenat wasn’t wrong. There was no better alternative, circa 1985, but then the technology improved.

Snowflake’s Semantic View Autopilot (SVA) is another example. Instead of reading your painstakingly crafted semantic views, Snowflake’s AI can discover them by watching your usage patterns. I can, equally, imagine an LLM producing an ontology on its own.

Talisman may be right that ontology is a grand, scientific enterprise, and analytics is small beer. Karp is betting his company on it. Me, I just want to make sure everyone in my shop has the same definition of “back-end gross.”