SUGGESTIONS by Benjamin Grosof 2003/11/12, (using also some of suggestions by Harold Boley's 2002/11/08 draft) ON DRAFT $Revision: 1.26 $ of $Date: 2003/11/07 22:30:26 $
The group is chartered to develop a practical and useful rules language for the Semantic Web. [[[benj: /* OMIT MAKING JUSTIFICATIONS/PROOFS A TOP-LEVEL GOAL OF THE WG. See Benjamin Grosof's and Ian Horrock's postings to www-rdf-rules@w3.org on 2003/11/11 for details of why. Briefly, justifications/proofs is a more research-y area that can and should be severed from the Rules Working Group effort, and pursued as a standard after the Rule language has been mainly designed. That said, the ability to support a future proofs/justifications language should be a requirement for the design of the Rule language. But it should not one of the two main goals/deliverables of the Rules Working Group. */ ]]] The [[[benj: Rule ]]] language will allow the expression of the knowledge that when certain things are [[[benj: believed, certain other things should also be believed. /* Knowledge representation is more accurately and appropriately described as about belief than truth. KR prescribes what ought to be believed as conclusions given belief in a set of premises. */ /* Omitted the stuff about justifications that was here. */ ]]]
This work is based [[[benj: largely ]]] on the Resource Description Framework (RDF) [[[benj: (including RDF Schema) ]]], 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.
[[The section is still rough]]
The architectural vision for the semantic web has included an interoperable standard language [[[benj: /* fixed typo */ ]]] for rules, for a long time. [[[benj: Currently commercially important rule systems and applications, and their users, suffer from the lack of interoperability. ]]] The readiness and urgency in this field are growing, and have crossed the threshhold for Working Group creation:
[[[benj: Achieving the major benefits of Semantic Web critically depends on the suite of standards becoming more complete by including Rules. /* Restated this to be less all-or-nothing. ]]] The community needs now to deliver the more powerful tools [[[benj: a Rule language enables ]]] for expressing facts and relationships on the Semantic Web. [[[benj: /* We should be consistent, presumably, throughout the document about capitalized vs. lower case for "Semantic Web". */ ]]] [[[benj: While ]]] OWL and RDF technologies [[[benj: will handle well certain applications, their uses ]]] also lead naturally to cases in which things need to be expressed which cannot be expressed [[[benj: directly ]]] in OWL [[[benj: (or RDF) ]]] alone.
[[[benj: /* Omitted the paragraph about justifications that was here. See instead the added paragraph about proofs in section 2.5, which essentially replaces the paragraph that was here. */ ]]]
[[[benj: /* The following paragraph should be given some better context, it seems out of place and maybe could be omitted or moved to a more background-y passage. If included, perhaps it would help to discuss at least briefly the relationship of CARIN and Triple to the Description Logic Programs approach. */ ]]] 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)
[[The section is still rough]]
[[[benjamin and harold: The Working Group will consider rule expressiveness levels as required by Semantic Web inference systems and use cases. However, only one or a few expressiveness levels will be dealt with by this group. for selecting such expressiveness, Design criteria will be drawn from the desire to integrate smoothly and powerfully with OWL, RDF, and currently commercially important rule systems.]]]
[[[benj:
/* Revised this section quite a bit. The previous version (1.26)
contained significant technical confusions/errors. Permitting existentials
in the rule head/consequent is beyond Horn. The distinction between Horn
and Datalog is simply that of disallowing logical functions. */
One traditional level of expressive power is a natural candidate as
a starting point: the Horn subset of first-order logic (hereafter "Horn FOL").
A key goal for the expressiveness of the Rule language is
that it should support, smoothly and powerfully,
layering Rules knowledge on top of OWL and/or RDF, i.e., combining Rules
knowledge with OWL ontologies and/or RDF knowledge.
One immediate implication is that the Rule language will use URIs as
symbols; as in RDF and OWL.
Sticking close to the expressiveness directly in the OWL and RDF models
implies some expressive restrictions relative to Horn FOL.
Notably, these include:
On the other hand, RDF and OWL contain some expressive features that
militate towards considering extending Rules expressiveness to go beyond Horn.
/* We can call this "RDF-inspired expressiveness" */
Notably, these include:
The Working Group will also need to consider to what extent the Rule language
should expressively permit integrity constraints, as well.
Note that Horn FOL does permit integrity constraints,
as does, roughly, the following degenerate form in RDF:
Another key goal for the expressiveness of the Rule language is that it
support, smoothly and powerfully, the ability to interoperate with a
substantial expressive fragment (i.e., subset) of currently commercially
important (hereafter "CCI") rule systems.
There are (at least) four important families
of such CCI rule systems: Prolog, SQL relational database,
production rules descended from the OPS5 system (i.e., forward-chaining
condition-action rules), and Event-Condition-Action rules.
One immediate implication is that the Rule language should support
procedural attachments in the rule body to perform queries/tests
including, as a first step, via invoking built-in procedures
from standardized libraries of such built-ins.
Built-ins are discussed more in section 2.4.
/* probably should add an intra-document link here for the cross-reference. */
The Working Group will also need to consider to what extent, and how
immediately, the Rule language should be expressively extended (or
limited) in other directions so as to support CCI rule systems. Many
if not most CCI rule systems and applications rely heavily on (nonmonotonic)
negation-as-failure and/or prioritized conflict handling.
Negation-as-failure (and prioritized conflict handling) is a feature that
goes beyond the expressive capabilities of first-order
logic ("FOL"), and thus in particular go beyond those of Horn FOL.
(FOL is logically nonmonotonic.)
Some in the Rules
community feel that nonmonotonicity should be left out of scope of the
Working Group V1.
Others in the Rules community feel that nonmonotonicity, especially
negation-as-failure, should be considered for inclusion in V1
rather than defined as out of scope in the charter.
Negation-as-failure is an area where the research understanding is
arguably more mature in several regards than is the area of
adding existentials to Horn rule heads.
Motivations for including nonmonotonicity include
long experience with it in CCI rule systems and requirements from Semantic
Web Services.
Many CCI rule systems and applications also
rely heavily on procedural attachments for (side-effectful) actions.
Procedural attachments
for actions, like nonmonotonicity,
goes beyond the expressive capabilities of FOL and thus of Horn FOL.
Another expressiveness-level issue is related to support of interoperability
with CCI rule systems, and especially to extensibility in the directions of
negation-as-failure/nonmonotonicity and actions. Declarative Logic Programs
(hereafter "LP")
and most CCI rule systems can be viewed semantically as essentially drawing
conclusions that are restricted to be ground atoms.
In particular in the Horn case: Horn LP is an expressive subset of Horn FOL
that can thus be viewed as a restricted/weakened expressiveness level.
Horn LP, rather than precisely Horn FOL,
provides the fundamental departure point
for expressive extensibility towards negation-as-failure and actions.
Overall for the Working Group, therefore, an important issue will be to decide
what expressive features and restrictions/levels
should be deferred to a later major revision
("V2") of the Rule language rather than included in the initial
version of the Rule language. Besides head existentials (discussed above),
another particularly important such expressive feature is negation-as-failure.
It will be wisest for the sake of the Working Group's effectiveness
and momentum to proceed in stages, specifying first a basic
set of features and functionality, e.g., binary-predicates Datalog Horn rules
with built-ins.
Accordingly, the Working Group's process will have the following principle.
Any expressive features must be clearly motivated in the requirements
document and agreed by consensus of the Working Group, subject to right of
review by related groups.
/* [[ Perhaps omit from the main text some or all of the above discussion
of the debatedness of head-existentials and of nonmonotonicity.
These issues, however,
certainly deserve discussion on the www-rdf-rules@w3.org list.
At a process level, it is not yet clear whether the scoping decision about
these should be made beforehand versus by the Working Group itself. ]] */
/* [[ Likewise, Might want to omit in this document, for sake of brevity,
some of the technical detail above, e.g., put it in
a separate "Technical Issues" document or something.
For this version at least,
I thought it was easier to put it in and be clear, since some of the topics
are contentious wrt scoping, then if necessary take some of it out. ]]
*/
]]]
The Working Group will need to consider to what extent the Rule language
(i.e., its expressiveness levels)
should be expressively extended specifically in the direction of
permitting anonymous-individual and existential-form knowledge of the kind
above.
Some in the Rules community feel that existentials in the head should
not be permitted; others feel that they should indeed be permitted.
Just {rdf graph} => {rdf graph} with variables.
The rdf graph in the head here will typically be a conjunction.
The rdf graph in the body here may well contain a blank node.
Horn rules generalized to permit conjunction in the rule head
and existentials in the rule body are well known to be expressively reducible
to Horn rules without such head conjunction or body existentials.
{rdf graph} => {an inconsistent rdf graph}
[[[benj: /* Not sure where to put the following -- if still included it belongs somewhere earlier in this section: ]]] The need for rules of the form [[[harold: "for all X and Y, if P(X,Y) then Q(X, Y)" @@stick to binary but discuss n-ary "extension path"]]] is clear. (@@cite positive Horn Clause definition, precedent in DAML J-C rules, RuleML, N3/cwm).
[[The section is still very rough]]
Due to the wide and conflicted range of expected [[[benj: use cases, the group is chartered /* fixed typos */ ]]] to work on multiple interchange syntaxes, including at least one XML-base syntax and one non-XML syntax. Specifically, there are [[[benj: four ]]] styles which the group is expected to consider before settling on two or more syntaxes for standardization:
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 [[[benj: rather /* softened from "extremely" */ ]]] verbose syntaxes, and there is little hope for improvement. Additionally, there are unanswered and perhaps troubling question about formal semantics of such systems. [[[benj: /* Question: Can someone briefly describe what are those formal semantics issues? */ ]]]
The group is expected to investigate this area thoroughly and produce a vocabulary for reifying rules [[[benj: /* Omitted the previous bit about justifications here */ ]]] if the benefits in terms of the identified use cases outweigh the difficulties with verbosity and formal semantics.
XML [[[benj: (non-RDF). ]]] [[[benj: This approach is to encode the syntax using non-RDF XML. There are several approaches within this camp. Two of these are: ]]]
Vocabulary Neutral (X-Triples). An XML syntax [[[harold: such as RuleML 0.8 ]]] where the terms are not mixed in with the XML tags [[[benj: /* Questions: Can someone please clarify what exactly is meant here by "terms" and "mixed in"? Also, what do "vocabulary neutral" and "X-triple" mean here? This item needs much better explanation. */ ]]] has certain advantages, including simplicity of validation.
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.
[[[benj: String (Non-XML). ]]] Expected to be more "human-readable", [[[benj: A human-oriented string syntax, to facilitate human reading and authoring/editing of rulebases, ]]] like [[[harold: the classical Prolog syntax, the merged Prolog/F-Logic PR-Syntax, or the compact N3 RDF-interface syntax]]].
Extension of RDF/XML. An XML syntax could be developed which [[[benj: directly ]]] extends RDF/XML by adding a rule construct and scoped, quantified variables, but otherwise maintains compatibility with RDF/XML. 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 syntax (which is in XML). [[[benj: /* Moved this to be broken out from the rest of non-RDF XML syntax, since it's quite different in spirit. ]]]
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 Joint Committee's Semantic Web Rules Language (SWRL) proposal, which does not maintain independence between Rules and OWL. ]]
[[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, [[[benj: SweetRules's sensor procedural attachments, ]]] etc.)
[[[benj: /* omit the last point about proofs referring to built-ins. */ ]]][[The section is still very rough]]
[[[benj:
/* Added the following paragraph so as to reflect that support of a
future language for exchange of proofs is a requirement for the Rule language
rather than one of the two main objectives and deliverables of the Rules
Working Group. */
In the overall vision of the Semantic Web, exchange of proofs will be an
important capability to support. Exchanged proofs may then be used
as a basis to increase trust. Identifying the premises, sources, reasoning
techniques, and reasoning steps that formed the basis for inferences makes
it easier and less risky to trust those inferences.
Checking, inspection or validation of such proofs may be
performed automatically in a distributed manner, e.g., by one application
that is a receiver of another application's reasoning results.
Accordingly, a requirement for the Rule language is
that it be designed with an eye to supporting smoothly a future-developed
language for exchange of proofs. These proofs may include reasoning
with rules knowledge alone or, more generally, reasoning with
combinations of rules plus ontologies (notably, OWL) and/or RDF knowledge.
Closely related to proofs are
justifications (which is sometimes used interchangeably as a concept)
and explanations. Proofs are needed for OWL as well as Rules.
Languages and techniques for exchangeable proofs is an area whose
evolution and maturation will be assisted by
the development of a standardized Rule language.
The Rule language work should ensure future extensibility of the
Semantic Web to support exchange of proofs that involve Rules.
]]]
[[[benj: /* Omitted/replaced the short paragraph that constituted this section 2.5 in version 1.26. Its main relevant point was covered in the added paragraph above. */ ]]]
The following deliverables seem to be necessary and sufficient to achieving the mission of this Working Group:
In addition to traditional W3C wide review and consensus (specifically Internationalization, Quality, and Accessibility) we note the following dependencies: