Scan the QR code with WeChat
Add your dedicated advisor
Save to favorites
Published: 2026-08-14 15:20:23 Views: 1952
Recommendation
Struggling to unify metric definitions across data teams? Apache Ossie tackles the semantic layer interoperability challenge of the AI era with an open exchange standard, making business data trustworthy and usable. Key points: 1. Four problems caused by fragmented semantic layers across data tools (metric drift, manual translation, unreliable AI, heavy integration debt) 2. Apache Ossie's open exchange standard and hub-and-spoke model 3. The core value of a unified semantic layer for business data management and AI analytics
Yang Fangxian
Founder of 53AI / Most Valuable Expert of Tencent Cloud (TVP)
Over the past few years, data teams have been chasing one goal: giving business metrics a unified definition.
But reality often falls short.
The same "revenue" is calculated one way in financial reports, another way in BI dashboards, and a third way in data science notebooks. In the AI agent era, the problem gets even more complicated: for a large model to answer business questions, it must understand data tables, fields, relationships, metrics, time definitions, and business synonyms. If these definitions are scattered across different tools, the AI may look smart, but it can easily produce results that "sound plausible but use the wrong definition."
Apache Ossie emerged precisely in this context.
It is not trying to build yet another BI tool, nor to replace dbt, Snowflake, Databricks, Salesforce, GoodData, or other semantic layer products. What it aims to solve is something more fundamental: providing an open, neutral, exchangeable representation format for semantic models.
Simply put, Ossie wants to become the "semantic exchange standard" between AI, BI, data catalogs, and semantic layer tools.
Put in a context more familiar to domestic data teams, it is answering the same question as OneData, metric systems, data asset catalogs, and enterprise wikis:
Where should an organization's business semantics be consolidated, and how can systems actually use them?
Today's data stack is already very rich.
Data warehouses have their own modeling approaches, BI tools have their own semantic layers, data catalogs have their own asset descriptions, and AI analytics tools need additional business context. Every system is trying to describe "what business data means," but their ways of describing it are not unified.
This leads to four typical problems.
First, metric drift.
A KPI gets defined repeatedly in different tools. As soon as one place changes it and the others don't sync, the numbers slowly diverge. Eventually, meetings devolve into arguments not about the business itself, but about "why your revenue number differs from mine."
Second, high manual translation costs.
When a team migrates from one platform to another, or wants multiple tools to share the same set of semantic definitions, engineers usually have to manually translate fields, metrics, relationships, and permission contexts. This kind of work is tedious, error-prone, and hard to maintain over the long term.
Third, AI lacks reliable grounding.
When an AI agent does data analysis, it shouldn't just guess table names and field meanings. It needs to know which fields are dimensions, which metrics can be aggregated, which tables can be joined, and which metric business terms like "GMV," "sales," and "revenue" actually refer to. If semantic definitions conflict with each other, the AI won't have no answer—it will give an untrustworthy one.
Fourth, integration debt keeps piling up.
Suppose there are N semantic layer or analytics tools. If every pair of tools needs point-to-point conversion, you theoretically need N × (N - 1) conversion paths. The more tools, the more complex the connections and the higher the maintenance cost.
Ossie's judgment is: rather than making every tool interoperate with every other tool, it's better to first define a common format. Each tool only needs to be able to import and export Ossie, and it can exchange semantic models with other tools through it.
This is the classic hub-and-spoke model: Ossie is the hub, and the various tools are the spokes.
Looking at the project structure, the core of Apache Ossie is a JSON / YAML format semantic model specification.
What it cares about is not how data is stored or how SQL is executed, but abstracting business semantics into a set of structures that tools can read, validate, and transform.
Ossie's core model mainly includes several types of objects.
Semantic Model is the top-level container, used to describe a complete semantic model.
Datasets represent logical datasets, which can be understood as business entities or fact tables and dimension tables, such as orders, customers, and store_sales. They point to underlying physical tables, views, or query sources, and declare primary keys, unique keys, and fields.
Fields represent row-level fields within a dataset, which can be simple column references or computed expressions. Fields can be annotated with data types, and can also be marked as time dimensions.
Relationships describe how datasets are joined, supporting simple foreign keys as well as composite keys.
Metrics represent business metrics, such as total_revenue, average_order_value, and customer_lifetime_value. Metrics are defined at the model level and can reference multiple datasets.
AI Context is a design worth noting. Ossie allows adding AI context at various levels—model, dataset, field, relationship, and metric—such as business descriptions, synonyms, example questions, and usage instructions. This shows it is not only aimed at traditional BI, but also preparing for AI agents to use semantic models.
Custom Extensions are responsible for preserving vendor-specific information. Different platforms will inevitably have their own extra configurations. Ossie doesn't try to cram all vendor capabilities into the core specification; instead, it allows extension information to be preserved via vendor_name + JSON data.
This point is crucial.
An open standard that only pursues the lowest common denominator easily loses important information from real production systems; if it standardizes everything, it becomes bloated and sluggish. Ossie's approach is: keep the core semantics as unified as possible, carry vendor differences through extensions, and preserve them as much as possible during conversion.
In other words, Ossie is not a manual written for humans to read, but a semantic contract written for systems to read.
Ossie is fairly intuitive when written in YAML. A simplified model looks roughly like this:
version: " semantic_model: - name: sales_analytics description: Sales and customer analytics model ai_context: instructions: "Use this model for sales analysis" datasets: - name: orders source: sales.public.orders primary_key: [order_id] fields: - name: order_date expression: dialects: - dialect: ANSI_SQL expression: order_date datatype: Date dimension: is_time: true - name: amount expression: dialects: - dialect: ANSI_SQL expression: amount datatype: Decimal metrics: - name: total_revenue expression: dialects: - dialect: ANSI_SQL expression: SUM(orders.amount) datatype: Decimal ai_context: synonyms: - "revenue" - "total sales"
There are several details in this YAML worth noting.
First, field and metric expressions support dialects. That is, the same field can carry expressions in different dialects simultaneously, such as ANSI_SQL, SNOWFLAKE, DATABRICKS, and BIGQUERY. The target platform's converter can prefer its own dialect, and fall back to ANSI_SQL if none is available.
Second, datatype and dimension.is_time are handled separately. A field with a Date data type doesn't necessarily mean it should be used as a time axis in analytics interfaces; an Integer-typed year field can also be explicitly marked as a time dimension. This separation of "type" and "role" is important for cross-tool conversion.
Third, ai_context is not placed only at the top level, but can be placed at multiple levels. For AI, field names
ss_ext_sales_price
On its own, it doesn't carry much business meaning; but if it comes with a description and synonyms, the agent can more easily map what the user says—like "sales amount" or "line total"—to the correct field.
Many teams already have wikis, metric definition documents, data maps, field descriptions, and data asset catalogs.
So why is Ossie still needed?
My understanding is: a wiki solves "how humans understand semantics," while Ossie solves "how systems exchange semantics."
A wiki is great for writing background, explanations, and reasoning processes.
For example, "why GMV doesn't equal revenue," "how refunded orders are handled," or "why the new vs. returning user definition was adjusted in 2024"—this kind of content fits very naturally in a wiki. It has context, discussion, historical notes, and it's easy for business and data teams to maintain together.
But wikis have several inherent limitations.
First, they are usually not strongly structured.
A metric document can contain a lot of valuable information, but it's hard for a system to reliably determine which part is the metric name, which is the calculation expression, which are the available dimensions, which are filter conditions, and which is a deprecated definition.
Second, they usually can't be directly validated.
Just because a document says "revenue = payment amount - refund amount" doesn't mean the implementations in the BI tool, SQL templates, AI agents, and the metrics platform are actually consistent. A wiki can tell people what to do, but it can hardly automatically prove that systems are already doing it.
Third, it's hard to sync across tools.
When a definition changes in the wiki, the semantic model in Snowflake doesn't change automatically, the dbt metric doesn't change automatically, and the field descriptions in the BI platform don't change automatically. In the end, someone still has to move things manually.
Ossie is more like a machine-readable semantic model layer sitting next to the wiki.
The wiki explains why.
Ossie describes what.
The wiki records business context and decision-making processes.
Ossie records datasets, fields, relationships, metrics, expressions, SQL dialects, and AI context.
The wiki is for human collaboration.
Ossie is for tool exchange, automated validation, and automated transformation.
The two are not substitutes but complements.
The truly ideal state is: a metric has a business explanation in the wiki, a structured definition in Ossie, an executable implementation in the data warehouse and BI tools, and retrievable, citable, constraining semantic context in the AI agent.
That's what it means for business semantics to move from "written in documents" to "running inside systems."
Viewed through the OneData lens, Ossie's position becomes clearer.
OneData emphasizes unified data standards, unified metric definitions, unified dimensional modeling, and unified data asset management. Many enterprises build a methodology around data domains, subject areas, business processes, dimensions, fact tables, atomic metrics, derived metrics, and composite metrics.
This methodology itself is sound.
The problem is that OneData implementations often stall at three points.
First, they stall at the data warehouse modeling layer.
Teams do a good job with the ODS, DWD, DWS, and ADS layers, build fact and dimension tables, and consolidate common dimensions and summary tables. The warehouse itself has order, but once you get to BI, data applications, and AI agents, different tools still redefine the semantics all over again.
Second, they stall at the metrics management platform.
A metrics platform can manage metric names, definitions, owners, and lifecycles, and can even generate some SQL. But in real analysis scenarios, metrics also need to combine with dimensions, filter conditions, dataset relationships, tool dialects, and permission context. If the metrics platform can't interoperate with downstream tools, it easily becomes yet another silo.
Third, they stall at the documentation governance layer.
Many enterprises have very complete data standards documents and metric dictionaries, but there's no strong constraint between the documents and the execution systems. The documents say one thing, the queries run another, and the AI agent sees a third.
What Ossie can fill in is the "semantic exchange layer."
It doesn't replace the OneData methodology, doesn't replace warehouse layering, and certainly doesn't replace metric governance processes. It's more like adding an intermediate representation between OneData and specific tools, so that the semantics accumulated through OneData can be consumed by more systems.
You can think of it this way:
Data domains and subject areas help organize the business scope.
Fact tables and dimension tables help organize the data structure.
The metrics system helps organize calculation definitions.
The data asset catalog helps organize discovery and governance.
The wiki helps organize explanation and collaboration.
Ossie, meanwhile, helps these semantics be read, validated, transformed, and exchanged by machines.
Here's an example.
In OneData, "payment amount" might be an atomic metric in the transaction domain, "net revenue" might be a derived metric in the finance domain, and "user," "product," "store," and "date" are common dimensions.
Having these definitions in a metrics platform or wiki is certainly valuable. But for an AI agent to correctly answer "how much net revenue did new users in East China bring last month," the system also needs to know:
净收入
Which metric it corresponds to.
新用户
Whether it's a tag, a dimension value, or a computable condition.
华东地区
Whether to use the user's region, the store's region, or the order fulfillment region.
上个月
Whether to use payment time, order time, or revenue recognition time.
Which datasets these metrics and dimensions come from.
Which relationships to use when analyzing across datasets.
Whether the target platform is Snowflake, Databricks, or another engine, and how to choose the expression dialect.
If this information relies only on the wiki, the AI can hardly execute reliably; if it relies only on warehouse table schemas, the AI lacks business meaning; if it relies only on a single BI semantic layer, it's hard to share across platforms.
This is where Ossie's value lies: it organizes the semantics that were previously scattered across the metrics platform, dimension table design, field descriptions, SQL snippets, and business documents in OneData into an exchangeable model.
The standard itself is only the first step. What really determines whether Ossie can be adopted is the converters.
The current repository already includes converters in multiple directions, including implementations or directories related to Snowflake, dbt, Databricks, GoodData, Omni, WisdomAI, NVIDIA GSF, Honeydew, OrionBelt, Salesforce, Polaris, and more. Their common direction is clear: use Ossie as the intermediate format.
The typical flow looks like this:
- A semantic model can first be created in dbt, Snowflake, or another platform.
- An import converter converts the platform's native model into Ossie YAML.
- The Ossie model is checked for structural correctness via JSON Schema or validation scripts.
- The model enters Git, the data catalog, CI/CD, or an internal semantic service.
- An export converter then converts the Ossie model to other target platforms.
- If a downstream platform produces changes, round-trip them back to Ossie as much as possible, and use custom_extensions to preserve information that cannot be mapped to the core spec.
The value of this pattern is not just reducing the number of converters.
More importantly, it gives enterprises the opportunity to treat the semantic model as a governable, versionable, reviewable asset, rather than as implicit configuration scattered across various tool UIs.
For data teams, this is much like the process of moving data pipelines from hand-written scripts to dbt / Git / CI back in the day. Once semantic definitions become readable, diffable, verifiable text files, the way people collaborate changes.
If we only look at traditional BI, semantic layer interoperability is already an old problem.
But AI has amplified this problem.
In the past, when a metric definition was wrong, it usually meant one dashboard was wrong. Now, an AI agent may generate SQL based on wrong semantics, explain trends, write business analyses, and trigger follow-up actions. The error no longer stays in a single chart; it can spread along the automation chain.
This is also why the ai_context design in Ossie deserves attention.
What AI needs is not just table schemas. It also needs to know:
What synonyms "customer" has in this business.
Which metric "revenue" should use, rather than directly summing a field that looks like an amount.
Whether certain fields are for audit purposes only and should not be used as business time dimensions.
Which relationships cross-dataset metrics need to traverse.
Which business instructions to follow when facing ambiguous questions.
In the past, this information might have been hidden in data analysts' experience, in BI field descriptions, in Confluence docs, or simply existed only in Slack discussions. If an AI agent cannot access this context, it can only guess.
The significance of Ossie is that it attempts to structure these semantics and context, so that AI, BI, and data platforms can share the same set of business definitions.
This is not to make AI better at "writing SQL," but to make AI misunderstand the business less.
Placing Ossie within the full chain of OneData, Wiki, BI, and AI agents, it mainly solves five types of problems.
First, turning metric definitions from "documented conventions" into "structured contracts."
A Wiki or metrics platform can describe a metric, but Ossie can put the metric expression, referenced fields, data types, synonyms, and AI context into the same model. It makes definitions not just readable, but parseable.
Second, allowing semantic models to enter engineering workflows.
Semantic models in YAML / JSON form can be put into Git, code-reviewed, schema-validated, and checked in CI for correct field and relationship references. This makes it easier to establish engineering constraints than maintaining a set of page documents.
Third, reducing duplicate definitions across different tools.
If a metric is defined once in dbt, once in Snowflake, once in a BI tool, and once again in an AI analytics system, drift is almost inevitable. Ossie's hub-and-spoke approach lets tools import and export around the same intermediate model, reducing point-to-point translation.
Fourth, providing more reliable semantic grounding for AI agents.
AI should not only see table schemas, nor should it only read a few document fragments. It needs structured knowledge of: which datasets, which fields, which metrics, which relationships, which synonyms, which instructions. Ossie's ai_context gives this information a chance to be passed along with the model structure.
Fifth, preserving platform differences rather than pretending they don't exist.
Semantic layer tools in the real world inevitably differ. Snowflake, Databricks, dbt, GoodData, and Salesforce each have their own capabilities and metadata. Ossie preserves this information through custom_extensions; the goal is not to flatten all platforms, but to avoid losing information as much as possible while unifying the core semantics.
Taken together, these five points show that what Ossie solves is not "how to build a data warehouse," but "how the semantics of a built data warehouse can be consistently understood by different tools."
It is also not about "how to write metric documentation," but about "how business definitions in documents can become system-executable semantic assets."
That said, we should avoid deifying Ossie.
It does not replace data warehouse modeling. Fact tables, dimension tables, data layering, and subject domain division remain foundational OneData work.
It does not replace metric governance. Whether metrics are reasonable, whether definitions are accepted by the business, who the owners are, and how changes are approved—these remain organizational governance issues.
It does not replace the Wiki. Complex business context, historical decision processes, exceptions, and definition disputes still need to be carried by documentation.
It also does not directly replace query engines. Ossie describes semantic models, but how to actually generate SQL, execute queries, and enforce access control still requires integration with specific platforms.
So a more sensible way to adopt it is to place Ossie in the middle of the semantic asset chain.
Upstream, it connects to OneData's metric system, dimension system, data models, and business documentation.
In the middle, it forms machine-readable semantic models.
Downstream, it connects to BI, AI agents, data catalogs, semantic services, and various vendor platforms.
That is its proper place.
Reference project:
Apache Ossie GitHub[1]
53AI, the top service provider for enterprise LLM adoption
Products: scenario implementation consulting + LLM application platform + industry solutions
Commitment: free POC validation, cooperation only after results meet standards. Zero-risk LLM adoption, delivered to 160+ medium and large enterprises
Loading...
Scan to consult
Scan to log in
By logging in, you agree to the "53AI Website Service Agreement"
Service Agreement
Welcome to the [53AI Official Website] (hereinafter referred to as "this website" or "we"). This "Membership Service Agreement" (hereinafter referred to as "this Agreement") is a legal agreement between you (hereinafter referred to as "member" or "user") and [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.] regarding registration, login, and use of this website's membership services.
Before you register or log in, please be sure to carefully read and fully understand the terms, especially those exempting or limiting liability, intellectual property terms, and dispute resolution terms. Such terms will be highlighted in bold to draw your attention. When you successfully log in to this website via WeChat official account authorization, phone verification code, or other means, you are deemed to have fully understood and agreed to accept the entire contents of this Agreement.
I. Definitions
This website: refers to the website and related mobile pages operated by [Shenzhen Bosi Xiechuang Network Technology Co., Ltd.] with the domain [53ai.com].
Membership services: refers to the knowledge base article access, content search, and other related value-added services provided by this website to registered members.
Knowledge base content: refers to the digital content resources published by this website, including but not limited to text, charts, data, research reports, industry analyses, etc.
II. Account Registration and Login
Login methods: This website supports the following login methods, and you may choose according to your actual situation:
WeChat Official Account authorized login: You agree to authorize this website to use your WeChat OpenID information for creating or linking a membership account.
Mobile verification code login: You must provide a real and valid mobile phone number and complete identity verification and login/registration via SMS verification code.
Account security: Your account is for your personal use only; gifting, lending, renting, transferring, or selling it is prohibited. Any losses resulting from account theft or password leakage due to your failure to safeguard it properly shall be borne by you.
Real-name verification: As required by relevant laws and regulations, we may ask you to complete real-name verification for certain features. If you refuse to provide it, you may be unable to use some or all of the services.
Protection of minors: If you are under 18 years of age, please read this agreement accompanied by your legal guardian and use this service only with your guardian's consent.
III. Service Content and Standards
Knowledge base access: After logging in, members have the right to browse and search online the relevant articles and content in this website's knowledge base within the scope of permissions corresponding to their membership level.
Service changes: We have the right to adjust, change, or terminate part of the service content as needed for business development, and will provide advance notice via website announcements, Official Account messages, and other means.
Prohibited conduct: When using the services, you must not engage in the following:
Using technical means to bulk crawl, download, or re-store knowledge base content;
Using knowledge base content for commercial purposes or disseminating it to third parties without authorization;
Interfering with the normal operation of this website or infringing upon the legitimate rights and interests of other users;
Publishing illegal or non-compliant information or engaging in activities contrary to public order and good morals.
IV. Intellectual Property Statement
Ownership of rights: The intellectual property rights of the layout design, software code, and other content in this website's knowledge base belong to [Company Full Name] or the original rights holders, and are protected by laws such as the Copyright Law of the People's Republic of China.
Limited license: This website grants members a non-exclusive, non-transferable, non-sublicensable ordinary license, limited to online access to knowledge base content for personal study and research purposes only.
Enforcement against infringement: Without written permission, no organization or individual may copy, republish, excerpt, mirror, compile, or otherwise use the above content in any form. Once discovered, we reserve the right to pursue legal liability.
V. Protection of Personal Information
We value the protection of your personal information. For how we collect, use, store, and protect your personal information, please read the Privacy Policy separately.
The information you provide through WeChat Official Account authorization or mobile phone verification will be processed by us strictly in accordance with the Personal Information Protection Law, and used only for necessary purposes such as identity verification, service provision, and security verification.
You may at any time exercise your rights to access, correct, or delete your personal information and withdraw your authorization consent through website settings or by contacting customer service.
VI. Disclaimer
Content accuracy: Knowledge base content is for reference only and does not constitute professional advice. We make no express or implied warranties regarding its completeness, accuracy, or timeliness; you should make your own judgment and assume the risks of use.
Force majeure: We shall not be liable for breach of contract for service interruptions or delays caused by force majeure such as natural disasters, changes in policies and regulations, network failures, or third-party platform interface anomalies (such as WeChat interface maintenance or carrier SMS channel failures).
Third-party links: This website may contain links to third-party websites; the content and services of such websites are beyond our control, and you should assess the risks yourself.
VII. Liability for Breach
If you violate this agreement, we have the right to take measures such as warnings, feature restrictions, service suspension, or account cancellation depending on the circumstances, and reserve the right to demand compensation for losses.
If your breach causes us to suffer administrative penalties, third-party claims, or reputational damage, you shall bear full liability for compensation (including but not limited to fines, damages, attorney fees, notarization fees, etc.).
VIII. Governing Law and Dispute Resolution
The formation, performance, and interpretation of this agreement shall be governed by the laws of mainland China.
Any dispute arising from or in connection with this agreement shall be resolved through friendly negotiation between the parties; if negotiation fails, either party may file a lawsuit with the people's court with jurisdiction in [Company Location].
IX. Miscellaneous
This agreement constitutes the entire agreement between the parties regarding this service and supersedes any prior oral or written agreements.
If any provision of this agreement is found to be invalid or unenforceable, it shall not affect the validity of the other provisions.
We have the final right to interpret this agreement and reserve the right to modify it at any time within the scope permitted by law. The modified agreement takes effect upon publication, and continued use of the service shall be deemed acceptance of the revised content.