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 Operational Data Model (ODM), Clinical Document Architecture (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 their 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; and describes 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. Use of formal models is encouraged to express Service-Aware Interoperability Framework (SAIF) and Enterprise Conformance and Compliance Framework (ECCF) traceability from service to business requirement. This formalism not only ensures 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 the 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
- 1.3.1 - Bind Models An artifact description associates a resource with normative definitions of value specifiers. A value specifier includes a collection of value sets. A value set is defined in terms of its structure and semantics. A property-value pair construct binds an artifact description to the semantics of a value set within a given execution context.
- 1.3.2 - Constrain 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.
- 1.3.3 - Extend 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 permission constraint governs the ability of a participant or other actor to perform an action or enter some specified state. The ability to extend a service specification, including any associated model artifact, is subject to the permission policies embodied in the contract between the participants.
- 1.3.4 - Model Create, destroy, edit, and maintain models.
- 1.3.5 - Semantic Annotation 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.
