DRAFT: Semantic Web Rules Working Group Charter

1. Mission

The group is chartered to develop a practical and useful rules language for the Semantic Web, along with a corresponding language for expressing justifications. The rules language will allow the expression of the knowledge that when certain things are true, certain other things must also be true; the justification language will allow the expression of the knowledge of how certain rules were used to reach a conclusion.

This work is based the Resource Description Framework (RDF) in order to enable full interoperation with other elements of the Semantic Web, including the OWL Web Ontology Language and possible future languages for logic and knowledge representaion. The group is to extend and if necessary refine the RDF abstract and concrete syntaxes to allow expressing rules, in direct service to use cases the group gathers during its operation.

2. Scope

2.1. Motivation

The architectural vision for the semantic web has included an interoperable standard langauge for rules for a long time. The readiness and urgency in this field are growing, and have crossed the threshhold for Working Group creation:

• Semantic Web Services work such as OWL-S has found that while OWL allows a lot to be stated, there is a clear need for rules for this work.
• Rules systems have of course existed for a long time, but now we see multiple suggestions for webized RDF-compatible rules langauges. [Horrocks & P-S] [Boley] [Metalog]
• Work on Description Logic Programming (DLP) has shown how OWL and rules language can interoperate, with Rules systems and Description Logic reasoners making partial use of knowledge from the other domain

The full benefit of the technology really depends on the suite of standards being complete. The community needs now to deliver the more powerful tools for expressing facts and relationships on the semantic web. So whereas OWL and RDF technologies will cover certain applications, they also lead naturally to cases in which things need to be expressed which cannot be expressed in OWL alone.

This charter also addresses a language for the exchange of proofs. This is based on the observation that:

• Greater interoperability can be achieved for proff checkers than for inference systems. Whereas sifferent inference systems can in general have completely different inferences given a data set, th etask of checking that an inference was valid is simpler, and always tractable.
• Semantic web technology has requirements for security. The ability justify a given decision and to trace the steps by which it was made and the sources data used is a need expressed by in both commercial and military fields.
• Several existing systems use different languages for this [inference web] [Euler] [PCA]

UMLS presentation at ISWC cited CARIN: A Representation Language Combining Horn Rules and Description Logics (1996) as what they want; others cited triple (in proceedings ISWC June 2002 Sardenia)

2.2 Expressiveness

[[The section is still very rough]]

Without straying too far from the RDF model, two traditional levels of expressive power are natural candidates: the datalog and the Horn clause subsets of first-order logic (hereafter "datalog" and "Horn FOL").

    * Sticking close to the RDF model (no n-ary predicates, no
      function terms), just adding what's needed for datalog and Horn
      rules.   Just   {rdf graph} => {rdf graph}  with variables.
      (The Horn/Datalog line her appears in whether existential
      variables can be scoped inside the consequent.)
 
    * The degenerate form   {graph} => {an inconsistent graph}
      gives us classical negation, aka integrity constraints.

    * The degenerate form    {something true} => {graph}   should be
      writable as just   graph   .  This means the rules language
      concrete syntaxes will include (possibly new) concrete syntaxes
      for RDF. 

The need for rules of the form "for all X, Y, and Z, if P(X,Y,Z) then Q(X, Y, Z)" is clear. (@@cite positive Horn Clause definition, precedent in DAML J-C rules, RuleML, N3/cwm). This necessitates justifications of the form "F is given; P(x, y, z) => Q(x, y, z) is given where [F, P and Q are RDF graphs]; substituting A for X etc. in P(X, Y, Z) gives F; this justifies Q(A, B, C)".

The scope is to create two almost identical langauges, one being restricted to exclude the presence of existential variables in the consequent, in other words to exclude the presence of blank nodes in the RDF graph Q; and the other not being so restricted. Each language has its advantages and disadvantages, and at the time of writing of the charter there is no clear indication that the community will not need both. When one language is a functionally subset of the other, there is clearly a great deal of interoperability to be gained by ensuring they use the same syntax.

The languages will use URIs as symbols; as in RDF.

Any further expressiveness (beyond this RDF-style Horn) must be clearly motivated in the requirements document and agreed by consensus of the Working Group, subject to right of review by related groups.

2.3 Syntax

Due to the wide and conflicted range of expected uses cases, the group is charted to work on multiple interchange syntaxes, including at least one XML-base syntax and one non-XML syntax. Specifically, there are three styles which the group is expected to consider before settling on two or more syntaxes for standardization:

1. Reified in RDF. Instead of being directly expressed, rule expressions can be described and asserted in RDF. With this approach, any RDF syntax (such as RDF/XML or N-Triples) can express rules. Here, rules-language semantics are just semantics for a particular RDF vocabulary.

   This approach allows some reuse of the developing RDF infrastructure and allows all the tools (include rules systems) to work, without modification, with the rules expressions themselves as data.

   Unfortunately, past efforts in this direction have offered extremely verbose syntaxes, and there is little hope for improvement. Additionally, there are unanswered and perhaps troubling question about formal semantics of such systems.

   The group is expected to investigate this area thoroughly and produce a vocabulary for reifying rules (as well as justifications) if the benefits in terms of the identified use cases outweigh the difficulties with verbosity and formal semantics.

2. XML. There are several approaches within this camp, including:

   1. Extension of RDF/XML. An XML syntax could be developed which extends RDF/XML by adding a rule construct and scoped, quantified variables, but otherwise maintains compatibility. The downsides here are verbosity, plus carrying forward all the existing issues with RDF/XML as a syntax. This group is expected to consider this as one possible XML syntax.

   2. Vocabulary Neutral (X-Triples). An XML syntax where the terms are not mixed in with the XML tags has certain advantages, including simplicity of validation.

   3. Ontology or Schema Directed. Alternatively, the terms can be used as tags and meta-knowledge (eg an OWL ontology or an XML Schema) can provide the information which RDF/XML gets from parseType attributes, allowing RDF and Rules information to look like more natural (and less verbose) XML.

3. Non-XML. Expected to be more "human-readable", like Prolog or N3. (@@ justify this, in terms of lowering the bar to entry into the rules world.)

Of course, having too many syntaxes defeats some of the purpose of standardization, so the group is encouraged to provide as many as are thoroughly justified by the use cases, but no more.

[[ Note about the syntax of the OWL Rules Language proposal, which does not maintain independence between Rules and OWL. ]]

2.4 Standard Library

[[The section is still very rough]]

A standard library of built-in terms such as integer sum, string concatenation, and the like, based on the XML Query functions and operators is in scope, since it clearly contributes to interoperability and utility of rules technology. These functions shall be implemented as RDF properties (using RDF Lists to handle n-ary functions, as implemented in cwm). While it is not required that the URIs of the RDF properties be the same as those of the XQuery functions and operators, where RDF functions and operators terms correspond to XQuery ones, the semantics should be exactly equivalent. @@justify - conversion, reuse of code etc.

The standard library of terms may include some which allow access to the web, although this may significantly complicate their semantics. (cwm's log:semantics, see also XSLT's document() function, etc).

Proofs will of course include the ability to refer to the elaboration of such standard library of built-ins.

2.5 Justification Language

[[The section is still very rough]]

A proof or justification language makes it much easier for inferred information to be trusted. Proof checking is computationally much easier than theorem proving.

@@justifications based on the state of the web (ala log:semantics)? in-scope? out of scope? let/make the WG decide?

3. Deliverables

The following deliverables seem to be necessary and sufficient to achieving the mission of this Working Group:

• Use cases and requirements: Use cases to engage the community and requirements to explicitly negotiate planned functionality versus desired functionality. Requirements are the primary mechanism for negotiation with related groups. Some uses cases may come from other W3C work, such as CC/PP and APPEL.
• Tutorial material: to explain the rules technology in successive-elaboration style to those that intend to build tools and to the early-adopter users that will use the technology before tools, books, etc. are widely available.
• A test collection: to capture resolution of issues and facilitate test-driven development of supporting tools.
• Formal specifications: exhaustive design documentation including machine-readable information such as axioms, ontologies, schemas and grammars where appropriate.

4. Schedule

[[ This schedule was written thinking the charter would go to the Advisory Committee by about 7 October 2003, which is no longer the plan, so the dates are probably already too early. ]]

The Working Group Schedule is as follows, subject to negotiation with groups with dependencies:

Jan 2004

preliminary teleconferences, begin collecting use cases and candidate requirements

Feb 2004

1st ftf meeting, Cambridge

May 2004

1st Working Draft of requirements in time for WWW2003 in NY. Perhaps early draft of tutorial and begin organizing tests.

Q3 2004

1st Working Draft of design

Q4 2004

Last Call, perhaps Candidate Recommendation

Q1 2005

Proposed Recommendation, Recommendation

A contingency of 6-12 months may from experience be required for unforseen complications. The scheduled duration is thru March 2005, to allow for this and 3 to 6 months of post-Recommendation work.

5. Related Activities and Dependencies

In addition to traditional W3C wide review and consensus (specifically Internationalization, Quality, and Accessibility) we note the following dependencies:

RDF Core WG

review extension of RDF syntax to accommodate universal quantification, implication

Web Ontology WG

OWL and the Rules language are expected to be the first two major Semantic Web logics; it is important that they work well together

Semantic Web Services Interest Group

provide and review use cases, scenarios; participate in test case development and design review

P3P Community

The rules language should subsume APPEL.

XML Query WG

dependency for standard library of terms

RuleML initiative

The RuleML group has a been discussing languages in and near this space. This charter draws from some of that experience. We expect the partipation from RuleML participants.

DAML Joint Committee

This group has been discussing these issues and developing an OWL Rules Language proposal, which is expected to be valuable input to this working group.

RDF Query WG

If an RDF Query WG is formed to run in parallel, the groups will have to negotiate their considerable overlap, including:

• the similarity between rule antecedents and queries
• the similarity between proof-step binding information and query-response binding information

6. Membership, Meetings, and Logistics

W3C advisory committee representatives may appoint WG participants (@@link to CFP/WBS form). (@@limit 3 per org?). Chair may invite experts.

Public proceedings. W3C Royalty Free @@cite.

Weekly telcons. 3 to 5 f2f meetings per year for the 1 to 2 year duration.

7. Resource Allocation

co-chairs: Dan Connolly and [to-be-determined]. Team contact: Sandro Hawke and/or Massimo Marchiori . W3C Team resources: 3/4 FTE. Membership resources: a co-chair, 1/3 FTE. A few editors, 1/4 FTE, 10 to 30 participants, 1/5 FTE.