2015年11月，约翰霍普金斯大学图书馆系统馆员Jonathan Rochkind在离职前2天，发表长篇博文《关联数据注意事项》（Linked Data Caution），表明他对关联数据的认识【参见：知识图谱、语义网、关联数据】。虽然他在总体上对图书馆应用关联数据现状持否定态度，但文章写得相当客观。他并不反对关联数据，他担心的是图书馆界把关联数据本身作为一个目标，并且“基于关联数据、重建围绕数据格式的基础设施（infrastructure）”，而不是以用户为中心的考虑。他认为所有这些问题，很大程度上是受到关联数据倡导者误导，以为更广泛的IT世界都在应用——或许曾经是事实，只是时过境迁？
文章从关联数据入门开始，内容丰富。摘译部分如下。（说明：“我”指原博文作者，【本人标注说明】）
– 什么是关联数据？
一个抽象数据模型——如何建模数据的模型。该模型说，所有元数据将列作一个“三元组”，（1）主体，（2）谓词（或关系），（3）客体。对这些数据元素，尽可能首选使用标识符，尤其是URI形式的标识符。URI作为标识符很好，因为基于域名，有很好“命名空间”途径以避免冲突，是全域标识符。
如同任何数据建模，仍然需要“领域模型”——你关心实体的正式清单（图书、人物），这些实体有什么特性、属性及相互关系。在图书馆世界，甚至在有计算机前，我们一直在创建这些正式的领域模型。我们称之为“词表控制”或“规范控制”。在关联数据中，领域模型采用形式为实体、属性和关系的标准共享URI标识符。为属性或关系建立有某种含义的标准共享URI，是基本的“词表控制”，而为实体建立标准共享URI，则是基本的“规范控制”。仍然需要通用词表，让关联数据可互操作。
– 语义网vs关联数据？vs RDF？【基本上是同义词】
RDF代表“资源描述框架”，实际上是“三元组”的抽象数据模型的官方名称。然后“关联数据”可理解为使用RDF和URI的数据，“语义网”是由很多人使用形成的生态系统。
– 实际上想做什么？用户在哪里？ 【略】
– 其他人真的做吗？也许没有
【1】谷歌在检索结果的丰富片断（rich snippets）和侧栏事实即知识图谱中使用。但谷歌为其知识图谱收割的大部分数据源实际上不是关联数据，而是谷歌收割、内部转为关联数据——然后实际上曝光关联数据化（三元组化）数据到更广泛的世界。
【2】Talis【图书馆2.0时代的著名英国公司】在2000年代中战略中心开始转向语义网/关联数据。2011年，他们实际上售出其图书馆管理部门，主要专注语义网技术。但很快在2012年，他们宣布“语义网和数据市场领域投资将停止。现在所有工作集中在教育行业。”【主导者Richard Wallis在2012年4月去OCLC，2015年7月离开】
【3】2009年《纽约时报》兴奋宣布一项计划，曝光其内部主题词表为关联数据。虽然数据仍在，但在我看来已在2010年放弃。
【4】在语义网/关联数据全盛期的一对大关联数据的数据库：Freebase始于2007年，在2010年被谷歌获得…2014年关闭；DBPedia开始更早、仍然存在…但不再引起激动与buzz。较新的WikiData（2012）仍然存在，被视为Freebase的后继者。人们普遍承认，这些项目都没有达到最初的希望，即导致实际有用的面向用户的产品或服务，仍然是实验。
我的感觉是：一般业内理解，关联数据不像人们在2007-2012年全盛期所想那样，事实上采用已减缓且逆转（谷歌趋势图）。 【 参见：语义网还是个事儿吗？ 】
事实上，图书馆及其同盟文化遗产部门，以及来自政府机构（尤其是英国）及学术出版（主要是Nature）的有限参与，是当前关联数据研究与实施的主要驱动者。我们是关联数据研究的某些领导者，我们不是跟随私营部门。在“信息检索”领域，图书馆作为研究与实施感兴趣及有用技术的驱动者，并没有什么错误——40-80年前，本行业在信息检索技术中是领导者，它将再次如此，当然高兴！但是我们不应该以“其他人都在做”作为我们活动的动机或理由——并非因为主要web参与者正重度投资于此（他们没有），这一定是个好主意；并非如果我们转换所有我们的基础结构到关联数据，因为所有人都这将这么做（他们不一定，并且大家都使用关联数据并不足以互操作，还需要在词表上协调，只是开始），我们就能以我们想要的方式与其他人互操作。
– 我在数据与服务互操作挑战上的经验 【9方面的例子】
过去7年多，我的主要工作是在图书馆环境中，参与集成来自不同系统、厂商和来源的服务与数据。……有些问题很适合关联数据。
但是，在我的经验中，几乎没有问题只需简单转换基础架构到关联数据，就能提供解决方案或基础进步。障碍经常在其根的商务模型（实体有你要互操作的数据，但不想共享它们的数据，因为保持封闭对他们具有商业价值；或者只是没有商业兴趣投资于需要更好分享数据的技术）；或者缺少共享的领域模型（词表控制）；或缺少人力创建/记录机读格式所需的数据。
关联数据既非必须也不足以解决我碰到的大多数实际障碍。简单转换到基于关联数据的基础设施，而不处理商业或领域模型问题完全没有帮助；不需要关联数据来解决商业或领域模型问题，也不清楚对此的帮助：主要的关联数据运动可能不是解决这些问题最有效、最具费用效益或最快速的方法。
以下是一些例子。
【1】我们有什么连续出版物馆藏？【需要机器可操作的馆藏记录格式】
【2】记录中缺少OCLC号或其他标识符【有共同的标识符，无需LD就可以做很多事】
【3】数据陈旧/准确性
【4】难以由数据获取格式/形式信息，表达用户所关注的【识别资源的格式/体裁】
【5】工作集分组和关系【FRBR化】
【6】馆藏/许可信息的多来源馆藏/许可信息的多来源
【7】谷歌图书不链出
【8】OpenURL，被时光冻结的标准【不再有人维护了？】
【9】从开放Web链接到图书馆复本
– 为什么人们对关联数据如此兴奋？
【从众心理】没人会因为买了IBM被开除
【真实信徒】尽管在图书馆界有关联数据咨询者，说服你全力投入关联数据而获利（自有所指）
我认为，图书馆决策者知道我们“需要把我们的东西放在谷歌中”，并被告知“关联数据”是这么做的一种途径，但对“在谷歌中”意味着什么没有清晰的图景。如我已经说的，我认为谷歌在关联数据上的投资或投入被夸大了，但确实schema.org标记可被谷歌用于丰富片断或知识图谱事实盒。我实际上同意，我们图书馆网页应该使用schema.org标记，以机器可读标记曝光其信息。对图书馆信息网页，现在这会有比目录页还强大的结果（丰富片断）。并且对目录书目页这么做也不难，不需要重建我们整个基础设施，我们的MARC数据就这么能相当简单地对照到schema.org，如Dan Scott已经用VuFind、Evergreen和Koha有效证明了（How discovery layers have closed off access to library resources, and other tales of schema.org）。是的，所有我们的“发现”网页应该这么做。Dan Scott报告说，那没有很大效果，但如果每个人都这么做会（有效果）。
– 我们应当做什么？
【1】保持怀疑。当然，对我也是。
【2】自学有关元数据技术【不被忽悠】
【3】把图书馆当作IT组织（至少大学图书馆是）。
【4】保持用户中心。“关联数据”不能成为你的目标。
【5】包含schema.org标记在你的网页和目录/发现页。为了曝光给谷歌，或其他人。
【6】避免以“是否支持关联数据”作为评估问题。
【7】在数据中放置标识符。我不在意它是不是作为URI，但是的，确保每条记录有一个OCLC号。是的，每条书目应该记录LCCN或其他标识符，关联到创作者规范记录，不只是标目。这是我无保留支持的“关联数据”建议。
【8】你应该信任谁？不信任任何人，呵呵。不过如果你要我的个人建议，注意Diane Hillmann，看她的博客。
【9】要求关联数据计划产生迭代增量【即一开始就有成果并逐步增加，而不是到遥远的未来才能显现效果】