+ All Categories
Home > Documents > Chapter 5

Chapter 5

Date post: 12-Jan-2016
Category:
Upload: sibyl
View: 17 times
Download: 0 times
Share this document with a friend
Description:
Chapter 5. Knowledge Management. Additional Recommended Literature. Staab, S., Studer, R. (Eds.): Handbook on Ontologies Springer Verlag 2003. Series - PowerPoint PPT Presentation
68
Prof.Dr. Michael M Richter Process Modeling Calgary 2004 Chapter 5 Knowledge Management
Transcript
Page 1: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Chapter 5

Knowledge Management

Page 2: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Additional Recommended Literature

• Staab, S., Studer, R. (Eds.): Handbook on Ontologies Springer Verlag 2003. Series

• v. Elst, L; Dignum, V., Abecker, A. (Eds.): Agent Mediated Knowledge Management. International Symposium AMKM 2003, Stanford, CA, USA, March 24-26, 2003, Revised and Invited Papers. , Vol.  2926, Springer Verlag 2004. F. Maurer, H. Holz: Process-oriented Knowledge Management for Learning Software Organizations, Proceedings KAW-99, Banff, Canada, 1999

• Harald Holz: Process-Based Knowledge Management Support for Software Engineering, Dxissertation Kaiserslautern, 2002 (see also his web page).

Page 3: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Part 1

General Principles

Page 4: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Collection• Knowledge Acquisition• Call management• Documents

Discovery• Email, chat, forums,

feedback, surveys • Data mining

OrganizationDatabases, Knowledge

bases, Directories

Access• Retrieval (Text, CBR, ES)• Process Oriented (Policies

& procedures, DSS, ES)

Collaboration & Sharing• Internet, Intranet• Groupware

Aspects of Knowledge Management

Informing agents-on demand, pro-active

Page 5: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Knowledge Management The knowledge manager (KM) employs several information assistants A who again assist other agents Ag who perform certain actions. This has a global and a local aspect:Global view:Organization

KM

A

AA

A

. . . . . . . . . . .

Ag

Ag

Local view: Communication

Agent1 Agent2

Page 6: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

general process

general knowledge actual data andinformation

actual process

Knowledge and Processes

instance

needs needs

Page 7: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Flow of Knowledge

Data

Information

Knowledge

Data Bases Knowledge Base

Actions

Flow from external sources

restructure

make explicit

use

Page 8: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Information and Processes

Step in the general process (process model)

Corresponding steps in the actual projects

Information Source Information Source Information Source

The manager organizes the necessary sources

Instantiation

details

Information improves the value of actions at all levels:

Page 9: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Purpose of Information and Knowledge

• The purpose of knowledge and information is to perform process steps or to perform them better. This is called an INFO-NEED for the process step.

• INFO-NEEDS are stored in INFO-SOURCES. • However:• Knowledge can be missing• Knowledge Management tasks:

– Get external or internal knowledge, make it explicit and restructure it

– Distribute knowledge to agents who need it at the right time in the right format in the needed quality

– Draw correct conclusions from customer information

Page 10: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Information Sources

• News• Mailing Lists• FAQs• Web Sites (tool vendors,…)• Online Reference Books• DMS• Lessons Learned• Experience Factory• Project Traces• Bug Tracking Systems• …

‘Experts’…

Information distribution: Task- and situation-

specific Proactive Systematic

Problem:

Software Development

Info Needs

Info Needs

Page 11: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Info Needs

• Info Needs can be attached to processes in – A very general knowledge model– A process model– A plan

• In a plan the information need can only be used for that specific plan instance, on the higher levels it can be used for all plan instances.

• A special case is to represent the information need by a bookmark. Then no further reference to the information source is necessary

Page 12: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Task-specific Information Needs Example (1)

available actors?

qualified actors? admissible

actors?

p p’

Who performed similar tasks? Effort of

similar tasks?

Problems with

similar tasks?

Similar Design Docs?

Def. of Factory-Pattern?

Guidelines/checklists?

Who has designed

RMI applicationsbefore?

Problems with RMI

and Serializatio

n?

Former Review Docs for similar

designs?

Design Review

DesignDoc

ReviewDoc

Enactment:

Assign task Design Review

Planning:

Page 13: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example (2)

Where do I find tutorials on EJB?Description

programmer programmer is an EJB novice

For whom?

How toobtain

information?

java_tech_docs_infoNeed …

MoreInformation

Needs?

Implementation Process System design is based on EJB

When?

information need ejb_tutorial_infoNeed question

process type activity constraints

useful for roles

skill constraints

information source usage recommendations

sub information needs

Page 14: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example (3)

sun_javasoft_domain

Which informations

source?

none

programmer

none

Suitable for whom?

Search for phrases "EJB" and "Tutorial" search(?keywords="EJB"+"Tutorial")

Query to the informations

information source usage recommendation information source recommendation

information source

activity constraints

useful for roles

skill constraints

usage directionscomment

queryCommand

end

Page 15: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Retrieval of INOs

Task “System Design”

RationalRose

uses_tool

UMLis_tool_for

INODesign

INORationalRose INOUML

e.g.“UML Specification?”

e.g.“Who performed similar design tasks before?”

e.g.“How do I load JDK 1.2 into RR?”

Domain model entities play a role for both organization and retrieval.

Page 16: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Information Need as Object

• Attributes for specification of context- and search space

Representation

Information Source

Query

Supported Role

Information Category

Precondition

Which error reports are assigned to Harald in project MILOS?

Executer

General

BugZilla System

?system=MILOS&name=Harald

Implementation.isRestarted()

Process step:Implementation

Information Need

Page 17: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Meta Knowledge

• Talks about knowledge management, e.g.:• Collect for each process type :

– Which information is useful for the participating? – When? (depends on roles, specific situations,...)– Where can one find such informationen?– How should they be represented?

We need:

Information sources recommenrdations for

information sources Information needs ...

Page 18: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Organizing Meta Knowledge (1)

• Primarily by process types.• Problem:

Handling of spezialization/decomposition?• Ex.:

Testing

Glass-BoxTesting

What tools areavailable for testing?

Black-BoxTesting

What tools areavailable for black-box testing?

How should I report bugs?

Overview of Testing Techniques? <in

<in

Allow information needs to be specialized

Approach: Inheritance of information needs

Page 19: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Organizing Meta Knowledge (2)

• Observation: Certain information needs occur in several process types, depending on the used technologies, concepts, products, etc.

• Problem: Redundant definition make maintenance more difficult Approach: Association of information needs and domain model entities

Info Source Recommendation:GoF Design Pattern Catalogue

Info Source Recommendation:‘Patterns in Java’ Catalogue

<isr

How do I launch RationalRose?

Tool Language

RationalRose

JDK 1.2 ModelingLanguage

OO-ProgrammingLanguage

JavaST-80UML SDL

…CS Thing

Page 20: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Organizing Domain Entities (1)• Interpretation:

– The Meta Knowledge associated with some model element is only activated, if the element (or an instanzce of it) is referenced.

– Can be regulated by constraints

• Transitivity of activation:

activity of type“Design”

tool“RationalRose”

uses_tool

language“UML”is_tool_for

InfoNeedsUML

e.g.“UML Specification?”

InfoNeedsDesign

e.g.“Who performed similar design tasks before?”

InfoNeedsRationalRose

e.g.“How do I load JDK 1.2 into RR?”

Page 21: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Question: Associate with process type or domain entity?

Organizing Domain Entities (2)

• Heuristics:– as a default with a process type.– Possibly changed by constraints

JUnit

Implement Test Cases

tool : JavaTestingTool

JavaTestingTool

TestMentor

tool is JUnit

tool isTestMentor

IN3.1

IN3.2

IN2.1

IN2.2

…tool isJavaTestingTool

IN1.1 IN1.2 …

Page 22: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Organizing Domain Entities

JUnit

Implement Test Cases

tool : JavaTestingTool

JavaTestingTool

TestMentor

tool is JUnit

tool isTestMentor

IN3.1

IN3.2

IN2.1

IN2.2

…tool isJavaTestingTool

IN1.1 IN1.2 …

Heuristics

JUnit

Implement Test Cases

tool : JavaTestingTool

JavaTestingTool

TestMentor

IN1.1

IN1.2

IN3.1

IN3.2…

IN2.1

IN2.2

Page 23: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Conceptual ViewInformation

IN1

IN2

INn

IS1

IS2

ISm

ContextContext

Development process

Information Sources

Page 24: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Information Assistant (1) • The information assistant is integrated to the enactment

environment.

• Functionality:

– actively signals possible knowledge delivery support,

– presents a structured set of currently relevant INOs after he is started on demand,

– allows to execute the retrieval specified by a selected INO,– allows to access a query interface of an information source

specified by a selected INO, and– allows a user to post queries to be persistently stored.

Page 25: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Information Assistant (2)

• The information assistant can act– on demand– pro-active

• Acting on demand requires a query. – Example: Asking for an explanation

• Acting pro-actively requires a trigger, usually an event in order to apply an ECA-Rule.– Example: The information assistant is notified that an agent

is working on a specific task that requires certain knowledge.

Page 26: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example (1)

• Scenario 1: A programmer has to estimate the time for the implementation of a Java component based on a given class diagram.

• Information provided:– a) coding speed in classes per time unit. – b) the number of classes within the input product „Class

Diagram“.

• The corresponding information sources are:– data base storing agent performance data– input product.

Page 27: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example (2)

• Scenario 2: A project manager has to dcecide which programming language to use for implementing an object oriented design.

• Information provided:– Available methods for implementation (from the process

definition and a methodology data base)– functional and quality requirements (from a requirements

document)– available experienced agents (from a skill data base)– available tools (from a tool data base).

• Some of these sources will be stored in the experience factory.

Page 28: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Information Assistant (3)

• The knowledge manager knows the process model PM

• To each action in the model it is associated:– the agents involved – the type of knowledge or information needed

• The needed knowledge is divided into– some knowledge which the agents surely do not not have

(e.g. because only the manager has it so far)– knowledge which some agents may have and others not

(depending e.g. on the experience of the agents); here some knowledge of the manager about the agents is required.

Page 29: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Extended Process Model

InformationResource

IS RecommendationInformation

SourceRecurrent

Information Need

IS Usage Recommendation

info source

Object WithInfo Resources

(Interface)

0..n

0..n

info source usage recommendation

0..n

sub-information needs

commentqueryCommand

executeQuery()

Page 30: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

An Integrated View

Process ModelProject Plan Workflow

Process Modellingenvironment

Project Planningenvironment

Workflowenvironment

InformationAssistant

Informationsources

Enriched

Page 31: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Part 2

Ontologies

Page 32: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Ontologies and Knowledge Management

• In order to provide knowledge support for agents one first has to collect and to restructure knowledge.

• The restructuring has to be done in such a way that all agents participating in the process (or all members of a team/company) can be supported in an efficient way.

• The knowledge comes usually from different sources that have different representation formats as well as a different semantics for the used terms.

• The idea of an ontology is to collect, combine and restructure such knowledge.

Page 33: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Characteristics “An ontology is a formal, explicit specification of a shared conceptualization”

• An ontology is:

– formal: is machine understandable (therefore we need formal languages!)

– explicit specification: contains explicitly defined concepts, properties, relations, functions, constraints, axioms, ...

– shared: represents consensual knowledge of a community

– conceptualization: abstract model of some phenomenon in the world

• Difficulties: Some knowledge may not be (easily) formulated in a formal ontology.

Page 34: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Database Schema & OO Models• Conceptual database schema (e.g. ER diagrams) and OO

models (e.g. UML analysis diagrams) allow the formal specification of a conceptualization.

• ER and UML differ in the modeling primitives• Relation to Ontology definition:

– formal? : YES can be encoded in machine readable form– explicit specification: YES: modeling primitives have a clear semantics– shared? : Not per se – conceptualization? : YES abstract model containing important concepts.

• If shared, they can become an ontology!

Page 35: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Part of an Ontology: Glossary• A Glossary is:

– A collection of terms (e.g. given at the end of a book) – Each term has a textual definition– The definition may contain links to other terms

• Example Glossary for UML (OMG-Unified Modeling Language, v1.4)aggregation: A special form of association that specifies a whole-part relationship between

the aggregate (whole) and a component (part). See: composition.association: The semantic relationship between two or more classifiers that specifies

connections among their instances.analysis: The part of the software development process whose primary purpose is to

formulate a model of the problem domain. Analysis focuses on what to do, design focuses on how to do it. Contrast: design.

• Relation to Ontology definition:– formal? : NO, definitions not machine understandable– explicit specification? : NO not formal, links can be “semi-formal”– shared? : YES, goal is to share it among the readers/users of the book.– conceptualization? : YES abstract model containing important concepts.

Page 36: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Part of an Ontology: Thesaurus• A Thesaurus is:

– A collection of words with semantic relations among them– different meanings of words are mentioned– classification w.r.t. syntactic categories – sometimes with explanations of meanings of words

• Example: Wordnet http://www.cogsci.princeton.edu/~wn/

– 118.000 word forms, 90.000 word meanings, – syntactic categories: noun, verb, adjective, adverb, preposition, ...– semantic relations: hyperonym/hyponym (=is-a), meronym/holonym (has-

part(part-of), synonym, antonym, ...

• Relation to Ontology definition:

– formal? : Partially, meaning not machine understandable

– explicit specification: PARTIALLY formal relations

– shared? : YES; at least this is claimed.

– conceptualization? : YES abstract model containing important concepts.

Page 37: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Types of Ontologies• Ontologies can talk about different issues:

top-level ontology

domain ontology task ontology

application ontology

Page 38: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Structure of Ontologies

Entries of an ontology are usually structured in a directed graph which is often a tree:

.

.

...

The nodes areannotated with the concept or thetheir instances.The semantics of thecan be of different character.

Page 39: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Components

• Many objects can be regarded as a composition of simpler parts called components. Component orientation means that the component structure is the dominating view.

• Top-down view: Decomposition of a complex object• Bottom-up view: Synthesis of complex object.• Objects which have no parts are called atomic.• In top-down planning complex tasks are decomposed

into simpler parts.• This gives rise to the part-of relation.

Page 40: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Part-of Relation• With the part-of relation one can associate different

meanings and intentions: – A is a mandatory part of B– A is an optional part of B– A is an important part of B– A is a part of B which can be exchanged– A is an expensive part of B– A is a visible part of B– etc.

• These variations give rise to different uses and applications.

Page 41: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Is-a Relation (1)

• The most common interpretation of “A is-a B” is that the subset interpretation: A B where A and B are sets.

• This justifies the use inheritance operations as e.g. in object oriented programming languages.

• “is-a” is, however, often in less clear circumstances used, e.g.:– mechanical engineering is-a engineering science

• It is not clear to which sets the terms refer:– The persons working in each science ?– The employees of the university departments ?– The scientific papers ?

Page 42: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The Is-a Relation (2)

• The reason is that the instances are not defined here. If we have the instance concept defined each object can be regarded as the set of its instances. But again one has to be careful if inherited properties can be overwritten.

• The deeper problem arising here is connected with the extensional and intensional interpretation of concepts:– The extensional interpretation represents a concept C fully by a

set of elements (or members or instances). All what one has to know about C is in principle only the set of elements of C.

– The intensional interpretation associates with C everything what one can do with C. This can be made precise in different ways; it is, however, not in the scope of this lecture.

Page 43: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Is-Hierarchy: Example

• Example:

• Some of the edges denote subclasses and some denote instances

Graphics Card

S3 Graphics Card MGA Graphics Card

ELSA 2000 Stealth 3D200 Miro Video

Matrox Mill. 220 Matrox Mystique220

VGA V64

S3 Virge Card S3 Trio Card

Page 44: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Multiple Use of Ontologies• The idea of using one ontology for different purposes

has several consequences:– How to interpret the concepts of an ontology in different

situations ?

– How to translate the concepts of an ontology into different representations of an application ?

– How to select the knowledge for some application ?

• The last questions require domain knowledge. The first two questions deal with formalisms and their syntactic properties. This is discussed in the chapter on predicate logic.

• Ontologies can be re-used for different projects.• A proper reuse is the task of the experience factory.

Page 45: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Reuse of Ontologies (1)

• A translation between ontologies makes the reuse of ontologies within the same representation language possible.

• Example (for predicate logic):

• Told is supposed to be an ontology for the organization of personell with a predicate vacation(space, location) (shall express: when and where) with corresponding regulations. Furthermore let Lnew be a language with the predicate holidays(time). A suitable translation is

(holidays(x)) = y(vacation(x,y))

• The knowledge base of Told can now be reused.

Page 46: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Reuse of Ontologies (2)

• For different logical languages, e.g. differently represented fragments of predicate logic it is necessary to – understand the expressions of one language

syntactically in the other language• or

– to understand the expressions of both languages in a third language (exchange format).

• The condition in order to achieve this is that the expressions are not ambigious.

Page 47: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Car seatspecification

GermanyCanadaUSAMexico

Different safetyregulation

Example: Different Interpretation of Legal Terms

Investingmoney

GermanyBahamasHongkongUSA

Different taxregulations

Requires always a flexible interpretation

Page 48: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Different Ontologies for a Common Goal

• Knowledge can be distributed over different ontologies :• Different experts see and describe the world from different views;

they have their own knowledge stored in different ontologies:– Financial experts, environment experts, regional experts (in

particular in global distribution), technical experts (again many possibilities) .....

• Each expert talks and thinks about the same real world objects– in different terminologies– in different degrees of abstraction– in different form of details

• In order to make use of such distributed knowledge a principal problem of communication arises (see chapter on Predicate Logic).

• Some part of the problem can be solved by using normed terminologies

Page 49: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Comparison of Ontologies (1)

Li :: Representation languageOntolologyi: Ontology in Li Expresssioni: Expression in Li

i = 1,2

Expression1Ontolology1 Expression2Ontolology2

This side isknown to me

How to translateit to this side ?

Page 50: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Comparison of Ontologies (2)

• Under which conditions are two expressions in different ontologies equivalent and how can this be tested ? What is the meaning of equivalence of ontologies ?

• How can one find for a given expression in one ontology some equivalent expression in another ontology (translation problem) ?

• Are there universal languages to compare arbitrary ontologies (exchange formats) ?

• The mapping of two expressions onto an expression in an exchange format which is equivalent to the given expressions is called semantic unification (analogous to syntactic unification defined for substitutions).

Page 51: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Concept• name• extension• intension• sim• description• purpose• intended user(s)• assertion/ precondition

Constructs for SE-Ontologies:

Types of terminal concept attributes• name• supertype• value range• unit• sim

Kinds of Nonterminal Concept Attributes• name• reverse name• purpose• structure• properties

Terminal Concept Attributes• name• description• cardinality• type• default value• mandatory• value inference• inferred attributes• standard weight

Nonterminal Concept Attributes• kind• destination concept• ...

Instances• name• concept• values

Formula for• value inference• assertion/precondition• concept similarity• type similarity

Page 52: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example for Conceptual Knowledge

Concept:• Name: Project• Intension: { , ...}• Description: characterizes a

specific software project• Purpose: explicitly states the

organizational context from which the experience originates (modeling)

• Intended user(s): project supporter, project member, project manager

Terminal Concept Attribute:

Name: team sizeDescription: number of project team

members allocated to the projectCardinality: 1Type:...

Type:Name: PeopleNumberSupertype: CardinalValue Range: 1..100Similarity: sim(i, q)=1 –

|i – q|99

Page 53: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Maintenance: Knowledge Gaps

• Knowledge is usually incomplete in complex situations.• A knowledge gap can mean: Some knowledge entry is simply missing or

(worse) incorrectly stated.• Knowledge gaps occur dynamically due to a changing context.• To deal with knowledge gaps is a major task for knowledge acquisition and

knowledge management• How to characterize knowledge gaps ?• They can occur when knowledge is

– simply missing– in principle present but not (sufficiently easy) accessible– not or not sufficiently well understood– not adequately presented– out of date– Incorrectly stated

Page 54: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Indicators for Knowledge Gaps (1)• Knowledge gaps usually do not say on their own

initiative: Look at me, I am a gap! • Whether a gap can be realized by the agent who carries

out a certain activity depends on– the situation– the experience of the agent

• If e.g. some action requires the value of some parameter and the agent knows this fact then it is easy to realize that this value is missing and the agent can send a corresponding query.

• In such situations we have direct indicators for gaps.• In many situations, however, there are only indirect

indicators for the gaps.

Page 55: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Indicators for Knowledge Gaps (2)• Indirect indicators for knowledge gaps are:

• Actions which insufficiently well performed:– Missing expertise if needed

– Expensive errors, missed opportunities

• Changes in the context and in the environment:– New products, aging products

– New technologies, aging technologies

– New customers and business partners with new interests

– Changes in organization and management

– Changes in the general opinion and taste

• Some of such changes occur at once, others continuously.

Page 56: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Dynamic and Maintenance

• Knowledge gaps have a dynamic character– They can occur continuously– They are not anounced and often not recognized– They will slowly lead to low quality in every respect

• Requirements for knowledge maintenance :– Has to be a coninuous process– Has to include a control function– Has to be correlated with all parts of the management

Page 57: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

HTML – XML – XML-based Ontologies (1)

• Examples of web-ontology languages– SHOE (Simple HTML Ontology Extension, University of Maryland,

Hendler): Uses in addition to HTML new tags for defining ontologies. Has an inheritence concept and allows rules of inference. Web pages can be annotated in order to extract information.

– OML (Ontology Mark-up Language, Washington State Univ., Kent): It is an extension of SHOE and is based on conceptual graphs.

– XOL (XML based Ontology Exchange Language, SRI, P. Karp): Allows to specify T-boxes and A-boxes. The semantics is based Open Knowledge Base Connectivity (http://www.ai.sri.com/~okbc/ )

Page 58: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

HTML – XML – XML-based Ontologies (2)

DAML (Darpa Agent Mark-up Language): DAML-ONT is written in RDF (which is coded in XML and uses XML name spaces). Has many features like allowing synonyms, cardinalities, multiple inheritance.

OIL (Ontology Interface Language): Extends frame languages (OKBC) by terminological logics and web languages (XML, RDF). For OIL there is a DTD and an XML schema.

ONTOBROKER (AIFB/University of Karlsruhe & Ontoprise GmbH,

http://www.aifb.uni-karlsruhe.de/Forschungsgruppen/WBS

http://www.ontoprise.de)

Page 59: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

HTML – XML – XML-based Ontologies (2)

DAML (Darpa Agent Mark-up Language): DAML-ONT is written in RDF (which is coded in XML and uses XML name spaces). Has many features like allowing synonyms, cardinalities, multiple inheritance.

OIL (Ontology Interface Language): Extends frame languages (OKBC) by terminological logics and web languages (XML, RDF). For OIL there is a DTD and an XML schema.

ONTOBROKER (AIFB/University of Karlsruhe & Ontoprise GmbH,

http://www.aifb.uni-karlsruhe.de/Forschungsgruppen/WBS

http://www.ontoprise.de)

Page 60: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Annotated HTML Pages<html><head><TITLE> Richard Benjamins </TITLE><a onto=“page:Researcher“> </a> </head>

<H1> <A HREF=“pictures/id-rich.gif“> <IMG align=middle SRC=“pictures/richard.gif“></A><a onto=“page[photo=href]“ HREF=“http://www.iiia.csic.es/~richard/pictures/richard.gif“ ></a>

<a onto=“page[firstName=body]“>Richard</a><a onto=“page[lastName=body]“>Benjamins </a> </h1> <p>

<A onto=“page[affiliation=body]“ HREF=“#card“> Artificial Intelligence Research Institute (IIIA)</A> - <a href=“http://www.csic.es/“>CSIC</a>, Barcelona, Spain <br>and <br><A onto=“page[affiliation=body]“ HREF=“http://www.swi.psy.uva.nl/“>Dept. of Social Science Informatics (SWI)</A> -<A HREF=“http://www.uva.nl/uva/english/“>UvA</A>, Amsterdam, the Netherlands

Page 61: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

RDF (Resource Description Framework)

• RDF is an alternative to XML• RDF has two parts:

– The RDF syntax (different syntaxes from XML)– An RDF model described as a set of triples

• The purpose of RDF is to define vocabularies (simple terminologies)

• It is machine readable• It is of interest for digital libraries and e-commerce

Page 62: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

The RDF Data Model

• The data model has – Resources:

• A resource is an object that can be referenced• Resources have an URI• RDF definitions are again resources

– Properties• Slots define relations to other resources or atomic values

– Statements• Values can be resources or atomic XML - data

Page 63: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

RDF Data Model• Resource:

– A resource is an information object (most likely in the Web) that is described by meta data

– A resource is referenced by a Universal Resource Identifier (URI)• E.g. a URL is a special kind of URI• URIs can point to parts of a document

• Properties:– A resource is described by a property with a value– A property is a binary relation between a resource and a value– A property is also a special kind of resource

• Literals:– Literals are strings that stand for themselves– Can be used as values for properties

• Statements:– One meta data description item for a resource– Statement is a triple: (Resource, Property, Value)

• Value can be a Resource or a Literal

Page 64: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

RDF / RDF SchemaRDF = Resource Description Framework (from W3C)• Purpose: Description of Resources (e.g. Web documents)

in a relational manner• Consists of:

– RDF Data Model (Resources has Property with value)– RDF Syntax: representing a RDF Data Model as XML document

RDF Schema:• Purpose: Vocabulary Definition Language (e.g. for an

ontology)• Can itself be described in RDF• Description like OO, but “property centric“ representation

Page 65: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

RDF Schema• Vocabulary definition language (for RDF) and in RDF• Can be used to encode an ontology• Main components: special kinds of resources and

properties are introduced:– rdfs:Resource : everything described is a rdfs:resource– rdfs:Class : Meta Class, i.e. a class whose instances are classes

themselves– rdf:Property : a special kind of resource to describe properties

rdf:type : a property that represents the instance-of relation– rdfs:subclassOf : a property that represents the is-a relation– rdfs:domain : domain (left side) of a property– rdfs:range : range (right side) of a property

Page 66: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Example using RDF Schema

ontology

documentmeta data

Page 67: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

Document Meta Data in XML

<rdf:RDF><rdf:Description about=“http:/.../Proposal/“> <rdf:type rdf:resource=“eg:Document“ />

<eg:author> <rdf:Description>

<rdf:type rdf:resource=“eg:Person“ /><eg:name>Tim Berners-Lee</eg:name >

</rdf:Description></eg:author><dc:title> Information Management: A Proposal </dc:title>

</rdf:Description></rdf:RDF>

Page 68: Chapter 5

Prof.Dr. Michael M RichterProcess ModelingCalgary 2004

• A larger example ontology (“music_ontology”) find on an excel sheet.


Recommended