In conformity with the functional requirements for evidence, we assert that evidence can only be made by compliant organizations using responsible, implemented and consistent recordkeeping systems. Records captured by such systems must be comprehensive, identifiable, accurate, understandable, meaningful and authorized. They must be maintained inviolate, coherent, auditable and removable. And to be used they must be available, renderable, evidential, exportable and redactable.
In addition to satisfying the requirements for evidence, business
acceptable communications must carry metadata to satisfy the
requirements
of large scale, distributed implementations over long periods of
time
during which human memories of the contexts of creation will not
suffice
and software and hardware will have significantly changed.
The following reference model proposes a six layer structure of
metadata:
designed to satisfy the functional requirement for evidence and the requirements of business acceptable communication and support the effective management of any record over long periods of time.
For more information, please refer to the following papers
Metadata Requirements for Evidence, by David Bearman,
Archives
& Museum Informatics, and Ken Sochats, University of Pittsburgh, School of Information
Sciences
Item Level Control and Electronic Recordkeeping, by David
Bearman, Archives & Museum Informatics, DRAFT of a paper given
at the 1996 Society of American Archivists Meeting in San Diego, CA, August 29,
1996.
I.A.2. Transaction-Domain-Identifier
[Mandatory]
Uniquely identifies the domain from which the
record originated with sufficient
specificity to identify the transaction-type and the organization
responsible.
I.A.3. Transaction-Instance-Identifier
[Mandatory]
Uniquely identifies a transaction instance with date, time and
necessary sequence identifiers.
I.B.2. Content-Descriptor [Optional] Provides terms used by the office of origin/receipt to describe or index the record.
I.B.3 Record-Natural-Language [Optional] Identifies the natural; language of the record (e.g. English, French, Portuguese)
II.A.2. Use-Rights-Status [Mandatory]
Defines if there are use restrictions which must
be resolved.
II.B.2 Resolver-Terms [Mandatory for records with
access restrictions]
Defines terms for access in a way that is
recognized by the resolver.
II.C.2 Use-Terms (Mandatory for records with use
restrictions)
II.C.2.b. Redacted-Record-Rule
[Mandatory if content view must be
restricted]
Identifies views that are permitted to
different users. It may be executed
algorithmically or may require human intervention to produce a
releasable view.
II.C.2.c. License-Terms [Mandatory
for Licensed Data]
If the data is licensed, this data
enables the proper resolution of use of the
record according to the guidelines set by the
license.
II.D. Disposition Requirements Metadata (Not
Repeatable)
Identifies the conditions regarding retention and
disposition of the records according to
policy.
II.D.2. Retention-Policy-Citation
[Mandatory]
Comprised of textual information identifying the
organization's internal policy/policies
for record's retention - indicates the specific policy (s)
governing retention and links to authority
issuance.
II.D.3. Retention- Authority Issuance[Optional;
unless retention-period-end-time is
unspecified]
Comprised of textual information regarding the
legislative or governmental
law(s)/regulation(s) governing record retention (ex. Code of
Federal Regulations) - indicating the
specific legal/regulatory policy number, version, dates issued,
dates effective, etc.
II.D.4. Retention-External -Authority [Optional;
unless retention-period-end-time is
unspecified]
Comprised of textual information identifying the
issuing organization that has
jurisdiction over the law(s)/regulation(s) governing records
retention.
II.D.5. Retention-Period-End-Time
[Mandatory]
Indicates scheduled retention period end date
(mmddyyyy) for the record. This
information is determined at the time of the record's creation.
If
unspecified (frequently indicated as
(99999999), the record must contain citations to policy,
regulation
and authority (II.D.2-4)).
II.D.6. Disposition-Instruction-Code
[Optional]
Identifies the methods that apply to the
ultimate
disposition of the record.
III.B.2.File-Data-Representation
[Mandatory]
Identifies the data encoding standards used by
the
file (i.e., ASCII, EBCDIC, or
UNICODE character data, ASN.1, CCITT Group III raster,
etc.)
III.B.3.Data-Codes [Mandatory if non-standard
methods of representation are used]
Indicates specifically how the data is encoded
when registered methods are not being
used. For example, for vector data whether it is topological,
spaghetti, chain-node, etc., for raster data
the number of dots per inch and their bit density, for sampled
data
the number of samples per second,
etc.
III.B.4.Compression-Method [Mandatory]
Identifies the method of compression, if any,
that
was used (ex: None, JPEG, MPEG,
Quicktime, LZW, etc.). If the method complies to a specific
standard, this may consist of only the
identification of that standard (name, version, etc.),
otherwise the method may need to be defined in
technical detail.
III.B.5.Encryption-Method [Mandatory]
Identifies the algorithms used by the record
originator to encrypt the record's content.
All records are stored in the de-encrypted form in which they
would
have be read by
recipients.
III.C.2.Software-Environment-Dependency [Mandatory
- Repeatable]
Indicates what software, including operating
systems and API's, if any, the record is
dependent upon. If there is a dependency, the name of the
software
package(s), the version, registration
information, and display information (such as font sets or
other
software dependent attributes] is
recorded at the time of record creation.
III.C.3.Hardware-Dependency [Mandatory -
Repeatable]
Indicates what hardware, if any, the record is
dependent upon. If there is a
dependency, the hardware needed, model number, configuration, and
output information (such as
printers or viewers required or other hardware dependent
attributes] are recorded at the time of record
creation.
III.C.4.Rendering-Rules [Mandatory -
Repeatable]
Identifies the procedures necessary to enable
the
record to be displayed, printed, or
otherwise represented as it had been at the time of creation
(macros, dimension, spatial reference data,
etc.) - may operate at different levels.
III.C.5.Representation-Standard/De Facto Standard
[Mandatory - Repeatable]
Identifies any standard(s) applied to the file
that affect how the file is rendered (ex:
SGML, Postscript, TIFF, etc.).and which version of the
standard
was used.
III.D.2.File-Interchange-Standard: Version
[Mandatory]
Identifies the standard(s) (including
identifying the appropriate version) employed by
the record to enable file interchange.
III.E.2.Content-Data Set [Optional]
If the content is identified as being
structured,
this cites the data set which indicates
how it is structured. Consists of the actual name of the data
set
definition. If a data set definition is
neither registered or a well-known registered identity, then it
will need to be registered.
III.E.3.Application-Dictionary [Mandatory, if
structured and no content data set]
Identifies the data dictionary for the entire
database. This consists of the actual data
dictionary itself - or it could take the form of a set of
referential integrity controls.
III.E.4.Delimiters/Labels [Optional, good
practice]
Consists of the actual delimiters/labels used
throughout the data and their usage
rules.
III.E.5.Data Value-Lookup Tables [Mandatory, where
present - Repeatable]
Consists of the authority file containing the
values of the codes used throughout the
record and their usage rules.
III.E.6.Data View-at Creation [Mandatory, if
partial
view]
Identifies how the application viewed the record
at the time of the record's creation.
This is the redaction subset of the data dictionary.
III.E.7.Version-Relationships [Mandatory, if prior
version exists]
Consists of any Record-Identifiers of previous
versions of the record.
III.E.8.Set-Relationships [Mandatory, if other set
members exist]
Identifies the record as belonging, for business
purposes, to an overall set of records.
Can consist of the classification of that set, or the
Record-Identifier(s) of other records.
III.E.9.Dynamic-Relationships [Mandatory, if
higher/lower exists]
Identifies what data is required from other
records/files in order to populate other
values. This is active in set relationships where a record
cannot
be opened unless the contents of other
records are available.
III.F.2.Data-Source-System-Documentation
[Optional]
Identifies or consists of the documentation that
outlines the conditions needed to create
the record - contains information on the data processing
function.
III.F.3.Data Capture-Instrument-Type [Mandatory,
if
instrument captured source data]
Identifies the type of instrument was used to
capture the data (i.e. light recording,
sound recording, temperature recording, location recording,
etc.) and the specific instrument used
(manufacturer, model number, etc.).
III.F.4.Data Capture-Instrument-Settings
[Mandatory,
if instrument captured source
data]
Identifies the settings, calibration, etc. were
in
effect when the data was captured.
III.F.5.Source Data-Quality [Optional, good
practice]
Identifies the degree of reliability of the data
generated by the source.
IV.A.2. Recipient-Identification
[Mandatory]
Identifies either the office/person/system that
received the transaction and the time of
receipt.
IV.A.3. Copy-Identification
[Mandatory]
Identifies whether the copy encapsulated by the
metadata is the sender's or the
recipient's copy.
IV.A.4. Business-Transaction-Type
[Optional]
Identifies the type of transaction (its
business functional context].
IV.A.5. Business-Transaction Procedure Reference
[Optional]
Identifies the originating organization's
specific
policy/policies and/or procedure(s) (i.e.
business rules) governing this type of transaction. May
consist
of citations or of the actual
policy/policies and/or procedure(s). In either case it should
note
the relevant version, effective dates,
etc.
IV.A.6. Linked-Prior Transaction [Mandatory, if
applicable]
Identifies the Record-Identifier(s) for
transactions that are part of the same business
activity.
IV.A.7. Action-Requested [Optional, good
practice]
Identifies if an action was requested as a
result
of the transaction. Could enable links
to past transactions if they occurred.
IV.A.8. Recipient Specific-Configuration Data
[Optional, good practice]
Identifies the permissions and views that the
recipient would have had. May reference
the data dictionary.
IV.B.2. Authorization [Optional, good
practice]
Identifies the source of authorization for
specific office(s)/position(s)/individual(s)
authorized to engage in the identified transaction.
IV.C.2 System Audit-Implemented [Mandatory]
Citation to most recent system and procedure
audit
transactions which contains
evidence of the system being implemented.
IV.C.3 System Audit-Consistent [Mandatory]
Citation to most recent system and procedure
audit
transactions which contains
evidence of the system being consistent.
V.A.2. Content-Incorporated
[Optional*]
Contains identifiers of records incorporated
into
the content or the actual data
contained in these records.
VI.A.3. Use-Instance-Time [Mandatory]
Identifies when the data was used - i.e. the
date
and time the data was
used.
VI.A.4. Use-Instance-User [Mandatory]
Identifies who or what used the data on a given
date at a given time.
VI.A.5. Use-Evidential Consequences [Mandatory if
redacted on release]
Identifies the impact of a particular use
(for
example, may identify the part of the
record released, the terms used in indexing, the importance of a
specific view what part of the record
was viewed).
Last Modified: 9/18/96