enabling technology for knowledge sharingtk338by5382/tk338by5382.pdf · enablingtechnology for...

Post on 10-Mar-2020

4 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Enabling Technologyfor

Knowledge Sharing

Prof. Richard Fikes

Knowledge Systems LaboratoryComputer Science Department

Stanford University

2/20/92 Knowledge SystemsLaboratory, Stanford University

/

Knowledge Sharing Technology Project

Principal Participants --Prof. Richard Fikes Prof. Jeff Van Baalen (Univ. of Wyoming)Prof. Mike Genesereth Prof. Mark Cutkosky (Mech. Eng.)

Tom Gruber (Res. Assoc.)Project Objective -- Develop technology to enable reuse of knowledgebases and knowledge systems

Current Focus -" The Heterogeneous Languages Problem

" Reuse requires translating from one language to another" We are developing -

" A standard knowledge interchange language (KIF)" Tools to automate the translation process

" The Heterogeneous Ontologies Problem" Combining kbs requires reconciling vocabulary differences" We are developing --

" Tools for developing and combining ontologies (Ontolingua)* Standard domain vocabularies in a portable form

Knowledge Systems Laboratory, Stanford University

The Problem

Encoding knowledge requires extensive time and expertise

" Domain modelsMethods for performing tasks

Knowledge bases and knowledge systems are not reusableEach new system requires a new knowledge base

" Existing systems cannot be incorporated into new systems

We must find ways of:PreservingReusingCombiningExtending

existing knowledge bases and knowledge systems

2 Knowledge SystemsLaboratory, Stanford University

DARPA Knowledge Sharing Effort

Objective --Develop the technical infrastructure to support the sharing ofencoded knowledge

Sponsors -Defense Advanced Research Projects Agency (DARPA)Corporation for National Research Initiatives

" National Science Foundation (NSF)Coordinators -

Bob Neches and Ramesh Patil, ISIWorking groups -

InterlinguaCommon KR System SpecificationsExternal InterfacesReusable Ontologies

3 Knowledge SystemsLaboratory, Stanford University

Incorporate or Intemperate?

Incorporate knowledge and methods into new systemImport, combine, and extend existing knowledge basesImport and link reasoning modules

" Analogous to an agent learning the knowledge and methodsInteroperate with existing systems to obtain knowledge services

Establish languages and protocols for -" Knowledge interchange" Reasoning services

Analogous to establishing a team of specialists

Both incorporation and interoperation will be needed

4 Knowledge SystemsLaboratory, Stanford University

The Central Task: Knowledge Communication

Elements of a knowledge communication language

Knowledge manipulation operators

5 Knowledge Systems Laboratory, Stanford University

Problem: Heterogeneous Syntax and Semantics

Knowledge is represented in widely varying languages

Languages are specialized for specific tasks and methods

Reuse requires translatingfrom one language to another

What's needed?A standard knowledge interchange syntax and semanticsTools to automate the translation process

6 Knowledge SystemsLaboratory, Stanford University

7 Knowledge Systems Laboratory, Stanford University

Addressing the Syntax and Semantics Problem

The Interlingua Working Group" Co-chairs -

Richard Fikes and Mike GeneserethObjective -

Develop technology for interchanging encoded knowledgeApproach -

Design interlingua for communicating knowledge in literary mode

/keT\( 'n )\§RiyKBSI

/keT\( 'n )\§R2/KBS2

8 Knowledge Systems Laboratory, Stanford University

KIF: A Knowledge Interchange Format

Design criteria --Implementation independent declarative semanticsLogically comprehensive

Capable of representing all declarative knowledge in typicaapplication kbs

TranslatableEnables practical means of translating KB's to and from typicalrepresentation languages

Human readableUse to describe representation semanticsUse to publish example KB'sEnable human assisted translation

9 Knowledge Systems Laboratory, Stanford University

KIF Characterization - 1

Basic vocabulary

(* (salary Joe) 2) (+ $x $y) (value $f ab) (if (> ao)a (- a))(setof $x (parent Joe $x))

Sentences(on blockl block2) (disjoint $x <2>w) (holds $r $x $y)(forall $x (=> (member $x elephants) (color $x grey)))(siblings = (lambda (sp) (union (brothers $p) (sisters $p))))(bel John/(material moon cheese))(=> (bel John $s) (bel mary $s))

and or if => + sin member first $x @y

Terms

10 Knowledge SystemsLaboratory, StanfordUniversity

KIF Characterization - 2

Definitions

(defunction paternal-grandfather (sx) ::= (father (father $x)))(defrelation bachelor (sx) ::= (man $x) (not (married $x)))(defrelation person (sx) ::=> (mammal $x))

Inference rules

(bird $x) (consis (flies $x)))

To find out more about KIF -Reference manual available via FTP

@hudson.stanford.eduProposals discussed on an open e-mail distribution list

interlingua@isi.edu

(defobject pi ::= 3.14159)

(«= (flies $x)

12

Ontology Development

KIF includes a set of basic constantsand if true + sin member union first domain

Nonbasic constants can be defined in terms of basic constants

E.g, subset, one-to-one engine, pump, weight,(defrelation subset (ssl $s2)

(=> (member $x $s1 ) (member $x $s2)))

Who defines what?Computer scientists can provide -

" General representational primitivesE.g., class, instance, slot, value-class, value-cardinality

"Starter" domain vocabulariesE.g., lumped parameter models

Domain experts must build the domain models

Knowledge Systems Laboratory, StanfordUniversity

::=(setpssl) (setpss2)

PDES: Product Data Exchange Specification Project

Developing a standard for describing engineered products (STEP)

" ISO committee on Industrial Automation Systems" Subcommittee on Manufacturing Languages and Data

The standard is a domain ontologyCalled an "information model"A formally defined vocabulary for describing productsDefined in their own implementation independent language

13 Knowledge Systems Laboratory, Stanford University

Summary and Conclusions

We must find ways of reusing and sharing encoded knowledge

Multiple efforts are underway to produce reusable knowledge

What's needed?Standard languages and protocolsKnowledge reuse tools

Knowledge base translators" Ontology development environments

Reusable knowledge bases and servicesLibrariesKnowledge vendors

References -R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator, & W. Swartout; "Enabling

Technology for Knowledge Sharing"; Al Magazine, Vol. 12, No. 3; Fall 1991 ; pp 36-56.R. Fikes, M. Cutkosky, T. Gruber, J. Vanßaalen; "Knowledge Sharing Technology Project

Overview"; Knowledge Systems Laboratory Technical Report 91-71; November 1991.

19 Knowledge Systems Laboratory, StanfordUniversity

tH

.1

I

{

"s *

bp fl bo 53.So Q 8 „ cv

fl-T3,fl'3 3 2-*

"Ell* gfoSSSi"1 %^«"S^J Sfi &JS g^"^C S>Ph Eo S+» fi

&** ill 8 I «~ jg g c * ft SP-S S

"a *~ ,2 «§ £S £o-J 2 6 k&,&"3 s1-B !*-81-s

oi <n C _3 *2 .JS oo

?»^gg«g ■So

®bo2«,««osis

"S'o2~>o2ft0^ g S.SPU ?5 *__! o -3 E?*s?° *"£w„ fi 2> £> fi -S a ft S

5»2 8 rt 3Sh

3_g -g Sts ,fl £.2 o% >»?fi 5 3 S S A73 o

co «}

_>

ST t_ §

ft^S— 3>8«2t5ag.^ bo rt fIH«C'3rt'-3g203

e_<

o . o r h

S^i-cSgo^cv £ E

<v

.S -3 -*& Sffi £ eg >,a g

©

rtj- "* <v *££ -£aß'-'flflrt^JS« " S :§ «Z c w> fl § «5

g ,fl cfl £ * _r*

© t_

ft "** *^ 33 *B S&iP ® ? S boboc g-J&?fl^| «330fl

"g s f ■&j* b -§ 1 a aIllgS g^, § ?1" ftja S s « S S*

*- T fi c 2? £* «gj«t-' o.s ea art"

'T3 3flfifi22*9 M B»? ftJ_ o'0 2

"

S 2? o -2fl^«rt»H o^*a>*wo-fifl,ia w«j_o ->

<p-rt fi => fi« So^^.&^^fi

Sa* aVi ?j^ 5^ rtx

g,£ cd g'5 1!fl » §. ar^ i2«g.a

Ba)-aOai ft Cfi«iB«1J» S S c « S * S

hs c S g "■« .S -3 S 2 «*j

®

S S

©

S.S 8 k:J3« 8 5

fl-^jj a o <«32 fe^s«S S>,2-a

Si aS | ill § 1 2-g li

Sd— '3 a> 1? « S g >> °

©

c o *Blli|lg :»«I'»J6-aMrtObSS-SSSKaJfioSanooQ( Q Pa rao<vviOoflfl

"

o

CU

■**

6 £° *»a> cv-«j o:s

Crt

3

Ct- CO

o ««"£o oft. 2a

CO

fi JC

fi fert JS

c n,o :""JJ C Jj« * cS"Is 88 1?.5 «a 'Sm fi

O

illo =5 fl

9 8» feJ-5 oCO ? fi

'?"< ftftfe °

-a§of

T3 §.2 B

firt o"^

t*

w .Bcv >ft flcfl 53x, S■4- 0}_

-♦*

.S wa) C

03

§ ft

s *** «Uca "75

.-<

ft■_» "-05 S8 «MC o«S «cvrt boC *« I

©

5'Si r3■S-Sfi 15obo Cfi %"fH

CO

~3 cv3 ft*S «v

"

tocv"QoI—l3fiotttc

.FNT3

"afi

aTa>

CO

_2

bfiT3,2 «

!§?«t- fi

O

OS-*-» ""*S c-2.2fi -5o a

CU

q>

I ft

s "Sbo ISc

*Eb cvfi &03

CO

"€ SPv C0) oc Beh rt

'covcv>"

rt

1rt-<-OT

&oi—ioflo"V

bofl

"l-l(-

XOT

9>bocv

"5o5

9bo

fi e ft*C 3 * ftrfi «J 2 *°? fi g -sft-5 °*"

« c g

©

8 'SjS "-" co 03

©O £ o

fill§»J 8 gS "5 :s j_ -"

■£

©

n fl rtHIPg gt^ g>

®

£ fi 1 "§

ata rt *a rtfi = -at £

■*»

fl

s*

rt"s 1 1 1 i41,0 w « SX 53 "8 fl

13

9 fi S5 T3 .3 5>

fl«g% ft rt o «* 2 £* «Si fl y c

rt ".2 §§ rt § g£© So bo Z. JSS|.g£-a1 ■§ "» S 2

&2^ its

fi Sj §1S * g fa S

SCSI'S S-S 2 ,S 2 -t?c *_!

Q

3 rt

.a a %"* -

©

rt ft Q <dlljll« ft ©

©

bp.So to ..^3 rt

&

«s 1 *? § i fiS6 ft^.S 3

cv

0 fl j_ *S■+j rt

©

0h bo fi 2**fe 2 c « §rt C i—3

C

cv "*J3 co S 53 "£ «o

8 &'§ S «,2 bojK«ft.2.S .2 S51

§ „ ftMfl^ rt^«^5 rt 5 g £| g

C c c J3 rs rs "»o co O rt sf1 si

*S o C h rt^'-j^s

"s S 8 eg 6-g^j

c ©«£»» ofi^

© ft -_» 13 rt S&?n *»

B?fl«ffi°Ool.;£>B©.2©-_!_2ita,|>'floft.Bcooi>t>

'co

©

>"r-lflU)

Ih

flrt-t->OT

o"3fl

©

bofl

'CdOT9bo

©

o

*CQ

v

©

>"r-lfl

T3Ih

flrt-t->OT

QJ60

OSrHOCO

"rH

S0)

cdU

13QJcl

QJ Id"rHOS

ovv

"rH"—Ht—H

QJ

BCL,

"l-H

CO

QJ

" rHoCL

0>?H

13CLSH0)

0)50

OUo

I-H

QJ"I-H

QJ-4-*Cio

CL aak>vnHMMMM

fi

B*"»

s_CL

QJ«4->«4-»OS

i

Dmann O

"♦-»#co

QJrfi

vo

oQJ

"I-HcdCio

"rH

CLCD

QJU

oCO

O

QJ

3*<o

COO

Oh-»

1_ CO

I 8 1CO QJ Jj *£

* fi 25!_. S * G

j_ tf Sjj &_2 o gO jq

iv oSJ co

OUfi

J; g ort S t 3"8 8 .g0^ **^-*^^,

QJ

3 iv g 5<3 qj hg J3 sM £ g-V fi ■?S sS rt1' *fi fi fi

v

oI

p-Hrt

a! <£"Sl coo SCO -M

CO r-* Sg sVo6I

COcortg

QJU

"rH

fi"rH"afirtCL

"S

v rt

<v rfi

i/QJU

"rH

i60fi

"rHT3firtCLX

QJU

"|H

ff fifi *iH

«+■» CO

"fi co60 £"JH O

Vv"rHI60

"rHrtO

CLQJU

The StanfordHow Things Work

Project

Principal Investigators: Ed FeigenbaumRichard Fikes

Research Associates: Bob EngelmoreTom GruberYumi Iwasaki

Knowledge Systems LaboratoryComputer Science Department

Stanford University

1/23/92 Knowledge Systems Laboratory, StanfordUniversity

2 Knowledge Systems Laboratory, Stanford University

Project Objectives

Develop knowledge-based technology for an "engineer's associate"

" Multi-use representations of engineering knowledgeModeling design knowledge

" Structure, behavior, requirements, assumptions, rationaleReasoning methods to perform core engineering tasks

Predicting and analyzing device behaviorRapid modeling and analysis of preliminary designs

Provide tools implementing the technology to research community

" Device Modeling Environment (DME)

3 Knowledge Systems Laboratory, Stanford University

Role of Knowledge-Based Technology

Multi-use knowledge representations

" Highly expressive logic-based declarative languages

" Automatic translation into specialized representations

Assistance with the prediction and analysis of device behaviorAutomatic formulation of an appropriate simulation model

" Abstractions, assumptions, perspective, level of detail, ...Qualitative simulation during preliminary stages of designGuidance of a simulator to consider relevant scenariosGenerating causal explanations of simulation resultsDetermining whether behavior satisfies specifications

4 Knowledge Systems Laboratory, Stanford University

An Experimental Methodology

Work with representative electromechanical devicesE.g., " Electrical power system for Hubble Telescope

Motion control devices (e.g., robot manipulator)Reaction control system for Space ShuttleTemperature gauge, pressure regulator, ...

Collaborate with

" Engineering groupsStanford's Center for Design Research

Professor Mark Cutkosky

" Research groups working on similar problems" Lockheed Laboratories" NASA AMES

Palo Alto Collaborative Testbed (PACT)Xerox Palo Alto Research Center

Embody methods in experimental testbed systems

" DME: Device Modeling Environment

Traditional Simulation Environment

Device-specificcomputational

model

Behaviordescription

5 Knowledge Systems Laboratory, StanfordUniversity

Simulation fl iengine #-/l = 1 j f uman

I v^

6 Knowledge SystemsLaboratory, Stanford University

Knowledge-based Device Modeling Environment

DMEModel formulation from librariesarid graphical interactionGeneration of equation modeAutomatic identification ofqualitatively relevant regionsInteractive exploration ofbehavior scenariosJ fumonAutomatic generation of causaexplanations

NICD Battery Normal Operating Range Behavior

; Model ofa NICD battery behavior in its normal operatingrange.Participant:

$NICD :type Nickel-Cadmium-Battery

Activation-condition:

Behavior-constraints:

; In the normal operatingrange, the voltage stays constant

8 Knowledge Systems Laboratory, StanfordUniversity

6.0 < (stored-charge $NICD) < 30.0

(voltage-generated $NICD) = 33.0

NICD Battery Over Charged Behavior

; Model of the NICD battery charging or discharging in the overchargedstate.

Participant:$NICD :type Nickel-Cadmium-Battery

Activation-condition:(stored-charge $NICD) > 30.0

Behavior-constraints:

; During overcharging, the voltage is an increasing function of the storedcharge.

9 Knowledge SystemsLaboratory, Stanford University

(voltage-generated $NICD) = (Mo+ (stored-charge $NICD))

10

EPS Desirable ScenarioVoltage(volts) 4

Batterydamaged 35.0 [

openK2

openKl

close K2

close Xl

over-charged

Knowledge Systems Laboratory, Stanford University

normal-operating-range

Under-charged

EPS Undesirable Scenario

Under-charged normal-operating-range

over-charged

Knowledge Systems Laboratory, Stanford University11

14 Knowledge Systems Laboratory, StanfordUniversity

DME Today: Semi-Automatic Behavior Analysis

Designer describes deviceComponents from a libraryInterconnections of components

Designer selects behavior models of interest

From model library

System generates simulation model of deviceQualitative or quantitative

Designer uses simulator to explore possible device behaviors

System provides causal explanations of simulated behavior

Designer compares predicted and expected behavior

15 Knowledge Systems Laboratory, Stanford University

Toward Fully Automatic Behavior Analysis

Designer describes device

«** Designer describes expected functionalityThe criteria against which behavior is to be tested

«»* System composes behavior model appropriate for the test

" Abstractions, assumptions, perspective, level of detail,System generates simulation model of device

«** System guides simulator to scenarios relevant to specifications

" System provides causal explanations of simulated behavior

<«* System determines whether behavior satisfies specificationsPresents constraints which design needs to satisfy specifications

16 Knowledge Systems Laboratory, Stanford University

Goal-Directed Model Formulation

Task is to compose behavior model appropriate for the test

" PerspectiveE.g., electrical, chemical, heat, spatial,

Simplifying assumptionsE.g., ignore friction, turbulence, resistance, ...

GranularityE.g., time, distance, size,

Active processesE.g., current flows, heat flows, chemical reactions, ...

Research objective is to develop:Languages for expressing model composition knowledge

"Applicability" conditions for model fragmentsModel composition rules and heuristics

Model composition methods that effectively use the knowledge

Context Driven Model Formulation

Primary Investigator: Pandu Nayak

" Objective: Build an adequate model for a given task

Key idea:Adequatecomponent models are determined by the context inwhich they operate

Example: Model a metallic pipe as -A physical support if it is part of the superstructure of a towerA flow channel if it is connected to a water tankAn electrical conductor if it is connected to a battery

17 Knowledge SystemsLaboratory, Stanford University

18 Knowledge Systems Laboratory, Stanford University

Example Model Formulation Rules

Structural context of a component

" Electrical conductors must be metallic

" If a wire is connected to a voltage source,Then model the wire as a electrical conductor

If a terminal is connected to a voltage terminal,Then model the terminal as a voltage terminal

Behavioral context of a componentIf a metallic pipe is acted on by a strong transverse force,

Then model the pipe as a deformable bodyIf the voltage drop across a wire exceeds a threshold

Then model the wire as a resistorIf the electrical power loss in a resistor exceeds a threshold,

Then model the resistor as a thermal resistor

22

Summary

Project objectives --Develop technologyfor an "engineer's associate"

Multi-use representations of engineering knowledgeReasoning methods to perform core engineering tasks

Focus is on behavior analysis of preliminary designs

" Designer describes design

" Device, operating environment, functional specificationsSystem composes behavior model appropriate for the testSystem generates simulation model of deviceSystem guides simulator to scenarios relevant to specificationsSystem provides causal explanations of simulated behaviorSystem determines whether behavior satisfies specifications

Presents constraints which design needs to satisfy specifications

Knowledge SystemsLaboratory, Stanford University

top related