开源地理空间智能项目中的本体思想 4-1:查询篇——五个跨库案例实测:快是治理出来的
4-0 概览里说跨库查询慢在跨端点拉数据数据搬到本地就没这个问题一条链能答出多少由最弱的一环决定。本篇用五个查询案例把这两句话坐实前四个在 QLever 公共端点上真实跑过2026-08-13原始结果全部留档口径见附录第五个来自 KnowWhereGraph 2025 年系统论文的能力演示。跳数从两跳加到五跳数据源从两个加到五个。每个案例拆成四块问题、每一跳、替代的笨办法及代价、图谱办法为什么快。本篇一句话结论跨库查询的快不是引擎的魔法是数据治理三件事里缝数据这件活被提前干完了。数据来源两个OpenStreetMap简称 OSM全球志愿者维护的地图数据经 osm2rdf 转成 RDF空间关系已预先算好存成数据和 Wikidata维基媒体基金会的结构化知识库。什么叫跳、标识约定见 4-0 概览 [1]。案例一2 跳柏林哪个区的居民最不缺公园问题柏林 12 个区每个区每万居民拥有多少个公园跳这一跳问什么数据在哪第 1 跳空间柏林包含哪 12 个区每个区包含哪些公园OSMQLever 端点缝合每个区关系上挂着wikidata标签值是 Q 号如 Marzahn-Hellersdorf 是 Q119284OSM 志愿者手工标注第 2 跳语义拿 Q 号查该区人口Wikidata联邦查询实测结果2026-08-13几十毫秒Marzahn-Hellersdorf 363 个公园、约 29.7 万人每万人 12 个Neukölln 138 个、约 33.2 万人每万人 4 个。最富的区是最穷的区的 3 倍。笨办法PostGIS 或 QGIS 算空间部分这一步确实容易然后从 Wikidata 导出 12 个区的人口表按区名 join。代价在 join区名带变音符号Neukölln、有历史改名、多语言拼写不一。12 个区手工对一对还行换成全德国 400 个县就是一整天的体力活且下月数据更新要重来一遍。图谱为什么快Q 号是全球唯一标识符两个库靠它缝合不靠名字空间关系已物化成数据查询只是图遍历。案例二3 跳柏林的轨道交通车站归谁运营问题柏林的铁路车站分别由哪些公司运营跳这一跳问什么数据在哪第 1 跳空间柏林包含哪些铁路车站OSM缝合车站上的operator:wikidata标签运营商的 Q 号OSM 志愿者标注第 2 跳运营商是哪家公司Wikidata第 3 跳公司的名称、总部、性质Wikidata实测结果2026-08-1335 毫秒带运营商标签的车站里Berliner Verkehrsbetriebe柏林交通公司11 座DB InfraGO德铁基础设施公司5 座。这个案例的教训是覆盖率柏林的轨道车站数以百计标了operator:wikidata的只有 16 个。跨库查询的答案质量取决于链条上最弱一跳的覆盖率。标签没标的车站查询再快也查不出来。这就是 4-0 里那句大白话的第一次现身数据治理得不好什么高科技都白搭。这里的治理缺的是第二件事缝数据里的一个动作——志愿者还没给车站标 Q 号。笨办法导出柏林车站清单逐个搜索引擎查运营商再查公司背景。几百个车站几天。而且结果是一张死表下月 OSM 更新就过期。图谱为什么快同案例一——共享标识符加联邦查询区别是多走了一跳语义关系成本没有增加。案例三4 跳柏林的雨水最终流进哪片海问题流经柏林的河流顺着水系往下走最终汇入哪片海跳这一跳问什么数据在哪第 1 跳空间哪些河流与柏林相交OSM缝合河流上的wikidata标签OSM 志愿者标注第 2 跳这条河注入哪条河Wikidata 属性 P403注入水体Wikidata第 3 跳那条河又注入哪条河Wikidata第 4 跳最终注入哪片海Wikidata实测结果2026-08-13与柏林相交的河流有施普雷河Spree、哈弗尔河Havel、达默河Dahme等。顺着注入关系走施普雷河→哈弗尔河→易北河Elbe→北海。柏林的雨水最终流进北海。这个案例说明两个库的分工OSM 管河在哪几何Wikidata 管河流向哪水系关系。同一条河在两个库里各存一半信息Q 号把两半缝成一条完整的链。笨办法GIS 叠加分析能答第一跳——哪些河流过柏林。但注入关系在 GIS 数据里根本不存在那是百科知识。剩下的路是逐条河翻百科全书手工往下追。河流一多比如换成全德国追链变成人肉递归。图谱为什么快水系关系在 Wikidata 里本来就是图上的边顺着边走即可无论走几跳都是同一种走法。案例四5 跳柏林的博物馆都是谁创办的问题柏林 247 家博物馆创办者分别是哪国人跳这一跳问什么数据在哪第 1 跳空间柏林包含哪些博物馆OSM247 家缝合博物馆的wikidata标签OSM144 家有标签第 2 跳博物馆对应的 Wikidata 条目Wikidata第 3 跳创办者是谁属性 P112Wikidata第 4 跳创办者的国籍属性 P27Wikidata第 5 跳按国籍分组计数查询里现算口径说明第 5 跳严格说是聚合统计不是图上的一次跳转计入跳数是为了说清这条链一共走了几步。实测结果2026-08-135.2 秒有创办者国籍信息的 15 家博物馆里创办者国籍为德国的 7 家普鲁士王国的 4 家法国、德意志帝国、德意志国、勃兰登堡藩侯国各 1 家。两个观察。第一国籍一列冒出普鲁士王国“勃兰登堡藩侯国”——历史政权在图谱里也是正经对象有自己的标识符可以和今天的人建立关系。表格数据库里没有这一层。第二覆盖率漏斗247 家博物馆144 家有 Q 号只有 15 家查得到创办者加国籍。五跳查询的答案天花板由最弱一跳决定——这与案例二的教训是同一个数据治理的第二件事缝数据只缝了一半查询就只能答出一半。笨办法144 家博物馆逐个打开维基百科页面找到创办者再点开创办者页面找国籍填进 Excel。一个人干一整天还难免抄错。图谱为什么快创办者、国籍都是 Wikidata 里现成的边唯一慢的是联邦查询要跨端点拉数据——5.2 秒是四个实测案例里最慢的。为什么慢、以及数据都在本地是不是就没这个问题4-0 概览的第一句大白话已经答了慢在跨端点搬中间结果QLever 实际就是把 Wikidata 和 OSM 各装一份在本地绕开实时跨网。即便这样5.2 秒和一整天的手工劳动仍然是几秒钟和一天的区别。案例五多源应急山火、医院与行政区——KnowWhereGraph 的预付路线这个案例不是本文实测的。它来自 KnowWhereGraph以下简称 KWG2025 年系统论文的能力演示本系列 02 篇已核查 [2]。问题得克萨斯州哈里斯县有哪些山火的路径与机场相交跳这一跳问什么数据在哪第 1 跳哈里斯县包含哪些山火事件应急部门的火灾记录第 2 跳山火的火场边界折算成 S2 网格单元KWG 建库时预计算第 3 跳同一批网格单元上有哪些机场航空数据另一机构第 4 跳机场所在行政区、人口普查局数据又一机构原始数据分散在应急部门、气象局、普查局、农业部等 30 多个公开数据集里各用各的编码。KWG 的做法是把对齐工作在建库时一次干完所有数据集映射到同一套本体150 个类、70 种关系、75 种属性空间上统一折算到 S2 网格。建库完成后上面那道题就是一条查询几秒钟出答案。这个案例在本篇里的角色它就是笨办法做彻底之后的样子。下载、清洗、对齐、入库——传统数据仓库也干这些。区别在于 KWG 用一套公开的本体当图纸用全球唯一标识符当连接键再把结果作为公共端点开放。它的快不是魔法是把案例一到四里每次查询现做的对齐工作改成建库时一次做完——数据治理三件事KWG 在建库阶段就全部干完了。笨办法灾害发生时现做 ETL抽取、转换、加载下载四个机构的数据设计临时 schema对齐编码入库再查。02 篇的原话灾害不会等你对齐完再蔓延。附那套本体公开可下载——但下载到的是图纸不是服务能看能下载分三层2026-08-20 核查 [3][4][5]设计说明本体论文公开在 arXiv编号 2410.13948期刊版见 Journal of Web Semantics150 个类、70 种关系、75 种属性的设计取舍都在里面。文档仓库GitHub 组织下的kwg-ontologies仓库按数据集分目录给出本体文档行政区、空气质量、普查、山火等外加一份void.ttl清单列出全图谱由哪些子图构成。可下载的本体文件以灾害子本体为例kwg-hazard-ontology仓库里有一个ontology-hazard-kwg.owl文件BSD-3-Clause 许可可直接下载。打开看就是一份 OWL 词汇表定义了河流洪水“城市洪水”碎屑流等灾害类型谁是谁的子类、有什么因果关系逐条写明。本体里的每个类都有自己的标识符形如kwg-ont:Wildfire展开是http://stko-kwg.geog.ucsb.edu/lod/ontology/Wildfire——这就是 KWG 里的全球唯一标识符。一个口径要说清KWG 的查询服务当前处于停机状态02 篇已记录2026-08-20 本机实测这个标识符的在线解析也返回异常重定向。停机的是什么服务能说清。KWG 当年对外的服务是三样 [2]SPARQL 端点懂查询语言的人直接发查询一次跨 30 多个数据集取数、Knowledge Explorer 网页界面在地图上圈定区域、按条件逐层点选、GIS 插件在 ArcGIS Pro 或 QGIS 里调用图谱做地理增强。02 篇 2026-08 核查时官网和文档可达SPARQL 端点执行查询报 GraphDB 许可过期错误——也就是说停掉的是替你查的服务不是给你看的图纸。图纸只是文档它怎么发挥作用三条具体的路。第一当词汇表直接复用你建自己的图谱时灾害类型直接引用kwg-ont:Wildfire这些现成的类不用自己从零造一套词。第二当对齐的靶子你把自家数据映射到这套类上就和所有映射到同一套图纸的数据天然对上了——这正是数据治理三件事里缝数据的施工图。第三机器可读.owl文件不是给人看的文档格式它能直接装进图谱工具和推理机配合 SHACL 形状做入库前的机器校验。图纸公开而服务停机的意义就在这里答题的机器停了但下一个团队想建自己的灾害图谱不用从零画图。全球唯一标识符是通用标准叫 IRI它包括什么什么时候用现成的、什么时候自己定义它和 Wikidata 是什么关系它是什么、包括什么。它的正式名称是 IRIInternationalized Resource Identifier国际化资源标识符互联网工程任务组IETF的标准RFC 3987W3C 的 RDF 标准规定每个对象用 IRI 命名 [6]。拿本篇反复出现的一个 IRI 拆开看——http://www.wikidata.org/entity/Q119284http://协议说明它可以在 Web 上访问www.wikidata.org域名说明这个号是谁发的——全球唯一性就靠域名体系保证谁拥有域名谁在自家域名下编号天然不和别人撞车/entity/Q119284路径号码本身这里就是 Wikidata 的 Q 号。IRI 可以理解为网址的国际化扩展和网址同源但允许编号里出现中文等非英文字符。什么时候用现成的什么时候自己定义。判断标准只有一条这个对象在全世界是不是已经有公认编号了。有——国家、城市、河流、公司这类公共事物——就直接引用现成的 IRI不要自己另造一个两个库引用同一个 IRI说的就是同一个东西这正是案例一到四缝合的全部秘密。没有——你的门店、你的传感器、你的某次观测是你业务独有的对象——就在自己控制的域名下发号自己保证唯一、自己维护解析。KWG 的格子就是后者S2 编号规则是 Google 公开发布的但这个格子是 KWG 图谱里的一个对象这件事是 KWG 用自家域名声明的。它和 Wikidata 是什么关系。Wikidata 是目前最大的公共 IRI 发放处之一它给海量事物各编了一个 Q 号配上它的域名就成了全球唯一 IRI任何人都可以引用。OSM 志愿者把 Q 号标在地图对象上案例一到四的wikidata标签就是把两个库缝起来的那根线。同样的道理跨端点的联邦查询也不是 QLever 项目的私有功能——它是 W3C 的 SPARQL 1.1 联邦查询标准2013 年发布QLever 只是实现了这套标准的引擎之一 [7]。标准公有、实现多家这正是标准存在的意义4-4 收尾篇的横评会回到这一点。本篇小结快是治理出来的天花板由没治理完的部分决定五个查询案例合起来说了一件事跨库查询的快是数据治理提前付出来的答案的天花板是数据治理没做完的那部分决定的。但到目前为止进图谱的都是对象和关系这类数据。地理智能还有一大块数据没进场遥感影像——动辄 TB 的栅格进不了也不该进图谱。影像怎么和图谱协作4-2 影像篇接着讲。附录A.1 实测口径与留档案例一2026-08-13QLever OSM Planet 端点联邦 Wikidata 端点。空间谓词走www.opengis.net/rdf#命名空间osm2rdf 物化数据人口取 Wikidata 各时点声明中的最大值。留档docs/assets/topic3/qlever-berlin-parks-per-district.json。案例二同日同端点。仅统计带operator:wikidata标签的railwaystation对象柏林共 16 个BVG 11、DB InfraGO 5未标标签的车站不在口径内。留档docs/assets/topic3/qlever-berlin-stations-by-operator.json。案例三同日先查 OSM 端点与柏林相交且带 Q 号的河流 13 个对象再查 Wikidata 端点的注入水体P403链Spree→Havel→Elbe→North Sea。Elbe 另有 German Bight、Heligoland Bight 等注入声明均为北海的组成部分。留档docs/assets/topic3/wikidata-river-mouth-chain.json。案例四同日同端点联邦查询耗时 5.2 秒。覆盖漏斗博物馆 247 家→带 Q 号 144 家→创办者与国籍齐全 15 家。国籍含历史政权普鲁士王国等为 Wikidata 原始口径。留档docs/assets/topic3/qlever-berlin-museum-founders.json。案例五非本文实测来自 KWG 2025 年系统论文的能力演示与本系列 02 篇已核查材料。KWG 公共端点本次从本机不可达2026-08-13未重跑。A.2 术语速查跳从一个对象走到另一个对象的一次跨越4-0 概览定义。联邦查询一条查询跨多个服务端点发问SPARQL 里用SERVICE关键字实现W3C 标准不是某个引擎的私有功能。IRI国际化资源标识符IETF 标准RFC 3987的全球唯一标识符RDF 用它给每个对象命名。可以粗略理解为可引用的网址式编号。Q 号Wikidata 项目内部给每个条目编的号如 Q119284配上www.wikidata.org/entity/前缀即成全球唯一 IRI。物化把能预先算出的结果如空间关系在建库时算好并写成数据查询时直接取不再计算。OWLW3C 的本体描述语言本体文件如上文的.owl文件用它写类、关系、属性及其约束。KWG 本体KnowWhereGraph 的图纸150 个类、70 种关系、75 种属性论文、文档仓库、子本体文件均公开见案例五附注。参考文献[1] 本系列 4-0 概览《案例集概览——地理智能的地基是数据治理和查询》。[2] KnowWhereGraph 系统论文The KnowWhereGraph: A Large-Scale Geo-Knowledge Graph for Interdisciplinary Knowledge Discovery and Geo-Enrichment. arXiv:2502.138742025https://arxiv.org/abs/2502.13874 核查过程见本系列 02 篇《KnowWhereGraph》。[3] KWG 本体论文The KnowWhereGraph Ontology. arXiv:2410.139482024https://arxiv.org/abs/2410.13948 2026-08-06 核查。[4] KWG 本体文档仓库KnowWhereGraph/kwg-ontologies含按数据集组织的本体文档与void.ttl清单https://github.com/KnowWhereGraph/kwg-ontologies 2026-08-20 经 GitHub API 核查。[5] KWG 灾害子本体仓库KnowWhereGraph/kwg-hazard-ontology含ontology-hazard-kwg.owlBSD-3-Clause 许可https://github.com/KnowWhereGraph/kwg-hazard-ontology 2026-08-20 经 GitHub API 核查该文件自述为草案。[6] IRI 标准RFC 3987, Internationalized Resource Identifiers (IRIs)IETF2005https://www.rfc-editor.org/rfc/rfc3987 。[7] SPARQL 1.1 Federated QueryW3C 推荐标准2013-03-21https://www.w3.org/TR/sparql11-federated-query/ 。[8] QLever OSM Planet 与 Wikidata 公共端点实测记录2026-08-13原始 JSON 四份见附录 A.1 留档清单。版权声明本文为CSDN博主「LadiesAndGentlemen」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。原文链接https://blog.csdn.net/qiupingzhao/article/details/163625924 开源 github