Page History

...

• 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.1.1 - Service Classification Schemes Sept. 6, 2010 A classification scheme for organizing services based on business objectives, domain, and usage
  • 5.2.5.1.2 - Service Metadata Sept. 6, 2010 Service metadata includes information about service interactions and dependencies.
  • 5.2.5.1.3 - Transaction Management Sept. 6, 2010 Data updates may include updates to multiple data sources, necessitating the need for transactions.
• 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.2.1 - Analyze Sept. 6, 2010 The use of well defined service metadata promotes better discovery and reuse of services during design.
  • 5.2.5.2.2 - Reason Sept. 6, 2010 This category supports reasoning and using an OWL DL representation of models, and research and clinical data. This addresses a requirement from the BRIDG stakeholder communities. (BRIDG) explicitly called for this capability. This also addresses the CDISC requirement for ontologies
• 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.3.1 - Discover Sept. 6, 2010 A key function desired by virtually all stakeholders is the ability to query by example using an item from a model or vocabulary (e.g., data element, property, data type, constraint, relation, concept, etc.) to find equivalent and related elements defined anywhere in the knowledge repository. The response should provide an easily understood description of the degree and nature of the semantic convergence between the example item and responsive items.
  • 5.2.5.3.2 - Find Sept. 6, 2010
  • 5.2.5.3.3 - Runtime Contract Discovery Sept. 6, 2010 A powerful query mechanism that allows either the service orchestrator or a program to find the services that best fit the requirements of a given process. This increases both runtime and design time flexibility by enabling selection of services based on computable metadata.
  • 5.2.5.3.4 - Service Generation Sept. 6, 2010 Service generation is the ability to generate services from user defined service metadata. The semantic infrastructure provides this metadata and the platform leverages this metadata for service generation. The constraints and policies specified in the semantic infrastructure are inherited by the platform and are enforced as runtime policies.
  • 5.2.5.3.5 - Visualize Sept. 6, 2010 Given the complexity of the models in use, and the large number, users are constantly confronted with the problem of trying to gain an understanding of new domains not familiar to them. Visualizations of models and vocabularies are perceived as essential to this task. The requirement is to provide visualizations that are easy to navigate, that identify the contact points between models and between vocabularies and that allow users to seamlessly move from model constructs to data.
• 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.4.1 - Governance Processes Sept. 6, 2010 The BIG Health vision brings a lot more stakeholders into the KR. Each of these has their own governance processes in respect to metadata and terminology. At a minimum the KR has to be aware of these processes, and their outcomes, to be able to express the status of metadata definitions and terminology concepts it contains. Some stakeholders expressed the wish to manage their governance processes within the KR.
  • 5.2.5.4.2 - Services Sept. 6, 2010 Users expressed requirements that suggest caBIG services are not sufficiently described to determine if they meets a user’s requirements or are interoperable with other services. These requirements are deemed applicable to future KR services.
• 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.5.5.1 - Access Control Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around access control constraints.
  • 5.2.5.5.2 - Design Constraint Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around design constraints.
  • 5.2.5.5.3 - Governance Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around governance constraints.
  • 5.2.5.5.4 - Runtime Constraint Policies Sept. 6, 2010 Service policies help establish constraints on the service specifications and mandate an approach. Policies can be specified around runtime constraints.