Learning Center
Plans & pricing Sign in
Sign Out
Get this document free

Inference Web


									       Inference Web:
Portable and Sharable Proofs
     for Hybrid Systems

   Deborah L. McGuinness, Paulo Pinheiro da Silva
                and Bill MacCartney
   with Richard Fikes, Gleb Frank, Jessica Jenkins, Rob
                     McCool, Yulin Li

             Knowledge Systems Laboratory

                   Stanford University


               {dlm | pp}
                  Motivation - TRUST

If users (humans and agents) are to use and integrate system
   answers, they must trust them.
System transparency supports understanding and trust.
Thus, systems should be able to explain their actions, sources,
 and beliefs.

Also, if systems are hybrid, it is useful to work in an integrated
 yet separable manner.

               McGuinness, Pinheiro da Silva, and MacCartney, 2003   2
          Technical Infrastructure Reqs

 Provenance information - explain where source information: source
  name, date and author of last update, author(s) of original information,
  trustworthiness rating, etc.
 Reasoning information - explain where derived information came from:
  the reasoner used, reasoning method, inference rules, assumptions, etc.
 Explanation generation – provide abbreviated descriptions of the proof
  – may include reliance on a description of the representation language
  (e.g., DAML+OIL, OWL, RDF, …), axioms capturing the semantics,
  rewriting rules based on axioms, other abstraction techniques, etc.
 Distributed web-based deployment of proofs - build proofs that are
  portable, sharable, and combinable that may be published on multiple
  clients, registry is web available and potentially distributed, …
 Proof/explanation presentation - Presentation should have
  manageable (small) portions that are meaningful alone (without the
  context of an entire proof), users should be supported in asking for
  explanations and follow-up questions, users should get automatic and
  customized proof pruning, web browsing option, multiple formats,
  customizable, etc.
                McGuinness, Pinheiro da Silva, and MacCartney, 2003      3
                         Inference Web

Framework for explaining reasoning tasks by storing, exchanging,
   combining, annotating, filtering, segmenting, comparing, and
   rendering proofs and proof fragments provided by reasoners.
    DAML+OIL/OWL specification of proofs is an interlingua for proof
    Proof browser for displaying IW proofs and their explanations
     (possibly from multiple inference engines)
    Registration for inference engines/rules/languages

    Proof explainer for abstracting proofs into more understandable
    Proof generation service for facilitate the creation of IW proofs by
     inference engines
    Prototype implementation with Stanford’s JTP reasoner and SRI’s
     SNARK reasoner
    Discussions with Boeing, Cycorp, Fetch, ISI, Northwestern, SRI, UT,
     UW, W3C, …
                McGuinness, Pinheiro da Silva, and MacCartney, 2003         4
              Inference Web Architecture

               World Wide Web
                                    Registrars                        Agent
  non-IW documents                                                    dependency
                                        entries                         Web

                                                      IW Browsers       agent

                         proof fragments

               McGuinness, Pinheiro da Silva, and MacCartney, 2003           5
               IW Registry and Registrar
 IW Registry has meta-data useful for disclosing data provenance and
  reasoning information such as descriptions of
    inference engines along with their supported inference rules

    Information sources such as organizations, publications and ontologies

    Languages along with their axioms

 The Registry is managed by the IW Registrar

                   McGuinness, Pinheiro da Silva, and MacCartney, 2003        6
        Inference Engine Registration                                      (1)
       Engine registration involves the creation of an engine entry
        and its association with entries of inference rules

       Rule entries can be either reused or added to the registry

 An entry for SRI’s SNARK engine                         An entry for SNARK’s Binary
                                                                 Resolution inference rule

                 McGuinness, Pinheiro da Silva, and MacCartney, 2003                  7
           Inference Engine Registration                                 (2)

 Otter’s binary resolution, hyper-resolution and paramodulation rules
  were reused for the registration of SNARK

 Assumption and negated conclusion rules were added for SNARK

                                                                       Rule reuse

                 McGuinness, Pinheiro da Silva, and MacCartney, 2003                8
            Inference Engine Registration                                 (3)

Summarizing the Inference Engine Registration process:

 Use the registry to include meta-information about the engine and its rules

    Add an entry for the new inference engine

    Identify the core inference rules supported by the engine

    Add unregistered core inference rules, if any

    Associated the core rules with the core inference engine

 Prepare the engine to dump proofs in the IW format

    Implement a routine for calling the proof generator service

       Example routines in Java and Lisp can be provided

    Publish successful results of the proof generator services in portable proof
     format (OWL/DAML/RDF/XML compliant files)

 Browse your proofs in the IW Browser

                    McGuinness, Pinheiro da Silva, and MacCartney, 2003             9
                  Generation of IW proofs

     Send node information:                   Registry
     reasoner ID, labeling                                    WWW
     sentence in KIF, rule
     ID, antecedent URIs,                                Registrar
     bindings, and
     sourceID                                                           (can collect
                                               (2) Verify information
                                                                        statistics, provide
           (3) Return proof      Proof generator service
Reasoner                                                   Proof
              (4) publish proof                          fragments

                 McGuinness, Pinheiro da Silva, and MacCartney, 2003                    10
                Integration with SNARK

 Done by non-SNARK author to test strategies for integration

 Tests alternative reasoning strategy – proof by contradiction

 No special modifications made as a test of leverage

 Learned some new requirements (CNF processing, reasoning
  modes may be useful, …)
 Initial integration fairly easy

 More complete integration in process

                  McGuinness, Pinheiro da Silva, and MacCartney, 2003   11
       SNARK Example: nuclear threats

“Weapons-grade nuclear material may be
                                                      (1)    ore  refiner  material
derived from uranium ore if refining
                                                      (2)    black-mkt  material
technology is available, or it may be
acquired from a black market source.                  (3)    black-mkt  ore
Foobarstan is known to have either                    (4)    black-mkt  ore
uranium ore or a black market source,                 (5)    material  detonator  casing  warhead
but not both. Foobarstan will build a                 (6)    material  warhead
nuclear warhead if and only if it can                 (7)    detonator  warhead
obtain nuclear material, a detonator,                 (8)    casing  warhead
and the bomb casing. A warhead and                    (9)    warhead  missile  nuke
a missile, or a warhead and a truck,                  (10)   warhead  truck  nuke
constitute a nuclear threat. Foobarstan               (11)   missile  truck
has either a missile or a truck.”

Is Foobarstan a nuclear threat?

                   McGuinness, Pinheiro da Silva, and MacCartney, 2003                            12
Example: proof by contradiction

    McGuinness, Pinheiro da Silva, and MacCartney, 2003   13
Example: a proof tree

McGuinness, Pinheiro da Silva, and MacCartney, 2003   14
   An example in FOL

McGuinness, Pinheiro da Silva, and MacCartney, 2003   15
        Registering SNARK: next steps
 Add support for ‘source’ and ‘author’ fields
   Match with IW-registered ontologies where possible

 Standardize treatment of SNARK rewrites
   When do rewrites correspond to resolution, hyperresolution,
   Utilize SNARK rewrites for IW abstraction strategies

   Consider tableaux approaches for explanation

 Implement correct handling of SNARK procedural attachments
   SNARK includes procedural attachments for math, lists

   User can define new procedural attachments on the fly

   This constitutes an inference rule with an open-ended definition

 Track variable bindings through course of proof

 Integrate IW interface into SNARK standard release
                McGuinness, Pinheiro da Silva, and MacCartney, 2003    16
                    Conclusion/Next Steps
 Proof specification ready for feedback/use
 Proof browser prototype operational and expanding
   Recent: ground axiom collection, source doc/ontology collection,
    aggregation view
   Current: multiple formats, simplification, pruning, …)

 Registration service expansion - integration with XML database, use in
 EPCA, registration of services (with Fetch)

 Inference engine integration work – further rewrites for JTP (temporal
 reasoner), SNARK, begin with KM – explanation style for HALO.
 Integration with web services – current: KSL Wine Agent, KSL DQL client
 (NIMD implementation), begin with registration of web services (Fetch)
 Documentation – more examples, etc. More comments solicited (thanks to
 date to some for comments including Berners-Lee, Chalupsky, Chaudhri, Clark, Connolly,
 Forbus, Hawke, Hayes, Lenat, Murray, Porter, Reed, Waldinger, …)
                     McGuinness, Pinheiro da Silva, and MacCartney, 2003         17

McGuinness, Pinheiro da Silva, and MacCartney, 2003   18
        Proof browsing: an example                                       (1)
 Tools can be used for browsing IW proofs. The following example
  demonstrates the use of the IW Browser to visualize, navigate and ask
  follow-up questions.

 Lets assume a Wines ontology:
   Example DAML KB:
             xmlns:rdf =“”
             <rdf:Description rdf:ID="TonysSoftShell">
                       <rdf:type rdf:resource="#CRAB"/> </rdf:Description>
             <rdfs:Class rdf:ID="CRAB">
                       <rdfs:subClassOf rdf:resource="#SHELLFISH"/>   </rdfs:Class>
             <rdfs:Class rdf:ID="SHELLFISH">
                       <rdfs:subClassOf rdf:resource="#SEAFOOD"/></rdfs:Class>

 Determination of the type of a concept or instance is a typical problem
  on the Semantic Web. A reasoner may ask either about the type of an
  object and may also ask if an object is of a particular type

  Example Query: (rdf:type TonysSoftShell ?X)

                   McGuinness, Pinheiro da Silva, and MacCartney, 2003                19
          Proof browsing: An example                                    (2)
 Browsers can display portions of proofs.

 Selecting premises users can navigate throughout proof trees.

                  McGuinness, Pinheiro da Silva, and MacCartney, 2003         20
                                Trust Disclosure
 IW proofs can be used:

    to provide provenance for
     “lookup” information
    to display (distributed)
     deduction justifications
    to display inference rule
     static information

                          McGuinness, Pinheiro da Silva, and MacCartney, 2003   21
              Technical Requirements
 annotate information with meta information such as source, date,
  author, … at appropriate granularity level (per KB, per term, …)
 explain where source information is from

 explain where derived information came from

 prune information and explanations for presentation (utilizing user
  context and information context for presentation)
 provide a query language capable of expressing user requests along
  with filtering restrictions
 provide a ubiquitous source annotation language

 provide a ubiquitous proof language for interchange

 Compare answers

 propagate meta information appropriately (if I got something from a
  source I consider trusted and you consider me a trusted source, you
  may want to consider my source trusted as well)
 Identify multiple (or unknown) truth values
                McGuinness, Pinheiro da Silva, and MacCartney, 2003   22

To top