Rule languages for interoperability: HP Position paper

Dave Reynolds (
Jeremy Carroll (


We outline our perspective and position on the issues involved in scoping an interoperable rule language for the semantic web. This is based on our experience with developing and supporting the Jena rules language and on the usage of such rules within some of our current semantic web applications. We also offer the start of an analysis of potential use cases and their implications for scoping such a rules language.


Our primary interest is in the specification of an interoperable rule language for use in semantic web applications. Rule languages are widely used in other contexts but we feel that (a) several such needs are already covered by existing efforts (e.g. OMG's work on Business Rules), (b) W3C standardisation efforts in this area should be narrowly scoped to aid timely progress, and (c) there is a need for a semantic web rule language layer. We expand on the need for standardisation of such a layer later when we look at use cases.

Our views on the role and requirements for a semantic web rules language stem from our experience developing and supporting the Jena rules language and from our use of rules in various semantic web applications.

Jena experience: In Jena we have supported a set of rule engines (both forward and backward) for RDF processing for a little under two years. The aim of these engines was two fold - firstly as an implementation vehicle for processors of RDFS and some OWL/full fragments, secondly as a generic mechanism for developers wishing to perform RDF transforms and inferences not easily expressible within RDFS/OWL. Both usages were seen as largely Jena-specific and we did not intend these languages as a general purpose KR extension but as an local processing tool.

Judging by support list traffic (bearing in mind that this is subject to significant sampling errors) usage of these rule engines by Jena developers has been high. The applications indicated by the list traffic include security policy expression, event triggering, non-DL RDF inference and structural transformations. We see usage of both the forward engine (event triggering, transforms, some general inference) and the backward engine (policy checking, some general inference). Usage appears to be roughly evenly split between standalone RDF processing and combinations with RDFS/OWL processing. Aside from scaling/persistence issues the primary extension requests revolve around the (extensible but minimal) set of procedural primitives provided - particularly greater support for date/time arithmetic. There has been some interest in supporting negation and one contributed extension in that area though some of these needs appear to have been met by simpler closed world testing of non-inferred data properties.

Application experience: Our own use of rules within applications falls into several categories: tuning RDFS/OWL subsets to trade off expressivity/performance, implementation of non-DL semantics, transformation and abstraction of RDF models for data integration, generic scripting tool for simple data rewrites.

Scoping issues

Based on this experience we can begin to analyse some of the use cases for rules within the semantic web and explore which of them would benefit from interoperability. First we outline some of the issues in scoping an interoperable semantic web rule layer so that we have these in mind when looking at the use cases. Of particular note, from our perspective, are:

Layering with OWL/RDFS:
One approach to a semantic web rule language is to regard it as an extension of the existing ontology languages to enable richer knowledge representation. SWRL's [SWRL] extension of the OWL semantics is one example of this. However, this requires rule language implementations to also implement OWL semantics and the combination is in general undecidable ([SWRL][FRANCONI]). In our experience a significant set of use cases for a semantic web rule language can be met by RDF processing without OWL integration. A further set of uses can be met by a layering approach in which rules are able to process the results an OWL classification or inferred triples can be submitted to an OWL reasoner. Such layering has a straightforward procedural semantics and implementation. In the general case the declarative semantics is not clean but is clear for more restricted layerings (e.g. the "view set" restriction in DL-Log [FRANCONI]).

DL constraints:
If the rule language can explicitly reference OWL constructs (whether by tight integration or layering) then that leads to the issue of whether to reflect the OWL-DL/full distinctions within the rule language. For example, separation of data values and individuals might be required for OWL-DL compatibility but are an awkward restriction for RDF processing.

In designing an interoperable rule language there are several decisions on key features which affect the expressivity and complexity of the language. Assuming a base design of some form of datalog language with a set of procedural primitives (for arithmetic operations and the like) then some of the key design options are:

Closed world negation of non-inferred literals (semi-positive datalog) is useful for internal processing and arises in several of the Jena rule uses we have seen. It less clear if such closed-world processing is appropriate within an interoperable semantic web rule language. It is also unclear to what extent richer support for classical negation is required (well-founded semantics or approximations such as stratified negation).
Object introduction
The ability to invent new data values in the course of a rule computation (whether by permitting non-body variables in rule heads, or by use of an explicit makeValue primitive) usefully extends the expressivity of a rule language [VIANU]. Certainly for RDF processing, bNode introduction has proved useful in several Jena rule applications.
Property variables
Rule languages for RDF processing typically permit variables to be used to match properties, whereas rule languages based around OWL or DL extensions tend not to.
Recursive datastructures/general function symbols
RDF is able to express list datastructures. Some rule processing of such datastructures can be achieved either at the RDF triple level or by use of list primitive procedural calls. However, the ability to construct recursive datastructures could be useful in some applications.
Strong constraints
Some rule languages provide a notion of strong constraints (an empty rule head indicating that the combination of body literals is inconsistent). Such a notation may be useful to express validation rules, though an explicit procedural validation-report action is sufficient for some validation applications.
The lack of unique name assumption in RDF leads to a requirement to express and infer equality and inequality between symbols.

Use cases

We next group our experience with rule applications into use cases and for each briefly comment on their implications in terms of whether and where interoperability might be needed and the implications for expressivity. This is not an exhaustive or fully populated list, we have attempted to sketch enough content to enable the reader to decide if a fully worked out version of this would be a useful framework for scoping decisions. Ordering of the list is not significant.

Use case
Interoperability relevant?
Expressivity features?
View transformation
Data in one RDF form is required by a consumer in a different format. The transformation may involve vocabulary substitution, property omission, structural abstraction (replacing a subgraph by a node), structure introduction, structural rewriting and literal value transformation.
Examples: data mediation between two formats, abstracting simple view from rich model for a limited application.
Publish libraries of transformations to support data mediation.
Open interface for servers able to deliver tailored views specified by view rule set.
c.f. XSLT.
Object introduction
[property variables]
[[recursive data structures]]
View integration
This is an extension of the above away from point to point transformations to situations where several data sets are to be merged into a common model. The extension affects the processing model but probably doesn't significantly affect the required expressivity or the relevance of interoperability
Libraries of integration-related transforms.

Express application-specific constraints on an RDF data set which need to be met before further processing can proceed.
E.g. Closed world cardinality constraints, cross-property constraints, non-trivial mathematical constraints.
To enable an application to publish constraints in a standard form, to an open set of clients, for documentation or active validation
Expression of pre-/post- conditions in process models.
Validation report action or strong constraints.
Ability to invoke selective closed world assumptions.
Negation of ground data.
Implementation of semantic web standards
Rules can be used to implement RDFS and some OWL fragments as well as emerging best practice vocabularies such as SKOS [SKOS].
They permit coverage/performance trade offs for particular application usage.
Share implementation rule sets.
Definition of subset profiles agreed between groups.
Definition of semantic web standards
Informative rule base to explicate standard to encourage greater implementer uptake (e.g. RDFS).
Normative rule base to specify profiles.

Knowledge representation to complement RDFS/OWL
Express ontology relationships beyond OWL representation. Examples include: property composition, cross property relations.
Sharing of rule-enriched ontologies.
Strong constraints?
OWL integration or layering
Policy expression
Express a set of conditions which an instance model must satisfy to meet some policy requirement. A generalization of the validation use case.
Example: access control decisions based on model of the information to be accessed, the requested operation and the requester.
Example: expression of a desired state in a control application.
Situations where a policy has be interpreted by multiple independent applications.
Selective closed world?
Reporting actions.
Event triggering
Express a set of conditions in an instance model which should trigger an event.
Example: selective subscription to changes in an RDF repository.
Open subscription interfaces.

Vocabulary for expressing the consequent actions.
Convenient tool for expressing one-off or customizable RDF processing needs. Many such examples may fall into the other use cases like view transformation.
Not clear.

The interoperability requirements indicated by these use case provide good justification for standardisation of a rule language layer. In addition to the value for individual use cases a common rule language would save tooling and skill-building costs for users, even if the rule sets themselves not always shared.

Note on Query
Some of the use cases above can be met by a query language without the need for a full rule language. In particular, SPARQL's CONSTRUCT feature [SPARQL] allows non-recursive view construction. This will be sufficient for some uses of event triggering (e.g. subscription interfaces where you register a query and the action is implicit) and some view transformations.

This suggests, for example, that a semantic web rule language should use a compatible syntax for specifying triple patterns to that adopted in SPARQL.


Based on our experiences and usage so far we outline a starting position for the scoping of most interest to us. This is a starting position, rather than a non-negotiable set of requirements.


SWRL: A Semantic Web Rule Language Combining OWL and RuleML. Ian Horrocks et al, W3C Member Submission 21 May 2004.
Rule and Queries with Ontologies: a Unified Logical Framework. Enrico Franconi and Sergio Tessaris. In Principles and Practice of Semantic Web Reasoning: Second International Workshop, PPSWR 2004, volume 63 of Lecture Notes in Computer Science, pages 50-60, 2004.
Rule-based languages. Vicotr Vianu. Annals of Mathematics and Artificial Intelligence, volume 19, no. 1-2, pages 215-259, 1997.
SKOS: Knowledge Organisation Systems and the Semantic Web.
SPARQL Query Language for RDF. Eric Prud'hommeaux, Andy Seaborne. RDF Data Access Working Group