1 / 60

Rational Agents in Logic Programming for the Semantic Web

Rational Agents in Logic Programming for the Semantic Web. Lu í s Moniz Pereira et al. AI Centre, Universidade Nova de Lisboa. Linköping, September 29th, 2005. Outline. Overview of the Semantic Web The REWERSE project Overview of select LP features Dynamic Logic Programming

crete
Download Presentation

Rational Agents in Logic Programming for the Semantic Web

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rational Agentsin Logic Programming • for the Semantic Web Luís Moniz Pereira et al. AI Centre, Universidade Nova de Lisboa Linköping, September 29th, 2005

  2. Outline • Overview of the Semantic Web • The REWERSE project • Overview of select LP features • Dynamic Logic Programming • Evolving Logic Programs • Reasoning Integration Framework • Semantic Web Application • Left out LP features • Project W4: Well-founded semantics for the World Wide Web

  3. The Semantic Web • "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation."-- Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2001 • The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. It is a collaborative effort led by W3C, with participation from a large number of researchers and industrial partners.

  4. The Semantic Web Continues the idea of today’s portals: • Information must be independent from its actual location (“talk aboutsomething”). • Combination of information by “the Web”, not by the user  combination instead of mappings. • Information sources must support this  cooperation. • Semantics-based, instead of syntax/data-structure based querying.

  5. Knowledge in the Semantic Web - 1 • The Semantic Web brings new problems to the knowledge representation community, due to its distributed and world-wide character. • At the start of the Semantic Web Initiative it was clearly noted that the globalization of Knowledge Representation introduces new challenges. • The Semantic Web is what we get if we perform the same globalization process to Knowledge Representation that the Web initially did to Hypertext. • One removes the centralized concepts of absolute truth, total knowledge, and total provability, and see what one can do with limited, and limitedly available, knowledge.

  6. Knowledge in the Semantic Web - 2 • The following fundamental theoretical problems have been identified (among others): • Negation, Contradiction, and Inconsistencies • Open World versus Closed World assumptions • Rule Systems in the Semantic Web • The first two issues have been circumvented till now in RDF, by discarding the facilities to introduce them, namely classical negation and closed world assumptions. • The widely recognized need of having rules in the Semantic Web restarted the discussion of the fundamentals of closed world reasoning in the Semantic Web. And the appropriate mechanisms in Rule Systems to implement it, in particular “negation as failure.”

  7. Knowledge in the Semantic Web - 3 • The RDF(S) recommendation has been a major breakthrough, and provides solid ground to discuss the issues. • We defend that partial valued logics are a step forward, and a necessary one, for a powerful and expressive Semantic Web. • We claim that semantics like those proposed in the logic programming and deductive databases communities can be immediately used for specifying Rule Systems in the Semantic Web, in particular the semantics proposed here.

  8. Knowledge in the Semantic Web - 4 • Negation, Contradictions, and Inconsistencies • The ability to express negative knowledge, beside positive one, is an obvious requirement for a knowledge representation language. This is particularly sensible in the Semantic Web, because for instance one has to be capable of expressing that a user/machine is “NOT authorized” to access some information. • One initial justification for still having this limitation appears in the Semantic Web Roadmap: As far as mathematics goes, the language at this point has no negation or implication, and is therefore very limited. Given a set of facts, it is easy to say whether a proof exists or not for any given question, because neither the facts nor the questions can have enough power to make the problem intractable.

  9. Knowledge in the Semantic Web - 5 • The tractability argument can no longer be used because, as stated in the RDF Semantics W3C recommendation, the general problem of determining simple entailment between arbitrary RDF graphs is decidable but NP-complete. • So the question is now whether there are any knowledge representation frameworks with the same, or similar complexity classes, supporting rules and (two kinds of) negation. • By restricting the language of our theories to Datalog (no function symbols), the data complexity of the language is co-NP-complete (i.e. testing if a query holds in all stable models), and NP-complete for testing the existence of a stable model. • Other semantics have even lower data complexity classes, like Well-founded Semantics and its extensions supporting two forms of negation which are P-complete.

  10. Knowledge in the Semantic Web - 6 • A major reason for these good complexity results is that the arrow symbol (←) in our rules is interpreted as a sequent, not implication, and therefore they can only be used in one direction. The classical Modus Tollens cannot be applied, avoiding the indirect inference of disjunctive conclusions. • Furthermore, disjunctive heads are also not allowed, thus there is no way of obtaining arbitrary disjunctive conclusions. This language limitation keeps data complexity from increasing to higher complexity classes. • The existence of negation also paves the way to the problem of introducing contradictions in the Semantic Web, and is probably the main motivation for not having negation now in RDF. This is an important concern, since the existence of a single contradiction in a rule base, asserted or deduced, explodes the consequences and therefore trivializes the rulebase. Proper paraconsistency is a must!

  11. Knowledge in the Semantic Web - 7 • Our understanding is that each user/agent/application should be concerned solely with the knowledge that it decided/trusted/agreed to assert or load in its local subset of the Semantic Web. • There is huge theoretical work in paraconsistent logics from which the Semantic Web might benefit, and there exist several proposals for logic programming knowledge representation systems, with two kinds of negation, that tolerate inconsistency. • The paraconsistent partial logic based semantics proposed here tolerates contradictions in the knowledge base, and does not always render the rule base useless.

  12. Why RDF, Ontologies, and OWL? • Heterogeneity of data models and notions used by different data sources  data integration • RDF provides a unified simple model with seamless integration of ontologies: • sometimes: mapping between ontologies • ontology level [synonyms, hyponyms etc], not XML level views/mappings as before, in data integration.

  13. Behaviour in a “Passive” Semantic Web • So far there are no actual processes but some behaviour is already required, e.g. Cooperative Query Answering in the Semantic Web • Query answering (e.g., RDQL): • actual integration of RDF/OWL information is simple • task: queryingthis information • distributed (P2P) process •  communication and collection of queries and answers • Note too: policies, trust, dealing with incomplete knowledge etc., needs reasoning that is often described and implemented in a procedural way.

  14. Cooperative Evolution of the Semantic Web: update propagation • Overlapping ontologies and information between different sources: • Consistency between data sources (although querying deals with a static notion of state, it requires that this state be consistent) •  local updates of data sources must be propagated • While state change in a database is an update, state change in the (Semantic) Web requires “background” activity. • Directed communication between dependent data sources (push, pull, ...) - in tightly coupled peers, viz. bioinformatics, sources are known • Communication to unknown data sources? Updates as “events” (e.g. “our address changes to ...”) reactivity

  15. Semantic Updates • Contained information is independent from its location. • Updates: in the same way as there are semantic query languages, there must be a semantic update language. • updating RDF data: just tell (a portal) that a property of a resource changes: intensional, global updates •  must be correctly realized in the Web! • “The Web” must do something – it’s “the Web”, not a single page/site! • Communication and view maintenance, rough ideas: • tell each source explicitly what changes (“push”) • “send” update to a portal, the sources have to care for relevant updates • Both cases: reactivity see such updates as eventson which sources must react upon.

  16. Cooperative Evolution of the Semantic Web: processes • There are not only queriesand updates, but there are activitiesgoing on in the Semantic Web: • The Semantic Web as a base for processes • Business rules, designed and implemented in participating nodes: banking, travel booking, etc. • Burocracy. • Ad-hoc rules designed by users. • The less standardized the processes (e.g. human travel organization), the higher the requirements on the Web’s assistance and flexibility. • local behaviour of nodesand cooperative behaviour in “the Web”

  17. Semantic Web: abstraction levels • Abstraction Levels •  evolution of single pages (updates + reasoning) •  evolution of the Web (updates + processes) • local vs. remote/distributed • physical data model (XML) vs. logical data model (RDF in a node) • combination: Web-wide: global, RDF/OWL • Infrastructure and Principles •  communication •  reactivity: communication ; evolution

  18. Evolution and Behaviour Behaviour is ... doing something • When it is required • upon interaction (user, or service call) • abstractly: as a reaction to a message • as a reaction to an internal event (temporal, update) • Continuously (process) • which in fact most of the time does nothing, but also reacts on events • Event-Condition-Action Rules are a well-known paradigm (not just in Active Database Systems).

  19. Local Evolution of Web Nodes • Web nodes with local behaviour • React on: • local updates • incoming messages • temporal events • possibly poll/query other sources  Trigger-like: update/message + condition ⇝ update (possibly including a remote query)

  20. Event-Condition-Action (ECA) Rules • Intended basic paradigm: Reactivity • communication/messages • specification and implementation of (at first: local) behaviour •  Homogeneous, modular framework • ECA Rules: • “On Eventcheck Conditionand then do Action” • Active Databases • modular, declarative specification • sublanguages for specifying Events, Conditions, Actions • simple kind (database level): triggers

  21. REWERSE – Reasoning on the WebThe project • European Network of Excellence • EU 6th Framework Programme • Project no. 506779 • IST Objective “Semantic-based knowledge systems” • Funded by EC and Switzerland (ca. 5 Mio €) • Start: March 1, 2004 (scheduled for 4 years) • Networking … • Over 100 researchers from 27 participating institutions in 13 European countries • … excellence in research • logic programming, reasoning with rules & constraints • constraint and rule-based languages • Web systems

  22. Reasoning on the (Semantic) WebSemantic Web Protocol Stack “For the semantic web to function, computers must have access to [...] sets of inference rules that they can use to conduct automated reasoning.” Tim Berners-Lee, James Hendler, and Ora Lassila. Scientific American, May 2001.

  23. REWERSE ObjectivesReasoning languages for advanced Web systems • Web reasoning languages & processing • Define set of reasoning languages • Coherent • Inter-operable • Functionality and application independent • For Advanced Web systems and applications • Advanced Applications as testbeds for languages • Context-adaptive Web systems • Web-based decision support systems • Dissemination and Standardization • Dissemination to industry and academe • Develop open pre-standards of languages

  24. Rational Agent LP Features • DLP - Dynamic Logic Programming • PDLP – DLP with preferences • MDLP - Multi-Dimensional DLP • LUPS - Language for Dynamic Updates • EVOLP – Evolving Logic Programs • Prolog based standard XML tools • W4 project: WFS for the WWW

  25. Rational Agent LP Features, left out… • Available features left out in here… • Multi-agent updating • Paraconsistency • Belief revision • Learning (Logic+Genetic algorithms) • Abduction • Abduction+Updates • Preferences+Abduction (+Updates) • Constructive negation + Abduction • …but see much documentation on these: Available at: http://centria.fct.unl.pt/~lmp/ • Implementations of rational agent features: Above site and: http://centria.fct.unl.pt/~jja/updates/

  26. DLP • DLP is a semantics for successive updates of LPs by other LPs, with generalised rules (not’s in heads and bodies). • Guarantees the most recent rules are in force, and that previous rules are valid by inertia insofar as possible: i.e. they are kept as long they do not conflict with more recent rules, and become revived if the latter are in turn superseded. • DLP default negation is treated as in the Stable Models semantics of generalized programs. Presently DLP is also defined for the WFS.

  27. EVOLP • A Logic Programming language generalizing DLP and LUPS: • For specifying evolution of knowledge bases. • Allowing dynamic updates of specifications. • Capable of dealing with external events. • Deals with sequences of sets of EVOLP rules. • EVOLP rules are generalized LP rules (not’s in heads and in bodies) plus predicate assert/1, that may appear both in heads or bodies. • The argument of assert/1 is any EVOLP rule(and so assert’s can be embedded). • Sequences may fork due to alternative assertions in alternative models.

  28. EVOLP semantics • The meaning of a sequence is given by the sequences of models. • Each sequence determines a possible evolution of the KB. • Each model determines what is true after a number of evolution steps in the sequence (i.e. at a state). • A first model in a sequence is built by “computing” the semantics of the first EVOLP program, where assert/1 is treated as any other predicate. • If assert(Rule) is true at some state, then the KB is updated with Rule in the next state. • This updating of the KB, and the “computation” of the next model in the sequence, is performed as in DLP.

  29. Email agent core example • Personal assistant agent for email management able to: • Perform basic actions of sending, receiving, deleting messages. • Storing and moving messages between folders. • Filtering spam messages. • Sending automatic replies and forwarding. • Notifying the user of special situations. • All dependent on user specified criteria, where • the specification may change dynamically.

  30. email EVOLP rules • By default, messages are stored in the inbox: assert(msg(M,F,S,B,T)) ← newmsg(M,F,S,B), time(T), not delete(M). assert(in(M,inbox)) ← newmsg(M,F,S,B), not delete(M). assert(not in(M,F)) ← delete(M), in(M,F). • Spam messages are to be deleted: delete(M) ← newmsg(M,F,S,B), spam(F,S,B). • The definition of spam can be done by LP rules: spam(F,S,B) ← contains(S,credit). • This definition can later be updated: not spam(F,S,B) ← contains(F,my_accountant).

  31. More email EVOLP rules • Messages can be automatically moved to other folders. When that happens the user wants to be notified: notify(M) ← newmsg(M,F,S,B), assert(in(M,F)), assert(not in(M,inbox)). • When a message is marked both for deletion and for automatic move to another folder, the deletion should prevail: not assert(in(M,F)) ← move(M,F), delete(M). • The user is organizing a conference, assigning papers to referees. After receipt of a referee’s acceptance, a new rule is to be added, which forwards to that referee any messages about assigned papers: assert( send(R,S,B1) ← newmsg(M1,F,S,B1), contains(S,PId), assign(PId,Ref) ) ← newmsg(M2,Ref,PId,B2), contains(B2,accept).

  32. Our XML Tools • A non-validating XML parser, supporting XML Namespaces, XML Base, and complying with the recommendations of XML Info Sets. It can read US-ASCII, UTF-8, UTF-16, and ISO-8859-1 encodings. • A converter of XML to Prolog terms. • A RuleML compiler for the Hornlog fragment of the language, extended with default and explicit negation. • Query evaluation procedures for our paraconsistent Well-Founded Semantics with eXplicit negation (WFSXp).

  33. Semantic Web Applicability • Logic Programming and the Semantic Web: • RuleMLgroup. • Implementation of Prolog based standard XML tools Namelya fully functional RuleML compiler for the Horn fragmentwith two types of negation, default and explicit. • Evolution and updating of knowledge bases The existing implementations are being integrated with RuleML. • Semantics of logic programming Supporting uncertain, incomplete, and paraconsistent reasoning, based on Well-founded Semantics and Answer Sets. • Development of advanced Prolog compilers(GNU-Prolog and XSB). • Development of distributed tabled query procedures for RuleML. • Constraint Logic Programming. • Prolog/Java interface:www.declarativa.com • Applications.

  34. W4 project:Well-founded semantics for the WWW • Mission Statement • The W4 project aims at developing Standard Prolog inter-operable tools for supporting distributed, secure, and integrated reasoning activities in the Semantic Web.

  35. W4 project:Goals • Development of Prolog technology for XML, RDF, and RuleML. • Development of a General Semantic framework for RuleML including default and explicit negation, supporting uncertain, incomplete, and paraconsistent reasoning. • Development of distributed query evaluation procedures for RuleML, based on tabulation, according to that semantics. • Development of Dynamic Semantics for the evolution/update of Rule ML knowledge bases. • Integration of different semantics in Rule ML (namely, Well-founded Semantics, Answer Sets, Fuzzy Logic Programming, Annotated Logic Programming, and Probabilistic Logic Programming).

  36. W4 project:Expectations • The results of the W4 project are expected to contribute to the ongoing REWERSE European Network of Excellence. • The implementation efforts build on the previously described theoretical work and implementations, and the RuleML language proposal. • A full RuleML compiler is available for an extension of the Hornlog frament of RuleML. It supports default and explicit negation, both in the heads and in the bodies of rules, as well as the assert statements of EVOLP programs. • The implemented semantics is: Paraconsistent Well-founded Semantics with Explicit Negation (WFSXp).

  37. W4 project:Well-founded semantics for the WWW • Why Well-founded Semantics ? • THE adopted semantics for definite, acyclic and (locally) stratified logic programs. • Defined for every normal logic program, i.e. with default negation in the bodies. • Polynomial data complexity. • Efficient existing implementations, namely the SLG-WAM engine implemented in XSB. • Good structural properties. • It contains the undefined truth-value. • Many of the extensions are built over the WFS, and capture paraconsistent, incomplete, and uncertain reasoning. • Update semantics via Dynamic Logic Programs. • It can be readily "combined" with DBMSs, Java, Prolog, and Stable Models engines.

  38. W4 project: Major Guidelines • Tractability of the underlying reasoning machinery. • Build upon well-understood existing technology and theory, and widely accepted core semantics. • General enough to accommodate and integrate several major reasoning forms. • Should extend definite logic programming (Horn clauses). Desirable integration with (logic-)functional languages. • Most of the reasoning should be local (not very deep dependencies among goals at different locations). • Fully distributed architecture, resorting to accepted standards, recommendations and protocols.

  39. Why ? - 1 • Theoretical Issues: current proposals are limited to classical definite logic programming, meaning that: • Atoms are either true or false: no form of naturally representing uncertainy (fuzzy, probabilistic, etc.). • No default (non-monotonic) negation for representation of incomplete information. • No negation(s) for stating explicit negative information. • No handling of contradiction/paraconsistency. • No way of extending the language with new connectives. • Most of the above is raised in the Semantic Web Activity Statement, and there are solutions to them in the LP lore.

  40. Why ? - 2 • Practical Issues: current proposals seem not to address some important problems, namely: • What happens if a computation fails on the Web ? • What happens if a loop is introduced in the course of distributed inference (positive or negative) ? • Can the computation safely proceed while answers do not arrive ? • How to share and avoid redundant computations ? • How to update knowlege (in the Web) ? • How to handle event-condition-action rules ? • Logic programming based semantics and their implementation technology contains answers to these questions.

  41. Problems • The current RDF proposal has very limited expressivity: • Only binary facts • No complex terms • No negation • No disjunction • In WG-I1 we are currently extending RDF semantics to support two forms of negation in order to deal with: • Partial knowledge • Negative knowledge • We are also defining a rule language and corresponding semantics for RDF.

  42. Hard facts about the Semantic Web - 1 • The Semantic Web does not exist: if all the knowledge available in the Semantic Web is merged together then an inconsistency is obtained. • There are no omniscient Semantic Web agents: An agent can have only a limited view of the Semantic Web. • A knowledge producer should be able to use the forms of reasoning it likes. • A knowledge consumer should be able to reject the forms of reasoning it does not accept.

  43. Hard facts about the Semantic Web - 2 • The Semantic Web is always evolving. Uncontrolled non-monotonic reasoning is considered dangerous in the Semantic Web. • There is no uniquely adopted Semantics for Knowledge Bases, and this is desirable! • Knowledge Bases in the Semantic Web will certainly introduce mutual dependencies between them, both positive and negative. • Communication and agents will: fail/abort/crash...

  44. Principles • Use existing theory, namely KR representation formalisms and LP languages • Propose mechanisms which can work in the major LP semantics • The knowledge producers should respect some guidelines in the development of Semantic Web Knowledge Bases • The knowledge consumers are responsible for loading/connecting to the knowledge bases and understand the assumptions used by the producers

  45. What is needed • Dealing with Negations, Contradictions, and Inconsistencies • Allow for Open World and Closed World Assumptions • Modules for Knowledge Bases in the Semantic Web A logic programming language with two kinds of negation !!!

  46. Basic Mechanisms • Expressing totalness • P V -P • Expressing non-contradiction • ← P, -P • Expressing closed-world assumptions • - P ← not P or • P ← not -P

  47. The producer • The producer expresses visibility of predicates and open/closed world assumptions in the knowledge bases: • Global predicates: can be used and redefined anywhere. • Visible predicates: can be used anywhere, but not be redefined. • Open predicates: can only be used inside the knowledge base. • Closed predicates: can only be used inside the knowledge base, and instances are closed by default. • Internal predicates: can only be used inside the knowledge base and the programmer may use all availabe connectives in the language, monotonic or not. • Only strong negation can be applied to global, visible, open, and closed predicates.

  48. The consumer • The consumer has several modes for importing knowledge base • accept-all:any form of reasoning is allowed, monotonic or not. • allow-closed: locally closed predicates might be used, but no predicate can be declared internal. • force-open:closure rules are inhibited and cannot be used in the inference engine by its deductive mechanisms. Internal predicates are forbidden. • reject-closed:rejects both closed and internal predicates in knowledge bases.

  49. What about Paraconsistency ? • With the introduction of a form of explicit negation, contradictions may arise in knowledge bases. • We have defined a paraconsistent well-founded semantics with explicit negation (WFSXp), with very desirable properties: • contradiction is "propagated" by the coherence principle, corresponding to a localized Reductium ad Absurdum. • we can detect dependency on contradiction, so we can reason safely in the presence of contradiction. • contradiction can be blocked by resorting to normalized default rules. • there is a program transformation into WFS. • there are polynomial inference procedures.

  50. Extended Antitonic Programs • We have a proposal for a semantics allowing the integration of explicit negation with default negation in a many-valued setting. • We adhere again to the coherence principle. • Our main algebraic structures are bilattices, as defined by Ginsberg and Fitting. • Our results are very encouraging, and have been published.

More Related