Difference between revisions of "Template:Classic RAD (1)"
| Line 4: | Line 4: | ||
| − | This version of the RAD template follows RAD's ''areas of description'' closely. It differs from [[Template: Classic RAD (2)|Classic RAD (2)]] in the way it handles RAD elements that have no direct ISAD(G) or Qubit | + | == Structure == |
| + | |||
| + | [[Image:ClassicRAD1_Summary.png|500px|right|thumb|Divs used to organize data entry screen]] | ||
| + | |||
| + | |||
| + | This version of the RAD template follows RAD's ''areas of description'' closely. It differs from [[Template: Classic RAD (2)|Classic RAD (2)]] in the way it handles RAD elements that have no direct ISAD(G) or Qubit analogs. The general approach in this implementation is to create custom fields (via records in the Qubit ''property'' table) for RAD elements that have no ISAD(G) equivalent. | ||
*'''Advantage''': descriptions are more fully RAD-compliant, data is more easily segregated into RAD elements with little loss of RAD specificity. | *'''Advantage''': descriptions are more fully RAD-compliant, data is more easily segregated into RAD elements with little loss of RAD specificity. | ||
| Line 10: | Line 15: | ||
*'''Disadvantage''': requires much back-end customization to implement fields that are little-used even in RAD environments. | *'''Disadvantage''': requires much back-end customization to implement fields that are little-used even in RAD environments. | ||
| + | The divs that structure the data entry screen are drawn from RAD areas, with several others added to handle Qubit-specific fields / implementations. | ||
| − | |||
| − | |||
| − | |||
<br clear="right"> | <br clear="right"> | ||
Revision as of 17:04, 27 August 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 (1)
Document status: in progress
Structure
This version of the RAD template follows RAD's areas of description closely. It differs from Classic RAD (2) in the way it handles RAD elements that have no direct ISAD(G) or Qubit analogs. The general approach in this implementation is to create custom fields (via records in the Qubit property table) for RAD elements that have no ISAD(G) equivalent.
- Advantage: descriptions are more fully RAD-compliant, data is more easily segregated into RAD elements with little loss of RAD specificity.
- Disadvantage: requires much back-end customization to implement fields that are little-used even in RAD environments.
The divs that structure the data entry screen are drawn from RAD areas, with several others added to handle Qubit-specific fields / implementations.
Identity area
Title and statement of responsibility area
Edition area
Class of material specific details
Creation context
Physical description area
Publisher's series area
Archival description area
Notes area
Access points