IRDS Goals and Requirementssowa@watson.ibm.com
Date: Thu, 18 Jun 92 09:27:47 EDT
To: SRKB@ISI.EDU, KR-ADVISORY@ISI.EDU, CG@CS.UMN.EDU
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Subject: IRDS Goals and Requirements
In various notes, I have been mentioning the ANSI X3H4 Committee on
IRDS (Information Resource Dictionary Systems). But I'm sure that
many people are not completely sure what IRDS is supposed to do.
Some X3H4 members are trying to formulate a succinct statement of
the IRDS goals and directions. There is as yet no officially approved
statement, but the following formulation by Burt Parker of MITRE
quite accurately describes what people are trying to do.
As you can see from the statement, an IRDS could be approached at
several different levels. In one sense, it could be little more
than a place to store and retrieve information with a minimum amount
of metainforamation about what it contains. The 1988 ANSI IRDS
standards assume entity-relationship diagrams as the notation for
the metainformation. But it is generally recognized that E-R
diagrams are inadequate to express everything. The question that
people are still debating is how much more is needed.
Some of us on the X3H4 committee take the term "metainformation"
seriously and explore its implications to the limit. When you do that,
the IRDS goals become very ambitious, and practically every aspect of
knowledge representation in AI becomes relevant. Most people on the
committee recognize that point, but there are two reactions to it:
1. Great! That gives us an opportunity to do all of AI within
the IRDS committee.
2. Get serious! We've got products to deliver and problems to be
solved this year.
We are trying to reach a compromise that will provide something
reasonable for commercially implementable systems within a couple
of years, but which at the same time leaves the door open to new
developments that may come out of the research community.
I believe that the work that is being done within the DARPA Knowledge
Sharing Effort comes very close to providing the kinds of facilities
necessary to support the long-range goals of the IRDS.
The IRDS problem statement is multi-dimensional:
* What is the purpose of an IRDS
* Why have an IRDS
* Why have an IRDS standard
* What are the requirements of an IRDS
IRDS PURPOSE: Provide an electronic "bucket" in which information about
information assets can be stored; also, provide the mechanisms for getting
that information into and out of the "bucket," and for managing the
information in the "bucket."
WHY IRDS: IRDS standardizes, organizes, and synchronizes the information
assets of a domain of interest, for example: that of an enterprise. The IRDS
promotes reuse of an organization's information assets and facilitates exchange
of information assets within the domain of interest.
WHY IRDS STANDARD: By standardizing storage and management of information
about information assets (meta-data), the IRDS standard provides a consistent,
widely accepted definition of repositories. Such a definition facilitates
exchange and reuse of information assets between domains of interest, e.g.,
IRDS REQUIREMENTS: The IRDS must manage the structural configurations of all
informational representations of an organization as organizational assets.
In addition to the traditional character-based data and program structures of
the typical repositories of the past (program/subroutine libraries, data
dictionaries, data directories, and data encyclopedias), the IRDS must define
and manage multi-media data structures (e.g., graphic, still & motion imagery,
audio), the entire range of information assets of an enterprise (e.g., goals,
objectives, plans, data & process models, specifications, standards, policies,
organizational structures, data & code structures), and possibly even the
instantiations of all these information structures.
The IRDS must operate within and support a distributed, heterogeneous platform
environment. It must also support passive, active, and dynamic access
mechanisms to accommodate legacy systems as well a new system development
utilization of the IRDS.
IRDS access mode definitions:
- Passive (e.g., only the definition and management of Meta-data
- Active (e.g., definition and management of Meta-data and
data/code as well as generation of application system code and
- Dynamic (e.g., control of actual applications at run-time as
well as application generation and Meta-data/data/code definition).
The IRDS must provide the means to describe, document, control, protect, and
provide access to all types of information about all information assets of an
organization in order to support management of such information.
There are two sets of meta-data necessary for the IRDS. The first is that
meta-data necessary to create, maintain, and control the "electronic bucket"
and to get information into and out of the "bucket." These can be thought of
as IRDS administrative meta-data or meta-meta-data.
The second is that meta-data necessary to the domain of interest of the
repository end-users. These can be thought of as IRDS functional meta-data or
just meta-data. This functional meta-data has six "flavors": who, what,
where, why, when, and how. These flavors define the information manager-
oriented (rather than IRDS administrator) functional meta-data requirements of
* What: Information assets; identifies and documents the information
assets of the organization, such as hardware, networks, applications,
data/process/organization models, requirements, specifications, databases,
* Who: Information management roles; information management role
responsible for an information asset, such as database administrator, data
administrator, systems analyst, programmer.
* Where: Organizational structures of the enterprise; the organization
entity responsible for an information asset and/or an information management
* Why: Benefit ( basic cost/benefit justification for the information
asset); identifies and documents the essential "raison d'etre" of the
* When: Information asset life cycle(s); identifies and documents the
life cycle phase in which the information asset "lives" or is created.
* How: Guidance (standards, policies, procedures, metrics, tools);
quality assurance guidance relating to the information asset.