Presentation "Rules for the Semantic Web" by Benjamin Grosof http://www.mit.edu/~bgrosof for W3C Team Meeting, 3/29/01 copyright 2001 by Benjamin Grosof All Rights Researved. (this presentation available at http://www.mit.edu/~bgrosof/rules+sw-w3c-team-032901.txt) This is a post-edited version of 3/30/2001. This version to be posted on the Web, and OK for W3C team members to distribute amongst themselves by e-mail, as long as attribution to the author is maintained. (BG's memo to himself: directory .../ruleml/w3c-team.../ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Agenda: o RuleML and the Semantic Web Activity o Overview of Rules and RuleML mainly technically, plus brief update on current RuleML status - medium level detail - more detail on technical dimensions, issues, research agenda - examples NB: This includes some new (in places, half baked) research ideas. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% RuleML and the Semantic Web Activity The four commercially important families of rule systems today are: SQL, Prolog, production rules and Event-Condition-Action rules (ECA) incl. OO-embedded, and used for biz process connectors / workflow all have common core abstraction: declarative logic programs (LP) Rules relatively mature and familiar/deployed, actually even considerably more than Description Logic which is the basis for DAML+OIL - thriving tho' fragmented market for non-DB rule systems - very many users & developers familiar with SQL - many developers familiar with Prolog or ECA (see my FIPA 7/O0 talk slides: at http://www.mit.edu/~bgrosof/paps/fipa-grosof-07-00-distrib.pdf - on commercially important flavors of rule-based systems (slide 15), - advantages of LP (slides 24-25) ) Possibility: RuleML becomes a W3C Working Group, say "XML Rules", under the Semantic Web Activity - separate from, but coordinated with: 1) RDF 2) Ontologies cf. DAML+OIL For Discussion: ? Issues, Timing ? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Overview of RuleML (see lots of stuff at http://www.mit.edu/~bgrosof/ruleml-w3cf2f.html, including presentation from RuleML Birds Of a Feather session at the W3C Technical Plenary meeting, 2/26-28/01 ) Technically: starting point: logic programs: o Horn o +/- extensions/restrictions forms a family (lattice) of expressive classes: each with a DTD (syntax) and associated knowledge representation semantics (KRsem). why have several instead of 1 most general: precision facilitates and maximizes effective interoperability, given heterogeneity KRsem specifies what set of conclusions are sanctioned for any given set of premises. XML syntax is straightforward. Crucial is the semantics (KRsem) and the choice of expressive features. extensions: o URI's o NAF (Negation-As-Failure): with Well-Founded Semantics o Courteous LP: prioritized defaults; builds on top of NAF o Situated (Courteous) LP: disciplined procedural attachments for queries and actions o conditional equations/equivalences/rewriting cf. Equalog restrictions: o Datalog o binary-predicates only o facts only o URI-centered cf. RDF syntax extensibility-to/compatibility-with: o KIF o N3? current work on RuleML DTDs V0.8 and V0.9: o eliminate order-dependence in predicate tuples => o ...map to RDF as an option (also support non-RDF XML encoding) - already: there's a translator to RDF available as tool o ontology to describe the KR expressive class utilized - attributes such as: Datalog, binary-predicates-only, ... o anticipate future use of XML Schema not just DTD's - soon: it's simple to generate XML Schema version of the RuleML specification, from DTDs current work beyond DTD's: o discussions with companies wrt participating/implementing - possible early implementations o discussion with JSR Java Rules Engines specification effort upcoming invited conference talks and tutorials: - JavaOne (June, Bay Area) - IJCAI (August, Seattle) other recent talks/discussions: - DAML PI Meeting: Rules BOF (2/14/01) - W3C Technical Plenary: Rules BOF (2/26-28/01) - ABA E-Agents (3/24/01) American Bar Association, Business Law Committee Technical Dimensions involved, in more detail: *** = new research issues I am personally exploring o shortcomings of classical logic / KIF: lacks non-monotonicity, lacks procedural attachments o NAF and prioritized defaults; courteous logic programs o procedural attachments for queries and for side-effectful actions: - Situated LP; currently generalizing to: - ***"Socially" Situated LP o ***semantics of failure in remote queries - not inferred, wrt what entailment-concept / inference-procedure vs. - ***service unavailable: communication failure, service refused, etc. o resultant overall semantics of failure: - not inferred, and had a real full go at it vs. - stymied due to dependency upon a service unavailable ***Near-term issues: o defining the detailed syntax and semantics of sensing and importing, using: - protocols for XML services - XML Query o define the semantics and syntax of (dependent-upon-)service-unavailable - today typically treated extra-logically; maybe keep it that way - an alternative: define an extra truth value, similar to Undefined, say "NA" (for "Not Available") or "Incapable" - another alternative: treat meta-logically; this might get messy ***Larger Research Agenda: o distributed belief transfer: incl. sources, non-monotonicity o rules combined with XML services: situated LP, rule-based services, service queries from rulebases, rules in business process protocols o rules using ontologies (and ontology translation), rules for ontologies, hybridize rules with Description Logic, rules for ontology translation %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Example: a fairly generic one: creditworthiness analysis by an agent We'll walk thru in detail the agent is named "self", and is one agent among many self has to make decisions about two requests for credit self gets credit info from two sources, and puts it together for each request NOTE: The syntax below is impressionistic and abbreviated, relative to a realistic XMLified version, to enable human readability and because some aspects of syntax (importing, procedural attachments) are not yet fully worked out. In particular, view the predicate and logical-function constants below as standing for URI's. The (Situated Courteous) Logic Program syntax is taken from the CLPfile format from IBM CommonRules. ***Note: the treatment of importing and procedural attachments, which goes beyond previous work on situated logic programs, reflects new current (still half-baked) tresearch by me personally -- especially on how procedures are invoked in an "XML-y" way. Version 1: in Ordinary LP with NAF; no priorities or remote queries Premises: says(self,shouldGrantCredit,?Requester) <- says(creditReportsRUs,creditRating,?Requester,good) and FNEG says(self,shouldDenyCredit,?Requester). /* FNEG means Negation-As-Failure, i.e., "Failure NEGation" */ says(self,shouldDenyCredit,?Requester) <- says(recommenderServiceD,fraudExpert,?BlackBallService) and says(?BlackballService,creditRating,?Requester,bad). says(recommenderServiceD,fraudExpert,studentLoanAgency). says(creditReportsRUs,creditRating,Sue,good). says(creditReportsRUs,creditRating,Joe,good). says(studentLoanAgency,creditRating,Joe,bad). Conclusions drawn: says(self,shouldGrantCredit,Sue). says(self,shouldDenyCredit,Joe). /* BUT NO conclusion that: shouldGrantCredit(self,Joe). */ Version 2: in Courteous LP Premises: says(self,shouldGrantCredit,?Requester) <- says(creditReportsRUs,creditRating,?Requester,good). says(self,shouldDenyCredit,?Requester) <- says(recommenderServiceD,fraudExpert,?BlackBallService) and says(?BlackballService,creditRating,?Requester,bad). mutex_head <- says(self,shouldGrantCredit,?Requester) and says(self,shouldDenyCredit,?Requester). overrides(posCredEvid,negCredEvid). says(recommenderServiceD,fraudExpert,studentLoanAgency). says(creditReportsRUs,creditRating,Sue,good). says(creditReportsRUs,creditRating,Joe,good). says(studentLoanAgency,creditRating,Joe,bad). Conclusions drawn: same as in Version 1. Version 3: ***with importing premises from remote sources Premises: says(self,shouldGrantCredit,?Requester) <- says(creditReportsRUs,creditRating,?Requester,good). says(self,shouldDenyCredit,?Requester) <- says(recommenderServiceD,fraudExpert,?BlackBallService) and says(?BlackballService,creditRating,?Requester,bad). mutex_head <- says(self,shouldGrantCredit,?Requester) and says(self,shouldDenyCredit,?Requester). overrides(negCredEvid,posCredEvid). ::IMPORT:: recommenderServiceD/fraudAgencies.xml /* results in obtaining: says(recommenderServiceD,fraudExpert,studentLoanAgency). */ ::IMPORT:: creditReportsRUs/creditRatings.xml . /* results in obtaining: says(creditReportsRUs,creditRating,Sue,good). says(creditReportsRUs,creditRating,Joe,good). */ ::IMPORT:: studentLoanAgency/creditAlerts.xml . /* results in obtaining: says(studentLoanAgency,creditRating,Joe,bad). */ Conclusions drawn: same as in Version 1. Version 4: ***with procedural attachment to dynamically query remote sources Premises: says(self,shouldGrantCredit,?Requester) <- says(creditReportsRUs,creditRating,?Requester,good). says(self,shouldDenyCredit,?Requester) <- says(recommenderServiceD,fraudExpert,?BlackBallService) and says(?BlackballService,creditRating,?Requester,bad). mutex_head <- says(self,shouldGrantCredit,?Requester) and says(self,shouldDenyCredit,?Requester). overrides(posCredEvid,negCredEvid). ::IMPORT:: recommenderServiceD/fraudAgencies.xml /* results in obtaining: says(recommenderServiceD,fraudExpert,studentLoanAgency). */ says(creditReportsRUs,creditRating,?X,?Y) ::sensor-procedural-attachment:: creditReportsRUs/ queryRules?q=creditRating(?X,?Y) . /* results in obtaining: says(creditReportsRUs,creditRating,Sue,good). says(creditReportsRUs,creditRating,Joe,good). */ /* ff. uses a more ambitious/sophisticated "universal" querier: */ says(?Source,?Predicate,?X,?Y) ::sensor-procedural-attachment:: #/queryRules?q=says(?Source,?Predicate,?X,?Y) /* results in obtaining: says(studentLoanAgency,creditRating,Joe,bad). */ Conclusions drawn: same as in Version 1. Version 5: ***with procedural attachment to perform side-effectful actions triggered by drawn conclusions Premises: says(self,shouldGrantCredit,?Requester) <- says(creditReportsRUs,creditRating,?Requester,good). says(self,shouldDenyCredit,?Requester) <- says(recommenderServiceD,fraudExpert,?BlackBallService) and says(?BlackballService,creditRating,?Requester,bad). mutex_head <- says(self,shouldGrantCredit,?Requester) and says(self,shouldDenyCredit,?Requester). overrides(posCredEvid,negCredEvid). ::IMPORT:: recommenderServiceD/fraudAgencies.xml . /* results in obtaining: says(recommenderServiceD,fraudExpert,studentLoanAgency). */ says(creditReportsRUs,creditRating,?X,?Y) ::sensor-procedural-attachment:: creditReportsRUs/ queryRules?q=creditRating(?X,?Y) . /* results in obtaining: says(creditReportsRUs,creditRating,Sue,good). says(creditReportsRUs,creditRating,Joe,good). */ /* ff. uses a more ambitious/sophisticated "universal" querier: */ says(?Source,?Predicate,?X,?Y) ::sensor-procedural-attachment:: #/queryRules?q=says(?Source,?Predicate,?X,?Y) /* results in obtaining: says(studentLoanAgency,creditRating,Joe,bad). */ says(self,shouldGrantCredit,?X) ::effector-procedural-attachment:: #/performAction?notify(self.CreditDept,?X). says(self,shouldDenyCredit,?X) ::effector-procedural-attachment:: #/performAction?notify(self.CreditDept,deny,?X). Conclusions drawn: same as in Version 1. Actions Taken: notify(self.CreditDept,grant,Sue) notify(self.CreditDept,deny,Joe)