南京参会记·报到日

坐T65软卧的上铺,5.25夜22:54离开北京,去火车站的路上出了一些状况,按下不表(路上被某小同学问到:你认为RDA足够支撑一篇硕士毕业论文的内容么?)。总之顺利到达火车站,看到Z同学已经上车。(我之前一直以为会有三个人)

一夜火车,心情莫名:没有往日旅行的激动,但有些说不清的东西。

第二天早9:17到达。下车根据Google Map的提示坐地铁,南京的地铁很赞,票也很有意思。(另外,南京也是有一座有着丰富硬币的城市)。然后坐到“新街口”站(北京的同学,你明白的)。费了一番周折(Google map上显示的一条路因为施工被堵上了……),找到目的地,汉府酒店。一路上对南京的市容赞叹不已:路边是高大的法国梧桐,道路不算宽,而且,很凉快。

办理入住,决定下午去钟山玩一下。然后和Z同学吃了很有名的某某粉(我吃的是炸酱凉面,很好吃)。然后本打算按照地图的提示,坐地铁,赫然发现,那条地铁线要到本月28号才开始运营,也就是说,我能赶上的!

说到钟山,不得不赞叹一下南京的地形之有趣。钟山号称“东郊风景区”,可是距离本人居住的酒店(这是绝对的市中心,在步行10分钟的距离内,有两座图书馆、至少一座大型购物中心、一家大型超市、若干家咖啡店,其中包括两家星巴克,以及一座总统府和一座“人民大会堂”)只有6站地之远,而且随着新开通的地铁,连接大学城-钟山-明故宫-市中心的联络线变得异常方便,这让我对南京这座城市有了巨大的好感。

于是坐车到钟山,进山。山里树木如荫,两边都是高大的什么什么树,很赞。这个风景区里有明孝陵、中山陵和灵谷寺若干个景区。景区虽大,可是有若干个公交路线贯穿于景区之间,所以实际上很方便。不过这三个景点对我来说都不算有趣,让本人有小小的失望。原因之一可能在于,灵谷寺并不像本人所想,是一座古庙……不过我仍然对另外几个地方有着比较大的希望,而且因为本人将全程待在这座城市(不太想走马观花的去参加“文化参观”:扬州和镇江),所以应该是有大把的时间探索这座城市,至少希望如此。

全程参观完毕已经是4点左右(没去明孝陵)。回来的路上,去超市采购生活用品(这似乎是本人到另外一座城市必然要做的一件事……)。然后回到宾馆,见到未来三天的室友,一位北图社的老师,被应允获赠一本精灵老师的新书,很得意。然后洗澡,晚上要见一位书社会上认识的老师。

第一天乏善可陈(今天听到的基本都是坏消息),期待明天的正式议程。

————

几个感想:

南京给我的感觉很好,甚至于不输上海。这是一座现代城市,很有文化,而且城市边上就是那么大的一片森林(它的绿化面积大概应该是北京的若干倍),很妙。

南京图书馆坐落在市中心,无比华丽,可是读者似乎并不算多。

————

参会记:开场

RDA学习笔记3:关于RDA需要记住的12件事

来源:RDA培训材料Module 9

 

1、用户需求/用户任务
2、接受你看到的一切(呈现原则)
3、作品——内容表达——载体表现——单件
4、核心元素以及“如果……则核心”(core if…)元素,可以增加其他的内容(#1)
5、交替规则(althernatives)、选择忽略(optional omissions)、选择附加(optional additions)(#1)
6、减少使用缩写(#1和#2)
7、关系、关系、关系(绝大多数是核心元素之间的关系)
8、内容、媒体和载体类型
9、废除“三”原则,转而依靠编目员的判断
10、信息源得到扩展
11、受控词汇表
12、识别特征,作为未来关联数据系统的组成部分
——受益于RDA元素、子元素和元素子类型的结构
p.s. RDA培训材料的翻译工作即将开始,感兴趣志愿参加的同学欢迎联系本人,本人的邮箱是:islanderee@gmail.com(文章瓜分完毕,感谢各位关注)

————

RDA学习笔记2:Tillett的ppt

RDA学习笔记1:资料

【翻译】AACR2的“责任说明”和DC的“创作者”

原文地址:http://metalogger.wordpress.com/2008/06/02/aacr2-statement-of-responsibility-vs-dc-creator/

作者:

译者:Nalsi

 

对于图书馆员而言,“责任说明”一直都运作良好,它同时是检索点和对于资源的描述。规范文档则能够在逻辑上解决名称变异的问题。

 

都柏林核心元素集(Dublin Core)的属性(property)“创作者”(creator),则没有这么容易管理,你使用仓储(repositories)不久之后就能发现这一点。作者的姓名和机构(affiliations)是有问题的:怎样处理多个机构以及定期改变机构的情况?怎样储存或者链接到作者的个人或者机构页面、博客和wiki、电子邮件地址、名称变异以及其他的联系信息?

 

如果你试图通过“责任说明”的方式进行思考,即便是仅仅试图在量上扩展AACR2的概念,都会在机构仓储(IR)的环境中失败。

 

因为IR的世界试图把创作者当做两个截然不同的概念来处理,它们绝不可能相同。

 

一方面是出版的文档上创作者的姓名。这里的姓名就是“责任说明”,它也是对于文档的描述。“这本书是A.B.写的。

 

但是另一方面,我们希望把创作者当成是坐在办公室电脑前的一个人,他有工作的历史,还在进行若干专业活动。在这种情况下,创作者就绝不可能是“责任说明”,除非是一些开玩笑的评论。

 

所以,这两个“创作者”概念之间的关系是怎样的呢?

 

前者是后者的表达(expression)。(但我并没有用这个词在FRBR模型里的意义)出现在文档题名页上的姓名是坐在办公室里的人的表达。那个人的每一本新书都会有一个新的题名页,来表达这个创作者。

 

有时候,这个创作者会使用一个不同形式的名称;有时候,他们在一个不同的机构;有时候,他们会成为许多作者中的主要作者或者联系人,也有可能是单独的作者或者次要的作者。

 

所以一个真实的创作者能够,而且实际上经常有多个创作者的表达。这种区分看起来就像是吹毛求疵的区分你不同部位毛发,因为我们的直觉能够告诉我们哪个是哪个,不可能搞混。但是计算机程序可没有直觉,所以对于计算机来说,吹毛求疵的区分是必要的,这让它们能够理解这些内容,为我们所用。


AACR2只关注创作者的表达,也就是它所谓的“责任说明”。它只想要管理纸质、声像或者一些电子资源,但并不想管理实际的作者。


如果AACR2可以被看作是为了二维的资源而设计的,那么我们现在可能要开始关注虚拟的三维馆藏资源,只要我们开始得到组织和财政上的支持。因为上面这句话可能暗示了,社区不仅仅需要重视“文档”或者“图像”或者“数据集”资源的检索点,它们还需要重视“创作者”的资源,哪怕只是创作者的数据库,或者检索点。

 

(机构和财政支持的需求需要和社区的支持结合起来,后者需要领导力和教育上的努力……但这就是另一个故事了)


尽管我并没有使用expression在FRBR中的意义,但是FRBR模型把dc的术语“创作者”分配给了作品实体,并且把“代理”(agent,个人姓名和细节)单独列为另一个实体,它就是通过这种方式来处理这个问题的。

 

DCMI术语和DC抽象模型从技术上更详细的解释了这个问题。

 

DCMI中的“创作者”是一个“属性”术语。它的定义是:“对创作资源负有主要责任的实体。”


Other property terms include “title”, “subject”, “type”, “publisher” and heaps more.

其他的属性术语还包括“题名”、“主题”、“类型”、“出版者”及其他。

 

除了“属性术语”,DCMI还使用“类别术语”。其中包括:Agent、BibliographicResouce和MediaType等等,但是数量没有属性术语多。

 

DC抽象模型(DCAM)表明,一个属性可以属于任意数量的不同类别。“创作者”的属性在逻辑上能够同时属于Agent和BibliographicResource两个类别。

 

因此,创作者是一个独立的属性,能够从属于其他类别,但是不会和其他类别混为一谈。

 

老的“责任说明”就是它字面上的意思,是对题名页或者封面的描述性说明。它在图书馆使用的一直都很好,因此值得尊敬的纪念。