Professional Documents
Culture Documents
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.
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
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
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
Table 3.1-1 - BOM Model Identification Table and Relation to other Metadata Standards
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
intended. However, this metadata will still be useful
Object class structure table when searching out BOMs for reuse.
Attribute Table Application Use this field to specify the type or class of
Domain application to with the BOM pertains. Choices might
Interaction Class table include Analysis, Training, Test and Evaluation,
Parameter table Engineering, or Acquisition.
Description Use this text field to provide a detailed and
Datatype tables descriptive account of the content of the BOM.
Notes Table Use The author of a BOM should use this text field to
Limitation. provide any known applications for which this BOM
FOM/SOM Lexicon 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
All other tables in the OMT 1516.2 not identified are found the BOM useful should provide feedback to the
those not needed for the BOM. 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
Further discussion on the Model Definition is found in potential users as evidence of BOM quality.
Keywords The BOM authors are urged to associate as many
the BOM Template Specification and also the keywords with a BOM as is practical. The keywords
forthcoming HLA Evolve - OMT Specification, which may come from a list of the author’s own creation.
is also incorporating the Model Definition table. 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,
4 Making the Most of BOM Metadata 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
Let us now examine how we can define and use BOMs organizations.
to support the activities associated to federation References* The use of multiple references is encouraged. One
common reference would be the conceptual model
development and execution. from which a BOM was developed. Other references
would be references to related BOMs or to FOMs
4.1 Defining BOM Metadata 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
In order to make the most of the BOM metadata, it for information that fits one of the other metadata
must first be defined. The key in defining BOM fields.
Glyph This is an image that can be used to represent a
metadata is to ensure that enough descriptive content
has been captured regarding a BOM’s application, so
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
that it can be properly reused. Table 4.1 provides BOMs. The graphic should be as simple as possible
guidance useful for filling out the Model Identification. while still conveying the intended use of the BOM
and differentiate the BOM from others.
4.2 Identifying Candidate BOMs 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,
Requirements and the conceptual model produced from
records and videos. The likely mechanism for
the analysis of requirements can be used as key criteria
canvassing integration Use History metadata is to
to search metadata and identify candidate components /
provide an on-line collection mechanism affiliated with
piece-parts. The objective should be to catalog the
a reuse library where the BOM was retrieved.
requirements and conceptual models in a manner that is
useful for searching and identifying candidate BOMs.
4.4 Mapping Metadata Standards
A good place to start is to mirror the information
within the BOM metadata or another metadata standard It is important to recognize that a BOM can support
such as the DDMS. For instance, a stated requirement other metadata standards (even if labels do not fully
can be mapped to the identified Purpose within the align). This can be accomplished through the
Model Identification table. Additionally, Keywords, application of an XML Stylesheet Language
Use Limitations, and Application Domain provide key Transformation (XSLT) where mappings can be
search criteria and should be identified. created to support this alignment. These XSLTs can
be applied autonomously using an XSLT processor
Identifying these elements makes it easier to locate typically included with an XML Parser, which will
candidate models through metadata matching. Once produce the desired output. This type of mapping
candidate models have been found, one can peruse capability allows for a greater use of data objects to be
additional metadata such as Use History as an aid in made available and understood by the community.
making a final selection.
One mapping in particular that might prove to be
A likely approach for facilitating the automation resourceful is a BOM mapping to the DDMS schema
process of metadata matching and discovery might be structure. As shown in Table 3-1 previously, many of
via the application of web services that are tied to reuse the elements provided by the BOM Model
libraries, which host a collection of BOMs. Identification, can map directly with the DDMS.
Furthermore, the application of requirements and
conceptual models used in identifying candidate BOMs
through metadata matching can then be used to identify 5 Summary
candidate federates supporting BOMs, and/or BOM
implementations such as source code, byte code, and BOMs are seen as a key technology for facilitating the
software components for federates. Hence this could reuse of components in the construction of simulations
help facilitate the automation of the FEDEP process. and simulation environments. For any resource to be
reusable, it must be visible and accessible.
4.3 Integration History and Feedback
By visibility, it is not only meant that the ability exists
Part of making BOMs useful to others is hinged upon to recognize that BOMs are available, but also that they
reflecting integration Use History. It is imperative that have sufficient descriptors to allow a potential user to
as BOMs are used and applied in the construction or determine whether a BOM is appropriate for his/her
modification of a BOM Assembly, FOM, SOM, or use. To that end, a common set of descriptors has been
another purpose that the integration history regarding a defined in the BOM Model Identification Table.
BOM’s use (and success) is shared back to the
communities at large who either use or develop BOMs. By accessibility, which is the second factor in
This feedback involves sharing integration experience 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