Apache Ossie表达式语言两大层级详解本体层与逻辑层边界完全指南【免费下载链接】ossieApache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data项目地址: https://gitcode.com/GitHub_Trending/osi1/ossie对于刚接触 Apache Ossie 语义互操作规范的新手最容易困惑的一点是表达式到底写在哪一层Ossie 的表达式语言明确规定了两大层级——本体层Ontology Layer与逻辑层Logical Layer并且当前的 SQL 表达式规范只作用于逻辑层。本文用一张架构图和几个真实示例带你彻底搞清这两层的边界在哪里、为什么这样设计。先看架构图三层分工一目了然Ossie 的核心规范中有一张经典的三层示意图是理解整个项目的最佳起点这张图揭示了表达式语言所处的位置来源expression_language.md层级使用的语言职责Ontological Layer本体层语言待定Language TBD描述企业级的概念、关系与业务规则类似 OWL 等建模语言Logical Layer逻辑层Ossie SQL直接映射数据库与物理层承载指标、字段、过滤等表达式⬜Physical物理层各数据库原生 SQLSnowflake、BigQuery、PostgreSQL 等实际存储与执行一句话总结逻辑层的表达式用标准化 SQL 写本体层的表达式语言目前还是待定两者互不越界。逻辑层Ossie SQL 到底能写什么、不能写什么逻辑层是 90% 用户日常打交道的地方——指标metrics、字段fields、过滤条件filters的表达式都写在这里。规范基于ANSI SQL:2003核心子集设计遵循四条原则见 expression_language.md可移植核心函数在所有实现中行为一致熟悉感基于广泛采用的 SQL 语法与语义分析导向优先支持 BI 与数据分析常用函数可扩展厂商方言可以超出核心集扩展逻辑层表达式支持的典型结构包括列与指标引用、四则运算、比较与逻辑运算符、BETWEEN、IN、LIKE/ILIKE、IS NULL、CASE WHEN、聚合函数SUM/COUNT/AVG/MEDIAN等、窗口函数ROW_NUMBER()、LAG()等以及标量函数。而以下结构被明确排除在表达式之外expression_language.md不支持的结构原因SELECT/FROM/JOIN由语义层统一处理GROUP BY由粒度grain规范控制WHERE改用 filter 属性表达子查询、CTE用字段引用替代UNION/ DDL / DML不属于表达式范畴 记住这个边界表达式只描述行级怎么算和怎么聚合表与表怎么连、按什么分组交给模型声明。逻辑层的规范结构可以在核心规范文档中找到例如字段定义中的表达式对象spec.mdexpression: dialects: - dialect: ANSI_SQL expression: customer_id本体层用业务语言描述世界长什么样本体层位于逻辑层之上见 ontology.md它把企业数据建模为概念Concepts、关系Relationships和业务规则而不是表与列。概念分为两类ontology.mdEntityType实体类型现实世界的对象如员工、航班ValueType值类型带有额外语义的数据类型如纬度、取消原因代码本体层最有特色的是它的规则表达式。以官方示例 flights.yaml 为例requires: - COUNT[Airport] 0 # 必须至少存在一个机场 - COUNT[Carrier] 0 # 必须至少存在一家承运人再看一个值类型约束flights.yaml- concept: CancelationCode type: ValueType extends: [ String ] requires: [ CancelationCode A OR CancelationCode B ]注意这种COUNT[Airport]、CancelationCode A的写法——它不是 SQL而是本体规范自己的表达形式与逻辑层的 Ossie SQL 是两套体系。两大层级的边界一张表讲透对比维度本体层Ontology Layer逻辑层Logical Layer抽象高度业务概念人、公司、航班、金额语义分析结构数据集、字段、指标、关系表达式语言待定规范中尚无统一 SQL 方言Ossie_SQL_2026默认方言基于 ANSI SQL:2003表达式形态COUNT[Airport] 0、DegreesLatitude 90SUM(amount)、CASE WHEN status completed THEN amount END服务对象企业级统一语义、AI 理解业务规则跨 BI/AI 工具交换指标与字段定义类比OWL、Legend、(Py)Rel 等建模语言传统 BI 语义模型规范文档ontology/ontology.mdcore-spec/expression_language.md边界口诀逻辑层回答这个指标怎么算本体层回答这个业务概念是什么、受什么规则约束。为什么不直接统一成一套表达式语言规范作者其实留了一个美好的愿景希望本体层未来能复用同一套表达式语言但当前版本被明确拆分为独立提案处理expression_language.md。原因可以归纳为三点抽象层次不同逻辑层要能无损映射到各数据库方言SQL 是天然选择本体层面对的是纬度不超过 90这类业务公理SQL 反而表达力不足。兼容性策略不同逻辑层需要dialects机制spec.md让同一个字段可以同时提供ANSI_SQL、SNOWFLAKE、BIGQUERY等多个版本expression_language.md而本体层规则不需要关心方言差异。演进节奏不同逻辑层规范已处于 Proposed Final 状态本体层的语言表达尚在讨论中强行合并会拖累两者进度。实战提示写表达式时守住这三条边界写指标/字段表达式→ 只写逻辑层 Ossie SQL不带SELECT/FROM/JOIN聚合粒度由模型声明决定。要厂商特有函数→ 通过dialects多版本声明如 BigQuery 的DATE_TRUNC(order_date, MONTH)与 ANSI 的DATE_TRUNC(month, order_date)并存核心ANSI_SQL版本永远保留。描述业务约束与概念→ 放进本体规范concept、requires、derived_by不要试图塞进 SQL 表达式里。延伸阅读与项目资源核心规范core-spec/spec.md —— 语义模型、数据集、字段、指标的完整定义表达式语言提案core-spec/expression_language.md —— 函数清单、方言扩展与合规级别本体规范ontology/ontology.md —— 概念、关系与规则的表达方式完整示例examples/flights.yaml本体示例、examples/tpcds_semantic_model.yaml逻辑层 TPC-DS 语义模型机器可读 Schemacore-spec/ossie-schema.json校验工具validation/validate.py —— 提交模型前验证是否符合规范搞清楚本体层与逻辑层的边界你就掌握了 Apache Ossie 表达式语言最关键的架构思想让每层用最适合的语言说话同时通过统一规范保证跨工具、跨平台的一致语义。【免费下载链接】ossieApache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data项目地址: https://gitcode.com/GitHub_Trending/osi1/ossie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
