Contents
Introduction
Document Conventions
Reasons for Customizing a DC Template
When to Customize a Template
Supported Customizations
Roles of Files Modified in Template Customization
While the templates provided as part of the DC database frameworks (DC(2) and DCQ) shipped with the OCLC Database Builder's Record Builder application are generally suitable for creating and editing records in DC databases without any modification, you may need to customize a template for a specific database.
"Customize a template" is a generic term for modifying a database's template.xml, field.xml, constant.xml, .dtd file, and/or database configuration files to produce a customized data entry workform (displayed on Record Builder's Edit Record screen) for online record entry and editing.
This document briefly describes the reasons for customizing a template, when to customize a template, and supported customizations. It also explains the role of the files that you may modify when you customize a template. You should understand the role of each of these files before you modify them.
- DC(2) refers to the Dublin Core(2) database framework introduced in SiteSearch 4.1.1. The DC(2) database framework uses Version 1.1 of the Dublin Core Metadata Element Set (DCMES).
- DCQ refers to the Dublin Core with Qualifiers database framework introduced in SiteSearch 4.1.2. The DCQ database framework also uses Version 1.1 of the DCMES and qualifiers, as defined by the Dublin Core Metadata Initiative in Dublin Core Qualifiers.
- <WebZ_root> refers to the location of the SiteSearch environment that includes Record Builder.
- XML namespace is an identifier used to ensure uniqueness among XML elements with the same name. Namespaces used in DC templates are DC, MANTIS, RDF, and in SiteSearch 4.1.1, RB. In a tag used to specify an element, the namespace precedes the element's name and a colon separates the namespace and the element, such as DC:Title or RB:Info.
Reasons for Customizing a DC Template
Some reasons for customizing a DC template include:
- Adding domain-specific elements and/or qualifiers to the Dublin Core metadata element set. These are elements recommended by a Dublin Core Metadata Initiative (DCMI) Working Group, such as the Architecture and Education Working Groups.
- Adding locally-defined elements or qualifiers.
- Streamlining data entry by removing elements, schemes, or qualifiers not applicable to a particular database.
- For a DC(2) database, preparing for subsequent migration to the DCQ framework.
As you plan a new DC database, review the elements and qualifiers included in the DC database frameworks provided with Record Builder. If you need to modify the template, the best time to make these modifications is before you create the database and add any data to it. See Planning a New DC Database for more information.
Record Builder supports a number of customizations to DC templates. The following table lists these customizations along with links to procedures that explain how to perform each of these customization tasks.
| Task | Procedure |
| Adding domain-specific or locally-defined elements | Adding Elements to a DC Template |
| Adding domain-specific or locally-defined qualifiers and/or schemes to existing elements |
Adding or Removing Schemes and Qualifiers for a DC(2) Template Adding or Removing Schemes and Qualifiers for a DCQ Template |
| Removing qualifiers or schemes |
Adding or Removing Schemes and Qualifiers for a DC(2) Template Adding or Removing Schemes and Qualifiers for a DCQ Template |
| Removing elements | Removing Elements from a DC Template |
| Adding constant data | Creating or Disabling Constant Data for a DC Template |
You can implement these customizations in any combination for a particular database. For example, you can add new domain-specific elements and remove qualifiers for existing elements in the same template.
Other customizations may cause Record Builder to function erratically and may be incompatible with future upgrades to Record Builder.
Roles of Files Modified in Template Customization
Another document (The Record Builder Interface in Action) describes how the elements of the Record Builder interface work together to perform online updates to a local database. This section provides additional detail about how the following files contribute to creating a workform displayed on Record Builder's Edit Record screen:
Except for the database configuration file, all of these files reside in the database's top-level directory, typically <WebZ_root>/dbbuilder/dbs/db_name.
The template.xml file is a database's master XML template, and often its only workform.
Click here
for an example of a template.xml file in a second browser window. The
example includes numbered callouts that describe key sections of this
file.
After an XML declaration statement, it includes Record Builder specific-statements that call hooks to populate the completed workform, as shown on the Edit Record screen, with constant data, values for drop-down lists, and buttons. Other statements create the administrative information about the record at the top of the workform. All of these statements must remain intact as shipped.
Element specifications for each of the elements in the DCMES, version 1.1 (such as <DC:Title>, <DC:Identifier>, and so on), follow the <ID> element, in the format <DC:element_name>, where DC is the element's XML namespace and element_name is the element's name.
Record Builder uses the statements in each element specification to create a data entry field for the element on the Edit Record screen. Statements define the label, type (textarea or listbox), display size, and maximum size of the data entry field and whether the data entry field is replicable (it can have more than one instance in a record). The element specification also indicates whether the element has schemes and/or qualifiers (modifiers in SiteSearch 4.1.1).
When you add or remove elements for a DC database, you edit template.xml accordingly.
| Return to top of section |
While the <DC:scheme> and <DC:qualifier> sections within an element specification indicate whether to include Scheme or Qualifier lists for the element on the Edit Record screen, the field.xml file contains the lists of values to be included in each list. Each element with schemes and/or qualifiers has a section in field.xml. The <DC:element_name></DC:element_name> tags delimit each section for a particular element.
field.xml in DC(2) Database Framework
Click here
for an example of a field.xml file for a DC(2) database in a second browser
window. The example includes numbered callouts that describe key sections
of this file. The important things to note about the field.xml file for
a DC(2) database are that:
- Scheme and qualifiers for an element are grouped together, with schemes first and qualifiers following. In SiteSearch 4.1.2, the scheme list begins and ends with <DC:scheme> and </DC:scheme> tags and the modifier list with <DC:qualifier> and </DC:qualifier> tags (the corresponding tags in SiteSearch 4.1.1 are <RB:scheme></RB:scheme> and <RB:modifier></RB:modifier>, respectively). <entry> and </entry> tags delimit each list item.
- Scheme and
qualifier values are independent of each other. The metadata specialist
can select any available scheme/qualifier combination.
field.xml in DCQ Database
Click here
for an example of a field.xml file for a DCQ database in a second browser
window. The example illustrates the qualifier-scheme association in DCQ
databases. The important things to note about the field.xml file for a
DC(2) database are that:
- It lists a qualifier and all the schemes associated with that qualilfier. Then it lists another qualifier and its schemes, and so on. This associates qualifiers and schemes. When a metadata specialist enters a qualifier to refine the value of a data element, Record Builder changes the drop-down list values for the scheme to those associated with the qualifier in field.xml.
- It is possible to have blank (no value) as an allowable qualifier or scheme value.
- Each element has default scheme and qualifier values.
You edit field.xml when you add or remove schemes or qualifiers for an existing element, create a new element with schemes and/or qualifiers, or remove an existing element.
| Return to top of section |
A constant.xml file is optional. If it exists and the database's configuration file contains a reference to the file, it allows you to predefine values (element, scheme and qualifier) for any elements in the database. This allows metadata specialists to populate elements with identical values across many records. See Record Builder and Constant Data for more information.
Click here
for an example of a constant.xml file for a DC database in a second browser
window.
| Return to top of section |
The .dtd file (dc.dtd for DC(2) or dcq.dtd for DCQ) contains a list of all elements in template.xml (including elements in the DC, RB, and MANTIS namespaces) in the form namespace:element_name and their corresponding field numbers. A field number associates an element in template.xml with the tag path to this element in its BER record in the database. This allows Record Builder to place data from an existing record in the appropriate fields on the Edit Record screen and to store data entered on the Edit Record screen in the database.
You edit this file when you add or remove elements from a template.
| Return to top of section |
The .dsc file (dc.dsc for DC(2) or dcq.dsc for DCQ) includes definitions for the database's indexes. If you add new elements to a database template, you create index definitions for the elements in the .dsc file.
| Return to top of section |
A DC database's configuration file includes references to the template.xml, field.xml, constant.xml, and .dtd files in its [ttemplate_definition] section. Since it also contains references to the indexes defined in the database's .dsc file, you edit this file when you create indexes for new elements.
| Return to top of section |
See Also
Planning
a DC Database
Elements of the Record Builder Interface
The Record Builder Interface in Action
DC(2) Workform Example
DCQ Workform Example