Knowledge Engineering in First-Order Logic: by G. Sathish Kumar Ap-Cse

KNOWLEDGE ENGINEERING
IN FIRST-ORDER LOGIC
By
G. Sathish Kumar
AP-CSE
KNOWLEDGE ENGINEERING IN
FIRST-ORDER LOGIC
• The general process of knowledge-base construction — a process
called knowledge engineering.
• A knowledge engineer is someone who investigates a particular

domain, learns what concepts are important in that domain, and
creates a formal representation of the objects and relations in the
domain.
The knowledge-engineering process
Knowledge engineering includes the following steps:
1. Identify the task.

• The knowledge engineer must delineate the range of questions that
the knowledge base will support and the kinds of facts that will be
available for each specific problem instance.
• For example, does the wumpus knowledge base need to be able to

choose actions or is it required to answer questions only about the
contents of the environment?
• Will the sensor facts include the current location?
• The task will determine what knowledge must be represented in

order to connect problem instances to answers.
• This step is analogous to the PEAS process for designing agents

2. Assemble the relevant knowledge.
• The knowledge engineer might already be an expert in the domain,

or might need to work with real experts to extract what they
know—a process called knowledge acquisition.
• At this stage, the knowledge is not represented formally. The idea is

to understand the scope of the knowledge base, as determined by the
task, and to understand how the domain actually works.
3. Decide on a vocabulary of predicates, functions, and constants.
• That is, translate the important domain-level concepts into

logic-level names.
• This involves many questions of knowledge-engineering style.
• Like programming style, this can have a significant impact on the

eventual success of the project.
4. Encode general knowledge about the domain.
• The knowledge engineer writes down the axioms for all the
vocabulary terms.
• This pins down (to the extent possible) the meaning of the terms,
enabling the expert to check the content.
5. Encode a description of the specific problem instance.
• If the ontology is well thought out, this step will be easy.
• It will involve writing simple atomic sentences about instances of

concepts that are already part of the ontology.
6. Pose queries to the inference procedure and get answers.
• This is where the reward is: we can let the inference procedure
operate on the axioms and problem-specific facts to derive the facts
we are interested in knowing.
• Thus, we avoid the need for writing an application-specific solution

algorithm.
7. Debug the knowledge base.
• The answers to queries will seldom be correct on the first try.
• More precisely, the answers will be correct for the knowledge base as
written, assuming that the inference procedure is sound, but they will not
be the ones that the user is expecting.
• For example, if an axiom is missing, some queries will not be answerable

from the knowledge base.
The electronic circuits domain
• Will develop an ontology and knowledge base that allow us to reason
about digital circuits
• Will follow the seven-step process for knowledge engineering.
1. Identify the task
• There are many reasoning tasks associated with digital circuits.
• At the highest level, one analyzes the circuit’s functionality.
• For example, does the circuit actually add properly?
• If all the inputs are high, what is the output of gate A2?
• Questions about the circuit’s structure like, what are all the gates connected
to the first input terminal?
• Does the circuit contain feedback loops?
• There are more detailed levels of analysis, including those related to timing
delays, circuit area, power consumption, production cost, and so on.
• Each of these levels would require additional knowledge.
2. Assemble the relevant knowledge
• What do we know about digital circuits?
• For our purposes, they are composed of wires and gates.
• Signals flow along wires to the input terminals of gates, and each gate
produces a signal on the output terminal that flows along another wire.
• To determine what these signals will be, we need to know how the gates
transform their input signals.
• There are four types of gates: AND, OR, and XOR gates have two input
terminals, and NOT gates have one.
• All gates have one output terminal.
• Circuits, like gates, have input and output terminals.
3. Decide on a vocabulary
• We now know that we want to talk about circuits, terminals, signals, and
gates.
• The next step is to choose functions, predicates, and constants to represent
them.
• First, we need to be able to distinguish gates from each other and from other
objects.
• Each gate is represented as an object named by a constant, about which we
assert that it is a gate with, say, Gate(X).
• The behavior of each gate is determined by its type: one of the
constants AND, OR, XOR,or NOT.
• Because a gate has exactly one type, a function is appropriate: Type
(X)=XOR.
• Circuits, like gates, are identified by a predicate: Circuit(C1).
• The connectivity between gates can be represented by a predicate,

Connected, which takes two terminals as arguments, as in
4. Encode general knowledge of the domain
• One sign that we have a good ontology is that we require only a few
general rules, which can be stated clearly and concisely.
• These are all the axioms we will need:

5. Encode the specific problem instance
• The circuit is encoded as circuit C1 with the following description.
• First, we categorize the circuit and its component gates:
6. Pose queries to the inference procedure
• What combinations of inputs would cause the first output of C1 (the sum
bit) to be 0 and the second output of C1 (the carry bit) to be 1?
This final query will return a complete input–output table for the device, which can be
used to check that it does in fact add its inputs correctly. This is a simple example of
circuit verification.
7. Debug the knowledge base
• We can perturb the knowledge base in various ways to see what kinds
of erroneous behaviors emerge.
• We can pinpoint the problem by asking for the outputs of each gate.
For example,

Knowledge Engineering in First-Order Logic: by G. Sathish Kumar Ap-Cse

Uploaded by

Copyright:

Available Formats

Knowledge Engineering in First-Order Logic: by G. Sathish Kumar Ap-Cse

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Knowledge Engineering in First-Order Logic: by G. Sathish Kumar Ap-Cse

Uploaded by

Copyright:

Available Formats

KNOWLEDGE ENGINEERING

• A knowledge engineer is someone who investigates a particular

1. Identify the task.

• For example, does the wumpus knowledge base need to be able to

• The task will determine what knowledge must be represented in

• This step is analogous to the PEAS process for designing agents

• The knowledge engineer might already be an expert in the domain,

• At this stage, the knowledge is not represented formally. The idea is

• That is, translate the important domain-level concepts into

• This involves many questions of knowledge-engineering style.

• Like programming style, this can have a signiﬁcant impact on the

5. Encode a description of the speciﬁc problem instance.

• If the ontology is well thought out, this step will be easy.

• It will involve writing simple atomic sentences about instances of

• Thus, we avoid the need for writing an application-speciﬁc solution

• The answers to queries will seldom be correct on the ﬁrst try.

• For example, if an axiom is missing, some queries will not be answerable

• The connectivity between gates can be represented by a predicate,

• These are all the axioms we will need:

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.