Ontology and Policy Management


JBI Vision for COI and Current Support


  • "In combination with NCES (Network Centric Enterprise Services) core services, future Information Management Core Services will be utilized to dynamically create an information space and manage edge user interaction within a COI. An example of this, from a GIG ES perspective, would allow edge users to discover relevant COIs (using NCES), gain access to the information space (IM access controls using NCES user profiles and underlying security mechanisms), and exchange or manipulate relevant information (using IM core services). In this manner, an IM-enabled COI would have the full suite of core service information management capabilities, but would still be based on and have full access to NCES services. Together, NCES and IM core services will be utilized to develop end user applications targeted at mission-specific COIs to facilitate a secure, controlled information exchange and decision support environment. Within the GIG infrastructure, multiple IM-enabled COIs and other edge user applications will be established to satisfy specific end user needs. IM-enabled COIs will be capable of sharing their information among each other as well as other edge users operating on the GIG. The net result is that each user will have capabilities above and beyond what any individual service capability provides."
  • "MIO (Managed Information Objects) types can also be structured in a tree abstraction called a Community of Interest (see the RI Information Management Staff Administrators Guide for a more thorough discussion). Implementation-wise, it still is a hierarchy much like the parent-child relationship except that no schemas are required to establish a node in the COI hierarchy – it’s just a grouping much like directories are to files at the operating system level. Computer users don’t store all of their files in one giant directory, nor do they use nondescript file names like myfile1; they take the time to build a meaningful directory structure (COI) in which to place their well-named (typed) documents. COI structure is usually formed to classify MIOs functionally if they’re critical to a process (e.g., by tactical operation) or organizationally if agencies require specific management oversight on their information."
  • "The JBI RI allows for a higher level abstraction called a Community of Interest. Implementation-wise, it is a hierarchy except that no metadata schemas are required to establish a COI tree sub-path. Just like individual computer files shouldn’t be crammed into a single giant directory, MIO types should be organized into some meaningful structure. The ultimate structure is an ontology defined for each COI with ontology translation rules between the universes of participating COIs. The RI does not quite accomplish this, but it does have some unique features you should be aware of when you’re ready to create packages and enter MIOs into the MSR. COIs can be set up to denote a functional breakdown like the operations that occur during Intelligence Preparation of the Battlefield or an organizational breakdown like all the agencies that participate in the Theater Air Combat System. The figure depicts an organizational structure one might concoct for the military or .mil domain. It includes three Armed Services and a detailed breakdown of USAF organizations that would be involved in an Air Campaign. The blue nodes are purely organizational representations while the yellow are MIO types defined by their metadata schema. Yellow leaf nodes are child nodes while yellow non-leaf nodes are parents. To follow the complete path to an AOC plans division, you would traverse the tree: mil-usaf-caf-aoc-plans. Another way to represent this path if you’re a Java developer is to use: mil.usaf.caf.aoc.plans, this nomenclature looks like a Java package structure for organizing source code. That is why some of this documentation uses the term package to describe a simple tree structure. In previous versions you had to create roles using the package syntax. In V1.2.6 RI you will be working within a more intuitive tree structure in which to insert MIO types, although you still have to know the old way to create a COI or package in the first place."
  • "The 1.2.6 version of RI Core Services gives the IMS Admin the ability to have schema types belong to their own package. Creating schema types in a package hierarchy will greatly increase the granularity of the security provided by the JBI Administration Web Tools. By assigning privileges to a group of schemas in a package security control over the Communities of Interest is now enhanced. The package structure is very simple, it consists of Communities (folders) and schemas types which have periods as a delimiters. Enhanced package security example: Assume the IMS Manager has two communities of interest, a group that is in training and a group of established developers. The training group will be learning JBI by creating examples types, deleting types and changing metadata. As you can see this can create havoc with other JBI groups if they shared the same Community of Interest. It is better to create two packages like mil.af.rl.train and mil.af.rl.dev and give each group control over their individual communities. The IMS Admin still has Fine Grain Control over schema types and information objects. He can grant privileges across many Communities of Interest to give any JBI users the rights they needs."