| 创造者: | 安的应用 MIMAS，英国曼彻斯特大学 |
| 发布日期： | 2005-06-13 |
| 最新版本: | //www.voudr.com/specifications/dublin-core/dc-citation-guidelines/ |
| 发布历史： | //www.voudr.com/specifications/dublin-core/dc-citation-guidelines/release_history/ |
| 描述: | 本文档提供了在都柏林核心描述中捕获书目引用信息的指南。它专注于期刊文章的书目引用，但也考虑其他类型的文章。它主要处理一个资源在它自己的元数据中的书目引用，但也指出了一些指导方针来描述对其他资源的引用。还讨论了使用Dublin Core元数据描述书目资源时出现的其他一些问题。 |
本文档提供了在都柏林核心数据库中获取书目引用信息的指南™ 描述它主要侧重于：
除了需要描述用于发现和检索记录后供人类阅读的书目引文信息外，一些应用程序还需要将这些信息编码为适合机器阅读的格式。这些指导方针建议使用来自OpenURL框架标准(Z39.88-2004)[1]的描述，而不是发明一种替代的DCMI语法。
许多实现都需要一种方法来描述期刊文章，并且由于缺乏任何指导方针，他们发明了许多特别的解决方案，这些方案在本地解决了问题，但却阻碍了互操作性。这些指南提供了在Dublin Core™描述中编码书目引文信息的推荐和可互操作的方法。
当打算使用Dublin Core™元数据来描述用于资源发现或简单、可互操作的资源描述的书目项目时，预计这些指南将非常有用。这些指导方针的目的不是为更复杂的元数据描述需求提供解决方案，它们也不寻求替换更适合这种情况的元数据方案。对于在XML中描述书目项的更详细的方法，建议使用替代方案，例如PRISM[2]、MODS[3]或NLM Data[4]，可能更合适。
本文档不提供Dublin Core™中书目引用信息的XML编码的详细指南。XML编码的指导方针将在未来的单独文档中发布。
在下面的各种数据表中，对简单字符串（称为“值字符串”）和应解释为URI（称为“值URI”）的属性值进行了区分。在适当的情况下，为值字符串指定词汇编码方案。
在本文档中，Dublin Core™名称空间使用以下缩写:
| 缩写 | 名称空间 |
|---|---|
| dc: | http://purl.org/dc/elements/1.1/ |
| 使用dc: | http://purl.org/dc/terms/ |
这些指南是DCMI引文工作组几年来讨论的结果[5]。它们取代并反对集团先前提出的任何建议，但DCMI使用委员会认可的建议除外。在引入都柏林核心之前™ “书目引文”一词不太清楚如何用都柏林核心期刊完整地描述一篇期刊文章™ 元数据。没有合适的都柏林核心™ 属性捕获期刊标题，与文章标题或卷、问题和页面详细信息不同，而不是作为一般说明的一部分。提出了各种建议的解决方案，最吸引人的是将期刊和发行信息描述为“isPartOf”关系，但这不包括页面细节，这些细节与文章本身有关。
建议1。使用dcterms:书目引文捕获资源的书目引文信息。
在资源自身元数据中描述资源的书目引用信息的推荐属性是使用dc: bibliographicCitation．这是dc:identifier的元素细化，在'dcterms'命名空间中定义。此属性的值将保存包含资源的书目项的详细信息以及资源在其中的位置。因此，对于一篇期刊文章，它可以捕获期刊标题、卷和发行编号、页码和出版日期，或者对于一本书的章节，它可以捕获书的详细信息和页码。资源的其他细节，比如它的标题和创建者，将使用通常的Dublin Core™属性进行描述。这些细节也可能包含在引用中，这是可选的，但是多余的。期刊的ISSN或书籍的ISBN可以被捕获为dcterms:isPartOf关系属性中的值URI。示例1和2显示了期刊文章和会议论文的Dublin Core™元数据描述。它们以表格形式给出，而不是任何特定的语法，但适合在任何推荐的Dublin Core™语法中使用。
例1。Dublin Core™期刊文章描述
| 所有物 | URI编码方案 | 值字符串 | URI值 |
|---|---|---|---|
| dc:名称 | 使用日志文件研究电子期刊用户行为 | ||
| dc:创建者 | 余，L | ||
| dc:创建者 | 应用程序, | ||
| dc:主题 | http://purl.org/dc/terms/DDC | 020 | |
| dc:主题 | http://purl.org/dc/terms/LCC | Z671 | |
| dc:出版商 | 爱思唯尔 | ||
| dc:类型 | http://purl.org/dc/terms/DCMIType | 文本 | |
| 使用dc:发布 | http://purl.org/dc/terms/W3CDTF | 2000 | |
| 使用dc: isPartOf | 瓮号：ISSN:0740-8188 | ||
| 使用dc: bibliographicCitation | 图书馆和信息科学研究22（3），311-338。(2000) |
例2。都柏林核心™会议论文描述
| 所有物 | URI编码方案 | 值字符串 | URI值 |
|---|---|---|---|
| dc:名称 | 为研究人员和学习者提供跨领域资源 | ||
| dc:创建者 | 应用程序, | ||
| dc:创建者 | 麦金太尔，R | ||
| dc:主题 | 都柏林核心 | ||
| dc:主题 | 元数据 | ||
| dc:主题 | e社区 | ||
| dc:出版商 | 佛罗伦萨大学出版社 | ||
| dc:类型 | http://purl.org/dc/terms/DCMIType | 文本 | |
| 使用dc:发布 | http://purl.org/dc/terms/W3CDTF | 2002 | |
| 使用dc: isPartOf | urn: ISBN: 8884530431 | ||
| 使用dc: bibliographicCitation | 都柏林核心™国际会议记录和电子社区元数据，2002;DC-2002:电子社区的元数据:支持多样性和融合，意大利佛罗伦萨，2002年10月13-17日，第71-80页 |
建议2。总是提供纯文本引用
对于一般资源发现和人类可读性，bibliographicCitation属性的值应该以明文形式给出。即使提供了机器可解析的引文，也建议将该引文作为相应的纯文本引文重复。
纯文本的引用也许根据一个公认的引文风格。DCMI引文工作组审查了几种风格，并在引文风格[6]页面上列出，但对于选择风格没有特别的建议。如果样式具有URI，则可以将其指示为编码模式。否则，没有DCMI认可的编码方案来表示引用风格。
推荐3。正文书目引用应该包含足够的详细信息以识别资源。
正文书目引用应该包含足够的细节，通过引用来识别资源。dcterms:bibliographicCitation是一个元素细化的dc:identifier，认识到一个书目资源是有效地识别其引文信息。因此，对于一篇期刊文章，dcterms:bibliographicCitation属性的值至少应该包含:期刊标题(或期刊的其他标识符);适当的卷号和发行号或零件号;开始页码，或在期刊期刊内的一些其他标识的电子纯文章。提供完整的分页信息也可能是明智的，即包括最后的页码;以及发布日期，即使这可能重复单独的dcterms:已发布属性的价值。示例3中有一些纯文本引用示例。
例3。示例文本引用
推荐4。对于机器可读的引用，使用OpenURL ContextObject。
鼓励提供机器可解析引用以促进数字互操作性。
“上下文敏感服务的OpenURL框架”是ANSI/NISO标准，Z39.88-2004。它提供了一种方法来描述被引用的资源，并将其与组成引用上下文的相关资源绑定在一起。这个包叫做“ContextObject”。该标准还定义了“OpenURL”，这是在网络系统之间传输这些描述的方法。ContextObject是OpenURL的“有效负载”，但也可能是一个自治的数据对象，因此是Dublin Core™属性的值。OpenURL框架标准的更多细节见附录A。
目前，OpenURL框架在其初始注册表中定义元数据格式[7]，因此作为标准的一部分，用于：期刊和期刊的一部分；书籍和部分书籍，包括会议记录和论文、报告和简单文件；论文；和专利。将来可能会定义更多的元数据格式。
这些元数据格式可用Key/Encoded-Value (KEV)和XML格式。XML格式的使用将在以后的文档中描述。但是对于除XML应用程序之外的许多用途，KEV格式将是最合适的。KEV格式是由“&”分隔的对组成的字符串，每对由一个标签或键和一个关联的值组成，由一个“等号”分隔。该值为'URL-encoded'，这意味着特殊字符会被转换成等价的十六进制字节串，以防止它们在HTTP传输时被误读(例如:'/'变成'%2F'， ':'变成'%3A')。
例4和例6显示了例1和例2中相同期刊文章和会议论文的书目引用信息的关键字和值。示例5和7显示了相同示例的完整url编码的ContextObject，在XHTML中编码的bibliographicCitation属性中。示例5还将日志ISSN作为dcterms:isPartOf属性的值URI。这些例子包括描述资源最常用的ContextObject键，即OpenURL框架术语中的“referent”。完整的元数据格式在OpenURL Registry[7]中定义，这些示例使用日志元数据格式[8]和图书元数据格式[9]。在KEV实现指南[10]中有更多的例子。ContextObject还可以包含进一步的细节，如文章标题和作者，但这些在Dublin Core™描述中是多余的。注意，由于推荐3的原因，ContextObject中应该有足够的信息来标识资源。
可选地，ContextObject可以包括“referer”，即ContextObject的发起人，从而指示其来源。在这些例子中，推荐人是Zetoc当前意识和文件交付服务。引用者被标识为“info:sid/”方案中的URI，使用服务的DNS名称，后跟数据库名称（可选），例如info:sid/mimas.ac.uk:zetoc。
这里用来描述引文的KEV ContextObject由URI 'info:ofi/fmt: KEV:mtx:ctx'标识。在XHTML示例中，为了与XHTML中表达Dublin Core™的指导原则保持一致，它被引用为一个名为“kev”的模式的一个元素“ctx”。所需的声明显示在示例5的开头。
在Dublin Core™摘要模型[11]术语中，dcterms:bibliographicCitation属性的值是一个值字符串，根据KEV ContextObject编码方案进行编码。它并不是资源标识符，对于期刊文章来说，它可能使用适当的URI模式，比如DOI
例4。用于期刊文章的ContextObject键和值
| 关键 | 价值 | 描述 |
|---|---|---|
| ctx_ver | z39.88 - 2004 | ContextObject规范的版本 |
| rft_val_fmt | 信息:ofi / fmt:凯文:mtx:杂志 | Referent使用KEV期刊元数据格式进行描述 |
| rft.jtitle | 图书情报科学研究 | 参照杂志的标题 |
| rft.stitle | LISR | 参考期刊的缩写标题 |
| rft.volume | 22 | 指示物的数量 |
| rft.issue | 3. | 参照问题数量 |
| 斯帕奇 | 311 | 参照起始页 |
| rfr_id | 信息:sid / mimas.ac.uk: zetoc | 推荐人标识符 |
例5。都柏林核心书目引文™ 期刊文章的属性
< link rel = "模式。DCTERMS" href="http://purl.org/dc/terms/" />
[注意：“内容”中的换行符仅用于表示。ContextObject应为一条完整的行。]
例6。ContextObject会议论文的键和值
| 关键 | 价值 | 描述 |
|---|---|---|
| ctx_ver | z39.88 - 2004 | ContextObject规范的版本 |
| rft_val_fmt | 信息：ofi/fmt:kev:mtx:book | Referent使用KEV书元数据格式进行描述 |
| rft.btitle | 都柏林核心™国际会议记录和电子社区元数据，2002;DC-2002:电子社区的元数据:支持多样性和收敛，2002年10月13-17日，意大利佛罗伦萨 | 参考诉讼程序(书)标题 |
| 斯帕奇 | 71 | 参照起始页 |
| rft.isbn | 8884530431 | 参考ISBN |
| rfr_id | 信息:sid / mimas.ac.uk: zetoc | 推荐人标识符 |
例7。会议论文的书目引用Dublin Core™属性
< link rel = "模式。DCTERMS" href="http://purl.org/dc/terms/" />
[注意：“内容”中的换行符仅用于表示。ContextObject应为一条完整的行。]
建议5。使用dcterms:引用来从资源中获取引用的引用信息。
所述资源引用的另一个资源的书目详细信息可以捕获为dcterms:references属性的值，该属性是dc:relation的元素细化。上述建议3和4编码dcterms的价值：书目引文也适用于dcterms的价值：参考文献。但是，可能会包括更多的细节，如引用资源的标题和作者（如果可用），反映引用资源中引用的文本。示例8以表格形式显示了包含两个引用的期刊文章的元数据。示例9和10分别显示了对以XHTML编码的期刊文章的单个引用，第一个引用是纯文本引用，第二个引用是编码为OpenURL ContextObject的值字符串。
与资源本身的书目细节不同，参考文献应作为要么供人类阅读的纯文本引用或一个用于机器阅读的OpenURL ContextObject。不适合提供重复引用，因为没有办法将单个引用的两个不同编码的实例关联起来。
示例8。一篇有参考文献的期刊文章。
注意，OpenURL ContextObjects不是url编码的，为了清晰起见，它包含了换行符。
| 所有物 | 语法编码方案URI | 值字符串 | URI值 |
|---|---|---|---|
| dc:名称 | zetoc中的数字图书馆原型技术 | ||
| dc:创建者 | 应用程序, | ||
| dc:创建者 | 麦金太尔，R | ||
| dc:出版商 | 斯普林格出版社 | ||
| 使用dc:发布 | http://purl.org/dc/terms/W3CDTF | 2002 | |
| 使用dc: isPartOf | urn: ISSN: 0302 - 9743 | ||
| 使用dc: bibliographicCitation | 计算机科学讲义2458,309-323 (2002) | ||
| 使用dc: bibliographicCitation | 信息:ofi / fmt:凯文:mtx: ctx | &ctx_ver=Z39.88-2004 &rft_val_fmt = info: ofi / fmt:凯文:mtx:杂志 &rft.jtitle=计算机科学课堂讲稿 &请求量=2458 &rft.spage = 309 |
|
| 术语：引用 | 信息:ofi / fmt:凯文:mtx: ctx | &ctx_ver=Z39.88-2004 &rft_val_fmt = info: ofi / fmt:凯文:mtx:杂志 &rft.aulast =应用 &rft.auinit =一个 rft。title=zetoc:基于Dublin Core™的当前感知服务 rft。数字信息杂志 &rft.volume = 2 &rft.issue = 2 &请求日期=2002年 |
|
| 术语：引用 | 信息:ofi / fmt:凯文:mtx: ctx | &ctx_ver=Z39.88-2004 &rft_val_fmt = info: ofi / fmt:凯文:mtx:杂志 &rft.aulast=卡纳尔 &rft.auinit = D rft。标题=本周网站:电子邮件提醒服务 rft。jtitle =英国医学杂志 &rft.volume = 324 &rft.spage=56 &请求日期=2002年 |
示例9。引用期刊文章作为XHTML编码的纯文本引用
< meta name = "使用dc。Apps, A.， MacIntyre, R. zetoc:基于Dublin Core™的当前感知服务。数字信息学报(2)(2002)"/>
例10。以XHTML编码的OpenURL ContextObject形式引用期刊文章
< link rel = "模式。DCTERMS" href="http://purl.org/dc/terms/" />
[注意：“内容”中的换行符仅用于表示。ContextObject应为一条完整的行。]
在简单的Dublin Core™中没有提供书目引用的建议。Simple Dublin Core™不包括编码方案或控制词汇表的概念来约束属性的值，所有值都被认为是纯文本值字符串。这排除了在简单的Dublin Core中提供机器可读的细节，除非按照本地约定。建议在一个简单的Dublin Core™描述中，书目引文信息应包含在以下其中之一:
一个KEV OpenURL ContextObject可以作为一个简单的Dublin Core™dc:identifier属性的值，与一个平行的纯文本引用一起包含，如示例11所示，以提供某种可能性，但不能保证机器理解。当在XHTML编码中使用时，如DCMI抽象模型文档附录D所示，DC的值。标识符是一个值字符串，即使对人类读者来说它看起来像一个URI或URI的一部分。
例11。一篇期刊文章的简单Dublin Core™书目引用
< meta name = "。/>
[注意：“内容”中的换行符仅用于表示。ContextObject应为一条完整的行。]
由简单的Dublin Core™描述的资源引用的另一个资源的引文信息可以被捕获为dc:relation属性的字符串值。同样，这可以使用作为值字符串提供的KEV ContextObject来捕获。
例12。简单都柏林核心™ 以XHTML编码的OpenURL ContextObject形式引用期刊文章
[注意：“内容”中的换行符仅用于表示。ContextObject应为一条完整的行。]
在未来的文档中将提供用XML编码书目引文信息的建议。
正如前面介绍中所建议的，对于需要复杂XML元数据描述的应用程序来说，其他专门为书目项目设计的元数据方案(如OpenURL框架[1]、PRISM[2]、MODS[3]或NLM Data[4])更合适。
与都柏林核心图书馆书目引文信息描述相关的其他几个问题™ 已经确定。
建议6。使用dc:contributor捕捉作者的从属关系。
对于书目资源，特别是期刊文章，作者的隶属关系是一个重要的信息项目，用于资源发现（例如“查找所有由曼彻斯特大学成员出版的关于镁的文章”）以及资源描述。期刊文章或会议论文的从属关系与资源相关。这是作者在创建资源时的从属关系，即使作者转移到其他机构，这种关系也将持续存在。因此，它是资源的财产，而不是作者的财产。建议将这种联系视为dc:contributor财产的价值，承认作者的机构将为资源的创建做出贡献。由于从属关系是资源的属性，而不是创建者的属性，因此无法将特定作者与其从属关系关联（当存在多个作者时）这一事实不是问题。
示例13。都柏林核心™会议论文描述，包括作者的从属关系
| 所有物 | 值字符串 | URI值 |
|---|---|---|
| dc:名称 | 为研究人员和学习者提供跨领域资源 | |
| dc:创建者 | 应用程序, | |
| dc:创建者 | 麦金太尔，R | |
| dc:贡献者 | 曼彻斯特大学咪咪斯 | |
| dc:出版商 | 佛罗伦萨大学出版社 | |
| 使用dc:发布 | 2002 | |
| 使用dc: isPartOf | urn: ISBN: 8884530431 | |
| 使用dc: bibliographicCitation | 都柏林核心™国际会议记录和电子社区元数据，2002;DC-2002:电子社区的元数据:支持多样性和融合，意大利佛罗伦萨，2002年10月13-17日，第71-80页 |
建议7。全局标识符应该被编码为uri。
有各种与书目资源相关的全局标识符，例如用于连载的ISSN、用于图书的ISBN、SICI(串行项目和贡献标识符)、数字对象标识符(DOI)。它们应该作为值uri编码在Dublin Core™属性的值中。表1列出了其中一些标识符。其中一些标识符使用新的'info' URI方案[12]。在引入这个方案之前，书目资源中没有这些标识符的通用URI名称空间。
表1。书目资源的标识符。
| 标识符 | URI命名空间 | 例子 |
|---|---|---|
| 石头 | urn: ISSN: | urn: ISSN: 0302 - 9743 |
| ISBN | urn: ISBN: | urn: ISBN: 8884530431 |
| NBN（国家书目编号） | urn: NBN公司禁止: | urn: NBN公司禁止:fi-fe19981001 |
| 数字对象标识符 | 信息：内政部/ | 信息:doi 10.1045 / / july99-caplan |
| SICI | 信息:sici / | 信息：sici/07408188（200010）22:3%3C311:SEUB%3E2.0.CO；2-X |
| PubMed | 信息:pmid / | 信息:pmid / 9036860 |
| 开放档案倡议 | 信息：oai/ | 信息:的oai / arXiv.org: hep-th / 9901001 |
上面给出的描述期刊文章书目引文信息的建议假设该文章发表在印刷期刊内，并通过其起始页在该期刊内识别。尽管大多数期刊文章现在都可以通过电子方式获得，但它们仍然被包装在一期杂志中，带有起始页的概念（事实上，它们仍然以印刷版和电子版的形式发布）。但越来越多的“天生的数字”电子期刊没有平行印刷版本，也不存在页码的概念。而且，一些迅速发展领域的期刊文章在被分配到期刊之前就已经发表了。因此，为了描述一篇纯电子期刊文章，需要在期刊内或独立期刊上对文章进行一些识别。此标识将取决于特定物品及其发布情况。对于按期出版的电子期刊中的文章，该期中的文章会有一些标识，如例14所示。通过标识符（如数字对象标识符（DOI））或通过指向可阅读文章的位置的URL来描述一些电子文章（如果可用）更合适。
例14。电子期刊文章的书目引文。
| 所有物 | 值字符串 | URI值 | 资源URI |
|---|---|---|---|
| dc:名称 | 在学术信息环境中使用OpenURL框架的开放链接 | ||
| dc:创建者 | 范德松佩尔，H | ||
| dc:创建者 | 阿,Beit-Arie | ||
| 使用dc:发布 | 2001 | ||
| dc：标识符 | 信息：doi/10.1045/march2001-vandsompel | ||
| 使用dc: isPartOf | 瓮号：ISSN:1082-9873 | ||
| 使用dc: bibliographicCitation | D-Lib杂志7(3)，2001-vandesompel |
可能需要指出一个书目项目的资源类型，例如期刊文章、会议论文。建议将dc:type属性与可识别词汇表中的术语一起使用作为其值。
15例。指示期刊文章的资源类型
< meta name = "。类型”计划= "使用dc。MESH" content="期刊文章[出版类型]" />
DCMICite Dublin Core™结构性价值已弃用。
在其生命周期中，DCMI引文工作组提出了都柏林核心™结构化值(dccsv)， DCMICite，以机器可解析和人类可读的形式捕获书目引文信息。该建议的版本在各种论文中发表，并在多个实现中使用，主要是因为没有其他建议可遵循。此建议现在已弃用，不应使用，除非在本地应用程序中。因为它没有得到DCMI使用委员会的认可，使用DCMICite不能保证未来的互操作性。该建议基于DCSV，这种语法也已被弃用。书目引用描述不再需要它，OpenURL框架元数据格式现在可以取代它。
“上下文敏感服务的OpenURL框架”是ANSI/NISO标准，Z39.88-2004[1]。它提供了一种方法来描述被引用的资源，并将其与组成引用上下文的相关资源绑定在一起。这个包叫做“ContextObject”。该标准还定义了“OpenURL”，这是在网络系统之间传输这些描述的方法。ContextObject是OpenURL的“有效负载”，但也可能是一个自治的数据对象。
通常，在数字图书馆环境中，用户会点击HTML页面中的OpenURL链接，例如在电子期刊文章参考列表中的引文旁边。引用的OpenURL将被传递给链接服务器或解析器，该服务器或解析器将向用户返回与引用的文章相关的资源选择，最好包括指向文章全文的适当副本的链接。
一个ContextObject最多可以包含六个实体。其中一个是'referent'，它保存了关于被引用资源的信息。它必须始终包含在ContextObject中。其他五个实体是:引用发生的资源(引用实体);用户(请求方);向其发送请求的服务(解析器);生成OpenURL的服务(referrer);以及所请求的服务类型。
在ContextObject中，关于每个实体的信息可以以四种方式详细说明。指定名称空间中的标识符将定义资源。以'by-value'或'by-reference'编码的一组元数据可以描述实体。不同之处在于，按值元数据描述包含在ContextObject中，而按引用元数据描述则保存在ContextObject中标识的其他URI中。第四种类型是未定义的私有数据，需要事先了解解析器和引用器之间的关系。
实体可以采用“键/编码值”（KEV）格式或XML进行编码。KEV是一个由“与”分隔的对组成的字符串，每对由一个标签或键以及一个关联值组成，由一个“等于”分隔。该值为“URL encoded”，这意味着特殊字符将被转换为其等效的十六进制字节字符串，以防止在通过HTTP传输时对其产生误解。
OpenURL框架非常通用，有潜力在许多应用程序领域和许多社区中使用。它的核心组件是在OpenURL Registry[7]中定义的。它包括标识符名称空间和元数据格式的列表。从Registry中选择适用于特定应用程序域的一致组件集是“Community Profile”，它也在Registry中定义。
有关OpenURL框架的更多详细信息和解释，请参见KEV实施指南[10]和标准[1]。