| 创作者： | 都柏林核心集合说明任务组 |
| 发行日期： | 2004-08-06 |
| 最新版本： | //www.voudr.com/specifications/dublin-core/collection-description/collection-model/ |
| 发布历史： | //www.voudr.com. |
| 描述： | 本文档讨论了Dublin核心集合描述应用程序配置文件中使用的数据模型。 |
本文件总结了所描述的数据模型的子集集合的分析模型及其目录[1]，并提出添加新实体类型，服务。
具体实现内容。项目可能是物理或电子。
DC CD AP不提供项目的描述，所以不提供相应的类。
一个或多个项目的聚合。
集合的示例包括：
在DC CD AP中，此实体类型对应于类DCMITYPE：集合。
举办集合的地方。
位置的示例包括：
DC CD AP不提供所需的位置的描述，因此不提供相应的类。但是，DC CD AP应提供一个属性来描述收集和位置之间的关系（见下文）。
为最终用户或软件应用程序提供或向其感兴趣的一个或多个函数提供提供或系统。
服务的示例包括：
此实体类型对应于类DCMITYPE：服务。
在DC CD AP的上下文中，感兴趣的服务是提供对集合的访问的子类：
一个信息服务是提供对集合的访问权限（和/或集合中的项目的服务？）。
信息服务的示例包括：
DC CD AP不提供信息服务的描述，因此不提供相应的类。但是，DC CD AP应提供一个描述收集和信息服务之间关系的属性（见下文）。
一个代理人是能够采取行动的实体。
DC CD AP不提供代理的描述，因此不提供相应的类。但是，DC CD AP提供了描述集合和代理之间的“收集器”和“所有者”关系的属性（见下文）。
提供有关集合信息的资源。
这分析模型[1]识别Collection描述的四个子类：
一个集合描述，只包含有关整个集合的信息，并且不提供有关其内部各个项目的信息。
酉查找辅助设备包括“收集级”描述，例如使用RSLP CD模式创建的辅助程序和使用ISAD创建的“顶级”档案说明。
一种集合描述，包括有关整个集合的信息，以及有关它内部的各个项目及其内容的信息，包括关于项目与整个集合的内容的上下文信息。
档案发现辅助辅助工具，如多级ISAD（g）描述或EAD文件是分层发现辅助。
层次调查辅助方法本身是一个集合，并且可以通过单一的发现辅助来描述。
一个集合描述，包括有关它内部的各个项目及其内容的信息。
图书馆目录通常是分析发现助剂。
分析发现助剂本身是一个集合，并且可以通过单一的发现辅助来描述。
一个集合描述，由来自它内部的各个项目派生的信息组成。
由全文搜索引擎创建的索引是索引查找辅助的示例。
索引发现辅助本身是一个集合，并且可以通过单一的发现辅助来描述。
注意：在分析模型中，关系可能携带属性;在DC CD AP中，关系表示为简单的属性，并且本身不携带属性，因此模型的一些表达性丢失在元数据模式中。
一个物品*是收集的 - 一个或多个**集合**。
一种收藏*是-A-A-GALLING-OF_一个或多个**项目**。
DC CD AP未描述项目和集合之间的这些关系，因此不提供相应的属性。
一种收藏*位于一个或多个**位置**。
一种地点*是 - 位置 - 一个或多个**集合**。
在DC CD AP中，位于“关系类型”对应于该属性（Gen：异丙嗪？，Gen：位置？）;DC CD AP不提供代表逆关系类型的属性。
一种地点*是逐个或多个**代理**负责物理或数字环境。
一个代理人*管理_零或更多**位置**。
DC CD AP未描述位置和代理之间的这些关系，因此不提供相应的属性。
一种收藏*是 - 访问-Via_一个或多个**信息服务**。
一个信息服务*提供 - 访问-to_恰好一个**集合**。
在DC CD AP中，逐个关系类型对应于该属性（Gen：Isaccessedvia？Gen：Access？）;DC CD AP不提供代表逆关系类型的属性。
一种服务*提供 - 一个或多个**代理**。
一个代理人*提供零或更多**服务**。
DC CD AP未描述服务和代理之间的这些关系，因此不提供相应的属性。
一种收藏*被描述为your_零或更多**收集描述**。
一种收集描述*恰好描述_一个**集合**。
在DC CD AP中，逐个关系类型对应于属性DC：描述;DC CD AP不提供代表逆关系类型的属性。
物理收集（例如，库集合）位于物理位置（库）。
该地点由图书馆代理管理。
访问集合的访问由几种物理服务提供（例如，参考服务，贷款服务）。
每个服务由库辅助机构（或图书馆的某些子组）提供。
物理收集由图书馆目录（分析发现辅助）描述。
访问库目录由几个数字服务提供（例如Web OPAC接口，Z39.50目标）提供。
每个服务由库辅助机构（或图书馆的某些子组）提供。
[跟随]
位置和服务之间有关系吗？例如是一个服务 - 在一个位置吗？或者是独立于位置的服务？
是否有可能描述与数字服务不同的数字位置？
或者对于数字集合，我们只描述数字服务（而不是数字位置）吗？
资源位置 - 服务模型是否可以概括为集合以外的资源类别？
资源定位定位模型不适用是否存在资源类别？活动，代理商，“摘要”/概念资源？它只适用于“信息资源”（但是它们定义）？
资源定位 - 服务区别如何适合其余架构风格（可以参考资源的标识符以获得资源的表示）？
在DC元数据中表示，收集和服务之间的（两种不同）关系（可用 - 可用 - 通过）和收集和位置（位于in）之间的关系
DC：关系？在DC元数据中对现有做法有什么影响（例如，现有使用DC：标识符），特别是与“愚蠢”相关联“简单的DC”？