|
标题:
|
在HTML元元素中记录合格的Dublin Core™元数据 |
|
创造者：
|
|
|
创造者：
|
|
|
创造者：
|
|
|
发行日期:
|
2000-08-15 |
|
标识符:
|
|
|
取代：
|
|
|
取而代之的是:
|
|
|
最新版本:
|
|
|
文件的状态：
|
这是一个dcmi工作草案． |
| 描述文档: | Dublin Core™元数据元素集(DCMES)允许表达关于资源的大量描述性信息。但是，在某些应用程序中，需要细化DCMES元数据的含义。改进DCMES的方法包含在一个称为Qualified Dublin Core™元数据的扩展模型中，该模型需要额外的标签和数据，通常称为限定符。在本建议中，我们描述了HTML直接提供的方法，并解释了如何使用文档中的元素在HTML中记录Qualified DCMES元数据。 |
|
|
|
Dublin Core™元数据元素集(DCMES) [DCMES]允许表达关于资源的大量描述性信息。但是，在某些应用程序中，需要细化DCMES元数据的含义。改进DCMES的方法包含在一个称为Qualified Dublin Core™元数据[qDC]的扩展模型中，该模型需要额外的标签和数据，一般称为限定符．
可以用多种方式记录DCMES元数据。这些包括(但不限于)表、数据库系统和XML [DCMES-XML]和HTML [DCMES-HTML]中的序列化。虽然很流行，但HTML在语法上是有限的，特别是在记录更复杂的信息模型时。然而，通过使用合适的约定，合格直流模型的大部分需求都可以被覆盖。在本建议中，我们描述了HTML直接提供的方法，并解释了如何记录合格的HTML中的DCMES元数据元素< >头．
两个元素，用于记录元数据:<链接>和．属性的值中必须包含所有数据属性这些元素。
一个HTML<链接>元素允许与其他文档的关系进行记录。HTML规范[HTML]定义属性<链接>其中以下内容对我们有用的元素：
href % URI;(CDATA)标识相关资源的链接类型;(CDATA)类型的链接从这个文档转发到相关资源rev %链接类型;(CDATA)类型的链接，从该文档返回到相关资源
通常只有一个rel和牧师将适用于单个链接。我们使用<链接>来指示文档中其他地方使用的术语的模式或定义的位置，然后应用类似于XML名称空间[XMLnames]的简写符号。的href属性记录模式的位置，以及rel属性表示链接是架构，并建立一个前缀，该前缀可以与文档中其他地方的术语一起使用，如下例所示：
将前缀连接起来直流到了位于的模式http://purl.org/dc/elements/1.1/．
HTML规范[HTML]描述了使用该方法的另一种方法，使用该方法配置文件的属性元素。该方法有效地为所使用的术语生成默认名称空间，而不需要前缀。而配置文件方法可能在许多实例中使用，在混合来自多个模式的术语时必须小心—请参阅哪个模式?
超文本标记语言元素允许记录一个简单的元数据列表。HTML规范[HTML]定义属性其中以下内容对我们有用的元素：
| 的名字 | 的名字 | 元数据元素标签 |
| 内容 | cdata. | 元数据的值 |
| 模式 | cdata. | 表示用于该值的编码方案 |
| 郎 | % Languagecode | 表示自然语言 |
| dir | LTR |RTL. | 表示值的文本方向 |
中记录了DCMES元素的名称和值的名字和内容属性[DCMES-HTML]，其模式如下:
< meta name = "。元素" content="Value">
在哪里元素是15个DCMES元素之一价值是此元素的价值对于感兴趣的资源。元素名称的前缀“直流。“指的是一个模式<链接>如上所述的同一文件中的元素。
为了清楚地记录DC [qDC]认证所用的文字和标签，需要在批注中附加位置。对于合格的直流电机，我们使用不同位置的限定符来对应不同类别的限定。
HTML中不直接支持元素细分元素。
为了优化元素的含义，可以将元素细化附加到由点（。）分隔的DCMES元素名称，并将其存储为的名字属性:
< meta name = " DC.Element。ER”内容= "价值" >
其中ER是元素细化。
这遵循了许多现有的实践[DCMES-HTML]。
在HTML中直接支持值编码方案元素，使用属性计划和郎．
郎在值为纯文本的情况下使用，并且计划否则:
< meta name = "。元素" scheme="listB" content="Value selected from listB">
< meta name = "。元素" lang="langC" content="Value expressed in language langC">
地点:
如果一个计划要么郎，则内容必须根据该方案进行编码，包括使用任何结构和标点符号。
在HTML中表达限定DC元素的完整语法可以总结如下:
<链接rel =“schema.dc”href =“/ qdcmes / 1.0 /”标题=“dcmes plus dcmi推荐的限定符”>
其中电码为:
在DC元数据的实际情况下，每个这些码字被QDC注册表中定义的令牌或字符串替换，指示符合符合性限定符（参见下面的示例）。
XHTML是使用XML [XML]重新定义的HTML。XHTML建议[XHTML]描述了使文档成为有效XHTML所必需的许多更改。其中两个问题与我们有关:
合格的DCMES元数据[qDC]可以使用元素的定义如下:
< link rel = "模式。直流”href = " / qdcmes / 1.0 /”标题="DCMES plus DCMI recommended qualifiers" />
"/"之前的空格对XHTML来说并不是必须的，但是推荐使用，因为它允许大多数HTML客户端正确地处理XHTML文档，从而允许在两种情况下使用单个XHTML文档。
客户端系统可能无法处理QDC Metada以若干原因呈现给它，特别是：
在这种情况下，有必要考虑信息如何降级为更简单的形式。
对于根据这里描述的方法在HTML中记录的qDC元数据，可以应用一个简单的规则:丢弃任何不能理解的限定符。
为编码方案结果很简单。而完整的编码值的含义要求客户端理解符号，客户端系统仍然可以处理在内容而忽略了计划要么郎属性。任何基于字符串的表示法都不会给现有软件带来不便。
而且，资源甚至可能不需要解析值发现．大多数搜索操作中使用的字符串匹配方法仍然应该从扩展值中找到目标文本字符串。系统将获取文本值到索引中，而不管标记法如何，资源仍然可能由那些通常具有专门标记法知识、独立于索引软件的用户定位，从而能够构建合理且成功的查询。
为优雅的元素不合格的(“哑”)版本是通过删除部分的名字紧跟在DCMES元素名称之后。这就要求客户端软件更加复杂。然而，由于分层的点(.)符号在标记的前面包含DCMES元素名，哑元素应该总是清晰的。
它是传统的，但不是强制性的，用于使用字符串的前缀“直流”记录DC元数据时，尽管可以替换任何其他字符串。可能尤其需要不同的前缀，以便指代修改或扩展DCMES的本地架构，以及在同一文档中使用多种模式。例如：
< link rel = "模式。直流”href="http://purl.org/dc/elements/1.1/" title="The Dublin Core™ metadata Element Set">
这里我们使用了可选的标题属性以记录其他注释）。
当使用限定符时，也应该在链接到元素实例上使用的前缀的模式中定义限定符。
HTML的一个重要限制是没有显式的、递归的分组机制元素。这意味着在HTML中记录完全结构化的元数据元素是不可能的。
不过，有两种方法可以列出DC元数据元素的重复值，这在特定情况下可能很重要:
元数据提供者可以使用这两种不同的分组方法来表示需要分组的值(例如，在Coverage元素中标识单个位置的信息)和不同的值(例如，与单个资源相关的几个不同位置的标识符)之间的结构区别。
这里描述的语法包含表示合格的DC模型所需的组件，同时剩余完全符合HTML [HTML]。它提供了一种与HTML工具兼容的录制方法，如浏览器和元数据收割机。
虽然充分利用合格信息的工具可能还没有广泛使用，但元数据提供程序可能使用这里描述的语法来记录丰富的信息。自qDC语义模型的要求是被这里描述的符号,用户可能会相信,软件可以用来提取合格的元数据迁移到其他符号保存完整的语义,所以以这种方式投资获取丰富的信息不会被浪费。
DCMI [qDC]已经发布了一组通用的限定符，以鼓励互操作性并说明示范实践。还可以开发其他限定符以供当地情况或特定社区使用。只要它们遵循qDC模型的指导方针，就可以使用与DCMI批准的限定符相同的机制来记录它们。
下面的例子将出现在元素。
< link rel = "模式。直流”
href = " / qdcmes / 1.0 /”
title="DCMES + DCMI推荐限定符
< meta name = "。语言”计划= "定义“内容= " en-AU " >
< meta name = " DC.Date。创建”计划= " W3CDTF”内容= " 1999-04-21 " >
< meta name = " DC.Date。修改”计划= " W3CDTF”内容= " 1999-04-28 " >
< meta name = " DC.Relation。需要”=“URI”内容= " http://www.foo.bar/stylesheet.css " >
< meta name = " DC.Relation。isFormatOf”=“URI”内容= " http://www.foo.bar/explanation.doc " >
< meta name = " DC.Relation。hasFormat”=“URI”内容= " http://www.foo.bar/explanation.pdf " >
< meta name = " DC.Format。媒介”计划= " IMT”内容= " text / html " >
< meta name = " DC.Format。媒介”计划= " IMT”内容= "图像/ gifl " >
下面的扩展示例使用了这里讨论的所有限定和结构化组件，并使用了两个不同的模式:
< link rel = "模式。直流”href = " / qdcmes / 1.0 /”title="DCMES + DCMI推荐限定符< link rel = "模式。>
(dcm)
DCMI 1999Dublin Core™元数据元素集，版本1.1:参考描述http://purl.org/dc/elements/1.1/
(DCMES-HTML)
j . Kunze 1999用HTML编码Dublin Core™元数据http://www.ietf.org/rfc/rfc2731.txt
[DCMES-XML]
D. Beckett, E. Miller, D. Brickley, 2000。在XML中使用Dublin Core™//www.voudr.com/specifications/dublin-core/dcmes-xml/
(DCMI)
Dublin Core™Metadata Initiative, OCLC, Dublin Ohio。//www.voudr.com/
[html]
大卫·拉格特，阿诺德·勒·霍斯，伊恩·雅各布斯，1999年，HTML 4.01规范http://www.w3.org/TR/html40/
[QDC]
DCMI 2000。都柏林核心™限定符．//www.voudr.com/specifications/dublin-core/dcmes-qualifiers/
(XHTML)
史蒂文·彭伯顿和其他许多人，2000年可扩展的超文本标记语言http://www.w3.org/TR/xhtml1
(XML)
W3C 1998，可扩展标记语言http://www.w3.org/XML/
(XMLnames)
W3C于1999年XML名称空间http://www.w3.org/tr/rec-xml-names.