Semantic Qualities

Specifications
Building over C-Infrastructure layer, D-Semantics layer introduces new compatibility issues, especially in RQ evaluation and exchange. Specifications are required to better support RQ semantics. Specified RQ semantics management infrastructure design and interfaces are required to support standards extensions, as industry consensus is progressively reached for specific RQs.

Infrastructure and Semantics
All RQs can be managed at the default Infrastructure or at the Semantics (if available and enabled) layers. Semantics layer validation and use can be defined for any conforming and enabled RQ with a valid formula.

The default Infrastructure mode supports string based qualities. For finer grained semantic support, RQs use corresponding available and enabled semantics “plug-ins”.

Existing QoS specifications already lay some of the foundations for both RQ layers B-Negotiation and D-Semantics, as well as for managing NFPs in some more specific domains (e.g. QoS, FT, Risk).

The separation between infrastructure and semantic layer specifications provides flexibility and structure but requires clear definition to ensure that everything that can be generalized is specified at the generalized infrastructure level and that semantic specifications are reserved for semantics issues. There are many, especially as RQs can often be very domain and application specific.

Infrastructure Level
RQs can be operated at two layers: C-Infrastructure and D-Semantics. By default, they operate in Infrastructure mode. Infrastructure mode, uses generalized character string based attribute values, assuming that applications manage RQ semantics as required (e.g. default or custom).

Semantics Plug-ins
Because formulas can be built on content queries and predicates, operating at infrastructure level is fine in many cases, but an increasing number of RQs will also require semantic specifications.

The OMG QoS specifications (UMLTM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms Specification) offer an interesting basis to build from.

Building on QoS, based on XML, a RQ semantics “plug-in” interface is required to support RQ semantics “plug-ins” that add semantics layer for given RQs.

Specific semantics are used only for the RQs that they are defined, enabled, and validated for. Also requiring specification, RQ semantics bindings are defined and managed through meta-data resources (e.g. attribute types), as well as validated with XML-Schema and Schematron.

At run-time, the semantics “plug-in” for an RQ is typically automatically used, when available and enabled, otherwise, infrastructure level operation is used.

Predefined common semantic RQs (e.g. QoS, ISO, FT) Semantics “plug-ins” require specification.