Difference between revisions of "Template:Classic RAD"

From ICA-AtoM
Jump to navigation Jump to search
 
(44 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
[[Main Page]] > [[BCAUL pilot project]] > [[Templates]]
 
[[Main Page]] > [[BCAUL pilot project]] > [[Templates]]
  
{| style="width:100%; border="0"
+
{| style="width: 100%; border: 0"
  
 
|-valign="top"  
 
|-valign="top"  
  
| style="width=50%; border: 1px solid rgb(255, 201, 201); padding: 0.5em 1em 1em; color: rgb(0, 0, 0); background-color: rgb(255, 243, 243);" |  
+
| style="width: 500px; border: 1px solid rgb(255, 201, 201); padding: 0.5em 1em 1em; color: rgb(0, 0, 0); background-color: rgb(240, 240, 255);" |  
  
'''Template: Classic RAD'''
+
=== Classic RAD template ===
*Data entry template following the Canadian ''Rules for Archival Description''
 
*Document status: in progress
 
  
| style="width:50%; border: 1px solid rgb(198, 201, 255); padding: 0.5em 1em 1em; color: rgb(0, 0, 0); background-color: rgb(240, 240, 255);" |
+
''Document status: draft (3 Sep 2008)''
  
[[Template: Classic RAD|Overview]]
 
  
[[Template: Classic RAD - Title|Title and statement of responsibility area]]
+
Related documents:
 +
*[[Template: RAD ISAD(G)ed]]
 +
*[[Template: RAD2]]
  
[[Template: Classic RAD - Edition|Edition area]]
 
  
[[Template: Classic RAD - Class specific|Class of material specific details area]]
+
| style="width: 500px; border: 1px solid rgb(198, 201, 255); padding: 0.5em 1em 1em; color: rgb(0, 0, 0); background-color: rgb(255, 243, 243);" |  
  
[[Template: Classic RAD - Physical description|Physical description area]]
+
'''Contents'''
  
[[Template: Classic RAD - Publisher's series|Publisher's series area]]
+
[[#Overview|Overview]]
  
[[Template: Classic RAD - Archival|Archival description area]]
+
[[#Identity area|Identity area]]
  
[[Template: Classic RAD - Notes|Notes area]]
+
[[#Title and statement of responsibility area|Title and statement of responsibility area]]
  
[[Template: Classic RAD - Standard number|Standard number area]]
+
[[#Edition area|Edition area]]
  
[[Template: Classic RAD - Common|Control area | Digital object | Storage location]]
+
[[#Class of material specific details area|Class of material specific details area]]
  
 +
[[#Creation context|Creation context]]
 +
 +
[[#Physical description area|Physical description area]]
 +
 +
[[#Publisher's series area|Publisher's series area]]
 +
 +
[[#Archival description area|Archival description area]]
 +
 +
[[#Notes area|Notes area]]
 +
 +
[[#Standard number area|Standard number area]]
 +
 +
[[#Control area / Digital object / Storage location|Control area / Digital object / Storage location]]
 
|}
 
|}
  
Line 40: Line 51:
 
[[Image:tmplClassicRADStructure1.png|500px|right|thumb|Divs used to organize data entry screen]]
 
[[Image:tmplClassicRADStructure1.png|500px|right|thumb|Divs used to organize data entry screen]]
  
This version of the RAD template follows RAD's ''areas of description'' closely. The divs that structure the data entry screen are drawn from RAD areas, with additional divs to handle Qubit-required fields / implementations. RAD contains a number of elements that have no ISAD(G) or Qubit analogs. There are two basic approaches for handling these:
+
The purpose of this template is to provide an interface that mirrors as closely as possible 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:
 
#Create custom fields via the Qubit '''property''' table; or
 
#Create custom fields via the Qubit '''property''' table; or
 
#Map RAD elements onto existing Qubit fields, relying on the Qubit '''note''' and '''event''' tables to handle exceptions.
 
#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.
 
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.
 +
 +
 +
<br clear="right">
 +
 +
== Identity area ==
 +
 +
[[Image:tmplClassicRADIdentity1.png|500px|right|thumb|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.
 +
 +
 +
<br clear="right">
 +
== Title and statement of responsibility area ==
 +
 +
[[Image:tmplClassicRADTitle1.png|500px|right|thumb|Option 1: custom fields for each RAD title element]]
 +
 +
[[Image:tmplClassicRADTitle2.png|500px|right|thumb|Option 2: multiple title handled by separate title table]]
 +
 +
[[Image:tmplClassicRADIdentity1.png|500px|right|thumb|Option 3: title handled by Identity area]]
 +
 +
[[Image:tmplClassicRADIdentity3.png|500px|right|thumb|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''.
 +
*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.
 +
 +
 +
<br clear="right">
 +
 +
== Edition area ==
 +
 +
[[Image:tmplClassicRADEdition1.png|500px|right|thumb|Edition area: option 1]]
 +
 +
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.
 +
 +
 +
<br clear="right">
 +
 +
== Class of material specific details area ==
 +
 +
[[Image:tmplClassicRADClassMaterialSpecific1.png|500px|right|thumb|Option 1: separate div displaying each field]]
 +
 +
[[Image:tmplClassicRADClassMaterialSpecific2.png|500px|right|thumb|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.
 +
 +
 +
<br clear="right">
 +
== Creation context ==
 +
 +
[[Image:tmplClassicRADCreationContext1.png|500px|right|thumb|Option 1: Creation context div]]
 +
 +
[[Image:tmplClassicRADArchivalDescription2.png|500px|right|thumb|Option 2: Move to Archival description area]]
 +
 +
This div corresponds roughly to RAD area 1.4, ''Dates of creation, publication, distribution, etc''. Where ISAD(G) has 1 date element (3.1.2), RAD has  5: ''Dates of creaton'' (1.4D), ''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). In addition, there are 2 RAD note elements (1.8B8 and 1.8Ba) that permit distinguishing dates of creation vs dates of accumulation.
 +
 +
Note, however, that RAD presents the date elements in terms of an either-or: use '''either''' 1.4B (for aggregate-level descriptions or at the item level for unpublished material) '''or''' 1.4C-G (published items). RAD formats 1.4C-G as a single statement with punctuation rules for separatng elements.
 +
 +
 +
'''Option 1'''
 +
*Implement as Qubit '''events'''.
 +
*Include an ''Event type'' field to allow user to select different type of event (e.g. Created, Accumulated, Published, Broadcast etc).
 +
*Include ''Admin histories'' for each '''actor''' registered as a creator.
 +
 +
 +
'''Option 2'''
 +
*Same implementation as option 1, but move to ''Archival description area'' div (where the RAD ''Admin history / bio sketch'' element resides).
 +
*Eliminate as a separate div.
 +
 +
 +
<br clear="right">
 +
 +
== Physical description area ==
 +
 +
[[Image:tmplClassicRADPhysicalDescription1.png|500px|right|thumb|Option 1: separate Physical description area div]]
 +
 +
[[Image:tmplClassicRADPhysicalDescription2.png|500px|right|thumb|Option 2: incorporate into an expanded Identity area div]]
 +
 +
[[Image:tmplClassicRADPhysicalDescription3.png|500px|right|thumb|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'' or ''Archival description 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.
 +
 +
 +
<br clear="right">
 +
 +
== Publisher's series area ==
 +
 +
[[Image:tmplClassicRADPublishersSeries1.png|500px|right|thumb|Option 1: implement as custom fields]]
 +
 +
[[Image:tmplClassicRADPublishersSeries2.png|500px|right|thumb|Option 2: implement as Qubit notes]]
 +
 +
This div corresponds to RAD area 1.6. It applies only at the item level for information relating to the publisher's or artist's series to which an item belongs. It contains 5 elements: ''Title proper of publisher's series'' (1.6B), ''Parallel titles of publisher's series'' (1.6C), ''Other title information of publisher's series'' (1.6D), ''Statement of responsibility relating to publisher's series'' (1.6E), and ''Numbering with publisher's series'' (1.6F). There is in addition one related RAD ''Note'' (1.8B10, ''Publisher's series'').
 +
 +
None of these elements have ISAD(G) or Qubit equivalents. They can be implemented either as custom fields or adpated to Qubit '''notes'''.
 +
 +
 +
'''Option 1'''
 +
*Use Qubit '''property''' records to store field name and values.
 +
*Use a '''getRADPublishersSeries()''' method to get the values on the [[View screen]] in a single statement formatted by RAD punctuation rules.
 +
 +
 +
'''Option 2'''
 +
*Map RAD Publisher series elements to Qubit '''notes''' (type = "Publisher's series note").
 +
*Retain as separate div with drop-down to register notes as needed.
 +
 +
 +
'''Option 3'''
 +
*Same as option 3, but eliminate as a separate div since data can be managed in the ''Notes'' div.
 +
 +
 +
'''Option 4'''
 +
*Do not even try to map these fields as they are rarely used.
 +
*Rely on RAD 1.8B10 (''Publisher's series note'') for any information relating to publisher's series.
 +
*Eliminate this area as a separate div since data can be handled by the ''Notes'' div.
 +
 +
 +
<br clear="right">
 +
== Archival description area ==
 +
 +
[[Image:tmplClassicRADArchivalDescription1.png|500px|right|thumb|Option 1: Admin history field moved out of div]]
 +
 +
[[Image:tmplClassicRADArchivalDescription2.png|500px|right|thumb|Option 2: Dates of creation moved into div]]
 +
 +
[[Image:tmplClassicRADArchivalDescription3.png|500px|right|thumb|Option 3: Dates and Extent fields moved into div]]
 +
 +
This div corresponds to RAD area 1.7. This area contains 3 elements: ''Administrative history / biographical sketch'' (1.7B), ''Custodial history'' (1.7C), and ''Scope and content'' (1.7D). Each of these has clear ISAD(G) equivalent. Given the way Qubit implements date ranges (as '''events''' linked to '''actors'''), it makes sense to display the ''Admin history'' field with the creation events / dates.
 +
 +
 +
'''Option 1'''
 +
*Move ''Admin history / bio sketch'' to the ''Creation context'' area.
 +
 +
 +
'''Option 2'''
 +
*Move the date range / creation event fields to this div, eliminating the RAD ''Dates of creation, publication, distribution area'' div.
 +
 +
 +
'''Option 3'''
 +
*Same as option 2, but also move ''Extent'' to this div, eliminating the RAD ''Phyiscal description area'' div (since this has only the ''Extent'' field in it).
 +
 +
 +
<br clear="right">
 +
== Notes area ==
 +
 +
[[Image:tmplClassicRADNotes1.png|500px|right|thumb|Notes area: Qubit fields where equivalents exist, Qubit notes for others]]
 +
 +
This div corresponds to RAD area 1.8, ''Notes area''. RAD includes 30 elements as distinct types of notes in this area. A number of which have analogs in ISAD(G) where they are treated as descriptive elements in their own right rather than "notes". These elements should be mapped to the corresponding Qubit fields, using Qubit '''notes''' only for RAD notes that have no direct equivalents.
 +
 +
 +
<br clear="right">
 +
== Standard number area ==
 +
 +
[[Image:tmplClassicRADStandardNumber1.png|500px|right|thumb|Option 1: custom field, own div]]
 +
 +
[[Image:tmplClassicRADStandardNumber2.png|500px|right|thumb|Option 2: custom field, moved to Identity area div]]
 +
 +
This div corresponds to RAD area 1.9, ''Standard number area''. It includes only one element: ''Standard number'' (1.9B), applicable only at the item level for international standard numbers (e.g. ISBNs, ISSNs).
 +
 +
 +
'''Option 1'''
 +
*Create a custom Qubit field as needed ('''property''' table, name="Standard number" value-" ").
 +
 +
 +
'''Option 2'''
 +
*Same as option 1, but move to ''Identity area'' and eliminate ''Standard number area'' as a separate div.
 +
 +
 +
'''Option 3'''
 +
*Eliminate both ''Standard number'' field and div.
 +
*Map to Qubit ''Identifier'' when needed, using Qubit '''note''' to elaborate if required.
 +
 +
 +
<br clear="right">
 +
 +
== Access points ==
 +
 +
[[Image:tmplClassicRADAccessPoints1.png|500px|right|thumb|Option 1: restrict to RAD-recognized types of access point]]
 +
 +
[[Image:tmplClassicRADAccessPoints2.png|500px|right|thumb|Option 2: implement as in ISAD(G) template]]
 +
 +
RAD chapter 21 deals with access points. RAD recognizes the following types of access point (see 21.0A3):
 +
*''Provenance'': name of the person(s), family (ies), or corporate body (bodies) responsible for the creation and/or accumulation and use of the unit being described.
 +
*''Author'': person(s), corporate body(ies) responsible for the form and intellectual or artistic content of the unit being described, if different from the creator of that unit.
 +
*''Other non-subject'': e.g. name(s) of custodians, offices held by a person, persons holding office, persons comprising a family, title.
 +
 +
BCAUL supports ''Name'' access points. Archives Canada accommodates ''Subjects'' in addition to ''Names''.
 +
 +
 +
'''Option 1'''
 +
*Restrict access points to forms explicitly recognized by RAD.
 +
*Limit access points to names of Qubit '''actors'''.
 +
*Include field for specifying type of access point (e.g. "Provenance", "Author", "Custodian", "Officer", "Family member").
 +
 +
 +
'''Option 2'''
 +
*Implement the same as ISAD(G) template, i.e. allowing ''Name'', ''Place'' and ''Subject'' access points with no qualifying "types".
 +
 +
 +
<br clear="right">
 +
 +
== Control area / Digital object / Storage location ==
 +
 +
[[Image:tmplClassicRADCommon1.png|500px|right|thumb|Implement as in ISAD(G) template]]
 +
 +
These divs contains elements that have no RAD analogs (for record control) or fields required for Qubit-specific implementations (digital object and physical object storage). These can all be implemented the same as the ISAD(G) template.

Latest revision as of 14:28, 3 September 2008

Please note that ICA-AtoM is no longer actively supported by Artefactual Systems.
Visit https://www.accesstomemory.org for information about AtoM, the currently supported version.

Main Page > BCAUL pilot project > Templates

Classic RAD template

Document status: draft (3 Sep 2008)


Related documents:


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

The purpose of this template is to provide an interface that mirrors as closely as possible 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.
  • 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: option 1

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

Option 1: Creation context div
Option 2: Move to Archival description area

This div corresponds roughly to RAD area 1.4, Dates of creation, publication, distribution, etc. Where ISAD(G) has 1 date element (3.1.2), RAD has 5: Dates of creaton (1.4D), 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). In addition, there are 2 RAD note elements (1.8B8 and 1.8Ba) that permit distinguishing dates of creation vs dates of accumulation.

Note, however, that RAD presents the date elements in terms of an either-or: use either 1.4B (for aggregate-level descriptions or at the item level for unpublished material) or 1.4C-G (published items). RAD formats 1.4C-G as a single statement with punctuation rules for separatng elements.


Option 1

  • Implement as Qubit events.
  • Include an Event type field to allow user to select different type of event (e.g. Created, Accumulated, Published, Broadcast etc).
  • Include Admin histories for each actor registered as a creator.


Option 2

  • Same implementation as option 1, but move to Archival description area div (where the RAD Admin history / bio sketch element resides).
  • Eliminate as a separate div.



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 or Archival description 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.



Publisher's series area

Option 1: implement as custom fields
Option 2: implement as Qubit notes

This div corresponds to RAD area 1.6. It applies only at the item level for information relating to the publisher's or artist's series to which an item belongs. It contains 5 elements: Title proper of publisher's series (1.6B), Parallel titles of publisher's series (1.6C), Other title information of publisher's series (1.6D), Statement of responsibility relating to publisher's series (1.6E), and Numbering with publisher's series (1.6F). There is in addition one related RAD Note (1.8B10, Publisher's series).

None of these elements have ISAD(G) or Qubit equivalents. They can be implemented either as custom fields or adpated to Qubit notes.


Option 1

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


Option 2

  • Map RAD Publisher series elements to Qubit notes (type = "Publisher's series note").
  • Retain as separate div with drop-down to register notes as needed.


Option 3

  • Same as option 3, but eliminate as a separate div since data can be managed in the Notes div.


Option 4

  • Do not even try to map these fields as they are rarely used.
  • Rely on RAD 1.8B10 (Publisher's series note) for any information relating to publisher's series.
  • Eliminate this area as a separate div since data can be handled by the Notes div.



Archival description area

Option 1: Admin history field moved out of div
Option 2: Dates of creation moved into div
Option 3: Dates and Extent fields moved into div

This div corresponds to RAD area 1.7. This area contains 3 elements: Administrative history / biographical sketch (1.7B), Custodial history (1.7C), and Scope and content (1.7D). Each of these has clear ISAD(G) equivalent. Given the way Qubit implements date ranges (as events linked to actors), it makes sense to display the Admin history field with the creation events / dates.


Option 1

  • Move Admin history / bio sketch to the Creation context area.


Option 2

  • Move the date range / creation event fields to this div, eliminating the RAD Dates of creation, publication, distribution area div.


Option 3

  • Same as option 2, but also move Extent to this div, eliminating the RAD Phyiscal description area div (since this has only the Extent field in it).



Notes area

Notes area: Qubit fields where equivalents exist, Qubit notes for others

This div corresponds to RAD area 1.8, Notes area. RAD includes 30 elements as distinct types of notes in this area. A number of which have analogs in ISAD(G) where they are treated as descriptive elements in their own right rather than "notes". These elements should be mapped to the corresponding Qubit fields, using Qubit notes only for RAD notes that have no direct equivalents.



Standard number area

Option 1: custom field, own div
Option 2: custom field, moved to Identity area div

This div corresponds to RAD area 1.9, Standard number area. It includes only one element: Standard number (1.9B), applicable only at the item level for international standard numbers (e.g. ISBNs, ISSNs).


Option 1

  • Create a custom Qubit field as needed (property table, name="Standard number" value-" ").


Option 2

  • Same as option 1, but move to Identity area and eliminate Standard number area as a separate div.


Option 3

  • Eliminate both Standard number field and div.
  • Map to Qubit Identifier when needed, using Qubit note to elaborate if required.



Access points

Option 1: restrict to RAD-recognized types of access point
Option 2: implement as in ISAD(G) template

RAD chapter 21 deals with access points. RAD recognizes the following types of access point (see 21.0A3):

  • Provenance: name of the person(s), family (ies), or corporate body (bodies) responsible for the creation and/or accumulation and use of the unit being described.
  • Author: person(s), corporate body(ies) responsible for the form and intellectual or artistic content of the unit being described, if different from the creator of that unit.
  • Other non-subject: e.g. name(s) of custodians, offices held by a person, persons holding office, persons comprising a family, title.

BCAUL supports Name access points. Archives Canada accommodates Subjects in addition to Names.


Option 1

  • Restrict access points to forms explicitly recognized by RAD.
  • Limit access points to names of Qubit actors.
  • Include field for specifying type of access point (e.g. "Provenance", "Author", "Custodian", "Officer", "Family member").


Option 2

  • Implement the same as ISAD(G) template, i.e. allowing Name, Place and Subject access points with no qualifying "types".



Control area / Digital object / Storage location

Implement as in ISAD(G) template

These divs contains elements that have no RAD analogs (for record control) or fields required for Qubit-specific implementations (digital object and physical object storage). These can all be implemented the same as the ISAD(G) template.