Advanced knowledge modelling

Advanced Knowledge Modeling

Additional domain constructs Domain-knowledge sharing and reuse

Catalog of inferences Flexible use of task methods

Advanced knowledge modelling 2

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

infec tion

mening itis pneumonia

bacteria lpneumonia

acute v ira lpneumonia

chronic v ira lpneumonia

v ira lpneumonia

infec tion

mening itis pneumonia

chronicpneumonia

acute v ira lpneumonia

acute bac teria lpneumonia

acutepneumonia


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

infec tion

acuteinfec tion

chronicinfec tion

viralinfec tion

bac terialinfec tionmening itispneumonia

acute viralmening itis

c ausal agenttime fac tor


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

componentcons tra int

R ULE -‐T Y P E component-‐cons tra int; CONS T R AINT : component;E ND R ULE -‐T Y P E component-‐cons tra int;

E xample cons tra ints (ca r is a component):

ca r.we ight < 500 kgca r.leng th < 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(

cab.weight < 500)

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” –  Units and dimensions


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 ➤  Meta classes


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

value

descriptor value

object

object type object class

class constraint

has feature

descriptor value set

in dimension

instance of

class of

has descriptor

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

Chandrasekaran et al. (1999)


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

a s s oc ia tivegenera tion

genera tehypothes is

mode l-‐ba s edgenera tion

genera tions tra teg y

heuris ticma tch

caus a lcovering

genera tehypothes is

caus a lcovering

s ingle methodfor hypothes isgeneration

work-‐around for multiple methods for the same task

obta inna ture of da ta


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

Date post:	07-Jun-2015
Category:	Technology
Upload:	guus-schreiber
View:	175 times
Download:	0 times

Advanced knowledge modelling

Technology