This Working Group is chartered to produce a core rule language plus extensions which together allow rules to be translated between rule languages and thus transferred between rule systems. The Working Group will have to balance the needs of a diverse community — including Business Rules and Semantic Web users — specifying extensions for which it can articulate a consensus design and which are sufficiently motivated by use cases.
This work is divided into two phases, and this charter only provides resources for the first phase (up to two years). Upon completion of the first phase, the Director may extend this charter to cover the second phase. (See Note on Duration.)
Contents:
The Working Group is to specify a data format or language for rule exchange across systems. This language will function as an interlingua into which established and new rule languages can be mapped, allowing rules written for one application to be published, shared, and re-used in other applications and other rule engines.
Because of the great variety in rule languages and rule engine technologies, this common format will take the form of a core language to be used along with a set of standard and non-standard extensions. The Working Group is chartered to first establish the extensible core and a very small set of extensions, and then to begin to specify additional extensions based on user requirements.
This mission is part of W3C's larger goal of enabling the sharing of information in forms suited to machine processing, as seen in several application areas presented at the 2005 W3C Workshop on Rule Languages for Interoperability:
To help motivate and clarify the scope of this working group, here are three cornerstone scenarios, each illustrating a kind of application which should be supported by the rule exchange infrastructure provided by this work.
Jackson is trying to find someone: he needs at least one more client before the end of the quarter. He has access over the web to dozens of databases, some public, some licensed, and some maintained within his company. Together, they contain millions of potential candidates, but how is he going to narrow the field to the five or ten leads he should seriously pursue?
He thinks for a minute, then constructs a new query. He clicks on interesting properties, sees their values, and locks in the ones he thinks will act as useful filters. After a few minutes he gets frustrated, because the same concepts seem to have different names in different databases. Worse, the same idea is sometimes expressed in different structures; one database follows the Outlook model of having "name of assistant" and "phone number of assistant" properties, while another simply has an "assistant" property, which links to another person. Trying to handle structural variations like this in his query is becoming impossible.
Fortunately, Jackson's system supports a rule language. The query construction interface helps him construct mapping rules between different constructs which seem equivalent to him, letting him infer new information that is customized to his needs, so he can query over a virtual unified database with a structure that seems to him to be simple and straightforward.
In fact, these rules were already being used; the data views Jackson saw were in many cases constructed by rules other people had written. His own rules will be available to his department (because he stored them in department workspace), allowing his co-workers to use the unified view he finds so useful.
Bob goes to his new physician, Dr. Rosen, complaining of a painful cough and some difficulty breathing. The diagnosis of pneumonia is straightforward, and Dr. Rosen prepares to prescribe erythromycin. First, he asks Bob if he is taking any medications. Unfortunately, Bob is not entirely forthcoming: he says no, even though he takes pimozide to help manage Tourette's disorder. The omission seems harmless enough, and Bob is uncomfortable with people knowing about this difficult aspect of his medical history.
Fortunately, Bob uses the same pharmacy for both prescriptions, and his pharmacy checks all prescriptions against a merged, multi-source rule base. This rule base includes the fact that erythromycin is a macrolide antibiotic (coming from the erythromycin vendor) and an encoding of the 1996 FDA bulletin that pimozide is contraindicated with macrolides. When the pharmacist enters the prescription, he is informed of the potentially dangerous drug interaction. He talks to Bob, and with Bob's permission contacts Dr. Rosen to plan an alternative therapy.
The same technology could be made available to doctors, to double check their own knowledge and available references, and to consumers who want to take a greater role in understand their own health care. The key is the ability to efficiently merge rules from multiple sources because we have an interchange language.
Cory is shopping for a home equity loan. A web search finds a site (loans.example.com) of which Cory has heard and which offers to get him three free quotes. He enters the required information. The application form uses rules that indicated that since his location is in California, he is required by state law to specify whether his application is for home improvement. This "intelligent form" means that he is less likely to be have his application returned for additional information. His application is then dispatched to three lenders. The lenders in turn each add his application to their applicant database where it is subject to matching by their rules.
One lender's system determines a suitable rate and sends Cory an e-mail and paper-mail reply immediately. The second flags the application for review by a loan officer who looks briefly at the data before authorizing the automated offer process to continue. At the third lender, Cory is automatically classified as a highly desirable customer, and a loan officer is flagged to call Cory and personally move the process forward.
The rules in each lender's rule base are in fact based on a combination of their own business rules, rules of their aftermarket loan trading partners, and rules encoding government regulations. Again, this becomes much more practical when based on a common interchange language.
In each case, conventional rules technology is enhanced not only by the usual economies of standardization, but also by the ability to exchange and merge rules from different sources. Particularly in the first scenario, we see the kind of ad hoc data fusion which is the hallmark of the Web, finally being done by machine.
It is important for the Working Group to reuse and build on existing technologies and standards, even when it makes the design job harder. The greatest challenge in establishing a rule language standard may be the multitude of existing approaches in the marketplace. Interoperation with the most widely deployed technologies will be crucial for obtaining the desired standardization effect.
The Working Group is chartered to address its mission in two distinct phases. Its mission in the first phase is to produce a W3C Recommendation for a very simple and yet useful and extensible format for rules. In the second phase (below), it will produce Recommendations for extensions which address the broader set of use cases important to the participating communities.
The essential task of the Working Group in Phase 1 is to construct an extensible format for rules. The output of Phase 1 must make it clear how the format can be extended to cover the various user needs it does not address directly.
This means that the Working Group must be responsive to people expressing concerns about extensibility. Comments claiming an inability to extend the language should be addressed with either a clarification (typically in the WG documents) of either: (1) how the desired extension can be performed, or (2) why the intended functionality of the extension is not necessary for the practical interchange of rules.
The core languagePhase 1 rule semantics will be Datalog, also called function-freeHorn logic. This isRules, a logicwell-studied
sub-language of simpleFirst-Order Logic which is also suited to Logic
Programming.
Not every rule engine is able to fully process Horn Rules,
each declaring that if allwhich they have some undesirable computation properties. (They
are Turing Complete; they are not decidable; the deductive
closure of a particularHorn rule set is often infinite.) An often-implement
subset of conditions (the antecedent)Horn is true, then the consequent condition mustFunction-Free Horn, also be true. There may be variablescalled "Datalog",
which bridge between conditions in the antecedentis decidable and betweenhas a finite deductive closure.
This disconnect — the antecedentformat supporting Horn and the consequent.many
rule engines supporting only Datalog — is decidable and relatively simplethe first of many
cases where, naturally, some rules will be expressed using some
feature which a particular engine does not support. The Working
Group must address this situation, specifying appropriate
behaviors, in order to implement.best support its rule-exchange use cases.
While it correspondsmight be possible to mandate that conformant engines
"must" support Horn logic, the logic used in relational databases, such as to define views.Working Group should not do this,
since there will be other extensions, later, for which support
can not be mandated because they are non-standard or otherwise
not cost-effective for wide implementation.
The language must include a way to express facts as well as rules, and also metadata (annotations) about documents, facts, and rules.
The primary normative syntax of the language should be an XML syntax. It is unlikely this format will be practical to author or read directly, except for the simplest rules. Users are expected to work through tools or rule languages which are transformed to and from this format.
The syntax should support named arguments (also called "role" or "slot" names), allowing n-ary facts, rules, and queries to be provided through property/value interfaces, such as in object-oriented systems and RDF.
Note that the natural overlap in expressivity between this
language and RDF means this syntax should function as an
alternative XML serialization for RDF Graphs.Graphs (or possibly a
subset of RDF Graphs, such as those without blank nodes).
The core rule engine functionality is to load zero or more rulesets (or datasets) and then answer zero or more queries against the deductive closure of the merged contents. This functionality can be implemented with forward chaining or backward chaining.
The Working Group should not specify an engine control or query interface (language, protocol, or API) as part of the core specifications, although it is expected to make use of some interfaces as part of the test suite and in examples.
Many rules engines support external operations, such as requesting more data or invoking procedures when certain rules fire or conclusions are reached. These functions are essential to many applications, but they can be built around load-and-query engines, and their complexities and dependencies on other specifications make them not as well suited to being part of the core.
Datatypes need support in the language, including both a
syntax for literals and a set of common functions and operators.
Most of the design and selection work here has been done as part
of XML Schema and XML Query. Boolean, lists,See Relationships
to Other Efforts.
Text strings (xsd:string),
32-bit signed integers (xsd:int),
andunlimited-size decimal numbers (xsd:decimal ).),
Boolean values (a
href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean),
and list structures.
Note that there may be rule languages and engines which do not support some types, eg xsd:decimal, and "good behavior" when encountering these unsupported features during attempted rule use must be explained in the Technical Specification.
Note on Duration: this charter runs until 30 November 2007, to allow for possible unexpected difficulties. If the Recommendation milestone is reached before then and Working Group membership remains sufficient, it is expected that the Director will extend this charter to cover the second phase.
Because of the diversity of rule technology and the ongoing innovation in the field, the rule interchange format must be extensible. The Phase 1 mission of the Working Group was to establish the basic extensibility mechanism and produce a usable language. With that core, vendors and advanced users can begin to use the format. For work outside the small set of use cases addressed in Phase 1, however, they will need to find or create non-standard extensions.
During Phase 2, the Working Group is chartered to produce Recommendations for extensions which are strongly motivated by use cases and for which it can articulate a consensus design. These Recommendations may be released separately, grouped into language "levels", as with CSS and DOM, or the Working Group may decide to use a combination of release strategies to maximize effective deployment.
Note that allocation of resources to complete Phase 2 is not guaranteed. (See Note on Duration.)
As in Phase 1, the deliverables are:
The grouping into documents is at the discretion of the Working Group. Several extensions may be grouped into a single Recommendation, published concurrently as a multi-part Recommendation, or extensions be handled as separate Recommendations. Test Cases and motivating use cases may be included along with a Technical Specification, or kept separate. The Working Group is encouraged to organize the documents in a way which avoids user confusion.
This list of extensions is a starting point and fall-back list for the Working Group. The Working Group may alter this list by consensus decision when doing so is motivated by use cases and does not significantly endanger the schedule.
The general directions for extensions in expressive power lie along two roads: monotonic extensions towards full first-order logic (FOL) and non-monotonic extensions based on minimal-model semantics found in Logic Programming (LP) systems. The Working Group will have to navigate this space and find extensions which best serve users.
AdditionAdditional datatype and data structure support, both for
literal values and functions and operators is in scope, but
should be based on XML Schema and XML Query whenever possible.Query. See Relationships to Other Efforts.
While it is sufficient for the core to say that the rules and data used by a rule engine are expressed in the specified format and loaded by explicit configuration instructions, in practice valuable data is likely to be provided in other formats and via other mechanisms.
Production rule systems are generally built around the concept that when the conditions in a rule's antecedent are met, the rule fires and one or more actions specified in the consequent are performed. In some cases, the actions are just to add more facts to the knowledge base, and the rules are equivalent to Datalog/Horn rules. In other cases, the actions have the effect of running external procedural code, or modifying the knowledge base (which is equivalent to running external code which attempts to modify the knowledge base).
Rule systems typically provide ways to interact with the knowledge base of the running engine. This is generally hard to do in standard, technology-neutral ways, but in two areas it seems sufficiently motivated as well as feasible.
These milestones assume the Working Group decides to call the Phase 1 output "Level 1" and to group the Phase 2 features into two packages, "Level 2" and "Level 3". If the features are not grouped, the milestones will be more complex.
The Rule Markup Initiative has been active since 2000 in developing and promoting rule interchange technology. Versions of the RuleML XML syntax are used in all the rule submissions, and RuleML participants were active at the workshop (which was co-chaired by RuleML co-founder Said Tabet). In short we expect considerable overlap in participation and to draw on technologies and experience developed as part of RuleML.
The JSR 94: Java Rule Engine API effort, part of the Java Community Process, provides a standard way to access rule engines from Java, but does not specify a rule language. At the workshop, JSR 94 Lead Daniel Selman reported that the JSR 94 community was supportive of W3C developing a rule interchange format to complement their work.
Following a September 2003 Request for Proposals on Business Rules Representation, the Object Management Group (OMG) began its Production Rule Representation effort. This group is chartered to specify a meta-model for the representation of production rules at the Platform-Independent Model (PIM) level of the Model Driven Architecture (MDA). This work was described in a paper and presentation at the workshop.
Although there is some conceptual overlap between the PRR group and this W3C Working Group, they are essentially different, with PRR focusing on modeling rules instead of rule interchange. The PRR designers have stated they expect that the W3C format specified by this WG will be a syntax for PRR rules (at the PSM level of the MDA). We expect significant overlap in membership to help us avoid any unnecessary duplication of effort.
@@@OMGThere may be a useful overlap between this Working Group and
OMG's Object Constraint Language (OCL), a part of UML 2.0, especially with OCL At least the extension/restrictionextensions
being definedconsidered for PRRPRR.
The Semantics of Business Vocabulary and Business Rules (SBVR) effort is a response to the OMG's June 2003 Business Semantics of Business Rules RFP. This work was described in a paper and presentation at the workshop. We anticipate some overlap in participants to help bring SBVR's user perspective and use cases to the Working Group.
The ISO Common Logic effort aims to produce "a language designed for use in the interchange of knowledge among disparate computer systems. It will be a logically comprehensive language with a declarative semantics, and it will provide for the representation of knowledge about knowledge". (From the 2001 Proposal for a New Work Item.) This work is considered an inheritor of Knowledge Interchange Format (KIF).
There are important overlaps in functionality between the goals and designs of Common Logic and this Working Group. Some of the Phase 2 extensions (especially FOL) bring this interchange format close to Common Logic, and any differences (such as sequence variables) should be identified in Use Cases and Requirements. We expect some overlap in participants.
The RDF Data
Access Working Group is producing a query language and
protocol for data seen as binary relations (the RDF model). Via
role names, rule data should usebe
viewable this way. Thus SPARQL becomes one path by which a rule
engine may query for more data, as well as a way in which a rule
engine may be queried for deduced answers.
The SPARQL
Functions and Operators specification also shows how XQuery 1.0 /and XPath 2.0
Functions and Operators for it's datatype built-ins, where applicable SPARQL. Thecan be applied outside of XQuery dataand
XPath. This model may be the basisuseful for accessthis Working Group.
The outputs of several Working Groups currently running in the
XML Activity
are relevant to this Working Group. In general, they provide
default designs which should be directly used by rulesthis Working
Group. Any deviation from the default must be strongly motivated
by the use cases and raised as an issue with the other Working
Group (if it is still active), so that misunderstanding can be
avoided and the other group learns about a potential problem with
its work.
The XML Schema
Working Group provides a way to define XML data.grammars,
which may be useful in defining the rule format syntax, and a
model for data types and data structures.
A joint task force of the XML Query Working Group and the XSL Working Group is producing the XQuery 1.0 and XPath 2.0 Functions and Operators, which provides a default list of datatype and data structure operations.
The XML Query Working Group provides a model for logical conditions (query pattern matches) about XML data, a Phase 2 feature
The Working Group should note and borrow as necessary from relevant W3C submissions:
We expect some authors of these submissions will participate in the WG.
To become a member of this Working Group, a representative of a W3C Member organization must be nominated by their Advisory Committee Representative. The appropriate process will be identified in the Call for Participation.
Each W3C Member organization is limited to at most one principal participant and one or more alternate participants of this Working Group. Attendance by an alternate discharges the principal's attendance obligations. In general, there may be at most one alternate, but the chair may allow additional alternates when it benefits the group (such as when one representative is an Editor).
Participation is also open to invited experts from the community, selected by the chair, in accordance with current policy, in order to balance the technical experience of the group. Invited experts participate as principals.
Participation is expected to consume at least one day per week of each Working Group participant's time.
The Working Group's technical discussions will occur on the public mailing list public-rif-wg@w3.org or a discussion Web site (such as a wiki). All technical documents and decisions will be made available to the public through the Working Group's process.
The Working Group will use its @@@home page to record the history
of the group, and which will provide access to the archives,
meeting minutes, updated schedule of deliverables, membership
list, and relevant documents and resources. The page will be
available to the public and will be maintained by the Chair in
collaboration with the W3C team contact.
A one to two hour Working Group phone conference will be held every week. When necessary to meet agreed-upon deadlines, phone conferences may be held twice a week. Each principal (or alternate) participant is expected to participate in phone conferences. The Chair may, at his or her discretion, invite guest experts to attend particular phone conferences.
Meeting records should be made available within three days of each telephone meeting. Meeting records must be made publicly available except for non-technical issues that do not directly affect the output of the Working Group. The Chair decides which issues are not made public.
Participation in face-to-face meetings is limited to working group members and observers invited by the Chair. Decisions may be taken in face-to-face meetings but must be announced on the Working Group mailing list. Observers may take part in decision-making at the discretion of the Chair.
In addition to the required face-to-face meetings, the Working Group may schedule other face-to-face meetings in a manner that maximizes co-location with events that Working Group members would be attending anyway.
The Chair makes Working Group meeting dates and locations available to the group at least eight weeks before the meeting, per W3C Process.
The first face-to-face meeting is being planned for 7-8 December in the San Francisco Bay Area. The second face-to-face meeting is planned for the Technical Plenary.
To be successful, we expect the Working Group to have at least 10 participating Member organizations and invited experts for its duration. We also expect a large public review group that will participate in the mailing list discussions.
The W3C Team expects to dedicate the services of one engineer at 50% for the duration of the Working Group.
This Working Group operates under the W3C Patent Policy (5 Feb 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
This is a draft. It is subject to change, of course. This is $Revision: 1.11 $. See history.
This is the second major revision. See also the first public working draft.
Please send comments (noting revision number!) as follows:
We're aiming for an Activity Proposal to go to the AC for formal review on September 22nd.
Advisory Committee Representatives, please make official Member Review comments using the on-line form.