Skip to the content | Change text size

Describing Records in Context in the Continuum: the Australian Recordkeeping Metadata Schema*

Sue McKemmish is an Associate Professor in the School of Information Management and Systems (SIMS) at Monash University in Melbourne, Australia. With her Monash colleagues she has developed innovative, integrated, multi-disciplinary approaches to records management, archival and information management education at postgraduate and undergraduate levels within the framework provided by records continuum and information continuum theory. She was Principal Chief Investigator for the 1998-99 SPIRT Recordkeeping Metadata Research Project, is Director of the Records Continuum Research Group within SIMS, and a research associate of the new Enterprise Distributed Systems Technology National Collaborative Research Centre. Sue is the immediate past editor of "Archives and Manuscripts" and a Laureate of the Australian Society of Archivists.

Glenda Acland is a recordkeeping consultant based in Brisbane, Australia. She is a Research Associate of the Records Continuum Research Group in the School of Information Management and Systems at Monash University and was Research Consultant for the 1998-99 SPIRT Recordkeeping Metadata Research Project. She has had an extensive career as an archivist/ recordkeeping professional operating within the records continuum model and has been employed at institutions such as Australian Archives and the University of Queensland. Since 1998 Glenda has worked in a freelance capacity as a consultant, researcher and educator mainly for Monash University. Her professional interests include articulation of records continuum thinking, electronic recordkeeping and enterprise recordkeeping regimes.

Nigel Ward is a Senior Research Scientist based at the Melbourne Office (Monash University) of the Distributed Systems Technology Centre (DSTC). DSTC is a joint venture of over 20 participating organisations developing the technical infrastructure for tomorrow's enterprise. At the DSTC, Nigel is a member of the Resource Discovery Unit which investigates technologies for the location, retrieval, and management of resources located on widely distributed heterogeneous networks like the Internet. His current research interest is in using context to improve a user's information environment. Since early 1999 he has contributed his expertise to the SPIRT Recordkeeping Metadata Research Project particularly in metamodelling of the Recordkeeping Metadata Scheme. Prior to relocating to Melbourne he worked at the Head Office of DSCT at the University of Queensland where he investigated Metadata Standards and Distributed Search Infrastructures.

Barbara Reed is the Director of Recordkeeping Systems Pty Ltd, a specialist consultancy company based in Sydney, Australia. She is a Research Associate of the Records Continuum Research Group in the School of Information Management and Systems (SIMS) at Monash University and has responsibility for the development of professional continuing education program. From 1995-1998 Barbara held the position of Senior Lecturer in SIMS following an extensive career as a recordkeeping consultant in the private sector and government records environments. She provided expert advice to the 1998-99 SPIRT Recordkeeping Metadata Research Project arising from her specialisation in the strategic integration of recordkeeping into business processes. Barbara is Head of Australian Delegation to TC 46, International Standards Organisation sub committee on Records Management.

Abstract

The Australian Recordkeeping Metadata Schema (RKMS), approved in July 1999 by its academic and industry steering group, is the major deliverable of an eighteen month Australian collaborative research project reported on in this article. The project's conceptual frame of reference was the Records Continuum Model and the Australian Series System. The RKMS uses recordkeeping understandings to make explicit connections between business, defined broadly to encompass all social and organisational activity, the people or agents who do business, and the records which are by-products of that business. Its vision links the dynamic world of business and social activity to the passive world of information resource management in cyberspace. In this article the conceptual models developed by the research team as a framework for standardising and defining Recordkeeping Metadata are presented, the Schema elements introduced and their extensibility explored through the metamodels employed to enable rigorous structuring and test validity. The capacity of the RKMS to facilitate semantic interoperability by providing a framework for mapping or reading other metadata sets is outlined, followed by a brief discussion of implementation issues and future directions.


Describing Records in Context in the Continuum: the Australian Recordkeeping Metadata Schema*


By Sue McKemmish, Glenda Acland, Nigel Ward and Barbara Reed

Introduction

Metadata, which can be generically defined as "structured data about data", is simply a new term for the type of information that has existed in records and archives systems throughout time - indeed records managers and archivists have always been metadata experts. Traditional archival finding aids, index cards, file covers, file registers, the headers and footers on paper documents, and all of their computerised counterparts are rich in metadata that helps recordkeepers to identify, describe, authenticate, manage and provide access to records. More recently, specific sets of records and archives metadata have been standardised, such as the records management metadata specified in the US Department of Defense Design Criteria Standard for Electronic Records Management Software Applications1 and the archival description metadata in the General International Standard Archival Description, ISAD(G)2. Working within the context of a range of metadata related initiatives in Australia and elsewhere, the 1998-99 SPIRT Recordkeeping Metadata Research Project set out to comprehensively specify and codify recordkeeping metadata in ways that enable it to be fully understood and deployed both within and beyond the recordkeeping community3 . It has built a framework within which recordkeeping metadata standards can be developed for targeted application in different sectors or domains, for example in the government sector, in a particular corporate context or in archival institutions.4

Much of the work on metadata in networked environments is based on notions of passive document-like information objects. This is certainly the case with the Dublin Core initiative with its emphasis on the discovery of information resources in a web environment5. In our own field the work of the international archival descriptive standards community has essentially been concerned with the retrospective description of records as artefacts. The SPIRT Recordkeeping Metadata Research Project takes a different perspective. It regards records as active participants in business processes and technologies, dynamic objects which need to be associated throughout their life span with ever broader and richer layers of contextual metadata in order to maintain their reliability and authenticity, and to be meaningful and accessible through time and space6. This perspective has developed in the context of records continuum thinking and practice in Australia, with particular reference to the work of Frank Upward in developing the Records Continuum Model7, and Chris Hurley's writings on archival description, the Australian series system, and the functional context of recordkeeping8. It also draws on David Bearman's insights into recordkeeping systems, the possibilities of managing records as metadata encapsulated objects, and item level control, as well as his pioneering work on the Business Acceptable Communications model9.

The composition of the SPIRT Project Team reflects the way that records continuum thinking and practice brings together records managers and archivists as a community under the recordkeeping umbrella in Australia. The essence of this recordkeeping approach has been articulated as follows:

Records continuum thinking focuses on the unifying purposes shared by all recordkeeping professionals, defined as to do with the delivery of frameworks for accountable recordkeeping regimes that enable access to essential, useable evidence of social and business activity in the business, social and cultural domains10.

Major initiatives undertaken by this community include the Australian Records Management Standard, AS 4390, and the Australian Records and Archives Competency Standards11. Such endeavours are underpinned by a concept of records which is inclusive of records of continuing value (archives). This concept is increasingly being used as a basis for official definitions of records in Australia. For example, in AS 4390 records are defined as "recorded information, in any form, including data in computer systems, created or received and maintained by an organisation or person in the transaction of business or the conduct of affairs and kept as evidence of such activity." And archives are defined as "those records that are appraised as having continuing value."12

The major deliverable of the eighteen month Research Project, "Recordkeeping Metadata Standards for Managing and Accessing Information Resources in Networked Environments Over Time for Government, Commerce, Social and Cultural Purposes," is the Australian Recordkeeping Metadata Schema (RKMS)13. This high level Schema provides:

The genesis of the Project lies in the increasing opportunities for information accessibility and the transaction of business electronically in networked environments as well as a dawning recognition of the recordkeeping risks associated with "getting Australia on line."15 The recordkeeping community in Australia is vitally concerned with the quality of public and corporate recordkeeping in electronic environments, particularly recordkeeping-related issues concerning the reliability, accessibility and accountability of online activities and services, and the persistence of records of continuing value to society. Major problems in electronic recordkeeping have been linked to the lack of controls, frameworks and standards in this rapidly evolving area. The response has been a proactive, innovative approach to the research and development role, epitomised in the involvement of the industry partners in the SPIRT 1998-99 Research Project.

The broader social context of the project is the need to enable 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 in distributed enterprises, i.e. in enterprises operating in networked environments in local or global domains. Maintaining reliable, authentic, and useable evidence of transactions through time and space has significant business, social, and cultural implications as records provide essential evidence for governance, accountability, memory, and identity purposes. They support democratic rights of review and the transmission of our cultural heritage.

A further very significant factor in shaping the Research Project was the recognition that to manage records effectively in distributed networks it is essential that recordkeeping metadata regimes be compatible with initiatives relating to metadata development frameworks underway in the broader metadata community. Among other things, this will ensure that records, including those of continuing value, can be accessed with an array of other types of information resources through common user interfaces. This approach also acknowledges that records can provide a rich source of enterprise information and promotes their exploitation and reuse for reasons unrelated to the business or social activity they document.

Finally, the Research Project has been influenced by the international discourse on electronic recordkeeping and archival description, in particular by Terry Cook's exploration of the concept of the archival fonds and insights into the "conceptual relationships between creating structures, their animating functions and the resulting records,"16 Margaret Hedstrom's writings on electronic recordkeeping17, and Wendy Duff's work on literary warrant18. The Project has also used the research outcomes of the University of Pittsburgh's "Functional Requirements for Evidence in Recordkeeping Project"19 and the University of British Columbia's "Protection of the Integrity of Electronic Records Project."20

Records Continuum Frame of Reference

For the purposes of the Project, recordkeeping metadata was defined to include all standardised information that identifies, authenticates, describes, manages and makes accessible through time and space documents created in the context of social and business activity. Traditionally some of this metadata has been captured in records systems and some in archival control systems and finding aids. And some of it has been present in the physical form, ordering, juxtaposition and location of records. Increasingly recordkeeping metadata is also captured in workflow, document management and knowledge management systems, and it is essential to make what was before evident in the physicality of the record explicit in metadata.

As long as records remain in the local domains in which they are created, a lot of broader contextual metadata is "in the air," carried in the minds of the corporate users of the records.21 When records move beyond the boundaries of the local domain in which they were created, or, as is increasingly the case in networked environments, they are created in the first place in a global rather than a local domain, then this kind of metadata needs to be made explicit - i.e. captured and persistently linked to the record. This is essential so that users in the broader domain can uniquely identify, retrieve, and understand the meanings of the records. In a paper world this need typically arose when records were transferred to an archives repository. Thus broader contextual metadata was captured in archival control systems and finding aids rather than in current records systems. However, in the global and virtual domains of cyberspace, we need to make what was before evident through physical ordering and location (custody) explicit in metadata captured with the record or persistently linked to it. We need to document fully the logical associations that derive from the role the records play in business processes and contexts. And we may need to make available to current records systems the broader contextual metadata traditionally found in archival systems and finding aids, for example information about the records' wider organisational context and relationships to high level functions, as well as the narrower contextual metadata of the immediate business environment. The latter includes information about transactions, business processes, and the actors involved that is captured in enterprise systems such as document management, workflow, and human resources applications.

A fundamental premise of the Project is that it is possible to identify, categorise, label, and present in a formal, standardised way the metadata that supports recordkeeping through time and space - regardless of where, when or how that metadata is captured.

The term recordkeeping metadata as used in the Project labels a much broader concept than the term metadata as used in writings that take a life cycle perspective and focus exclusively on the use of metadata in records management systems or in archival description as traditionally defined.22 The decision to adopt the particular concept of recordkeeping metadata used by the Project is bound up with the way description is defined in Australian records continuum thinking. Records continuum approaches are based on establishing an integrated regime of management processes for the whole of the records existence. In the records continuum description is therefore defined as a series of iterative recordkeeping processes that capture and inextricably link authoritative metadata to documents created in the context of social and business activity from the time of their creation and throughout their life span. The primary aim of these processes is to provide the intellectual controls that enable reliable, authentic, meaningful, and accessible records to be carried forward through time within and beyond organisational boundaries for as long as they are needed for the multiple purposes they serve. Recordkeeping processes (including archiving processes) "fix" documents which are created in the context of social and business activity, and "preserve" them as evidence of that activity in ways that assure their accessibility for as long as they are of value. Managing documents as evidence of social and business activity involves developing records and archives systems that can carry them forward with their "fixed" content, render their structure or documentary form, and maintain sufficient contextual links to preserve their meaning through time. Recordkeeping professionals (records managers and archivists) are responsible for managing these processes to achieve these goals. In the words of the Australian Records Management Standard, recordkeeping includes:

a) The creation of records in the course of business activity and the means to ensure the creation of adequate records.
b) The design, establishment and operation of recordkeeping systems.
c) The management of records used in business (traditionally regarded as the domain of records management) and as archives (traditionally regarded as the domain of archives administration).23

The term archival description has been used to refer, narrowly, to the post-transfer process of establishing intellectual control over archival holdings where the descriptions function as cataloguing records, surrogates whose primary purpose is to help researchers to find relevant records and understand something of their purpose and origins. More broadly, it has referred to the augmentation of the contextual metadata captured by recordkeepers in records systems. In continuum thinking description has evolved into an even broader concept: that of a more complex multi-layered recordkeeping function. This concept is not set up as an alternative to traditional understandings of archival description. It does not focus on either the "front end" or the "back end" of the records life cycle. Rather it encompasses and extends traditional definitions so that it can apply throughout the records continuum. According to this view, archivists:

participate in recordkeeping processes by documenting complex relationships between records and context. Records must be placed in context - in time and place - by fashioning descriptive entities and documenting relationships. This is how we can locate them into a time-bound, evidential cocoon of meaning.24

The Australian series system, with its emphasis on describing both context and records entities, and the complex, dynamic relationships between them, was another key aspect of the frame of reference for the Project25. The conceptual framework of the Project extends Peter Scott's revolutionary approach to archival description, as outlined by Terry Cook:

Scott's fundamental insight was that the traditional archival assumption of a one-to-one relationship between the record and its creating administration was no longer valid. He also demonstrated clearly that administrations themselves were no longer mono-hierarchical in structure or function, but ever-changing, complex dynamisms, as were their record-keeping systems. He therefore developed the Australian series system approach as a means for describing multiple interrelationships between numerous creators, and numerous series of records, wherever they may be on the continuum of records administration: in the office(s) of creation, in the office of current control, or in the archives … In effect, Scott has moved archival description from static cataloguing to a dynamic system of multiple interrelationships … Although he worked in a paper world, his insights are now especially relevant for archivists facing electronic records, where - just as in Scott's system - the physicality of the record has no importance compared to its multi-relational contexts of creation and contemporary use.26

Cook, Hurley and others have also drawn attention to the misconception that the Australian series system is minimalist in only describing the "series", and does not enable description of the fonds. Whereas, in fact, because of its approach to describing records entities, context entities and their multiple, dynamic interrelationships, the system is capable of "generating a fonds (i.e. a documentary representation of a fonds) when called upon to do so." 27

Relationship with Emerging Australian and International Metadata Standards

As mentioned above, the SPIRT Recordkeeping Metadata Schema has been developed using conventions and protocols adopted by the wider metadata community, in particular the Dublin Core (DC) and Australian Government Locator Service (AGLS) metadata initiatives, to ensure compatibility, as far as practicable, between related resource management tools. The minimalist Dublin Core metadata set is a generic resource discovery metadata schema designed for implementation in web-based environments.28 The Dublin Core-derived Australian Government Locator Service (AGLS) metadata standard is primarily concerned with describing government services and information resources for discovery and retrieval purposes, although its further development aims to facilitate the transaction of government business online29. The relationship between DC, AGLS and RKMS can be described as follows:

The main objective of AGLS is to improve the visibility, accessibility and interoperability of government information and services through the provision of standardised Web-based resource descriptions which enable users to locate the information or service that they require. At the conception of the AGLS schema it was recognised that a high proportion of information resources described or required online to support Internet based government services and transactions would be records, i.e. that in many cases AGLS metadata would be assigned to government records. Thus the metadata defined in the AGLS schema went beyond that required for the bibliographic description of information resources as defined in the Dublin Core. It was also recognised that the prime purpose of assigning AGLS metadata, namely enabling resource discovery and resource retrieval by authorised users, is also one of the requirements of a recordkeeping system. The SPIRT Recordkeeping Team therefore sees AGLS metadata as essentially a subset of any standardised metadata set specified for recordkeeping purposes.30

The National Archives of Australia Recordkeeping Metadata Standard for Commonwealth Agencies 199931 was developed by the major industry partner in the Project in tandem with the SPIRT Schema. Essentially a sub-set of the SPIRT Schema, it is designed for implementation by Commonwealth government agencies in electronic systems which create and manage records. In another SPIRT related initiative, the Descriptive Standards Committee of the Australian Society of Archivists/Australian Council of Archives has proposed a codification of the Australian series system, which is currently implemented in archival control systems in non-standard ways by the National Archives of Australia, most State Archives and many small archives.32

The SPIRT Project involved extensive analysis of the business, organisational and social contexts of recordkeeping, as well as national and international standards, statements of best practice and research project outcomes. The analysis focussed on identifying recordkeeping metadata related requirements throughout the continuum, for example in AS4390 Australian Standard: Records Management33 , the Australian Common Practices Manual34, the US Department of Defense Design Criteria Standard for Electronic Records Management Software Applications35 , the University of Pittsburgh's "Functional Requirements for Evidence in Recordkeeping Project"36, and the University of British Columbia's "Protection of the Integrity of Electronic Records Project."37

The SPIRT Project team identified the recordkeeping requirements that pointed explicitly or implicitly to the need to capture descriptive metadata as being those required to meet the following range of recordkeeping purposes:

Another key research method involved an iterative process of conceptually mapping the elements of the emerging Recordkeeping Metadata Schema against elements in existing "best practice" generic sets, like DC, and elements in recordkeeping specific metadata sets, for example the Business Acceptable Communications Model (BAC)38, the General International Standard Archival Description39, ISAD(G), and the related International Standard Archival Authority Record for Corporate Bodies, Persons, and Families, ISAAR(CPF), the Encoded Archival Description standard40, (EAD), and the metadata specified in the Victorian Electronic Records Strategy41 (VERS) project.

Element to element mapping initially enabled a comparison of the meaning and purposes of metadata. Common elements, overlaps, redundancies and gaps were identified, and additional metadata specified. Further development of the mapping methodology within the broader framework provided by the RKMS is producing "crosswalks" which more formally identify the equivalences and correspondences between different sets of recordkeeping metadata and link metadata elements to their recordkeeping purposes. Such mappings also enable an evaluation of the adequacy of specific metadata sets for the purposes they are designed to serve, and will provide the basis for interoperability between sets as explored further below.42

Framework for Standardising and Defining Recordkeeping Metadata

Another key aspect of the research methodology was the development by the Research Team of three high level models (Figures 1, 2 and 3) to provide the conceptual framework for standardising and defining recordkeeping metadata43. The models and brief explanations of them are presented below.

People do business of all kinds with each other. In the course of doing business, they create and manage records. The records created in the course of doing business capture in documentary form the business done. In the conceptual models developed by the Project, the term Business was defined in the very broadest sense to encompass social and organisational activity of all kinds.

Optimally recordkeeping forms an integral part of any business activity.

People do business in social and organisational contexts that are governed by external mandates (e.g. social mores and conditioning, laws, regulations, standards, best practice codes, professional ethics) and internal mandates (e.g. corporate culture, policies, administrative instructions, delegations, authorities)44. Mandates establish in both formal and informal ways who is responsible for what, and govern social and organisational activity and recordkeeping behaviours. 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 as they capture not only the content, but also the context of the interactions they document. And they account for the execution of the mandate - internally and externally, currently and over time.

Recordkeeping Metadata

With reference to these high level conceptual models, the RKMS is presented diagrammatically below (see Figure 4) as essentially concerned with three classes of entities - Business entities, People/Agent entities and Records entities - as well as their interrelationships, and the mandates which are associated with them and govern the relationships between them. Furthermore, Business Recordkeeping entities form a sub-class of the Business entity class.

The RKMS envisions description and management of records, agents and business at different layers of aggregation. A taxonomy of layers has been defined with reference to the Records Continuum Model.45

For the Business entity class these layers are Business Transactions, Business Activities, Business Functions and Ambient Functions. They encompass, respectively, acts, actions decisions, communications or the component parts of business processes; the social or organisational activities or occupations of which they are a part; the functions the activities carry out; and the broader societal purposes they fulfil. Similarly for the Business Recordkeeping entity class (a sub-set of the Business entity class) the layers are Recordkeeping Business Transactions, Recordkeeping Business Activities, Recordkeeping Business Functions and Recordkeeping Ambient Functions. This sub-class of the Business entity has been broken out and identified separately because it represents the social and organisational activities that are concerned with recording, managing and enabling the use of records of the other types of social and organisational activity that form part of the larger Business entity class. [That is, they have a special functional importance.]

Agents may be social entities (e.g.organisational bodies or other social drivers such as motherhood), persons, legal and other such instruments. They may operate at any level in a hierarchy and may be responsible for creating, controlling and managing records, or they may be engaged in their use. Examples include intelligent agents (such as in electronic systems which undertake discretionary decisions), organisational positions, organisational units or work groups, organisations, social institutions (including social constructs such as motherhood or friendship), persons or families. The layers defined in this entity are Persons or Actors (who carry out the transactions), Organisational Units or Work Groups (responsible for the activity), Organisations or Corporate Bodies (mandated to carry out the function), and Social Institutions (associated with ambient functions in the sense of high level societal purposes).

The Records entity class encompasses records at any layer of aggregation or disaggregation. The layers defined are Record Objects, Record Aggregations (including any organic grouping of records, series, files, or items), the Corporate Archive (the whole of the records of an organisation, the corporate recordkeeping system), and the Collective Archives (all of the records within a specified society, jurisdiction, business or social sector brought into an encompassing framework to form collective memory).

All these entities and their complex interrelationships require unique identifiers and standardised descriptive metadata.

The Recordkeeping Metadata Elements Schema (Release Version 1.00)

A highly structured set of elements and qualifiers has been defined. (Note that only the elements are represented in Figure 5b, see Appendix for full set.) The view of the Schema provided in Figure 5 presents the elements in four sub-sets. This view of the metadata elements is derived from the conceptualisation of records in their "business" context as depicted in Figures 1-3 and defined above. The Schema inherits part of the Australian Government Locator Service set and extends it to address the sector specific needs of recordkeeping.

The elements and qualifiers defined in the Recordkeeping Metadata Schema identify and describe significant features of the business contexts in which records are created, managed and used. They identify, name, date and place the Business, Business Recordkeeping, Agents and Records entities (Identifier, Title, Date, Place). They specify Record to Record, Agent to Agent, Business to Business, Business Recordkeeping to Business Recordkeeping relationships, and they link Business and Business Recordkeeping entities to the Agents involved and the Records themselves (these various relationships being termed their "Relation"). They also describe relevant mandates (Mandate), provide for the functional classification of the entity (Functional Classification), state the language or script in which the Business is conducted, the Agent does business or the Record is captured, stored or rendered (Language), and provide for a brief descriptive note (Abstract). In relation to the Business class and Business Recordkeeping sub-class, the Business Rules element provides for description of business rules, work processes, procedures and system specifications. The RKMS also enables management of recordkeeping functions, activities and transactions that are concerned with creating, capturing, and managing records, and enabling their use, e.g. transactions and activities relating to the recordkeeping functions of appraisal, control, preservation, retrieval, access and use of records. This is achieved through the unique Records metadata elements of Appraisal, Control, Preservation, Retrieval, Access, and Use. There is also provision for the tracking and documenting of recordkeeping processes (through the Event History element).

The Entity Type "Switch" and Category Type Element

A significant feature of the RKMS set of metadata is that when it is implemented it can apply to records at any specified level of aggregation, as well as to business and recordkeeping business activities ranging from an individual transaction to the societal purpose it ultimately serves, and to agents acting at any level in organisational and social hierarchies. The concept of an Entity type "switch" has therefore been included in the set as represented in Figure 5. In any particular instance the Entity type will be "switched" to Business, Business Recordkeeping, Agent or Records, indicating what is being described.

The Category Type element further specifies the type of entity by defining which layer an entity belongs to, functioning as a kind of handshake, for example:

(The Appendix includes a full listing of the Category Types for Business, Business Recordkeeping, Agent and Records entities as defined in the RKMS.)

Data Model for the RKMS

As explained above, the RKMS is made up of a set of highly structured metadata elements and qualifiers. This structure is based on a data model for metadata developed by the World Wide Web Consortium (W3C)46 in the Resource Description Framework (RDF)47 initiative. The RDF data model is being considered for adoption by the Dublin Core (DC) and Australian Government Locator Service (AGLS) communities. Metadata is represented in this data model as "assertions" of the form:

This assertion says that the entity identified by the Entity Identifier has a property identified in the Schema by an Element Name. The property relates to an aspect of the entity. The specific value of the property in any particular instance is labelled Value.

Entities can have multiple properties, and properties can be repeated. For example, an Agent entity could be described using the RKMS as:

Qualifiers in the RKMS

The RKMS defines Element Names (such as Title and Date above) that can be used to describe Business, Record and Agent entities at a high level of abstraction. The RKMS also defines qualifiers that can be used to refine the semantics of these elements and to add precision to their values. It adopts three types of qualifiers identified in the Dublin Core initiative: Element Qualifiers, Value Qualifiers and Value Components. We draw these qualifiers using a variation of RDF proposed by Simon Cox.48

Element Qualifiers refine the meaning of an element by further specifying the relationship of the element value to the recordkeeping entity. That is, they are used to refine the meaning of a metadata description. For example, the meaning of the unqualified Date element in the example above is vague. It is defined in the RKMS to be "a time/date/date range of the Agent or events related to it." An Operational Period element qualifier could be applied to the Date element to specify the nature of this date:

Value Qualifiers, known as Schemes in the RKMS, identify authorities that provide typologies for values; controlled vocabularies for values; rules for constructing values; and rules for encoding values. For example, we might want to indicate we are using a standard format for encoding the Date of our Agent's Operational Period (in this case the format conforms to the ISO 8601 standard for dates):49

Similarly, the vocabulary used for the Functional Classification element could be controlled by the Keyword AAA Thesaurus, a hierarchical classifying scheme for administrative activities and functions, developed by the State Records Authority of New South Wales. Or the description of a Record-Agent relationship could be provided by the National Archives of Australia's Commonwealth Record Series system. In this case, example values are Agency Creating, Agency Recording, Agency Transferring, and Agency Controlling.

Value Components represent structure in a value by splitting the value into labelled components. For example, the value of the Mandate element for an Agent may be split into Description and Date components (in this case the date is a period of validity):

The empty oval in this figure is an artefact of the RDF notation. It means that there is no single value for the Mandate element. The value is a structured aggregate of the arcs leading from this oval. In this case, the Mandate has both a Date and a Description.

Extensibility: Inheritance of Metadata from other Metadata Schemata

The RKMS envisages use of metadata elements, element qualifiers and value components from other metadata schemas. These allow RKMS descriptions to be extended using the structure and semantics from other descriptive standards.

These other metadata schemas are identified in RDF diagrams as "names" preceding the element and qualifier names. For example, if we identify the National Archives of Australia's Commonwealth Record Series system with the name "NAACRS", then we can use the Agency Location and Agency Address metadata elements from this schema as value components that further describe the Place element in our example:

Note that all of the RKMS elements, qualifiers and value components in the previous diagrams are implicitly preceded by the RKMS "name." In these diagrams this "name" has been omitted for the sake of brevity and clarity.

Within individual elements, it is possible to extend the RKMS specification by referencing other metadata sets, e.g. the Pittsburgh Business Acceptable Communications Structure layer metadata elements and qualifiers could be used to extend the Preservation and Retrieval elements within the Records entity class.

Indeed, the RKMS provides for the importation of a full range of metadata elements, element qualifiers, value components, and value qualifiers from another metadata schema for any of its entities. For example, the Agency elements and qualifiers from the National Archives of Australia's Commonwealth Record Series system could be imported (Agency Number, Agency Title, Date, Function, Related Legislation, Agency and Series Relationships, Descriptive Note), or the elements that describe Records Creators could be inherited from ISAAR.

The RKMS also envisages inheritance of the data values from another schema. Particularly when specifying metadata associated with agents and business, it does not seek to create separate recordkeeping views of these entities. Rather it enables reference to metadata schemas that have been defined in other circumstances. For example, in Australia one way of identifying a commercial organisation is by its Australian Company Number (ACN) as defined and managed by the Australian Securities Commission (ASC). The Recordkeeping Metadata Schema can encompass the specification of a company ACN as an identifier, and enable inheritance of all of the data values contained in the Register of Australian Companies by explicitly naming the ASC as the originator of the metadata schema.

As shown above, the RKMS uses the convention of specifying the "names" of other metadata schemas in RDF diagrams to indicate inheritance of sets and sub-sets of metadata elements, qualifiers, and values, and to identify the authority by which they were created. However, the metadata community as a whole is only beginning to explore the complexity of, and relationships between, the schemas that govern and control metadata elements, qualifiers, and values. An exciting area for further research is the development of metadata regimes to better define and describe schemas and more rigorously depict and map the interrelationships between them. Formal descriptions and mappings could be used to automatically translate between metadata schemas, for example, a description and mapping of how the value components in two sets of Agent metadata can be deployed.

Expression of Complex Relationships

As outlined earlier, the development of the RKMS was influenced by the Australian series system, especially its emphasis on describing relationships between records and provenance entities, and Chris Hurley's writings on archival description and the functional context of recordkeeping. In describing the capacity of the Australian series system to depict relationships between records and agencies, Terry Cook recently stated that:

Australian archivists are now testing enriching this contextuality by adding other multiple relationships based on formal functions and the larger ambient provenance contexts beyond those of the immediate creator. All these interrelationships are not fixed one-to-one linkages, as in most archival descriptive approaches (despite some cross referencing), but rather exist as many-to-one, one-to-many and many-to-many relationships: between many series and one creator, between many creators and one series, between many creators and many series, between creators and other creators, between series and other series, and between series and creators to functions, and the reverse.50

The RKMS extends this tradition, enabling relationships to be set up between Business, Agent, and Record entities at any layer of aggregation and through time. Business to Business, Business Recordkeeping to Business Recordkeeping, Agent to Agent, and Record to Record relationships can also be depicted in and through time. Any single Agent, Business, Business Recordkeeping or Records entity may have relationships with like or unlike entities that extend through layers of aggregation in ways which establish a rich envelope of contextual metadata.

It is the Relation element in the RKMS which enables the expression of these complex, multiple relationships (see Figure 12 below).

Using the RDF based notation introduced above, we have been investigating the use of the RKMS to model these relationships. For example, at the Business Activity level of the hierarchy, the following relationships may exist between a Loan Application Management business activity (BUSINESS001), and the Loan Application Records (RECORD001):

This RDF diagram can be read as follows. The entity BUSINESS001 is a Business Activity, and the entity RECORD001 is a Record Aggregation. The BUSINESS001 has a Business to Record relationship with RECORD001. This relationship has a number of aspects:

This diagram illustrates contemporaneous relationships within one layer of the conceptual model (the Business Activity layer). Within this layer in the above diagram, it would also be possible to build in relationships between the Loan Officer (an Agent entity, belonging to the Category Type, Organisational Unit) and the Loan Management Business Activity, and between the Loan Officer and the Loan Application Records. The relationships could be further described using the qualifiers specified in the Relation element. These qualifiers provide for the definition of the relationship (e.g. the Loan Officer is responsible for Loan Management, the Loan Officer creates the Loan Application Records), the date range of the relationship, and the mandate governing the relationship (e.g. the Loan Officer is delegated to undertake the Loan Management activity by the Loan Management Authority, dated 1999-02-07). Other relationships within this layer might include the relationship between the Loan Application Records and the Loan Application Register that controls them.

As Figure 12 also illustrates, the RKMS enables depiction of relationships across layers, within entities, and through time. In our example, it would be possible to build in the following kinds of relationships:

Constructing these types of multi-dimensional relationships enables the reconstruction of recordkeeping systems in their functional and organisational contexts at any given point in time and through time, providing multiple views of a complex reality. This moves description in the continuum a long way beyond traditional approaches which "represent records and their context by freezing them in time", capturing the recordkeeping equivalent of early photographs, "incomplete streetscapes, ones from which all moving objects have 'vanished'." The RKMS currently employs a simple taxonomy of relationships between entity types.51

The RKMS currently employs a simple taxonomy of relationships between entity types. One example of these relationships is that expressed in the Element Qualifier, Record to Business, as shown in Figure 13 above. (Details of our simple taxonomy are provided in the description of the Relation element for each of the entities in the Appendix). Many metadata sets depict relationships as simple binary associations. As we have seen, the RKMS describes several aspects of relationships. The Relation element and its qualifiers include:

Although the RKMS set defines many aspects of relationships, they are not depicted as primary entities in the RKMS conceptual model (Figure 12). It was decided that modelling relationships as entities in this view of the RKMS would distract from the task of defining metadata for the primary recordkeeping entities (Agents, Business, Records). Given the complexity and importance of relationships in defining records context, this decision may be revisited in future revisions of the RKMS.

In extending the complex notions of relationships and in enhancing the understanding of their fundamental importance in defining the record's context - both values being present in Australian series-based archival systems -- the RKMS has pushed the description of relationships beyond the requirements of other information resource metadata sets. For this reason, while the conceptual understandings of relationships is well developed in the RKMS, issues to do with the taxonomy of relationships, the precision of the depiction of relationships and the metadata expression of such relationships is a fruitful area for future research in both the recordkeeping and wider metadata communities.

The SPIRT Recordkeeping Metadata Schema as a Framework for Mapping Metadata

As previously mentioned, one significant component of the research activity undertaken during the project has been an in-depth analysis of existing "best practice" generic metadata sets, such as Dublin Core, as well as metadata schemas specific to the records and archives sector. This was accompanied by the conceptual mapping of their elements in various combinations, followed, as the project advanced, by mapping the various iterations of the RKMS against these related schemas.

The following is a sample of the RKMS and ISAD(G)/ISAAR(CPF) Crosswalk:

 

ISAD(G): RKMS:
Level of Description RECORDS: Category Type (RKMS Scheme: Record Object, Record Aggregation, Corporate Archive, Collective Archives)
Dates of Creation RECORDS: Date (Element Qualifier: Record Creation)
Name of Creator RECORDS: Relation (Element Qualifier: Record-Agent Relationship; Value Components: Agent ID; Relationship Definition: Creating Agent)
  AGENTS: Title

All of the metadata elements identified in ISAD(G) and its companion standard, ISAAR(CPF), which provides a standardised way of describing personal and corporate records creators, can be mapped into the RKMS in the way illustrated in the above sample. ISAD(G) and ISAAR(CPF) metadata elements form a relatively small sub-set of the recordkeeping metadata identified by the RKMS as they are essentially concerned with the retrospective description of Records entities, associated with information in authority files about their creators.52

The mapping processes which informed the development of the RKMS metadata set itself point to one of the major uses of the Schema - as a framework within which other sets, targeted for application in specific sectors, can be developed and mapped against each other. For example, the National Archives of Australia's Recordkeeping Metadata Standard for Commonwealth Agencies, released in June 199953, was developed within this framework, and mapped against the more comprehensive RKMS. This enables equivalences and correspondences to be made between it and other metadata sets, each one being read against the standardised descriptions of recordkeeping metadata elements and qualifiers provided by the SPIRT Schema. The capacity for achieving semantic interoperability between specific implementations of metadata when mapped against a standard set is one of the resulting benefits for the recordkeeping community, nationally and internationally.

Currently, these mappings are presented in comparative tables of elements and qualifiers, or as text as in the sample from the RKMS and ISAD(G)/ISAAR(CFP) Crosswalk presented above. Possible future work could involve formalising these mappings in terms of the metadata data model. This formalisation would make the mappings amenable to machine processing, allowing semi-automated translation between metadata schemas. This could enable metadata, implemented in legacy systems, to be translated by current metadata schema, thus making the metadata interoperable in current system environments.

Metamodelling and the RKMS

Another important part of the SPIRT Research Project methodology has been the formal modelling of recordkeeping examples and the metadata set itself (i.e. metamodelling). Two formal modelling techniques were employed - RDF and ORM.

The Resource Description Framework (RDF) is an initiative of the World Wide Web Consortium. It is designed to support the creation, exchange and use of metadata. RDF provides a framework in which independent communities can develop metadata vocabularies that suit their specific needs and share those vocabularies with other communities. RDF defines a language for describing these vocabularies that is influenced by ideas for knowledge representation from the artificial intelligence community (e.g. CycL54 and KIF55 ) and schema representation from the database community (e.g. ORM56 and Entity Relationship Modelling57 ).

Like many metadata communities, the RKMS has adopted the RDF data model as a way of structuring and understanding its metadata. Prior to this decision, the set was defined using text descriptions that made it difficult to distinguish between element qualifiers, controlled lists of values, structured values, and so on. The RDF data model provided a means for clarifying the meaning of elements and values using qualifiers and gave the set a language for distinguishing these concepts.

Another related benefit was that the RDF model showed how other metadata sets could co-exist and be included within the RKMS descriptions. RDF allows the incorporation of metadata terms and definitions from other metadata authorities as described above.

Finally, RDF provided a convenient graphical representation of RKMS metadata descriptions, as illustrated in Figures 6-11 and 13 above.

Object-Role Modelling (ORM)58 is a method for designing database models. It is a conceptual modelling approach, that is, it specifies the model using concepts and language easily understood by non-technical users. It views the world in terms of objects, and the roles they play. Using the associated conceptual schema design procedure, these objects and roles are discovered and expressed using elementary natural language sentences. Object-Role Modelling is particularly suited to the task of modelling a data set such as the RKMS (that is, metamodelling) for two main reasons. Firstly, it is more expressive than many other data modelling techniques (such as Entity-Relationship modelling59). This expressiveness allows a high level of detail to be included and hence more rigorous analysis. Secondly, an ORM diagram can be populated with data examples, allowing for validation by an expert using natural language and examples from the profession or domain being modelled.

Through the process of describing our entities in natural language and then ORM diagrams, the technique clarified which entities where important in our descriptions, and the relationships between those entities. In particular, it became apparent that Recordkeeping Business metadata was an extension of Business metadata, and so could be modelled as a sub-type of the Business entity.

The initial aim of the metamodelling was not to produce implementation models but to highlight inconsistencies and gaps in the set, enable precise description and rigorous structuring of the RKMS, provide for better specification of relationships to other schemas, and serve as a graphical means of communicating the RKMS.

However as the modelling progressed, further exploration was undertaken of features such as the use of qualifiers, the extensibility of metadata sets, the depiction of relationships, and the identification, description and mapping of schemas. It is anticipated that future use of metamodelling will lead to the development of a RDF schema, enabling the expression of the RKMS in Extensible Markup Language (XML)60.

XML is a method for designing and putting structured data in a text file. It has a number of features that are useful in archival descriptions: it is unambiguous, easy to generate and read (by a computer), extensible, supports internationalisation, and is platform-independent. Additionally, XML files can be self-describing - that is, they can contain a definition of their own structure.

The population of the metamodels with more extensive examples, enabling further testing and validation, is also planned, as well as more complete depiction and expression of the complex relationships identified in the RKMS. Finally, it is intended that formal modelling of the relationships between metadata schemas be explored. Currently, RDF allows simple identification of external schemas used in a metadata description. This is not sufficient for Recordkeeping description, where external metadata schemas may also need to be described in terms of their period of validity, authority and so on. These requirements will be fed back into the metadata modelling community.

Implementation Issues and the RKMS

The RKMS as presented in this paper is modelled conceptually. As yet little implementation modelling has been attempted, although, as outlined above, the ongoing metamodelling in RDF will provide one kind of implementation model: the expression of the RKMS metadata in XML. This will allow RKMS metadata to be used in generic information resource description and discovery contexts (such as Dublin Core) as well as in recordkeeping-specific contexts, for example in web-based directories of online services. It is anticipated that future modelling may well take different "views" of the RKMS metadata set, e.g. modelling may focus on "events", or treat "relation", "mandates" and "business rules" as entities rather than elements. It is hoped that these alternate models will highlight elements in the current RKMS that need further refinement or that can be described more effectively. The RKMS was conceived as implementation neutral. The Schema specifies in a formal, standardised way the layers of metadata needed to support persistence of records in their business contexts through time and space for as long as they are of continuing value. But, it does not define any technological restrictions on how its elements are to be incorporated into systems. It does not presume use of any particular software architecture. It does not specify where, when, or how the metadata will be captured. The concern is that wherever, whenever, and however metadata is captured, it will be persistently associated with the record object. Although metadata standards per se cannot guarantee such persistent associations, they can clearly demonstrate that assuring such persistence is an imperative when implementing recordkeeping metadata.

In the long-term, implementation of recordkeeping metadata may occur in integrated systems environments with some recordkeeping metadata being embedded in or encapsulating self-managing records objects, and other recordkeeping metadata being created and maintained in document management, workflow, enterprise knowledge management and archival systems. The viability of such implementation strategies will depend on the feasibility of achieving persistent associations through embedding, encapsulation or the establishment of robust links between record objects and metadata created and maintained in other systems. In the short-term, however, uncertainties about persistence may lead to implementation of recordkeeping metadata in records-centric ways - if other systems cannot be trusted to sustain the links over time, then metadata must be brought explicitly within the boundaries of the records system itself. This might involve capturing metadata directly into the records system or importing it from the other enterprise systems in which it was originally created.61

Conclusion

As the SPIRT Project was reaching its conclusion the Project team quickly realised that it was not the beginning of the end but rather the end of the beginning. Work is now proceeding on related research deliverables, including further modelling of the full metadata set, as well as sub-sets, layers and different "views" of the set in RDF and ORM. A User Guide to the Schema is planned, as well as the prototyping of a system that deploys the RKMS in an integrated systems environment. The development of the RKMS as a National Standard is proceeding. A number of compelling areas for further research work have been identified, including the development of typologies of recordkeeping relationships, e.g. standardised sets of Agent to Record or Record to Record relationship definitions, and better ways of depicting and expressing them in metadata. Continuing input into research and development in the records and archives community internationally as well as the broader metadata community nationally and internationally has also been identified as a priority for the Australian recordkeeping community.

The RKMS uses recordkeeping understandings to make explicit connections between business, defined broadly to encompass all social and organisational activity, the people or agents who do business, and the records which are by-products of that business. It embraces traditional articulations of recordkeeping while envisioning future articulations. Part of this vision sees records as potentially self-managing information objects, intelligent agents that transact business in complex and dynamic organisational and social environments - the rich metadata provided through the RKMS supporting the necessary functionalities. This vision links the dynamic world of business and social activity to the passive world of information resource management in cyberspace.

*Acknowledgments: Funding for the development of the Australian Recordkeeping Metadata Schema was provided by the Australian Research Council and a consortium of industry partners (National Archives of Australia, State Records Authority of New South Wales, Queensland State Archives, Records Management Association of Australia, and Australian Council of Archives). Nigel Ward's involvement in the Project and the modelling work reported in this paper have been funded by the Co-operative Research Centre for Enterprise Distributed Systems Technology (DSTC) through the Federal Government's CRC Program (Department of Industry, Science & Resources). We acknowledge the contribution of other Project team members and associates, particularly Kate Cumming, APA(I) scholarship holder, Luisa Moscato (1998), Dr Linda Bird, DSTC, and Geoff Acland-Bell (for the expert rendering of the conceptual models). We also acknowledge the input of members of the Project Steering Committee, Steve Stuckey (National Archives of Australia, NAA), David Roberts (State Records Authority New South Wales, SRNSW), Lee McGregor (Queensland State Archives), Dennis Wheeler (Records Management Association of Australia) and Gavan McCarthy (Australian Council of Archives), and our Expert Reference Group of Australian and international reviewers David Bearman (Archives and Museum Informatics), Adrian Cunningham (NAA), Wendy Duff (University of Toronto), Anne Gilliland-Swetland (UCLA), Hans Hofman (Netherlands National Archives), Chris Hurley (New Zealand National Archives), Tony Leviston (SRNSW), John McDonald (National Archives of Canada), Nancy McGovern (University College London), Tony Newton (SRNSW), Dagmar Parer (NAA), and Catherine Robinson (SRNSW), Frank Upward (Monash University). We owe a particular debt to Frank Upward, Chris Hurley and David Bearman whose work on the records continuum, archival description and electronic recordkeeping respectively has stimulated and informed us.

Endnotes

1 US Department of Defense, DOD 5015.2-STD, Design Criteria Standard for Electronic Records Management Software Applications (November 1997). Available at http://jitc-emh.army.mil/recmgt/dod50152.doc. The Standard includes specification of the descriptive metadata that records management software should capture.

2 International Council of Archives, ISAD(G): General International Standard Archival Description, (Ottawa, 1994). Available at http://data1.archives.ca/ica/cgi-bin/ica?04_e.

3 The term "recordkeeping community" is used in Australia to identify the community of records managers and archivists who consciously work under the "recordkeeping umbrella". Their thinking and practice is informed by records continuum perspectives and they have worked together on major initiatives such as the Australian Records Management Standard, AS 4390, and the Australian Records and Archives Competency Standards".

4 The acronym SPIRT derives from the name of the Research Grant which funded the Project, Strategic Partnership with Industry - Research & Training (SPIRT) Support Grant, which provides for joint funding by the Australian Research Council and the Industry partners. The project was administered by Monash University on behalf of a collaborative Project team of researchers and industry partners, including the University of New South Wales, 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 Project Chief Investigators were 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. For background information on the project and its evolution, see Sue McKemmish, Adrian Cunningham and Dagmar Parer, "Metadata Mania: Use of Metadata for Electronic Recordkeeping and Online Resource Discovery" in Place, Interface and Cyberspace: Archives at the Edge, Proceedings of the 1998 Conference of the Australian Society of Archivists, Fremantle 6-8 August 1998 (Canberra, Australian Society of Archivists, 1999), pp. 129-144; and Sue McKemmish and Glenda Acland. "Accessing Essential Evidence on the Web: Towards an Australian Recordkeeping Metadata Standard", AusWeb99 Conference Proceedings. Available at http://ausweb.scu.edu.au/aw99/papers/mckemmish. For details of project outcomes and updates, visit the project web site at http://www.sims.monash.edu.au/rcrg/research/spirt/index.html.

5 For more information on this initiative, see the Dublin Core Metadata Initiative Web Site, http://purl.oclc.org/metadata/dublin_core/ and Stuart Weibel, "The State of the Dublin Core Metadata Initiative April 1999", D-Lib Magazine, 5, no. 4 (April 1999). Available from http://www.dlib.org/dlib/april99/04weibel.html.

6 For a more detailed exploration of these issues, see Sue McKemmish, "Are Records Ever Actual?" in The Records Continuum: Ian Maclean and Australian Archives first fifty years, edited by Sue McKemmish and Michael Piggott (Clayton, Ancora Press in association with Australian Archives, 1994), pp. 187-203, and Barbara Reed, "Metadata: Core Record or Core Business", Archives and Manuscripts 25, no. 2 (November 1997), pp. 218-41.

7 Frank Upward, "Structuring the Records Continuum Part One: Post-custodial Principles and Properties", Archives and Manuscripts 24, no. 2 (November 1996), pp. 268-285, and "Structuring the Records Continuum Part Two: Structuration Theory and Recordkeeping", Archives and Manuscripts 25, no. 1 (May 1997), pp. 10-35.

8 See, for example, "The Making and Keeping of Records: (1) What Are Finding Aids For?", Archives and Manuscripts 26, no.1 (May 1998), pp. 57-77; "What, If Anything, Is A Function?", Archives and Manuscripts 21, no.2 (November 1993), pp. 208-20; and "Ambient Functions: Abandoned Children to Zoos", Archivaria 40 (Fall 1995), pp. 21-39.

9 See in particular: "Record-Keeping Systems", Archivaria 36 (Autumn 1993), pp. 16-37; "Documenting Documentation", Archivaria 34 (Summer 1992), pp. 33-49; "Item Level Control and Electronic Recordkeeping", Archives and Museum Informatics 10 (1996), pp. 195-245 and (with Ken Sochats) "Metadata Requirements for Evidence." Available from http://www.sis.pitt.edu/~nhprc/BACartic.html.

10 Sue McKemmish, "Yesterday, Today and Tomorrow: A Continuum of Responsibility", in Preserving Yesterday, Managing Today and Challenging Tomorrow: Proceedings 14th National Convention RMAA, 1997, (Perth, Records Management Association of Australia, 1997), p. 19; also published in Naar een nieuw paradigma in de archivistiek (redactie P J Horsman, F C J Ketelaar, T H P M Thomassen), Jaarboek 1999 ("s-Gravenhage: Stichting Archiefpublicaties, 1999).

11 AS 4390.1-1996 Australian Standard: Records Management, (Homebush: Standards Australia, 1996); Records and Archives Competency Standards November 1997 (National Finance and Industry Training Advisory Body Ltd., Australian National Training Authority, 1997); for details of availability see http://www.standards.org.au/.

12 AS 4390, Part 1: General, pp. 6-7.

13 Schema is used to mean the semantic and structural definition of the metadata used to describe recordkeeping entities. A schema describes the names of metadata elements, how they are structured, their meaning etc. The metadata community also refers to a metadata schema as a metadata set or specification.

14 Within the Australian archival community the joint Australian Society of Archivists/Australian Council of Archives Committee on Descriptive Standards has endorsed the SPIRT Recordkeeping Metadata Schema as a framework for the Committee's future work on the development of domain specific recordkeeping metadata and archival descriptive standards. The Standards Australia Committee IT/21, responsible for AS4390 Australian Standard: Records Management, recently adopted a proposal by the Chair of this Committee to develop the SPIRT Recordkeeping Metadata Schema into a framework Australian Standard for Recordkeeping Metadata.

15 Information accessibility initiatives in Australia, as elsewhere, are addressing challenges relating to dealing interoperably at whole-of-government and global levels with facilitating resource description and discovery, e.g. the Australian Government Locator Service initiative (http://www.naa.gov.au/govserv/agls/), the whole-of-government directory GOLD - Government Online Directory (based on the X500 Directory Structure Standard) - and the web-based Functional Index of Federal Government (http://www.fedgov.au/). In response to the policy directions announced in late1997 as part of the Australian Government's Investing for Growth strategy (http://www.dist.gov.au/growth/html/infoage.html), a range of initiatives have also been taken to support and encourage individuals and organisations to transact business electronically. They include initiatives relating to the establishment and accessibility of online government services and gateways to information about government services and service delivery points, e.g. the federal government's Government Online (http://www.ogo.gov.au/) and Business Entry Point (BEP) (http://www.business.gov.au/). The thrust of government online initiatives is towards fully enabled online transactions as a significant component of service delivery. The Electronic Transactions Bill 1999 (http://law.gov.au/ecommerce/interim3.html) is a model law which potentially provides the regulatory framework for the use of electronic communications in government transactions (defined broadly to encompass all of the activities of government agencies in their roles as service providers).

16 Terry Cook, "The Concept of the Archival Fonds: Theory, Description, and Provenance in the Post-custodial Era", in The Archival Fonds: From Theory to Practice, ed. Terry Eastwood, (Ottawa, Bureau of Canadian Archivists, 1992) p. 38; see also "Electronic Records, Paper Minds: The revolution in information management and archives in the post-custodial and post-modern era", Archives and Manuscripts 22, no. 2 (November 1994), pp. 300-329.

17 See for example "Building Record-Keeping Systems: Archivists Are Not Alone On The Wild Frontier", Archivaria 44 (Fall 1997), pp. 44-71.

18 Wendy Duff, "Harnessing the Power of Warrant", American Archivist 61 (Spring 1998), pp. 88-105.

19 University of Pittsburgh, School of Information Sciences, "Functional Requirements for Evidence in Recordkeeping", available from http://www.sis.pitt.edu/~nhprc/.

20 University of British Columbia, School of Library, Archival and Information Studies, "Protection of the Integrity of Electronic Records Project", available from http://www.slais.ubc.ca/users/duranti/; see also Luciana Duranti and Heather MacNeil, "The Protection of Electronic Records: An Overview of the UBC-MAS Research", Archivaria 42 (Fall 1996), pp. 46-67.

21 The concept of contextual metadata being "in the air" comes from Chris Hurley who has written extensively about issues relating to archival description, finding aids and standards. See in particular: "The Making and Keeping of Records: (1) What Are Finding Aids For?" Archives and Manuscripts 26, no. 1 (May 1998), pp. 57-77.

22For the use of the term metadata in a narrower sense and from a life cycle perspective, see in particular the writings of Heather MacNeil, e.g. "Metadata Strategies and Archival Description: Comparing Apples to Oranges", Archivaria 39 (Spring 1995), pp. 22-32.

23 AS4390 Australian Standard: Records Management

24 Chris Hurley, "The Making and Keeping of Records", p. 74.

25 For more information about the Australian Series System, see the following papers, published in The Records Continuum: Ian Maclean and Australian Archives first fifty years, edited by Sue McKemmish and Michael Piggott (Clayton: Ancora Press in association with Australian Archives, 1994):

Mark Wagland & Russell Kelly, "The Series System - A Revolution in Archival Control", pp. 131-149.
Chris Hurley, "The Australian (Series) System: An Exposition", pp. 150-172.
Sue McKemmish, "Are Records Ever Actual?" pp. 187-203.

See also Peter Scott, "The Record Group Concept: A Case for Abandonment", American Archivist 29, (no. 4, October 1966).

26 Terry Cook, "What is Past is Prologue: A History of Archival Ideas Since 1898, and the Future Paradigm Shift", Archivaria 43 (Spring 1997), pp. 38-39. The quotation also references the following writings of Chris Hurley relating to the functional context of records: "What, If Anything, Is A Function?" Archives and Manuscripts 21, no. 2 (November 1993), pp. 208-20; and "Ambient Functions: Abandoned Children to Zoos", Archivaria 40 (Fall 1995), pp. 21-39.

27 Chris Hurley, "The Australian (Series) System", p. 169.

28 For further details of the Dublin Core (DC) initiative, see http://purl.oclc.org/metadata/dublin_core/.

29 For more information on the Australian Government Locator Service (AGLS) initiative, see Australian Government Locator Service (AGLS) Manual for Users, Version 1.1: 1999-06-09, (Canberra: Office of Government Online and National Archives of Australia, 1999). Available at http://www.naa.gov.au/govserv/agls/.

30 Sue McKemmish, Glenda Acland and Barbara Reed, "Towards a Framework for Standardising Recordkeeping Metadata: The Australian Recordkeeping Metadata Schema", Records Management Journal 9, no. 3 (December 1999), pp. 177-202.

31 Information on the Recordkeeping Metadata Standard for Commonwealth Agencies can be found at http://www.naa.gov.au/govserv/techpub/rkms/intro.htm.

32 The Committee has also proposed to Standards Australia that this codification be developed into an Australian National Standard within the framework provided by the RKMS.

33 Standards Australia, AS4390-1996, Australian Standard: Records Management. For details of availability see http://www.standards.org.au/.

34 The Australian Society of Archivists commissioned Chris Hurley to collect and systematise information about how Australian archival institutions structure and use descriptive data. The outcome was the Australian Common Practices Manual. It is descriptive of Australian common practice within a conceptual framework which presents information about descriptive data in relation to four kinds of entities - ambience, provenance, records and contents entities. Ambient entities refer to organisations, families, and groupings of agencies by jurisdiction or competence; provenance entities to persons and corporate bodies which create, maintain, control or use records; records entities to record aggregates; and content entities to record items. For more detail, see Chris Hurley, "Data, Systems, Management, and Standardisation", Archives and Manuscripts 22, no. 2 (November 1994), pp. 338-59.

35 The Design Criteria Standard for Electronic Records Management Software Applications can be accessed via http://jitc-emh.army.mil/recmgt/dod50152.doc.

36 The "Functional Requirements for Evidence in Recordkeeping Project" reports can be found at http://www.sis.pitt.edu/~nhprc/prog1.html.

37 The "Protection of the Integrity of Electronic Records Project" and its outcomes are described at http://www.slais.ubc.ca/users/duranti/.

38 University of Pittsburgh, School of Information Sciences, "Metadata Specifications Derived from the Functional Requirements: A Reference Model for Business Acceptable Communications", available from http://www.sis.pitt.edu/~nhprc/meta96.html. The BAC Model envisions records as dynamic, self-managing metadata encapsulated objects. The metadata is specified in layers, namely the handle (or identification), structure, content, context, terms and conditions, and use layers. The context metadata is most relevant to the immediate transactional business context of the record, and does not provide for description of the broader contexts in which records are created and used.

39 ISAD (G) was designed to provide a standardised set of elements for describing records in archival custody (archives), its main objective being to facilitate access by researchers. It enables the description of archives at various levels of aggregation. Its companion standard, ISAAR (CPF), enables the descriptions of archives using ISAD(G) to be linked to standardised information about records creators. Information about both the General International Standard for Archival Description (Ottawa, 1994), and the International Standard Archival Authority Record For Corporate Bodies, Persons, and Families (Ottawa, 1996) is available via http://data1.archives.ca/ica/cgi-bin/ica?04_e.

40 EAD: Encoded Archival Description Application Guidelines Version 1.0, prepared by the Encoded Archival Description Working Group of the Society of American Archives (Chicago: SAA, 1999); EAD elements are also listed at http://lcweb.loc.gov/ead/. It was designed to provide a data structure standard for archival finding aids so that they could be made available via the Internet, thus providing ready access to detailed information about archival collections. It further provides for the embedding or linking of digitised images of archival materials.

41 Public Record Office of Victoria, Victorian Electronic Records Strategy Final Report, 1998, available at http://home.vicnet.net.au/~provic/vers/final.htm. The VERS project developed functional specifications for an electronic archival system that captures records and their descriptive metadata as PDF files. The descriptive metadata is also captured in an XML database for management and resource discovery purposes. The metadata set specified as part of the VERS project is essentially a scaled-down version of the Business Acceptable Communications Model metadata. For more information about the VERS project, see also: Justine Heazlewood et. al., "Electronic Records: Problem Solved?", Archives and Manuscripts 27, no. 1 (May 1999), pp. 96-113.

42 Project Team member Kate Cumming is developing a series of crosswalks as part of her Masters thesis research work.

43 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" in David Bearman, Eric Miller, Godfrey Rust, Jennifer Trant and Stuart Weibel, "A Common Model to Support Interoperable Metadata: Progress report on reconciling metadata requirements from the Dublin Core and INDECS/DOI Communities." D-Lib, 5, no. 1, January 1999. Available at http://www.dlib.org/dlib/january99/bearman/01bearman.html.

44 The concept of mandate used in the Project has drawn on the work of the University of Pittsburgh "Functional Requirements for Evidence in Recordkeeping Project" on warrants for recordkeeping in organisational contexts, in particular the work of Wendy Duff (see "Harnessing the Power of Warrant"), and on the writing of Sue McKemmish on the broad social mandates found in sociology, creative writing and reflective narratives for the role of personal recordkeeping in witnessing to individual lives and constituting part of society's collective memory and cultural identity ("Evidence of Me…", Archives and Manuscripts 24, no. 1 (May 1996), pp. 28-45).

45 The Business entity class comprises entities represented on the Transactional Axis of the Model, the Agent entity class those on the Identity Axis, and the Records entity class those on the Recordkeeping Axis. For more information, see Frank Upward, "Structuring the Records Continuum Part One: Post-custodial Principles and Properties."

46 World Wide Web Consortium Homepage: http://www.w3.org/.

47 W3C RDF Homepage: http://www.w3.org/RDF.

48 Simon Cox has written an excellent discussion paper for the DC community on issues relating to structure, authority and qualification in DC: http://www.agcrc.csiro.au/projects/3018CO/metadata/dc-guide.

49 ISO 8601: 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times."

50 Terry Cook, "The Concept of the Archival Fonds: Theory, Description, and Provenance in the Post-custodial Era", p. 38.

51 Sue McKemmish, "Are Records Ever Actual?" p. 189.

52 See endnote 38 for a brief outline of the purposes of ISAD(G) and ISAAR(CPF).

53 See http://www.naa.gov.au/govserv/techpub/rkms/intro.htm.

54 CycL: The CYC Representation Language; http://www.cyc.com/tech.html#cycl

55 KIF: Knowledge Interchange Format; see http://logic.stanford.edu/kif/kif.html

56 T. Halpin, Conceptual Schema & Relational Database Design, Second Edition (Prentice Hall Australia, 1995).

57 Entity Relationship (ER) Modelling is a popular modelling technique which represents the high-level concepts in the users' world, in terms of entities and the relationships between these entities. Each entity has one or more 'attributes' associated it with it, which represent the properties of that entity. ER modelling is primarily used today as part of the process of database design.

58 T. Halpin, Conceptual Schema & Relational Database Design.

59 A comparison of ER modelling and ORM can be found in the December 1999 issue of the Journal of Conceptual Modeling. See: http://www.inconcept.com/JCM/index.html

60 Extensible Markup Language (XML) 1.0; World Wide Web Consortium Recommendation; http://www.w3.org/TR/REC-xml.

61 This is the approach taken by the Victorian Electronic Records Strategy (VERS) project, amongst others. VERS defines metadata for specific levels of records aggregation, as well as specifying agent and business metadata to be associated with the record itself. For more information on the VERS project: http://home.vicnet.net.au/~provic/vers/final.htm.

Appendix

The Appendix dated 23 March 2000 published with the article in "Archivaria" #48 gave a summary of the RKMS elements and qualifiers from the penultimate draft of the RKMS Release Version 1.0, the version current at the time of going to press. The final version of the RKMS, dated 31 May 2000, has some slight modifications. For the final version of the Summary of Elements and Qualifiers see Deliverables - Summary of RKMS Elements and Qualifiers.

 

RKMS.RECORDS  
RKMS01 CategoryType  
RKMS02 Identifier  
RKMS03 Title Element Qualifiers: May be used to specify type of title, e.g. Main, Alternative, Abbreviation, Assigned
Value Components: Name, Date
RKMS04 Date Element Qualifiers: May be used to specify type of date, e.g. Executed, Implemented, Valid
RKMS05 Mandate Value Components: Title, ID, Date, Description, Jurisdiction
RKMS06 Place Element Qualifiers: May be used to specify type of place, e.g. Business Activity Area, Service Delivery Point
Value Components: Title, ID, Date
RKMS07 FunctionalClassification Element Qualifiers: Ambient Descriptor, Functional Descriptor, Activity Descriptor, Transaction Descriptor, Function/Activity Descriptor,Activity/Transaction Descriptor,Ambient/Functional/Activity/Transaction Descriptor,Functional/Activity/Transaction Descriptor
Value Components: Descriptor(s), ID, Date, Description
RKMS08 Relation Value Components: Related To, Type, Definition, Date, Mandate, Business Rules
RKMS09 Abstract  
RKMS10 Language  
RKMS11 BusinessRules Value Components: Title, ID, Date, Description, System Specifications
RKMS12 CategoryType  
RKMS13 Identifier  
RKMS14 Title Element Qualifiers: May be used to specify type of title, e.g. Main, Alternative, Abbreviation, Assigned
Value Components: Name, Date
RKMS15 Date Element Qualifiers: May be used to specify type of date, e.g. Executed, Implemented, Valid
RKMS16 Mandate Value Components: Title, ID, Date, Description, Jurisdiction
RKMS17 Place Element Qualifiers: May be used to specify type of place, e.g. Business Activity Area, Service Delivery Point
Value Components: Title, ID, Date
RKMS18 FunctionalClassification Element Qualifiers: Ambient Descriptor, Functional Descriptor, Activity Descriptor, Transaction Descriptor, Function/Activity Descriptor,Activity/Transaction Descriptor,Ambient/Functional/Activity/Transaction Descriptor,Functional/Activity/Transaction Descriptor
Value Components: Descriptor(s), ID, Date, Description
RKMS19 Relation Value Components: Related To, Type, Definition, Date, Mandate, Business Rules
RKMS20 Abstract  
RKMS21 Language  
RKMS22 BusinessRules Value Components: Title, ID, Date, Description, System Specifications
RKMS23 CategoryType  
RKMS24 Identifier  
RKMS25 Title Element Qualifiers: May be used to specify type of title, e.g. Main, Alternative, Abbreviation, Assigned
Value Components: Name, Date
RKMS26 Date Element Qualifiers: May be used to specify type of date, e.g. Born, Died, Operational Period, Established, Disestablished
RKMS27 Mandate Value Components: Title, ID, Date, Description, Jurisdiction
RKMS28 Place Element Qualifiers: May be used to specify type of place, e.g. Business Address, Residential Address, Birth Place, Contact Address, Citizenship
Value Components: Title, ID, Date
RKMS29 FunctionalClassification Element Qualifiers: Ambient Descriptor, Functional Descriptor, Activity Descriptor, Transaction Descriptor, Function/Activity Descriptor,Activity/Transaction Descriptor,Ambient/Functional/Activity/Transaction Descriptor,Functional/Activity/Transaction Descriptor
Value Components: Descriptor(s), ID, Date, Description
RKMS30 Relation Value Components: Related To, Type, Definition, Date, Mandate, Business Rules
RKMS31 Abstract  
RKMS32 Language  
RKMS33 CategoryType  
RKMS34 Identifier  
RKMS35 Title Element Qualifiers: May be used to specify type of title, e.g. Main, Alternative, Abbreviation, Assigned
Value Components: Name, Date
RKMS36 Date Element Qualifiers: May be used to specify type of date, e.g. Transaction Recorded, Captured, Contents Authored, Sent, Received, Transmitted, Transferred
RKMS37 Mandate Value Components: Title, ID, Date, Description, Jurisdiction
RKMS38 Place Element Qualifiers: May be used to specify type of place, e.g. Repository Location, Store Location, Server Location, Place of Inspection
Value Components: Title, ID, Date
RKMS39 FunctionalClassification Element Qualifiers: : Ambient Descriptor, Functional Descriptor, Activity Descriptor, Transaction Descriptor, Function/Activity Descriptor,Activity/Transaction Descriptor,Ambient/Functional/Activity/Transaction Descriptor,Functional/Activity/Transaction Descriptor
Value Components: Descriptor(s), ID, Date, Description
RKMS40 Relation Value Components: Related To, Type, Definition, Date, Mandate, Business Rules
RKMS41 Abstract  
RKMS42 Language  
RKMS43 SubjectClassification Value Components: Descriptor(s), ID, Date, Description
RKMS44DocumentaryForm Value Components: Title, ID, Date, Description
RKMS45 Appraisal Element Qualifiers: Recordkeeping Requirement, Disposal, Sentencing, Destruction, Retention, Transfer
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS46 Control Element Qualifiers: Registration, Classification, Indexing, Context Description, Custody, Metadata Management, Arrangement
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS47 Preservation Element Qualifiers: Storage, Refreshment, Migration, Conservation
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS48 Retrieval Element Qualifier: Rendering, Representation, Transmission
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS49 Access Element Qualifier: Rights, Restrictions, Permissions, Conditions
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS50 Use Element Qualifier: Rights, Restrictions, Permissions, Conditions
Value Components: Statement, Date, Mandate, Business Rules, System Specifications
RKMS51 EventHistory Value Components: Event Type, Event Description, Event ID, Event Date, Mandate, Business Rules, System Specifications, Action Officer, User

Notes 1. All Elements, Element Qualifiers and Value Components may be further qualified with reference to the Schemes which authorise their typologies, controlled vocabularies, structures, and encoding. In some cases the RKMS itself provides Schemes e.g. RKMS Extension for ISO 8601 (which enables expression of open-ended date ranges), RKMS Category Type Scheme (used with all Category Type elements and Relation.Type value components), RKMS Entity Relationships Scheme (which may be used with all Relation.Definition value components), and RKMS Business-Recordkeeping Functions and Activities Scheme (which may be used for BusinessRecordkeeping.Title, BusinessRecordkeeping.Identifier and Business.Recordkeeping.FunctionalClassification elements and Records.EventHistory.EventType value component).

Back to top