Government

Previous | Table of Contents | Next

4. Characteristics of the GC RMAP

4.1 Metadata model

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.

4.2 Adoption of Dublin Core 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.

4.3 The principle of metadata inheritance

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.

4.4 Element names

Element names are sourced from the GC RMMS. The lowerCamelCase¹¹ 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.

4.5 Encoding schemes

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:

• It allows uses of those resources to find information efficiently; and,
  
  
• It allows records managers to separate unlike resources and to bring together similar resources.

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.

4.6 Linkages

The linkages attribute specifies the names of other elements precipitated by the following circumstances:

• The value of the current element is dependent upon the value of another element (e.g. the value of File Name will be dependent upon the value of File Code);
  
  
• The processing of the current element is dependent upon the value of another element (e.g. the processing of a final Disposition Action is dependent upon the identification of a Disposition Authority)
  
  
• The current element is interrelated with other elements (e.g. the strong relationship among Security Clearance, Sensitivity and Access Rights or the relationship among the Agent and Event elements to form a management and event history log)
  
  
• The value of the current element impacts the value or processing of another element (e.g. an ATIP request may result in the suspension or freeze/hold of the Retention Period which would then affect disposition processing)

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.

4.7 Obligation

Three levels for obligation are specified:

• Mandatory:
  The element must be used in a records management application.
  
  
• Mandatory, if applicable:
  The element must be used in a records management application if a condition exists that triggers the necessity to capture a metadata value. For example, Releasable To becomes a mandatory element when the security of the content of a record or file must be managed in terms of to whom the record or file can be released. For instances where this is not a concern, the element Releasable To would not apply.
  
  
• Optional:
  The element is not deemed crucial to records management. Consequently, the element would only be included in a records management application upon the discretion of the individual institution.

The determination of an element's obligation level is based on the following decision tree:

• If the MGI Policy specifies a requirement for an element, that element is deemed mandatory or mandatory, if applicable.
  
  
• If ISO 15489-1 and/or ISO 23081-1 prescribe the creation and usage of an element, as indicated in the rationale attribute of each element table, that element is deemed mandatory. In cases where the ISO prescribes the creation and usage of an element that has a conditional characteristic, that element is deemed mandatory, if applicable.
  
  
• All other elements are optional.

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
		Applicable	Obligation	Applicable	Obligation
Mandatory Elements
8.1	Access Rights	X	M	X	M
8.2	Addressee	X	M	-	-
8.3	Agent Individual Identifier	X	M	X	M
8.5	Agent Institution Name	X	M	X	M
8.8	Agent Role	X	M	X	M
8.9	Aggregation	X	M	X	M
8.16	Creator	X	M	-	-
8.17	Data Format	X	M	-	-
8.19	Disposition Action	X	M*	X	M*
8.20	Disposition Authority	-	-	X	M
8.23	Essential Status	X	M*	X	M*
8.24	Event Date/Time	X	M	X	M
8.26	Event Type	X	M	X	M
8.27	File Code	X	M*	X	M*
8.28	File Name	X	M*	X	M*
8.30	Format Medium	X	M	-	-
8.31	Identifier	X	M	X	M
8.32	Language	X	M	-	-
8.33	Location	X	M*	X	M*
8.34	Office of Primary Interest	X	M*	X	M*
8.35	Record Date	X	M	-	-
8.36	Record Locked	X	M	-	-
8.38	Retention Period	X	M*	X	M*
8.39	Retention Trigger	X	M*	X	M*
8.41	Security Clearance12	-	-	-	-
8.42	Sensitivity	X	M	X	M
8.45	Title	X	M	-	-
8.46	Trustee Individual Name	X	M	-	-
Mandatory, if Applicable Elements
8.12	Compound Record Links	X	MA	-	-
8.13	Container	-	-	X	MA
8.14	Container From Date	-	-	X	MA
8.15	Container To Date	-	-	X	MA
8.37	Releasable To	X	MA	X	MA
8.40	Retention Trigger Date	X	MA**	X	MA**
Optional Elements
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.10	Approved By	X	O	-	-
8.11	Approved Date	X	O	-	-
8.18	Description	X	O	X	O
8.21	Encryption Description	X	O	-	-
8.22	Encryption Status	X	O	-	-
8.25	Event Description	X	O	X	O
8.29	Format Extent	X	O	-	-
8.43	Subject	X	O	-	-
8.44	Supplemental Markings	X	O	X	O
8.47	Trustee Institution Name	X	O	-	-
8.48	Trustee Institutional Entity	X	O	-	-
8.49	Type	X	O	-	-
8.50	Usage Conditions	X	O	X	O

4.8 Occurrence

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:

1. Repeatability pertains to using an element more than once in describing the same resource at a single point in time. It does not pertain to recording in an element information about a series of events or actions that occur over the life cycle of a resource. For example, elements comprising management and event history (e.g. Event Type) are not repeatable because only one action can be taken on a resource at any one point in time. However, multiple instances of elements comprising management and event history will be recorded over the life cycle of a resource.
   
   
2. Elements may not be repeated to record additional information about the value placed in the first instance of the element. For example, if an individual's name is recorded in the Creator element, the element may not be repeated to then record information about that person (e.g. the name of the individual's institution, the position title of the individual, etc.) The Creator element would only be repeated if there was more than one creator of the resource. If desired, any other information about the individual would have to be recorded in the same instance of the element.

a. The following is not permitted:

Creator = "Smith, Joe"

Creator = "Indian and Northern Affairs Canada"

Creator = "Project Manager"

Creator = "Jones, Mary"

Creator = "External Consultant"

b. The following is permitted:

Creator = "Smith, Joe"

Creator = "Jones, Mary"

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.

4.9 Modifiable

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.

4.10 Language

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.

Previous | Table of Contents | Next