Batch and Individual Record Editing for DC Databases
Contents
Introduction
Document Conventions
Selecting Update Method(s)
Using SSDOT to Update Database
Using Record Builder to Create and Edit Records
Batch Loading Data in a Format Compatible with Record
Builder
Switching Between Batch Loading and Using Record
Builder
The purposes of this document are to:
- help you plan how to handle updates to local SiteSearch databases based on a DC database framework.
- compare how Open SiteSearch Database Builder and its Record Builder application handle batch updates and individual record updates for DC) databases
- 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.
- DC database refers to a local SiteSearch database based on a DC database framework (DC(2) or DCQ).
When you create a new local DC(2) database, the method(s) available for updating the database depend on whether you:
wish to use Record Builder for online record updates
have existing data to batch load into the database
The diamonds in the following flow chart represent these circumstances. The rectangles represent the method(s) appropriate for each circumstance. Click any of the rectangles in the flow chart to go to the part of the document that describes this method.
Although the flow
chart does not show this explicitly, when you batch load data in a format
compatible with Record Builder (
)you
can subsequently edit these records with Record Builder (
)and
vice versa.
Using SSDOT to Update Database
If you do not plan to use Record Builder to create and edit records, you can create a local SiteSearch database by using SSDOT to build the database. Use the dc.dtd and dc.dsc files available in <WebZ_root>/dbbuilder/dbs/dc for a DC(2) database and the dcq.dtd and dcq.dtd files available in <WebZ_root>/dbbuilder/dbs/dcq for a DCQ) database.
One of the steps in the build process is to update the database (load data into the database) using option 2 (Update database) on SSDOT's Database Creation and Maintenance menu. You also use this step for subsequent database updates.
When you load data into the database and the source data is in SGML format, SSDOT uses the sgmlconv utility to convert the data to BER format. By default, sgmlconv creates a BER record structure that stores the data values in a /1 subfield.
The following
example illustrates the relationships among the SGML data, the .dtd file,
and the resultant BER record in part of a DC(2) record when creating a
local database with SSDOT's Update
database option. The numbers (such as )
and color coding in the example show the corresponding sections of each
file. The table that follows describes each numbered section.
| Note: | Although Database Builder does not require the source data to have an <ID> field, the DC(2) record structure includes this field so the example includes it as well. |
| Item(s) | Description | ||||||||||||||||||||||||||||
 |
In each of these fields, a single SGML tag surrounds each data value in the SGML source data. The .dtd file includes a unique number to identify each field. The resultant BER file for each field has a two-level tag path: the field number (such as 1099, 101, and so on) and the field's data (1). | ||||||||||||||||||||||||||||
 |
The DC:Identifier field contains a nested tag structure in the source data. The example below shows the nested structure and the field number for each field from the .dtd file. The data values and their subfield tags (/1) appear in dark blue bold text.
The BER tag paths for this field reflect this nesting and place the data for the DC:Identifier field and its RB:state and RB:scheme subfields at the /1 level subordinate to the field numbers. |
||||||||||||||||||||||||||||
Using Record Builder to Create and Edit Records
If you want to use Record Builder to create and edit records, you begin by cloning a new database from the a DC database framework.
Record Builder uses the same database building utilities as SSDOT to update a local database as your catalogers add, update, or delete records. However, Record Builder uses a BER record structure that stores the data values in the subfield designated as PCDATA in the .dtd file. By convention, this is a /1001 tag rather than a /1 tag. This preserves subfields 1 through 10 for internal Record Builder use.
Batch Loading Data in a Format Compatible with Record Builder
When you update a local database with SSDOT, by default SSDOT runs sgmlconv to convert source data to BER format, and assigns the /1 tag at the data level. When you create and edit records with Record Builder, by convention Record Builder assigns the /1001 tag at the data level. So you cannot update records added to a local database via SSDOT with Record Builder or make batch updates to records added through Record Builder because of their different tag paths to the record data.
However, there is another way to batch load data so that you can subsequently add, modify, and delete individual records with Record Builder. The rest of this section summarizes this process and explains why it works, but the document Batch Loading Data into a Local DC Database Updated with Record Builder contains detailed step-by-step instructions for the entire batch loading process.
In essence, you need a way to create a BER record structure for your source data that stores the data in a /1001 subfield rather than a /1 subfield. You accomplish this by preparing your SGML source data file in a slightly different way and by running the sgmlconv utility with an optional flag, -p.
Using sgmlconv with the -p flag requires that you explicitly mark the portion of each record that contains the data value by surrounding it with <PCDATA> </PCDATA> tags. When run with the -p flag, sgmlconv uses the value of the PCDATA tag in the .dtd file (1001) to structure the BER record with the data in a /1001 subfield.
Another requirement for this batch loading process is that your records include an <ID> field with a unique identifier because Record Builder uses the value in this field to locate individual records.
The following example shows the SGML data structure and the .dtd file used to batch load data in a format compatible with Record Builder, and the resultant BER data structure. It highlights the differences between these versions and the ones that illustrate updating a database using SSDOT's Update database option. Differences appear in dark blue bold text:
- The SGML source data contains <PCDATA></PCDATA> tags to delineate the data portion of each field.
- The .dtd file contains a PCDATA field with a 1001 field number.
- The BER record structure is the same except that the subfield tag for all data values is /1001 instead of /1.
After you convert your source data to BER format, you run the Database Builder utility programs from SSDOT's Advanced Options menu to perform the other tasks that SSDOT normally completes automatically in the database update step of the database build process:
- Adding records to the database and creating index terms for these records
- Sorting the index terms
- Adding the index terms to the database
- Sorting sparse index terms (if necessary)
- Adding the sparse index terms to the database (if necessary)
If you need to perform several batch loads for a single DC database, or you need to populate several DC databases, you can automate this process by adding sgmlconv -p to SSDOT as another BER conversion method.
Switching Between Batch Loading and Using Record Builder
You can switch between batch loading data into a DC database using sgmlconv -p and editing records using Record Builder at any time.
See Also
Record
Builder Database Frameworks
Record Builder Interface
Performing Online Updates to Local Databases
with Record Builder