Semantic Infrastructure Concept of Operations Links |
---|
RM-OPD viewpoints provide different abstractions of the same system. The Semantic Infrastructure provides the means of capturing integration semantics for systems based on three of the five RMODP viewpoints: Enterprise, Information and Computation. From these three the Engineering and Technical viewpoints can be derived. The essential problem space is diagrammed in the model that follows.
Logical Components of the Semantic Infrastructure View
These components are:
- Vocabulary and Terminology
- Terminology Data
- Terminology Services
- Information
- Knowledge Repository
- Datatype Specification
- StatiC Model Repository
- Computation
- Interface Specifications
- Collaboration Specifications
- Enterprise and Business
- Rules and Policy Repository
- Role Specifications
Repositories and services expose semantic components. Note that this logical representation may or may not be realized physically.
Information Semantics support the Information RM-ODP viewpoint and comprise the metadata (or information objects), static models that can be used to create and enable designs and solutions, including invariant schema on the information objects for what must always be true, and dynamic schema that define the allowable state changes of the information objects (ITU-T Rec. X. 906 | ISO/IEC 19793 Use of UML for ODP system specifications). These are housed in metadata repositories including a static model repository. Models are not necessarily wire-format representations - domain analysis models, that describe the dynamic schema for example, may be kept here as well.
Computation and Engineering Semantics support the Computation viewpoint and provide guidance for the Engineering viewpoint. It is comprised of interface specifications, collaboration specifications, and engineering specifications including computational objects and bindings and QoS (Quality of Service constraints) that can be used to create or enable designs and solutions. Interfaces represent abstractions of operations that systems may deliver. Collaborations represent patterns of behavior between and among interfaces designed to fulfill some business need. Engineering specifications describe the mechanisms and services to provide platform independent specification (PIM) including engineering objects, clusters, capsules, nodes, channels and functions required to realize interface and collaboration specifications and the QoS constraints required by the system.
Additional Information
In RM-ODP the computation viewpoint describes the PIM, and overlaps with engineering viewpoint. Together they provide enough detail for the Technology viewpoint to derive the PSM. The engineering viewpoint, based on RM-ODP, must cover the items enumerated in this paragraph: clusters, capsules, nodes,etc. The E-CAT may need translation as to what these are represented as in ECCF (these are from RM-ODP19793 spec) but the point is that there are specific engineering specifications that need to be included.
Enterprise and Business Semantics support the Enterprise RM-ODP viewpoint and include a rules and policy repository, role specifications and processes that will meet the objectives of the enterprise. Rules and policies may or may not be expressed in formalism, such as one that can be articulated in UML using the Enterprise Metamodel (ITU-T Rec. X. 906 | ISO/IEC 19793 Use of UML for ODP system specifications), but this repository houses the regulations and compliant procedures required to support the mission of CBIIT. It includes permissions, obligations, and prohibitions associated with certain objects in the domain, as well as establishing which objects can play which roles. It is intended to provide the necessary specification which form the basis and objectives driving the rules associated with information and computational semantics, although it is a matter of management how and to what degree these would overlap. Role specifications include analysis supporting the capacities, competencies, and capabilities associated with coherent patterns of behavior that a system might play.
Each of these semantic groupings might require or be enhanced by a terminology associated with their domain. These terminologies may be implementation focused (for example, Snomed) or may be structural (for example, typing model components).
NCI CBIIT has certain of these components in place already, though the composition should be evaluated to establish fitness for purpose (see SI Conop Initiatives).
Current Implementations Providing Coverage for Various Semantic Components
Yellow indicates complete or partial coverage. Stereotypes represent mapping to intended infrastructure as discussed in the preceding paragraphs.