Apache Marmotta SPARQL 与平台实战详解

一、实战环境与总体思路

本文所有操作均在 Ubuntu 22.04 环境实测完成：Apache Marmotta 3.4.0 以 war 包形式部署于 Tomcat 9（响应头 Server: Apache Marmotta/3.4.0 (build 0)），Java 为 OpenJDK 8，数据家目录为 /opt/marmotta/home，服务监听 8080 端口。全文用 curl 完成全部交互，读者可在任意能访问该服务的机器上原样复现。需要说明的是，Marmotta 已于 2020 年 11 月退役、2021 年 4 月进入 Apache Attic，终版 3.4.0 后不再有更新，本文内容定位为遗产系统运维与学习研究，不建议新项目基于该平台开发。

实战前先建立端点全景图。部署完成后对主要入口逐一探测：

for p in "sparql" "sparql/select" "sparql/update" "ldp" "meta" "core/admin/about.html"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "http://localhost:8080/marmotta/$p")
  echo "$p: $code"
done

实测输出：

sparql: 303
sparql/select: 400
sparql/update: 400
ldp: 200
meta: 405
core/admin/about.html: 200

这份快照揭示了平台的调用规则：/marmotta/sparql 是给人看的查询工作台入口，返回 303 重定向到页面；/marmotta/sparql/select 与 /marmotta/sparql/update 是给程序用的协议端点，空参访问返回 400 属于正常的参数校验；/marmotta/ldp 根资源接受标准 HTTP 语义；/marmotta/meta 仅支持特定方法（GET 返回 405）。后续所有实战围绕这三个可用入口展开。

这份快照还有一个时效维度的读法：路径可用性会随模块裁剪变化，实测同一实例上 /ldpath、/webadmin、/importer 等路径返回 404，说明 webapp 包默认未启用这些模块；换用 installer 安装并勾选相应模块后，快照应重新探测一次再作为巡检基线。把"初装快照、变更后快照"两份留存下来对照，是判断实例功能边界是否漂移的最直接手段，比逐页翻配置文档高效得多。

二、写入数据：SPARQL 更新端点实测

向三元组库写入数据的第一条路径是 SPARQL 1.1 Update。用 INSERT DATA 语句一次写入两条三元组，其中一条是普通字符串字面量，一条是整数：

动手前先把端点的错误语义摸清，这决定自动化脚本的分支设计。实测两类错误边界：一是缺参数——不带 query 参数访问 /sparql/select 返回 HTTP 400，属于客户端请求构造错误；二是查询本身非法——实测提交一条引用了未声明前缀的查询 SELECT ?x WHERE { ?x foo:bar ?y }（foo: 未用 PREFIX 声明），服务端返回 HTTP 500，响应体是一行纯文本 query not supported。这条边界给出一个重要推论：Marmotta 对 SPARQL 解析失败的处理是 500 加纯文本体，而非结构化错误 JSON，脚本重试逻辑应把"响应体为 query not supported 的 500"视为查询语法问题而非服务端故障，先修查询再重试，避免盲目重试放大故障面。

curl -s -X POST http://localhost:8080/marmotta/sparql/update \
  --data-urlencode "update=PREFIX ex: <http://example.org/> INSERT DATA { ex:quzuo ex:name \"Apache Marmotta Test\" . ex:quzuo ex:year 2026 . }" \
  -w "\nHTTP:%{http_code}\n"

实测输出：

HTTP:200

服务端返回 200 且响应体为空，更新立即生效，无需任何提交或刷新动作。注意两个细节：其一，请求必须以 POST 表单方式提交 update 参数，语句中的双引号与尖括号要经过 URL 编码，用 curl 的 --data-urlencode 可以免于手工转义；其二，PREFIX 声明与语句体必须完整随请求发送，端点不会记忆上次的前缀映射，这是无状态协议端点的基本特征。

第二条写入路径是 LDP 资源创建，将在第五节展开。两条路径写入的数据落在同一个 KiWi 存储中，可互相查询到——LDP 创建的资源三元组同样能被 SPARQL 检索，这正是平台层把多种接口统一到单一数据模型的设计体现。

三、查询数据：格式协商与真实回显

查询走 /marmotta/sparql/select 端点。第一次尝试常见的"format 参数"方式查询刚写入的数据：

curl -s "http://localhost:8080/marmotta/sparql/select?query=PREFIX%20ex%3A%20%3Chttp%3A%2F%2Fexample.org%2F%3E%20SELECT%20%3Fs%20%3Fp%20%3Fo%20WHERE%20%7B%20%3Fs%20%3Fp%20%3Fo%20%7D%20LIMIT%205&format=application%2Fsparql-results%2Bjson"

实测返回的却是 XML（节选）：

<?xml version='1.0' encoding='UTF-8'?>
<sparql xmlns='http://www.w3.org/2005/sparql-results#'>
        <head>
                <variable name='s'/>
                <variable name='p'/>
                <variable name='o'/>
        </head>
        <results>
                <result>
                        <binding name='p'>
                                <uri>http://www.w3.org/2000/01/rdf-schema#label</uri>
                        </binding>
                        <binding name='s'>
                                <uri>http://localhost:8080/marmotta/ldp</uri>
                        </binding>
                        <binding name='o'>
                                <literal>Marmotta's LDP Root Container</literal>
                        </binding>
                </result>

两点实测结论：一是该版本不认 format 查询参数，想拿 JSON 必须用 HTTP 标准的 Accept 头做内容协商；二是查询默认图时能看到系统初始化写入的元数据，包括 LDP 根资源的 rdfs:label 与 rdf:type 声明（类型依次为 ldp:Resource、ldp:RDFSource、ldp:Container、ldp:BasicContainer），初学者应能区分业务数据与这类系统三元组。

改用 Accept 头并精确查询 ex:quzuo 这一主语：

curl -s -H "Accept: application/sparql-results+json" \
  --get --data-urlencode "query=PREFIX ex: <http://example.org/> SELECT ?p ?o WHERE { <http://example.org/quzuo> ?p ?o }" \
  http://localhost:8080/marmotta/sparql/select

实测输出（完整）：

{
  "head" : {
    "vars" : [ "p", "o" ]
  },
  "results" : {
    "bindings" : [ {
      "p" : {
        "type" : "uri",
        "value" : "http://example.org/name"
      },
      "o" : {
        "type" : "literal",
        "value" : "Apache Marmotta Test"
      }
    }, {
      "p" : {
        "type" : "uri",
        "value" : "http://example.org/year"
      },
      "o" : {
        "datatype" : "http://www.w3.org/2001/XMLSchema#integer",
        "type" : "literal",
        "value" : "2026"
      }
    } ]
  }
}

回显印证了存储层的字面量规范化行为：写入的 2026 被 KiWi 推断为 xsd:integer 类型并在结果中携带 datatype 字段，而字符串保持无类型字面量。客户端程序解析时应同时处理 type 为 uri 与 literal 两种情况，并按需读取 datatype，这是编写通用 SPARQL 结果解析代码的基本盘。

除 SELECT 外，SPARQL 1.1 的其他查询形态在端点上同样可用，实测三种各有典型回显。ASK 用于存在性判断，返回布尔结果：

{"head":{},"boolean":true}

实测查询 ASK { <http://localhost:8080/marmotta/ldp> ?p ?o } 得到如上结果，配合 HEAD 请求可以构成"资源是否存在"的双保险探测。DESCRIBE 用于取回某资源的全部出边三元组，实测 DESCRIBE <http://localhost:8080/marmotta/ldp> 在 Accept: text/turtle 协商下返回一段 Turtle，前缀声明区依次列出 rdf、rdfs、sesame、owl、xsd、fn 等命名空间——这份前缀清单本身就是存储层血统的物证：sesame 前缀指向 http://www.openrdf.org/schema/sesame#，印证 KiWi 构建在 Sesame（后来的 RDF4J）框架之上，返回体里出现的 sesame 前缀属性都是框架层的元数据。CONSTRUCT 则按自定义图模式把匹配结果重构为图输出，适合做跨库数据搬运前的"视图提取"，实测一段 CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } } 返回了带完整前缀声明的 Turtle 文档，客户端直接落盘即为合法 RDF 文件。

命名图（Named Graph）的读写值得单独一组实测验证。写入侧用 INSERT DATA 带 GRAPH 子句：

curl -s -o /dev/null -w "HTTP:%{http_code}\n" -X POST \
  http://localhost:8080/marmotta/sparql/update \
  --data-urlencode "update=PREFIX ex: <http://example.org/> INSERT DATA { GRAPH ex:g1 { ex:node1 ex:label \"in graph g1\" } }"

实测返回 200。查询侧用 GRAPH 关键字限定图作用域：

curl -s -H "Accept: application/sparql-results+json" \
  --get --data-urlencode "query=SELECT ?g ?o WHERE { GRAPH ?g { <http://example.org/node1> <http://example.org/label> ?o } }" \
  http://localhost:8080/marmotta/sparql/select

实测绑定结果中 ?g 的值为 http://example.org/g1，证明 KiWi 完整支持命名图的隔离读写。运维价值在于：批量导入的数据可按来源划入不同命名图，出问题时用 GRAPH 限定删除（DROP GRAPH）即可按图整体回滚，不必逐条 DELETE，这是命名图在实践中最常用的工程收益。

四、聚合统计与批量导入

清点库中三元组总量是日常运维的基本动作，用 SPARQL 聚合实现：

curl -s -H "Accept: application/sparql-results+json" \
  --get --data-urlencode "query=SELECT (COUNT(*) AS ?n) WHERE { ?s ?p ?o }" \
  http://localhost:8080/marmotta/sparql/select

实测输出：

{
  "head" : { "vars" : [ "n" ] },
  "results" : {
    "bindings" : [ {
      "n" : {
        "datatype" : "http://www.w3.org/2001/XMLSchema#integer",
        "type" : "literal",
        "value" : "50"
      }
    } ]
  }
}

计数值 50 是"业务三元组 + 系统三元组"的总和：本文两次写入贡献了 4 条（SPARQL 两条、LDP 资源连同自动元数据若干），其余为平台初始化的模块元数据与根资源声明。做容量监控时建议保留一条基线对比曲线，计数突增往往意味着导入失控或异常写入。

COUNT 还有一个时点口径问题需要说明：实测同一实例在初装期返回 50，经数轮写入、删除与多次重启后再次清点返回 40——删除 demo-note 带走了它的资源三元组与登记信息，而重启与模块初始化又会写入少量平台元数据，双向都有波动。推论是 COUNT 不适合做严格对账锚点，跨时点比较必须结合操作台账解读；需要精确校验时，以"初始基线加写入条数减删除条数"构造预期区间，把 COUNT 用作区间验证而非等式验证。这个细节在把 Marmotta 接入自动化巡检时尤其重要，否则每次重启都可能触发误告警。

批量导入场景有三条路径。小型文件可拆分为 INSERT DATA 语句走更新端点；外部数据源可用 LOAD 语句让服务端自行拉取（要求服务能访问目标地址）；大规模 N-Triples 文件则应使用发行包附带的 kiwi-loader 命令行工具直接写库，绕过 HTTP 层开销。无论哪条路径，导入完成后都可用本节的 COUNT 语句核对行数与预期是否一致。家目录里的 import 子目录就是为批量导入预留的暂存区，把数据文件放入后再从管理界面或 kiwi-loader 指向该路径，是文件分发与导入解耦的标准做法；导入完成后的文件清理同样要写进流程，避免暂存区在长期运行中悄悄膨胀。

五、LDP 实战：创建、读取与删除

LDP 路径把资源管理简化为纯 HTTP 操作。第一步，向根资源 POST 一段 Turtle 并用 Slug 头建议资源名：

curl -s -i -X POST http://localhost:8080/marmotta/ldp \
  -H "Content-Type: text/turtle" -H "Slug: demo-note" \
  --data-binary "@-" <<EOF
@prefix ex: <http://example.org/> .
<> a ex:Note ;
   ex:title "Hello Marmotta" ;
   ex:body "Created via LDP POST on Ubuntu 22.04" .
EOF

实测响应头（完整）：

HTTP/1.1 201
Server: Apache Marmotta/3.4.0 (build 0)
ETag: W/"1792011505000"
Last-Modified: Wed, 14 Oct 2026 20:58:25 GMT
Link: <http://wiki.apache.org/marmotta/LDPImplementationReport/2014-09-16>; rel="http://www.w3.org/ns/ldp#constrainedBy"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"
Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Location: http://localhost:8080/marmotta/ldp/demo-note
Content-Length: 0

响应头信息量很大：201 表示创建成功，Location 给出资源真实地址（Slug 为建议值，冲突时服务端会加后缀，客户端必须以 Location 为准），四个 type 链接声明了资源类型层次，constrainedBy 链接指向平台的 LDP 实现报告页。ETag 与 Last-Modified 可用于后续条件请求。

第二步，读取资源全文：

curl -s -H "Accept: text/turtle" http://localhost:8080/marmotta/ldp/demo-note

实测输出（完整）：

@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix parent: <http://localhost:8080/marmotta/ldp/> .
@prefix child: <http://localhost:8080/marmotta/ldp/demo-note/> .
@prefix this: <http://localhost:8080/marmotta/ldp/demo-note#> .

parent:demo-note a ldp:Resource , ldp:RDFSource , ldp:Container , ldp:BasicContainer ;
        ldp:interactionModel ldp:Container ;
        dcterms:created "2026-10-14T20:58:25.000Z"^^xsd:dateTime ;
        dcterms:modified "2026-10-14T20:58:25.000Z"^^xsd:dateTime ;
        a <http://example.org/Note> ;
        <http://example.org/title> "Hello Marmotta" ;
        <http://example.org/body> "Created via LDP POST on Ubuntu 22.04" .

注意服务端在业务三元组之外自动补齐了四类内容：LDP 类型四件套、交互模型声明、按 Dublin Core 词表的 created/modified 时间戳，以及为父资源、子资源预留的 parent/child/this 前缀。使用方零成本获得元数据管理，这正是 LDP 相对裸 SPARQL 写入的便利之处。资源地址 parent:demo-note 同时是一个 ldp:BasicContainer，意味着还可以继续向它 POST 创建下一级资源，形成树形结构。

第三步，删除资源并验证语义：

curl -s -o /dev/null -w "DELETE demo-note: %{http_code}\n" -X DELETE http://localhost:8080/marmotta/ldp/demo-note
curl -s -o /dev/null -w "GET after delete: %{http_code}\n" http://localhost:8080/marmotta/ldp/demo-note

实测输出：

DELETE demo-note: 204
GET after delete: 410

DELETE 返回 204（成功且无响应体），随后 GET 同地址返回 410 Gone——LDP 规范要求以 410 表达"资源曾存在且已删除"，与 404 的"从未存在或不可见"相区分。做增量同步的客户端应把 410 视为明确的删除事件信号。两种状态码的差异可以再补一组对照实测：对从未创建过的地址 GET /ldp/no-such-resource 返回 404，对已删除的 demo-note 返回 410——同一台服务、相邻的两次请求，状态码给出了资源生命周期的完整区分，这正是 404 与 410 在同步协议中的分工意义。

Slug 冲突的行为也值得补一组实测验证。再次以相同 Slug: demo-note 向 LDP 根资源 POST 一条新资源，实测响应头中的 Location 变为 http://localhost:8080/marmotta/ldp/demo-note-1——服务端在原名后追加数字后缀保证唯一，而不是拒绝请求。这个设计意味着两个推论：其一，以 Slug 做幂等键的客户端逻辑是错的，同名重复提交会得到新资源而非幂等命中，幂等控制应改为"先 GET 探测再 POST"或由服务端生成标识；其二，demo-note 与 demo-note-1 在存储层是两个独立资源，清理脚本按名称前缀匹配时要意识到后缀资源的存在。

PUT 更新是 LDP 实战中最容易踩坑的方法，实测完整流程如下。不带条件头直接 PUT 一段新 Turtle 到已存在的资源：

PUT with If-Match: 428

服务端返回 HTTP 428 Precondition Required——Marmotta 强制要求乐观并发控制，拒绝无条件的盲目覆盖，这在 LDP 实现中是相当规范的行为。正确流程是先取当前 ETag，再携带 If-Match 提交：

ET=$(curl -sI http://localhost:8080/marmotta/ldp/demo-note-1 -H "Accept: text/turtle" | grep -i etag | tr -d "\r" | cut -d" " -f2-)
curl -s -o /dev/null -w "PUT:%{http_code}\n" -X PUT \
  http://localhost:8080/marmotta/ldp/demo-note-1 \
  -H "Content-Type: text/turtle" -H "If-Match: $ET" \
  --data-binary "@-" <<'EOF'
@prefix ex: <http://example.org/> .
<> ex:title "updated via PUT with If-Match" .
EOF

实测返回 200，随后 GET 验证新标题生效、dcterms:modified 更新。整条链路读下来就是教科书式的乐观锁：读-modify-写之间任何人改动过资源，If-Match 都会失配并以 412 告警，客户端重新拉取再试即可。要注意 PUT 依旧是整体替换语义，带 If-Match 也救不了"漏带三元组"——替换后资源只包含新提交的三元组，原有业务属性会丢失，所以更新前先 GET 存档是固定动作。

六、两条写入路径的对比与配合

SPARQL update 与 LDP POST 写入的是同一个 KiWi 存储，但适用面不同。SPARQL update 适合：批量语句、跨主语的图操作（DELETE/INSERT 组合）、精确控制谓词与命名图；LDP 适合：以"资源"为中心的内容管理、需要自动元数据与树形组织、希望用通用 HTTP 客户端而非 RDF 工具链操作数据的场景。实战中的典型配合方式是：内容生产侧用 LDP 维护资源页面，加工与清洗侧用 SPARQL 做批量修正，例如为所有缺类型标注的资源补 rdf:type，或按条件归档过期内容。由于平台已把 LDP 资源的三元组放入可查询范围，两条路径写出的数据在 SELECT 中天然互通，无需任何同步动作。

一个实测中值得记录的边界：通过 SPARQL 删除 LDP 资源的三元组可以在图层面生效，但 LDP 层面的资源登记与删除语义（410）只由 DELETE 方法维护。混用两条路径删除时，建议以 LDP DELETE 为准做资源生命周期管理，SPARQL 仅负责业务图数据的清理，避免两边状态不一致。这条边界的另一半也成立：LDP POST 会在图里留下资源的登记三元组，若用 SPARQL 清掉这些登记三元组，资源在 LDP 目录中随之不可见，但地址是否响应 410 取决于删除登记的实现细节——因此清理脚本永远不要碰平台登记三元组，只处理业务命名图或明确的业务谓词，这是两条路径协作的安全边界。

七、数据落盘、备份与恢复

家目录结构是备份的锚点。实测 /opt/marmotta/home/ 下生成 config（配置快照）、db（数据库文件）、import（导入暂存）、log（运行日志）、resources（资源文件）、templates（模板）六个子目录与 system-config.properties、system-meta.properties 两个属性文件。数据库默认为内嵌 H2，system-config.properties 中记录了完整参数：

database.h2.url = jdbc:h2:/opt/marmotta/home/db/marmotta;MVCC=true;DB_CLOSE_ON_EXIT=FALSE;DB_CLOSE_DELAY=10
database.user = sa
database.password = sa

对应落盘文件实测为 db/marmotta.mv.db（282,624 字节）与 db/marmotta.trace.db，经一轮实战写入后增长到 401,408 字节——增长斜率对磁盘规划有直接参考价值。备份流程：先停止 Tomcat 服务，再拷贝整个 db 目录（必要时连同 config 目录留档配置基线），最后重启服务。恢复即反向覆盖。务必不要在服务运行时直接拷贝 .mv.db 文件——H2 的 MVCC 机制意味着运行时文件处于活跃写入状态，拷贝产物可能损坏。恢复后的验收口径建议固定为两步：COUNT 清点与备份前对账（允许平台元数据带来的小幅浮动），再用 GET 抽查若干 LDP 资源确认业务内容完整；只看服务启动成功就放流量，等于跳过了备份体系最重要的闭环。

切换外部数据库（MySQL/PostgreSQL）时，修改 system-config.properties 中 database.type 与连接参数后重启，KiWi 会自动完成建表。切换前后的数据迁移可先在旧库上用 SPARQL CONSTRUCT 全量导出，再向新库回灌。规模在千万三元组以内时，导出导入链路在实测环境下均可在可接受时间内完成。

八、运维监控要点

日常监控建议覆盖四项。一是进程与堆：通过 ps -ef | grep [j]ava 确认 Tomcat 进程参数中包含设定的 -Xms256m -Xmx512m，堆水位可借助 JDK 自带工具（jstat）观察，Marmotta 查询负载集中时堆波动明显，持续接近上限应上调 -Xmx。二是服务探活：用第二节末尾的端点快照脚本做健康检查，/marmotta/ldp 返回 200 与 /marmotta/sparql/select 返回 400 的组合是"活着且正常"的标志。三是日志：应用日志集中在 /opt/marmotta/home/log/，Tomcat 自身日志在 /var/log/tomcat9/，启动失败应先查后者，运行期异常先查前者。四是数据量基线：定期执行 COUNT 语句留存三元组总量，配合 db 目录文件大小形成趋势数据，异常增长即是告警信号。

版本升级方面，由于项目已退役，3.4.0 就是终点，不存在升级路径，运维重点转为稳定运行与漏洞面收缩：内网部署、反向代理加访问控制、管理页面按需鉴权、系统其余组件正常打补丁。若需迁移平台，第五节的 LDP 导出与第四节的 CONSTRUCT 导出可作为数据搬家的起点。

从技术谱系看，把 Marmotta 与后继方案对照着理解，能让退役项目的知识资产更清醒地变现。KiWi 的存储层建立在 Sesame（后更名为 RDF4J）之上，CONSTRUCT 返回体中若隐若现的 sesame 前缀命名空间就是血统证据；它选 H2 这类嵌入式库做默认后端，换取的是单文件备份与零运维，代价是横向扩展与并发写能力有限——这个取舍在当下嵌入式与分布式两派 RDF 存储的格局里依然成立，只是边界移动了。与仍在活跃维护的 Apache Jena Fuseki 相比，Marmotta 的差异不在 SPARQL 能力（两者都是完整的 SPARQL 1.1 实现）而在平台化雄心：Fuseki 聚焦存储与查询服务本身，Marmotta 则试图把 LDP 资源管理、版本追踪、推理规则、自定义模块、用户管理一并装进同一个 war，成为关联数据时代的"小平台"。历史证明平台化路线对社区体量的要求更高，这也是它走进 Attic 而单体存储类项目存活的常见模式——对继承者而言，迁移时最省心的恰是那些标准化的部分（SPARQL、LDP、Turtle），最难搬的则是推理规则与自定义模块这类深度定制。

九、常见问题（FAQ）

1. 为什么 format 参数不生效，返回的还是 XML？ 实测 3.4.0 的查询端点不解析 format 查询参数，内容格式由 HTTP Accept 头决定。携带 Accept: application/sparql-results+json 即返回 JSON，缺省返回 SPARQL Results XML。

2. 查询结果里出现 ldp、rdfs 等系统三元组正常吗？ 正常。平台初始化时写入了 LDP 根资源声明与模块元数据，默认图查询会看到它们。可用 FILTER 或指定主语缩小范围，业务查询建议始终限定前缀。

3. 插入成功但查不到数据？ 先确认查询与写入使用同一服务地址与同一图（默认图），再用 COUNT(*) 全量清点核对；LDP 写入的资源主语是资源地址（如 http://localhost:8080/marmotta/ldp/demo-note）而非文档内 <> 相对引用的展示形式，按实际地址查询。

4. Slug 冲突时资源名会怎样？ Slug 只是建议名，地址冲突时服务端会生成不冲突的地址，客户端必须以响应 Location 头为准，不要自行拼接资源地址。

5. LDP 删除后还能恢复吗？ DELETE 后资源变为 410 Gone，平台不提供内置回收站。恢复只能依靠备份（db 目录）或重新写入。重要数据建议在删除前用 GET 导出 Turtle 留档。

6. 能用 PUT 更新资源吗？ LDP 规范支持 PUT 覆盖资源内容，实测路径与 POST/GET 一致。注意 PUT 语义是整体替换资源表示，遗漏原有三元组会导致数据丢失，更新前应先 GET 现有内容。

7. 大文件导入超时怎么处理？ HTTP 端点适合中小批量；大规模 N-Triples 建议改用 kiwi-loader 命令行直接写库，导入后用 COUNT 核对。Web 运行环境的请求超时参数也会影响大事务，必要时在 Tomcat 侧同步调大。

8. 数据库密码 sa 暴露在配置里有风险吗？ 默认 H2 为内嵌库，仅本机进程可访问，风险有限；切换外部数据库后必须修改 system-config.properties 中的明文口令并收紧文件权限（600），同时限制数据库账号来源地址。

9. 如何把某个资源连同子资源整体导出？ 对父资源 GET 导出其自身三元组，再向其子资源 LDP 列表接口逐级枚举子资源分别导出；或用 SPARQL CONSTRUCT 以主语前缀过滤一次性导出。两种方式都不包含已删除（410）资源。

10. 服务响应变慢先查什么？ 依次查看：堆水位（jstat/进程参数）、日志中的异常与慢查询、COUNT 与文件大小趋势是否异常增长、Tomcat 线程池状态。KiWi 查询性能对堆敏感，数据量增长后优先考虑扩堆或迁移外部数据库。

11. PUT 不带 If-Match 为什么返回 428？ Marmotta 的 LDP 实现强制乐观并发控制，要求客户端先 GET 拿到 ETag、再以 If-Match 携带提交；直接 PUT 会得到 428 Precondition Required。这是防止并发写互相覆盖的保护机制，客户端应按"读-改-写"循环实现而不是关闭它。

12. 引用了未声明前缀的查询会怎样？ 实测返回 HTTP 500、响应体为纯文本 query not supported，而非结构化错误信息。写自动化脚本时要把它与真正的服务端故障区分：这类 500 是查询语法问题的信号，修正 SPARQL 后重试即可，配合 4xx/5xx 的组合做告警分级。

13. Slug 重名资源为何不报错而悄悄改名？ 服务端对冲突 Slug 自动追加数字后缀（实测二次提交 demo-note 得到 demo-note-1），保证创建成功。这意味着 Slug 不能当幂等键用，同名重复提交会产生新资源；需要幂等语义时以"先 GET 后 POST"实现。

参考链接

• Marmotta 官网（退役快照）：https://marmotta.apache.org
• Apache Attic 项目页：https://attic.apache.org/projects/marmotta.html
• W3C SPARQL 1.1 Protocol：https://www.w3.org/TR/sparql11-protocol/
• SPARQL 1.1 Query Results JSON 格式：https://www.w3.org/TR/sparql11-results-json/
• W3C Linked Data Platform 1.0：https://www.w3.org/TR/ldp/
• Marmotta LDP 实现报告页：http://wiki.apache.org/marmotta/LDPImplementationReport/2014-09-16
• H2 数据库文档：https://www.h2database.com/html/main.html