Knowledge Systems Laboratory Stanford University

---

Documents: home | architecture | publications | PML spec | IWBase | explanation generation | proof examples | FAQ
Tools: browser | explainer | PML API | PML handler | IWBase registrar

---

Step 1: Use the registrar to include meta-information about your engine and the rules it implements

1. Ask for a IW Registrar login and password

You should send a message to pp@ksl.stanford.edu in order to have a registrar's login and password for adding your own entries for sources, engines and inference rules. When creating a login for you, we also add your details as a Person entry and details of your company/university as a Organization entry.

2. Add an entry for the new inference engine

You need to log into the registrar to have access to its maintenance services. Every entry in the registry is associated to a submitter. Your are the submitter of your entries.

Once you have logged in, you can add a new engine by selecting the Add inference engine option or update an existing engine that belongs to you by selectiong the Update inference engine. An entry for your engine needs a name to become operational. However, primitive rules are the truly important information related to engines. This does not mean that you need to register all the primitive rules that your inference engine implements sice rules can gradually be associated with engines.

3. Identify the primitive inference rules supported by your inference engine

Rules can be either primitive or derived. A rule is primitive with respect to an inference engine. Thus, a rule may be a primitive rule to one engine at the same time that it can be a derived rule to another engine.

The identification of the primitive rules may be a difficult task since, for example, some of the primitive rules can be very specific to your engine and you may never considered to describe their implementations as rules.

In general, a rule entry needs just a name to become operational. In terms of explaining the rule, however, it will be appropriate if the rule has also a description and an example in English. In terms of verifying the rule, it is required that it should have either

• a definition of its premisses, conclusion and side conditions in terms of KIF patterns if it is a declarative rule or
• a verification function that is able to check the correct application of the rule.

KIF patterns or procedural attachements can be added later in the process of verifying proofs.

4. Add unregistered core inference rules, if any

5. Associated the core rules with the core inference engine

Step 2: Prepare the engine to dump proofs in the PML format

Inference engines can use any strategy for creating protable proofs. We suggest the use of the proof generator services for dumping portable proofs since they already have support for querying the IWBase in order to include the proof metadata annotating the proofs. Also, it provides an uniform way of generating protable proofs in case the portable proof specification evolves, for example.

1. Implement a routine for calling the proof generator services

Proof Generator Services API

Beta versions of these services are currently available on iw.stanford.edu/iwregistrar/. APIs of these services are presented by clicking on their links below.
• AddAnswer (http://iw.stanford.edu/iwregistrar/AddAnswers) service associates node sets with queries. Labeling sentences and variable bindings in node sets associated with queries are the answers of the query.
• AddQueries (http://iw.stanford.edu/iwregistrar/AddQueries) service associates queries with questions.
• CreateNodeSet (http://iw.stanford.edu/iwregistrar/CreateNodeSet) generates IW node sets, which are the building blocks of IW proofs and explanations. Reasoners use this service to facilitate the generation of their proofs into the portable proof format.
• CreateQuery (http://iw.stanford.edu/iwregistrar/CreateQuery) generates a IW query file. Reasoners can use this service to generate IW query files. Queries used to answer questions can be presented to users once they are stored in the IW query format.
• CreateQuestion (http://iw.stanford.edu/iwregistrar/CreateQuestion) generates an IW question file. Agents with embedded reasoners can use this service to generate IW question files storing questions probably written in a natural language, i.e., English, for future use in the process of answering and explaining the question.
• GetInferenceRules (http://iw.stanford.edu/iwregistrar/GetInferenceRules) service retrieves a list of primitive inference rules associated with a given inference engine.
• GetURIfromURL (http://iw.stanford.edu/iwregistrar/GetURIFromURL) service retrieves a URI from any URL related to a concept in the IWBase (the IW registry). This service may be used in combination with the other services that only accept URIs.

Typical Use of the Proof Generator Services

A complete process of generating proofs may involves the creation of Questions, Queries and Node Sets. The use of these services may vary from engine to another. Hovewer, they are not expected to be much different of the typical process described as follows.

1. Task 1: An agent answering a question can use the CreateQuestion service to store the original question for future use.
2. Task 2: The agent may reformulate the question into queries and call one or more reasoner to answer these queries.
3. Task 3: Reasoner can use the CreateQuery service to store queries. Alternatively,the CreateQuery service can be called leter in the process, after the answers are generated. So, the reasoner should be able to pass the URIs of the newly created node sets that are going to be associated with the new query as answers (Task 5 is not needed in this case).
4. Task 4: For the proof of each answer, the reasoner can traverse the proof and call the CreateNodeSet service for each node of the proof.
5. Task 5: Last node sets in a set of connected PML documents are usually query answers. The AddAnswers service associates node sets with queries as query answers.
6. Task 6: The AddQueries associated service associates questions with queries.
Since node sets are the building blocks of portable proofs, reasoners just need to perform the task 4 in order to generate proofs. However, reasoners carrying out tasks 3, 4 and 5 may have a better presentation of their proofs since users should be able to visualize the queries associated with proofs and answers associated with a query.

Examples of the use of the proof generator services

• An old (and perhaps no longer valid) example of a LISP program used to dump proofs produced by SNARK. This example shows how a LISP based program can call proof generation services.
• Example of a Java program used to dump proofs produced by JTP
  • The IWHandler.java class receives a JTP reasoning setp (the JTP's internal representation of proof) along with a base URI and a base filesystem path when instantiated. Thus, by calling its publish() method, the handler create the proof by calling IWUtil's generateNodeSet() and generateQuery().
  • The generateNodeSet() and generateQuery() of IWUtils.java are responsible for calling the IW proof generation services.
  • IWUtil.java uses the GetURLContents.java class.

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

Step 3: Browse your proofs in the IW Browser

---

Documents: home | architecture | publications | PML spec | IWBase | explanation generation | proof examples | FAQ
Tools: browser | explainer | PML API | PML handler | IWBase registrar

Copyright @2003 Stanford University
All Rights Reserved.

pp@ksl.stanford.edu