Knowledge Modeling and
Management
M1 2011-2012
Objectives for this session
History & theory of Knowledge
Management (KM)
 KM models
 Ontology and its design methodology.
 OWL.

What is Knowledge Modeling?


Knowledge modeling is a process of
creating a standard and computer
interpretable specifications of a given
domain knowledge.
Computer interpretable: it is expressed in
some knowledge representation language
that enables the knowledge to be
interpreted by software and to be stored.
Seek knowledge from the
cradle to the grave

Expertise, and skills acquired by a person
through experience or education; The
theoretical or practical understanding of a
subject:
 Knowing
that.
 Knowing how.
What is Knowledge?
It originates from the minds of knowers.
 In organizations it often becomes
embedded in documents, repositories,
organizational processes, practices and
norms. Davenport, T.H. & Prusak, L (1998). Working Knowledge.
 Knowledge is information in action. O’Dell C. &

Grayson Jr., C.J. (1998). If only we knew what we know.
Two types of knowledge
Know-how & learning
embedded within the minds
people.
Documented information
that can facilitate action.
Explicit knowledge

Formal or codified
 Documents: reports, policy
manuals, white papers,
standard procedures
 Databases
 Books, magazines, journals
(library)
Implicit (Tacit) knowledge




Informal and uncodified
Values, perspectives &
culture
Knowledge in heads
Memories of staff, suppliers
and vendors
Knowledge supports decisions and actions.
Sources: Polanyi, M. (1967). The tacit dimension. Leonard, D. & Sensiper, S. (1998). The Role of Tacit Knowledge in Group
Innovation. California Management Review.
Layers of knowledge
Explicit
Implicit (Tacit)
In people’s heads.
Individual
Personal documents
on my C:\
• Undocumented ways
• Formalized process.
of working.
• Cultural, conventions Organizational
• Corporate polices and
known and followed
procedures.
but not formalized.
Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented
at Annual AIR Forum, Toronto.
One Perspective of KM

“Knowledge Management involves
turning a company’s information into
actionable knowledge via a technology
platform.”
Susan DiMattia and Norman Oder in Library Journal,
September 15, 1997.
Understanding KM
Wisdom
Knowledge
Information
Data
From Facts to Wisdom
Knowledge Management Models
 Documentalist?
 Technologist?
 Learner
& Communicator?
Documentalists

In the first part of the twentieth
century, documentalists had grand
visions of collecting, codifying and
organizing the knowledge in form of
structural linguistics and semiotics.”.
Caution
 It
would be a mistake, though,
to define KM as solely the
domain of documents and
documentalists.
KM as a Technological Solution

KM is:
Big business.
A competitive advantage.
Intellectual capital.
An intranet solution.
An asset dimension.
A technological infrastructure.
Content nets
KM applications
As knowledge repositories for tacit
knowledge that has been made explicit
 For best practices databases or expert
“yellow pages”
 Online learning and knowledge sharing
 Knowledge sharing “boards”

The Challenges of Collaboration &
Knowledge Sharing


“Focusing exclusively on the technical issues of
knowledge sharing is a vey good way to a very
expensive failure.”
“A focus on the people issues dramatically increases
the potential for success.”
David Coleman, IBM Manager, San Francisco in Knowledge
Management, a Real Business Guide, London:IBM, nd.
Peoplenets & Processnets






For group learning applications
To connect individuals with each other for mentoring
and knowledge sharing
For decision support & decision making
To sense, share, and respond to the “signals” coming
from the environment
To capture ideas and turn them into action.
The eventual goal is to share knowledge
among members of the organization.
Caution
 It
would be a mistake, though,
to define KM as solely the KM’s
technology infrastructure.
Is it a mistake?
 “Processing
data can be
performed by machine, but only
the human mind can process
knowledge”!!!!
Jesse Shera in Machlup and Mansfield’s
The Study of Information: Interdisciplinary
Messages. NY: Wiley, 1983.
How to represent the knowledge

Links and structures

Notation

Ontology.
What is an Ontology?
•A written, formal description of a set of concepts and
relationships in a domain of interest. (Peter Karp (2000)
Bioinformatics).
• It is a formal explicit description of concepts in a domain,
properties of each concept describing various features and
attributes of the concept (slots (sometimes called roles
or properties)), and restrictions on slots (facets
(sometimes called role restrictions)).
• An ontology together with a set of individual instances
of classes constitutes a knowledge base.
• In reality, there is a fine line where the ontology ends and
the knowledge base begins.
Ontology is a system of concepts
Knowledge
Base
Ontology
An explicit specification of
a hidden conceptualization
of the target domain
The fundamental role of an ontology



An ontology is not directly used for problem
solving.
It gives a specification of knowledge/models in
a system.
The role of an ontology to a knowledge base is
to give definitions of concepts used in the
knowledge representation and constraints
among concepts
 to
make the knowledge base consistent and
transparent.

Knowledge Amplifier systems.
Why?
To share common understanding of the
structure of information among people or
software agents.
 Enabling reuse of domain knowledge.
 Making explicit domain assumptions
underlying an implementation.
 Separating the domain knowledge from the
operational knowledge is another common
use of ontologies.
 BI: analyzing domain knowledge.

Knowledge Eng. VS. Ontological
Eng.

KE is the research on:
 Domain-specific
heuristics for a standalone problem solver (AI).

OE is the research on:
 General/reusable/sharable/long-lasting
concepts for building a KB/model for
helping people solve problems.
Ontology types

Light-weight Ontology
 One
like Yahoo ontology
 Vocabulary rather than concepts
 Annotation-oriented ontology
 Used for Information search

Heavy-weight Ontology (,
 Koru,
Wolfram Alpha.
 Concepts rather than vocabulary
 for understanding the target world
 for building Knowledge-Based systems.
Know that Ontologies’
Design principles
Building Ontologies

In practical terms, developing an ontology
includes:
 defining
classes in the ontology,
 arranging the classes in a taxonomic
(subclass–superclass) hierarchy,
 defining slots and describing allowed values
for these slots,
 filling in the values for slots for instances.
Fundamental rules
There is no one correct way to model a
domain— there are always viable
alternatives.
 The best solution depends on the
application that you have in mind and the
extensions that you anticipate.

Fundamental rules
Ontology development is iterative.
 Concepts in the ontology are: objects and
relationships in a domain of interest.
 Objects are most likely to be nouns, the
relationships are verbs in sentences that
describe your domain.

Step 1. Determine the domain and
scope of the ontology
What is the domain that the ontology will
cover?
 For what we are going to use the ontology?
 For what types of questions the information
in the ontology should provide answers?
 Who will use and maintain the ontology?

Example





Consider an ontology which helps representing the
best combination (wine/ food).
Representation of food and wines is the domain of
the ontology.
We plan to use this ontology for the applications that
suggest good combinations of wines and food.
It is unlikely that the ontology will include concepts for
managing inventory in a winery or employees in a
restaurant.
If it helps restaurant customers decide which wine to
order, we need to include retail-pricing information.
Step 1 Example

Competency question
 Which
wine characteristics I consider when
choosing a wine?
 Is Bordeaux a red or white wine?
 Does it go well with seafood?
 What is the best choice of wine for grilled meat?
 Which characteristics of a wine affect its
appropriateness for a dish?
 Does a bouquet or body of a specific wine change
with vintage year?
Step 2. Consider reusing
existing ontologies

Sure, if they exist!!!
Step 3. Enumerate important
terms in the ontology




What are the terms we would like to talk about?
 wine, grape, winery, location, fish and red meat;
 subtypes of wine such as white wine, and so.
What properties do those terms have?
 a wine’s color, body, flavor and sugar content;
What would we like to say about those terms?
Constitute a list of terms without worrying about overlap
between concepts, relations among the terms, or whether
the concepts are classes or slots.
Step 4. Define the classes and the
class hierarchy

Methods
 Top-down: start with the most general
concepts in the domain and then their
domain and sub-classes.

For example creating classes for the general
concepts of Wine and Food. Then we
specialize the Wine class by creating some of
its subclasses: White wine, Red wine, Rosé
wine.
Step 4. Define the classes and
the class hierarchy
Bottom-up: starts with the most specific
classes, the leaves of the hierarchy, with
grouping of these classes into more general
concepts.
 Combination: it is a combination of the topdown and bottom-up approaches: We define
the more salient concepts first and then
generalize and specialize them appropriately.
Step 4. Define the classes and
the class hierarchy

Top-down
 Food
and Wine -- followed by White, Blush and
Red

Bottom-up
 define
specific wine class first and the work your
way up

Combination
Step 4. Define the classes and
the class hierarchy



From the list we select the terms that describe
objects having independent existence rather than
terms that describe these objects. These terms will
be classes in the ontology.
We organize the classes into a hierarchical taxonomy
by asking if by being an instance of one class, the
object will be by definition an instance of some other
classes.
A super class of B means that class B represents a
concept that is a “kind of” A.”
Step 5. Define the properties
of classes—slots

Types of properties
 “intrinsic”
properties such as the flavor of a wine;
 “extrinsic” properties such as a wine’s name,
 parts, if the object is structured; these can be both
physical and abstract “parts” (e.g., the courses of a
meal)
 relationships to other individuals; these are the
relationships between individual members of the class
and other items.
Step 5. Define the properties
of classes—slots




We have already selected classes from the list of terms we
created in step3. Most of the remaining terms are likely to be
properties of these classes.
For each property in the list, we must determine which class
it describes.
Describe the internal structure of concepts.
Examples
 a wine’s
 color,
 body,
 flavor
 sugar content
 location of a winery.
Completing slots

In addition to the properties we have identified
earlier, we need to add the following slots to the
Wine class: name, area, maker, grape.
Inheritance


All subclasses of a class inherit the slot of that class.
For example, all the slots of the class Wine will be
inherited to the subclasses Red Wine and White
Wine.
We will add an additional slot, tannin level (low,
moderate, or high), to the Red Wine class.
 The
tannin level slot will be inherited by all the classes
representing red wines (such as Bordeaux and Beaujolais).
Step 6. Define the facets of the slots


Slot cardinality
 defines how many values a slot can have.
 sometimes it may be useful to set the maximum
cardinality to 0 (why?)
Slot-value type
 what types of values can fill in the slot.
 allowed

values
other features of the values the slot can take.
Step 6. Define the facets of
the slots
 common
value types:
 String
 Number
 Boolean
 Enumerated
 Domain-range (instance- type) slots allow
definition of relationships between individuals.
Step 6 - Domain and Ranges




When defining a domain or a range for a slot, find the most
general classes or class that can be respectively the domain or
the range for the slots .
If a list of classes defining a range or a domain of a slot
includes a class and its subclass, remove the subclass.
If a list of classes defining a range or a domain of a slot
contains all subclasses of a class A, but not the class A itself,
the range should contain only the class A and not the
subclasses.
If a list of classes defining a range or a domain of a slot
contains all but a few subclasses of a class A, consider if the
class A would make a more appropriate range definition.
Step 7 - Creating Instances
Body: Light
 Color: Red
 Flavor: Delicate
 Tannin level: Low
 Grape: Gamay (instance of the Wine grape class)
 Maker: Chateau-Morgon (instance of the Winery
class)
 Region: Beaujolais (instance of the Wine-Region
class)
 Sugar: Dry

DONE??
Consistency/validity/sanity checks
Step 8 - Classes and a class
hierarchy

Ensuring that the class hierarchy is correct
 An “is-a” relation
 A subclass of a class represents a concept that is
a “kind of” the concept that the superclass
represents.
 Restrictions (transitivity, …) of the hierarchical
relations.
 Distinction between classes and their names
(synonyms of concept name do not represent different
classes.)
 Avoid class hierarchy cycles.
 All the siblings in the hierarchy must be at the same
level of generality.
Step 8 - Classes and a class
hierarchy

How many is too many and how few are
too few?
 If
a class has only one direct subclass there
may be a modeling problem or the ontology is
not complete.
 If there are a lot of subclasses for a given
class then additional intermediate categories
may be necessary.
Step 8 - Classes and a class
hierarchy
Multiple Inheritance is possible.
 When do you introduce a new level?

 Subclasses
of a class usually
(1) have additional properties that the super-class
does not have, or
 (2) restrictions different from those of the superclass, or
 (3) participate in different relationships than the
super-classes

Step 8 - Defining classes and a
class hierarchy


A new class or a property value?
 Depends on how important a concept
White Wine is in the domain
An instance or a class?
 starts with deciding what is the lowest level
of granularity in the representation.
 Individual instances are the most specific
concepts represented in a knowledge
base.
Step 8 - Limiting the scope
 The
ontology should not contain all the
possible information about the domain:

you need only to specialize (or generalize) more
than you need for your application at most one
extra level each way.
 The
ontology should not contain all the
possible properties of and distinctions among
classes in the hierarchy.
Details
Inverse slots
 Naming conventions
 Synonyms
 Defaults
 Disjoint subclasses

Next
Choose domain IN WHICH YOU ARE
EXPERT.
 Requirements

 Identify
intended use
 Show all steps mentioned so far…
OWL


OWL, Web Ontology Language, the language
that is aimed to be the standardised and broadly
accepted ontology language of the Semantic
Web.
RDF and RDFS allow the representation of:
 Subclass
and subproperty relationships,
 Domain and range restrictions, and,
 instances of classes.

A number of other features are missing:
OWL vs. RDF





Local scope of properties: rdfs:range defines the range
of a property, say eats, for all classes.
Disjointness of classes: Sometimes we wish to say that
classes are disjoint.
Boolean combinations of classes: Sometimes we wish to
build new classes by combining other classes using
union, intersection and complement.
Cardinality restrictions: Sometimes we wish to place
restrictions on how many distinct values a property may
or must take.
Special characteristics of properties: Sometimes it is
useful to say that a property is transitive.
OWL and RDF

OWL constructors like owl:Class,
owl:DatatypeProperty and owl:ObjectProperty
are all specialisations of their RDF
counterparts.
OWL
owl:Ontology element which contains comments,
version controls and inclusion of other
ontologies.
<owl:imports
rdf:resource="http://www.mydomain.org/persons
"/>
<rdfs:label>University Ontology</rdfs:label>
</owl:Ontology>
 Imports is a transitive property.

Class elements

There are two built-in classes, owl:Thing and
owl:Nothing.


The former contains everything (everything is a thing), the latter
is the empty class.
Classes are defined using a owl:Class element. For
example, we can define a class associateProfessor as
follows:
<owl:Class rdf:ID="associateProfessor">
<rdfs:subClassOf rdf:resource="#academicStaffMember"/>
</owl:Class>
Disjoint and Equivalence
- Equivalence:
<owl:Class rdf:ID="faculty">
<owl:equivalentClass
rdf:resource="#academicStaffMember"/>
</owl:Class>
- Disjoint:
<owl:Class rdf:about="associateProfessor">
<owl:disjointWith rdf:resource="#professor"/>
<owl:disjointWith rdf:resource="#assistantProfessor"/>
</owl:Class>
Property elements
In OWL there are two kinds of properties:

Object properties which relate objects to other items:
<owl:ObjectProperty rdf:ID="isTaughtBy">
<owl:domain rdf:resource="#course"/>
<owl:range rdf:resource="#academicStaffMember"/>
<rdfs:subPropertyOf rdf:resource="#involves"/>
</owl:ObjectProperty>

Datatype properties which relate objects to datatype values.
 OWL does not have any predefined data types, Instead it allows one to use XML
Schema data types:
<owl:DatatypeProperty rdf:ID="age">
<rdfs:range rdf:resource="http://www.w3.org/2001/XLMSchema
#nonNegativeInteger"/>
</owl:DatatypeProperty>

User-defined data types will usually be collected in an XML schema, and then
used in an OWL ontology.
Built-in properties

OWL allows us to describe « inverse properties ».
<owl:ObjectProperty rdf:ID="teaches">
<rdfs:range rdf:resource="#course"/>
<rdfs:domain rdf:resource="#academicStaffMember"/>
<owl:inverseOf rdf:resource="#isTaughtBy"/>
</owl:ObjectProperty>

Equivalence of properties:
<owl:ObjectProperty rdf:ID="lecturesIn">
<owl:equivalentProperty rdf:resource="#teaches"/>
</owl:ObjectProperty>
Built-in properties




owl:TransitiveProperty defines a transitive property.
owl:SymmetricProperty defines a symmetric
property.
owl:FunctionalProperty defines a property that has
at most one unique value for each object.
owl:InverseFunctionalProperty defines a property for
which two different objects cannot have the same
value.
Built-in properties
Example:
<owl:ObjectProperty rdf:ID="hasSameGradeAs">
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdf:type rdf:resource="&owl;SymmetricProperty" />
<rdfs:domain rdf:resource="#student" />
<rdfs:range rdf:resource="#student" />
</owl:ObjectProperty>

Exercises: Define « Age» and « IdNumber » using
FunctionalProperty and InverseFunctionalProperty.

Is there another way to define « Age » cardinality?
Property restrictions



owl:Restriction defines an anonymous class which has
no id, is not defined by owl:Class and can only be used
in the one place where the restriction appears.
In general, an owl:Restriction element contains an
owl:onProperty element, and one or more restriction
declarations.
One type of restriction declarations are those that define
restrictions on the kinds of values the property can take:

owl:allValuesFrom, owl:hasValue and owl:someValuesFrom.
Universal quantification
<owl:Class rdf:about="#firstYearCourse">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#isTaughtBy"/>
<owl:allValuesFrom rdf:resource="#Professor"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Existential quantification
<owl:Class rdf:about="#academicStaffMember">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#teaches"/>
<owl:someValuesFrom
rdf:resource="#undergraduateCourse"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
hasValue
<owl:Class rdf:about="#mathCourse">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#isTaughtBy"/>
<owl:hasValue rdf:resource="#949352"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Cardinality restrictions
<owl:Class rdf:about="#course">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#isTaughtBy"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">
1
</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

Here we require every course to be taught by at least someone.
Cardinality restrictions
<owl:Class rdf:about="#department">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMember"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">
10
</owl:minCardinality>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">
30
</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
 Here we specify that, for practical reasons, a department must have
at least ten and at most thirty members.

Exercise: a PhD student must have exactly two supervisors.
Enumerations

An enumeration is a owl:oneOf element, and is used to
define a class by listing all its elements.
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Monday"/>
<owl:Thing rdf:about="#Tuesday"/>
<owl:Thing rdf:about="#Wednesday"/>
<owl:Thing rdf:about="#Thursday"/>
<owl:Thing rdf:about="#Friday"/>
<owl:Thing rdf:about="#Saturday"/>
<owl:Thing rdf:about="#Sunday"/>
</owl:oneOf>
Boolean combinations

union, intersection, complement of classes.
<owl:Class rdf:about="#student">
<rdfs:subClassOf>
<owl:Restriction>
<owl:complementOf rdf:resource="#staffMember"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
 This says that every student is an instance of the complement of
staff members, that is, no student is a staff member.
Boolean combinations
<owl:Class rdf:ID="peopleAtUni">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#staffMember"/>
<owl:Class rdf:about="#student"/>
</owl:unionOf>
</owl:Class>
 As we did not specify that the two classes must
be disjoint, it is, in this case, possible that a staff
member is also a student!
Explain this!
<owl:Class rdf:ID="adminStaff">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#staffMember"/>
<owl:complementOf>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#faculty"/>
<owl:Class rdf:about="#techSupportStaff"/>
</owl:unionOf>
</owl:complementOf>
</owl:intersectionOf>
</owl:Class>
 defines
administrative staff to be those staff members
that are neither faculty nor technical support staff.
Instances
Defined as the following:
<academicStaffMember rdf:ID="949352">
<uni:name rdf:datatype="&xsd;string">Ford<uni:name>
</academicStaffMember>
For all instances you should use pairwise inequality:
<owl:allDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<lecturer rdf:about="949318">
<lecturer rdf:about="949352">
<lecturer rdf:about="949111">
</owl:distinctMembers>
</owl:allDifferent>
References
ASIS KM Website
http://www.asis.org/SIG/sigkm/index.html

Brint.com Knowledge Portal
http://www.brint.com/ym.html

Knowledge Management Research Center
http://www.cio.com/research/knowledge/

Karl-Erik Sveiby and Knowledge Associates
http://www.sveiby.com.au/

University of Arizona
http://www.cmi.arizona.edu/research/kno_mgmt/

Riichiro MizoguchiSIR, Osaka University
http://www.ei.sanken.osaka-u.ac.jp

Canadian Institutional Research and Planning Association.

Cartic Ramakrishnan, LSDIS Lab, University of Georgia.

Ontology Working Group.

Web Ontology Language: OWL, Grigoris Antoniou1 and Frank van Harmelen2
