This is an archive of an inactive wiki and cannot be modified.

This is a detailed description of one of the general General Use Case Categories abstracted from the possible Use Cases.

1. Abstract

The main common characteristic shared by use-cases falling in this category is the desire for flexibility in matching the needs and goals of end-users of a service or a service-delivery device with the needs and goals of providers and/or regulators of such services.

Currently cell phones and other wireless communication devices allow end-users to subscribe to communication services. These devices are engineered and configured to operate within the constraints specified by regional regulations, which means that they typically cannot operate in regions that are governed by different regulations, nor are they allowed to operate outside of pre-allocated frequency bands. However, recent technological and regulatory trends are converging toward a more flexible architecture in which devices will have the ability to reconfigure themselves dynamically to operate legally in whatever regulatory region and service environment they may find themselves. However the ability of a device to absorb the rules defining the policies of a given region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use. Moreover, since devices in the same service class may still possess different capabilities, one and the same policy may be interpreted differently and may therefore require different implementations.

The use of Service Level Agreements (SLAs) within a Web Services or Service Oriented Architecture (SOA) is another case in which flexible matching of service providers and consumers is desirable. Traditional practice typically entailed that service definitions, parameters, etc. be more or less fixed and agreed upon by consumers and producers statically. The advent of web-based service architectures offers the possibility of a more dynamic and flexible approach in which differentiated service definitions can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. However, the ability of a consumer process to understand the rules defining and governing differentiated SLAs is contingent upon those rules being in a form that the consumer process can use.

Both of these examples therefore point to the possible usefulness of a third party system sitting between the consumers/devices and the service providers and or regulatory agencies. The role of these third party systems would be to allow service providers and regulatory agencies to write the rules defining and governing their services once and register them with the third party system. This system would then provide a platform within which suitable interpretations and ultimately translations of those rules can be generated for any consumer process or device interested in using them.

The key distinction between this use case and the Write Once, Run Everywhere use case can be easily drawn by appeal to the concept of a metamodel. The latter case deals with situations in which interchange is based on the assumption of a shared metamodel that is specifiable within the RIF. A third party rule-interchange service that does translation would not provide much value-added in such scenarios since the tools and rule-platforms in those use cases would already be able to export-to and import-from other such systems that share the same metamodel and can use the RIF.

The situations presented in this general use case, on the other hand, are instances in which rule-interchange either is not based on the presumed use of a single shared metamodel or in which the point of the interchange is to enable different versions of a rule-set based on various non-formal factors can be generated and maintained.

2. Status

This is a generalized use case. For the status of the use cases it subsumes, follow the links to related use cases in the next section.

3. Links to Related Use Cases

This generalized use case is based on:

4. Relationship to OWL/RDF Compatibility

This is a generalized use case. For relationship to OWL/RDF Compatibility of the use cases it subsumes, follow the links to related use cases in the previous section.

5. Examples of Rule Platforms Supporting this Use Case

This is a generalized use case. For Examples of Rule Platforms etc, of the use cases it subsumes, follow the links to related use cases in the section above.

6. Benefits of Interchange

* Neutral format - enabling the separate organizations at each end of the service link to publish and inspect the transformation definition, independent of the rule implementation technology.

* The interchange format enables the use and integration of SLA engines from various platform and in a web-based and distributed fashion

7. Requirements on the RIF

8. Breakdown

8.1. Actors and their Goals

8.2. Main Sequence

Provide the typical course of events, ordered as below in a sequence of steps.

  1. First step of sequence

  2. ...

  3. Last step of sequence

8.3. Alternate Sequences

Describe possible variations of the main sequence in separate subsections, assigning a title to each.

8.3.1. (Title of Alternate Sequence)

Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).

9. Narratives

Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.

9.1. (Title of Narrative)

Describe an individual scenario. Samples rules and other test data may be optionally included.

10. Commentary

Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.