Minnesota Recordkeeping Metadata Standard
IRM Standard 20, Version 1.2:
Title: Minnesota Recordkeeping Metadata Standard
Date Issued : April 2003
Effective date: April 2003
Table of Contents
F. Public Policy
H. Standard Requirements
K.1 Table of Element Inter-Relationships
K.2 Table of Element Mappings to the Dublin Core Metadata Element Set (DCMES) and the Minnesota Geographic Metadata Guidelines (MGMG)
K.3 Metadata Examples
K.4 Draft Implementation Models
K.5 Revisions to Standard
The Minnesota Recordkeeping Metadata Standard was developed to facilitate records management by government entities at any level of government. It shares many of its elements with other metadata standards, such as the Dublin Core and the Minnesota Geographic Metadata Guidelines set, but goes further to address such issues as access restrictions, data practices, and records retention and disposition, thereby enabling the practical implementation of statutory mandates for records management. As well, use of the standard brings many other benefits such as:
- facilitation of data sharing where authorized,
- enhanced efficiency with respect to location, evaluation, and retrieval of records, and
- guidance for consultants, vendors, and system designers.
The standard is comprised of twenty elements, ten of which are mandatory. State agencies should note that it is referenced as a "current standard" in the Minnesota Enterprise Technical Architecture under Chapter 4, "Data and Records Management Architecture."
Records management is a statutory obligation of every government entity in the state. As the Minnesota Enterprise Technical Architecture states, "Accurate and well-kept records, including those in electronic form, are critical to the State's ability to provide its services, present evidence, provide historical documentation, preserve its heritage, and allow its actions to be reviewed and audited. These records must be created, preserved, retained, and disposed of as required by law. . . . Records have a distinct legal and administrative status. This may not be true of all information and documents in an information system. Therefore, records must be managed as important resources with special requirements that may be distinct from other information resources." One tool to aid in the proper management of records is metadata.
Metadata is often defined as "data about data." To elaborate, it is descriptive information that facilitates management of, and access to, other information. A traditional example of metadata would be the bibliographic information found in card catalogs. Recordkeeping metadata facilitates such records management actions as discovery, preservation, and disposition. While optimum metadata for any particular record set may vary, such information often includes items like the name of the record creator, date and time of creation, record identifier, key words, location, and retention information. It can also give reference to applicable policies and laws like the Minnesota Government Data Practices Act and even specific sections within those documents.
Without adequate metadata, a number of records management problems can arise, particularly with respect to electronic records. To list a few examples, it may be difficult to: locate and evaluate records, pinpoint the official record when multiple copies exist, determine whether a record has been modified since its creation, determine who should have access to a record, and carry out the proper disposition of a record (e.g., archive, destroy) at the end of its retention period. Recordkeeping requirements and associated metadata are best designed into a system as part of its core functionality, not as a tacked-on afterthought.
Standardized recordkeeping metadata offers several benefits, including facilitating:
- the practical implementation of statutory records management mandates;
- proper access to records with respect to the requirements of the Minnesota Government Data Practices Act, Minnesota Court Rules, and other access restrictions;
- authorized data sharing within and across agencies;
- preservation of records within their retention period;
- efficient and timely disposition of records past their retention period;
- auditing of government activities;
- location and retrieval of records for agency use and public access;
- evaluation and use of records with respect to legal admissibility and evidence;
- cost reduction through elimination of redundancy and unnecessary storage; and
- standardized guidance for system developers, consultants, and vendors.
This standard is intended for information resource management executives and staff, records managers, librarians, and data practices compliance officials.
This standard is applicable to electronic recordkeeping systems or hybrid records management systems encompassing records in multiple formats such as paper and electronic. It accommodates both public records and records with restricted access. The standard is designed to be used by any Minnesota government entity at any level of government. State agencies should note that it is referenced as a "current standard" in the Minnesota Enterprise Technical Architecture under Chapter 4, "Data and Records Management Architecture" and act accordingly.
The Minnesota Recordkeeping Metadata Standard is designed to be flexible, meaning that it can be used in a variety of implementation settings, including hybrid systems where records exist in multiple formats (e.g., electronic and paper) and environments where specialized commercial software is employed for records management, content management, and/or content management purposes.
It does not prescribe rules for the order in which agencies should apply metadata elements to records either from a system or workflow perspective; these are decisions that should be guided by agencies' business rules. It is likely that metadata will accumulate over time for any particular record or record series, with many elements being automatically captured or input at the time of creation and others being added over time as appropriate. Many, but not all of the elements and sub-elements defined in the standard can be applied to a record more than once to allow for adequate description.
Extensibility is another feature of the standard. Several of the metadata elements and sub-elements allow agencies to extend the given value lists to accommodate their own unique business needs and environments. Additionally, agencies may add new elements or sub-elements as needed. If agencies anticipate the routine sharing of metadata with others, they may wish to coordinate such extensions with their partners.
Several elements of the Minnesota Recordkeeping Metadata Standard have counterparts in other metadata standards used by Minnesota government entities, particularly the Dublin Core Element Set (used to describe electronic information resources) and the Minnesota Geographic Metadata Guidelines (used to describe geospatial data sets). The relationship between these standards is summarized in table form in Section K, Appendix K.2 (Table of Element Mappings to the Dublin Core Metadata Element Set and the Minnesota Geographic Metadata Guidelines).
It should be noted that in many cases, agencies using other metadata standards will have mechanisms already in place for capturing many of the required recordkeeping metadata elements. For example, six of the ten mandatory elements have counterparts in both the Dublin Core Metadata Element Set and the Minnesota Geographic Metadata Guidelines.
The Minnesota Recordkeeping Metadata Standard is referenced as a "current standard" in the Minnesota Enterprise Technical Architecture under Chapter 4, "Data and Records Management Architecture." State agencies bound by the Architecture should reference that document for compliance requirements. There are no compliance requirements for other users of the standard.
The Minnesota Recordkeeping Metadata Standard is directly based upon the one developed by the National Archives of Australia (NAA), the Recordkeeping Metadata Standard for Commonwealth Agencies, version 1.0, May 1999 <http://www.naa.gov.au/Images/rkms_pt1_2_tcm2-1036.pdf>. The standard development committee is grateful to the NAA for the permission to revise and adopt that publication, and for the valuable advice and comments offered by that organization's staff.
Several Minnesota government entities participated in the development of this standard, which was coordinated by State Archives Department of the Minnesota Historical Society. The initial study committee included representatives from the Minnesota Supreme Court; the Minnesota State Archives; the Department of Administration; the Department of Revenue; the Department of Transportation; the Department of Natural Resources; the Department of Human Services; the Department of Economic Security; the Department of Labor and Industry; and the Department of Children, Families & Learning.
Participating on the standard development committee were representatives of: the Minnesota Supreme Court; the Minnesota State Archives; the Office of the Governor; the Office of Technology; the Legislative Reference Library; InterTech; the Department of Administration; the Department of Transportation; the Department of Employee Relations; the Department of Public Safety; the Department of Natural Resources; the Department of Economic Security; the Department of Children, Families & Learning; the City of Minneapolis; and the Minneapolis Community Development Agency.
Minnesota Historical Society, State Archives Department. Preserving and Disposing of Government Records. May 2008.
Minnesota Historical Society, State Archives Department. Trustworthy
Information Systems Handbook. Version 4, July 2002.
Minnesota Office of Enterprise Technology.
Minnesota Enterprise Technical Architecture. Revision 2.02, 8 September 2006.
Minnesota Foundations Project (Bridges). Best Practice Guidelines for Web Metadata. Emphasis on using the Dublin Core Metadata Element Set.
Minnesota Geospatial Information Office (MnGeo). Information on the Minnesota Geographic Metadata Guidelines (GIS metadata), the Minnesota Geographic Data Clearinghouse, and other products and services available at:
F. Public Policy
Minnesota Rules, Chapter 1205 (Department of Administration, Data Practices).
Minnesota Statutes, Chapter 13 (Minnesota Government Data Practices Act).
Minnesota Statutes, Chapter 15.10 (Records Delivered to Department Heads).
Minnesota Statutes, Chapter 15.17 (Official Records Act).
Minnesota Statutes, Chapter 138.17 (Government Records Act).
Minnesota Statutes, Chapter 138.163 (Preservation and Disposal of Government Records).
Minnesota Statutes, Chapter 325K (Minnesota Electronic Authentication Act).
Minnesota Statutes, Chapter 325L (Uniform Electronic Transactions Act).
Rules of Public Access to Records of the Judicial Branch (Minnesota Court Rules).
Not available online.
Any government entity at any level of government.
The process of identifying an individual, of verifying that the individual is who he or she claims to be.
Inktomi's Content Classification Engine, an add-on to the Inktomi search engine used by the State of Minnesota (http://search.state.mn.us). CCE provides a hierarchical display of browseable topics for easy searching. The terminology is primarily derived from LIV-MN.
In terms of Public Key Infrastructure technology, "A transformation of a message using an asymmetric cryptosystem such that a person having the initial message and the signer's public key can accurately determine: (1) whether the transformation was created using the private key that corresponds to the signer's public key; and (2) whether the initial message has been altered since the transformation was made." (Minnesota Statutes, Chapter 325K.01)
The translation of a record into a secret code.
"A record created, generated, sent, communicated, received, or stored by electronic means." (Minnesota Statutes, Chapter 325L.02)
Enterprise Technical Architecture:
"A logically consistent set of principles, practices, standards, and guidelines that are derived from business requirements and that guide the engineering of an organization's information systems and technical infrastructure." (Minnesota Enterprise Technical Architecture, Preface)
"Data, text, images, sounds, codes, computer programs, software, databases, or the like." (Minnesota Statutes, Chapter 325L.02)
The Minnesota-specific edition of the Legislative Indexing Vocabulary, a searchable online thesaurus available at http://www.bridges.state.mn.us/thesaurus
Data about data. Information that is used to facilitate intellectual control of , and structured access to, other information.
"All cards, correspondence, discs, maps, memoranda, microfilms, papers, photographs, recordings, reports, tapes, writings and other data, information or documentary material, regardless of physical form or characteristics, storage media or conditions of use, made or received by an officer or agency of the state and an officer or agency of a county, city, town, school district, municipal subdivision or corporation or other public authority or political entity within the state pursuant to state law or in connection with the transaction of public business by an officer or agency…The term "records" excludes data and information that does not become part of an official transaction, library and museum material made or acquired and kept solely for reference or exhibit purposes, extra copies of documents kept only for convenience of reference and stock of publications and processed documents, and bonds, coupons, or other obligations or evidence of indebtedness, the destruction or other disposition of which is governed by other laws." (Minnesota Statutes, Chapter138.17, subd. 1)
"Information that is inscribed on a tangible medium or that is stored in an electronic or other medium and is retrievable in perceivable form." (Minnesota Statutes, Chapter 325L.02)
Records arranged according to a filing system or kept together because they relate to a particular subject or function or result from the same activity.
The act or process of creating, maintaining, and disposing of records. See also "Records Management."
The planning, controlling, directing, organizing, training, promoting, and other managerial activities related to the creation, maintenance, use, and disposition of records. See also "Recordkeeping."
Records Retention Schedule:
A plan for the management of records listing types of records and how long they should be kept, the purpose of which is to provide continuing authority to dispose of or transfer records to the State Archives.
The record is formally captured by or created in the recordkeeping system.
A process in which the system, following business rules, automatically enters a value for a particular element/sub-element.
"An action or set of actions occurring between two or more persons relating to the conduct of business, commercial, or governmental affairs." (Minnesota Statutes, Chapter 325L.02)
Uniform Resource Identifier, the generic name for all types of names and addresses that refer to resources on the World Wide Web, including Uniform Resources Locators (URLs) and Uniform Resource Names (URNs). See http://www.w3.org/Addressing
H. Standard Requirements
The Minnesota Recordkeeping Metadata Standard consists of twenty elements, ten of which are mandatory and ten optional. In addition, many of these elements contain a number of sub-elements, some mandatory and some optional. There are a total of fifty-five sub-elements. Many elements and sub-elements are inter-related, and the assignment of a value to any given one may require the simultaneous assignment of a value to another. Section I, Appendix I.1 (Table of Element Inter-Relationships) offers a high-level summary of these relationships to help guide decisions on which elements to implement.
The word "shall" in technical descriptions of elements and sub-elements denotes mandatory states, conditions, or objectives.
The word "should" denotes desirable, but not mandatory states, conditions, or objectives.
Each recordkeeping metadata element is described in Section 9.6 using the following structure:
Definition: Describes the information that is captured in the element.
Purpose: Indicates what will be achieved by using the element.
Rationale: Gives reasons for the use of the element.
Obligation: Indicates whether use of the element is mandatory (i.e., essential for Minnesota government recordkeeping purposes), or optional. Agencies are not required to implement optional elements unless they have business reasons for doing so. However, if mandatory sub- elements are included under an optional element, those sub-elements must be used if the element itself is used.
Applicability: Indicates the level(s) of aggregation of record description at which the element is applicable.
Use Conditions: Denotes any conditions which must be in place prior to using the element, including reliance on defined values for other elements or sub-elements, and any effects that use of the element will have on the values of other elements or sub-elements.
Repeatable: Denotes whether or not the element may be used more than once in describing the same record or record series.
Sub-elements: Lists any sub-elements which are applicable to the element and indicates each sub-element's obligations for implementation and any schemes (standards or methods) which may be used to encode that sub-element. In cases where an element has no sub-elements, appropriate schemes are indicated at the element level.
Comments: Provides additional information to aid in the understanding of the purpose and use of the element.
Each recordkeeping metadata sub-element is described in Section 9.6 using the following structure:
Definition: Provides a short description of the information that should be captured in the sub-element.
Purpose: Provides short statements of what will be achieved by using the sub-element. Sometimes also includes the rationale for its use.
Obligation: Indicates whether use of the element is mandatory (i.e., essential for Minnesota government recordkeeping purposes), or optional (i.e., use can be decided by individual agencies based on their specific business requirements).
Use Conditions: Denotes any conditions which must be in place prior to using the sub-element, including reliance on defined values for other elements or sub-elements, and any effects that use of the sub-element will have on the values of other elements or sub-elements.
Assigned Values: Lists and defines any values which can be used for the sub-element (some assigned values are undefined because they are self-explanatory). In many cases the lists are extensible, and new values may be added by agencies to meet specific business requirements. Not all sub-elements have assigned values.
Default Value: Provides a pre-selected value for the sub-element. A value will remain as the default unless changed by an individual or the system in response to other requirements. In cases where no default value is listed, agencies may select their own value.
Repeatable: Denotes whether or not a particular sub-element may be used more than once in describing the same record at a single point in time.
Assigned By: Denotes whether the value of the sub-element is assigned automatically (system-assigned/generated), or whether it is assigned by an individual, either by selecting the value from a pick-list or by entering the value manually.
Schemes: Indicates any defined standards or methods which may be used to encode the sub-element.
Comments: Provides additional information to aid in the understanding of the purpose and use of the sub-element.
The following lists each element with all of its sub-elements, and displays the obligation for implementing each one. Full descriptions of each element and its corresponding sub-elements are available in Section 9.6.
1. AGENT (**Mandatory)
1.1 Agent Type (Mandatory)
1.2 Jurisdiction (Optional)
1.3 Entity Name (Mandatory)
1.4 Entity ID (Optional)
1.5 Person ID (Optional)
1.6 Personal Name (Optional)
1.7 Organization Unit (Optional)
1.8 Position Title (Optional)
1.9 Contact Details (Optional)
1.10 E-mail (Optional)
1.11 Digital Signature (Optional)
2. RIGHTS MANAGEMENT (**Mandatory)
2.1 MGDPA Classification (Mandatory)
2.2 Other Access Condition (Optional)
2.3 Usage Condition (Optional)
2.4 Encryption Details (Optional)
3. TITLE (**Mandatory)
3.1 Official Title (Mandatory)
3.2 Alternative Title (Optional)
4. SUBJECT (**Mandatory)
4.1 First Subject Term (Mandatory)
4.2 Enhanced Subject Term (Optional)
5. DESCRIPTION (Optional)
6. LANGUAGE (Optional)
7. RELATION (Optional)
7.1 Related Item ID (Mandatory)
7.2 Relation Type (Mandatory)
7.3 Relation Description (Optional)
8. COVERAGE (Optional)
8.1 Coverage Type (Mandatory)
8.2 Coverage Name (Optional)
9. FUNCTION (Optional)
10. DATE (**Mandatory)
10.1 Date/Time Created (Mandatory)
10.2 Other Date/Time (Optional)
10.3 Other Date/Time Description (Optional)
11. TYPE (Optional)
12. AGGREGATION LEVEL (**Mandatory)
13. FORMAT (Optional)
13.1 Content Medium (Mandatory)
13.2 Data Format (Mandatory)
13.3 Storage Medium (Mandatory)
13.4 Extent (Optional)
14. RECORD IDENTIFIER (**Mandatory)
15. MANAGEMENT HISTORY (**Mandatory)
15.1 Event Date/Time (Mandatory)
15.2 Event Type (Mandatory)
15.3 Event Description (Mandatory)
16. USE HISTORY (Optional)
16.1 Use Date/Time (Mandatory)
16.2 Use Type (Mandatory)
16.3 Use Description (Optional)
17. PRESERVATION HISTORY (Optional)
17.1 Action Date/Time (Mandatory)
17.2 Action Type (Mandatory)
17.3 Action Description (Mandatory)
17.4 Next Action (Optional)
17.5 Next Action Due Date (Optional)
18. LOCATION (**Mandatory)
18.1 Current Location (Mandatory)
18.2 Home Location Details (Mandatory)
18.3 Home Storage Details (Mandatory)
18.4 Recordkeeping System (Optional)
19. DISPOSAL (**Mandatory)
19.1 Retention Schedule (Mandatory)
19.2 Retention Period (Mandatory)
19.3 Disposal Action (Mandatory)
19.4 Disposal Due Date (Mandatory)
20. MANDATE (Optional)
20.1 Mandate Type (Mandatory)
20.2 Refers To (Mandatory)
20.3 Mandate Name (Mandatory)
20.4 Mandate Reference (Optional)
20.5 Requirement (Optional)
K.2 Table of Element Mappings to the Dublin Core Metadata Element Set (DCMES) and the Minnesota Geographic Metadata Guidelines (MGMG)
As of its first publication in May 2002, this standard has not been implemented in any Minnesota government setting. However, draft models for implementation do exist and are freely available. Those wishing more information should contact the individuals listed below.
|Name of Model||Description||Contact Person|
|Minnesota Recordkeeping Metadata Standard Data Model||Standard presented in data model format (database perspective) along with SQL script used to create table. Not reviewed or approved by CFL.|| Developed by Lorraine Swick
Department of Children, Families & Learning (CFL). MODEL NO LONGER AVAILABLE.
|Metadata and Data Interchange System (MDIS)||Theoretical model intended for the record series level. XML-based system centered around a metadata hub that would allow resource discovery in a non-proprietary, free software environment. Not reviewed or approved by Mn/DOT.||
Department of Transportation
Please direct all questions, corrections, and suggestions for revisions to:
State Archives, Collections Department
Minnesota Historical Society
All substantive revisions will be coordinated with the Minnesota Office of Enterprise Technology and the Minnesota Architectural Review Board, a sub-committee of the Information Policy Council. Non-substantive revisions (e.g., URL updates) will be carried out as necessary to maintain the currency of the standard.
Version 1.2 (April 2003):
- Element 6. LANGUAGE: Correction to the coding for “English” in ISO 639-2 from “en” to “eng”.
- Element 10. DATE: Sub-element 10.3 Other Date/Time Description added. Also added to Section I. Summary List of Metadata Elements.
- Element 13. FORMAT, sub-element 13.2: “Not Applicable” added to Assigned Values list.
- Element 13. FORMAT, sub-element 13.3: “Audiotape” and “USB Drive” added to Assigned Values list.
Version 1.1 (July 2002):
- Examples added after all elements except 6. LANGUAGE, 9. FUNCTION, 11. TYPE, 12. AGGREGATION LEVEL, and 14. RECORD IDENTIFIER.
- Full record metadata example added to Section K.3.
- Element 4. SUBJECT, sub-elements 4.1 and 4.2: Assigned Value lists moved to Schemes; No assigned values suggested.
- Element 8. COVERAGE, sub-elements 8.1 and 8.2: Assigned By definitions changed from “system assigned” to manual entry.
- Element 13. FORMAT, sub-element 13.3: Changed from “Not Repeatable” to repeatable in the case of compound records.
- Element 16. USE HISTORY, sub-element 16.3: Assigned by definition changed from “system-assigned” to “agent-assigned.”
Minnesota Recordkeeping Metadata Standard: Version 1.2, April 2003.
Links updated 2/2010; links verified 6/2010.