Computing & Information Sciences Kansas State University Lecture 18 of 42 CIS 530 / 730 Artificial Intelligence Lecture 18 of 42 Knowledge Representation

Computing & Information SciencesKansas State University

Lecture 18 of 42CIS 530 / 730Artificial Intelligence

Lecture 18 of 42

Knowledge Representation Continued: KE,Inheritance, & Representing Events over Time

Discussion: Structure Elicitation, Event Calculus

William H. Hsu

Department of Computing and Information Sciences, KSU

KSOL course page: http://snipurl.com/v9v3

Course web site: http://www.kddresearch.org/Courses/CIS730

Instructor home page: http://www.cis.ksu.edu/~bhsu

Reading for Next Class:

Section 10.4 – 10.9, p. 341 – 362, Russell & Norvig 2nd edition

IM: http://en.wikipedia.org/wiki/Information_management

Event calculus: http://en.wikipedia.org/wiki/Event_calculus

Protégé-OWL tutorials: http://bit.ly/3rM1pB, http://bit.ly/18pMgR

http://snipurl.com/v9v3

http://www.kddresearch.org/Courses/CIS730

http://www.cis.ksu.edu/~bhsu

http://en.wikipedia.org/wiki/Information_management

http://en.wikipedia.org/wiki/Event_calculus

http://bit.ly/3rM1pB

http://bit.ly/18pMgR



Lecture Outline

Reading for Next Class: Sections 10.4 – 10.9 (p. 341 – 362), R&N 2e

Last Class: Knowledge Engineering (KE), Protocol Analysis, Fluents Ontology engineering: defining classes/concepts, slots Concept elicitation techniques

Unstructured

Structured

Protocol analysis (“thinking aloud”)

Today: Frames, Semantic Nets, Inheritance; Event & Fluent Calculi Structure elicitation Computational information and knowledge management (CIKM) Representing time, events

Situation calculus

Event calculus

Fluent calculus Brief tutorial: OWL ontologies in Protégé (http://bit.ly/18pMgR)

Coming Week: CIKM, Logical KR Concluded; Classical Planning

http://bit.ly/18pMgR



Acknowledgements

© 2004 H. KnublauchTopQuadrant, Inc.(formerly University of Manchester)http://www.knublauch.com

© 2005 M. HauskrechtUniversity of PittsburghCS 2740 Knowledge Representationhttp://www.cs.pitt.edu/~milos

Milos HauskrechtAssociate Professor of Computer ScienceUniversity of Pittsburgh

Holger KnublauchVice President, TopQuadrantpreviously Research Fellow, Stanford Medical Informatics & Univ. of Manchester

© 2005 N. Noy & S. TuStanford Center for Biomedical Informatics Researchhttp://bit.ly/jwOf3http://bit.ly/2NBeCIhttp://bmir.stanford.edu

Samson TuSenior Research Scientist

BMIR

Natasha NoySenior Research ScientistBMIR

© 2001 G. TecuciGeorge Mason Universityhttp://bit.ly/3tUACW http://lalab.gmu.edu/cs785/http://lac.gmu.edu

Georghe TecuciProfessor of Computer ScienceDirector, Learning Agents CenterGeorge Mason University

http://www.knublauch.com/

http://www.cs.pitt.edu/~milos

http://bit.ly/2NBeCI

http://bit.ly/2NBeCI

http://bmir.stanford.edu/

http://lac.gmu.edu/members/tecuci.htm





Universe of Decision Problems

Recursive EnumerableLanguages

(RE)

RecursiveLanguages

(REC)

HL

VALIDLVALIDL

LSAT

SATLL L complem.

underclosure

DL

Decision Problems:Review

Co-RE (REC)

LH: Halting problem

LD: Diagonal problem

Semi-decidableduals:α LVALID iff¬α LSAT

C

Undecidabledualsα LVALID

C iff

¬α LSAT

α ⊢RES ?

α

Y

✓ ✗N



“Concept” and “Class” are used synonymously

Class: concept in the domain

wines wineries red wines

Collection of elements with similar properties

Instances of classes

Particular glass of California wine

Adapted from slides © 2005 N. Noy & S. TuStanford Center for Biomedical Informatics Researchhttp://bmir.stanford.edu

Concepts/Classes:Review

Middle

level

Top

level

Bottom

level




Slots in class definition C Describe attributes of instances of C Describe relationships to other instances e.g., each wine will have color, sugar content, producer, etc.

Property constraints (facets): describe/limit possible values for slot


Slots/Attributes/Relations:Review

Slots & facets for Concept/Class Wine




Tabs partition different work areas

Buttons and widgetsfor manipulating slots

Area for manipulating the class hierarchy

Protégé – Default Interface:Review


Downloads, primer, documentation:http://protege.stanford.edu


http://protege.stanford.edu/faq.html



Advanced approaches to KB and agent development

Elicitation based on the personal construct theory

A scenario for manual knowledge acquisition

Elicitation of expert’s conception of a domain

Knowledge acquisition for role-limiting methods

Knowledge Engineering:Review

© 2001 G. Tecuci, George Mason UniversityCS 785 Knowledge Acquisition and Problem-Solving http://lalab.gmu.edu/cs785/

http://lalab.gmu.edu/cs785/



A knowledge engineer attempts to understand how a subject matter expert reasons and solves problems and then encodes the acquired expertise into the agent's knowledge base.

The expert analyzes the solutions generated by the agent (and often the knowledge base itself) to identify errors, and the knowledge engineer corrects the knowledge base.

KnowledgeEngineer

DomainExpert

Knowledge Base

Inference Engine

Intelligent Agent

ProgrammingDialog

Results


How Agents Are Built:Review




Defining problem to solve and system to be built:requirements specification

Choosing or building an agent building tool:Inference engine and representation formalism

Development of the object ontology

Development of problem solving rules or methods

Refinement of the knowledge base

Feedback loops

among all phases

Understanding the expertise domain

Adapted from slide © 2001 G. Tecuci, George Mason UniversityCS 785 Knowledge Acquisition and Problem-Solving http://lalab.gmu.edu/cs785/

Agent Development Process:Review




(based primarily on Gammack, 1987)

1. Concept elicitation: methods(elicit concepts of domain, i.e. agreed-upon vocabulary)

2. Structure elicitation: card-sort method (elicit some structure for concepts)

3. Structure representation (formally represent structure in semantic network)

4. Transformation of representation (transform representation to be used for some desired purpose)


Elicitation Methodology:Review





Structure Elicitation:Card-Sort Method

The Card-Sort Method

(elicit the hierarchical organization of the concepts)

• Type the concepts on small individual index cards.

• Ask the expert to group together the related concepts into as many small groups as possible.

• Ask the expert to label each of the groups.

• Ask the expert to combine the groups into slightly larger groups, and to label them.

The result will be a hierarchical organization of the concepts





Card-Sort Method:Illustration

Satchwell

Time Switch

Programmer

Thermostat

Set Point

Rotary Control Knob

Gas Control Valve

Solenoid

Electrical System

Electrical Supply

Electrical Contact

Fuse

Pump

Motorized Valve

Electric Time Controls

Thermostat

Gas Control

Electrical Supply

Electrical Components

Mechanical Components

Control Electricity

Part of the hierarchy of concepts from the card-sort method




Strengths• gives clusters of concepts and hierarchical

organization• splits large domains into manageable sub-areas• easy to do and widely applicable

Weaknesses • incomplete and unguided • strict hierarchy is usually too restrictive

Card-Sort Method:Properties





Structure Representation [1]:Definition


Represents the acquired concepts into a semantic network and acquires additional structural knowledge:

• Ask the expert to sort the concepts by considering each concept C as a reference, and identifying those related to it.

• Ask the expert to order the concepts related to C along a scale from 0 to 100, marked at the side of a table. The values are read off the scale and entered in a data matrix.

• Generate a network from the matrix, where the nodes are the concepts and the weighted links represent proximities.

• For each pair of concepts identified as related, ask the expert what that relationship is.





Domestic Plumbing System

Time Switch

Electrical Supply

Pipe Water Supply

Feedback Loop

Electrical Contact

Flow Header Tank

Water Expansion

Thermostat

Thermal Circuit Heat

Radiator Control Valve

Gravity

Pilot Light Boiler Radiator Air

Gas Control Valve

Primary Circuit

Hot Water Cylinder

Immersion Heater

Main Gas Supply

Motorized Valve

Structure Representation [2]:Illustration





Structure Representation [3]:Properties

Strengths• gives information on the domain structure in the

form of a network• shows which links are likely to be meaningful• organizes the elicitation of semantic relationships

Weaknesses • results depend on various parameter settings • requires more time from the expert • combinatorial explosion limits its applicability




Hierarchy and Taxonomy

© 2005 M. Hauskrecht, Univ. of Pittsburgh CS 2740 Knowledge Representationhttp://www.cs.pitt.edu/~milos/courses/cs2710/

http://www.cs.pitt.edu/~milos/courses/cs2710/



Graphical Representation ofInheritance





Inheritance Networks [1]:Trees with Strict Inheritance

Based on slide© 2005 M. Hauskrecht, Univ. of Pittsburgh CS 2740 Knowledge Representationhttp://www.cs.pitt.edu/~milos/courses/cs2710/




Inheritance Networks [2]:Lattices with Strict Inheritance





Inheritance Networks [3]:Defeasible Inheritance





Problems withShortest Path





Formal:Inheritance Hierarchy





Protégé API(Classes, properties,

individuals, etc.)

Protégé GUI(Tabs, Widgets, Menus)

DBStorage

Pro

tég

é C

ore

Sys

tem

Protégé OWL API(Logical class defn’s,

restrictions, etc.)

Protégé OWL GUI(Expression Editor,

Conditions Widget, etc.)

OWL FileStorage

Jena API(Parsing, Reasoning)

OW

L P

lug

in

OWLExtension APIs(SWRL, OWL-S, etc.)

OWL GUI Plugins(SWRL Editors, ezOWL,OWLViz, Wizards, etc.)

OWL Plug-in Architecture

Adapted from slide © 2004 H. Knublauch (formerly University of Manchester)http://www.knublauch.com




OWLMetadata

(Individuals)

OWLMetadata

(Individuals)

OWLMetadata

(Individuals)

OWLMetadata

(Individuals)

Tourism Ontology

Web Services

Destination

AccomodationActivity

© 2004 H. Knublauch (formerly University of Manchester)http://www.knublauch.com

Tourism Semantic Web




Adapted from material © 2003 – 2004 S. Russell & P. Norvig.

SituationcalculusFigure 10.2p. 329 R&N 2e

Actions, Situations, Time & Events [1]: Situation Calculus Revisited

Axioms: Truth of Predicate P Fully specify situations where P

true biconditional (, iff)

Original Predicates Describe state of world Each augmented with situation

argument s



Actions, Situations, Time & Events [2]: Event Calculus

Domain-Independent Axioms

Domain-Dependent Axioms

Still Need to Solve Frame Problem (by Circumscription)

Figure © 2003 S. Russell & P. Norvig.

Event calculusFigure 10.3p. 336 R&N 2e



Actions, Situations, Time & Events [3]: Fluent Calculus

Fluent: Condition (Predicate) That Can Change Over Time (e.g., On)

Fluent Calculus: Variant of Situation Calculus Defaults ∘ (concatenation) of fluents with state

Figure © 2003 S. Russell & P. Norvig.

State fluentsFigure 10.6p. 340 R&N 2e

Washington

Adams Jefferson



CIKM:Review

Information Management Data acquisition: instrumentation, collection, polling, elicitation Data and information integration: combining multiple sources

May be heterogeneous (different in quality, format, rate, etc.)

Underlying formats, properties may correspond to different ontologies

Ontology mappings (functions to convert between ontologies) needed Data transformation: preparation for reasoning, learning

Preprocessing

Cleaning Includes knowledge capture: assimilation from various sources

Knowledge Management Term used most often in business administration, management science Related to IM, but capability and process-centered Focus on learning and KA, organization theory, decision theory

Discussion, apprenticeship, forums, libraries, training/mentoring

Modern theory: KBs, Expert Systems, Decision Support Systems



Terminology

Knowledge Engineering (KE): Process of KR Design, Acquisition Knowledge

What agents possess (epistemology) that lets them reason

Basis for rational cognition, action

Knowledge gain (acquisition, learning): improvement in problem solving Knowledge level (vs. symbol level): level at which agents reason Semantic network: inheritance and membership/containment relationships Knowledge elicitation: KA/KE process from human domain experts

Protocol analysis: preparing, conducting, interpreting interview

Less formal methods: subjective estimation & probabilities

Fluents: Conditions (Predicates) That Can Change over Time Classes, nominals (objects / class instances): spatial, temporal extent Fluent calculus: situation calculus with defaults, ∘ (concatenation)

Computational Information and Knowledge Management (CIKM) Data/info integration & transformation: collecting, preparing data Includes knowledge capture: assimilation from various sources



Summary Points

Last Class: Knowledge Engineering, Elicitation, Knowledge Rep. Elicitation

Techniques: unstructured, structured, “think aloud” (protocol analysis)

Stages: concept (last time), structure (today) Knowledge acquisition (KA) Information management, knowledge management defined KR: situation calculus and successor state axioms; fluents, intervals

Today: KE, Ontologies Concluded; CIKM; Event and Fluent Calculi Structure elicitation From semantic networks to ontologies Information management Knowledge management Event calculus Fluent calculus

Next Class: Defaults, Defeasible Reasoning; Planning Preview Coming Week: Planning (Section IV)

Documents

Computing & Information Sciences Kansas State University Lecture 18 of 42 CIS 530 / 730 Artificial Intelligence Lecture 18 of 42 Knowledge Representation