豆瓣启用“版本”功能

长久以来我一直觉得豆瓣虽然是一个非常好的2.0网站(当然最近或许也没那么好,在压制言论这个问题上),但是书目的功能上做得还蛮糟糕的,尤其是它没有区分所谓的FRBR的第一组实体。

刚刚收到豆瓣的系统消息,它开始启用作品版本这个概念了,当然现在还只限于图书:

亲爱的Nalsi:

图书版本功能已经上线。现在你能在某些图书的右侧看到它的其他版本,比如这本《朝花夕拾》右侧
http://www.douban.com/subject/1449352/

图书版本上线之后,同一作品的其他版本就不会重复出现在推荐里了。不同版本的图书还会有一个作品页面(
比如红楼梦
http://www.douban.com/book/works/1001757),方便书虫们比较各个版本的好坏。

我们知道你在读书方面有浓厚的兴趣,欢迎你帮助我们更新版本信息。如果你知道某些版本信息,可以去该本图书的“增改描述、封面图片”内的“添加其他版本”进行添加。在既有的作品页面,你也可以添加、报错或者删掉某些错误版本。

更多版本信息请访问 http://www.douban.com/help/subject#t5-q0

欢迎你为图书版本信息添砖加瓦。

目前主要的改动主要表现在:1、作品页的“其他版本”的提示(如上);2、在豆瓣主页不再推荐同一作品的不同版本;3、作品页面(如上)——但是目前只有多版本的作品才有这个页面

而且在搜索图书的时候,同一部作品的不同版本仍然会同时出现在搜索结果里。

作为我个人,当然很期待豆瓣有一天能完全实现FRBR化(我当然是说最狭义的FRBR化,也就是说,变成语义网络中的真正的“书目世界”),很期待。

关于FRBR中的作品集

William Denton报告了今年IFLA年会上和FRBR(我正在考虑我以后是不是要按照老外的读法来念这个词,虽然入乡随俗也不错)有关的内容。

今年Gordon Dunsire做的FRBR评论组的度报主要提到了两件事:申请FRBR的“名称空间”(namespace)作为后续开发利用的基础,以及VMFVocabulary Mapping Framework)对于FRBR的利用。

因为最近在写一篇该死的论文(似乎这篇文章我已经提到好多次了),所以一直在关注FRBR作品集工作组的动态。

根据William Denton的纪录去年的会议在三个原则之上确立了用来解释作品集的三种模型:整体部分模型(作品集是整体,单部作品是部分)、载体表现单个作品模型(作品集作为载体表现,包含了不同的作品)以及单个作品多个作品模型(作品集作为一个作品,包含了多个其他的单个作品)。然后第一个模型被否定了。

今年的会上提出了后两个模型的详细说明(载体表现多个内容表达模型以及作品多个模型),作者分别是ZumerTillett,比较模型之间差别很有趣。

我个人之前的想法是比较倾向于第一种模型的,也就是作品集是一个载体表现,其中包含了不同作品的内容表达,因为在第一组实体中,只有这两个实体之间的关系是“多对多”的。任何一个内容表达都只能实现一个作品,而且作品是不能归递(recursive)的——就是作品不能包含作品,虽然这件事我之前是没想过。

但是我读了Barbara Tillett对于第二种模型的解说,觉得这个说法在某些地方似乎也很有道理。虽然这个解释要把作品这个实体加上一个recursive的箭头(这个箭头在Tillett很多年前的ppt上就见到了),然后因为内容表达实现的是多部作品组成的一个作品,所以它也就是多部作品的实现,在我看来这也不符合FRBR的原意。但是FRBR5.3.1.1的原文确实是非常支持这种看法的:在作品内部存在整体/部分的关系。

当然相对来说,就像那个比较的表格的最后一栏所说,第一种模型无论如何是比较简单的,一方面不用创造出许多“作为作品集的作品”(因为显然作品集是一种比较重要的类型,根据估计,在Worldcat的数据库中,有多于一个内容表达的作品——也就是所谓的“复杂作品”——中有12%是作品集),另一方面也不用动用到整体/部分的关系来连接这些不同类型的作品。

Ps:作品集的聚合(aggregating)有三种情况:作品集(collection)、附加部分(augmentation)以及平行作品(parallel)。前两这可以大体等同于FRBR中所说的作品的“独立范畴”和“从属范畴”。根据FRBR评论组之前的决议(我不知道出处),在augmentation本身是看作主要作品的一个新的内容表达,而其所附加的部分要看作是一个独立作品(这个作品“没有必要单独识别”)的一个内容表达。第三个情况是比较少见而且还没有什么人关注过的一个问题。

【翻译】什么是(FRBR的)作品

原文链接:http://kcoyle.blogspot.com/2009/08/what-is-frbr-work.html
原文作者:Karen Coyle

译者:Nalsi

————

“什么是作品”,这是人们经常讨论的一个问题。人们的回答通常要么是“作品”在哲学上的意涵,要么是隐含在这个概念中的内在的抽象性。非此即彼。

我最近在Futurelib wiki上闲逛(虽然有点晚了,但我在这里收集了我对于Martha
Yee
的文章的所有评论),看到了Kristin
Antelman
两年前的一个
有趣的评论

我知道这个问题完全不是FRBR社区的争论所在,但是作品和内容表达这两个抽象实体的名称属性一直让我不高兴。它看上去和抽象实体的精神南辕北辙,更不要说它在实践层面上难以操作(比如说丛编)。同一部作品的不同载体表现当然会有很多题名。图书馆可能想要选择其中一个用来表示“作品”的题名或者用来显示。作品和内容表达只需要标识符的属性,用于表示作品、责任者和主题。

RDA定义了作品题名和载体表现题名(就是所谓的正题名)。我曾经听过一种看法,存在两种截然不同的数据元素:载体表现的题名是从实物上转录的,是载体表现的具体实现的一部分;作品题名(称之为“统一题名”)把同一个作品的所有内容表达以及载体表现聚合起来。Kristin的评论让我再一次想起这个问题,而且我同意她的看法,作品没有题名这种东西。统一题名是作品的标识符,因为我们现在还使用题名这类东西来标识事物。但是FRBRRDA意识到,实体将会使用另一种标识符,它和我们过去使用的名称和题名的显示形式截然不同。

这种“没有题名”的解决方式解决了创造作品显示过程中一个根深蒂固的问题,尤其是在多语种的目录下。如果你遵照统一题名的概念,作品题名应当是初始语种的题名。也就是说我们应当把Война и мир当作是作品的题名,可是绝大多数人都只知道《战争与和平》。我们能够显示英文的题名,可是如果目录的使用者用的不是英语怎么办呢?如果一些读者只能看懂法文、土耳其文或者中文该怎么办呢?如果作品有一个标识符(只对机器处理有用,不是用来显示给人看的),你就能够让使用者选择他们想要用什么语言来显示作品。(显然,这样的选择现在还做不到)

所以我喜欢不给作品分配题名的做法,但是我必须承认,我越来越多的把作品看作是一个集合,也就是作品的载体表现组成的集合,而不把它看作是一个事物。属于同一部作品(使用作品的标识符)的任何一个载体表现的每一种资源都是作品集合的一部分,正是这个集合定义了作品。

作品的集合是不固定的——新的资源可以随时加入这个集合。因此,作品是自下而上被定义的,它的定义来自于集合的内容。集合中的各个部分有各自题名和主题,也就是说,这个作品同样有这些题名和主题。

这个解决方法还是要我们决定用什么来表现作品。我们是否显示和作品有关的主题词?读者评论和内容摘录呢?如果我们想要显示封面,你怎样在那么多的封面里选择?

这样做的一个好处是你可以根据情况选择不同的显示方法。公共图书馆可以在作品显示中直接告诉读者馆藏位置,特藏可以显示出现有版本的重要信息,社交网站可以列出拥有这个作品不同版本的用户名单。作品的概念变得更加流动并且富有延展性,在我看来,比起一个只有几个属性的固定的“作品”来说,这样做和事实更加接近。

【翻译】FRBR和FRBR化

原文地址:http://managemetadata.org/blog/2009/07/18/frbr-vs-frbr-ization/
作者:Diane Hillmann

译者:Nalsi

————

在芝加哥举行的ALA年会一团乱——我做了三个主题发言(如果时间允许,我希望能谈论一下它们并且提供地址)。但是我参加了“MARC的未来”的特别小组,然后在星期五的第一个主题发言上说漏了嘴,这件事情就一直在我脑子里挥之不去。LC的Rebecca Guenther谈到了他们让MARC与时俱进的努力,OCLC的Ted Fons从“Big O”(感谢Karen Schneider发明了这个绝妙的名号!)的角度谈到了相似的话题。这两个发言的共同之处就是,他们想要用“FRBR化”的视角重组MARC数据,他们觉得这么做是让FRBR实现其价值的全部方式。我争辩到情况并非如此,而且我越思考这件事我就越相信:FRBR化和使用RDA中的FRBR模型不是一回事。

 

我的观点部分来自于,RDA和MARC的语义是截然不同的(不是句法,人们通常都会谈到句法)。RDA包含丰富的关系词汇表,能够在书目著录中使用,这是人们最为忽视的一件事。把RDA看作是文本的指南或者是一系列规则的绝大部分人都忽视了这一点,因为关系词汇表出现在附录中,但我们中的绝大多数人都不会把附录看作是随便哪本书中最重要的部分。但是想想吧:在RDA词汇表中,每一个关系都有一个标识符,每一个关系都是一个等级体系的一部分,这让我们能够在不同等级上表达书目的关系,而且能够让我们使用这些关系在书目之间进行导航,而不必深入数据,去解释我们在MARC数据中出于相同目的所使用的文字附注到底是什么意思。比如说,我们要说“资源X”是“资源Y”的一个缩略本(以及,“资源Y”有一个缩略版本“资源X”),使用RDA我们就能让系统清楚的把这句话表达给读者。任何人需要应用或者解释关系,关系都是独特的、经过标识的以及清楚界定的。

 

相反,FRBR化只能通过MARC到FRBR(或者RDA)的映射揭示出我们能够揭示的东西,最多也就是FRBR第一组实体之间的关系。相对于RDA表示的
关系,实际中的关系要多得多。你可以说这些关系并不是FRBR中必须的,但是如果我们把它们看作是作品、内容表达、载体表现、单件的“垂直关系”中的“水平关系”,我们就有可能用FRBR来思考我们的世界,我们其实是用得上这些关系的。

 

想到RDA的“测试”机构,这是让我头疼的一个问题。难道RDA非要塞到MARC里我们才会用它么?我们就不能学着把MARC看作是一种失真的输出格式,开
始使用其他的方式来表达关系,好让我们维护更广阔的数据世界中的一些更加重要的功能和可信度么?Jennifer Bowen和eXtensible Catalog的家伙们把MARC转换到RDA的时候发现(详细情况,请看我对于Jennifer的论文写的帖子),这么做较之于其他的方式,涉及到一些截然不同的问题。[顺便说,XC项目无所不在。加油,Jennifer!]

 

越来越多的零售商开始转向RDA模板,开始构建基于RDA的应用,而不是试图把MARC转换成一些会被误认作RDA的东西。我们要不得不接受,就像任何其他的元数据映射一样,天下没有免费的午餐,而且来了之后也就再也回不去了。

 

Registry已经注册了其中一些关系(看“RDA Roles”中FRBR第一组实体和第二组实体之间的关系,以及“RDA Relationships for Works, Expressions, Manifestations, Items”中RDA第一组实体之间的关系),但是我们要知道它们并不是最终的版本。我还没有得到最后修改的信息来进行这些更新,得到这些信息之后我会立刻宣布的。