Advanced Knowledge Modeling
Additional domain constructs
Domain-knowledge sharing and reuse Catalog of inferences
Flexible use of task methods
Viewpoints
need for multiple sub-type hierarchies
sub-type-of = "natural" sub-type dimension
typically complete and total
other sub-type dimensions: viewpoint
represent additional ways of "viewing" a certain concept
similar to UML "dimension"
helps to introduce new vocabulary through multiple
specialization ("inheritance")
Two different organizations of the disease hierarchy
infection
meningitis pneumonia
bacterial pneumonia
acute viral
pneumonia chronic viral pneumonia viral
pneumonia
infection
meningitis pneumonia
chronic pneumonia
acute viral
pneumonia acute bacterial pneumonia acute
pneumonia
Viewpoint specification
concept infection;
super-type-of: meningitis, pneumonia;
viewpoints:
time-factor:
acute-infection, chronic-infection;
causal-agent:
viral-infection, bacterial-infection;
end concept infection;
concept acute-viral-meningitis;
sub-type-of: meningitis, acute-infection, viral-infection;
end concept acute-viral-meningitis;
Viewpoint:
graphical representation
infection
acute infection chronic
infection
viral infection
bacterial infection meningitis
pneumonia
causal agent time factor
Expressions and Formulae
need for expressing mathematical models or logical formulae
imported language for this purpose
Neutral Model Format (NMF)
used in technical domains
see appendix
Rule instance format
See appendix for semi-formal language
Guideline: use what you are comfortable with
May use (semi-)operational format, but for conceptual purposes!
Implicit assumption: universal quantification
person.income < 10.000 suggests loan.amount < 1.000
“for all instances of person with an income less than 10.00 the amount of the loan should not exceed 1.000
Inquisitive versus formal rule representation
Intuitive rule representation
residence-application.applicant.household-type = single-person residence-application.applicant.age-category = up-to-22
residence-application.applicant.income < 28000 residence-application.residence.rent < 545 INDICATES
rent-fits-income.truth-value = true;
Formal rule representation
FORALL x:residence-application
x.applicant.household-type = single-person x.applicant.age-category = up-to-22
x.applicant.income < 28000 x,residence.rent < 545 INDICATES
rent-fits-income.truth-value = true;
Using variables in rules to eliminate ambiguities
/* ambiguous rule */
employee.smoker = true AND employee.smoker = false
IMPLIES-CONFLICT
smoker-and-non-smoker.truth-value =true;
/* use of variables to remove the ambiguity */
VAR x, y: employee;
x.smoker = true AND y.smoker = false
IMPLIES-CONFLICT
smoker-and-non-smoker.truth-value =true;
Constraint rules
Rules about restrictions on a single concept
No antecedent or consequent
component
component constraint
RULE-TYPE component-constraint;
CONSTRAINT:
component;
END RULE-TYPE component-constraint;
Example constraints (car is a component):
car.weight < 500 kg car.length < 5.5 m
Knowledge sharing and reuse:
why?
KE is costly and time-consuming
general reuse rationale: quality, etc
Distributed systems
knowledge base partitioned over different locations
Common vocabulary definition
Internet search, document indexing, ….
Cf. thesauri, natural language processing
Central notion: “ontology”
The notion of ontology
Ontology =
explicit specification of a shared
conceptualization that holds in a particular context”
(several authors)
Captures a viewpoint an a domain:
Taxonomies of species
Physical, functional, & behavioral system descriptions
Task perspective: instruction, planning
Ontology should allow for
“representational promiscuity”
ontology parameter
constraint -expression
knowledge base A cab.weight + safety.weight
= car.weight:
cab.weight < 500:
knowledge base B parameter(cab.weight)
parameter(safety.weight) parameter(car.weight)
constraint-expression(
cab.weight + safety.weight = car.weight)
constraint-expression(
rewritten as viewpoint
mapping rules
Ontology types
Domain-oriented
Domain-specific
– Medicine => cardiology => rhythm disorders – traffic light control system
Domain generalizations
– components, organs, documents
Task-oriented
Task-specific
– configuration design, instruction, planning
Task generalizations
– problems solving, e.g. UPML
Generic ontologies
– “Top-level categories”
Using ontologies
Ontologies needed for an application are typically a mix of several ontology types
Technical manuals
– Device terminology: traffic light system – Document structure and syntax
– Instructional categories
E-commerce
Raises need for
Modularization
Integration
– Import/export – Mapping
Domain standards and
vocabularies as ontologies
Example: Art and Architecture Thesaurus (AAT)
Contain ontological information
AAT: structure of the hierarchy
Ontology needs to be “extracted”
Not explicit
Can be made available as an ontology
With help of some mapping formalism
Lists of domain terms are sometimes also called “ontologies”
Implies a weaker notion of ontology
Scope typically much broader than a specific application domain
Example: domain glossaries, WordNet
Contain some meta information: hyponyms, synonyms, text
Ontology specification
Many different languages
KIF
Ontolingua
Express
LOOM
UML
...
Common basis
Class (concept)
Subclass with inheritance
Relation (slot)
Additional expressivity (1 of 2)
Multiple subclasses
Aggregation
Built-in part-whole representation
Relation-attribute distinction
“Attribute” is a relation/slot that points to a data type
Treating relations as classes
Sub relations
Reified relations (e.g., UML “association class”)
Constraint language
First-order logic
Second-order statements
Additional expressivity (2 of 2)
Class/subclass semantics
Primitive vs. defined classes
Complete/partial, disjoint/overlapping subclasses
Set of basic data types
Modularity
Import/export of an ontology
Ontology mapping
Renaming ontological elements
Transforming ontological elements
Sloppy class/instance distinction
Class-level attributes/relations
Priority list for expressivity
Depends on goal:
Deductive capability: “limit to first-order logic”
Maximal content: “as much as (pragmatically) possible”
My priority list (
from a “maximal-content” representative)
1. Multiple subclasses
2. Reified relations
3. Import/export mechanism
4. Sloppy class/instance distinction
5. (Second-order) constraint language
6. Aggregation
Art & Architecture Thesaurus
Used for indexing stolen art objects in European police
databases
The AAT ontology
description universe
description dimension
descriptor value set
descriptor value
object
object type object class
has feature descriptor
value set
in dimension
instance of
class of
descriptorhas
1+
1+
1+
1+
1+
1+
Document fragment ontologies:
instructional
Domain ontology of a traffic
light control system
Two ontologies of document
fragments
Ontology for e-commerce
Top-level categories:
many different proposals
Catalog of inferences
Inferences are key elements of knowledge models
building blocks
No theory of inference types
see literature
CommonKADS: catalog of inferences used in practice
guideline: maintain your own catalog
Catalog structure
Inference name
Operation
input/output features
Example usage
Static knowledge
features of domain knowledge required
Typical task types
in what kind of tasks can one expect this inference
Catalog structure (continued)
Used in template
reference to template in the CK book
Control behavior
does it always produce a solution?
can it produce multiple solutions?
Computation methods
typical algorithms for realizing the inference
Remarks
Inference “abstract”
Operation: input =data set, output= new given
Example: medical diagnosis: temperature > 38 degrees is abstracted to “fever”
Static knowledge: abstraction rules, sub-type hierarchy
Typical task types: mainly analytic tasks
Operational behavior: may succeed more than once.
Computational methods: Forward reasoning, generalization
Remarks:
.
Make sure to add any abstraction found to the data set to allow for chained abstraction.Inference “cover”
Operation: given some effect, derive a system state that could have caused it
Example: cover complaints about a car to derive potential faults.
Static knowledge: uses some sort of behavioral model of the system being diagnosed. A causal network is most common. e.
Typical task types: specific for diagnosis.
Control behavior: produces multiple solutions for same input.
Computational methods: abductive methods, ranging from simple to complex, depending on nature of diagnostic method
Remarks: cover is an example of a task-specific inference. Its use is much more restricted than, for example, the select
inference.
Multiple methods for a task
Not always possible to fix the choice of a method for a task
e.g. choice depends on availability of certain data
Therefore: need to model dynamic method selection
Work-around in CommonKADS
introduce method-selection task
Dealing with dynamic method selection
associative generation generate hypothesis
model-based generation generation
strategy
heuristic
match causal
covering generate
hypothesis
causal covering
single method for hypothesis
generation
work-around for multiple methods for the same task
obtain nature of data
Strategic knowledge
Knowledge about how to combine tasks to reach a goal
e.g. diagnosis + planning
If complex: model as separate reasoning process!
meta-level planning task
