Understanding the BOM Metadata and Making It Work For You

Paul Gustavson Roy Scrudder

SimVentions, Incorporated
11903 Bowman Drive, Suite 102
Fredericksburg, VA 22408
540-372-7727
pgustavson@simventions.com
Applied Research Laboratories
The University of Texas at Austin
Austin, TX 78713
512-835-3857
scrudder@arlut.utexas.edu

Robert Lutz Jane Bachman

Johns Hopkins University Applied NSWCDD - TEAMS
Physics Laboratory 17320 Dahlgren Road
Laurel, MD Dahlgren, VA 22448
240-228-759 540-653-7055
robert.lutz@jhuapl.edu jane.bachman@navy.mil

Keywords:
BOM, Composability, Metadata, Patterns, OMT, Reuse, HLA, DDMS

ABSTRACT: The concept of metadata is the single most important facet of information technology today.
Consider the reality that, in today’s digital world, information is being created, saved, exchanged and manipulated
at an exponential rate beyond human comprehension. The most important thing for the producer and consumer of
any information being exchanged or being made available is that it can be properly reasoned and understood.

Metadata is defined by a library task force as “structured, encoded data that describe characteristics of
information-bearing entities to aid in the identification, discovery, assessment, and management of the described
entities [2].” Good metadata that is properly structured helps facilitate reuse and understanding; otherwise
anything else may result in misintent and be unused.

A primary focus by the BOM Product Development Group has centered upon the identification of essential metadata
needed to support composable simulation environments for establishing federation agreements and enabling
federate capabilities.

Composability concepts that have successfully worked elsewhere -- such as design patterns, algorithmic state
machines (ASMs) within digital electronic design and software component interfaces -- have been leveraged in the
formation of this BOM metadata. This paper examines the various facets of metadata provided by the BOM, and
explores how it aids in the identification, discovery, assessment, and management of information.

interoperable simulation federations is described in the

1 Introduction High Level Architecture (HLA) Federation
Development and Execution Process (FEDEP) model
Today, we live in a society with a high demand for [1]. The FEDEP model identifies the design and
information. We want information quickly, and in a development of a federation beginning with the
manner that is easily accessible and understandable. exploration of reusing available components. The reuse
This need is no different in the M&S community. and integration of component and FOM “piece-parts”
Information is needed to build and maintain is considered a very useful method in expediting the
interoperable simulation federations. The sequence of development process and ensuring federate
activities recommended to build and maintain interoperability at a reasonable cost.
So, how does one expedite the development process
while ensuring federate interoperability? Base Object
Models (BOMs), noted for their ability to represent
and/or support discrete patterns of interplay within or
among simulations, provide an open standard approach
intended for describing and sharing reusable
components or “piece-parts” of a simulation or system.
It is through the use of metadata that BOMs provide
the key for discovery, reuse and composability.
Metadata allows a component or “piece-parts” or any
other type of information to be properly understood as
long as the information is described in manner that
allows such reasoning. Let us examine the various
facets of BOM metadata, and explore how it aids in the
identification, discovery, assessment, and management
of information.
1.1 What is Metadata?
Most simply put, metadata is data about data.
Officially, it is defined as “structured, encoded data
that describe characteristics of information-bearing
entities to aid in the identification, discovery,
assessment, and management of the described entities
[2].” Good metadata that is properly structured helps
facilitate reuse and understanding; anything else may
result in misintent and be unused.
In the context of the HLA, an object model is nothing
but metadata. Essentially it is data about object and
interaction classes, data types, etc., but there is not any
“real” instance data to be found anywhere in a FOM or
SOM. In the HLA context, metadata is the data that
describes/pertains to the entire object model.
particular the Object Model Identification Table
defined in IEEE 1516.2 embodies the central metadata
of a FOM or SOM. The primary purpose of HLA
object model metadata is to allow the discovery and
understanding of object models.
1.2 Goal of the BOM Product Development
Group (PDG)
The BOM Product Development Group (PDG) was
chartered by the Simulation Interoperability Standards
Organization (SISO) Standards Activity Committee
(SAC) on January 15, 2003 to research and develop a
standard for BOMs. With this objective, a primary
focus by the BOM PDG has centered upon the
identification of essential metadata needed to support
composable simulation environments for establishing
federation agreements and enabling federate
capabilities. Composability concepts that have
successfully worked elsewhere such as design patterns
used in software engineering, algorithmic state
machines (ASMs) used to support digital electronic
design, have helped influence the development of the
BOM metadata.
1.3 Key Terminology and Concepts
Early on we stated that a BOM is unique in that their
metadata is able to represent or support a discrete
pattern of interplay within or among simulations. A
pattern of interplay reflects the relationship of activities
among one or more conceptual entities that are carried
out to accomplish a common objective, capability, or
purpose.
Composability is defined by Dr. Petty, of the Virginia
Modeling & Simulation Association Center (VMASC),
as “the capability to select and assemble components in
various combinations into complete, validated
simulation environments to satisfy specific user
requirements across a variety of application domains,
levels of resolution, and time scales [3].” BOMs
provide a specification to describe these components,
which are selected and assembled, in a meaningful way
through the various metadata that can be exposed. This
specification defines the semantics and syntax needed
to represent a BOM. More precisely, this document
characterizes the essential metadata and model
elements by specifying a basic BOM Template for
documenting information needed to identify and assess
the reusability of BOMs.
2 Leveraging other Metadata Standards
In Before examining the various metadata elements of a
BOM, it would be helpful to examine some of the
metadata standards that have been leveraged by the
BOM Product Development Group (PDG), which was
charted to develop the BOM specification. The BOM
PDG strived to have one cohesive set of metadata for
HLA object models, not one set for FOMs/SOMs, and
another for BOMs, and yet another for BOMs
Assemblies. The BOM PDG felt it was important not
to embrace any one existing “standard”, but rather
select the appropriate elements.
2.1 HLA OMT, IEEE 1516.2
The BOM PDG started with the existing Object Model
Identification Table from the IEEE 1516.2 Object
Model Template (OMT) [4]. The primary purpose of
the HLA OMT is to define the format and syntax of the
data that is exchanged during runtime among members
of an HLA federation. There are several OMT tables
that are dedicated to that purpose, such as the
object/interaction class structure tables, and the
associated attribute and parameter tables. In support of
the one of the main overarching goals of the HLA,
facilitation of reuse, it is intended that when HLA
object models are developed, they will be considered
for reuse in future applications avoiding the design of
each new application entirely from scratch.
However, in order for the reuse of FOMs and/or SOMs
to be possible, there must be a means for users to
rapidly locate candidate object models with high reuse
potential, and to quickly assess that potential according
to relevant technical and practical criteria. The OMT
provides such basic descriptive information in the
Object Model Identification Table. This is the table
that is used to capture the essential metadata enabling
the discovery and understanding of HLA object
models; that’s its primary purpose. The contents of the
OMT object model identification table are as follows:
 Name- name assigned to the object model.
 Type - the type that the object model represents;
valid values are FOM: the object model describes
a federation and SOM: the object model describes
a federate
 Version - the version identification assigned to the
object model

Modification Date - the latest date on which this
version of the object model was created or
modified

Purpose - the purpose for which the federate or
federation was developed
 Application Domain - the type or class of
application to which the federate or federation
applies. The following values may be used for this
field, although other values are also valid:
Analysis, Training, Test and Evaluation,
Engineering, and Acquisition
 Sponsor - the organization that sponsored the
development of the federate or federation
 POC - the point of contact for information on the
federate or federation and the associated object
model
 POC Organization - the organization with which
the POC is affiliated
 POC Telephone - the telephone number for the
POC
 POC E-mail - the e-mail address of the POC
 References - pointers to additional sources of
information
 Other - shall specify other data deemed relevant
by the author of the object model.
The OMT allows for a single value to be assigned to
each of these fields, although that value may be free
text which provides a set of values.
The evolution from the older HLA V1.3 version of the
OMT to IEEE Standard 1516.2 resulted in only minor
enhancements to the object model identification table;
the addition of a row to support the identification of
reference sources and another row to specify other
general information relevant to the reuse of the federate.
These are currently the only rows in this table that the
OMT specification identifies as optional.
The next generation of user enhancements to the HLA
specifications is currently underway within the SISO-
sponsored “HLA Evolved” PDG. For the OMT, one of
the key areas in which users have expressed a need for
improvement is that of object model metadata. While
some of the changes that have been proposed within
the BOM PDG so far represent necessary Object
Model Identification Table extensions to support the
BOM concept, other changes are simply to better
reflect the content of existing metadata standards.
Some of the more significant and relevant standards to
draw from are discussed in the following sections.
2.2 Dublin Core
One of the more common metadata standards used in
commercial data management practices is the Dublin
Core standard. This standard is the result of the
collaboration of librarians, digital library researchers,
text-markup experts and content providers, which were
initially brought together for a workshop held in
Dublin, Ohio in 1995 with the purpose of identifying
essential discovery standards for information resources.
This effort is known as the Dublin Core Metadata
Initiative (DCMI) [5]. This work has been
standardized by the National Information Standard
Organization and ANSI. The metadata standard is
composed of a set of optional, repeatable elements.
Table 2.2 provides the high level details of the Dublin
Core Elements.
 Title - A name given to the resource
 Creator - An entity primarily responsible for
making the content of the resource.
 Publisher - An entity responsible for making the
resource available.
 Contributor - n entity responsible for making
contributions to the content of the resource.
 Subject - A topic of the content of the resource.
 Description - An account of the content of the
resource.
 Date - A date of an event in the lifecycle of the
resource.
 Type - The nature or genre of the content of the
resource.
 Format - The physical or digital manifestation of tethered to Security Set, Resource Set, Format Set, and
the resource. Summary Content Set.
 Identifier - An unambiguous reference to the
resource within a given context. Core Layer Category Set Primary Category Obligation

 Source A reference to a resource from which The Security elements enable the
description of security classification and Security Mandatory
the present resource is derived.

related fields
Language - A language of the intellectual content Title Mandatory
of the resource. Identifier Mandatory

 Relation - A reference to a related resource. Creator Mandatory

 Coverage - The extent or scope of the content of Resource elements enable the
Publisher
Contributor
Optional
Optional
the resource. description of maintenance and


Date Optional
administration information
Rights - Information about rights held in and Rights Optional

over the resource. Language Optional

Type Optional
Source Optional
Among the concepts drawn from the Dublin core for Subject Mandatory
inclusion on the BOM metadata were the following: Geospatial Mandatory unless

 Allowing multiple POCs for (creator, The Summary Content elements enable Coverage not Applicable
the description of concepts and topics Temporal Coverage Optional
publisher, contributor,…) Virtual Coverage Optional

 Adding a general “description” field Description Optional

 Allowing for a set of keywords to characterize

The Format elements enable the

a BOM (drawn from the “subject” field)

description of physical attributes of the Format Optional
asset

 Allowing a set of references (relations) to

other resources.
 Allowing for release restrictions (rights) on
BOMs
2.3 Department of Defense (DoD) Discovery
Metadata Specification (DDMS)
One of the more significant recent activities in
information management has been the effort to identify
a US DoD standard for discovery metadata. This is
known as the DoD Discovery Metadata Specification
(DDMS) [6]. The DDMS is part of the new National
Information Infrastructure initiatives. It replaces the
previous approach of data element standardization.
The emphasis of DDMS is to “Tell me what it is, not
how to build it.” It is largely based on Dublin Core.
The development group for the DDMS recognizes the
need for Community of Interest extensions. Figure
2.3-1 provides a view of the DDMS structure, whereas
Figure 2.3-2 provides a categorized view with elements
Figure 2.3 – 1 – DDMS Elements Structure
Given the relationship between the Dublin Core and
the DDMS, many of the changes to the BOM metadata
identified in the previous section also map to the
DDMS. One key additional element which came from
the DDMS was the inclusion of security classification
information in the BOM metadata. Some elements that
appear in both of the Dublin Core and the DDMS were
not included in the BOM metadata, given that they do
not make sense in the constrained domain of resources
we are describing (object models versus information
resources in general). The lack of the “format”
descriptors is a good example. Since data interchange
formats have been established for HLA object models
and BOMs, it is understood that the resource will be in
that format.
 Figure 2.3 – 2 – DDMS Elements Structure Categorized View

2.4 VV&A Recommended Practices Guide 3 BOM Elements

(VV&A RPG)
The following sections represent the current state of the
The VV&A Recommended Practice Guide is obviously BOM elements, which is illustrated in Figure 3.1. The
focused on metadata associated with VV&A [7]. metadata standards identified in section 2 have been
Derivation of this metadata set started with DMSO leveraged in the development of these elements; in
Authoritative Data Sources Project and ISO TC211 particular the BOM Model Identification table [8]. We
standard (geospatial metadata). Essentially, there is also look briefly at other BOM elements, to understand
overkill for much of what is in HLA Object Models, what the metadata within the Model Identification is
but the BOM PDG found some good ideas related to intending to describe and is encouraging to be reused.
intended Use and leveraged these for Use History. Note: it is likely that the PDG will evolve these BOM
elements further in the coming months.
Additionally, one of the key concepts drawn from the
VV&A RPG, which appear to a lesser degree in the
Dublin Core and the DDMS are the wide range of point
of contact relationships that can be associated with a
resource. Rather than constrain the BOM metadata to a
finite list of point of contact relationships as is done in
these three standards, the BOM metadata provides a
generalized structure for associating points of contact
with the BOM, where the user specifies the type of
relationships. Suggested values are provided, drawn
from the set of relationships in the Dublin Core,
DDMS, and VV&A RPG.

Figure 3-1 – BOM Metadata Elements

3.1 Model Identification
The purpose of the Model Identification table is to
document certain key identifying information within
the BOM description itself. It provides a minimum but
sufficient degree of descriptive information about a
BOM. For instance, when federation developers wish
to pose detailed questions about how a pattern was
constructed, point-of-contact (POC) information within
a BOM is extremely important. This helps facilitate
understanding, which leads to reuse. Table 3-1
provides a description of the categories of information
that comprise a Model Identification. Also provided is
a comparison to the other metadata standards that were
examined and leveraged for the development of the
BOM Model Identification table (see section 2 for a
description of these metadata standards).

Table 3.1-1 - BOM Model Identification Table and Relation to other Metadata Standards

Category Description HLA OMT Dublin DDMS VV&A RPG

IEEE 1516.2 Core
Name Specifies the name assigned to the object model. Name Title Title Info-Asset_Title
Type Specifies the type that the object model represents; for a Type Type Type Information-Asset Type
BOM the only valid value is “BOM.” This field is included Code
in anticipation of this table being eventually adopted for (e.g. FOM,
encapsulated BOMs and potentially for FOMs and SOM)
SOMs.
Version Specifies the version identification assigned to the object Version -- Identifier --
model.
Modification Date Specifies the latest date on which this version of the Modification Date Date Process Date / Time,
object model was last modified. If the object model is still Date Source Date / Time,
in its original version (has not undergone modification) Quality Date / Time,
this field shall contain the creation date. Reference Date
Security Classification Specifies the security classification of the object model. -- -- Security Security Classification
Release Restriction* Specifies any restrictions on the release of the object -- Rights Rights Access Constraints
(optional) models to specific organizations or individuals. Multiple
rows are permissible if multiple release restrictions exist.

Purpose (optional) Specifies the purpose for which the BOM was developed. Purpose Subject Subject Purpose

Application Domain Specifies the type or class of application to which the Application Subject Subject Use
(optional) pattern pertains. Domain
Description Provides an account of the content of the BOM. Specific -- Description Description Abstract
to BOMs, this field could also include description of the
BOM Generalization level.
Use Limitation Specifies any known applications for which this BOM has -- Coverage Geospatial Use Limitations
(optional) been found not to be appropriate. Coverage,
Temporal
Coverage,
Virtual
Coverage
Use History* Specifies where / how this BOM has been used in the -- -- -- Use
(optional) construction of other object models.
Keyword* Repeated as many times as necessary. -- Subject Subject (see below)
(optional)
Taxonomy Specifies the source of the keyword vocabulary. -- Subject Subject Information Asset Keyword
(optional) Thesaurus Name
Keyword Specifies the word or concept that is addressed by the -- Subject Subject Information Asset Keyword
BOM.
POC* Specifies an organization or a person who has a (see below) Creator, Creator, Primary POC,
particular role with respect to the BOM. At least one set Publisher, Publisher, Process Contact
of POC information must be supplied. Multiple sets may Contributor Contributor
be supplied.
POC Type Specifies the role that the POC has with respect to the -- -- -- Responsible Party Role
BOM. Code

POC Name Specifies the name of the POC, including an honorific POC Responsible Party
(optional) (e.g., Dr., Ms., etc.) or rank, first name, and last name Individual Name
where appropriate. In the case where the POC is an
organization, this field is optional, but either a POC Name
and/or a POC Organization must be specified.
POC Organization Specifies the organization if the POC is generalized to an POC Responsible Party
(optional) organization. If a POC Name is specified, then this field Organization Organization Name
is optional, and contains the name of the organization
with which the person is affiliated.
POC Telephone* Specifies the telephone number for the POC including POC Telephone Voice Telephone,
(optional) the international telephone code for the POC’s country. TDD/TDY Telephone,
DSN Telephone,
Facsimile Telephone
POC Email* Specifies the email address of the POC. POC Email Electronic Mall Address
(optional)
Reference* Specifies a pointer to additional sources of information. -- Source, Source (see below)
(optional) This set of fields may be repeated multiple times. Relation
Type Specifies the way in which the reference is related to the -- -- -- --
BOM.
Category Description HLA OMT Dublin DDMS VV&A RPG
IEEE 1516.2 Core
Identification Specifies how to locate the reference source. Examples References -- -- Identification Citation,
include a Uniform Resource Identifier (URI) , XML Data Dictionary Name
reference ID (ref ID), or ISBN.
Other Specifies other data deemed relevant by the author of Other -- -- Supplemental
(optional) the object model. Information
Glyph Specifies a glyph to visually represent a BOM in a tool -- -- -- --
(optional) palette or web-based repository
Src This field holds the image representing the BOM. -- -- -- --
Alt This field shall be used to provide alternative text in case -- -- -- --
(optional) the image represented in the Src field cannot be
displayed
Height This field shall specify the pixel height of the glyph image -- -- -- --
(optional) represented in the Src field
Width This field shall specify the pixel width of the glyph image -- -- -- --
(optional) represented in the Src field

As can be seen in the previous table, there are some

BOM metadata elements that do not trace to any of the
reference standards. These were requirements brought
forth by the members of the BOM Product
Development Group. These include the specification of
a glyph to server as small image that would be used to
identify a BOM. Another key element is the use history.
To a large extent, a potential user’s trust in using a
BOM can be based on where it has been successfully
used before.
3.2 Behavior Description
The Behavior Description provides a mechanism to
identify up to three different behavioral elements of a
component or piece-part for supporting a simulation.
 Patterns
 State Machines
 Events
A key to each of these elements is a focus on the
conceptual entity being characterized. A conceptual
entity is an abstract representation of a real world entity,
phenomenon, process, or system. These conceptual
entities are needed to understand the relationships
within a pattern of interplay, the roles in respect to state
machines across one or more patterns of interplay, and
the responsibilities as sender and/or receiver in regards
to the events that can occur to fulfill a pattern of
interplay.
Each one of these Behavioral Description elements will
be briefly described below in order to help understand
what the metadata in the Model Identification is
describing. For detailed information, it is encouraged
that the reader review the “SISO BOM Template
Specification” [8] and the “SISO Guide for BOM Use
and Development” developed by the BOM PDG [9].
3.2.1 Pattern Description
The Pattern Description provides a mechanism needed
for identifying the actions (including variations and
exceptions) necessary for fulfilling a pattern of
interplay. A Pattern of Interplay is a specific type of
pattern characterized by a sequence of activities
(identified as actions) involving one or more
conceptual entities. The activities described for these
activities may either tie in with a defined “event”
within the BOM (as described in section 3.2.3), or may
be referenced by a completely unique BOM all
together. The latter supports aspects of composability
and representation of higher order patterns
3.2.2 State Machines
The State Machine is used to identify the needed
behavior “states” anticipated of a conceptual entity to
support one or more patterns of interplay. The state
machine may utilize an action form one a pattern of
interplay to identify a state exit transition.
3.2.3 Events
Since the BOM can be used to identify a complete
pattern of simulation interplay, additional information
is needed to document how the interplay takes place,
what simulation elements are involved and how it is all
implemented using the HLA class constructs. The
types of BOM Events used to represent and carry out
an aspect of interplay are identified as BOM Triggers
and BOM Messages.
A BOM Trigger is an event, which is not directed to a
specific receiver(s); whereas a BOM Message is an
event, which is directed to a specific receiver(s).
HLA objects provide an external public view of the
current state of entities represented by federation
participants. Although HLA objects cannot exhibit
behavior directly, there is a strong association between
the values of the state information possessed by an
HLA object instance and the behavior exhibited by a
corresponding entity in a conceptual model.
3.3 Model Definition – Using the OMT
The Model Definition portion of the BOM provides the
means for identifying the object models needed to
represent the BOM. It’s important that the metadata in
the Model Identification capture the essence of what is
being provided in the Model Definition.
The major element used to support defining the Model
Definition is the HLA Object Model Template
specification. The key elements defined by the HLA
OMT for supporting the BOM Model Definition
include the following:
 Object model identification table

Object class structure table
 Attribute Table

Interaction Class table
 Parameter table

Datatype tables
 Notes Table

FOM/SOM Lexicon
All other tables in the OMT 1516.2 not identified are
those not needed for the BOM.
Further discussion on the Model Definition is found in
the BOM Template Specification and also the
forthcoming HLA Evolve - OMT Specification, which
is also incorporating the Model Definition table.
4 Making the Most of BOM Metadata
Let us now examine how we can define and use BOMs
to support the activities associated to federation
development and execution.
4.1 Defining BOM Metadata
In order to make the most of the BOM metadata, it
must first be defined. The key in defining BOM
metadata is to ensure that enough descriptive content
has been captured regarding a BOM’s application, so
that it can be properly reused. Table 4.1 provides
guidance useful for filling out the Model Identification.
Table 4.1 – Defining BOM Metadata
Metadata Guidance
Field
Name The name of the BOM should be descriptive and
unique. It is unlikely that any central authority will be
available to assign unique identifiers for every BOM
that is created. Thus, it is important that the BOM
name be sufficiently descriptive to allow a user to
locate the BOM by keyword searches while
differentiating it from other BOMs of a similar nature.
Type Use this field to indicate what specific type of model
is being defined. For BOMs the value of this field is
“BOM”. For FOMs and SOMs, which also uses this
table for the HLA Evolve effort, the value of this field
is “FOM” or “SOM” respectively.
Version The local versioning identification system used by the
BOM author should be used. The important concern
is that a potential user should be able to differentiate
among multiple versions of the same BOM. Be sure
to update the Modification Date as well.
Modification Use this field to specify the latest date for which the
Date BOM was modified. If a Version has been updated –
the Modification Date should also be updated. The
format of the date is yyyy-mm-dd.
Security Use this field to identify the security classification of
Classification the object model. Choices might include
Unclassified, Confidential, Secret, or Top Secret
Purpose Use this text field to identify the sponsor’s /
developer’s intended purpose for the BOM. BOM
users may determine that a BOM is useful for
purposes other than the one for which it was initially
intended. However, this metadata will still be useful
when searching out BOMs for reuse.
Application Use this field to specify the type or class of
Domain application to with the BOM pertains. Choices might
include Analysis, Training, Test and Evaluation,
Engineering, or Acquisition.
Description Use this text field to provide a detailed and
descriptive account of the content of the BOM.
Use The author of a BOM should use this text field to
Limitation. provide any known applications for which this BOM
has been found NOT to be appropriate.
Use History The author of the BOM will initially populate this list.
To maximize reuse of a BOM, other users who have
found the BOM useful should provide feedback to the
author of the BOM so that he/she can list the
additional use history. Evidence of broad applicability
and frequent reuse will generally be gauged by
potential users as evidence of BOM quality.
Keywords The BOM authors are urged to associate as many
keywords with a BOM as is practical. The keywords
may come from a list of the author’s own creation.
More useful will be lists of keywords from lists
established by communities of interest.
Point of Each BOM should have at least one POC. Usually,
Contacts this will be the author of the BOM. However, the
(POCs) template allows for multiple POCs to be associated
with a BOM. In line with the Use History guidance
above, POCs could be established in user
organizations.
References* The use of multiple references is encouraged. One
common reference would be the conceptual model
from which a BOM was developed. Other references
would be references to related BOMs or to FOMs
and/or SOMs where the BOM was employed.
Other This field can be used to contain any information that
the author of the BOM thinks is relevant. Although
not prohibited, the author should avoid using this field
for information that fits one of the other metadata
fields.
Glyph This is an image that can be used to represent a
BOM on a tool palette or web-based reuse library. It
is suggested that unique images are used to
represent a BOM to differentiate between other
BOMs. The graphic should be as simple as possible
while still conveying the intended use of the BOM
and differentiate the BOM from others.
Note: The BOM PDG chose not to attempt to define a
“standard convention” for representing conceptual
models, but rather providing the capability to reference
external conceptual models. This is supported through
the Reference item found in the Model Identification
table. Additionally, the Pattern Description and State
Machine Description both provide a unique mechanism
useful for documenting a perspective of the conceptual
model. However, even these two tables combined
likely fall short of satisfying a complete conceptual
model for most organizations.
4.2 Identifying Candidate BOMs
Requirements and the conceptual model produced from
the analysis of requirements can be used as key criteria
to search metadata and identify candidate components /
piece-parts. The objective should be to catalog the
requirements and conceptual models in a manner that is
useful for searching and identifying candidate BOMs.
A good place to start is to mirror the information
within the BOM metadata or another metadata standard
such as the DDMS. For instance, a stated requirement
can be mapped to the identified Purpose within the
Model Identification table. Additionally, Keywords,
Use Limitations, and Application Domain provide key
search criteria and should be identified.
Identifying these elements makes it easier to locate
candidate models through metadata matching. Once
candidate models have been found, one can peruse
additional metadata such as Use History as an aid in
making a final selection.
A likely approach for facilitating the automation
process of metadata matching and discovery might be
via the application of web services that are tied to reuse
libraries, which host a collection of BOMs.
Furthermore, the application of requirements and
conceptual models used in identifying candidate BOMs
through metadata matching can then be used to identify
candidate federates supporting BOMs, and/or BOM
implementations such as source code, byte code, and
software components for federates. Hence this could
help facilitate the automation of the FEDEP process.
4.3 Integration History and Feedback
Part of making BOMs useful to others is hinged upon
reflecting integration Use History. It is imperative that
as BOMs are used and applied in the construction or
modification of a BOM Assembly, FOM, SOM, or
another purpose that the integration history regarding a
BOM’s use (and success) is shared back to the
communities at large who either use or develop BOMs.
This feedback involves sharing integration experience
in the form of BOM metadata as defined in the BOM
Specification.
Much like how a defined purpose, keywords, and even
referenced conceptual models serve in assisting the
selection process so can the capture of Use History.
This metadata reflecting the feedback of experience
allows BOMs to be more easily matched, and used
with greater certainty of its capability.
The idea of Use History is somewhat analogous to the
reader comments and reviews that a web site such as
Amazon.com provides for potential customers of books,
records and videos. The likely mechanism for
canvassing integration Use History metadata is to
provide an on-line collection mechanism affiliated with
a reuse library where the BOM was retrieved.
4.4 Mapping Metadata Standards
It is important to recognize that a BOM can support
other metadata standards (even if labels do not fully
align). This can be accomplished through the
application of an XML Stylesheet Language
Transformation (XSLT) where mappings can be
created to support this alignment. These XSLTs can
be applied autonomously using an XSLT processor
typically included with an XML Parser, which will
produce the desired output. This type of mapping
capability allows for a greater use of data objects to be
made available and understood by the community.
One mapping in particular that might prove to be
resourceful is a BOM mapping to the DDMS schema
structure. As shown in Table 3-1 previously, many of
the elements provided by the BOM Model
Identification, can map directly with the DDMS.
5 Summary
BOMs are seen as a key technology for facilitating the
reuse of components in the construction of simulations
and simulation environments. For any resource to be
reusable, it must be visible and accessible.
By visibility, it is not only meant that the ability exists
to recognize that BOMs are available, but also that they
have sufficient descriptors to allow a potential user to
determine whether a BOM is appropriate for his/her
use. To that end, a common set of descriptors has been
defined in the BOM Model Identification Table.
By accessibility, which is the second factor in
reusability, this can occur when libraries of BOMs are
constructed and made available, and information has References
been captured using a consistent set of descriptions,
which is commonly called metadata.
1. IEEE Recommended Practice for High Level
Architecture (HLA) Federation Development and
The metadata contained in the BOM Identification
Execution Process (FEDEP), IEEE Std 1516.3-
Table is drawn from a commonly used set of metadata
2003.
standards. While the core of the table is reused from
the IEEE Std 1516.2 Object Model Template’s Object
2. The Final Report of the Association for Library
Collections and Technical Services’ Task Force on
Model Identification Table, the BOM Model
Metadata (2000),
M. D. Petty and E. W. Weisel, “A Composability
Identification Table has been extended to include
3.
Lexicon”, Proceedings of the Spring 2003
elements from other common standards such as the
Dublin Core, DDMS, and the VV&A RPG.
Simulation Interoperability Workshop, Orlando FL,
March 30-April 4 2003, 03S-SIW-023.
In summary, the BOM Model Identification Table
4. IEEE Standard for Modeling and Simulation
provides the essential metadata needed so that a BOM
(M&S) High Level Architecture (HLA) - Object
can be identified, discovered, assessed and properly re-
Model Template (OMT) Specification, IEEE Std
used. The metadata cataloged within a BOM such as
1516.2-2000.
Purpose (sometimes referred to as intent-of-use), Use
5. National Information Standards Organization
Limitations, integration Use History, Keywords, POCs,
(NISO) (2001). The Dublin Core Metadata
and References to other information such as conceptual
Element Set, ANSI/NISO X39.85-2001.
models, help facilitate not only greater reuse of models
6. U.S. Department of Defense Chief Information
and components, but also contributes to a better
Officer (DoD CIO), Department of Defense
understanding of the capabilities provided by those
Discovery Metadata Standard, Version 1.1, 1 July
Federates that may have been derived from BOMs.
2004.
Additionally, it is widely viewed that the XML-based
7. Defense Modeling and Simulation Office (DMSO),
metadata standards such as BOMs and DDMS will be
VV&A Recommended Practices Guide,
useful for helping enable the semantic web and
Millennium Edition, http://vva.dmso.mil, 2001
supporting the automation of discovery and processes
8. Base Object Model (BOM) Template Specification,
such as the FEDEP through the application of web
SISO-STD-003.1-TRIAL-USE-V0.9b.
services.
9. Guide for Base Object Model (BOM) Use and
Implementation, SISO-STD-003.0-DRAFT-V0.9.
Acknowledgments

In addition to those who have helped co-author this Author Biographies

paper, the following individuals have provided
significant help in developing the BOM metadata that
we have described and in supporting the objectives of PAUL GUSTAVSON is Chief Scientist and co-
the BOM PDG. We wish to thank them for their founder of SimVentions, Inc. He has over 15 years
countless contributions and steadfast support. experience supporting a wide variety of modeling and
simulation, system engineering, and web technology
 Björn Löfstrand, efforts within the DoD and software development

communities. Mr. Gustavson has been a long-time
Larry Root,

advocate and pioneer of the Base Object Model (BOM)
Jake Borah,

concept for enabling simulation composability,
Chris Turrell, interoperability and reuse. He has also co-authored and
 Steve Reichenthal, edited several software development books and articles
 Steve Goss, related to C++, UML and mobile computing.
 Chris Rouget, and
 Tram Chase ROY SCRUDDER is a program manager at the
Applied Research Laboratories, Information Sciences
In addition, we would like to thank the Defense Division, The University of Texas at Austin. Mr.
Modeling and Simulation Office (DMSO) for Scrudder has over 20 years experience in systems
sponsoring this development effort intended to bring analysis and design with the last nine years working in
forth increase in composability within the distributed support of various data engineering and data
simulation communities. management projects in the defense community. Mr.
Scrudder is currently working with a variety of
modeling and simulation programs and initiatives
including the M&S efforts for the Joint Strike Fighter
and Multi-mission Maritime Aircraft programs and
synchronization of initialization data among the US
Army’s C4I and simulation systems. He was a member
of the Drafting Group and Ballot Resolution
Committees for the IEEE 1516.2 HLA Object Model
Template. Mr. Scrudder currently serves as the Product
Development Group Chair for the revision of the IEEE
HLA standards.

ROBERT LUTZ is a Principal Staff Scientist at

JHU/APL. He has over 24 years of experience in the
design, implementation, and evaluation of computer
modeling and simulation (M&S) systems for military
customers. Since joining JHU/APL in 1992, Mr. Lutz
has assumed leadership roles on several M&S programs,
including the Naval Simulation System (NSS), Joint
Warfare System (JWARS), and the Simulation Based
Acquisition (SBA) initiative. Mr. Lutz also served as
the technical editor for IEEE 1516.2 (HLA Object
Model Template) and as working group chair for IEEE
1516.3 (HLA FEDEP). Currently, he is the deputy
M&S lead for the Multi-mission Maritime Aircraft
(MMA) Program, and actively supports the U.S.
Defense Modeling and Simulation Office (DMSO) on
several technology projects. He also serves as a guest
lecturer in The Johns Hopkins University Whiting
School of Engineering.
JANE T. BACHMAN is a Scientist performing
simulation engineering for the Testing, Evaluation and
Assessment Modeling and Simulation (TEAMS)
facility at Naval Surface Warfare Center (NSWC)
Naval District Washington West Area, Dahlgren, VA.
She has over 16 years in M&S and as a member of the
Simulation Interoperability Standards Organization
(SISO), serves as Vice Chair of the Conference
Committee, ex-officio of Standard Activity Committee
(SAC), co-Vice Chair of Distributed Simulation
Process and Tools (DSPT) Forum, and secretary of the
Base Object Model (BOM) Product Development
Group (PDG). Currently, Mrs. Bachman is working on
a visualization tool for the Guidance Integrated Fuze
(GIF).