Template:Classic RAD

Main Page > BCAUL pilot project > Templates

Classic RAD template Document status: in progress Related documents: Template: RAD ISAD(G)ed Template: RAD2

Contents Overview Identity area Title and statement of responsibility area Edition area Class of material specific details area Creation context Physical description area Publisher's series area Archival description area Notes area Standard number area Control area / Digital object / Storage location

Overview

Divs used to organize data entry screen

This template is modelled closely on the Canadian Rules for Archival Description (RAD). The divs that structure the data entry screen are drawn from RAD areas of description, with additional divs to handle Qubit-required fields / implementations that have no RAD equivalent.

RAD in turn contains a number of elements that have no ISAD(G) or Qubit analogs. There are two basic approaches for handling these:

1. Create custom fields via the Qubit property table; or
2. Map RAD elements onto existing Qubit fields, relying on the Qubit note and event tables to handle exceptions.

Approach (1) is most RAD-compliant but it requires more back-end customization to implement fields that are little-used even in RAD environments. Approach (2) requires less customization, but results in loss of RAD-specific information. In many cases a "mixed" approach may be most appropriate. Options are set out and ilustrated below in the relevant RAD area of description.

Identity area

Identity area

This div has no analog in RAD. It brings together several Qubit-required fields: Identifier, Level of description, Parent level, Repository. As these fields contribute to uniquely identifying the unit of description, the div name follows the ISAD(G) equivalent area.

Note that other fields may be added to this div, depending on implementation decisions elsewhere that may lead to the elimination of other RAD-specific areas of decription.

Title and statement of responsibility area

Option 1: custom fields for each RAD title element

Option 2: multiple title handled by separate title table

Option 3: title handled by Identity area

Option 4: title handled by expanded Identity area

This div corresponds to RAD area 1.1. Where ISAD(G) has only 1 title element (3.1.2), RAD breaks titles down into 5 elements: Title proper (1.1B), General material designation (1.1C), Parallel titles (1.1D), Other title information (1.1E), and Statements of responsibility (1.1F - applies only at item-level). These elements are then concatenated into a single title statement, with punctuation rules to distinguish the various components. RAD also includes 6 separate Note area elements for notes relating to titles (1.8B1 - 1.8B6). There are several options for implementing this area in Qubit.

Option 1

• Handle RAD elements as custom fields (field name and value stored in related Qubit property records).
• Use a getRADTitle() method to return the full title on the View screen, formatted according to RAD punctuation rules.

Option 2

• Create a new title table in Qubit to support multiple titles.
• RAD includes examples of many types of titles (formal, supplied, traditional, alternative, parallel).
• Table could also track previous titles (if name of fonds / collection has changed over time).
• Fields could include information_object_id, title, type_id, start_date, end_date.
• Would also be useful for ISAD(G) template.

Option 3

• Map all RAD element onto the single Qubit field information_object::title.
• Leave it to user to structure content according to RAD requirements.
• Use Qubit notes for additonal info relating to title.
• Abolish Title and statement of responsibility area div since all data is handled by other areas.

Option 4

• Map RAD Title proper to Qubit information_object::title.
• Accommodate RAD General material designation (1.1C) as custom field mapped to Qubit property::name="gmd" value=" ".
• Use Qubit event to register RAD Statements of responsibility.
• Map all other RAD titles to Qubit information_object::alternate_title.
• Use Qubit notes to manage any other descriptive info relating to title.
• Create a "RAD title notes" taxonomy for title notes.
• Abolish Title and statement of responsibility area div since all data can be handled by other areas.

Edition area

Edition area

This div corresponds to RAD area 1.2. It is used only at the item-level for statements relating to multiple versions of an item. The area contains 2 elements: Edition statement (1.2B) and Statements of responsibility relating to edition (1.2C).

Neither of these elements have an ISAD(G) or Qubit analog. They can be implemented either as custom fields or adpated to Qubit notes and events.

Option 1

• Use Qubit property records to store field name. and values.
• Use a getRADEdition() method to the values on the View screen in a single statement formatted by RAD punctuation rules.

Option 2

• Map RAD Edition statement (1.2B) to Qubit note.
• Map RAD Statements of responsibility relating to edition (1.2C) to Qubit event.
• Eliminate this area as a separate div since data can be handled by other areas.

Class of material specific details area

Option 1: separate div displaying each field

Option 2: separate div showing only fields as needed

This div corresponds to RAD area 1.3. It is used only with certain special media: catrographic materials (5.3 Mathematical data area – 3 elements), architectural and technical drawings (6.3 Scale area – 1 element), and philatelic records (13.3 Issue data area – 2 elements). None of these elements have direct ISAD(G) or Qubit analogs. The main options are to implement as custom fields or assimilate to Qubit notes.

Option 1

• Map RAD elements to Qubit custom fields (storing field names and values in Qubit property records related to the information object).
• Include fields on the interface for each element.

Option 2

• Same as (1) except provide a drop-down menu interface and only show elements on an "as-needed" basis.
• Control terms in the drop-down list by a "Class of material specific details" taxonomy using RAD element names.

Option 3

• Map RAD elements to Qubit notes, using "Class of material specific details" taxonomy to control note types by RAD element names.
• Eliminate Class of material specific details area as separate div, since it is handled by Notes area.
• Or, retain as separate div displaying only this type of note.

Creation context

Creation context div

This div loosely corresponds to RAD area 1.4, Dates of creation, publication, distribution, etc area. The difference reflects the way Qubit implements dates of creation as creation events tied to actors. This in turn means that the Administrative history / biographical sketch element is better suited for inclusion in this div, instead of appearing in the Archival description area div as per RAD.

This div captures RAD Dates of creation (1.4B). But RAD 1.4 also includes 5 elements applicable only at the item-level and relating to publication and distribution: Place of publication, distribution, etc (1.4C), Name of publisher, distributor, etc. (1.4D), Statement of function of publisher, distributor, etc (1.4E), Date of publication, distribution, etc (1.4F), and Place of manufacture, name of manufacturer, date of manufacture (1.4G). RAD presents these as an either–or: use 1.4B (aggregate or unpublished items) or 1.4C-G (published items). RAD formats 1.4C-G as a single statement with punctuation rules for separatng elements. These can be implemented as single publication events, though with some loss of RAD specificity.

Note that RAD includes 2 Note elements (1.8B8 and 1.8B8a) that allows describers to distinguish dates of creation vs dates of accumulation. This distinction can be incorporated in the Type (of event) field.

Physical description area

Option 1: separate Physical description area div

Option 2: incorporate into an expanded Identity area div

Option 3: extent data moved to separate table

This div corresponds to RAD area 1.5. Where ISAD(G) has 1 element (4.5.1 Extent and medium), RAD has 4: Extent of descriptive unit (1.5B), Other physical details (1.5C), Dimensions (1.5D), and Accompanying material (1.5E). Note, however, that in RAD the elements are concatenated into to a single statement, using punctuation rules to separate elements. Each description can have then multiple statements. E.g.:

• 16 photographs : b&w ; 6 x 6 cm + 1 identification key
• 82 maps : col. ; 55 x 79 cm or smaller, on sheets 73 x 90 cm or smaller + 1 index map

There are several options for implementing.

Opption 1

• Map all RAD elements to the single Qubit Extent and medium field.
• Leave it to the user to include RAD-compliant content / formatting.
• Some loss of RAD specificity (e.g. can't differentiate Dimensions from Other physical details when outputting as EAD).

Option 2

• Same as option 1, except move Extent and medium field to Identity area div.
• Eliminate Physical description area as separate div since it contains only 1 field.

Option 3

• Separate extent data from the information_object to its own table.
• 1 extent record = 1 extent statement about 1 descriptive unit.
• Allows multiple extent statements to be registered to the same description.
• Structure extent record with various fields along RAD or other lines.
• This model would also be useful in the ISAD(G) template and generally would help automate calculating extents up the hierarchy of description.