SI Sidebar
=<center>caBIG® Semantic Infrastructure - Overview</center>=
==<center>Existing caBIG Semantics Implementation</center>==
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 [Media:logicalComponents.JPG], [Media:contractDesign.JPG] and [Media:deploymentRuntime.JPG] as explained in terms of the architectural infrastructure above, 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<ref>The pre-condition behavior of a contract is issues 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.</ref> 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.
*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 disjoin between in the details, available through a general query interface, and the requirements needed for usage of the information.
The disjoin 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, its 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/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.
Footnote: The pre-condition behavior of a contract is issues 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.
