Contents
Introduction
Dublin Core Database Frameworks (DC(2) and DCQ)
Differences Between DC(2) and DCQ Database Frameworks
Schemes and Qualifiers in the DC(2) Database Framework
Qualifiers and Schemes in the DCQ Database Framework
MARC Catalog Database Framework
In SiteSearch 4.1.2, the Record Builder application included with OCLC Database Builder ships with three database frameworks (there are two frameworks shipped with SiteSearch 4.1.1). A database framework consists of a local database – its five physical files, .dsc file, .dtd file, database configuration file, master XML template and supporting files, and (optionally), one or more data entry workforms based on the template.
The database frameworks are designed to serve as a starting point for the local databases that you populate and maintain with the Record Builder application. You can clone a database framework and then use the resulting database to catalog local collections of digital objects (such things as images, sound files, Web sites, and .PDF files) and/or data. It is also possible to customize a database framework by modifying its template and supporting files. See Files Modified in Template Customization for more information about the purpose of the various files that comprise a Dublin Core database framework.
The database frameworks are:
- Dublin
Core Database Frameworks
- Dublin Core(2) (DC(2))
- Dublin Core with Qualifiers (DCQ) (beginning with SiteSearch 4.1.2)
In addition, SiteSearch 4.1.1 and 4.1.2 both contain two sample databases based on the DC(2) database framework. These databases demonstrate the versatility of this database framework for cataloging a variety of electronic resources. The parks database (US National Parks) contains maps and photographs from two U.S. national parks. The scores (Music Scores) database contains scanned images of the front covers of several musical scores from the 1920's. Refer to the records in these sample databases and the MARC Catalog database framework to see how to use the database frameworks and their associated workforms to describe various types of resources.
Dublin Core Database Frameworks (DC(2) and DCQ)
The DC(2) and DCQ database frameworks shipped with SiteSearch 4.1.2 have these features in common:
See Differences Between DC(2) and DCQ Database Frameworks for information about the unique features of each framework.
Dublin Core Metadata Element Set
Both Dublin Core database frameworks (DC(2) and DCQ) are designed for cataloging electronic resources using Version 1.1 of the Dublin Core metadata element set (DCMES), as described in Dublin Core Metadata Element Set, Version 1.1: Resource Description. The Dublin Core is a metadata element set intended to facilitate discovery of electronic resources, such as Web sites, images, or sound files. However, the Dublin Core is sufficiently flexible to represent resources (and relationships among resources) that exist in both digital and traditional formats.
The following table lists and briefly describes each of the elements in the Dublin Core Metadata Element Set (DCMES), Version 1.1 (see the Version 1.1 of the Dublin Core metadata element set for more information).
| Element | Description | ||
| Title | A name given to the resource. A title is typically the name by which the resource is formally known. | ||
| Identifier |
An unambiguous reference to the resource within a given context. A recommended best practice is to identify the resource with a string or number confirming to a formal identification system, such as the Uniform Resource Identifier (URI), the Digital Object Identifier (DOI), or the International Standard Book Number (ISBN). |
||
| Publisher | An entity responsible for making the resource available. Examples of a publisher are a person, an organization, or a service. You should generally use the publisher's name to indicate the entity. | ||
| Contributor | An entity responsible for making contributions to the content of the resource. Examples of a contributor are a person, an organization, or a service. You should generally use the contributor's name to indicate the entity. | ||
| Coverage |
The extent or scope of the content of the resource. Coverage typically includes spatial location (place name or geographic coordinates), temporal period (period label, date, or date range), or jurisdiction (such as a named administrative entity). Recommended best practices are to:
|
||
| Creator | An entity primarily responsible for making the content of the resource. Examples of a creator are a person, organization, or service. You should generally use the creator's name to indicate the entity. | ||
| Date |
A date associated with an event in the life cycle of the resource. A date is typically associated with the creation or availability of the resource. A profile
of ISO 8601 [W3CDTF]
defines a recommend best practice for encoding date values following
the yyyy-mm-dd format. |
||
| Description | An account of the content of the resource. A description may include, but is not limited to, an abstract, table of contents, reference to a graphical representation of content, or a free-text account of the content. | ||
| Relation |
A reference to a related resource. A recommended best practice is to reference the resource using a string or number that conforms to a formal identification system. |
||
| Rights | Information about rights held in and over the resource. A rights element typically contains a rights management statement for the resource, or references a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights field is blank, it is not possible to make assumptions about the status of these and other rights with respect to the resource. | ||
| Source |
A reference to a resource from which the present resource is derived. The resource may be derived from the source resource in whole or in part. A recommended best practice is to reference the source using a string or number that conforms to a formal identification system. |
||
| Subject |
The topic of the content of the resource. A subject is typically expressed using keywords, key phrases, or classification codes that describe a topic of the resource. A recommended best practice is to select subject values from a controlled vocabulary or formal classification scheme. |
||
| Type |
The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Use Format (rather than Type) to describe the physical or digital manifestation of the resource. A recommended best practice is to select a type value from a controlled vocabulary, such as the working draft list of Dublin Core Types [DCT1].
|
||
| Format |
The physical or digital manifestation of the resource. The format may typically include the media type or dimensions of the resource. You may use the format to specify the software, hardware, or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. A recommended best practice is to select a format value from a controlled vocabulary, such as the list of Internet Media Types [MIME], which defines computer media formats. |
||
| Language |
A language of the intellectual content of the resource. RFC 1766 defines a recommended best practice for specifying language values. This includes a two-letter Language Code (from the ISO 639 standard), followed optionally, by a two-letter country code (from the ISO 3166 standard); for example, 'en' for English, 'fr' for French, or 'en-uk' for English used in the United Kingdom.
|
| Note: | You can add locally-defined elements to supplement this element set. See Adding Elements to a DC Template for more information. |
The DC(2) and DCQ database frameworks both use two broad classes of qualifiers to refine and clarify data elements. As described in Dublin Core Qualifiers, these classes of qualifiers are:
- Element Refinement. These qualifiers make the meaning of an element narrower or more specific. A refined element shares the meaning of the unqualified element, but with a more restricted scope. A client that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. The definitions of element refinement terms for qualifiers must be publicly available.
- Encoding Scheme. These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value expressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., "2000-01-01" as the standard expression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. The definitive description of an encoding scheme for qualifiers must be clearly identified and available for public use.
In the DC(2) and DCQ database frameworks, the element refinement qualifier is referred to simply as a "qualifier" and the encoding scheme qualifier is called a "scheme". (This is the terminology used in the Cooperative Online Resource Catalog (CORC). In SiteSearch 4.1.1, the DC(2) database framework uses the term "modifier" instead of the term qualifier, but modifier and qualifier are synonymous.
See Differences Between DC(2) and DCQ Database Frameworks for information about how these database frameworks use qualifiers and schemes differently.
The DCQ and DC(2) database frameworks have workforms with a similar, although not identical, layout.
Workform Examples
Click
here to see the DCQ workform in a second browser window.
Click here for
an example of the DC(2) workform in a second browser window.
Parts of the Workform
The top part of the workform displays administrative information about the record: its record ID, status, the record's creator, and the date the record was created and last modified. You can specify the record's status by selecting a value from the drop-down list.
The body of the workform is a series of repeatable fields, each of which corresponds to an element in the DCMES. Each field has two parts: a scheme and a qualifier you select from a drop-down list and a text box or a drop-down list for entering the value of the data element.
Buttons
The following table describes each of the buttons on the DCQ and DC(2) workforms.
| Button | Action |
 |
Add another entry for this field. |
 |
If there are multiple entries for this field, delete this entry. If there is only one entry for this field, delete the data in the field. |
 |
Turn the entry into an authorized entry and lock the scheme and/or qualifier selections. If the scheme is a URL, this also turns the entry into a hyperlink to a URL. If the field's purpose is to specify the name and location of an image file, the hyperlink allows you to view the image in a second browser window while editing the record. |
 |
Unlock and scheme and/or qualifier and make the data in the field editable. |
Differences Between DC(2) and DCQ Database Frameworks
The features that differentiate the DC(2) and DCQ database frameworks are:
The DC(2) workform in SiteSearch 4.1.2 includes a Scheme drop-down list for each element and a Qualifier drop-down list for most, but not all, elements. The DC(2) workform in SiteSearch 4.1.1 is similar except that the names of the drop-down lists are Scheme and Modifier. In both versions, the Scheme list appears above the Qualifier (or Modifier) list. See Schemes and Qualifiers in the DC(2) Framework for a list of the schemes and qualifiers included in the default DC(2) workform delivered with SiteSearch 4.1.1 and 4.1.2.
The DCQ workform in SiteSearch includes Qualifier and Scheme drop-down lists for every element, although a list may contain blank (no value) as a selection. In addition, the Qualifier list appears above the Scheme list to reinforce the qualifier/scheme relationship in DCQ. See Qualifiers and Schemes in the DCQ Framework for a list of the schemes and qualifiers included in the default DCQ workform shipped with SiteSearch 4.1.2.
The primary difference between the DCQ and DC(2) database frameworks is the qualifier/scheme relationship in DCQ. In the DC(2) database framework, the qualifier and scheme values are independent of one another. A metadata specialist can select any qualifier value and any scheme value listed. In DCQ, however, the qualifier and scheme values are related. The metadata specialist selects a qualifier for an element. This qualifier has a specific set of allowable scheme values, which appear in the Scheme drop-down list after the metadata specialist.
Schemes and Qualifiers in the DC(2) Database Framework
The following table lists the scheme and qualifier (modifier in SiteSearch 4.1.1) selections available in the default DC(2) workform.
| Element | Scheme | Qualifier |
| Title | AACR2 (Anglo-American
Cataloguing Rules, 2nd ed.) AAPM CDWA (Categories for the Description of Works of Art) VRA (Visual Resources Association) Free Text |
N/A |
| Identifier |
URL (Uniform
Resource Locator) |
N/A |
| Publisher | AACR2 AAPM CDWA VRA Free Text |
Personal
name Corporate name |
| Contributor | AACR2 AAPM CDWA VRA Free Text |
Personal
name Corporate name Compiler Collector Editor Illustrator |
| Coverage | Free Text Long./Lat. (Longitude/Latitude) OSGB (Ordnance Survey of Great Britain) |
spatial |
| Creator | AACR2 AAPM CDWA VRA Free Text |
Personal
name Corporate name |
| Date | Free text ISO8601 |
Creation Current Modified Valid From Valid To |
| Description | AACR2 AAPM CDWA VRA Free Text |
Abstract Free Text |
| Relation | Free Text FPI ISBN ISSN URL URN |
IsPartOf HasPart IsVersion of HasVersion IsFormat of HasFormat References IsReferencedBy IsBasedOn IsBasisFor Requires IsRequiredBy HasSource |
| Rights | N/A | N/A |
| Source | Free Text FPI ISSN ISBN |
N/A |
| Subject | LSCH (Library
of Congress Subject Headings) AAT (Art and Architecture Thesaurus) TGM (Getty Thesaurus of Geographic Names) MESH (Medical Subject Headings) ICONCLASS (Iconographic Classification System) LCC DDC (Dewey Decimal Classification) Free Text |
N/A |
| Type | Text Image Sound Dataset Software Event Interactive Physical Object |
N/A |
| Format | Free Text MIME |
N/A |
| Language | ISO
639 Free Text |
N/A |
| Note: | You can add domain-specific or locally-defined schemes or qualifiers or remove schemes or qualifiers from this list. See Adding or Removing Schemes and Qualifiers for a DC(2) Template. |
Qualifiers and Schemes in the DCQ Database Framework
The following table lists the qualifier/scheme combinations provided in the default DCQ workform shipped with SiteSearch 4.1.2. For each element, the default value appears in dark blue bold text.
|
|
| Note: | You can add domain-specific or locally-defined schemes or qualifiers or remove schemes or qualifiers from this list. See Adding or Removing Schemes and Qualifiers for a DCQ Template. |
MARCCat (MARC Catalog) Database Framework
The MARCCat database framework is designed for cataloging a variety of local resources in MARC format. There are workforms for books, computer files, maps, serials, sound recordings, mixed materials, visual materials, and musical scores. Each workform has MARC fields suitable for the type of resource being catalogued. The data entry fields on the workforms include a Help button, which leads to a Web page that provides information about that particular field.
Workform Example
Click here
for an example of a MARC Catalog workform in a second browser window.
Parts of the Workform
This workform has three parts:
- The top of the workform displays metadata about the record: its unique identifier (ID), status (Rec Stat), and the dates the record was created (Entered), modified (Replaced), and last opened (Used).
- The second section of the workform is a number of single-entry text boxes. Some of the text boxes contain data relevant to the workform's type.
- The body of the workform contains a series of repeatable fields for entering the record's MARC fields. Each field has three text boxes: one for the MARC tag, one for the indicators, and one for the field data. Each workform includes tags typically used for cataloging that type of resource and may include relevant subfield codes. You can edit the data in any of the text boxes and leave the fields blank that do not apply to a particular resource.
Buttons
The following table describes each of the buttons on MARC Catalog workforms.
| Button | Action |
|
Add another entry for this field. |
|
If there are multiple entries for this field, delete this entry. If there is only one entry for this field, delete the data in the field. |
 |
Obtain online help for this field in a second browser window. |
See Also
Cloning a Record Builder Database
Performing Online Updates to Local Databases
with Record Builder
Batch Loading Data into a Local DC(2) Database
Updated with Record Builder
Edit Record Screen
Record Builder Process Model and System Overview
Customizing DC Templates
Planning a DC Database