The GC RMAP employs an alphabetical listing of elements in order to promote flexibility in the combining of elements and the interpretation of relationships among elements. It is a "flat" set in that it does not invoke parent-child (i.e. hierarchical) relationships or nesting (i.e. sub-division) of elements. All elements are considered to be at the same level. Institutions may wish to group elements in various ways in order to emphasize themes or functionality unique to their environments. However, all 50 elements must retain their status of element and one element must not be subsumed or placed under another, for example in a parent-child (i.e. hierarchical) relationship.
The GC RMAP is a 'flat' set in that it does not invoke parent-child relationships or nesting of elements.
Seven of the GC RMAP elements are based on Dublin Core descriptive metadata elements. Creator, Description, Identifier, Language, Subject, Title and Type are adopted from the Dublin Core; such adoption acknowledges that the semantics of the seven elements are useable within a records management domain and hence, alleviates the need to declare locally defined descriptive elements. Each is described in Section 8 using the same format as those for other GC RMAP elements except that the Dublin Core definitions and comments are cited. References to Dublin Core Metadata Initiative (DCMI) namespaces are used to differentiate Dublin Core elements from others; note, however, that the URIs listed do not have to resolve to a Web location with content but instead act as a unique identifier for the element.
Although the Dublin Core definitions refer to "resources", for the purposes of the records management domain and the GC RMAP in particular, use of these elements shall be constrained to records and/or files only.
In some instances, the names of elements declared within the GC RMAP appear to be synonymous with other Dublin Core elements (e.g. GC RMAP Data Format and DC Format) or element refinements (e.g. Access Rights); however, the GC RMAP elements are used for records management administration or management, and hence cannot adopt the semantic of the Dublin Core descriptive elements.
The GC RMAP uses the principle of metadata inheritance between levels of aggregation or classification (i.e. record and file).
Metadata inheritance refers to the association of metadata from a higher classification level with the metadata of a lower classification level. The inherited metadata may be either included as part of the metadata of the lower level or it may be referred to by the lower level to trigger a life cycle event.
For instance, the retention schedule of a record (lower level) will usually be determined by the retention schedule metadata applied at the file level (higher level).
Metadata inheritance is intended to improve efficiency by reducing the requirement to re-create metadata at each level of aggregation. Metadata inheritance also facilitates the grouping and tracking of like records and files to better ensure the entirety of records collections are managed throughout their life cycle.
How the inherited metadata is associated with the lower level (e.g. transmitted, linked) is determined by the application using the metadata (e.g. a records management system). However, inherited metadata, where possible, should be automatically associated within a file or record.
Element names are sourced from the GC RMMS. The lowerCamelCase11 convention used to format the names of GC declared elements is based on best practices recommended within the Treasury Board of Canada, Secretariat, Government of Canada Metadata Implementation Guide for Web Resources and on syntactical rules for the construction of element names within XML.
The names of Dublin Core elements are under the ownership and authority of the Dublin Core Metadata Initiative and are integrated as is into the GC RMAP.
The character strings representing the element names must remain immutable. This is especially important for translating the human readable GC RMAP document into a machine readable format (e.g. XML) and for ensuring interoperability. Changing the characters in element names will result in unpredictable behaviour in software applications.
An encoding scheme may control either the format or semantics used to record the value of an element or the list of allowable terms for the value of an element. A controlled vocabulary is an encoding scheme which controls both format and semantics.
Controlled vocabularies help users to describe resources in a consistent manner, which fosters two outcomes:
Wherever possible, the GC RMAP identifies the use of a specific controlled vocabulary for an element. The GC RMAP encourages institutions to consider using a previously registered GC controlled vocabulary whenever possible. If institutions discover that terms required for their particular application are not included in a registered list, then the institutions are asked to consider approaching the owners of the registered controlled vocabularies to have their terms added. This will promote and strengthen the use of standardized vocabularies throughout the GC. Only in the case where the institution believes their list of terms is significantly different or is used for a purpose other than any previously registered vocabulary should they consider developing an institution-specific controlled vocabulary. Upon further reflection and comparison, controlled vocabularies developed within the confines of individual institutions may in fact share many of the same attributes and as such may be candidates for consolidation into one standardized registered vocabulary for use throughout the GC; semantic understanding and interoperability will benefit.
For some elements, a choice from more than one controlled vocabulary may be indicated. If one of the choices states "institution-specific scheme", the value for the metadata element may be taken from a controlled vocabulary developed by the institution. If "institution-specific scheme" is the only value within the encoding scheme attribute, the value for the element must be taken from a controlled vocabulary developed, and ideally, registered, by the institution. The identification by name of the institution-specific controlled vocabulary may be documented in an institution-specific records management application profile (see Section 5 for additional information.)
The GC RMAP strongly advocates the use of registered controlled vocabularies and, if institutions take the path of developing their own institution-specific encoding schemes, encourages the institutions to register their controlled vocabularies once developed. Information on currently registered controlled vocabularies for use within the GC and on the registration process itself may be found at the Library and Archives Canada site: www.collectionscanada.gc.ca/government/controlled-vocabularies/index-e.html
Further guidance on controlled vocabularies may be found in the following document: Controlled Vocabularies Sub-Group, Government On-Line Metadata Working Group, Guide to the Development and Maintenance of Controlled Vocabularies in the Government of Canada, July 8, 2005.
The linkages attribute specifies the names of other elements precipitated by the following circumstances:
The following graphic illustrates the relationship among elements. File Code may be considered a "kingpin" element in that it is linked indirectly to many other elements via the few to which is it linked directly.
Figure 1: File Code Linkages
Details of the relationship are explained in the current element's comments and guidance section.
The identification of a linkage is heavily driven by records management principles (i.e. by the business of doing records management) and may result in significant impact on the development and implementation of an EDRMS.
Linkages does not apply in cases where one value may be used to populate more than one element (such as when the name of the Creator in some circumstances may also apply to Trustee Individual Name).
It is important to note that linkages is at the element level in that the attribute shows dependencies and relationships between or among elements. Relationships between or among resources are to be addressed by the element Compound Record Links.
For a summary of linkages, please refer to Appendix E.
Three levels for obligation are specified:
The determination of an element's obligation level is based on the following decision tree:
The table below categorizes elements based on their obligation.
The following information is useful for the interpretation of the table:
M = Mandatory MA = Mandatory, if applicable O = Optional
* Indicates the element is mandatory at record level or mandatory at file level. Must be mandatory for at least one level; may be mandatory at both levels.
** Indicates the element is mandatory, if applicable, at record level or mandatory, if applicable, at file level. Must be mandatory, if applicable, for at least one level; may be mandatory, if applicable, at both levels.
|Element Reference Number||Element||Record Level||File Level|
|8.3||Agent Individual Identifier||X||M||X||M|
|8.5||Agent Institution Name||X||M||X||M|
|8.34||Office of Primary Interest||X||M*||X||M*|
|8.46||Trustee Individual Name||X||M||-||-|
|Mandatory, if Applicable Elements|
|8.12||Compound Record Links||X||MA||-||-|
|8.14||Container From Date||-||-||X||MA|
|8.15||Container To Date||-||-||X||MA|
|8.40||Retention Trigger Date||X||MA**||X||MA**|
|8.4||Agent Individual Name||X||O||X||O|
|8.6||Agent Institutional Entity||X||O||X||O|
|8.7||Agent Position Title||X||O||X||O|
|8.47||Trustee Institution Name||X||O||-||-|
|8.48||Trustee Institutional Entity||X||O||-||-|
Many, but not all, of the elements in the GC RMAP may be used more than once to record multiple instances of information about a resource. For example, if a record has more than one creator, the Creator element may be repeated to list separately each one. It is important to note the following two caveats:
Or, if additional information about each Creator is to be recorded, then:
Creator = "Smith, Joe; Indian and Northern Affairs Canada; Project Manager" Creator = "Jones, Mary; External Consultant"
The choice of a delimiter (e.g. a semicolon) to separate parts of a single entry is an EDRMS-specific concern or a local implementation decision as is the convention of structuring the information within the element if the GC RMAP does not specify an entry convention.
Each element table indicates if the assigned metadata value may be altered before and after the resource is locked. In all cases, modifiable pertains to altering the metadata record only and not the content of the resource itself.
This application profile does not provide guidance on changing the value of a metadata element if the metadata value has inadvertently been entered incorrectly. The decision to modify an incorrect value is left to the individual institution. Instead, the GC RMAP provides guidance on whether a metadata value may be altered based on records management principles.
Values for metadata should be in the language of the resource being described and additionally in at least one of the two official languages, if necessary.
Language of the values for metadata should not be confused with the value for the element Language, which describes the language in which the resource itself is expressed.
Element labels may be changed and/or translated for use on end-user screens, but the character strings representing the element names are immutable.
11. The practice of writing multiple words together without spaces to form one word with the first letter of each of the multiple words capitalized. In lowerCamelCase, the first letter of the compound word is in lower case.
12. Security Clearance applies to the individual only and not to the record level or file level hence values do not appear in the cells in this table. However, it is a mandatory element for records management purposes. Refer to Security Clearance table within the body of the text for additional information.