文化遗产数据标准落地：OGC 构建模块弥合语义与地理空间鸿沟

文化遗产领域从不缺少描述“事物是什么”的标准。从描述对象、地点、人物和事件的 CIDOC-CRM，到记录来源与活动的 PROV-O，再到空间表达的 GeoJSON、传感器数据的 SOSA/SSN、数据集元数据的 DCAT，以及面向欧洲文化遗产门户的 EDM，标准体系已经相当完备。当文档工作涉及三维与测绘时，IFC、CityGML、LandInfra 和 INSPIRE 等第二组标准随即登场。问题在于，文化遗产文档恰好位于语义世界与地理空间、BIM 世界的接缝处，而实践中的大部分困难正源于此。

每个标准都是对其所针对问题的正确答案，但没有任何一个标准会直接给出下一层内容：面向具体用例的实际数据模型。仍然需要有人决定，一条关于某个展厅的记录包含哪些字段、状况评估如何表示为一组字段、房间如何与所在建筑及采集它的扫描数据关联，并将这些决策逐一绑定到标准术语上，形成软件可以操作的形式。概念参考模型告诉你如何思考文化遗产信息，但它有意不替你完成建模，也无法告诉软件“指向父站点的链接缺失了”。 于是每个项目都自行建模，且做法各不相同。结果是，数据集都正确声明遵循同一套标准，却仍然无法互操作。本文介绍的正是如何一次性、公开地完成这项建模工作，并以软件可操作的形式发布。 OGC 构建模块是小型、自包含的规范或其中可复用的部分。每个模块对应一类事物的数据模型，并以稳定名称打包为单一包，例如 ogc.heritage.building，其中包含模式、文档、校验规则、示例和测试。注册库则是已发布并持续维护的模块集合。OGC Blocks 是构建这些模块的框架，许多通用领域已有公开注册库。 模块可以组合，这是整个方法赖以运转的机制。最直观的形式是剖面：整体采用另一个模块，然后对其约束或扩展，而不重新定义或分叉。更关键的是，一个模块不限于单一父级，它可以同时继承多个模块、组合其他模块的部分、收窄继承内容，并在一个定义中提供备选父级。剖面正是通过组合这些技术构建的，而不是沿单一继承线向下特化。 这能让数据模型保持恰当规模。宽泛标准为广泛适用而写，直接采用往往同时导致过度指定和指定不足：携带了与数据无关的术语和选项，却仍无法表达用例所依赖的关键区分。而且，无论怎么调整，单一标准常常无法独自覆盖足够范围。组合则允许按需取舍。 HERITALISE 项目以都灵附近的维纳利亚王宫为试点，其中大画廊的文档需求涵盖建筑、场地、表面状况、激光扫描与摄影测量，以及执行者、时间和仪器。项目采用 OGC 构建模块方法，将规范定义为小型模块化组件，便于验证、标准合规和扩展，最终发布了 bblocks-heritage——一个包含 27 个可复用构建模块的公共注册库。其背后的 AI 辅助方法可迁移至任何领域。 对于构建或指定数据系统的团队而言，这一层的价值在于：软件可以检查真实文件、理解它，并将其传递下去。文化遗产数据由此从“声明遵循标准”迈向“可验证地遵循标准”，并为跨项目互操作奠定基础。若想了解 27 个构建模块的具体构成、组合机制的技术细节以及 AI 辅助方法的完整流程，请点击原文链接查看完整技术内容。