开源地理空间智能项目中的本体思想 4-4：收尾篇——五种做法怎么选，治理之后还剩什么活

八个案例全部讲完：4-1 的五个查询案例（四个实测、一个论文案例）、4-2 的两个影像构造案例、4-3 的一个选址构造案例。这些案例里一共出现了五种干活的方式。本篇做三件事：把它们直接放在一起比较，说清每种场景该怎么选，再盘点数据治理之后还剩哪些技术活。

本篇一句话结论：做法按场景选------要跨机构、跨库、公开发布，目前只有 RDF+SPARQL 这一整套国际标准；而数据治理做完之后，存储、引擎、联邦、大模型、保鲜五类技术活一件都省不掉。

五种做法横评：只有 RDF 管到语义一致这一层

八个案例里出现过五种干活的方式：关系数据库+外键、空间数据库/GIS、属性图、JSON Schema 数据目录、RDF+SPARQL。直接比较（最后一列标明它出现在哪个案例里）：

做法	多跳查询	跨机构一致性	适合场景	短板	对应案例
关系数据库+外键	库内 join 极快	管不了------外键跨不出自己的库	单一机构、结构稳定的数据	没有共享标识符，跨机构靠导出对齐	未实际使用；出现在案例一至四"笨办法"的导出对齐环节
空间数据库/GIS（PostGIS、QGIS）	空间一跳极快	管不了	空间分析、地图生产	语义关系（注入、创办者）数据里根本没有	案例一至四、六、八的"笨办法"
属性图（Neo4j 等）	多跳遍历原生快	词表自定义，跨机构靠事先约定	单一组织内的复杂关系分析	无全球标识符、无联邦查询标准	本系列案例未实际使用，作为对照项
JSON Schema 数据目录（STAC 式）	不支持图遍历	管到"结构一致"一层	数据目录、接口校验	不做跨源标识符和关系语义	案例六（影像发现）
RDF+SPARQL（QLever、KWG）	多跳快，代价是存储膨胀与物化预付	管到"语义一致"：共享 IRI+共享词表+联邦标准	跨机构、跨库、要公开发布的数据	建模门槛高，效率靠预存换	案例一至五，及案例七、八的图谱环节

属性图一行要多说几句，前面各篇没给它戏份。属性图的代表实现是 Neo4j：数据存成节点和带属性的边，查询语言叫 Cypher；属性图查询语言在 2024 年有了 ISO 国际标准（GQL，ISO/IEC 39075） $1$ 。在单一组织内部，属性图完全行，多跳遍历往往比 RDF 引擎还快。它缺的不是能力，是两个公共标准：没有全球标识符标准，两个机构各建各的图、编号体系对不上；没有联邦查询标准，跨库发问没有统一问法。4-1 里靠 Q 号缝合两个库的查询，在属性图里不是不能写，而是每对接一个新来源就要单独约定一次------没有公共标准兜底。

属性图在单组织内 完全行------它缺的是跨机构的公共标识符和联邦标准；关系库加外键在单库内永远是最省的选择------外键解决不了"两个机构的库里说的是同一个区"这个问题。

技术选型：按场景选；跨机构公开发布，目前只有 RDF

RDF 是唯一的选择吗？不是。 本体思想------先把对象、属性、关系定义清楚再存数据------与载体无关：关系库的 schema、JSON Schema、RDF 本体都是它的载体。

原 04 长文说"RDF 多出来的是两样东西：全球唯一的标识符，和跨端点的联邦查询标准"，这句话要收紧了说才严谨：这两样东西不是 RDF 凭空多出来的，而是两个公开的国际标准------标识符是 IRI（IETF 标准，W3C 的 RDF 采用），联邦查询是 W3C 的 SPARQL 1.1 标准（4-1 查询篇已展开）。QLever 只是实现了这些标准的引擎之一，不是这两样东西的来源。同样要严格的是另一面：属性图并非做不到全球编号和跨库查询，而是没有公共标准，每做一对接就要单独约定一次。

所以选择标准是场景，对应上面五种做法：数据不出一个机构，关系数据库+外键最划算；图遍历深但不出一个组织，属性图也行；要跨机构、跨库、还要让陌生人不用打电话就能查你的数据------目前只有 RDF+SPARQL 这一整套 W3C 与 OGC 标准。 这正是 4-0 那句大白话的另一面：++数据治理的工作量守恒------不在建库时做完，就在每次查询时重做++，RDF 是唯一把"提前做完"做成了公共基础设施的路线。

规律：八个案例指向同五句话

++数据治理的工作量守恒。++跳数乘以数据源个数，就是总治理量。不在建库时做完（KWG 预对齐 30 多个数据集），就在每次查询时重做（每次按名字手工 join），或者摊给社区慢慢做（OSM 志愿者逐个标 Q 号）。QLever 的 13 毫秒和 KWG 的几秒钟，都是治理做完之后的效果。
地理智能的典型查询 = 空间一跳 + 语义多跳。 GIS 管得住空间那一跳，管不住后面的语义跳；百科全书和统计库管得住语义跳，管不住空间跳。把两段焊起来的是共享标识符------本系列里是 Q 号，KWG 里是 S2 格子编号，作用相同。
一致性分三层，一层比一层贵。 语法一致（文件能互相读）< 结构一致（字段对得上，JSON Schema 管到这层）< 语义一致（说的是同一个东西，要共享标识符和词表）。笨办法全部卡在第二层到第三层之间。
答案质量取决于最弱一跳。 博物馆案例里五跳查询只答出 15 家，车站案例里几百个车站只有 16 个带标签。链条设计得再漂亮，覆盖率最低的那一跳就是天花板。换成大白话：**数据治理得不好，什么高科技都白搭。**评估一个跨库方案，先数每一跳的覆盖率，再谈查询速度。

治理之后还剩五类技术活，外加研究人员的题

前面七个案例容易给人一个印象：数据治理三件事干完------图纸立好、数据缝好、质量管好------后面就是跑查询的事了。这个印象对了一半。治理解决的是"对不对"------不同来源的数据说的是不是同一个东西。剩下"快不快、稳不稳、好不好用"的问题，一个都少不了。按工程顺序摆一遍，每条附上当前水平。

（一）存储与索引：预存多少是个设计决策。 RDF 引擎的索引为"任意方向跳转"设计，主流做法是把三元组按主语、谓词、宾语的全排列存多份。QLever 在这条路上做到单机万亿级三元组（01 篇），Wikidata 和 OSM 全球数据都跑在单机公共端点上------这一层的当前水平是成熟 。真正的设计决策在物化：哪些关系预先算好存成数据，哪些留给查询时计算。QLever 物化六种空间关系，换来 13 毫秒的柏林公园查询；KWG 把推理结果也物化进去，290 亿条三元组里 80 亿条是推理补全的。存得越多查得越快，但存储膨胀、更新变慢。"哪些边值得预存"目前靠经验，没有自动化的成熟方法------这是这一层的主要待解决问题。

（二）引擎选型：标准在，实现参差。 标准词表是公共的，各引擎的实现范围不是。03 篇记录过一个实测插曲：大模型调用标准里定义的 geof:length 函数，QLever 跑了 949 秒后报错"不支持此函数"。选引擎实质是四维权衡：查询性能（QLever 领先）、推理能力（商业引擎 GraphDB 更全）、GeoSPARQL 函数覆盖（各家不一，以实测为准）、成本（开源 vs 商业许可）。当前水平：单机查询成熟，分布式 RDF 存储相对薄弱------QLever 自己走的也是单机大内存路线。

（三）联邦查询：标准里最不成熟的一环。 本系列自己就是证据：案例一跨端点查人口，27 毫秒；案例四跨端点查创办者国籍，5.2 秒。差了 200 倍，原因在联邦查询要把中间结果跨端点搬运，数据量一大就慢。端点可用性是另一个现实问题------4-1 写作时，KWG 的公共端点从本机就无法连通。当前水平：能演示，难生产。 认真对待延迟的系统都绕开了实时联邦：KWG 选择预集成（把 30 多个数据集搬进自家图谱），QLever 把 Wikidata 和 OSM 各装一份在自家机器上------所谓联邦，实际是"联邦的标准、本地的副本"，4-0 的第一句大白话说的就是它。

（四）接大模型：最热，也最不成熟。 这一块要拆开讲，它其实是两个方向。

方向一，大模型帮用户查图谱 （自然语言转查询），坑按出现的顺序排：词表太大塞不进模型的上下文（KWG 的 150 类、70 关系只是一例）；模型会幻觉出不存在的谓词；就算谓词对了，也可能调用引擎没实现的函数（上一条的 geof:length）；空间常识题"对人易、对模型难"（本系列 GRASP 一篇的主旨）。当前水平：单端点、简单模式的"自然语言转 SPARQL"已经可用；多跳加空间加联邦的组合查询，在 QALD 等公开评测集上仍是难题。工程上的续命办法是把词表检索（RAG）、形状文档、执行报错重试拼成脚手架。

方向二，大模型帮专家做治理，更值得关注：自动推荐数据集到本体的映射、生成对齐候选，把"立图纸、缝数据"里的体力活变成半体力活。但终审仍是业务专家------对齐错了，后面的一切都快而错。

（五）保鲜：物化的边会过期。 物化换效率的代价在更新端。03 篇附录提过一个口径细节：OSM 数据集每周更新，重跑同一个查询数字会漂移------底数变了，物化的空间边就得重算。KWG 的版本策略是"大变发新版、小变只记档"，新增数据过 SHACL 校验才入库。增量物化、跨库变更传播，目前都没有标准化的做法，各系统自己想办法。

业务专家管治理，工程师管权衡，研究人员管还没有标准答案的题

上面这些活常被分成两摊：治理是业务专家的活，解决"对不对"；五类技术活是工程师的权衡活，解决"快不快、稳不稳"。那研究人员干什么？答案已经散在上面的字里行间------每一节里标注了"没有成熟方法""没有标准化做法""仍是难题"的地方，就是研究人员的题：

"哪些边值得预存"的自动化决策（存储层）；
联邦查询的性能与可用性，让它从"能演示"走到"能生产"（联邦层）；
多跳、空间、联邦组合的自然语言查询，在 QALD 等评测集上过关（大模型层）；
增量物化与跨库变更传播的标准化（保鲜层）；
大模型辅助治理的可靠性------映射推荐、对齐候选错了怎么发现（治理层）。

这些问题的共同点是：工程上能绕，但没有公认的好解法。哪些是真问题、哪些已有近两年的进展，我们会在后续专题里按论文逐条核对。

结尾：语义层讲完了，动力层是下一站

八个案例里，前七个的活都在本体的语义层------对象、属性、关系；只有 4-2 的"写回"露了一次动力层的头。动作、权限、函数这另一半思想在真实项目里长什么样，我们后面会专门介绍它的体现，希望大家持续关注。

我们会持续分享地理空间智能相关的内容。有问题可以在下面留言，后面也会建一个群，让大家一起来交流。

附录

术语速查

五种做法：本系列统一名称------关系数据库+外键；空间数据库/GIS（PostGIS、QGIS）；属性图（Neo4j 等）；JSON Schema 数据目录（STAC 式）；RDF+SPARQL（QLever、KWG）。

GQL：属性图查询语言的 ISO 国际标准（ISO/IEC 39075，2024 年发布）；Cypher 是 Neo4j 的属性图查询语言。

QALD：Question Answering over Linked Data，面向链接数据的问答公开评测系列。

物化：把能预先算出的结果（推理结论、空间关系）在建库时算好并写成数据，查询时直接取，不再计算。

联邦查询：一条查询跨多个服务端点发问；W3C 的 SPARQL 1.1 标准，不是某个引擎的私有功能。

参考文献

$1$ GQL 标准：ISO/IEC 39075:2024, Information technology --- Database languages --- GQL，2024-04 发布；Neo4j 与 Cypher：https://neo4j.com/ 。

$2$ 本系列 4-0 概览、4-1 查询篇、4-2 影像篇、4-3 选址篇；01 篇《QLever》、02 篇《KnowWhereGraph》、03 篇《GeoSPARQL 与 OGC DGGS》。

$3$ QLever OSM Planet 与 Wikidata 公共端点实测记录（2026-08-13），原始 JSON 留档清单见 4-1 查询篇附录。

$4$ KnowWhereGraph 系统论文：arXiv:2502.13874，2025：https://arxiv.org/abs/2502.13874 。

$5$ STAC 规范：https://stacspec.org/ （4-2 影像篇专题）。

原文链接：https://blog.csdn.net/qiupingzhao/article/details/163625924 开源 github