What kind of rule specification does it make sense for the W3C to create? There seem to be at least two possibilities:
The former, a representation and exchange format for integrating, say, OPS5 production systems with Prolog and other rules-consuming systems seems a perfectly reasonable thing to standardize. But it's not what the W3C should do; leave that to ISO or OASIS or OMG.
The W3C should make a rules spec that works on and works for the Web. And that means, for all practical purposes, making a rules spec that works on and works for the Semantic Web. And what that really means is making a rules spec that meshes very well with RDF and OWL. Since the RDF case is relatively easy, we'll concentrate in this position paper on the OWL case. Essentially what we advocate is a solution whereby OWL ontologies can be extended by rules, and where rules can use OWL ontologies. In other words, we prefer that the W3C focus on interoperability between whatever rule language emerges and OWL.
There are at least three possibilities for integrating OWL and rules:
In this case a rules spec would define the common intersection of rules and OWL and restrict itself to that intersection. Alone, this leads to very restricted use of OWL and of the rules language as they likely intersections are very small and somewhat odd. This is the approach taken by Description Logic Programs (DLP), which is the intersection of Description Logics (DLs) and logic programming. However, this is not a practical interoperability solution for rules and OWL for two reasons:
There has be a considerable amount of work on combining rule and Description Logic systems, dating to the inclusion of simple production rules in the Classic system (later formalized by means of the epistemic operator, K). More recently, there have been hybrid systems that permit the use of "DL atoms" in the heads and bodies of Datalog style rules (see AL-Log, CARIN, and most recently DL safe rules). All these combinations have the virtue of increasing the expressivity of the combined logics while remaining decidable. We have begun implementing and experimenting with modeling with these languages (see Cautiously Approaching SWRL) and have found them to be promising, though with different strengths and weaknesses. AL-Log, for example, involves the weakest combination. Essentially, on can write Datalog rules with a set of additional constraints in the body consisting of class DL atoms which "type" variables appearing elsewhere in the body. This style seems quite natural for integrating OWL-DL ontologies into preexisting rule sets. Implementation is also quite simple, consisting basically of bolting the DL and Datalog evaluators together.
Of course, this lightness of interaction considerably weakens the expressivity of the resultant hybrid. In the CARIN system andDL safe rules, there is considerably more latitude in the kind and position of DL atoms. In Cautiously Approaching SWRL, section 4, we provide a more extended discussion of various DL safety and how they interact with the expressivity of the DL component. There are several choices that fit in well with OWL-DL.
The final method of combining rules and OWL is to simply extend OWL with fully generalized conditionals with arbitrary combinations of DL-like atoms on both sides of the rule. This is the approach taken by the Semantic Web Rules Language (SWRL). SWRL has the disadvantage of being undecidable and fairly untested in the field. (To our knowledge, there are no deployed complete SWRL reasoners available, other than, perhaps, some experimental translators to first order logic to be run on general first order logic reasoners). However, SWRL has been incorporated in other submissions to the W3C, in particular, OWL-S. This indicates that SWRL could serve at least some other W3C standardization efforts. Perhaps more significantly, SWRL is a proper superset of all the hybrid systems discussed above. Thus, SWRL can serve as a integration framework for all those, and future, hybrids. We find this flexibility compelling. The hybrid system, as decidable fragments of SWRL, provide validation of SWRL's usefulness and implementability. Adopting SWRL, on the other hand, allows us to defer choosing a particular hybrid system to standardize. As the semantics of SWRL is crystal clear, we believe SWRL provides the most appealing starting point for standardization.
A key family of uses cases involve policies of some sort or another. Clearly, the highest value short term policy win is policies for Web Services. At the W3C Workshop on Constraints and Capabilities for Web Services the vast majority of participants expressed the strong need for some activity on this front soon, but there was little agreement on the details of language needed for Web Services policies. However, there was a fair amount of agreement that relatively inexpressive languages were sufficient and, in fact, desirable. The rules based presentations did not get a lot of uptake. Furthermore, the leading industry proposal for a policy language, WS-Policy can be easily encoded in a tiny fragment of OWL-DL (see our service policies page for further discussion and examples). While we are engaged in a policy oriented research project in which we anticipate needing more expressive languages, it is hard to see, at least in the service area, that the deployment experience and industry mind share have yet converged on rich policy languages. Thus, we would argue that Web Service policies are not a strong motivation for a rules working group.
Semantic Web Services (SWS) are an exciting area, with automated composition being one of the most prominent areas of research. Most systems seem to require more or different expressivity than OWL alone seems to offer. (Though there has be a spate of recent work in using somewhat extended Description Logic for service composition; most of the most interesting work is not yet available for citation, Bernardi et al is suggestive.) Again, the service oriented desiderata for a rules language will be driven by the needs of a services oriented working group. The W3C already has a very expressive language for describing service compositions, Web Service Choreography, which seems rather orthogonal to the Semantic Web efforts. If service composition is to be a driver for a W3C rules language, we would prefer to wait until it became clearer what that composition group identified as its primary needs. (Perhaps the upcoming Semantic Web Services workshop will help produce such clarity.)
As a tangent, we do believe that Web Service discovery is a promising area for the W3C and the Semantic Web. But again, industry seems quite content with relatively inexpressive systems such as UDDI. The Data Access Working Group seems to have this under control. It's worth noting that with the CONSTRUCT keyword, the SPARQL language has a very limited sort of rule (with no recursive evaluation of rules; i.e., every rule is an island). Since the semantics of SPARQL queries, especially in relation to expressive datasets, is still uncertain and underdescribed, we do not have a clear idea of how it fits in with our above discussion. Ideally, there will a clear relationship between SPARQL queries, with and without CONSTRUCT, and any emergent rules language.
The final use case we'll discuss is that of almost purely syntactic modification and validation of OWL ontologies and knowledge bases. At the moment, a number of OWL constructs are either verbose, easy to get wrong, or both. It would be convenient to be able to specify macro or rewrite like rules that would easy data entry and ontology construction. K-operator based rules have been used for such things in Classic. We can also imagine using SPARQL for this
One example where this might change the effective, if not the actual, expressivity is for simulating defaults. We were given this example by a partner: They wished to use an OWL DL engine for policy enforcement, with policy violations showing up as a contradiction. In their ontology they had two classes of employee, regular and senior, with senior being a subclass of regular. Senior employees can delegate rights that the rest do not. The problem, of course, is that when they tried a bad assertion, i.e., that Mary the regular employee delegated such right, the system inferred that Mary must be a senior employee. The obvious work around of explicitly asserting of every non-known-to-be-senior employee that they do not have delegation powers was unpalatable from a human factors point of view. Thus, a rule that sanitized the input in this case (that is, upon learning that Sally is a senior employee, the rule would remove her from the no-delegation class and add her to the delegation class) would have been very helpful.