摘要

  • RFC 5165 登记了 ogc 命名空间，却没有要求 OGC 永远只发 URN；后来的 OGC 政策把新公共标识符默认形式改为 HTTP URI。
  • 迁移是否成功，不取决于新链接能否打开，而取决于注册表能否保留权威、状态、等价关系、前任/后继与历史版本。

一个旧系统保存的是 urn:ogc:def:crs:EPSG::4326，新系统展示的是一个 HTTP 地址。两边看起来都在说同一个坐标参考系。真正需要证明的却有三件事：这两种形式是否由 OGC 权威记录为等价；请求时取回的是哪一个版本；当年的计算究竟使用了哪份定义。

RFC 5165 在 2008 年以 Informational RFC 发布。它把 ogc 登记为 URN Namespace Identifier，给出 urn:ogc:{OGCresource}:{ResourceSpecificString} 结构，并由 OGC Naming Authority 管理资源类别与登记值。这个动作建立了全球可识别的命名入口，而不是把未来发放政策锁死。

OGC 后来的 Policy Directive 33 要求：新的公共持久 OGC 标识符原则上使用 HTTP URI，不再默认发 URN；新标准和新的大版本也应改用 HTTP 形式，除非 OGC-NA 批准例外。

这不是宣布旧 URN 失效。2021 年的 OGC Naming Authority Procedures 仍然定义 HTTP URI 与 URN 两套持久命名形式，并说明二者可以提供等价标识。HTTP 形式可利用 DNS 和 Web 基础设施；URN 本身不承诺位置或特定解析机制。

兼容不是重定向成功

把旧 URN 全部导向“最新”页面，能让大多数浏览器看起来工作正常，却可能破坏历史可重复性。旧数据集引用的定义可能已经被纠正、替代或退役。新页面如果只呈现当前定义，用户无法判断旧计算是否依据另一版本。

因此迁移需要保留至少四种关系：旧形式与新形式的权威等价；具体条目的当前状态；被替代条目与后继条目的链接；曾经取得的表示与时间。缺少任意一项，解析成功都可能只是在把历史请求改写成今天的答案。

OGC 当前政策把注册表设为规范来源。可见路径的规律是治理工具，不是客户端自行造名的授权。知道 /def/crs/EPSG/0/ 的模式，可以拼出一个像真的地址；只有注册项或获准的构造规则，才能说明它是否属于正式命名空间。

单个资源与按规则生成的名字承担不同承诺

Category A 名字对应服务中可取得的离散资源，需要逐项登记。Category X 名字按规则或算法构造，可能没有独立可取得的页面；权威登记的是类别和构造规则。

这一区分决定运维方法。对 A 类，资源不可取得可能是故障。对 X 类，用“每个名字都要返回独立页面”做健康检查反而会误判。X 类更需要核对规则、权威、版本与客户端解释。

本轮研究抓取的两个 OGC EPSG 定义地址都在跳转后返回 HTTP 200。这只能证明两个路径在抓取时刻给出了响应，不能外推为所有 OGC 名字、历史版本、表示格式、网络路径或客户端都可用。

状态变化是持久性的一部分

OGC 注册流程不是一个永久的布尔值。提交项尚未被接受；接受后成为 valid；后来可以 superseded，并记录前任与后继；也可以 retired，表示不再推荐但未必有替代。experimental、invalid、stable 又各有含义。

持久命名不是要求所有旧项永远“有效”，而是要求状态变化不抹去身份与历史。一个已被替代的名字仍可能是复算旧数据的唯一入口。一个退役名字不应继续进入新系统，却不应因此从审计记录中消失。

RFC 5165 还允许未登记的实验类型，并明确承认不同用户可能为不同用途选择同一值。实验区的自由建立在“不把碰撞当成正式授权”之上。一旦实验值进入长期配置，就必须补齐项目范围、发行者、日期与正式迁移路径。

完整证据链应分别记录 IANA NID、OGC 类别或条目、发行或受委托权威、使用当时的状态、等价关系、解析响应、取得的表示、版本及应用结果。字符串相同，只能关闭第一层识别问题。

来源