Position Paper for W3C Workshop on
Rule Languages for Interoperability

Ryusuke Masuoka, Zhexuan Song, Sung Lee, Yannis Labrou

Fujitsu Laboratories of America, Inc.

1. Introduction

We are conducting research and development on pervasive computing, grid computing and enterprise software development based on the Semantic Web technologies. Task Computing (TC) is a user-oriented framework that lets end-users accomplish complex tasks in environments rich with applications, devices, and services. Task Computing provides many ways for users to interact with these ubiquitous environments and applies the Semantic Web technologies, such as OWL and OWL-S as its core enablers. Also in grid computing and enterprise software development projects, we strive to let end-users to accomplish complex tasks using services by utilizing OWL and OWL-S extensively.

Initially we did not have to resort much to rules, but as we proceed to add higher functionalities, it has become clear that the rules would play a major role and that the rules have to be shared. In this position paper, we list present and future requirements and use cases of rules in terms as concrete as possible. Some of them may be implemented without resorting to rules, but we tried to make the list as inclusive as possible.

2. Requirements

Here we list the requirements for rule languages. They will be linked in the next use cases section.

As for [R-3], it should be possible to provide user interface to let end-users create rules basically in all of our applications. Logics and its expression or syntaxes can be somewhat (but, not too much) complex as long as the user interface is easy and reasonable and the results of rule applications are expectable for the users.

3. Use Cases

3.1 Service Compositions in Pervasive Environment

Unlike Web Services on the public Internet where the services are accessible from anywhere, service compositions of service instances are less useful in pervasive environments. In pervasive environments, the services (which are provided often from devices) are accessible only within a sub-network in many cases.

In order to enable meaningful service compositions even in pervasive environments, it is necessary to specify each service in the composition by some kind of rules, which the end-user can create on his/her own.

For example, one can compose and execute a service composition in Task Computing from two services, "My File" and "View on Projector". "My File" on your computer lets you select a file from your computer and expose it. "View on Projector" on the network shows on the projector the file given to it and let the user control the presentation. Combining them into a composition and executing it, the user can do a presentation without connecting the VGA cable to the projector.

Saving the service composition (in OWL-S) of those service instances is useful only as long as the user is on the same sub-network. But as soon as the user leaves the sub-network, the service composition becomes useless if the sub-network is inaccessible from the outside (for example, if it is behind a proxy). Even if the similar projector services is available in some other place, the service composition becomes non-executable.

But if the user can save the service composition, "Do the Presentation", something like the following set of conditions for the two consecutive services, it can be used in other environments.

[Condition 1:]
A service which is local and has File output with the name, "My File"
[Condition 2:]
A service which is of a projector service type with resolution more than XGA and it is within 10 meter from the user's current position.
[R-1.1], [R-2.1], [R-2.2], [R-3]
Need to share the rule:
Medium to High

3.2 Input Checking Rules for Semantic Services

Currently in Task Computing, service compositions are driven by semantic matching of input and output of the services. It can match the services when the output of the first service is a subclass of input of the next service.

Many of the matching are described using such a scheme using ontologies, but some of the conditions does not fit well and are done better as execution time input checking.

For example, we have "Route from FLA to" service which accepts an address as an input and displays the map from FLA to the given address. We might want to check the integrity of the address and limit the address to those of the mainland US. We might want to add, in its OWL-S, rules to check if the input address is in US and its state is not Hawaii.

[R-1.1], [R-1.2], [R-2.2], [R-3]
Need to share the rule:

3.2 Service Compositions for Enterprise and Grid

Here we list rules necessary for semantic service descriptions and composition rules in enterprise system development and grid computing.

In enterprise systems, database accesses are essential. We need to capture the effect/result of database read action as something like "After the database read action, it is known that the book is checked out or that the book is not checked out". We assume that we need K- (epistemic) operator to express this.

We also need to express semantic level conditionals for loops and branches based on input, output, and errors the services.

[R-1.1], [R-1.2], [R-4]
Need to share the rule:

Figure 1: Diagram of executable phylogenetic analysis workflow

In case of bioinformatics grid applications, rules can be used to help the user narrow down the options for applications to use for each workflow step. Figure 1 shows a diagram of executable phylogenetic analysis workflow with list of service fulfilling each required function. The application options for each step can be reduced by the user-specified rules. Example rules can be as follows:

Rule for database search:
If target database is a nucleotide sequence database use BLAST, if target database is a protein database use FASTA
Rule for sequence alignment:
If input is set of nucleotide sequences use ClustalW, if input is set of protein sequences use Muscle
Rule for phylogeny inference:
If number of sequences is less than or equal to 50 use MrBayes, if number of sequences is greater than 50 and less than or 100 use PAUP* for maximum likelihood, if number of sequences is greater than 100 and less than 200 use Phyml, if number of sequences is greater than 200 use PAUP* for neighbor joining.
[R-1.1], [R-2.1]
Need to share the rule:

Other general rules to determine which services to use include:

[R-1.1], [R-1.2], [R-2.1], [R-3]
Need to share the rule:

3.3 Policy-based Access Control

We have implemented prototypical policy-based access control for Task Computing. It uses Rei policy engine from UMBC.

In this schema, the credential is checked against its digital signature first. Then, the expiration date/time of the credential is compared against the current date/time to check if it is not expired. Finally, the content (fact assertions) of the credential, ontology, policy rules, and delegation rules are combined to determine if the person has the right. They are something like the following:

Delegation rules:
Policy rules:

From those statements, the system determines that Visitor-A can print or that Employee-B can print. Or without delegation rules, the system determines that Visitor-A can not print.

[R-1.1], [R-1.2], [R-2.2], [R-3]
Need to share the rule: