Today's battlefield requires agility in a matter of minutes, not hours or days, but there is a critical data sharing gap at the tactical edge. Implementation of the DOD Net-Centric Data Strategy through XML-based data standards is essential to fixing this problem and providing an environment where interoperable data is available to the war-fighter wherever and whenever needed. To address these challenges, we are developing a collection of data components that provide semantics understood by all, and rules for composing them as needed into data exchange specifications. This effort is known as the C2 Core. Possibly the first major user of the C2 Core is the Tactical Edge Data Solutions (TEDS) Joint Capability Technology Demonstration (JCTD). The TEDS JCTD was initiated to work with the Services to overcome documented gaps in data sharing, and create a Joint approach to delivering data for use in a leader centric, net enabled future.

The U.S. Department of Defense (DoD) presents an instance of an ultra-scale information management problem: thousands of information systems, millions of users, billions of dollars for procurement and operations. Military organizations are often viewed as the ultimate in rigid hierarchical control. In fact, authority over users and developers is widely distributed, and centralized control is quite difficult – or even impossible, as many of the DoD core functions involve an extended enterprise that includes completely independent entities, such as allied military forces, for-profit corporations, and non-governmental organizations. For this reason, information management within the DoD must take place in an environment of limited autonomy, one in which influence and negotiation are as necessary as top-down direction and control.This presentation examines the DoD’s information management problems in the context of its transformation to network-centric warfare The key tenent of NCW holds that “seamless” information sharing leads to increased combat power. We examine several implications of the net-centric transformation and show how each depends upon shared semantic understanding within communities of interest. Opportunities for research and for commercial tool development in the area of conceptual modeling will be apparent as we go along.

The DoD net-centric transformation will bring extended reach & flexible capabilities through seamless information sharing. This requires breaking down the stovepiped systems that limit commanders from taking advantage of external information and assets. However, stovepiped systems are not all bad: one side-effect of those arbitrary and rigid barriers is to ensure access only to vetted information by authorized participants. As we take down these old barriers, many new information flows and decision procedures become possible. Some of those possibilities are wrong, and should not be permitted. The question for this paper is: Who decides, and what is required to enforce those decisions? We need new procedures and technical features to ensure that the right information gets to the right people, that all information is protected, and that overall information flow policy is preserved for the enterprise. This paper discusses the impact of net-centric operations on technical architectures and some of the options and capabilities that new technologies can provide.

: The DoD net-centric transformation will bring extended reach & flexible capabilities through seamless information sharing. This requires breaking down the stovepiped systems that limit commanders from taking advantage of external information and assets. However, stovepiped systems are not all bad: one side-effect of those arbitrary and rigid barriers is to ensure access only to vetted information by authorized participants. As we take down these old barriers, many new information flows and decision procedures become possible. Some of those possibilities are wrong, and should not be permitted. The question for this paper is: Who decides, and what is required to enforce those decisions? We need new procedures and technical features to ensure that the right information gets to the right people, that all information is protected, and that overall information flow policy is preserved for the enterprise. This paper discusses the impact of net-centric operations on technical architectures and some of the options and capabilities that new technologies can provide.

For meaningful information exchange or integration, providers and consumers need compatible semantics between source and target systems. It is widely recognized that achieving this semantic integration is very costly. Nearly all the published research concerns how system integrators can discover and exploit semantic knowledge in order to better share data among the systems they already have. This research is very important, but to make the greatest impact, we must go beyond after-the-fact semantic integration among existing systems, to actively guiding semantic choices in new ontologies and systems - e.g., what concepts should be used as descriptive vocabularies for existing data, or as definitions for newly built systems. The goal is to ease data sharing for both new and old systems, to ensure that needed data is actually collected, and to maximize over time the business value of an enterprise's information systems.

This paper examines the implications of network -centric warfare for information system development: How should we build C2 informatio n systems for net-centric operations? We begin with six highly-probable predictions for the NCW future. From these we derive a number of present implications for system development: things we should do now, and problems we will have to solve along the way. Our answers touch on the information technology to be employed within the systems, the architectural principles that will guide and structure their development, and the acquisition process used to build and deploy the systems.

Abstract : This paper presents the "C2 Enterprise Reference Architecture" (C2ERA), which is a new technical concept of operations for building information systems better suited to the Network-Centric Warfare (NCW) environment. The C2ERA is the technical architecture mandated by the Designated Acquisition Commander for C4ISR Enterprise Integration in the U.S. Air Force. The C2ERA contains two key ideas. Related activities and functions are gathered into a C2 Node, with a designated node manager responsible for delivering and sustaining an integrated capability to the user community. The development of mission functionality is separated from the system infrastructure. This infrastructure (and the responsibility for it) is divided into one part that must be the same across the enterprise, called the "Common Integrated Infrastructure," and another part that may vary between C2 Nodes, called the "node platforms". Thirty-one briefing charts summarize the presentation.

The data resources in a large enterprise typically exist as many separate islands of data. Each is maintained by a distinct community for its purposes, and is largely unusable by others. It is common to see whole data archipelagos comprised of thousands of separate resources [Ston00]. We would, of course, prefer to see one single integrated data resource usable by all. This is the “grand vision” of data integration: discovery of and access to all data, with multiple sources properly combined, delivered in a form that each consumer can interpret. Decentralized organizations such as the US Air Force might accept for now a slightly less ambitious dream – the ability to establish a connection between islands, a way to obtain any desired information from any other source.

Organizational factors—lifecycles, staff specialization and retraining, and participants' incentives—are too rarely considered in data integration research. We discuss how one can repackage the familiar tasks and research problems, to better fit organizations' needs. The goal is to obtain data integration tools that support an industrial process of data integration.

Questions the panel may address include: 1. Can we create a unified annotation service that applies across all the example media? What are the requirements for each medium, and what is common among them? What infrastructure and standards activities are required? Are they likely? 2. Do we need YADM (yet another data model)? Would XML be a panacea, a help, or a distraction? Should W3C's RDF be used?3. How would users want to discover, query, and view annotations? What are the requirements for performance, integrity, security,...?4. What data administration problems will be created by annotations? What happens when the annotated data changes? What happens when the annotated schema changes? What happens when new products are derived from annotated data?5. What database administration problems will be created? How can we get decent performance, with low administration overhead?6. Are annotations a suitable vehicle for collaboration (e.g., collaborative authoring)? Which problems might be solved? Which problems remain?

The DARPA Intelligent Integration of Information (I3) effort is based on the assumption that systems can easily exchange data. However, as a consequence of the rapid development of research, and prototype implementations, in this area, the initial outcome of this program appears to have been to produce a new set of systems. While they can perform certain advanced information integration tasks, they cannot easily communicate with each other.With a view to understanding and solving this problem, there was a group discussion at the DARPA Intelligent Integration of Information/Persistent Object Bases (I3/POB) meeting in San Diego, in January, 1996; and a further workshop was held on this topic at the University of Maryland in April, 1996. The list of participants is in Appendix A. The idea emerging from these meeting a was not to force all systems to communicate according to specified standards, but to agree on the following:• A minimal core language, or Level 1 option, which would be a restriction of the object-oriented query language OQL, such that it will accept queries for relational databases. We recommend that all system components be able, at a minimum, to accept queries in this syntax, provided they address concepts (e.g., relations or classes, attributes or instance variables) known to that component. There must be a simple protocol to determine the schema of a system (its set of supported concepts).• A simple format for representing answers. This could also be a fragment of OQL and will be included in the core language specification.• A set of extensions, one of which could be full OQL, and would handle complex structures and abstract types (with methods). Other extensions will be needed to support rules (e.g., definitions of terms that can be shared among components), semistructured data (for self-describing objects), and shared code. A system component could support one or more of these extensions, independently, and there should be some simple protocol to determine the particular extensions that are supported.

Data sharing within and among large organizations is possible only if adequate metadata is captured. But administrative and technological boundaries have increased the cost and reduced the effectiveness of metadata exploitation. We examine practices in the Department of Defense (DOD) and in industry's Electronic Data Interchange (EDI) to explore pragmatic difficulties in three major areas: the collection of metadata; the use of intermediary transfer structures such as formatted messages and file exchange formats; and the adoption of standards such as IDEF1X-97. We realize that in large organizations, a complete metadata specification will need to evolve gradually. We are concerned here with initial steps. We therefore propose a simple framework, for both databases and transfer structures, which can accommodate varying degrees of metadata specification. We then propose some conceptually simple (but rarely practiced) techniques and policies to increase metadata reusability within this framework.

The data heterogeneity problem is well known, and is illustrated in Figure 1. There are five different data schemas, all representing the same information about aircraft maintenance schedules. Systems A and B are different only in the names of the data elements. Systems B, C, and D have a different structure: the type of aircraft is represented as a value in system B, an attribute name in system C, and a table name in system D. Finally, systems A and E are structurally equivalent, but differ in their representation for ACTYPE and the scheduled completion time. In order for any of these systems to exchange information, the data must be converted from the source schema to the receiver schema.