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.
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.
Expressivity:
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:
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 |
Description |
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. |
|
| Validation |
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. |
Equality |
| 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. |
Negation? 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? Negation? 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. |
| Scripting |
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.