如果企业的数据已经全部存在 MySQL、PostgreSQL、Oracle 里还需要为了知识图谱重新搬一遍数据吗Ontop 给出的答案是不一定。GitHubhttps://github.com/ontop/ontop官网https://ontop-vkg.org/一、先说结论Ontop 是干什么的Ontop 是一个开源的Virtual Knowledge Graph虚拟知识图谱系统。它最核心的能力可以用一句话说明把关系型数据库“映射”为知识图谱但数据依然保留在原来的数据库里。也就是说MySQL PostgreSQL Oracle SQL Server ↓ Ontop ↓ Virtual Knowledge Graph ↓ SPARQL你并不一定需要MySQL ↓ ETL ↓ RDF ↓ Neo4j / RDF Store把整个数据库复制一份。Ontop 会在查询的时候把针对知识图谱的SPARQL Query转换成关系数据库能够执行的SQL Query然后直接查询原始数据库。这就是它最有意思的地方。截至 2026 年 8 月Ontop GitHub 主仓库约有 900 Stars采用 Apache 2.0 LicenseGitHub Release 页面显示当前稳定版为Ontop 5.5.0发布时间为 2026 年 2 月 14 日。二、为什么会出现 Ontop先看一个非常常见的企业系统。比如一个电商平台的数据可能全部放在 MySQL 里users orders products suppliers payments表之间通过user_id order_id product_id supplier_id连接。对后端开发来说这种结构非常熟悉。例如SELECTu.name,o.id,p.nameFROMusers uJOINorders oONu.ido.user_idJOINorder_items oiONo.idoi.order_idJOINproducts pONoi.product_idp.id;但是知识图谱不是这么理解世界的。知识图谱可能会把它描述成User | | places ↓ Order | | contains ↓ Product | | suppliedBy ↓ Supplier也就是说数据库关注的是表 字段 主键 外键知识图谱关注的是实体 关系 语义两套世界观不一样。三、传统知识图谱的问题如果企业已经有1000 万用户 5000 万订单 1 亿商品记录传统做法可能是生产数据库 ↓ ETL ↓ 数据清洗 ↓ RDF Triple ↓ Knowledge Graph问题马上就来了。1. 数据重复原来 MySQL 已经有一份100GB现在知识图谱里又有100GB相当于复制了一份。2. 数据同步数据库发生变化订单状态 pending ↓ paid知识图谱里面也必须同步。于是开始出现CDC Kafka ETL 同步任务 定时任务系统越来越复杂。3. 实时性数据库已经payment_status paid知识图谱可能还停留在payment_status pending如果 Agent 使用的是知识图谱就有可能拿到旧数据。4. 数据治理成本企业实际上变成业务数据库一套 知识图谱一套 搜索一套 向量数据库一套数据越多维护成本越高。于是 Ontop 提出了另外一种思路不复制数据让知识图谱成为数据库上面的一层语义视图。四、什么是 Virtual Knowledge GraphVirtual Knowledge Graph简称VKG可以翻译成虚拟知识图谱。所谓“虚拟”意思就是图并不真正完整存储在那里。真正的数据还是MySQL PostgreSQL OracleOntop 在数据库上方增加一层Ontology Mapping最终SPARQL ↓ Ontology ↓ Mapping ↓ Ontop ↓ SQL ↓ Relational Database用户看见Knowledge Graph数据库看见SQLOntop 负责中间翻译。这就是它的核心。五、一个具体例子假设数据库里有一张CREATETABLEusers(idBIGINTPRIMARYKEY,nameVARCHAR(100),emailVARCHAR(200),company_idBIGINT);还有CREATETABLEcompanies(idBIGINTPRIMARYKEY,nameVARCHAR(200));数据库世界里users.company_id只是一个外键。但是在 Ontology 里面可以定义User Company以及User worksFor Company于是从语义层面王仕宇 | | worksFor ↓ JavaPub不再只是company_id 1001这就是语义层的价值。六、Ontop 的三个核心部分Ontop 可以简单理解为三个核心模块Ontology Mapping Query Rewriting七、第一部分OntologyOntology 负责定义这个业务世界里面有哪些概念以及它们之间是什么关系。例如电商User Order Product Supplier Payment关系User ↓ places Order Order ↓ contains Product Product ↓ suppliedBy Supplier Order ↓ paidBy Payment如果使用 OWL / RDF 表示可以进一步描述User is a Person Supplier is an Organization Order hasPayment PaymentOntology 不负责保存具体王仕宇 订单 10001 iPhone 17它主要定义世界的结构。八、第二部分MappingMapping 是 Ontop 最重要的部分之一。因为数据库和 Ontology 本身是完全不同的两个世界。需要告诉 Ontop数据库里的 users 表 Ontology 里的 User比如users.id对应User URI然后users.name对应User.name再比如users.company_id对应User worksFor Company这就是 Mapping。九、一个 Mapping 示例假设SELECTid,nameFROMusers;可以映射成类似http://example.com/user/{id} rdf:type ex:User以及http://example.com/user/{id} ex:name {name}最终数据库id 1 name Alice在图世界里User/1 | rdf:type | User以及User/1 | name | Alice这就是Relational Data ↓ RDF View十、R2RML 是什么Ontop 支持R2RML Mapping。R2RML 是 W3C 用来描述如何把关系型数据库映射成 RDF 的标准。名字也很好理解RDB to RDF Mapping Language它主要描述哪张表 哪个 SQL 生成什么 Subject Predicate 是什么 Object 从哪个字段来例如概念上SELECT id, name FROM users映射{id} → User然后{name} → User.nameOntop 就可以知道该怎么构造知识图谱。十一、Ontop 最核心的一步SPARQL 转 SQL这才是 Ontop 真正厉害的地方。用户写SELECT ?name WHERE { ?user a :User . ?user :name ?name . }Ontop 接收到之后并不会去一个 RDF Database 里查。它会根据Ontology Mapping进行 Query Rewriting。最后可能生成SELECTnameFROMusers;数据库执行 SQLAlice Bob CharlieOntop 再把结果转换回 SPARQL Result。整个流程SPARQL ↓ Ontology Reasoning ↓ Mapping ↓ Query Rewriting ↓ SQL ↓ Database ↓ Result十二、复杂查询会发生什么例如 SPARQLSELECT ?user ?product WHERE { ?user :places ?order . ?order :contains ?product . }语义层看起来非常简单User ↓ places Order ↓ contains Product但是数据库可能是users orders order_items productsOntop 最终需要翻译成SELECTu.id,p.idFROMusers uJOINorders oONo.user_idu.idJOINorder_items oiONoi.order_ido.idJOINproducts pONp.idoi.product_id;对于上层开发者来说不再需要了解order_items product_id user_id 各种 JOIN只需要理解User places Order contains Product这就是 Ontology 带来的抽象。十三、Ontop 和数据库 View 有什么区别有人可能会说这不就是数据库 View 吗不完全一样。数据库 ViewSQL Schema ↓ SQL View本质还是表 字段OntopRelational Schema ↓ Semantic Model你看到的是User Organization Order Product worksFor purchased owns而不是tbl_user company_id order_user_rel更重要的是 Ontology 还可以表达继承 类型关系 语义规则这已经不是普通 View 能直接替代的。十四、为什么企业特别适合 Ontop因为企业数据最大的特点就是数据很多但都已经存在数据库里。比如银行Customer Account Transaction Loan实际存储Oracle医院Patient Doctor Diagnosis Treatment存储PostgreSQL制造业Machine Factory Order Supplier Part存储ERP Database这时候如果要上知识图谱最麻烦的是重新构建一套数据系统。Ontop 的优势就在于数据库不用动。 只增加语义层。十五、一个企业 Ontop 架构可以设计AI Agent | ↓ GraphRAG | ↓ SPARQL | ↓ Ontop / \ Ontology Mapping \ / | ↓ ----------------------------- | | | MySQL PostgreSQL Oracle | | | ----------------------------- | 企业业务数据这时候 Ontop 就像企业数据库和 AI 之间的语义中间层。十六、Ontop AI Agent这也是我觉得 Ontop 在今天重新变得非常有意思的地方。以前Ontop 更多是Semantic Web Knowledge Graph SPARQL现在可以把 AI Agent 放上去。比如用户问去年购买过服务器并且当前合同仍然有效的客户有哪些Agent 首先理解Customer purchased Server hasContract Contract然后生成SPARQL交给 Ontop。OntopSPARQL ↓ SQL然后MySQL / PostgreSQL返回真实业务数据。整个链条自然语言 ↓ LLM ↓ SPARQL ↓ Ontology ↓ Ontop ↓ SQL ↓ 业务数据库这就是一个非常漂亮的Semantic Data Agent。十七、为什么不直接让 LLM 生成 SQL这个问题很关键。现在很多项目是自然语言 ↓ LLM ↓ SQL也就是 Text-to-SQL。比如用户问查询购买过服务器的客户。LLM 必须知道customers 表 orders 表 order_items 表 products 表 字段名称 JOIN 条件问题是企业数据库可能有2000 张表 数万个字段LLM 很难理解。加 Ontology 之后Agent 看到的是Customer Order Product purchased不需要知道crm_customer_base_v2 sales_order_master sales_item_relation底层复杂度交给Mapping Ontop于是自然语言 ↓ Semantic Query ↓ SPARQL ↓ Ontop ↓ SQL从系统设计上可能更加稳定。十八、这可能比 Text-to-SQL 更适合大型企业小项目10 张表Text-to-SQL 完全够用。但是大型 ERP500 1000 5000 张表如果全部把 Schema 扔给 LLM基本不可行。Ontology 可以把5000 张数据库表抽象成Customer Order Product Supplier Employee Factory可能只有几十、几百个核心概念。于是复杂物理数据模型 ↓ 简单业务语义模型这就是 Ontology 最大的价值之一。十九、Ontop RAGOntop 也可以和传统 RAG 配合。比如结构化数据MySQL走Ontop非结构化数据PDF Word Wiki走Vector Database然后用户问题 | ↓ Agent / \ Graph Vector | | Ontop RAG | | Database Documents \ / ↓ LLM这比纯 Vector RAG 能处理更多问题。二十、Ontop GraphRAG进一步可以Ontology ↓ Virtual Knowledge Graph ↓ Graph Retrieval ↓ Document Retrieval ↓ LLM例如用户问A 公司最近为什么出现交付延期首先通过 Ontop 找A 公司 ↓ 订单 ↓ 供应商 ↓ 产品 ↓ 物流然后再到向量数据库搜索这些订单对应的合同 邮件 会议纪要 故障报告这就是Structured Graph Unstructured RAG结合起来。二十一、Ontop 支持什么数据库Ontop 面向关系数据库。常见场景包括PostgreSQL MySQL Oracle SQL Server本质依赖JDBC连接数据库。因此它本身特别适合 Java / 企业后端生态。二十二、Ontop 是 Java 项目Ontop 主体使用 Java 开发。GitHub 项目本身是 Maven 工程。源码构建gitclone https://github.com/ontop/ontop.gitcdontop然后mvn cleaninstall官方当前 Version 5 分支的 README 标明构建使用 Maven 3.6 和 Java 11。二十三、Ontop 也支持 DockerOntop 提供官方 Docker 镜像。因此生产环境可以PostgreSQL Ontop Ontology Mapping直接容器化。一个典型结构docker-compose.yml ontology.owl mapping.obda ontop.properties然后dockercompose up-d最终暴露一个SPARQL Endpoint给其他系统访问。二十四、Ontop ProtégéOntop 还有一个很方便的东西Ontop Protégé Plugin。也就是说Protégé Ontop可以直接结合起来。你可以在 Protégé 里设计 Ontology 编写 Mapping 连接数据库 执行 SPARQL然后看查询结果。这对于学习 Ontology 非常方便。官方 GitHub Release 也提供 macOS、Windows 和 Linux 的 Protégé Bundle。二十五、Ontop 不是什么理解一个项目最好的方式有时候是先知道它不是什么。Ontop 不是Neo4j它不会要求你把全部数据搬进 Graph Database。Ontop 不是Vector Database它主要不是做 Embedding Search。Ontop 也不是LLM它不会帮你聊天。它真正负责的是Semantic Layer Query Translation二十六、Ontop 和 Neo4j 的区别可以简单对比能力OntopNeo4j数据存储原数据库图数据库是否搬数据不一定通常需要QuerySPARQLCypher数据模型RDF / OntologyProperty Graph实时同步直接查询源库通常需要同步Ontology原生方向需要额外设计企业关系库集成强需要数据导入所以Neo4j 更像真正的 Graph DatabaseOntop 更像数据库上方的 Virtual Graph Layer二十七、Ontop 最大优势我觉得有三个。第一不用搬数据这是最大的优势。Business DB ↓ 直接查询不存在复制 同步 一致性这些额外问题。第二数据实时数据库发生UPDATE orders SET status paid下一次 Ontop 查询理论上就可以直接看到最新状态。因为它查询的是源数据库。第三语义层解耦底层tbl_order_2026 user_base_v3 sku_master_info上层Order User Product这对 Agent 特别重要。因为 AI 更容易理解Customer purchases Product而不是customer_id JOIN sku_order_relation二十八、Ontop 的缺点也很明显当然它并不是万能的。1. Mapping 成本真正难的部分Database Schema ↓ Ontology如何建立 Mapping。大型企业可能需要大量人工设计。2. 复杂 SQL 性能SPARQLGraph Traversal最终可能被翻译成大量 JOIN如果数据库设计不合理SQL 性能可能会变差。3. 依赖 Ontology 质量Ontology 如果设计得不好语义层本身就可能变成新的技术债务。二十九、LLM 可能解决 Ontop 最大的问题这也是我现在非常关注的方向。Ontop 最大的问题Mapping 太麻烦。但是 LLM 出现之后可以尝试Database Schema ↓ LLM ↓ 理解表和字段 ↓ 生成 Ontology ↓ 生成 Mapping ↓ 人工审核 ↓ Ontop例如数据库t_customer customer_name enterprise_idLLM 自动理解Customer Customer.name Customer belongsTo Enterprise然后生成R2RML Mapping这样 Ontology 工程的成本就可能大幅下降。三十、Ontop LLM 可能形成新的 Data Agent完整路线用户 | ↓ LLM | ↓ Semantic Understanding | ↓ SPARQL | ↓ Ontop | Mapping | ↓ --------------------- | | | MySQL Oracle PostgreSQL | | | --------------------- | Enterprise Data最终用户可以直接问今年购买 AI 服务超过 10 万元 但最近 30 天没有续费的客户有哪些LLM 不需要知道全部数据库字段。它只需要理解Customer Purchase AI Service RenewalOntop 负责Semantic ↓ Physical Database转换。三十一、Ontology 在 AI 时代重新有价值过去大家觉得 Ontology 很学术。因为OWL RDF SPARQL学习成本很高。但是 AI Agent 时代出现一个新问题AI 到底应该怎样理解企业的业务世界直接给它5000 张表很难。直接给它100 万个 Chunk也不够。我们真正需要的可能是Customer Order Contract Product Supplier这样的Business Semantic Layer。Ontology 恰好就是干这个的。三十二、我怎么看 Ontop如果只把 Ontop 看成一个 SPARQL 转 SQL 工具其实有点低估它。我更愿意把它理解成关系数据库和 AI 之间的一层语义操作系统。下面是MySQL PostgreSQL Oracle上面是Agent GraphRAG LLM中间Ontology Ontop于是AI Agent ↓ Ontology ↓ Ontop ↓ Business Data这条路线我觉得未来在企业 AI 里面会越来越有价值。三十三、总结一句话总结 OntopOntop 让关系数据库无需迁移数据就可以通过 Ontology 和 Mapping 被虚拟成知识图谱并使用 SPARQL 查询。它解决的不是如何存一张图而是如何让现有数据库拥有知识图谱的语义能力。传统方式Database ↓ ETL ↓ Knowledge GraphOntopDatabase ↓ Virtual Knowledge Graph未来再结合LLM GraphRAG AI Agent可能形成Natural Language ↓ LLM ↓ Ontology ↓ SPARQL ↓ Ontop ↓ SQL ↓ Enterprise Database如果说 Graphiti 更偏给 Agent 建立长期、动态的记忆。那么 Ontop 更偏让 Agent 直接理解和访问企业现有的结构化数据。这两个项目实际上代表了两条非常值得关注的路线Graphiti ↓ Agent Memory Ontop ↓ Agent Data Layer再往上汇合Ontology ↓ Knowledge Graph ↓ Context / Data ↓ AI Agent这也是我认为 Ontology 在 AI Agent 时代真正值得重新研究的原因。项目地址GitHubhttps://github.com/ontop/ontop官网https://ontop-vkg.org/王仕宇 JavaPubhttps://javapub.net.cn/