Apache Jena 详解：Java 开发者如何真正搭起一套知识图谱与语义服务

前面我们讲了 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

https://javapub.net.cn/