[Federal Register Volume 60, Number 39 (Tuesday, February 28, 1995)]
[Notices]
[Pages 10832-10835]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 95-4855]
-----------------------------------------------------------------------
DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No. 950124027-5027-01]
RIN 0693-AB38
Intent To Develop a Federal Information Processing Standard
(FIPS) for a Data Standard for Record Description Records--Request for
Comments
AGENCY: National Institute of Standards and Technology (NIST),
Commerce.
ACTION: Request for comments.
-----------------------------------------------------------------------
SUMMARY: NIST is considering the development of a Federal Information
Processing Standard (FIPS) for the data elements which, when taken
together, will describe information objects of many different kinds,
both electronic and non-electronic. The standard would apply to a wide
range of information-creating software products. It would apply also to
document management and object repository software products. Federal
agencies would use the standard in specifying many software products
used to create documents or information objects (e.g., electronic mail
systems), and also when specifying document or object storage and
management software products. This notice uses the word ``record'' as a
broadly-encompassing term to include ``documents'' and ``objects,''
regardless of media or application.
The framework for this proposed FIPS was developed by a working
group of the interagency Integrated Services Panel, under the Federal
Information Resources Management Policy Council. NIST solicits comments
on the scope, purpose, background, and rationale for the proposed
standard, and on certain technical issues. After analyzing the
comments, NIST may propose a FIPS for review and comment.
DATES: Comments on this effort must be received on or before May 30,
1995.
.ADDRESSES: Written comments should be sent to: Director, Computer
Systems [[Page 10833]] Laboratory, ATTN: Data Standard for Records
Description, Technology Building, Room B154, National Institute of
Standards and Technology, Gaithersburg, MD 20899.
Written comments received in response to this notice will be made
part of the public record and will be made available for inspection and
copying in the Central Reference and Inspection Facility, Room 5020,
Herbert C. Hoover Building, 14th Street between Pennsylvania and
Constitution Avenues, N.W., Washington, DC 20230.
FOR FURTHER INFORMATION CONTACT:
Mr. Bruce K. Rosen, National Institute of Standards and Technology,
Technology Building, Room A-266, Gaithersburg, MD 20899, (301) 975-
3246, Internet mail brosen@nist.gov.
SUPPLEMENTARY INFORMATION: The Computer Systems Laboratory of the
National Institute of Standards and Technology is considering the
development of a Federal Information Processing Standard (FIPS) for the
data elements--their identification, representation, arrangement, and
object binding--to describe information objects. Such objects include
but are not limited to electronic mail messages, word processing
documents, spreadsheets, forms, voice-mail messages, images, and
publications. This notice refers to all such objects with the single
term ``record'' as a generic term to encompass documents, messages, and
information objects of all kinds.
The set of data elements will constitute a Record Description
Record (RDR). The RDR will be created whenever e-mail messages, word
processing documents, image documents, spreadsheet documents, voice-
mail messages, etc., are created, using either commercial-off-the-shelf
(COTS) software products or non-COTS software. It will accompany those
information objects when they are passed to a document management
(storage and retrieval) or object repository product (either COTS or
non-COTS), or when they are passed to some other software being used to
store and retrieve them.
By applying the standard to document management or object
repository software products, it will become possible to use these
products to manage non-electronic records stored externally in addition
to the electronic information objects stored in and under the control
of the document management or repository products.
Terminology
1. Record
The computer industry is developing a new class of information
technology products designed to organize, store, retrieve, and manage
such electronic expressions of information as textual memos and
reports, sound recordings, scanned images, and computer software. As a
group, the information expressions are called ``documents,'' or
``objects.'' The latter tends to be a broader term, to include computer
software. Both my include sound recordings, images, and what are being
called ``compound documents'' and ``multimedia'' documents or objects.
The products being developed are usually called object repositories or
document repositories or document management systems or document
storage and retrieval systems.
2. Record Management System
Throughout this notice, the term ``record management system'' is
used broadly to include all software products intended to store,
retrieve, and manage electronic documents and information objects. It
is intended to encompass such products as those that are called
``object repository,'' ``document repository,'' ``document manager,''
and ``document storage and retrieval system.'' These products may be
stand-alone or they may be integrated with other products in an office
suite. They may have their own directory, or they may share directory
services with other software products with which they are integrated.
What distinguishes them is their functionality of receiving documents
or information objects--what this notice calls ``records'', storing
them for future retrieval, use, and disposition, and also managing
their integrity, access, and life-cycles.
Background, Purpose and Rationale
Like many private sector enterprises, Federal Government agencies
are re-engineering their programs, missions and administrative
activities to perform them faster, better, and at less cost. In
general, this means replacing paper-based processes with electronic,
computer-based workflows. Examples include the electronic commerce
programs, and electronic submission of regulatory reports and filings.
As activities are migrated from paper to electronic workflows,
transactions, and submissions, information objects pass between
different software environments. Those records must be identified and
described not only to support search and retrieval, but also to
substantiate their trustworthiness in legal proceedings and support
their transfer to the National Archives should such transfer be
required.
Federal Government agencies will be procuring record management
products, both COTS and non-COTS, some of which will be stand-alone and
some of which will be integrated with such creation software as word
processing, e-mail, and workgroup computing. Thus, the possible
interfaces between the software used to create records and the software
used to store and retrieve them can very from many different packages
bought from many different vendors in many different procurements, to a
single integrated suite of software bought at one time in one
procurement from one contractor.
This proposed standard would enable Federal agencies to avoid
reinventing in every procurement or system installation the
identification data for messages, letters, images, etc., and the way
that data is recorded and arranged. It will avoid the necessity for
suppliers of software products to customize their products differently
for different Federal agencies, or for Federal agencies to engage
individually in complex integration efforts and to develop agency-
unique solutions to a requirement common to all.
Issues
1. Basic Architecture and Applicability
The Record Description Record (RDR) is a set of descriptive
attribute that are identified, arrange, and bound in a prescribed
manner to whatever is being described. The attributes are sometimes
referred to as metadata, because they identify and describe the record,
and may or may not be a part of it. The RDR is itself called a record
because it a logically-related set of discrete data elements.
Whenever a record is created using a computer, the creating
software would be expected to generate a corresponding RDR. That RDR
would be passed to a record management system along with the record
itself. For records created and stored outside the computer
environment, e.g., non-electronic records or electronic records stored
``off-line,'' the RDR information may be entered manually into a record
management system, thereby using the system to manage records in
general, without restriction as to the record media. In essence, the
FIPS would be specifying a standard record to be used to describe other
records of many different kinds.
The RDR is envisioned as comprising three sets of data elements.
The first is a small set that wou8ld be mandatory in [[Page 10834]] all
RDRs and would apply universally to all records, regardless of their
nature or content. The second is a small set that would be mandatory
for certain classes of records, or conditions that apply to them. An
example would be records sent electronically from one party to another,
as contrasted with those that are printed and communicated by hand,
mail, messenger, or facsimile. The third is a potentially large set of
optional data elements to be specified by individual agencies.
This approach would yield a single RDR standard that would
prescribe how the data elements are identified, arranged, and
represented, and how the RDR for an electronic record is to be bound to
the record it describes. It presents two issues on which public comment
is desired. One is whether it is reasonable to establish a single RDR
standard for all applications, e.g., word processing, e-mail, voice-
mail, groupware, etc. The second is whether the three-level
specification of data elements is appropriate.
2. RDR Binding
There must be some binding between an electronic record and the RDR
that describes it. Because of the different ways in which record
management systems work, the actual RDR contents are likely to be
handled differently, stored differently, and used differently in the
various proprietary products. The RDR contains the kind of descriptive
data that these systems put in their directories, if they have
directories. To a great degree, the RDR may be viewed as being a
support to or enhancement of the directory functions of those record
management systems that have directories.
Record management systems need to know how the RDRs for electronic
records will be delivered to them--whether they will come as physically
separate records, as headers, or as trailers. If this aspect is not
standardized, then software products that create records would be free
to create the corresponding RDRs in any way whatsoever. A standard
approach could be established by which an RDR is bound to what it
describes, so that record management system products can accept records
from any source and understand their accompanying RDRs.
The RDR standard is seen as essential to support a Federal agency's
mix-and-match of software products from different vendors. However, in
the case of integrated office suites where the passing of a record from
the creating software to the storing/retrieving software is handled
internally or where the record is created and stored in just one place,
a standard for data element identification and arrangement and for
object binding may not be needed, and when adopted might not
necessarily apply. However, the RDR information content would still be
necessary. When a record is transferred out of a record management
system, to either another record management system or to the National
Archives, the accompanying RDR would have to be bound according to the
standard.
Both implementors of software products that create records and
implementors of record management system software products are asked to
comment on how binding should be accomplished, and why. Prospective
implementors are invited to propose specification language.
3. E-Mail Receipt Data
Just the conduct of electronic commerce and regulatory activities--
let alone intra-agency and inter-agency communications--requires that
agencies keep data about the origin and receipt of electronic
transactions and submissions. Much of that data is generated internally
by e-mail software packages.
The treatment of e-mail receipt data poses a special binding case.
An e-mail message may be sent to one or more receivers, who may receive
it at different times, or not at all. At some point, the e-mail system
may transfer the message and its accompanying data from its own message
store to a record management system. If some receipt data for that
message is generated in the e-mail system after the message to which it
applies has been transferred out, there is a question about what the e-
mail system should do with that subsequent receipt data. It could, of
course, be purged by the e-mail system. Alternatively, it could be put
into an RDR and passed out to the record management system. If put into
an RDR and passed out, the record management system would need to link
it to the message to which it applies, and for which one or more RDRs
already exist.
Both implementors of e-mail software and implementors of a record
storage software are asked to comment on how this issue might be
resolved, and are invited to propose specification language to address
it.
4. Data Element Identification
The RDR will be a set of data elements. A standard mechanism must
be established to identify the elements that are present, because the
record will be a combination of mandatory and optional data elements.
If a record management system is receiving records from e-mail, word
processing, voice-mail, electronic commerce, etc., it will be receiving
different RDRs depending on which package created the record, and
perhaps also on the kind of record being stored. Thus, the format of
the RDR must be standardized in a fashion analogous to a message header
or a file label. Because there are many possible ways of formatting
RDRs, the lack of a standard format would result in the creating
software packages putting out RDRs that record management systems might
not understand.
Comments are desired on how the RDR should be formatted, and how
data elements should be identified and represented, and why.
Prospective implementors are invited to propose specification language.
5. Universal Mandatory Elements
In general, these elements will address the questions of (a) what
kind of record it is, or what software was used to create it; (b) which
individual or organization created it; (c) when it was created; (d)
what it deals with; and (e) what unique identifier(s) has been given to
it. With respect to these and all other data elements, relevant
existing FIPS for data element representations would be expected to be
used. Representation standards would be established only for those
elements for which such Federal standards do not presently exist.
Comments are solicited on the specific data elements that should be
considered to be universal and mandatory. Their selection criteria are
(1) their importance in record identification and description, and (2)
their applicability across the broad spectrum of software used to
create records of different kinds.
6. Conditional Mandatory Elements
Conditional mandatory elements are those that would be prescribed
for records based on such characteristics as their application of
origin, their storage media or location, or some statutory or
regulatory requirement. The condition of greatest immediate concern is
electronic communication, where the process of communication adds its
own dimensions of time and place. Examples would be electronic mail,
file transfer, and the many other applications that exist at the
application layer of a multi-layer data communications reference model.
As mentioned above, electronic commerce and electronic submission
of regulatory reports and filings necessitate the inclusion of
``transmission'' data in the RDR for an electronic mail message. It is
expected that these activities will necessitate a comparable
requirement in [[Page 10835]] such other communications-based
applications as file transfers and electronic data interchange
transactions. Thus far, all that is reasonably certain is that some
data that is generated internally by e-mail systems or created by
message originators--e.g., the identities of message originators,
identities of receivers, the date and time of origination, and/or the
date and time of receipt--must be bound to the message in the RDR. That
is a relatively small set of data elements. However, two important
questions surround it. The first is which of those elements should be
mandatory and which optional, and the second is whether those mandatory
elements should apply to all applications.
Comments are desired on both of these questions, as well as on the
mandatory descriptive elements that should apply to voice-mail, scanned
image documents, compound documents, and multimedia documents.
7. Optional Elements
Optional elements may be associated with records such as e-mail
messages that are common across many Federal agencies, or they may be
associated with common descriptive characteristics such as case number
or client number, or they may be unique to a particular agency. Some
common elements may be candidates for standardization, but that is not
an issue in this context.
What is of principal concern with respect to the RDR is the
production of optional elements by the information creation software,
and their acceptance by the record management system. The data element
identification standard discussed above should cover the aspect of
identifying each optional element that is present in an RDR, but
questions remain concerning the number of optional elements that a
record management system must be able to accept, and what
specifications should apply to information creation software for the
creation of the optional elements.
Comments are solicited on these, and any other aspects of optional
data elements in RDRs.
Dated: February 22, 1995.
Samuel Kramer,
Associate Director.
[FR Doc. 95-4855 Filed 2-27-95; 8:45 am]
BILLING CODE 3510-CN-M
