NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

  • Created by Unknown User (wileyal), last modified on Sep 30, 2010

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 47 Next »

These pages include:

This document describes all the core semantic infrastructure capabilities and services. The services are organized by functional profiles that together represent the core services and capabilities. The profiles address the following requirements:

  • Artifact Management
  • Terminology and Platform Integration
  • Forms Modeling
  • Conformance Testing
  • Service Discovery and Governance
  • Reasoning and Inference

The functional decomposition of Semantic Infrastructure reflects the structure of the core Semantic Infrastructure requirements. Each functional profile is a grouping of capabilities corresponding to identified Semantic Infrastructure requirements. In addition all requirements identified during Gap Analysis (which immediately preceded roadmap development) have been merged into relevant functional profiles as capabilities with appropriate traceability to the Gap Analysis requirements.

The Semantic Infrastructure is a Semantic Service Oriented Architecture that conforms with the principles and guidelines specified by the corresponding OASIS Reference Models, Ontologies, and Architectures. Within this document, these standards are represented as Semantic Profiles. Conformance with these standards has architectural implications for the business-oriented functional profiles. These architectural implications are reflected as extended capabilities of each functional profile, with traceability to the appropriate Semantic Profile conceptual model for Service-Oriented Architecture (SOA). This traceability, and the associated contextual description, help provide a bridge between the domain-specific terminology used to express requirements and the terminology used to describe the Semantic Infrastructure architecture.

The functional profiles are organized by the Semantic Infrastructure Requirements as follows:

  • 5.2.1 - Artifact Management Sept. 6, 2010 The Semantic Infrastructure supports management, analysis, annotation, publication, query, and transformation of artifacts, including static and dynamic models.
    • 5.2.1.1 - Administer Artifacts Sept. 6, 2010 Artifact lifecycle management defines profiles to manage the lifecycle, governance, provenance, versioning, and representation of artifacts, as well as the relationships between artifacts.
    • 5.2.1.2 - Analyze Artifacts Sept. 6, 2010 Analyze Artifacts defines profiles supporting the analysis of artifacts utilizing semantic queries, reasoning, and rules.
    • 5.2.1.3 - Model and Annotate Sept. 6, 2010 Model and Annotate defines profiles supporting models, including model maintenance, constraints, bindings, extensions, and semantic annotations.
    • 5.2.1.4 - Publish Sept. 6, 2010 The ability to publish and discover information models will be supported by the semantic infrastructure, and the platform will leverage these capabilities.
    • 5.2.1.5 - Search and Access Sept. 6, 2010 The Semantic Infrastructure enables integrated access, search, and visualization of artifacts using a variety of search criteria, model serialization formats, and user interaction empowerment tools.
    • 5.2.1.6 - Transform Sept. 6, 2010 Transform defines profiles for management and application of transformations to support multiple views, serialization formats, inter-operability, semantic convergence, model migration, model merge and compare, and provisioning of target artifacts.
  • 5.2.2 - caGRID 2.0 Platform and Terminology Integration Sept. 6, 2010 The Semantic Infrastructure supports seamless integration with the caGRID 2.0 platform.
    • 5.2.2.1 - Export Sept. 6, 2010 Event Processing and Notifications enables monitoring of services in the ecosystem and provides for asynchronous updates by services, effectively allowing a loose coordination of services that both provide and respond to conditions (possibly defined in business rules).
    • 5.2.2.2 - Search and Access Sept. 6, 2010 This group of capabilities focuses on enabling developers of composite services and applications to discover, compose, and invoke services. This includes the discovery of published services based on service metadata and the generation of client APIs in multiple languages to provide cross-platform access to existing services.
  • 5.2.3 - Case Report Forms Definition and Modeling Sept. 6, 2010 Case Report Forms are the primary channel for capturing information in the healthcare and clinical domain. Forms also play a key role in information exchange and are critical to supporting interoperability in healthcare.
  • 5.2.4 - Conformance Testing Sept. 6, 2010 Services specifications developed by NCI and the community have to be testable to ensure that the implementation conforms to the specification.
    • 5.2.4.1 - Create Conformance Statements Sept. 6, 2010
    • 5.2.4.2 - Search and Access Conformance Statements Sept. 6, 2010 Conformance testing leverages the artifact and service metadata to validate that an implementation adequately addresses the requirements stated in the service specification. An example of service requirement is the ability to specify a response time in the specification (design time) and validate that this response time is valid for an implementation of the service. Additional test points include but are not limited to binding to specific terminologies and domain models.
    • 5.2.4.3 - Test for Conformance Sept. 6, 2010 Testing for SOA combines the typical challenges of software testing and certification with the additional needs of accommodating the distributed nature of the resources, the greater access of a more unbounded consumer population, and the desired flexibility to create new solutions from existing components over which the solution developer has little if any control. The purpose of testing is to demonstrate a required level of reliability, correctness, and effectiveness that enable prospective consumers to have adequate confidence in using a service.
  • 5.2.5 - Service Discovery and Governance Sept. 6, 2010 Service discovery and governance allows service developers to specify rich metadata about services. This enables better discovery, and governance of services.
    • 5.2.5.1 - Administer Services Sept. 6, 2010 Administer Services defines profiles for management of service metadata and service classification schems.
    • 5.2.5.2 - Analyze Services Sept. 6, 2010 Analyze Services defines profiles for service analysis, providing support for determining service interaction dependencies, service reuse, service conformance assessment, heterogeneous data interchange, service collaboration compatability, etc.
    • 5.2.5.3 - Search and Access Services Sept. 6, 2010 Search and Access Services defines profiles supporting the discovery and visualization of services.
    • 5.2.5.4 - Service Governance and workflows Sept. 6, 2010 This includes predefined templates, workflows, and governance policies for governing the service lifecycle as well as an approval and review process for service specifications and the ability to promote services through the stages of the service lifecycle.
    • 5.2.5.5 - Service Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance, access control and other design and runtime constraints.
  • 5.2.6 - Knowledge Engineering, Inference and Reasoning

The semantic infrastructure capabilities and services address requirements and use cases for each domain. In addition to the domain specific use-cases, the capabilities also address CBIIT internal development and architecture requirements. Specifically, CBIIT has standardized on Service-Oriented Architecture as the foundational principle for applications architecture and interoperability. CBIIT has also adopted a formal approach (Enterprise Conformance and Compliance Framework) for defining service specifications. The capabilities address both the requirements for supporting semantic interoperability, and the need to publish formal specifications that can be adopted by external organizations and vendors.

The search and access profiles for each requirement are different as they are customized to access specific information in a defined format. For example, platform tools like the orchestration engine will leverage specific metadata to determine compatibility between two services.

  • No labels