原文地址：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两个类别。
因此，创作者是一个独立的属性，能够从属于其他类别，但是不会和其他类别混为一谈。
老的“责任说明”就是它字面上的意思，是对题名页或者封面的描述性说明。它在图书馆使用的一直都很好，因此值得尊敬的纪念。