数据模型工作草案

创作者：	米克狼
发行日期:	1998-10-07
最新版本：	//www.voudr.com/specifications/dublin-core/datamodel/
发布历史:	//www.voudr.com/specifications/dublin-core/datamodel/release_history/
描述:	DC-RDF数据模型的概述。

1.一般

1．1
直流社区将从合理的其他社区中“借用或窃取”。这尤其适用于术语，模式，词汇表等。

2.数据模型

2.1
RDF数据模型是DC数据模型的基础。

2.2
我们将使用术语“结构节点”来表示RDF图中在现实世界中不独立存在的资源。

3.DC元素

3.1
在RDF中，我们只使用DC元素名作为表示实际资源的节点的属性名。换句话说，在最外层，除了15个DC元素名之外，我们不使用任何属性名。

3.2
在RDF中，除了作为应用于实际资源的属性名称外，我们不使用这15个DC元素名称。换句话说，在内部级别，我们不使用15个DC元素名称来命名属性。

3.3
以下每个属性的值可以是字符串或URI。URI可以是RDF节点的URI，也可以是为了获取值而需要解析的URI。

dc:贡献者
dc:创造者
dc:日期
DC：描述
dc:格式
dc:语言
dc:出版商
dc:关系
dc:权利
DC：主题
dc:名称
DC：类型

3.4
dc:标识符的语义目的由资源自己的URI来满足。如果使用了显式的dc:标识符，则其值可以是字符串或URI。URI可以是RDF节点的URI，也可以是为了获取值而需要解析的URI。

4.代理人

4．1
关于贡献者/创造者/出版者的问题，我们建议:

我们确实改变了一些描述性的名称(例如“其他贡献者”)，
我们确实改变了一些元素定义，
我们此时不添加或删除任何元素，
我们不改变任何元素标签(例如“Contributor”)，
我们不添加任何标签别名。

4．2
我们建议使用以下方式描述代理人：

使用字符串来保存代理的名称，
使用来自其他适当的命名空间（例如vcard或lcnaf）使用此类rdf的在线RDF已由拥有特定标准（例如vCard或LCNAF）的组织来制定此类RDF，
使用URI指向远程名称文件（使用vcard或lcnaf等）。

４．３
我们将“个人vs公司”问题引用到子元素WG，并询问他们是否需要由外部名称当局处理不需要对此区分的支持。

5.命名空间

5．1
我们将有两个DC命名空间：一个用于15个要素，一个用于资格认证。在文档中，我们将使用缩写“DC”和“DCQ”。

5.2
“简单”DC代理必须了解“简单”Dublin Core™命名空间（通常缩写为“DC”）和RDF M＆S命名空间（此处显示为“RDF”）。了解“RDF”命名空间包括了解如何通过遵循“RDF：Value”链来从合格的DC构造中提取不合格的DC值。

5．3
对于RFC 2413中定义的15个DC元素，我们将使用的命名空间是:

http://purl.org/dc/elements/1.0/

我们注意到:

purl.org/dc.

可能会在未来变化。

相应的推荐缩写是“DC”。

5．4
对于DC限定符（例如关系型），我们将使用的命名空间是：

http://purl.org/dc/qualifiers/1.0/

相应的推荐缩写是“DCQ”。

5．5
将由DC限定符（例如关系型）使用的一些术语（例如是isBasedon）将由DC社区定义。这些将被分组为逻辑相关的术语（例如，关系类型集）。我们将为每个这样的逻辑相关的术语定义一个命名空间（例如，对于该组关系类型）。

6.限定符

6.1
两个类别的限定符广泛有用,我们称为A和B类型和角色类别的例子和计划类别B的语义类别限定符来完善资源之间的关系的意义和价值,而B类限定符表述价值本身。我们使用合成节点的属性来表示这两类中的限定符。单个这样的合成节点可以同时具有类别A限定符和类别B限定符。使用这些类别的模板如下所示:

不合格:

[R1] --- DC：Foo ---------------------价值

合格:

(R1)——直流:Foo ---------------------->[ SN1]
[SN1]——rdf:价值 -------------------> 的值
[SN1]——dcq: a-category-A-qualifier——>…
[SN1] - DCQ：A-Category-B-Pretifier - > ...

除了用于限定DC元素的情况下，该模板可用于限定其他关系。

6.2
我们不应在类型等的名称中包含点(或任何其他标点符号)。

6.3
DC规范将定义一些DCQ限定符(如DCQ:TitleType)的值列表，但不是所有这些限定符的值列表。对于我们将为其定义值列表的一些限定符，它将向其他社区开放，以定义额外的值。对于那些我们没有定义值列表的限定符，所有可能的值将由其他团体定义。

6.4
参考上一点，在DC规范中定义的值将是uri(例如http:/purl.org/.../dublin.../...Alternative)。我们并没有将这种限制强加于别人所定义的价值观上。也就是说，通常情况下，dcq:XxxxType和dcq:Scheme等的值可以是一个字符串或URI。

6.5
rdf的值:可以通过dcq:Scheme进行限定。

6.6
我们定义了以下类型:

DC：标题可以通过DCQ：TIGLETTYPE限定。
DC：日期可以通过DCQ：DateType限定。
DC：关系可以通过DCQ：关系型来限定。
dc:创建者，dc:贡献者和dc:发布者可以通过dcq:AgentType进行限定，表示代理在资源中扮演的角色。

后续可能会添加其他类型。

7.重复

7.1.
可以使用简单重复或三个RDF M＆S收集构造（BAG，SEQ和ALT）中的任何一个来表达DC PropertyType的多个实例。DC DM WG寻求关于DC实现者的对该决定的反馈。

7.2
如果要订购DC PropertyType的多个实例，则应使用适当的RDF M＆S Collection构造（SEQ或ALT）。

7.3
上述决策也适用于键入A和B型限定符（虽然我们在这种情况下我们看不到Alt的良好用途）。DC DM WG寻求关于DC实现者的对该决定的反馈。

7.4
对于重复和订购值，我们建议使用单个RDF：值弧指向三个RDF收集构造中的相应之一（ALT，SEQ，BAG）。在某些情况下，它可能是合适的，而是重复整个DC元素，附加值。其中有多种语言提供的值，并且没有默认语言，我们建议使用袋子;如果有默认语言，我们建议使用ALT。DC DM WG旨在从DC实现者提供反馈，特别是在多语种DC上工作的反馈。

8.多语言字符串

8.1
DC社区需要处理多语言字符串的能力，将每个子字符串与其语言关联起来。对整个字符串的语言限定只是这一要求的一个退化情况。因此，堪培拉语言限定符(应用于整个字符串)的功能由XML的XML:lang属性来满足。

8.2
DC DM WG询问W3C的XML，I18N和HTML WGS为XML文档中的多语言字符串提供一般机制。

8.3
DC DM WG向W3C RDF M＆S WG询问，一旦指定，就会支持上述机制。