BIBFRAME还没开发完成，关联数据/语义网中的URI有可能在MARC记录中率先使用？至少美国合作编目计划（PCC）已经开始实质性行动。参见：
创制和获取URI的常用词表和参考源指南（2018-3-2）
编目常见URI问题：什么时候开始用？RWO又是什么？（2018-3-7）
在PCC的《URI常见问题》（URI FAQs, 2018-2-6）中，几次提到W3C文件《语义网的酷URI》。为更清楚地理解URI，找来仔细阅读。然后发现此文件中其实并没有解释《URI常见问题》中提到的dereference，因此又找到另一个W3C文件（见后）作为补充。以下为若干摘译（括号中数字为《语义网的酷URI》小节号）。
Cool URIs for the Semantic Web (W3C Interest Group Note, 03 December 2008)
摘要：资源描述框架RDF允许用户以计算机可处理的方式描述Web文档和真实世界中的概念——人物、组织、论题和事物。在Web上发布这样的描述会创建语义Web。URI（统一资源标识符）非常重要，既提供了框架本身的核心，又提供了RDF和Web之间的链接。本文件提供了其有效使用的指南；讨论了两种策略，称为303 URI和散列URI；给出了使用这些解决方案的几个网站的指针，并简要讨论了为什么其他几个方案有问题。
【URI】（1）
在语义网上，所有的信息必须表达为关于“资源”的陈述。资源由“统一资源标识符”（URI）标识。这种建模方法是“资源描述框架”（RDF）的核心。
【内容协商】（2.1）
Web客户端和服务器使用HTTP协议请求Web文档的表示并发回响应，HTTP具有强大的称为“内容协商”的机制来提供相同Web文档的不同格式和语言版本。
当用户代理（如浏览器）发出HTTP请求时，会随某些HTTP标头发送，以指示它喜欢的数据格式和语言。服务器然后从其文件系统中选择最佳匹配或按需生成所需内容，然后将其发送回客户端。
内容协商往往是一种扭曲的实现：服务器不是直接回答，而是重定向到找到适当表示的另一个URL。重定向由一个特殊的“状态代码”[响应码]表示。
【酷URI】要求（3）
1、在网上：给一个URI，使用标准Web传输协议HTTP，机器应该获得RDF数据，人类应该获得可读的表示如HTML。
2、无歧义：Web文档的标识符与其他资源的标识符之间不应混淆，一个URI不能同时代表一个Web文档和一个真实世界对象。
【Web文档 vs 真实世界对象】（3）
【Web文档 = 信息资源】根据《万维网的体系结构》第一卷，如果其所有基本特征都可以在消息中传达，则我们有一个Web文档（称为“信息资源”），如网页、图像或产品目录。
【真实世界对象 RWO = 事物 Thing】如人和汽车，甚至抽象的想法和不存在的事物，如神话中的独角兽。
【酷URI】设计要求（4.5）
1、简单性：简短助记。
2、稳定性：尽可能持久不变。
3、可管理性：如URI路径包含年份、可以每年更改URI模式而不影响旧URI；再如保留所有303 URI在专用子域上以简化未来迁移。
【真实世界对象URI的2种解决方案】（4）：
1、Hash URI（#）：如 http://www.example.com/about#alice
适用于相当小而稳定的资源集合，如RDF Schema词表和OWL本体。只需简单上传静态RDF文件到Web服务器、无需任何特殊配置，适合快速发布RDF。
2、303 URI（303 See Other 重定向）：
– 转发到通用文档，如：http://www.example.com/id/alice
重定向到：http://www.example.com/doc/alice，再经内容协商，
向机器提供：http://www.example.com/doc/alice.rdf
向人提供：http://www.example.com/doc/alice.html
– 转发到不同文档，如：http://www.example.com/id/alice（Alice这个人的标识符），重定向经内容协商，
向机器提供：http://www.example.com/data/alice（描述Alisce的RDF文档）
向人提供：http://www.example.com/people/alice（Alice的主页，Web文档）
以上3个文档在内容中当提供互相链接、揭示文档间关系（4.6）
【内容协商 Content negotiation vs 解引 dereference】（译自：Best Practice Recipes for Publishing RDF Vocabularies, W3C Working Group Note 28 August 2008）
[按PCC的URI FAQ 5：解引，即检索由URI标识的资源的一种表示] 当一个HTTP客户端尝试解引一个URI时，可以指定优先接收响应哪类内容，通过在请求讯息标头中包含Accept:字段……。当服务器接收一个请求，它能使用Accept:字段的值，选择最合适的可用响应，尝试尽可能满足客户端的首选。这个过程即内容协商的一个实例。
——— 附：响应码（response code）、Cool URI ———
关于HTTP URI消除歧义的简单规则，转引本文件之参考文献中的建议：
[httpRange-14] Resolved, Roy Fielding. 18 June 2005. http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html.
a）如果一个“http”资源对一个GET请求的响应码是2xx，那么被那个URI标识的资源是一个信息资源；【Web文档】
b）如果一个“http”资源对一个GET请求的响应码是303（See Other），那么被那个URI标识的资源可以是任何资源；
c）如果一个“http”资源对一个GET请求的响应码是4xx（错误），那么这个资源性质未知。
为什么称“酷URI”？源自Tim Berners-Lee的文章：
Cool URIs does not change Cool URIs don’t change, Tim Berners-Lee, 1998. http://www.w3.org/Provider/Style/URI.
什么让URI很酷？
酷的URI是不变的URI。
什么样的URI会变？
URI本身不变：是人改变了它们。
via Cool URIs in a RESTful World / by Thomas Bandholtz on Apr 08, 2008
中译版：RESTful世界里的Cool URI / 译者 王锐 发布于 2008年4月16日【上述译文略有修改】