The Model and Annotate category defines profiles supporting models, and includes capabilities related to model maintenance, constraints, bindings, extensions, and semantic annotations.
The Semantic Infrastructure provides capabilities for supporting the following kinds of models:
- Information Model. The Information Model of a service must specify the syntax (structure), and semantics (meaning) of the action messages and event notification messages as part of a service interface. It must also specify the syntax and semantics of any data that is carried as part of a payload of the action or event notification message. The information model exists at multiple levels of abstraction, which may be characterized as Computationally-Independent, Platform-Independent, and Platform-Specific. The model is often partitioned into multiple resources, reflecting levels of derivation from a set of standard semantic models. The portions of the model which characterize message interchange payloads are sometimes reflected in a Forms model, which may include specifications of style, syntax, and semantics for ODM, CDA, and other common clinical document standards. Information models may be expressed in different model languages, with data mediation capabilities facilitating interoperability between consumer and provider models. Information models may be semantically annotated with application-specific attributes (for example, defined using ISO 21090 healthcare datatypes). Information models may also define relationships between its attributes and data elements in the broader ecosystem.
- Behavioral Model. A behavior model characterizes the knowledge of the actions invoked against the service and events that report real world effects as a result of those actions; characterizes the temporal relationships and temporal properties of actions and events associated in a service interaction; describe activities involved in a workflow activity that represents a unit of work. The Behavior Model provides an unambiguous definition of the service constraints, capabilities, dependencies and interactions. The metadata and grammar required to realize service behavior is called behavioral semantics. Behavioral semantics provide a mechanism for better service discovery and enforcing the constraints at design and runtime.
- Content. It is encouraged to utilize formal models to express SAIF/ECCF traceability from service to business requirement. This formalism not only ensure that implemented services are compliant with business requirements, but also provides a "line-of-sight" from operational outcomes to computable business objectives. However, in order to support unstructured business requirements, scope, and vision, artifacts as unstructured text are supported by the Semantic Infrastructure. Examples may include storyboards, and scope. This unstructured content becomes an integral part of service specification, and content is leveraged across the enterprise for documentation and communications.
All Information and behavior models, along with their representation and binding to data-types and terminologies will be managed by the semantic infrastructure.
Link to use case satisfied from caGRID 2.0 Roadmap: The pathology, radiology and other data have various data formats which must be described, and the information model for the patient record must link between these various datatypes. The complete information model includes semantic links between datasets to build a comprehensive electronic medical record. Annotations on data are defined and included in the information model.
Functional Profile
- 5.2.1.3.1 - Bind Models Sept. 6, 2010 Bind models to data types and value sets.
- 5.2.1.3.2 - Constrain Sept. 6, 2010 A policy represents some constraint or condition on the use, deployment or description of a resource as defined by a participant or, more generally, a stakeholder. A contract is a constraint that has the agreement of the constrained participants. A policy constraint is a measurable proposition that characterizes the constraint that the policy is about. A permission constraint governs the ability of a participant or other actor to perform an action or enter some specified state. An obligation constraint governs the requirement that a participant must perform some action or maintain some state.
- 5.2.1.3.3 - Extend Sept. 6, 2010 There were more requests for various types of extensibility than any other category of request other than improvements to tool interfaces. caBIG users and other stakeholders articulated a compelling business need to readily extend models, terminologies, and data elements in a variety of ways.
- 5.2.1.3.4 - Model Sept. 6, 2010 Create, destroy, edit, and maintain models.
- 5.2.1.3.5 - Semantic Annotation Sept. 6, 2010 In a diverse information environment, semantics must be used to clearly indicate the meaning of data. This requirement is expected to be addressed by the Semantic Infrastructure, although there will be a touchpoint between the caGrid 2.0 and the Semantic Infrastructure to annotate data with semantics.
