|
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 its just a grouping much like directories
are to files at the operating system level. Computer users dont
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 theyre
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 shouldnt 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 youre 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 youre 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."
|
|