 |
Page History
| Wiki Markup |
|---|
{scrollbar:icons=false} |
Semantic Infrastructure Concept of Operations - Existing caBIG® Semantics Implementation
| Align | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Today's caBIG® Semantic Infrastructure forms the basis of the semantic interoperability capabilities embodied in the implementation of Data Services on the caGrid.
The existing caBIG® semantics implementation supports only the recording of data semantics. It does not embody all various properties of the three viewpoints shown in the VKC:logical components diagram, the VKC:contract design diagram and the VKC:deployment runtime diagram (explained in discussion of architectural infrastructure in these pages) and required to support services discovery and reuse.
Specifically:
- The role played by each system is implicit. In a services paradigm, this is sufficient for the client, but not for the service implementation. The role should be characterized by standards in accordance with RM-ODP viewpoints and describe the policies including permissions, obligations, and prohibitions.
- The data service has a single operation: Query. This service has a contract that dictates the terms by which it may interact with other systems, "Query by Example" (QBE), and is intended for use with any information type. It may not have rules associated with the information is passes through the service.
Info title Additional Information The pre-condition behavior of a contract is issue a request to the index service for an end point reference. The behavior is the fulfillment of the query. The contract is between the client (initiator of the query) and the system (the responder to the query). The contractual context exists for the period of the behavior.
- In contrast, the information that is exchanged through analytic services may be built from an analytical process – it may be necessary for the rules to be modeled with the information.
The compatibility guidelines serve to insure that the behavior can be performed and, separately, that the objects exposed are sufficiently annotated semantically. However, since these semantics are at least partially derived from rules about the information, depending on how the information was modeled, there is a potential disjoint between in the details, available through a general query interface, and the requirements needed for usage of the information.
The disjoint between the specified role, the interface, the information objects, and the environmental contract of the deployed service implementations seems not to be a problem in areas of high trust where business rules are not associated with information objects or where their application is unimportant. This is true in many of the research applications.
Where this same pattern is intended to apply to more business-oriented implementations (clinical data), this pattern is difficult to implement because of the disjoint between the rules and the exposed information. In other words, when a developer wants to simply expose data through a Data Service, this pattern may be sufficient and powerful, but when it is intended to be repurposed for other uses, problems may arise. For example, it is typical for a research data service to expose the data points that resulted from an analysis "Smoking Indicator," but not to expose the set of raw data that was analyzed in order to make this assessment. This limits the usefulness of the data point "Smoking Indicator" since the consumer of the data wouldn't know what criteria were used to make establish this indicator's value.
caBIG® already provides a vast framework for tools, tooling, and other pieces of infrastructure. Using the architectural infrastructure noted above, the existing caCORE tools and some of the caGrid infrastructure may be categorized by the component of the new Semantic Infrastructure to which they relate. Re-use and adaption of the existing semantics is preferred over replacement whenever that is the cost effective solution to semantic requirements.
Below is an initial list (perhaps partial) of existing tools categorized by the project or package in which they are currently developed and managed. This list will serve as a starting point for the comprehensive mapping and assessment of the gaps between current infrastructure and the architectural infrastructure noted above, which are intended to support a caBIG® enterprise SOA. While existing tools may only partially meet the functionality of the proposed architecture infrastructure, the rationale for using, adapting or replacing them will be contained in the project documents generated for each of the initiatives proposed by this Concept of Operations.
Initial Allocation of Existing Tool Packages to Components of the new Semantic Infrastructure Packages Component
| Advanced Tables - Table Plus | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||
|
| Wiki Markup |
|---|
{scrollbar:icons=false} |
