前面我们讲了 Graphiti、Ontop、TrustGraph、Owlready2。
这次换到 Java 生态，聊一个 Semantic Web 领域非常经典的项目：Apache Jena。
项目地址：
https://github.com/apache/jena
官网：
https://jena.apache.org/
如果只用一句话介绍 Apache Jena：
它是一套用 Java 构建 RDF、SPARQL、Ontology、知识图谱和语义服务的完整开源框架。
而且它不是一个单点工具。
Jena 更像是一整套：
RDF
+
SPARQL
+
TDB2
+
Fuseki
+
Ontology
+
SHACL
组合起来的基础设施。
一、为什么我要单独讲 Apache Jena？
从我的角度来说，前面我们聊的几个项目，特点都很鲜明。
比如：
Owlready2
↓
Python + Ontology
Graphiti：
Temporal Knowledge Graph
↓
Agent Memory
TrustGraph：
Context Layer
↓
GraphRAG / Agent
Ontop：
Virtual Knowledge Graph
↓
Database Semantic Layer
而 Apache Jena 更像是在解决：
如果我就想从底层搭一套标准的 Semantic Web / Knowledge Graph 服务，该怎么办？
这个时候 Jena 就很合适。
尤其如果你本身是 Java 后端开发者，会发现它的风格其实非常熟悉：
Java API
Maven
Server
Storage
Query Engine
HTTP Endpoint
只不过它操作的不是：
MySQL Table
而是：
RDF Graph
二、先理解一个关键点：Jena 不是 Neo4j
很多人一听知识图谱，就会想到：
Neo4j
但是 Apache Jena 和 Neo4j 的定位并不一样。
Neo4j 更偏：
Property Graph Database
而 Apache Jena 更偏：
RDF / Semantic Web
简单理解：
Neo4j 常见模型：
(:Person)-[:WORKS_FOR]->(:Company)
Jena 更偏标准 RDF Triple：
Subject
Predicate
Object
例如：
王仕宇
worksFor
JavaPub
就是一个 Triple。
三、RDF 是理解 Jena 的第一步
RDF：
Resource Description Framework
不要被名字吓到。
最简单理解：
RDF 就是用三元组描述世界。
结构：
Subject
Predicate
Object
比如：
王仕宇
created
JavaPub
可以写成：
Subject:
王仕宇
Predicate:
created
Object:
JavaPub
再比如：
JavaPub
focusesOn
AI
两个 Triple 连起来：
王仕宇
|
created
↓
JavaPub
|
focusesOn
↓
AI
知识图谱就开始形成了。
四、用 Jena 创建第一张 RDF 图
Java 里可以直接创建一个 Model。
例如：
import org.apache.jena.rdf.model.*;
public class JenaDemo {
public static void main(String[] args) {
Model model = ModelFactory.createDefaultModel();
String ns = "https://javapub.net.cn/kg/";
Resource shiyu = model.createResource(ns + "wang-shiyu");
Resource javapub = model.createResource(ns + "javapub");
Property created = model.createProperty(ns + "created");
shiyu.addProperty(created, javapub);
model.write(System.out, "TURTLE");
}
}
这里做的事情其实很简单：
王仕宇
↓
created
↓
JavaPub
只是用 Java 写了出来。
五、为什么这里叫 Model？
Jena 里面：
Model
可以简单理解成：
一张 RDF Graph。
比如：
Model model
里面可以有：
Entity
Relationship
Literal
例如：
王仕宇
created
JavaPub
再加：
JavaPub
hasWebsite
https://javapub.net.cn/
于是：
王仕宇
|
created
↓
JavaPub
|
hasWebsite
↓
https://javapub.net.cn/
六、URI / IRI 为什么这么重要？
RDF 里不会只写：
JavaPub
通常会写成一个唯一标识：
https://javapub.net.cn/kg/javapub
为什么？
因为真实世界里：
Apple
可能是：
Apple 公司
苹果水果
如果只用字符串，很容易冲突。
所以知识图谱喜欢：
IRI
它本质上解决：
这个实体到底是谁？
这也是 Semantic Web 一个非常重要的思想：
Global Identity
七、Literal 是什么？
不是所有 Object 都是实体。
例如：
王仕宇
age
30
这里：
30
就是 Literal。
再比如：
JavaPub
name
"JavaPub"
其中：
"JavaPub"
也是 Literal。
所以一个 Triple：
Subject
Predicate
Object
Object 可以是：
Resource
也可以是：
Literal
八、Turtle：比 RDF/XML 好看很多
RDF 可以有很多序列化格式。
例如：
RDF/XML
Turtle
N-Triples
JSON-LD
我个人更推荐学习时先看：
Turtle
例如：
@prefix ex: <https://javapub.net.cn/kg/> .
ex:wang-shiyu
ex:created ex:javapub .
ex:javapub
ex:focusesOn ex:ai .
看起来是不是比 XML 舒服很多？
所以如果刚学：
不要一上来盯着 RDF/XML。
先用 Turtle。
九、Jena 第二个核心：SPARQL
如果：
RDF
负责：
存知识。
那么：
SPARQL
负责：
查知识。
SPARQL 可以简单理解成：
知识图谱世界里的 SQL
例如 SQL：
SELECT name
FROM users;
SPARQL：
SELECT ?x
WHERE {
?x ex:created ex:javapub .
}
意思：
谁创建了 JavaPub？
结果：
王仕宇
十、Java 中执行 SPARQL
例如：
String queryString = """
PREFIX ex: <https://javapub.net.cn/kg/>
SELECT ?person
WHERE {
?person ex:created ex:javapub .
}
""";
Query query = QueryFactory.create(queryString);
try (QueryExecution qexec =
QueryExecutionFactory.create(query, model)) {
ResultSet results = qexec.execSelect();
ResultSetFormatter.out(System.out, results, query);
}
整个流程：
SPARQL
↓
ARQ
↓
RDF Model
↓
Result
十一、ARQ 是什么？
Apache Jena 里面负责 SPARQL 的核心引擎叫：
ARQ
你可以把它理解成：
SPARQL Query Engine
类似数据库里的：
SQL Query Engine
它负责：
Parse
Optimize
Execute
Return Result
Jena 6 系列已经在跟进 RDF 1.2 和 SPARQL 1.2 的相关能力，6.1.0 的官方变更记录明确提到对 RDF 1.2 格式和 SPARQL 1.2 Query / Update / Result formats 的支持。
十二、第三个核心：TDB2
如果数据只有：
100 个 Triple
直接放内存就可以。
但是如果：
100 万
1000 万
上亿 Triple
显然不能只放：
ModelFactory.createDefaultModel()
这个时候需要：
TDB2
TDB2 是 Jena 的原生 RDF 数据存储。
可以理解成：
RDF Database
官方发行包本身就包含 TDB，Jena 当前则主要推荐 TDB2；Jena 6.0 的变更说明也明确建议迁移到 TDB2。
十三、TDB2 可以怎么理解？
普通数据库：
Java
↓
JDBC
↓
MySQL
Jena：
Java
↓
Jena API
↓
TDB2
TDB2 专门存：
RDF Triple / Quad
所以：
Knowledge Graph
↓
TDB2
可以真正持久化。
十四、一个 TDB2 示例
例如：
Dataset dataset =
TDB2Factory.connectDataset("./data/tdb2");
然后：
dataset.begin(ReadWrite.WRITE);
try {
Model model = dataset.getDefaultModel();
// 写入 RDF
dataset.commit();
} finally {
dataset.end();
}
这就开始有：
Transaction
的味道了。
对于后端开发者来说，非常熟悉。
十五、第四个核心：Fuseki
如果只有 Java 程序内部访问图：
Jena API
就够了。
但是如果你希望：
Python
Node.js
Agent
前端
其他服务
也能访问怎么办？
这个时候用：
Apache Jena Fuseki
Fuseki 是 Jena 的：
SPARQL Server
官方当前下载页把 Jena Fuseki 单独作为 SPARQL Server 提供，6.2.0 也有独立 Fuseki 二进制发行包。
十六、Fuseki 是什么感觉？
可以理解成：
TDB2
↓
Fuseki
↓
HTTP
↓
SPARQL Endpoint
例如：
http://localhost:3030/ds/query
其他程序：
POST SPARQL
就可以查询。
所以：
Java
Python
Node
LLM
Agent
都可以连接。
十七、这就变成真正的 Knowledge Graph Server 了
整体：
Client
┌────────────┼────────────┐
↓ ↓ ↓
Java Python AI Agent
\ | /
HTTP
↓
Fuseki
↓
SPARQL
↓
TDB2
↓
Knowledge Graph
这已经非常接近一个：
Semantic Data Service
十八、如果从后端工程师角度理解
我会这样类比：
传统后端：
Spring Boot
↓
MyBatis / JPA
↓
MySQL
Semantic Web：
Fuseki
↓
SPARQL / Jena
↓
TDB2
只不过传统后端操作：
Table
Row
Column
Jena 操作：
Entity
Relation
Triple
十九、Jena 还支持 Ontology
Jena 不只是 RDF。
它也提供 Ontology API。
Jena 6 现在已经从旧的 org.apache.jena.ontology 转向：
jena-ontapi
官方 5.6.0 的迁移说明明确写了 Jena 6 会切换到 org.apache.jena.ontapi。
所以可以建立：
Class
Subclass
ObjectProperty
DatatypeProperty
例如：
Developer
is-a
Person
二十、Ontology 和 RDF Graph 的区别
RDF：
王仕宇
created
JavaPub
描述：
Fact
Ontology：
Developer
is-a
Person
描述：
World Structure
所以：
Ontology
↓
定义世界
RDF：
↓
记录世界
这是我现在特别喜欢的一个理解方式。
二十一、Jena + Reasoning
Jena 也有：
Inference
也就是：
推理
比如：
Developer
is-a
Person
然后：
王仕宇
is-a
Developer
系统可以推断：
王仕宇
is-a
Person
也就是说：
Known Facts
+
Rules
=
New Facts
二十二、这和 LLM 推理有什么区别？
我觉得这个问题特别重要。
LLM：
概率推理
Ontology Reasoner：
逻辑推理
LLM 可能说：
我认为大概率是这样。
Reasoner：
根据规则，必然成立。
所以未来 Agent 很可能是：
LLM
+
Semantic Reasoner
而不是所有事情：
全部交给模型猜。
二十三、Jena 还支持 SHACL
SHACL 用来：
验证图数据
比如规定：
Person
必须有 name
或者：
Order
必须有 amount
甚至：
age
必须是 integer
Jena 当前官方 Javadoc 里仍然提供独立的 SHACL 模块。
这对 AI 自动生成知识图谱特别重要。
二十四、为什么 AI + SHACL 很重要？
未来可能是：
Document
↓
LLM
↓
Entity Extraction
↓
Relation Extraction
↓
Knowledge Graph
问题：
LLM 会错。
所以：
LLM Output
↓
SHACL
↓
Validation
↓
Graph
这样会稳定很多。
二十五、Jena + LLM 可以怎么玩？
这才是我觉得 Jena 在今天重新有意思的地方。
以前 Jena：
Semantic Web
现在可以：
LLM
+
Knowledge Graph
例如：
用户输入文档
↓
LLM
↓
实体抽取
↓
关系抽取
↓
Jena
↓
RDF
↓
TDB2
然后：
Agent
↓
SPARQL
↓
Fuseki
↓
Knowledge Graph
整个链条就跑起来了。
二十六、一个完整的 Java AI Knowledge Graph 架构
例如：
User
↓
AI Agent
↓
LLM
/ \
↓ ↓
Vector Search SPARQL
↓ ↓
Documents Fuseki
↓
TDB2
↓
Knowledge Graph
这就是：
Vector RAG
+
Graph RAG
结合。
二十七、Jena + GraphRAG
假设：
Document A：
王仕宇创建 JavaPub
Document B：
JavaPub 发布 AI 内容
Document C：
AI 内容包含 Agent 教程
Graph：
王仕宇
↓ created
JavaPub
↓ publishes
AI Content
↓ includes
Agent Tutorial
用户问：
王仕宇创建的品牌里，
有哪些 Agent 相关内容？
Agent 可以：
Entity Linking
↓
SPARQL
↓
Graph Traversal
↓
Subgraph
↓
LLM
这就是 GraphRAG 的雏形。
二十八、为什么 Java 生态很适合企业知识图谱？
从我的角度来说，这是 Jena 比较现实的优势。
很多企业原来的技术栈：
Java
Spring
Oracle
MySQL
Kafka
Redis
如果突然上一套：
全 Python AI Stack
不一定适合。
Jena 可以直接：
Spring Boot
+
Jena
做：
Semantic Service
对于已有 Java 团队来说，迁移成本会低很多。
二十九、Jena + Spring Boot
完全可以：
Controller
↓
Service
↓
Jena
↓
TDB2
例如 API：
GET /api/graph/customer/{id}
内部：
SPARQL
查询：
Customer
↓
Order
↓
Product
再返回：
{
"customer": "...",
"orders": [],
"products": []
}
这就变成：
Graph API
三十、甚至可以做一个 Semantic Backend
我觉得这个词很好理解：
Semantic Backend
传统 Backend：
API
↓
Database
Semantic Backend：
API
↓
Ontology
↓
Knowledge Graph
↓
SPARQL
↓
Data
AI Agent：
↓
Semantic Backend
不再需要理解几百张表。
三十一、Jena 和 Owlready2 怎么选？
Owlready2：
Python
优点：
和 LLM / AI 生态结合方便
Jena：
Java
优点：
企业后端
服务化
SPARQL Server
RDF Infrastructure
所以我会这么理解：
Owlready2
↓
Ontology SDK
Jena：
↓
Semantic Platform
三十二、Jena 和 Ontop 怎么选？
Ontop：
Database
↓
Virtual Knowledge Graph
特点：
数据不搬
Jena：
RDF
↓
TDB2
特点：
真正构建 RDF Graph
所以：
如果数据已经在大型关系数据库：
Ontop
可能更好。
如果你就是要建设：
RDF Knowledge Graph
Jena 更合适。
三十三、Jena 和 Neo4j 怎么选？
Neo4j：
Property Graph
+
Cypher
Jena：
RDF
+
SPARQL
+
OWL
Neo4j 更工程化：
Graph Application
Jena 更标准化：
Semantic Web
如果你特别需要：
Ontology
OWL
RDF Standard
SPARQL
Jena 会更自然。
三十四、从我的角度，我会怎么用 Jena？
如果让我现在做一个项目，我不会只做：
企业知识图谱展示页面
我会做：
Semantic Agent Backend
架构：
Business Documents
Database
API
↓
LLM
↓
Knowledge Extraction
↓
Apache Jena
↓
TDB2
↓
Fuseki
↓
AI Agent / MCP
也就是说：
让 Jena 成为 Agent 背后的一层 Semantic Data Service。
三十五、Jena + MCP 也很有想象力
可以自己做一个 MCP Server：
MCP
↓
SPARQL
↓
Fuseki
Agent 调用：
query_knowledge_graph
输入：
“JavaPub 和哪些 AI 项目有关？”
MCP Server：
Natural Language
↓
SPARQL
↓
Fuseki
↓
Result
再返回给：
Claude Code
Codex
Cursor
这就开始变成：
Knowledge Tool
三十六、我越来越觉得“知识图谱不是数据库，而是 AI 的理解层”
以前做后端：
Database
就是：
Source of Truth
但 AI Agent：
不能直接理解：
500 张表
3000 个字段
几十种系统
它需要：
Customer
Order
Product
Supplier
Payment
这样的：
Semantic World
所以：
Database
↓
Data Layer
Knowledge Graph：
↓
Semantic Layer
Agent：
↓
Action Layer
三十七、把前面的项目串起来看
现在我们已经聊了：
Owlready2
Ontop
Graphiti
TrustGraph
Apache Jena
其实已经可以形成一张架构图：
AI Agent
↓
TrustGraph
Context Layer
┌──────────────┼──────────────┐
↓ ↓ ↓
Graphiti Jena Ontop
↓ ↓ ↓
Memory RDF / SPARQL Database
↑
Ontology
↑
Owlready2
可以理解成：
Owlready2
↓
Ontology Creation
Jena
↓
Semantic Infrastructure
Ontop
↓
Database Semantic Layer
Graphiti
↓
Temporal Memory
TrustGraph
↓
Agent Context
这套组合已经非常接近：
Ontology-driven Agent Stack
三十八、Apache Jena 现在还值得学吗？
我的答案是：
值得。
但不是因为：
Semantic Web 很流行。
而是因为：
AI Agent 时代重新需要结构化语义。
以前大家嫌：
RDF
OWL
SPARQL
太复杂。
现在问题反过来了：
LLM 太自由。
于是我们又需要：
Schema
Ontology
Constraint
Graph
Reasoning
给它增加结构。
这时候 Jena 这类成熟工具重新有价值。
三十九、当前版本需要注意什么？
截至 2026 年 8 月，Apache Jena 官方下载页已经提供：
Apache Jena 6.2.0
以及：
Apache Jena Fuseki 6.2.0
Jena 6 要求：
Java 21+
Jena 6.0 开始还明确推荐：
TDB2
并逐渐弱化旧的 TDB1。
所以如果现在新建项目：
Java 21
+
Jena 6
+
TDB2
+
Fuseki
会比较合理。
四十、总结
如果只用一句话总结 Apache Jena：
Apache Jena 是 Java 生态里一套非常成熟的 RDF、SPARQL、Ontology、推理和知识图谱基础设施。
它解决：
如何表示知识？
↓
RDF
如何查询：
↓
SPARQL
如何存：
↓
TDB2
如何提供服务：
↓
Fuseki
如何定义世界：
↓
Ontology
如何验证：
↓
SHACL
最后：
↓
AI Agent
如果把整个链条压缩成：
Business Data
↓
RDF
↓
Ontology
↓
Knowledge Graph
↓
SPARQL
↓
Context
↓
Agent
Apache Jena 正好处于这条链中间非常关键的位置。
从我的角度来说，我现在不会把它只看成一个：
Semantic Web 老项目
我更愿意把它看成：
Java 世界里一个成熟的 Semantic Backend 基础设施。
过去：
Spring Boot
+
MySQL
解决：
程序如何访问数据。
未来：
Spring Boot
+
Apache Jena
+
Knowledge Graph
可能解决：
AI 如何理解业务数据。
这也是我觉得 Apache Jena 在 Agent 时代重新值得关注的地方。
项目地址
GitHub：
https://github.com/apache/jena
官网：
https://jena.apache.org/
王仕宇 JavaPub
