## Introduction

The Collection Administration tools are designed to aid in the production, maintenance, and sharing of resource records. At the most basic level, the information contained in individual resource records can be considered data about data, often called metadata. Metadata is the background information which describes the content, quality, condition, and other appropriate characteristics or properties of the resource. It allows for the organization, indexing, and classification of data for storage, discovery, and precise retrieval by users.

As shipped, the software offers a default set of metadata fields drawn from the Dublin Core Metadata Element Set (ANSI/NISO Z39.85-2001), additions from Dublin Core Metadata Initiative (DCMI) proposals, DCMI recommended refinements, and three from the Institute of Electrical and Electronics Engineers (IEEE) Learning Object Metadata (LOM) standard. The DC element set was developed by the DCMI, an organization dedicated to promoting the widespread adoption of interoperable metadata standards and developing specialized metadata vocabularies for describing resources that enable more intelligent information discovery systems. These fields are meant to be both broadly applicable and easily understood. The fields are defined in the Metadata Field Definitions section.

In order to add and edit records, users must use the work template that is available from the Add New Resource and the Edit Resources pages. Initially, each cataloging record template has this default set of fields available. The default fields parallel (at a basic level) the structured approach of a library catalog or commercially available database. The default fields are supplied for convenience only. Apart from the few required fields, Collection Administrators may disable and delete fields as needed. For completing these default fields, no particular cataloging rules, syntax, taxonomy, or other descriptive encoding level are prescribed or required by the portal software. Organizations are encouraged to carefully examine organizational cataloging needs and keep them in mind when establishing which standards, classification schemes, and encoding levels to follow for portal development. Additionally, organizations that customize the database should appropriately modify all help texts to reflect the changes.

Collection Administrators may customize the metadata fields as desired using the Metadata Field Editor. Why would Portal Creators want to use the Metadata Field Editor? Most simply, the Metadata Field Editor allows Collection Administrators the option of creating, editing, and deleting database fields and their content. For example, if the Collection Administrator wants to add a database field for the date a resource will be updated in the future, he or she would use the Metadata Field Editor to create a new date field called Date of Future Update. Display, cataloging templates, searching, and indexes throughout the portal are automatically updated after a change is implemented.

The required fields for the Metadata Tool to establish a record are the Url, Title, Description, Date Record Checked, Date of Record Creation, and Release Flag. These fields may not be deleted from the database, the class type changed, or made optional. In some cases, a default value may be supplied. In the case of Date of Record Creation and Date Record Checked, the portal software will supply these dates with the current date when no other information is given.

The Metadata Tool has special authorization features for components of the metadata separate from the authorization to add and edit resource records to the database. Because of the nature of Classifications and Names, an organization may wish to restrict access and editing permission of these two tables within the database. This permission only applies to adding/editing/deleting classification or name entries from the database. Unauthorized persons will not be able to view these options. This authorization is controlled by the system administrator.

## Qualified Metadata

This software package provides for the qualification of the Dublin Core metadata fields by encoding schemes and element refinements. These features offer additional information regarding the metadata value and provides context for that value when sharing metadata. Portal software handles encoding schemes differently than element refinements. An example of an encoding scheme, qualifying Classification with the Dewey Decimal Classification (DDC) informs of a particular value for Classification and that value is to be interpreted within the DDC realm vs. other similar schemes. An element refinement example would be a more specific Date such as Date Submitted or Date Copyrighted.

The portal software is shipped with default encoding scheme values drawn from Dublin Core Metadata Inititative (DCMI) recommendations. These DCMI recognized encoding schemes are provided for convenience. To make use of the metadata qualifying features, portal Administrators must define (in the Administration section) whether a metadata field uses encoding schemes and at what level (record or field level). They are not required by the software either at the metadata field or the record level.

Item Level Qualifiers means that a particular field could possibly have more than one possible encoding scheme. For example, drawing upon both Library of Congress Subject Headings (LCSH) and the National Library of Medicine's Medical Subject Headings (MeSH) vocabularies for Subject. Resource editors, when completing a resource record in the Metadata Tool, then choose between the allowed qualifying values provided to them by the portal Administrator. The scheme name will appear next the the value in the metadata record. For option lists (for example, Resource Type) encoding schemes are selected when added to a list of Metadata Tool Options. The alternative to item level is for a metadata field to be refined at the field level, in other words, any particular metadata field within a given portal uses the same qualifier. One qualifying encoding scheme can be selected as a default by the Administrator. This is the value the software will supply when no value is selected by the resource editor.

DCMI recommended element refinement fields are handled differently by portal software. As the software is shipped, these are supplied as default metadata fields. To make use of these portal administrators should enable all desired fields on the Metadata Field Editor page.

DCMI recommended refinements share meaning with the DCMI simple elements but have narrower semantic properties. For example, Title and Alternate Title share meaning, but Alternate Title is more specific interpretation. The portal software handles refinements differently than qualifying with encoding schemes. DCMI recommended element refinements are supplied as metadata fields. These fields in the OAI harvested metadata portal software will give the correct DCMI tags with corresponding DCMI URI(s). This is also the case for the three Institute of Electrical and Electronics Engineers (IEEE) Learning Object Metadata (LOM) and the DC Education Working Group recommended fields.

Note: Presently the Import, RSS, and manual export functions do not support DCMI Qualifiers. Qualified metadata is supported in OAI harvesting at this time.

For an up-to-date specification of all metadata terms maintained by the Dublin Core Metadata Initiative, including elements, element refinements, encoding schemes, and vocabulary terms (for example, DCMI Type Vocabulary) see the DCMI Metadata Terms document. A basic discussion of the application of the Dublin Core Element Set is the Dublin Core User Guide.

### See Also

- Metadata Field Definitions