© 1998 Records Continuum Research
Group, Monash University. All Rights Reserved.
Technical Introduction
This Section provides a roadmap for understanding the recordkeeping metadata element definitions.
(PDF Version 
(479 Kb) )
|
|
|
|
|
|
© 1998 Records Continuum Research
Group, Monash University. All Rights Reserved. |
Technical Introduction
This Section provides a roadmap for understanding the recordkeeping metadata element definitions. (PDF Version |
Technical IntroductionThis Section provides a roadmap for understanding the recordkeeping metadata element definitions.
Conceptual Framework
Each of the Business, Agents, Records, and Business-Recordkeeping classes has a separate metadata element set. Each set shares ten common metadata elements, and includes other elements specific to the description of each entity:
Entity Types and Aggregation Levels An entity's level of aggregation is indicated using the Category Type element. For example, the description of a person would contain an "Agents.CategoryType" element with value "Person / Actor". The complete list of RKMS layers of aggregation are defined in the RKMS Category Type Scheme, described in the Schemes section below. Relationships and Mandates The decision to describe relations and mandates using element has many implications. In particular, the amount of information that can be recorded about relationships and mandates is limited, and only binary relationships can be depicted. Given the complexity and importance of relationships and mandates in defining records context and the possibility that depicting only binary relationships is too restrictive, this decision may be revisited in future revisions of the RKMS. These issues are discussed in greater depth in Ongoing Research, Re-modelling the RKMS Set. Metadata Model Structure The RKMS data model supports description of any Business, Agents, Records and Business-Recordkeeping entities that have identity.
Statements come in two forms: Basic and Qualified. A basic statement consists of a metadata element and a simple text value.
For example, a collection of two basic statements about title and date characteristics of an Agents entity might be:
Qualified statements consist of elements and values that are structured. Elements can be structured with element qualifiers that specialise or refine the meaning of an element. For example, "Established" is an element qualifier that can refine the meaning of the "Date" element for an Agents entity. Values can be qualified in two ways: Schemes These indicate either:
A qualified value can have a single text value (like a basic value), or multiple value components. Value components consist of value component labels representing the name of the value component and the value itself, represented as text value. A qualified value may have a scheme relating to the whole value. When the value is a simple text string, this scheme defines an authority or structure for that text. For example, the scheme may indicate that the simple text value "1999-01-01" conforms to the ISO 8601 format for dates. When the value is a set of value components, the scheme usually indicates a naming authority for the value component labels. For example, the scheme may indicate that the labels come from the vCard (http://www.imc.org/pdi/) system for describing people. Additionally, if the value consists of value components, then each value component may have an individual scheme.
When the value consists of multiple value components, at least one of those components should represent the information that would be entered into the "unstructured value". For example, the "Business.Mandate" element is defined as "Information about the mandate or instrument that provides the legal or administrative basis of the business, ...". It has many value components: "Title", "ID", "Date", "Description", and "Jurisdiction". A Mandate description that only used the "Date" and "Jurisdiction" components is not a valid description because it does not convey enough information to effectively describe the Mandate. Such a description should at least use the "Title" or "ID" components. The following table contains examples of four qualified statements about an Agents entity.
Identifying Entities 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". Some qualified metadata statements contain an "ID" value component, intended to identify the value being described. These identifiers should also contain context if they are to be understood beyond the immediate domain. Redundancy and Robustness of Descriptions Context is captured within RKMS descriptions in two ways: as text within a metadata description, and as relationships to other entities. For example, the title of a Records entity would be described in the "Records.Title" metadata element, but the creator of the record would be described within the "Records.Relation" metadata element as a reference to a separate Agents entity. The viability of capturing context using references to other entities depends on the feasibility of achieving persistent associations between entity descriptions, and the persistence of the other entity descriptions themselves. 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. RKMS addresses the problem of maintaining persistent metadata over time in three ways:
The first approach is taken in the case of description of recordkeeping activities. These 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. The second approach is taken in the case of mandate descriptions. Mandates are not separate entities in the RKMS conceptual framework. As a result, the description of a mandate that governs many entities will be repeated within the Mandate element of each of those entities. This ensures that Mandate descriptions are always accessible within the description of each entity. It does mean, however, that Mandate descriptions are less detailed than if they were separate entities that had own metadata sets. The final approach is available to any context captured using a relationship. The RKMS Relation element is used to describe references to other entities. It has "Related To", "Type", "Definition", "Date", "Mandate", and "Business Rules" value components intended to capture some of the context of the referenced entity. This means that even if a description of the referenced entity is lost, some context is available within the referencing description. Metadata Syntax An RKMS Simple Text Syntax metadata statement consists of an element definition and a value definition, separated by an equals sign (=):
Element definitions consist of a schema identifier(RKMS), entity name, element name, and an optional element qualifier, separated by dots (.). For example,
Elements and element qualifiers with multiple word names are compacted by capitalising the first letter in each word and concatenating them together. For example,
Qualified values are represented in the syntax as a series of value components, separated by semi-colons (;). For example, a value with three value components c1, c2, c3 would be written as:
Value components consist of labels representing the name of the value component and values representing the data itself. Colons (:) separate a value component label from the value component value. For example, the mandate description given in the data model section above would be written:
Value component labels containing multiple words are compacted in the same way as multiple word elements:
Schemes are represented in the syntax as names within square brackets ([name]) which precede values. The Functional Classification and Date examples given in the table above would be written as:
Value component values can also have schemes. In the following example there is a scheme associated with the value of the "Date" value component:
Extensibility Use of other independently maintained metadata schemas requires a metadata syntax that can distinguish between metadata components from different schemas. RDF has an XML syntax designed to support this requirement. The RKMS Simple Text Syntax, however, is restricted in this sense. It can only identify elements and schemes from other schemas, but not element qualifiers or value components from other schemas. Elements from other metadata schemas are identified in the RKMS Simple Text Syntax using an appropriate schema identifier. For example, a Records description could use a combination of elements from RKMS and the Australian Government Locator Service (AGLS):
Schemes from other metadata schemas are identified in the RKMS Simple Text Syntax as names within square brackets. For example,
Layout of Definitions Summary of Elements and Qualifiers RKMS Register Summary RKMS Register
Additionally, the following attributes are used to describe each element:
Fortunately, some of these attributes are common to all RKMS elements, and so are not shown in the element definitions. These are:
Additionally, most elements have the same occurrence restrictions. That is, most elements have:
There are two exceptions to this. The "Category Type" elements must occur exactly once:
And "Identifier" elements must occur at least once:
RKMS Schemes
Endnotes
About Research Publications Consulting Links Sitemap Authorised by Head, School
of Information Management and Systems. Caution.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
