Introduction
The aXiom Project is a Space and Naval Warfare (SPAWAR) Systems Center, Charleston, S.C., research and development project. As a spin-off from another project, Team SPAWAR began exploring semantic net-centric solutions that would enable discovery of "self-evident truths" from disparate data sources for improved situational awareness.
Under the leadership of aXiom's chief engineer, Michael Howard of SPAWAR Systems Center Charleston, Transformational C4I Branch, the aXiom project has leveraged various Defense Department, Department of Homeland Security (DHS) and federal government sponsor needs to explore advanced concepts and technologies relating to semantics and service oriented architecture. Through development and delivery of various reference implementations, the aXiom Team has developed significant intellectual expertise in the science of ontologies and SOAs. In March 2007, Team aXiom was awarded the SPAWAR Charleston command and control department's C2 Innovation Award for work related to the DHS Domestic Nuclear Detection Office.
The aXiom project is developing a context management framework that goes beyond just data management and current disciplines, such as master data management, by supporting an enterprise view of our environments.
This process begins by utilizing the TEAM (Total Enterprise Management) approach to develop an enterprise concept map. The TEAM model breaks down the enterprise in seven interrelated components as shown in Figure 1. The purpose of the TEAM enterprise model is to provide a complete perspective of an enterprise — the people, processes and technologies that support the workings of the enterprise to fulfill its mission. The DoD has created a domain-specific high-level model of its organization. Labeled as the "DoD Core Taxonomy," this framework is encompassed within the TEAM model as shown in Figure 2.
The TEAM approach is most mature in the application of semantic technology to support Master Data Management (MDM). As a data integration approach, MDM attempts to manage data content, structure, meaning and their respective relationships over time and across all participating components within an information technology environment.
This management is performed by many specific tasks common to most enterprise information environments, including consolidation, federation, propagation, changed data capture and transformation. Within a SOA or enterprise service bus (ESB), MDM takes on a critical role in supporting the integration of rapidly changing data components. But, MDM is more than just a way of aligning data and schema over time.
MDM also must support higher level analysis by correlating similar elements across nonobvious relationships, as in the case of multiple, yet distinct, sensor feeds of the same target object. In this case, MDM ultimately is responsible for presenting that target to system users as a single item.
While communities of interest (COI) across the DoD attempt to align their data to common schema models, the aXiom project has implemented a MDM approach that supports both the dynamic and process-based nature of SOA/ESB implementations by performing all MDM work within a contextual service layer provided by the aXiom framework. This layer represents more than just technology; it also encompasses the dynamic processes of end user participation, participation by the COI and organizational governance acting over time.
While many other SOA reference architectures and implementations have a context layer, aXiom is unique in that it provides a variant that uses semantic technology to support MDM functions, specifically a semantic service providing data mapping and manipulation, metadata storage, conceptual search, semantic inference and integration with correlation engines.
All of these capabilities, in turn, are wrapped in a layer of policy and data providence, thus supporting governance, information security and system evolution. These semantic components vary in maturity, complexity and depth of implementation, but are available to each other, as well as any participant in the framework at large.
But, MDM is only the beginning. The true role of a context management system is to ensure that the correct data is presented at the appropriate time — using the appropriate interface — to the appropriate user. This involves mapping the organizational mission and requirements, business processes, work units and their workflows (mission threads), functions, roles and resources. In a context-based framework, individual roles, not just Web services, are valid resources participating and necessary for the successful accomplishment of organizational goals.
aXiom Context System
The aXiom framework utilizes a dynamic, process-oriented approach to context management (CxMF). This means that design and development of the people (roles) and processes necessary to support context management are interwoven within the technology. The following three areas are specifically called out in the development plan of the framework:
• People
• Process
• Technology
aXiom Context People
The aXiom framework uses a federated approach to context management. This means that while there is initial, top-down mapping for enterprise concepts and rules, individual users are expected, encouraged and supported to participate in the process of evolving the system. The following roles have been defined as minimally necessary to support a basic aXiom framework implementation:
• Analyst
• Manager
• User
The aXiom context analyst performs the initial discovery and documentation of enterprise concepts. Individuals acting in this role must translate policy documents and stakeholder interviews into artifacts that can be used to build formal ontologies and rule sets that describe enterprise concepts. The context analyst also works closely with the technical team in designing interfaces, business processes, workflow and data access requirements.
The aXiom context manager is responsible for the creation and maintenance of all enterprise ontologies and rule sets. The individuals in this role work very closely with the technical team to ensure that the lower-level functions of data access, data/ metadata correlation and custom correlation work within the actual technical resources of the organization. This role is also responsible for mapping the various ontologies to each other in a way that meets enterprise goals and requirements.
Finally, this role is responsible for the most challenging portion of context management: adjudicating the various requests from users and COIs to integrate custom concepts and rules into official ontologies of the system itself.
The aXiom user is a generic role played by all participants within the system. Users have the capability of creating concepts, properties and metadata values, either in their own ontologies, or within the ontologies they have been granted write permission (typically at the COI/work unit manager level). While this is an unprecedented level of system access, the impact on system performance, data accuracy and mission accomplishment must be weighed against the value provided by these customizations.
All roles require ongoing education as to the goals of the system, the actual capabilities and the general concepts of semantic and metadata management. Education and documentation for each role is an ongoing process that is being integrated into the system via tutorials, contextual help files and training sessions.
aXiom Context Process
The process of context management is still an evolving and challenging arena. The aXiom framework uses a high-level, multistep process to attain success in this difficult and necessary arena:
• Discovery/Documentation
• Evaluation
• Cyclical Review
• Revision
The discovery/documentation step involves the initial creation of the enterprise model following the TEAM approach. The aXiom implementation team uses documents, interviews and data schema as the primary sources of information to model an enterprise to a detail level necessary to support contextual operations. While there is always an initial bias on data mapping and business process, the team also focuses on governance, access control and effect criteria.
Effect criteria are rules that govern when a work unit product has been produced and delivered in a format, timeliness, and of sufficient quality to support the success criteria of the organization.
In the evaluation step, the team uses inference and rules engines, as well as community review to establish the completeness, accuracy and appropriateness of the enterprise model. While this step might uncover conceptual inconsistencies in the doctrine and practice of the enterprise itself, the primary purpose of this effort is to ensure that the system’s technical resources can support the specific products, mission threads and goals of the organization itself.
As a final step, the evaluation process will identify the criteria for model evolution, that is, what standards must be met before new concepts and rules are incorporated into the doctrinal enterprise model that forms the bedrock of system operation.
Once operational, the enterprise model will evolve. This evolution will be driven by both technical realities, feedback from day-to-day operations and user-contributed additions and extensions to the model.
The purpose of the cyclical review is to establish a scheduled, published and resourced review process that will use criteria defined in the evaluation step to identify candidate concepts created by users and COIs for inclusion into the enterprise model baseline. Additionally, the context manager will use statistical techniques and tools to identify nonobvious emergent concepts and properties that indicate operative trends and conditions. Identified changes are subject to the same criteria for inclusion into the baseline.
The revision step is the process where new baseline concepts and rules are actually tested and implemented into the system as a whole. Due to the potential negative impact that might occur from inconsistencies during transition, this is a distinct step. Starting with a comprehensive test environment and implemented ideally during an operational pause, the system itself will incorporate changes into the baseline and subsequent tests for consistency (process as well as data) will be performed.
aXiom Context Technology
To make enterprise concept maps more than just readable artifacts and to operationalize context within the organization, the aXiom framework relies on semantic technology (including an ontology-based metadata management system, inference engines and a semantic rules engine). Ontologies are not only used as the basis of all configuration operations within the aXiom framework, but they also play a particularly important role in the following specific areas:
• Concept-Data Mapping
• User-Driven Concept Model Enhancement
• Nonobvious Relationship Discovery
• Dynamic Data Discovery
• Context-Based Data/Function Security
• Concept-Data Mapping
The core of aXiom’s context capability is the map between concepts and the data elements available to the framework. At the most basic technical level, this means mapping the XML schema of all known data services to a common core ontology (aXiom core ontology). This ontology is then made available to other domain-specific ontologies. These additional ontologies can be COI-specific, for example, antisubmarine warfare, or can be used to expose aXiom data and functions using other standard models.
Other aXiom context services have primary dependencies on the data mapping. The search service, for instance, allows users to search for common concepts across all data sources without having to specify or have foreknowledge of these data sources. A specific example is a search on the concept of “person.”
While multiple data sources for this information might exist, the user does not have to be aware of these data sources nor their access methods. Additionally, because the aXiom framework enforces information security in an integrated fashion, users are only allowed to see those elements of data for which they are explicitly authorized.
From a system management perspective, this mapping power provides significant benefits over time. As new data sources become available they can be integrated into the overall data model simply by mapping their elements to the aXiom core ontology. From the user’s perspective, their interfaces don’t change, but the richness and variety of their data increase seamlessly. Analytical functions or other automated processes that rely on the mapping service also benefit from a lower refactor rate.
User-Driven Concept Model Enhancement
In the past, semantic technology has relied typically on top-down, centrally-controlled concept models. While the aXiom core ontology is centrally controlled, the contextual services layer allows individual users and communities to create and map their own ontologies to the core. These independent ontologies allow community-specific (and community-controlled) tagging, annotation and extension.
This additional metadata can, in turn, be made available to all users as a whole, thus supporting workflow, information assurance and the necessary collaboration between analytical and operational communities across all phases of operations. As these independent concept models mature, aXiom administrators can choose the “best of breed” for eventual inclusion into the aXiom core itself, providing a balance between centralized control and the inevitable evolution of the system itself.
As an example of the power of user-driven concept model enhancement, consider an analyst tracking insurgent financial networks within a given area of responsibility. From unstructured human intelligence reporting, analysts can, for example, determine that certain groups are using the color of tennis shoes as a signal for who is the authorized intermediary for financial exchanges. As a result, analysts can create their own extensions to the aXiom core ontology adding “shoe color” as an attribute on the person concept. Additionally, analysts can share this extension with specific users (or COIs) to further track and identify these networks.
Nonobvious Relationship Discovery
Semantic technology involves more than just managing metadata for user interaction. With the addition of inference and semantic rule engines, context services can provide significant analytical functions based simply on the concept models themselves. A specific example can be seen with the aXiom search server. Consider a user who wants to explore how a given person is connected to other non-family members.
First, the user creates a relationship property in the ontology, calling it “is connected to.” By default this is a transitive property meaning that if person A “is connected to” person B, and person C “is connected to” person B, then person A “is connected to” person C. The user then adds the specific relationship types from the core ontology to be considered “is connected to.”
Because the “is connected to” relationship property is immediately available to the user as a search criteria, the user then simply searches on the identifying information of the person of interest and all connections to this person from all data sources are immediately returned as a result.
With the addition of data-specific correlation engines and user-defined semantic rule engines, aXiom can provide sophisticated, nuanced and evolving strategies for automatic entity disambiguation, which has long been considered one of the most difficult analytical challenges. Because aXiom supports user-extensible concept models, COIs can choose their own strategy for correlation.
Consider the concept of an “event.” For an operational COI, the rules for determining which actions are included in a single event (and which are part of a separate event) can be dramatically different than for an analytical COI. The aXiom context services can support both.
Dynamic Data Discovery
New concepts and data created within the aXiom framework are immediately available to users (subject to originator release and classification provisions). For data from external sources, aXiom implements several components to assist with the dynamic discovery of new external data sources. First, the aXiom framework regularly queries external SOA repositories to identify additional data sources.
The data access methods and data formats of these new data sources are then scanned with text extraction technology and provisional mappings to the existing aXiom core ontology are created. An alert is then sent to the aXiom administration team. Once notified, the team performs the final integration and mapping and exposes the new data source to aXiom users.
Context-Based Data/Function Security
Appropriate access to system data and functions isn’t simply a matter of DoD classification, it also involves user roles, unit workflows and organization governance and, of course, the appropriate technology transport and presentation systems.
Through use of COI semantic inference and business rules, applied as defined by mission functions, access to Web services, user interfaces, available data, automated network configuration for geographic locations, interoperability between organizational SOAs and organizational workflow can be determined for a specific user at login.
By mapping security policy to these enterprise concepts, aXiom includes all facets of information security in decisions about data and functional management, while maintaining integration with existing security and authorization schemes.
Additionally, the aXiom framework supports ad-hoc information security requirements, allowing, as an example, COIs to set and manage the security on their own evolving sets of information and process. This extensibility is a key factor that supports the real-world flexibility requirements of operations conducted with coalition, host-nation and law enforcement partners.
In March 2007, Team aXiom was awarded the SPAWAR Charleston command and control department’s C2 Innovation Award for work related to the DHS Domestic Nuclear Detection Office. For more information, go to http://enterprise.spawar.navy.mil.