View Source

{scrollbar:icons=false}
h1. {page-info:title}
{section}
{column:width=75%}
{anchor:ContentsofthisPage}{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}
{column}
{column}
{include:SI Conop Sidebar to Include}
{column}
{section}
h2. Assessment of semantic unification of compositional and derivational models

This initiative is contingent on adoption by caBIG®/CBIIT of a more than one architectural style. It focuses on assessing the ability of the resources developed in [Initiative 1|Semantic Infrastructure Concept of Operations Initiative 1 Repositories], [Initiative 3|Semantic Infrastructure Concept of Operations Initiative 3 Rules] and [Initiative 5|Semantic Infrastructure Concept of Operations Initiative 5 Compliance] to be aggregated in such a way as to provide semantic unification of artifacts from different architectural styles.

The semantic infrastructure must support clinical domains governed by regulation and complex business relationships, and also research where agility is paramount. Experience has shown that caBIG's model-driven, backend-loaded labor-intensive semantics does not comfortably support the research domain, hence the attempt to develop semantics from line-of-business artifacts (See [Initiative 2|Semantic Infrastructure Concept of Operations Initiative 2 Automation]). The RM-ODP requires well-described information models that can be tied. However, support of both clinical and research domains probably will require changes to the caBIG®/CBIIT architectural model external to the semantics infrastructure. The top-down "derivative" architectural model that works reasonable well for the clinical space is a poor fit for the research domain. caBIG/CBIIT architects have begun to discuss use of bottom-up "compositional" architecture as an alternative that may be better suited to the needs of the research domain. Refer to the following table for a summary of the properties of derivative and compositional architecture approaches.

*High Level Characteristics of Derivative and Compositional Architecture*
Rendered in the text from an attached image that is courtesy of A Honey and J Landgrebe
|| Item || Derivational Architecture Type ("specialization by restriction") || Compositional ("specialization by extension") ||
| Modelling direction | Top-Down: from *single, comprehensive, business level* reference model to small, purpose-oriented models (_"grammar and content are represented in single model"_ | Bottom-up: from *information model primitives* to domain composities (_"separation of grammar and content primitives so that each can be manipulated separately"_) \\ |
| Shared elements | * &nbsp;Reference information model, derived domain information models, localised information models, data types
* Vocabulary rules | * &nbsp;Domain agnostic reference model, data types
* Open (in the sense of easily expandable) library of primitives
* Vocabulary rules |
| Type of reference model | Domain specific, minimal syntax and very rich semantics at the "shared" level (*{_}reference{_}* _model contains both grammar and conten{_}t) \\ | Domain-independent, rich syntax and minimal semantics at shared reference "common model" level ("mostly grammar in the *reference* model")\\ |
| Specialization and Localisation technique | *Restriction:* via property deletions in specialised classes as well as property additions and constraints on attributes\\ | *Extension:* No attribute deletions, use OO-type grammar to manage property addition and OO-constraints to create specialised classes\\ |
| Primary interoperability paradigm | Message exchange/service collaboration based on identical information transport objects carrying infrastructure in payload\\ | Message exchange/service collaboration based on processing of information transport objects derived from shared infrastructure, minimal payload\\ |
| MOF/MDA/XMI and SBVR compatibility | No (or limited)\\ | Yes |
| Examples | HL7 V3 MIF\\ | open EHR (CCTS)\\ |

Assessment and adoption of the compositional architecture approach as a solution to research domain needs is not part of this concept of operations. If, however, two architectural approaches were adopted by caBIG®/CBIIT, the semantic infrastructure would have to support both.

The ii4sm architects have envisioned the logical components of the semantic infrastructure shown in the [the logical components, contract design, and deployment and runtime diagrams|Semantic Infrastructure Concept of Operations - Existing caBIG Semantics Implementation], organized into a "semantic backbone" composing the three sets of interdependent semantic services as shown in the figure that follows. ii4sm believes that a semantic backbone comprising both types of shared elements (from a derivational and compositional approach) can be used to resolve the semantics of shared information from both sources. The figure that follows is a very high level representation that includes several components that are not fully architected. However, it seems clear that in addition to the work done in [Initiative 1|Semantic Infrastructure Concept of Operations Initiative 1 Repositories], [Initiative 3|Semantic Infrastructure Concept of Operations Initiative 3 Rules] and [Initiative 5|Semantic Infrastructure Concept of Operations Initiative 5 Compliance] (which would realize the resources called Information Management, Rules Management and Terminology Management respectively) additional integration would be needed to enable the components to operate as implied in the figure that follows.

*Grouping of Semantics Services*
!SemanticServices.JPG|alt="diagram of grouping of semantic services"!

Some resources not explicitly represented (e.g. ISO 11179 Repository and ISO 21090 Service). Courtesy of A Honey & J Landgrebe

This Initiative will encompass definition and realization and testing of the interactions among the model, terminology and rules components. These tests would be designed to assess the backbone's ability to correctly represent semantics of services designed top down (derivative) and bottom up (compositional) -- assuming both styles would be required to support the clinical and research domain's operations. (Assessment of the ability of the compositional approach to support the need of the research domain for rapid evolution is not part of this proposal. That is assumed to be an initiative undertaken by the life sciences).

h2. Requirements
[Initiative 7 section of the Requirements Initiatives Master List|Semantic Infrastructure Requirements Progression]

h2. Forum
[Initiative 7 - Assessment of semantic unification of compositional and derivational models|https://cabig-kc.nci.nih.gov/Vocab/forums/viewforum.php?f=56]

{scrollbar:icons=false}