用例：“开放图书馆”数据

原文链接：http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Open_Library_Data 名称：开放图书馆数据（Open Library Data）

名称 开放图书馆数据Open Library Data - Kai：使开放图书馆数据能够尽可能被其它的Web应用所重用。（牧羊人 Keven Liu 刘炜）

所有者

Karen Coyle (红色文字是Kai的反馈意见)

背景和现状

【格式说明】本用例应用的特定领域，需要事先特别说明。本部分就是用于说明该领域。 将该领域的说明和解释放在这个部分，能够使整个情境描述的文本简明扼要。如果本用例情境描述的重点在技术方面，这里可以主要用来描述现状。一个用例之所以重要，常常是因为其所设定的情景会带来很多问题。

开放图书馆是一个包含图书元数据的大型书目数据库（大约有2500万数据条目）。其中包含可以或不能开放存取的DAISY格式的文本，后者是仅供视障读者使用。元数据的来源有：图书馆书目记录、亚马逊网站的书目数据、出版商的ONIX数据、以及直接由开放图书馆用户输入的数据等。开放图书馆没有以图书馆标准格式MARC来存储这些数据，而是采用了一系列自行开发的模板，模板的结构为“键-值”对，其中一些组合成类似于FRBR/FRAD模型的实体形式，例如“作品”和“作者”（仅限个人作者）实体，还有一个“版本”实体是参照MARC格式的书目数据设立的。将来如果全面采用FRBR模型，这些元素可以进一步区分为“作品”或“表达”的元素。

Kai：开放图书馆中的数据并不符合图书馆标准。个人姓名格式也非来自图书馆数据，因此也不再与图书馆规范数据格式有任何联系。属性也不是MARC数据中的“子字段”（例如，题名和副题名被当做单独的字串）。国会图书馆主题标目已经分面，分为：主题、地点、时间（题材作为“主题”处理）。因此直接将开放图书馆中的书目数据与传统图书馆的数据进行交互是困难的。但从另一方面来看，开放图书馆中的书目数据与维基百科条目数据进行交互就比大多数传统图书馆的数据更加用户友好（本段内容从“问题”部分移到此处）。

目标

【格式说明】用两个陈述说明： (1) 本情境在不提及“关联数据”概念的情况下，如何说明问题； (2) 我们应该如何利用关联数据技术达到这个目标。

以RDF方式输出开放图书馆的数据以便方便地成为关联数据的一份子。

Kai：(1)应当尽可能提高开放图书馆中数据重用的可能性，是这种可能性最大化。对于开放图书馆中的数据，至少应支持以下目标：

使任意网站能够直接链接到开放图书馆中的记录；

如果开放图书馆中有原文的话，允许彼任意网站的用户看到原文；

使用户以尽可能容易的方式链接至开放图书馆中的数据记录，例如链接到某个作品的表现（manifestation），同时立即提供同一个作品的其它单件（item）或表现的信息，如果有全文的话。

(2) 关联数据技术能够很容易地用来将开放图书馆中的数据与其特定的表现联系（参考）起来。书目数据通过开放而被“参引”（dereference），或者通过提供一个SPARQL端点来加强网站的引用。（Bibliographic data can be exposed by dereferencing or an SPARQL end-point to enhance the citation on the website）。对于第三个目标，需要合适的数据模型，可喜的是开放图书馆已经有了。通过采用适当的词表（如FRBR），有关信息能够以标准的形式提供。

META: 我想造成这些混淆的原因是大家都被“目标”这个词误导了。应该有一个最高目标，说明我们为什么写所有这些用例的原因，解决诸如“我们应该以关联数据方式发布数据”的大问题。但是当我们在写这些用例的时候，必须记住我们的目标是描述用例中角色的需求。这些角色（或许我们应该辟出专门的段落明确这些角色）是系统和数据的真正用户，他们将受惠于关联数据。对于角色需求的分析应该改变视角，从开发者（生产者）的角度转变到“用户”（消费者）的视角。这才是软件开发对于用例的起码要求。描述一个具体应用的用户能做和会做的事情能够有助于获得具体的需求，从而开发一个更加切合实际的应用系统。

这并不是说数据生产商不能作为系统中的具体角色或者用户。数据生产商在数据维护或优化时就成了消费者，他们“使用”系统和关联数据技术来改进他们自身的数据。这里可能会让人有些迷惑哦！

用例情境描述

【格式说明】情景描述部分主要描述各种角色在系统中进行交互的情景，应该专注于描述情境中对于用户需求的满足。不必描述具体的技术实现，以及如何采用关联数据等。

1. 网上有各种需要参考到图书的情况，但是基本上都无法链接到图书本身。开放图书馆中的每本电子书其实都可以提供这种引文或参考链接，当网上有全文电子书时直接向用户提供原文。

2. 开放图书馆中的数据库包含有版本信息，可以用来建立“版本-作品”关系，满足查询特定版本作品的需求。例如，用户搜索图书馆数据库能找到一本书的一个版本，用户所需的某个具体表现可能没有电子版，利用开放图书馆中的“版本-作品”关系，能够判定是否该作品是否另有表现，于是可以判定是否有该表现的电子版可以获取。

Kai：这里没有补充意见。该节内容应该提供十分宝贵的用例分析内容。

用例中关联数据的应用 【格式说明】该节内容描述采用关联数据技术实现上述用例的方法。注意应从一个抽象的层面描述关联数据的用法，而不要过于拘泥于具体的应用和词表。提示：不要局限于图书馆领域。

建立大量的关联书目数据条目，取自万维网上可以利用的各类资源。

Kai：通过向开放图书馆中的元数据记录以及其参考的全文资源赋予URI，建立起初步的链接关系。通过采用SPARQL端点或“参引”URI并返回相关RDF信息等方法，RDF和SPARQL能提供发布和使用这些资源的基本方法。

目前利用FRBR词汇作为基本数据模型在Web上发布数据的方法，能够发布关于“作品”、“表现”和“单件”的有用信息，开放图书馆的实践已经展现了标准和可重用的做法。

现有工作（可选） 【格式说明】本节内容列出实现上述用例的现有技术或方法。提示：图书馆领域的具体方法可以在这里阐述。

Kai：开放图书馆已经以关联数据的形式发布数据，但是由于上面提到的问题，利用这些数据并不容易。以下是发布数据的具体实例：

作者的普通页面： http://openlibrary.org/authors/OL22022A/Barbara_Cartland

作者的RDF数据： http://openlibrary.org/authors/OL22022A.rdf

作品的普通页面：http://openlibrary.org/works/OL6037025W/Code

作品的RDF数据：http://openlibrary.org/works/OL6037025W.rdf

版本的普通页面：http://openlibrary.org/books/OL6807502M/Code

版本的RDF数据：http://openlibrary.org/books/OL6807502M.rdf

相关词表（可选） 【格式说明】这里可以列出和说明所采用的或相关的词表（元素集合及取值词表）：

foaf

frbr

rdvocab

dcterms

问题和局限

【格式说明】本节列出为什么本情境难以实现的原因，包括可能并不具备的前提条件、技术障碍等等。技术上面临的挑战尤其需要在这里加以明确。这样能够有助于制定对策路线图以克服挑战。

Kai：以下文本调整至“背景”部分，当然不一定正确，还可商量。;-))

开放图书馆中的数据并不符合图书馆标准。个人姓名格式也非来自图书馆数据，因此也不再与图书馆规范数据格式有任何联系。属性也不是MARC数据中的“子字段”（例如，题名和副题名被当做单独的字串）。国会图书馆主题标目已经分面，分为：主题、地点、时间（题材作为“主题”处理）。因此直接将开放图书馆中的书目数据与传统图书馆的数据进行交互是困难的。但从另一方面来看，开放图书馆中的书目数据与维基百科条目数据进行交互就比大多数传统图书馆的数据更加用户友好。

Kai：开放图书馆的数据很难轻易地映射为支持图书馆标准的数据。尤其对于个人姓名来说尤其成问题，因为他们未能与规范数据进行链接。这个链接必须另外提供，个人姓名要保持一致，对于用户而言，直接显示个人姓名是必须的。一般而言，具有挑战的问题是如何维护一种简便可用的形式，并与其它图书馆数据进行整合和加以利用，以及使人们可以利用开放图书馆的数据，

相关用例及非预期用法（可选）

【格式说明】本情境的上述内容描述了一个具体的利用关联数据的案例，但是根据这个情境所作出的解决方案，也适用于其它案例。本节抓取了适用上述情境的系统的一些非预期用法。

以下由安东尼（Antoine）根据这个内容添加：

书目网络（Bibliographic Network） 能够部分利用本案例提供的数据发布方法。

图书馆数据范围和主题

维度和主题用来组织用例，同时有助于进一步明确尚未涉及的部分。如果有需要说明的主题或维度在上文中没有说明，可在此以星号“*”注明。

• 这些内容不在最初的列表中，建议加上

参考文献（可选） 本部分列出引用文献和网站。

回到： 图书馆关联数据用例解读目录 LLD Use Cases Chinese Shepherd http://www.w3.org/2001/sw/wiki/LLD_Use_Cases_Chinese_Shepherd