DSpace 1.6.1 手册：功能概览与关键特性

需积分: 9 76 浏览量更新于2024-08-01 收藏 1.87MB PDF 举报

"DSpace 1.6.1 手册(英文版)" 是一份针对 DSpace 1.6 版本的详细操作指南，由 DuraSpace 出版，版权属于 DuraSpace 组织。该手册包含了系统文档介绍、功能概述、数据模型、插件管理器、元数据、打包插件、交叉引用插件、电子人员与用户组、认证、授权、录入流程和工作流、监督与协作、Handle 系统、位流持久标识、SRB（Storage Resource Broker）支持、搜索与浏览、HTML 支持、OAISet 支持、OpenURL 支持、Creative Commons 许可支持、订阅、导入导出、注册、统计等多个方面的内容。 DSpace 是一个开源的数字对象存储和管理系统，用于存储、管理和分发学术文献和其他数字资产。在 DSpace 1.6.1 中，其核心功能包括： 1. 数据模型：DSpace 的数据模型定义了如何组织和表示存储的数字对象，包括元数据结构和内容位流。 2. 插件管理器：DSpace 允许通过插件机制扩展其功能，插件管理器使得这些扩展易于集成和管理。 3. 元数据：DSpace 使用一套元数据标准来描述存储的资源，支持自定义元数据方案以适应不同的学科或机构需求。 4. 包装插件和交叉引用插件：这两类插件分别处理数字对象的导入导出格式转换以及不同元数据标准之间的互换。 5. E-People and Groups：DSpace 支持用户管理，包括个人（E-Person）和用户组，允许权限分配和协作。 6. 认证与授权：DSpace 提供身份验证机制，控制用户访问资源的权限，可以配置多种认证策略。 7. 工作流和录入过程：DSpace 具有灵活的工作流系统，支持多步骤的审核和发布流程。 8. 搜索和浏览：DSpace 内置搜索引擎和浏览功能，便于用户查找和定位资源。 9. HTML 支持和 OAISet 支持：DSpace 可以生成 HTML 页面展示内容，同时符合开放存档信息集（OAIS）标准，便于长期保存和检索。 10. OpenURL 支持：DSpace 支持 OpenURL 协议，使用户能从其他引用服务直接链接到具体资源。 11. Creative Commons 支持：DSpace 可以设置资源的 Creative Commons 许可，促进资源的合法分享和使用。 12. 订阅功能：用户可以订阅特定的资源或集合，以便接收更新通知。 13. 导入导出功能：DSpace 提供工具将数据导入或导出到其他系统，便于数据迁移和整合。 14. 注册：新用户可以通过注册过程成为 DSpace 系统的成员。 15. 统计：DSpace 能够收集并报告关于资源访问和使用的统计信息。这份手册对于管理员和用户来说是宝贵的参考资料，详细解释了 DSpace 系统的各个方面，有助于更好地理解和利用这一强大的数字存储平台。

Chapter 2. DSpace System

Documentation: Functional Overview

The following sections describe the various functional aspects of the DSpace system.

2.1. Data Model

DSpace System Documentation: Functional Overview

Data Model Diagram

The way data is organized in DSpace is intended to reflect the structure of the organization using the DSpace system. Each

DSpace site is divided into communities, which can be further divided into sub-communities reflecting the typical university

structure of college, departement, research center, or laboratory.

Communities contain collections, which are groupings of related content. A collection may appear in more than one community.

Each collection is composed of items, which are the basic archival elements of the archive. Each item is owned by one collection.

Additionally, an item may appear in additional collections; however every item has one and only one owning collection.

Items are further subdivided into named bundles of bitstreams. Bitstreams are, as the name suggests, streams of bits, usually

ordinary computer files. Bitstreams that are somehow closely related, for example HTML files and images that compose a

single HTML document, are organised into bundles.

In practice, most items tend to have these named bundles:

• ORIGINAL -- the bundle with the original, deposited bitstreams

• THUMBNAILS -- thumbnails of any image bitstreams

• TEXT -- extracted full-text from bitstreams in ORIGINAL, for indexing

• LICENSE -- contains the deposit license that the submitter granted the host organization; in other words, specifies the rights

that the hosting organization have

• CC_LICENSE -- contains the distribution license, if any (a Creative Commons [http://www.creativecommons.org] license)

associated with the item. This license specifies what end users downloading the content can do with the content

Each bitstream is associated with one Bitstream Format. Because preservation services may be an important aspect of the

DSpace service, it is important to capture the specific formats of files that users submit. In DSpace, a bitstream format is a unique

and consistent way to refer to a particular file format. An integral part of a bitstream format is an either implicit or explicit notion

of how material in that format can be interpreted. For example, the interpretation for bitstreams encoded in the JPEG standard

for still image compression is defined explicitly in the Standard ISO/IEC 10918-1. The interpretation of bitstreams in Microsoft

Word 2000 format is defined implicitly, through reference to the Microsoft Word 2000 application. Bitstream formats can be

more specific than MIME types or file suffixes. For example, application/ms-word and .doc span multiple versions

of the Microsoft Word application, each of which produces bitstreams with presumably different characteristics.

Each bitstream format additionally has a support level, indicating how well the hosting institution is likely to be able to preserve

content in the format in the future. There are three possible support levels that bitstream formats may be assigned by the hosting

institution. The host institution should determine the exact meaning of each support level, after careful consideration of costs

and requirements. MIT Libraries' interpretation is shown below:

Table 2.1. MIT Libraries' Definitions of Bitstream Format Support Levels

Supported The format is recognized, and the hosting institution is confi-

dent it can make bitstreams of this format useable in the future,

using whatever combination of techniques (such as migration,

emulation, etc.) is appropriate given the context of need.

Known The format is recognized, and the hosting institution will

promise to preserve the bitstream as-is, and allow it to be re-

trieved. The hosting institution will attempt to obtain enough

information to enable the format to be upgraded to the 'sup-

ported' level.

DSpace System Documentation: Functional Overview

Unsupported The format is unrecognized, but the hosting institution will un-

dertake to preserve the bitstream as-is and allow it to be re-

trieved.

Each item has one qualified Dublin Core metadata record. Other metadata might be stored in an item as a serialized bitstream,

but we store Dublin Core for every item for interoperability and ease of discovery. The Dublin Core may be entered by end-

users as they submit content, or it might be derived from other metadata as part of an ingest process.

Items can be removed from DSpace in one of two ways: They may be 'withdrawn', which means they remain in the archive but

are completely hidden from view. In this case, if an end-user attempts to access the withdrawn item, they are presented with

a 'tombstone,' that indicates the item has been removed. For whatever reason, an item may also be 'expunged' if necessary, in

which case all traces of it are removed from the archive.

Table 2.2. Objects in the DSpace Data Model

Object Example

Community Laboratory of Computer Science; Oceanographic Research

Center

Collection LCS Technical Reports; ORC Statistical Data Sets

Item A technical report; a data set with accompanying description;

a video recording of a lecture

Bundle A group of HTML and image bitstreams making up an HTML

document

Bitstream A single HTML file; a single image file; a source code file

Bitstream Format Microsoft Word version 6.0; JPEG encoded image format

2.2. Plugin Manager

The PluginManager is a very simple component container. It creates and organizes components (plugins), and helps select a

plugin in the cases where there are many possible choices. It also gives some limited control over the lifecycle of a plugin.

A plugin is defined by a Java interface. The consumer of a plugin asks for its plugin by interface. A Plugin is an instance of

any class that implements the plugin interface. It is interchangeable with other implementations, so that any of them may be

"plugged in".

The mediafilter is a simple example of a plugin implementation. Refer to the Business Logic Layer for more details on Plugins.

2.3. Metadata

Broadly speaking, DSpace holds three sorts of metadata about archived content:

Descriptive Metadata

DSpace can support multiple flat metadata schemas for describing an item.

A qualified Dublin Core metadata schema loosely based on the Library Application Profile [http://www.dublincore.org/

documents/library-application-profile/] set of elements and qualifiers is provided by default. The set of elements and qual-

ifiers used by MIT Libraries [http://dspace.org/technology/metadata.html] comes pre-configured with the DSpace source

code. However, you can configure multiple schemas and select metadata fields from a mix of configured schemas to de-

scribe your items.

DSpace System Documentation: Functional Overview

Other descriptive metadata about items (e.g. metadata described in a hierarchical schema) may be held in serialized bit-

streams. Communities and collections have some simple descriptive metadata (a name, and some descriptive prose), held

in the DBMS.

Administrative Metadata

This includes preservation metadata, provenance and authorization policy data. Most of this is held within DSpace's relation

DBMS schema. Provenance metadata (prose) is stored in Dublin Core records. Additionally, some other administrative

metadata (for example, bitstream byte sizes and MIME types) is replicated in Dublin Core records so that it is easily

accessible outside of DSpace.

Structural Metadata

This includes information about how to present an item, or bitstreams within an item, to an end-user, and the relationships

between constituent parts of the item. As an example, consider a thesis consisting of a number of TIFF images, each

depicting a single page of the thesis. Structural metadata would include the fact that each image is a single page, and the

ordering of the TIFF images/pages. Structural metadata in DSpace is currently fairly basic; within an item, bitstreams can

be arranged into separate bundles as described above. A bundle may also optionally have a primary bitstream. This is

currently used by the HTML support to indicate which bitstream in the bundle is the first HTML file to send to a browser.

In addition to some basic technical metadata, bitstreams also have a 'sequence ID' that uniquely identifies it within an item.

This is used to produce a 'persistent' bitstream identifier for each bitstream.

Additional structural metadata can be stored in serialized bitstreams, but DSpace does not currently understand this natively.

2.4. Packager Plugins

Packagers are software modules that translate between DSpace Item objects and a self-contained external representation, or

"package". A Package Ingester interprets, or ingests, the package and creates an Item. A Package Disseminator writes out the

contents of an Item in the package format.

A package is typically an archive file such as a Zip or "tar" file, including a manifest document which contains metadata and

a description of the package contents. The IMS Content Package [http://www.imsglobal.org/content/packaging/] is a typical

packaging standard. A package might also be a single document or media file that contains its own metadata, such as a PDF

document with embedded descriptive metadata.

Package ingesters and package disseminators are each a type of named plugin (see Plugin Manager), so it is easy to add new

packagers specific to the needs of your site. You do not have to supply both an ingester and disseminator for each format; it

is perfectly acceptable to just implement one of them.

Most packager plugins call upon Crosswalk plugins to translate the metadata between DSpace's object model and the package

format.

2.5. Crosswalk Plugins

Crosswalks are software modules that translate between DSpace object metadata and a specific external representation. An

Ingestion Crosswalk interprets the external format and crosswalks it to DSpace's internal data structure, while a Dissemination

Crosswalk does the opposite.

For example, a MODS ingestion crosswalk translates descriptive metadata from the MODS format to the metadata fields on a

DSpace Item. A MODS dissemination crosswalk generates a MODS document from the metadata on a DSpace Item.

Crosswalk plugins are named plugins see Plugin Manager), so it is easy to add new crosswalks. You do not have to supply both

an ingester and disseminator for each format; it is perfectly acceptable to just implement one of them.

There is also a special pair of crosswalk plugins which use XSL stylesheets to translate the external metadata to or from

an internal DSpace format. You can add and modify XSLT crosswalks simply by editing the DSpace configuration and the

stylesheets, which are stored in files in the DSpace installation directory.

DSpace System Documentation: Functional Overview

The Packager plugins and OAH-PMH server make use of crosswalk plugins.

2.6. E-People and Groups

Although many of DSpace's functions such as document discovery and retrieval can be used anonymously, some features (and

perhaps some documents) are only available to certain "privileged" users. E-People and Groups are the way DSpace identifies

application users for the purpose of granting privileges. This identity is bound to a session of a DSpace application such as the

Web UI or one of the command-line batch programs. Both E-People and Groups are granted privileges by the authorization

system described below.

2.6.1. E-Person

DSpace hold the following information about each e-person:

• E-mail address

• First and last names

• Whether the user is able to log in to the system via the Web UI, and whether they must use an X509 certificate to do so;

• A password (encrypted), if appropriate

• A list of collections for which the e-person wishes to be notified of new items

• Whether the e-person 'self-registered' with the system; that is, whether the system created the e-person record automatically

as a result of the end-user independently registering with the system, as opposed to the e-person record being generated from

the institution's personnel database, for example.

• The network ID for the corresponding LDAP record

2.6.2. Groups

Groups are another kind of entity that can be granted permissions in the authorization system. A group is usually an explicit list

of E-People; anyone identified as one of those E-People also gains the privileges granted to the group.

However, an application session can be assigned membership in a group without being identified as an E-Person. For example,

some sites use this feature to identify users of a local network so they can read restricted materials not open to the whole

world. Sessions originating from the local network are given membership in the "LocalUsers" group and gain the corresonding

privileges.

Administrators can also use groups as "roles" to manage the granting of privileges more efficiently.

2.7. Authentication

Authentication is when an application session positively identifies itself as belonging to an E-Person and/or Group. In DSpace

1.4, it is implemented by a mechanism called Stackable Authentication: the DSpace configuration declares a "stack" of authen-

tication methods. An application (like the Web UI) calls on the Authentication Manager, which tries each of these methods in

turn to identify the E-Person to which the session belongs, as well as any extra Groups. The E-Person authentication methods

are tried in turn until one succeeds. Every authenticator in the stack is given a chance to assign extra Groups. This mechanism

offers the following advantages:

• Separates authentication from the Web user interface so the same authentication methods are used for other applications such

as non-interactive Web Services

剩余356页未读，继续阅读

loess

粉丝: 0
资源: 2

DSpace 1.6.1 手册：功能概览与关键特性

dspace1.5.2 使用手册

DSpace-Manual学习资料

Dspace-Manual

DSpace-Manual.pdf

dSPACE_ControlDesk-Brochure_05_2020_English.pdf

dSPACE_ControlDesk-Brochure_07_2018_English.pdf

内模pid控制.zip_dSPACE_dspace control_dspace real time_dspace simuli

dSPACE.rar_dSPACE 电机_dspace control_dspace+电机_motor_电机 pdf

dspace部署

dspace实例

最新资源