Associate Professor Sue McKemmish, School of Information Management and Systems, Monash University, 26 Sir John Monash Drive, Caulfield East, Victoria 3145, Australia, Sue.McKemmish@sims.monash.edu.au
Glenda Acland, School of Information Management and Systems, Monash University, 26 Sir John Monash Drive, Caulfield East, Victoria 3145, Australia, glenda.acland@uq.net.au
In electronic networked environments, metadata communities are working together to develop coherent information architecture and metadata regimes to support information management, discovery and delivery. The main drivers thus far have related to improving information resource identification, discovery and delivery to support information sharing and knowledge transmission via electronic networks which are populated by ever increasing numbers and varieties of document-like information objects. More recent imperatives relate to supporting the transaction of business via distributed networks.
A key component of the evolving metadata regimes is the use of standard metadata elements, embedded in, encapsulating or persistently linked to information objects. This paper will report on an Australian research project, which aims to develop a framework for standardising metadata in the records and archives community and defining a high level set of recordkeeping metadata within the broader context of the initiatives and imperatives referenced above. The project's main focus is on the definition and conceptual mapping of recordkeeping metadata. It has involved extensive research on records management and archival standards and existing metadata sets in the records and archives sector nationally and internationally, as well as reference to evolving generic metadata sets such as the Dublin Core, and related sector specific sets like the Australian Government Locator Service.
AusWeb delegates will be familiar with the drivers and processes involved in the development of the Dublin Core (DC) [HREF1] and Australian Government Locator Service (AGLS) [HREF2] metadata element sets. Both are primarily concerned with information resource discovery in networked environments. However the purposes of AGLS go beyond those of the Dublin Core to encompass the visibility, accessibility and interoperability of government information and services.
In support of the initiatives announced in the Australian Government's Investing for Growth [HREF3] package in late 1997, AGLS has emerged as a "key enabler which will encourage individuals and organisations to transact business electronically with government agencies at all three levels of government" (Cunningham 1998). The deployment of AGLS metadata supports and enhances specific initiatives such as Government Online [HREF4] and Business Entry Point (BEP) [HREF5], while opportunities for the exploitation of this metadata are being pursued in related projects under the auspices of AGLS. As it must deal interoperably at the global level with facilitating resource description and discovery, as well as with the transaction of Australian government business, the AGLS metadata set is based on qualified DC, with added Function and Availability elements. It is designed to be used to identify and describe information resources at any level of aggregation, as well as government services and agencies, the delivery points for the services.
Records and archives form a significant sub-set of the information resources increasingly being created and made available in the Web environment. Records are a by-product of doing business and they have an important role to play in doing it electronically. A simple way of defining a record is as a document that has taken part in a business process, and thereafter provides evidence of the transaction of that business. Records document business activity of all kinds, and are critical to corporate, democratic and historical accountability. They constitute a vital part of organisational and collective identity and memory, and provide important sources of value-added information. As records provide evidence of social and organisational activity, they need to be managed in ways which take account of their evidential nature as well as those characteristics they share with other information resources.
In networked environments, records, like other information resources, need to be adequately identified, described and authenticated. They need to be readily accessible via common user interfaces to authorised users, and retrievable for as long as they are required, then to be disposed of in a systematic way. Terms and conditions of access, including freedom of information law, privacy protection and confidentiality requirements, need to be managed and monitored. But records, as accountability traces and evidence of business activity, have additional metadata requirements. Authoritative well-structured metadata which specifies their content, structure, context and essential management needs must be embedded in, wrapped around or otherwise persistently linked to them from the moment they are created if they are to continue to function as evidence.
The genesis of the SPIRT Recordkeeping Metadata Research Project lies in the increasing opportunities for information accessibility and transmission of knowledge in distributed networked environments, and the seemingly unlimited scope for the transaction of business of all kinds via the Web. The late 1997 announcement by the Commonwealth government of the delivery of all appropriate services electronically via the Internet by 2001, and the establishment of electronic commerce as a normal means for Commonwealth payments by the year 2000 signaled the emergence in the public sector of radically different ways of structuring service provision and business processes, areas already being explored in the private sector. To support business activities in cyberspace, reliable and robust mechanisms are required to enable the continuing accessibility of essential evidence of business activities and ensure that the accountability protections provided by the electronic record persist over time.
The recordkeeping community, recognising that new approaches to managing records were needed, identified as a priority the development of a framework for standardising recordkeeping metadata and defining a high level set of metadata elements to support the persistence in networked environments of reliable, authentic, meaningful and accessible records. This imperative brought together a collaborative group of researchers and industry partners which was successful in attracting a 1998 Strategic Partnership with Industry ñ Research & Training (SPIRT) Support Grant from the Australian Research Council. Matching funding was provided by the industry partners. The SPIRT project, "Recordkeeping Metadata Standards for Managing and Accessing Information Resources in Networked Environments Over Time for Government, Social and Cultural Purposes" [HREF6], involves Monash University, the University of New South Wales, and a consortium of industry partners ñ the National Archives of Australia, the New South Wales State Records Authority, the Queensland State Archives, the Australian Council of Archives and the Records Management Association of Australia. The Chief Investigators are Sue McKemmish, Monash University, and Ann Pederson, University of New South Wales, with Industry Partner Chief Investigator Steve Stuckey of the National Archives of Australia.
The broader social context of the project relates to enabling society, government, commerce and individuals to continually access the information they need to conduct their business, protect their rights and entitlements, and securely trace the trail of responsibility and action. Maintaining authentic, reliable and useable evidence of transactions has significant social and cultural implications as records are a bastion of democratic and cultural accountability. They enable democratic rights of review and examination, and the transmission of our cultural heritage. Such rights have been increasingly protected in legislative mandate. Without the appropriate frameworks for the creation and management of electronic records in the networked environment equivalent to those well established in the paper world, society will be unable to exercise these rights and the cultural record of endeavour will be lost.
The immediate challenge to the records and archives profession is to develop recordkeeping metadata management regimes that will meet organisational, social and cultural needs relating to:
A significant factor in the shaping of the SPIRT Recordkeeping Metadata Research Project was recognition that managing records effectively in distributed networks involves ensuring that recordkeeping metadata regimes are compatible with the metadata development framework initiatives in the broader information community, in particular the DC and AGLS initiatives. Much of the metadata work undertaken so far in electronic networked environments is based on a passive notion of document-like information objects, seeing them as existing only to provide and disseminate information. The records and archives metadata community in Australia takes a different perspective in relation to records, regarding them as "active participants in business processes and technologies" rather than "passive objects to be described retrospectively" (Reed 1997). Envisaging records as information objects that act as the transactors of business informs the SPIRT Recordkeeping Metadata Research Project and links the dynamic world of business activity to the passive world of information resource in cyberspace.
The high level models in Figures 1 and 2 provide the framework for standardising and defining recordkeeping metadata.
Figure 1: The Business

People do business with each other. In the course of doing business, they create and manage records. Optimally their recordkeeping actions form an integral part of the business activity. The records created in the course of doing business capture the business done in documentary form. Business is here defined in the very broadest sense to encompass social and organisational activity of all kinds. Recordkeeping metadata can therefore be seen as essentially concerned with three classes of entities ñ Business entities, People entities and Records entities, as well as with the recordkeeping actions that create and manage records. The Business entity class encompasses business transactions, the business activities of which they are a part, the business functions the activities carry out, and the broader societal purposes they fulfil. The People entity class includes natural and legal persons, e.g. individuals, work groups, corporate bodies, and social institutions. The Records entity class covers records at item level or at any level of aggregation. All these entities and their complex inter-relationships require unique identifiers and standardised descriptive metadata.
Figure 2: The Business Context

People do business in social and organisational contexts that are governed by external mandates (e.g. social mores, laws) and internal mandates (e.g. policies, business rules). Mandates establish who is responsible for what, and govern social and organisational activity, including the creation of full and accurate records. Authentic records of social and organisational activity provide evidence of that activity and function as corporate and collective memory. They also provide authoritative sources of value added information. And they account for the execution of the mandate ñ internally and externally, currently and over time. Recordkeeping metadata therefore needs to include an element which enables identification and description of the external and internal mandates which are associated with Business, People and Records entities.
The SPIRT project's work on standardising recordkeeping metadata and defining metadata elements is based on an analysis of the business, organisational and social contexts of recordkeeping, national and international standards which specify recordkeeping requirements, and existing generic resource discovery and recordkeeping sector specific metadata schemes. The records and archives standards and schemes analysed in the project include:
On the basis of this work, metadata-related requirements are being identified, and a set of high level metadata elements are being defined in the Recordkeeping Metadata Scheme (see Figure 3), classified according to purpose and mapped against existing sets.
Figure 3: Recordkeeping Metadata

The elements defined in the Recordkeeping Metadata Scheme [HREF13] identify and describe significant features of the business contexts in which records are created, managed and used. They identify and describe the people or agents involved, and the records themselves. They also link business contexts to the people or agents doing the business and the records that document it, and they reference the mandates, laws, policies and business rules that authorise and control business activity. They enable description and management of recordkeeping actions, e.g. the processes which fix the content of records, enable their forms to be re-presented and rendered over time, manage their physical preservation, classify and index them. They enable the stringing together of related records, the administration of terms and conditions of access, use and disposal, and the tracking and documenting of the recordkeeping actions themselves, as well as the history of the use of the records.
The Recordkeeping Metadata Scheme elements are presented in Table 1. They include generic elements (RKM1-11) which identify and describe features of the business contexts in which records are created, the people or agents involved, the records, and the relationships amongst and between these entities ñ and elements that relate specifically to recordkeeping processes (RKM 12-16). Metadata elements that manage the metadata itself are also being developed with reference to the Admin Core of DC.
The Recordkeeping Metadata Scheme elements are presented as three sub-sets:
Business Metadata
Business metadata can be used to identify and describe business transactions and activities, as well as the business functions and broader societal purposes that they serve.
Agent Metadata
Agents may be corporate bodies or persons. They may operate at any level in a hierarchy. Examples include an operational position, an organisational unit or work group, an organisation, an institution, a person or a family.
Record Metadata
Records may be at any level of disaggregation or aggregation, e.g. a component of a record, a file, a records system, a corporate archive, a collective archives.
| Table 1: Recordkeeping Metadata Elements Draft Version 2.0 |
|---|
| Business RKM1 CATEGORY RKM2 IDENTIFIER RKM3 TITLE RKM4 DATE RKM5 PLACE RKM6 FUNCTIONAL CLASSIFICATION RKM8 DESCRIPTION RKM9 LANGUAGE RKM10 RELATION RKM11 MANDATE Agent Record |
The RKMS is made up of a set of highly structured metadata elements, sub-elements and qualifiers, and provides for the specification of the schemes used to determine the values of the metadata elements. The set is also designed to be extensible, e.g. the University of Pittsburgh Business Acceptable Communications Model's Structure Layer elements could be used as sub-elements to extend RKM12 Logical Form and RKM13 Physical Form. Some of the special features of the set are described below.
In the next stage of the SPIRT project, the RKMS metadata elements will be modelled in RDF and expressed in XML. It is also planned to model the RKMS set in UML from the perspectives of:
Scaleability
A significant feature of this high level set of metadata is that it is scaleable, i.e. when it is implemented it can apply to records at any level of aggregation, to business dealings ranging from an individual transaction to the societal purpose it ultimately serves, and to agents acting at any level in organisational and social hierarchies. A Category element or "switch" has therefore been included in the set. In any particular instance the Category element (RKM1) functions as a handshake, introducing the type of entity being identified and described:
Expression of Complex Relationships
The Relation metadata element (RKM10) enables links to be made between the Record, Agent or Business entity being identified and described in a particular instance and any other Record, Agent or Business entity, as illustrated in Figure 4.
Figure 4: Relationships

Recordkeeping metadata must be capable of expressing the multiple and complex time-based relationships illustrated in the following statements. In the Recordkeeping Metadata Scheme, this requirement is addressed by the Relation element (RKM10) and its type and date qualifiers.
| Agent:Business | The Lending Group was responsible for managing the loan application and approval process. John Smith, Animal Welfare Officer, is authorised to issue a dog licence. The Australian Taxation Office is mandated by law to carry out the Commonwealth Government's tax function. |
| Business:Record | The agreement was manifested in a contract. The research project activity is evidenced in the laboratory notebooks system. The university's teaching role is accounted for by the corporate archive. |
| Agent:Record | Betty Brown created an accident report. The FOI Unit controls access to records of arson investigations. BHP Corporate Archives is custodian of the company archive. |
| Business:Business | Calling for public submissions is part of the parliamentary committee inquiry process. Checking the credit rating occurs before a recommendation to approve or reject a loan application is made. |
| Agent:Agent | The PR Department reports to the CEO. The Commonwealth of Australia inherited the immigration function from the colony of Victoria. |
| Record:Record | The land register controlled land title files. The loan application is part of the electronic loan history file. The agenda and minutes form part of Board's recordkeeping system. |
Various schemes defining types of relationships already exist in the records and archives community, but there is a pressing need for a standard taxonomy.
Recordkeeping Actions Metadata
Record Elements RKM12-16 support the description and management of recordkeeping processes that relate to Logical Form, Physical Form, Access, Use and Disposal. The following examples illustrate the scope of these elements.
| RKM12 LOGICAL FORM | I take the form of a memo/letter/contract/title deed/receipt. I am registered in an annual single number system. I am indexed by name/geographical location. My contents are structured in the following way. To reconstruct my content, you need to follow these processes. I was indexed and classified by Barry at 12.12.05 EST on 19 Aug 1996. |
| RKM13 PHYSICAL FORM | I contain these physical files. I am text/sound/image. I am encoded in ASCII/x bits per pixel/x samples per second. I am compressed in this way and encrypted like this. I am software/hardware dependent in the following way. I am in Word7. I am marked up in SGML. This is how my files are linked together. I contain data from an instrument; and this is what you need to know about it. If you want to render/refresh/migrate me, you need to do this. I was refreshed on 28 Dec 1998. |
| RKM14 ACCESS | Anyone can look at me. I am closed to public access until 2008 under section 321 (b) of the Archives Act. You can see me if you are a child protection officer. You can see me under the provisions of the FOI Act. I'm classified Top Secret ñ buzz off unless you are cleared at this level. Special access conditions apply ñ go to the following site to see if they apply to you. My access status was changed by Jane on 3 Feb 1999. |
| RKM15 USE | You can look at me but you can't copy me. Copies of me are for sale ñ go to this site to arrange to buy one. You can reproduce me if you cite me in this way. You can get a licence to use me Ö these are the conditions Ö go to this site to arrange a licence. A version of me that suppressed the names of victims of child abuse was viewed by Fred on 19 Aug 1998. |
| RKM16 DISPOSAL | Don't you dare delete me ñ I'm a national treasure. I'll be disposed of in accordance with the Company Disposal Schedule in 10 seconds Ö 10, 9, 8Ö I was deleted by Betty on 5 Oct 1998. |
As part of the SPIRT Recordkeeping Metadata Research project, the RKMS set is being mapped against existing records and archives descriptive metadata, and against sets like DC and AGLS. In Table 2, the RKMS set is mapped against the AGLS set.
| Table 2: Recordkeeping Metadata ñ AGLS Map | |
|---|---|
| Business RKM1 CATEGORY RKM2 IDENTIFIER RKM3 TITLE RKM4 DATE RKM5 PLACE RKM6 FUNCTIONAL CLASSIFICATION RKM8 DESCRIPTION RKM9 LANGUAGE RKM10 RELATION RKM11 MANDATE Agent RKM1 CATEGORY RKM2 IDENTIFIER RKM3 TITLE RKM4 DATE RKM5 PLACE RKM6 FUNCTIONAL CLASSIFICATION RKM8 DESCRIPTION RKM9 LANGUAGE RKM10 RELATION RKM11 MANDATE Record RKM1 CATEGORY RKM2 IDENTIFIER RKM3 TITLE RKM4 DATE RKM5 PLACE RKM6 FUNCTIONAL CLASSIFICATION RKM7 SUBJECT RKM8 DESCRIPTION RKM9 LANGUAGE RKM10 RELATION RKM11 MANDATE RKM12 LOGICAL FORM RKM13 PHYSICAL FORM RKM14 ACCESS RKM15 USE RKM16 DISPOSAL *Partial map only: concepts not aligned |
Services TYPE* IDENTIFIER TITLE DATE** FUNCTION* SUBJECT DESCRIPTION LANGUAGE Government Agencies TYPE* IDENTIFIER TITLE DATE** FUNCTION* SUBJECT DESCRIPTION LANGUAGE Data/Documents TYPE* IDENTIFIER TITLE DATE**, COVERAGE COVERAGE* FUNCTION* SUBJECT DESCRIPTION LANGUAGE RELATION** TYPE* FORMAT**, TYPE* RIGHTS** RIGHTS** **RKM element extends concept in AGLS element |
| Note: This mapping is based on the current guidelines for using AGLS. | |
As the AGLS-RKMS mapping shows, in some cases, for example the Identifier, Title, Subject and Description elements, there is a direct match. This tends to occur when the elements represent clear, simple concepts. In other cases the concepts are not fully aligned ñ this is particularly the case in relation to the Type element in AGLS, which clumps together a number of concepts that are represented separately in the RKMS set (in the Category, Logical Form and Physical Form elements). Indeed in both the AGLS and DC sets there would appear also to be internal confusion between the Type and Format elements.
In yet other cases the RKMS element encompasses and extends the concept represented in the corresponding AGLS element. For example, in the AGLS set, the Format element provides a minimalist description of the format of an information resource as its main purpose is to provide users with the information they need to physically access and/or download the resource. Whereas in the RKMS set, the Physical Form element encompasses and extends the concept embodied in the AGLS Format element to serve the recordkeeping purposes associated with the management of the physical form of a record. Similarly the Rights element in AGLS acts merely as a pointer to more detailed information about copyright and intellectual property issues; while in the RKMS set more extensive Access and Use metadata elements relate to all aspects of managing access and use terms and conditions.
Although the sector specific needs of the records and archives community should not in any way drive the evolution of the AGLS set, the mapping undertaken by the SPIRT team does identify some areas of conceptual confusion in the AGLS set.
The mapping also highlights the need for more attention to be given to how the AGLS set can be used to identify and describe government services and their delivery points (government agencies). For example, the current guidelines appear to limit the use of the Relation element to relationships between documents/data. Exploration of its potential use in relation to government services and agencies is warranted.
The RKMS has also taken quite a different approach to identifying and describing the agents that are responsible for creating, controlling, managing and using records. Whereas the AGLS set, like Dublin Core, only recognises agents that play a creating, publishing or contributing role in relationship to information resources, the RKMS set is able to deal with various types of agents and to express the multiplicity of time-based relationships that exist between agents and records. This approach reflects traditional Australian archival approaches to documenting the complex relationships between records, their business contexts, and the people and agencies involved in their creation, control, management and use. In this regard the records and archives community is in line with the approaches being developed in the intellectual rights community, as outlined by Bearman, Miller, Rust, Trant and Weibel in a recent article that reports on progress in reconciling the metadata requirements of the Dublin Core and INDECS/DOI communities, and "charts a path for harmonizing their respective conceptual models" (Bearman 1999).
Standardised recordkeeping metadata supports the conduct of electronic business and contributes to the reliability and trustworthiness of business transactions. It enables access to essential evidence of business activity in networked environments by:
It can also be harvested from records and archival systems for uses quite unrelated to recordkeeping purposes because it provides a rich source of authoritative information that could be used to describe services available online, identify service delivery points or produce government and business directories.
The records and archives metadata community in Australia has been working with other metadata communities to define common requirements and specify common structures through the AGLS initiative and with reference to DC and related developments. Like other stakeholders, the records and archives metadata community is seeking to meet its sector specific requirements while at the same time working cooperatively to address shared requirements in relation to resource description and discovery and to support interoperability. The SPIRT Recordkeeping Metadata Research Project reported on in this paper addresses both these needs.
We wish to acknowledge the contribution to the development of this paper of our colleagues Kate Cumming, SPIRT Recordkeeping Metadata Research Project Research Team, Barbara Reed, Recordkeeping Systems, and Nigel Ward, Distributed Systems Technology Centre, Monash University.
The Project Team, in developing a simple but high level framework model for recordkeeping metadata given as Figure 1, used as an example of effective visual representation the INDECS Community's "Model for Commerce" (Bearman 1999).
Bearman, D., Miller, E., Rust, G., Trant, J., &Weibel, S. (1999). A Common Model to Support Interoperable Metadata: Progress report on reconciling metadata requirements from the Dublin Core and INDECS/DOI Communities, D-Lib Magazine [HREF14]
Cunningham, A. (1998). The Australian Government Locator Service: Enabling Seamless Online Access to Government, paper delivered at the Metadata Unravelled Seminar 26 August 1998 [HREF15]
Public Record Office Victoria (1998). Victorian Electronic Records Strategy: Final Report
Reed, B. (1997) Metadata: Core Record or Core Business, Archives and Manuscripts 25:2 (pp. 218-41) [HREF16]
Standards Australia (1996), AS 4390: Records Management, Homebush NSW
Sue McKemmish and Glenda Acland, © 1999. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.
[ Proceedings ]