Title: Advanced Knowledge Modeling
1Advanced Knowledge Modeling
- Additional domain constructs
- Domain-knowledge sharing and reuse
- Catalog of inferences
- Flexible use of task methods
2Viewpoints
- 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")
3Two different organizations of the disease
hierarchy
4Viewpoint 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
5Viewpoint graphical representation
6Expressions 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
7Rule 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 lt 10.000 suggests loan.amount lt
1.000 - for all instances of person with an income less
than 10.00 the amount of the loan should not
exceed 1.000
8Inquisitive 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 lt 28000
- residence-application.residence.rent lt 545
- INDICATES
- rent-fits-income.truth-value true
- Formal rule representation
- FORALL xresidence-application
- x.applicant.household-type
single-person - x.applicant.age-category up-to-22
- x.applicant.income lt 28000
- x,residence.rent lt 545
- INDICATES
- rent-fits-income.truth-value true
9Using 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
10Constraint rules
- Rules about restrictions on a single concept
- No antecedent or consequent
11Knowledge 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
12The 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
13Ontology should allow for representational
promiscuity
ontology
parameter
constraint -expression
mapping rules
viewpoint
knowledge base B
knowledge base A
parameter(cab.weight)
parameter(safety.weight)
cab.weight safety.weight
parameter(car.weight)
rewritten as
car.weight
constraint-expression(
cab.weight safety.weight
cab.weight lt 500
car.weight)
constraint-expression(
cab.weight lt 500)
14Ontology types
- Domain-oriented
- Domain-specific
- Medicine gt cardiology gt 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
- Units and dimensions
15Using 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
16Domain 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
17Ontology specification
- Many different languages
- KIF
- Ontolingua
- Express
- LOOM
- UML
- ......
- Common basis
- Class (concept)
- Subclass with inheritance
- Relation (slot)
18Additional 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
19Additional 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
- Meta classes
20Priority 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) - Multiple subclasses
- Reified relations
- Import/export mechanism
- Sloppy class/instance distinction
- (Second-order) constraint language
- Aggregation
21Art Architecture Thesaurus
Used for indexing stolen art objects in
European police databases
22The AAT ontology
description
object
universe
instance of
1
1
description
dimension
class of
object type
object class
in dimension
1
value set
1
1
has
descriptor
descriptor
descriptor
value set
descriptor
1
value
has feature
value
class
constraint
23Document fragment ontologies instructional
24Domain ontology of a traffic light control system
25Two ontologies of document fragments
26Ontology for e-commerce
27Top-level categoriesmany different proposals
Chandrasekaran et al. (1999)
28Catalog 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
29Catalog 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
30Catalog 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
31Inference abstract
- Operation input data set, output new given
- Example medical diagnosis temperature gt 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.
32Inference 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.
33Multiple 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
34Dealing with dynamic method selection
35Strategic 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