|Full Title:||SPIRT Recordkeeping Metadata Project|
|Dates:||1998 – 1999|
- Re-Modelling the RKMS Set
- Identifying and Describing Metadata Schemas
- Formal Mapping of Metadata Schemas
- Persistence and New Recordkeeping Paradigms
- RKMS Business-Recordkeeping Functions and Activities Scheme
- RKMS Entity Relationship Scheme
The current RKMS conceptual framework, and its instantiation in terms of metadata element sets will be re-examined, perhaps in terms of different “views” of the set, e.g. modelling may focus on “events”, or treat “relation”, “mandates” and “business rules” as entities rather than elements.
Part of this work will include further meta-modelling in RDF and ORM of the full RKMS metadata set, as well as its sub-sets and layers. The population of the metamodels with more extensive examples, enabling further testing and validation, is also planned.
Also under investigation is a more complete depiction and expression of the complex relationships identified in the RKMS. The Recordkeeping Metadata Project has extended the Australian Series System’s complex notions of recordkeeping relationships and understandings of their fundamental importance in defining the record’s context. The RKMS has also pushed the description of relationships beyond the requirements of other information resource metadata sets. 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.
One of the preliminary findings of the modelling of examples of relationships undertaken so far is that many of the relationships in a recordkeeping context may be three- or even four-way relationships. Many of the binary relationships expressed in the modelling implicitly assumed a third or even fourth party to the relationship. For example, a binary relationship between Agents might be described as a “predecessor-successor” relationship. However implicit in this description is the unstated fact that the inheritance of a Business Function is the basis for defining the relationship as one of “predecessor-successor”. Similarly when a relationship between an Agent and a Record Object is described as being one of “created by”, implicit in this description is the understanding of what it means to be a “records creator” (a records creator is defined in terms of the responsibility of an Agent for the function, activity or transaction documented in the record).
Although the RKMS set defines many aspects of relationships, they are not depicted as primary entities in the RKMS conceptual model. 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). However, given the complexity and importance of relationships in defining records context and the possibility that depicting only binary relationships is too limiting, this decision will be revisited as part of the re-modelling work.
Most metadata communities envisage use of metadata elements, qualifiers and schemes from external metadata schemas. Use of external metadata requires mechanisms for including and defining external metadata schemas. An exciting area for further research that is closely related to the establishment of metadata registries is the development of metadata sets to better define and describe schemas. Recordkeeping description metadata has unique needs in this regard. For recordkeeping purposes, the external schemas may need to be described in terms of their period of validity, authority and so on.
Future work includes the development of a RDF schema for RKMS. RDF has mechanisms for defining metadata schemas. RDF has mechanisms for including external metadata schemas and capturing the complex metadata structure found in RKMS (value components etc.). RDF also has the feature of having an XML syntax (Extensible Markup Language, http://www.w3.org/TR/REC-xml). XML has a number of features useful for archival descriptions: it is unambiguous, easy to generate and read (by a computer), extensible, supports internationalisation, and is platform-independent. RDF/XML can also be self-describing – that is, an RDF/XML description can contain a pointer to a definition of its own structure.
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. Mapping techniques that can more rigorously depict and map the interrelationships between them are needed.
The development of the Recordkeeping Metadata Project has involved extensive mapping of recordkeeping metadata sets. The RKMS has been designed as a framework in which other sets can be mapped against each other. The framework enables the metadata in specific implementation sets to be read against the standardised descriptions of recordkeeping metadata elements and qualifiers provided by the Schema. This facilitates the discovery of equivalences and correspondences between them. The capacity for achieving semantic interoperability between specific implementations of metadata when mapped against a standardised set is one of the resulting benefits for the recordkeeping community, nationally and internationally. However, currently, these mappings are presented in comparative tables of elements and qualifiers, or as text. There is a further research need to formalise 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 also enable metadata, implemented in legacy systems, to be translated by current metadata schema, thus making the metadata interoperable in current system environments.
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. It does not define any technological restrictions on how its elements are to be incorporated into systems, presume the use of any particular software architecture, or specify where, when, or how the metadata will be captured.
In the short-term, 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.
Issues of persistence currently manifest themselves in the RKMS Identifier element. One important use of this element is to point or provide a link to the description of an entity. It must therefore be able to uniquely identify the entity in the broadest domain in which it is likely to be used as a pointer or link. Sometimes there are global or universal schemes of identifiers in place, e.g. the ISBN in the global publication world or Australian Company Numbers in Australia. However, for many entities there are no comparable schemes in place. For this reason the identifier element may need to include “domain” information about the broader context of the entity.
The value of the Identifier element is a text string that acts as a reference to the entity. In general, understanding this reference involves understanding the context of the reference. For example, the identifier “ACN 052 372 577” is probably understandable within an Australian context as an Australian Company Number, but would probably not be well understood outside Australia. For this reason, it is recommended that identifiers contain context information that allows understanding beyond the immediate domain of application. For instance, the previous example could be better written as “[Australian Securities and Investments Commission, Australian Company Number] ACN 052 372 577”.
The RKMS also addresses some persistence issues by allowing record context to be embedded within metadata descriptions rather than being captured as a link to an external entity. For example, Business-Recordkeeping activities are captured either separately from the Records as Business-Recordkeeping entities referenced from a Records entity description, or within the description of the Records entity itself using the Appraisal, Control, Preservation, Retrieval, Access, and Use metadata elements. In this way, the RKMS has been designed to allow both the separated and record-centric description of recordkeeping business. Record-centric description ensures that the Business-Recordkeeping descriptions are more accessible over time and space (within the description of each Record).
Future work could include the investigation of new paradigms for implementing recordkeeping systems to ensure persistence through space and time. One possibility is that 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 linked document management, workflow, enterprise knowledge management and archival systems. The viability of such an implementation strategy 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. The Recordkeeping Research Project intends to track technologies aimed at achieving persistent association, and applying them to the recordkeeping context.
This Scheme is still under development. The values for the element qualifers for the Records.Appraisal through Records.Use and the Records.EventHistory.Type value component are derived from the classification of Business-Recordkeeping activities currently defined in this Scheme. Therefore they are limited to the activities identified so far. Further delineation and definition are anticipated.
This Scheme is under development. For further details of ongoing research on relationships see Re-modelling the RKMS Set