Integrating

Terminological

and

Deductive

Reasoning

Urs

Badertscher

and

Robert

Marti

Institut

fur

Informationssysteme

ETH-Zentrum

Switzerland

e-mail

fbadertscher

martig@inf.ethz.ch

March

Abstract

We

present

a

data

model

which

supports

two

kinds

of

reasoning

Firstly

it

supports

terminological

reasoning

in

the

style

of

KL-ONE

mainly

subsumption

of

concepts

-LRB-

types

-RRB-

and

instantiation

of

objects

a

kind

of

type

inference

for

objects

Secondly

it

also

supports

deductive

inferencing

and

integrity

checking

in

the

style

of

logic

programming

languages

and

deductive

databases

This

data

model

may

also

be

considered

as

a

typed

deductive

database

with

type

inferences

In

order

to

get

a

common

semantics

for

both

features

of

our

data

model

we

map

the

terminological

inferences

to

a

logic

program

The

data

model

has

been

implemented

as

a

prototype

in

Prolog

Contents

Introduction

The

Terminological

Component

Syntax

Semantics

Concept

Subsumption

The

Object

Component

Syntax

Semantics

Object

Instantiation

The

Integrity

Constraint

Component

Syntax

Semantics

Updates

The

Data

Model

as

Deductive

Database

The

Pre-Defined

and

the

User-Defined

Database

Syntactic

Restrictions

of

Deduction

Rules

Efficient

Evaluation

of

Integrity

Constraints

Extensions

of

the

Data

Model

Terminological

Cycles

Subroles

Semantics

Comparison

and

Outlook

Bibliography

A

Appendix

A.

Definition

of

Concepts

and

Roles

A.

Compatibility

Conditions

A.

Concept

Normalization

A.

The

Subsumption

Algorithm

A.

Correctness

of

Subsumption

A.

The

Instantiation

Algorithm

A.

Pre-defined

Integrity

Constraints

A.

An

Example

Database

Introduction

The

goal

of

knowledge

representation

is

to

find

accurate

means

to

formally

represent

structured

knowledge

and

draw

inferences

from

this

knowledge

KL-ONE

-LSB-

Brachman

Schmolze

-RSB-

is

an

important

and

influential

knowledge

representation

system

It

has

evolved

from

so-called

frame-based

languages

-LSB-

Hayes

Fikes

Kehler

-RSB-

KL-ONE

separates

domain

knowledge

into

two

components

In

the

terminological

component

-LRB-

T-Box

-RRB-

the

terminology

to

describe

the

real

world

has

to

be

defined

The

assertional

component

-LRB-

A-Box

-RRB-

contains

the

world

descriptions

namely

individuals

-LRB-

objects

-RRB-

and

their

relationships

to

other

individuals

KL-ONE-like

systems

have

many

features

in

common

with

object-oriented

languages

in

particular

with

object-oriented

database

languages

-LSB-

Cattell

-RSB-

For

example

they

both

separate

the

meta

level

-LRB-

T-Box

schema

types

classes

concepts

-RRB-

from

the

data

level

-LRB-

A-Box

objects

instances

individuals

-RRB-

A

second

similarity

is

the

presence

of

a

type

class

or

concept

hierarchy

Some

object-oriented

databases

additionally

distinguish

between

types

and

classes

The

systems

based

on

KL-ONE

are

commonly

called

terminological

systems

and

their

respective

languages

are

typically

termed

terminological

logic

or

sometimes

concept

language

-LSB-

Levesque

Brachman

Nebel

Schmidt-Schauss

Smolka

Woods

Schmolze

-RSB-

In

the

following

we

use

the

notions

of

concepts

and

objects

as

is

customary

in

the

context

of

terminological

logics

Relations

between

concepts

are

called

roles

An

important

difference

of

terminological

logics

to

most

object-oriented

languages

is

that

the

concept

subsumption

relationship

-LRB-

subclassing

-RRB-

and

the

classification

of

objects

is

inferred

from

the

properties

of

the

concept

definitions

rather

than

specified

explicitly

e.g.

using

an

IS-A

hierarchy

However

some

object-oriented

databases

also

offer

these

inferences

e.g.

COCOON

-LSB-

Scholl

et

al.

-RSB-

Research

in

deductive

databases

has

evolved

from

efforts

to

integrate

logic

programming

and

databases

The

main

idea

is

to

use

logic

as

a

uniform

database

language

for

representing

factual

data

deduction

rules

and

integrity

constraints

as

well

as

queries

and

updates

-LSB-

Lloyd

Bry

et

al.

Ceri

et

al.

Das

Cremers

et

al.

-RSB-

The

aim

of

this

work

is

the

integration

of

terminological

and

deductive

reasoning

For

this

purpose

we

have

defined

a

data

model

with

formal

semantics

and

implemented

it

in

Prolog

The

main

parts

of

our

data

model

have

also

been

implemented

in

ProQuel

-LSB-

Pfister

-RSB-

ProQuel

is

a

deductive

database

system

supporting

purely

declarative

semantics

setoriented

computation

and

persistence

-LSB-

Burse

-RSB-

ProQuel

is

implemented

on

top

of

the

commercial

relational

database

system

Oracle

Our

data

model

consists

of

three

components

ffl

In

the

terminological

component

concepts

are

defined

From

the

definition

of

a

concept

it

is

possible

to

infer

whether

it

is

a

subconcept

of

other

concepts

This

inference

is

called

concept

subsumption

ffl

In

the

object

component

objects

are

specified

which

may

be

related

to

other

objects

via

roles

-LRB-

relationships

-RRB-

The

object

component

can

be

seen

as

a

relational

database

with

binary

relations

or

when

incorporating

deduction

rules

as

a

deductive

database

ffl

In

the

integrity

constraint

component

pre-defined

and

user-defined

integrity

constraints

can

be

formulated

declaratively

The

integrity

constraints

are

simplified

and

checked

after

a

-LRB-

semantic

-RRB-

transaction

If

the

database

is

not

consistent

after

a

transaction

i.e.

not

all

integrity

constraints

are

satisfied

then

all

changes

made

within

a

transaction

are

rejected

Both

the

terminological

and

the

object

components

have

their

own

syntax

and

semantics

and

can

be

used

separately

The

instantiation

algorithm

associates

objects

with

concepts

thus

linking

the

two

components

together

Instantiation

can

be

seen

as

concept

-LRB-

type

-RRB-

inference

for

objects

Alternatively

we

can

separate

our

data

model

into

the

following

two

parts

The

pre-defined

database

consists

of

the

terminological

component

the

fact

part

of

the

object

component

and

the

pre-defined

integrity

constraints

The

user-defined

database

consists

of

the

rest

namely

the

rule

part

of

the

object

component

and

the

user-defined

integrity

constraints

The

main

difference

of

our

data

model

to

terminological

logics

is

the

presence

of

this

user-defined

database

This

view

of

our

data

model

as

deductive

database

is

further

described

in

section

This

work

has

emerged

from

the

project

Hybrides

Wissensbanksystem

within

the

Schwerpunktprogramm

Informatik

-LSB-

Reimer

et

al.

-RSB-

The

goals

of

this

project

are

-LRB-

-RRB-

to

extend

the

frame

model

FRM

-LSB-

Reimer

-RSB-

with

deduction

rules

and

integrity

constraints

and

-LRB-

-RRB-

to

implement

FRM

efficiently

by

mapping

it

to

the

object

data

model

COCOON

-LSB-

Scholl

et

al.

-RSB-

This

mapping

is

described

in

-LSB-

Norrie

et

al.

-RSB-

The

next

three

sections

describe

the

three

components

of

our

data

model

the

terminological

object

and

integrity

constraint

components

with

their

corresponding

inferences

In

section

we

consider

the

data

model

from

the

deductive

database

point

of

view

and

discuss

the

corresponding

restrictions

and

semantics

Section

contains

some

extensions

of

the

data

model

and

section

a

short

comparison

and

outlook

The

main

text

is

kept

rather

informal

Technical

and

implementation

details

are

covered

in

the

appendix

The

Terminological

Component

Syntax

The

two

main

syntactic

constructs

of

the

terminological

component

are

concepts

and

roles

similar

to

entities

and

relationships

in

the

ER-model

or

frames

and

slots

in

frame

models

A

concept

can

also

be

considered

as

a

type

or

a

class

or

as

a

unary

relation

A

role

can

be

seen

as

a

binary

relation

between

concepts

or

as

a

function

from

a

concept

to

a

set

of

concepts

This

follows

from

the

semantics

given

in

section

Atomic

concepts

are

those

concepts

introduced

explicitly

as

primitive

stating

only

necessary

conditions

for

individuals

to

be

considered

as

instances

of

them

or

as

defined

stating

necessary

and

sufficient

conditions

Starting

with

atomic

concepts

and

roles

one

can

construct

complex

concept

expressions

using

various

concept

forming

operators

Concept

expressions

are

formed

as

follows

If

C

is

an

atomic

concept

-LRB-

see

below

-RRB-

then

C

is

a

concept

If

and

are

concepts

then

so

are

and

and

or

If

R

is

a

role

and

C

is

a

concept

then

all

R

C

and

ex

R

C

are

also

concepts

If

R

is

a

role

and

N

is

a

number

then

min

R

N

and

max

R

N

are

also

concepts

The

terminological

language

is

thus

very

close

to

a

subset

of

a

first

order

language

where

and

or

all

and

ex

stand

for

and

respectively

The

main

differences

are

the

absence

of

negation

of

explicit

variables

and

of

function

symbols

Primitive

and

defined

concepts

are

those

concepts

introduced

explicitly

hprimitive-concepti

hprimitive-concepti

hconcepti

hdefined-concepti

hconcepti

Cyclic

definitions

of

concepts

are

not

allowed

-LRB-

but

see

the

extension

in

section

-RRB-

Pre-defined

concepts

are

anything

nothing

integer

string

and

boolean

Primitive

defined

and

pre-defined

concepts

are

called

atomic

concepts

Roles

have

to

be

introduced

explicitly

and

are

atomic

A

terminology

is

a

finite

nonempty

set

of

atomic

concepts

and

roles

The

Prolog-implementation

of

concept

definition

is

straightforward

and

given

in

appendix

A.

Note

for

example

that

the

definitions

of

the

predicates

concept

and

defined

concept

are

mutually

recursive

Example

We

present

an

example

terminology

with

departments

and

employees

The

data

base

is

fully

listed

in

appendix

A.

department

primitive

concepts

office

department

worker

employee

employee

defined

concepts

all

address

string

and

ex

department

and

all

age

integer

and

max

age

leader

all

address

string

and

min

address

and

ex

leads

department

and

ex

office

and

all

age

integer

and

max

age

allrounder

worker

and

leader

boss

leader

address

roles

-LRB-

relations

-RRB-

leads

age

In

this

example

department

office

and

worker

are

primitive

concepts

where

office

is

a

more

specific

concept

than

department

and

worker

is

a

more

specific

concept

than

employee

Employee

is

a

defined

concept

Individuals

are

instances

of

employee

if

and

only

if

-LRB-

-RRB-

they

have

zero

or

more

addresses

all

of

type

string

-LRB-

-RRB-

they

work

in

at

least

one

department

and

-LRB-

-RRB-

have

at

most

one

age

of

type

integer

A

leader

has

-LRB-

-RRB-

at

least

one

address

all

addresses

are

of

type

string

-LRB-

-RRB-

leads

a

department

and

-LRB-

-RRB-

works

in

an

office

and

-LRB-

-RRB-

again

has

at

most

one

age

of

type

integer

An

allrounder

is

both

a

worker

and

a

leader

Boss

is

a

synonym

for

leader

Examples

of

non-atomic

concepts

are

the

concepts

ex

works

in

department

max

age

and

worker

and

leader

In

the

above

example

terminology

address

works

in

leads

and

age

are

roles

Semantics

We

use

a

model-theoretic

semantics

Amodel

of

a

terminology

is

a

pair

D

E

where

D

is

any

nonempty

set

-LRB-

of

objects

-RRB-

called

the

domain

E

is

an

extension

function

which

assigns

a

subset

of

the

domain

to

any

concept

i.e.

E

TC

P

-LRB-

D

-RRB-

and

E

TR

P

-LRB-

D

D

-RRB-

where

TC

is

the

set

of

concepts

and

TR

is

the

set

of

roles

and

P

-LRB-

D

-RRB-

denotes

the

power

set

of

the

domain

D.

Typically

the

extension

E

-LSB-

C

-RSB-

of

a

concept

C

is

a

set

of

objects

which

are

viewed

as

instances

of

concept

C

The

extension

function

E

has

to

satisfy

compatibility

conditions

like

E

-LSB-

C

and

D

-RSB-

E

-LSB-

C

-RSB-

E

-LSB-

D

-RSB-

E

-LSB-

ex

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

E

-LSB-

Cp

-RSB-

E

-LSB-

C

-RSB-

if

Cp

C

and

E

-LSB-

Cd

-RSB-

E

-LSB-

C

-RSB-

if

Cd

C

-LRB-

see

appendix

A.

-RRB-

A

concept

C

is

called

incoherent

if

it

can

not

have

any

instances

i.e.

E

-LSB-

C

-RSB-

for

all

models

of

C.

Every

terminology

is

consistent

i.e.

it

has

a

model

This

is

true

even

if

the

terminology

has

incoherent

concepts

Example

We

construct

two

models

for

the

following

terminology

which

is

based

on

parts

of

example

department

office

department

employee

ex

department

For

the

first

model

we

define

fjohn

sales

productiong

For

the

primitive

concepts

we

choose

-LSB-

department

-RSB-

fsales

productiong

and

-LSB-

office

-RSB-

fsalesg

and

for

the

role

we

choose

-LSB-

works

in

-RSB-

f

john

sales

g.

For

the

defined

concept

employee

we

then

get

-LSB-

employee

-RSB-

-LSB-

ex

works

in

department

-RSB-

fjohng

These

definitions

satisfy

all

compatibility

conditions

as

can

be

verified

easily

We

can

additionally

compute

for

example

E

-LSB-

min

works

in

-RSB-

E

-LSB-

min

works

in

-RSB-

fjohng

E

-LSB-

min

works

in

-RSB-

and

E

-LSB-

department

and

office

-RSB-

E

-LSB-

department

-RSB-

E

-LSB-

office

-RSB-

fsalesg

For

the

second

model

we

define

fjohn

productiong

Then

we

further

choose

-LSB-

department

-RSB-

fproductiong

-LSB-

office

-RSB-

and

-LSB-

works

in

-RSB-

Therefore

we

get

-LSB-

employee

-RSB-

-LSB-

ex

works

in

department

-RSB-

Even

though

the

extensions

of

office

and

employee

in

this

model

are

empty

these

concepts

are

not

incoherent

However

the

concept

min

works

in

and

max

works

in

is

an

example

of

an

incoherent

concept

Concept

Subsumption

A

concept

is

subsumed

by

-LRB-

or

a

subconcept

of

-RRB-

a

concept

in

a

terminology

T

if

the

extension

of

is

a

subset

of

the

extension

of

i.e.

E

-LSB-

-RSB-

E

-LSB-

-RSB-

for

all

models

of

T

Notation

or

sub

-LRB-

-RRB-

Two

concepts

are

called

equivalent

if

they

subsume

each

other

Concept

subsumption

defines

a

partial

order

on

the

set

of

concepts

The

set

of

all

concepts

of

a

terminology

modulo

concept

equivalence

forms

a

lattice

The

algorithm

for

computing

concept

subsumption

is

the

main

inference

in

the

terminological

component

The

concepts

are

normalized

before

computing

subsumption

-LRB-

see

appendix

A.

-RRB-

The

subsumption

algorithm

is

based

on

-LSB-

Nebel

-RSB-

and

fully

listed

in

appendix

A.

We

present

Prolog

clauses

for

the

and

and

all

constructs

and

for

unfolding

defined

concepts

i.e.

the

replacement

of

concept

names

by

their

definitions

Note

that

we

have

used

operators

for

the

concept

constructors

and

or

-LRB-

infix

-RRB-

all

ex

min

and

max

-LRB-

prefix

-RRB-

and

for

the

concept

introductions

-LRB-

infix

-RRB-

and

-LRB-

infix

and

postfix

-RRB-

sub

-LRB-

C

and

-RRB-

sub

-LRB-

C

-RRB-

sub

-LRB-

C

-RRB-

a

-RRB-

sub

-LRB-

and

D

-RRB-

sub

-LRB-

D

-RRB-

sub

-LRB-

D

-RRB-

b

-RRB-

sub

-LRB-

all

R

C

all

R

:D

-RRB-

sub

-LRB-

C

D

-RRB-

-RRB-

sub

-LRB-

Cd

D

-RRB-

Cd

C

sub

-LRB-

C

D

-RRB-

a

-RRB-

sub

-LRB-

C

Dd

-RRB-

Dd

D

sub

-LRB-

C

D

-RRB-

b

-RRB-

Clause

a

-RRB-

reads

If

C

is

a

subconcept

of

the

concepts

and

then

C

is

also

a

subconcept

of

the

concept

and

Clause

-RRB-

reads

If

C

is

a

subconcept

of

concept

D

then

all

R

C

is

also

a

subconcept

of

concept

all

R

:D

If

sub

is

called

with

non-ground

arguments

in

order

to

compute

the

entire

subsumption

hierarchy

we

only

generate

solutions

which

relate

atomic

-LRB-

i.e.

primitive

or

defined

-RRB-

concepts

because

there

are

infinitely

many

concepts

The

subsumption

algorithm

can

be

represented

by

definite

clauses

-LRB-

except

of

the

use

of

the

built-ins

and

>=-RRB-

because

we

do

not

support

concept

negation

Note

that

there

is

no

explicit

clause

for

the

transitivity

of

the

subsumption

relation

Correctness

of

the

subsumption

algorithm

means

that

sub

-LRB-

C

D

-RRB-

implies

E

-LSB-

C

-RSB-

E

-LSB-

D

-RSB-

for

all

clauses

having

sub

-LRB-

C

D

-RRB-

in

their

head

Some

typical

cases

are

proven

in

appendix

A.

Example

We

now

give

an

example

session

for

the

use

of

the

subsumption

algorithm

with

the

terminology

from

example

Note

that

the

algorithm

may

be

used

both

for

testing

subsumption

relationships

between

concepts

and

for

generating

atomic

subsumed

concepts

We

use

the

Prolog

convention

that

identifiers

starting

with

a

capital

letter

stand

for

variables

office

department

yes

department

office

no

employee

all

address

string

yes

ex

office

ex

department

yes

leader

employee

yes

SubConcept

employee

SubConcept

worker

SubConcept

employee

SubConcept

leader

SubConcept

allrounder

SubConcept

boss

no

equivalent

-LRB-

leader

boss

-RRB-

yes

min

min

yes

An

office

is

a

department

because

it

is

primitively

specified

as

such

Employee

is

a

subconcept

of

all

address

string

because

by

its

definition

the

set

of

employees

is

a

subset

of

all

things

having

only

strings

as

addresses

The

concept

ex

works

in

office

is

a

subconcept

of

ex

works

in

department

because

office

is

a

subconcept

of

department

A

leader

is

an

employee

because

he

has

all

properties

of

an

employee

-LRB-

that

he

works

in

a

department

follows

from

the

previous

query

-RRB-

and

two

more

-LRB-

namely

at

least

one

address

and

leading

a

department

-RRB-

The

concept

hierarchy

of

our

example

terminology

is

u

u

u

employee

leader

bossw

orker

allrounder

department

office

I

I

Primitive

concepts

are

represented

by

a

circle

and

defined

concepts

by

a

rectangle

We

see

that

in

our

data

model

we

allow

multiple

inheritance

via

the

and-construct

for

example

an

allrounder

is

defined

as

allrounder

worker

and

leader

and

therefore

inherits

all

properties

both

of

worker

and

of

leader

This

is

called

additive

monotonic

signature

inheritance

in

-LSB-

Kifer

et

al.

-RSB-

The

Object

Component

Syntax

Fact

expressions

in

the

object

component

are

formed

the

following

way

rel

-LRB-

Object

Role

RelObject

-RRB-

inst

-LRB-

Object

Concept

-RRB-

The

facts

of

the

first

form

are

called

relation

facts

the

facts

of

the

second

form

are

called

instance

facts

Note

that

instance

facts

permit

the

assignment

of

any

object

to

any

concept

-LRB-

except

when

violating

integrity

constraints

see

section

-RRB-

This

is

in

contrast

to

most

object-oriented

languages

where

concepts

-LRB-

types

-RRB-

are

considered

as

integrity

constraints

-LRB-

restrictions

-RRB-

for

objects

Objects

are

introduced

implicitly

as

first

or

third

argument

of

a

relation

fact

or

as

first

argument

of

an

instance

fact

Therefore

a

value

is

also

an

object

and

we

do

not

distinguish

these

two

notions

In

fact

a

number

is

an

instance

of

the

pre-defined

concept

number

and

a

string

is

an

instance

of

the

pre-defined

concept

string

A

deduction

rule

has

the

form

H

Bn

where

the

head

H

is

a

relation

or

instance

fact

and

the

Bi

of

the

body

are

relation

or

instance

facts

or

negation

thereof

As

usual

in

deductive

databases

the

set

of

deduction

rules

has

to

be

range-restricted

-LRB-

allowed

-RRB-

and

locally

stratified

-LRB-

for

definitions

see

section

-RRB-

The

symbol

stands

for

i.e.

implication

from

right

to

left

and

the

commas

stand

for

logical

conjunction

An

object

base

is

a

set

of

relation

and

instance

facts

and

of

deduction

rules

Example

We

now

present

an

example

object

base

-LRB-

see

appendix

A.

-RRB-

which

will

be

used

together

with

the

terminology

from

example

inst

-LRB-

sales

office

-RRB-

inst

-LRB-

production

department

-RRB-

rel

-LRB-

bob

production

-RRB-

rel

-LRB-

mary

age

-RRB-

rel

-LRB-

bill

address

london

-RRB-

inst

-LRB-

john

leader

-RRB-

rel

-LRB-

bill

address

paris

-RRB-

inst

-LRB-

john

worker

-RRB-

rel

-LRB-

bill

leads

sales

-RRB-

rel

-LRB-

john

leads

production

-RRB-

rel

-LRB-

bill

age

-RRB-

rel

-LRB-

john

age

-RRB-

rel

-LRB-

E

production

-RRB-

rel

-LRB-

E

sales

-RRB-

rel

-LRB-

E

D

-RRB-

rel

-LRB-

E

leads

D

-RRB-

In

this

example

the

object

sales

is

an

instance

of

concept

office

and

object

production

is

an

instance

of

concept

department

Bob

works

in

the

production

department

but

his

address

and

age

are

unknown

Mary

has

age

Bill

has

two

addresses

namely

London

and

Paris

leads

the

sales

department

and

has

age

John

is

a

leader

and

worker

leads

department

production

and

has

age

The

first

deduction

rule

states

that

everyone

working

in

the

sales

department

also

works

in

the

production

department

By

the

second

rule

everyone

leading

a

department

also

works

in

the

department

Semantics

A

model

of

an

object

base

is

again

a

pair

D

E

where

D

is

any

set

-LRB-

of

objects

-RRB-

called

the

domain

and

E

is

an

extension

function

E

assigns

an

element

of

the

domain

to

any

object

i.e.

E

TO

D

-LRB-

where

TO

is

the

set

of

objects

-RRB-

It

has

to

satisfy

inst

-LRB-

Object

Concept

-RRB-

E

-LSB-

Object

-RSB-

E

-LSB-

Concept

-RSB-

rel

-LRB-

Object

Role

RelObject

-RRB-

E

-LSB-

Object

-RSB-

E

-LSB-

RelObject

-RSB-

E

-LSB-

Role

-RSB-

A

model

is

called

hybrid

if

it

is

both

a

model

of

an

object

base

and

of

a

terminology

For

a

given

object

base

and

terminology

there

may

exist

no

hybrid

model

-LRB-

for

example

if

an

object

is

instance

of

a

concept

violating

max-restrictions

-RRB-

Example

We

construct

a

hybrid

model

for

terminology

from

example

and

the

following

object

base

department

inst

-LRB-

production

department

-RRB-

office

department

inst

-LRB-

sales

office

-RRB-

employee

ex

department

inst

-LRB-

bill

employee

-RRB-

rel

-LRB-

john

sales

-RRB-

Similar

to

example

we

have

to

define

a

domain

and

an

extension

function

However

here

we

do

not

choose

any

set

as

domain

but

we

take

as

domain

D

a

superset

of

the

set

of

objects

TO

fbill

john

sales

productiong

Then

we

compute

E

for

primitive

concepts

from

instance

facts

only

and

finally

we

determine

the

extension

of

defined

concepts

and

roles

from

instance

and

relation

facts

and

the

compatibility

conditions

of

the

extension

function

By

the

instance

fact

inst

-LRB-

sales

office

-RRB-

we

know

that

sales

E

-LSB-

office

-RSB-

and

further

sales

E

-LSB-

department

-RSB-

because

E

-LSB-

office

-RSB-

E

-LSB-

department

-RSB-

Similarly

we

get

production

E

-LSB-

department

-RSB-

Now

by

the

facts

rel

-LRB-

john

works

in

sales

-RRB-

inst

-LRB-

sales

office

-RRB-

and

office

department

we

get

john

E

-LSB-

ex

works

in

department

-RSB-

E

-LSB-

employee

-RSB-

We

further

conclude

by

the

fact

inst

-LRB-

bill

employee

-RRB-

that

bill

E

-LSB-

employee

-RSB-

E

-LSB-

ex

works

in

department

-RSB-

So

we

know

that

there

exists

an

element

c

D

such

that

bill

c

E

-LSB-

works

in

-RSB-

and

c

E

-LSB-

department

-RSB-

Observe

that

we

could

choose

c

production

or

c

sales

as

well

We

finally

define

the

domain

as

D

fbill

john

sales

production

cg

and

the

extension

function

E

-LSB-

department

-RSB-

fsales

production

cg

E

-LSB-

office

-RSB-

fsalesg

E

-LSB-

employee

-RSB-

fbill

johng

and

E

-LSB-

works

in

-RSB-

f

john

sales

bill

c

g.

Note

that

we

can

express

some

kind

of

incomplete

knowledge

We

know

that

Bill

works

in

a

department

but

we

do

not

know

in

which

one

Object

Instantiation

Objects

can

be

assigned

to

concepts

either

by

the

user

-LRB-

predicate

-RRB-

or

by

the

instantiation

algorithm

-LRB-

predicates

in

-RRB-

Predicate

in

dir

determines

the

most

specific

concepts

of

which

an

object

is

an

instance

Similar

to

the

subsumption

algorithm

of

section

we

discuss

the

clauses

for

the

constructs

and

and

all

of

the

predicate

in

The

instantiation

algorithm

is

listed

fully

in

appendix

A.

-LRB-

I

C

and

D

-RRB-

-LRB-

I

C

-RRB-

-LRB-

I

D

-RRB-

and

-LRB-

I

all

R

C

-RRB-

-LRB-

rel

-LRB-

I

R

V

-RRB-

in

-LRB-

V

C

-RRB-

-RRB-

all

-LRB-

CWA

-RRB-

-LRB-

I

Cd

-RRB-

Cd

C

-LRB-

I

C

-RRB-

def.concept

The

and-clause

expresses

that

if

an

object

is

instance

of

both

concepts

C

and

D

then

it

is

also

instance

of

concept

C

and

D

An

object

is

instance

of

the

concept

all

R

C

if

all

its

entries

into

relation

facts

of

role

R

are

instances

of

concept

C.

Note

the

use

of

the

Closed

World

Assumption

-LRB-

CWA

-RRB-

in

this

case

The

all-clause

is

the

translation

of

R

C

-LRB-

-LRB-

rel

-LRB-

I

R

V

-RRB-

in

-LRB-

V

C

-RRB-

-RRB-

in

dir

-LRB-

I

all

R

C

-RRB-

-RRB-

into

Prolog

notation

Observe

that

objects

may

not

be

inferred

to

be

instances

of

primitive

concepts

because

primitive

concepts

do

not

state

sufficient

conditions

for

objects

to

belong

to

them

Example

We

now

present

an

example

session

for

the

use

of

the

instantiation

algorithm

and

for

querying

We

use

the

object

base

of

example

and

the

terminology

of

example

Object

in

department

Object

production

Object

sales

no

bob

in

Concept

Concept

employee

no

bill

in

Concept

Concept

boss

Concept

employee

Concept

leader

no

Object

in

employee

Object

bill

Object

bob

Object

john

no

mary

in

Concept

no

rel

-LRB-

E

production

-RRB-

E

bob

E

bill

E

john

no

rel

-LRB-

E

production

-RRB-

rel

-LRB-

E

age

A

-RRB-

A

A

E

bill

no

Bob

is

an

employee

because

-LRB-

-RRB-

all

his

addresses

are

strings

-LRB-

in

fact

he

has

-RRB-

-LRB-

-RRB-

he

works

in

a

department

-LRB-

namely

production

-RRB-

and

-LRB-

-RRB-

he

has

no

known

age

He

is

not

a

leader

because

there

is

no

rel

-LRB-

bob

leads

D

-RRB-

relation

fact

where

D

is

a

department

Neither

is

he

an

allrounder

Bill

is

an

employee

because

he

works

in

the

sales

department

-LRB-

by

the

second

deduction

rule

-RRB-

further

he

is

a

leader

-LRB-

and

therefore

also

a

boss

-RRB-

because

he

leads

the

sales

department

and

has

an

address

-LRB-

in

fact

he

has

two

-RRB-

Note

that

John

has

at

least

one

address

-LRB-

because

he

is

said

to

be

a

leader

-RRB-

but

it

is

unknown

Therefore

if

there

were

no

inst

-LRB-

john

leader

-RRB-

instance

fact

we

could

not

conclude

that

Bill

is

a

leader

The

last

query

asks

for

employees

in

the

production

department

who

are

younger

than

The

Integrity

Constraint

Component

Syntax

In

the

integrity

constraint

component

a

user

may

declaratively

specify

integrity

constraints

which

are

checked

after

updates

or

on

demand

A

first

order

formula

is

called

in

restricted

quantification

form

if

all

variables

are

restricted

by

a

range

-LRB-

see

-LSB-

Bry

et

al.

-RSB-

-RRB-

An

integrity

constraint

is

a

first

order

formula

in

restricted

quantification

form

in

which

only

the

pre-defined

predicate

symbols

of

the

terminological

and

object

components

plus

the

usual

equality

and

inequality

symbols

may

occur

We

choose

the

syntax

ic

-LRB-

Identifier

Formula

-RRB-

where

the

Formula

has

to

be

in

restricted

quantification

form

In

order

to

distinguish

the

logical

symbols

from

the

terminological

constructs

we

use

-LRB-

and

-RRB-

-LRB-

or

-RRB-

-LRB-

not

-RRB-

-LRB-

implication

-RRB-

as

logical

connectors

and

forall

and

exists

as

quantifiers

in

integrity

constraints

We

distinguish

pre-defined

and

user-defined

integrity

constraints

An

example

of

a

pre-defined

integrity

constraint

is

ic

-LRB-

mic

unique-introduction-of-concepts

forall

-LRB-

-LSB-

C

-RSB-

C

C

-RRB-

-RRB-

which

requires

the

unique

introduction

of

concepts

Therefore

it

is

a

functional

dependency

constraint

Other

pre-defined

constraints

guarantee

that

an

object

component

together

with

its

terminological

component

is

consistent

namely

that

there

are

no

instances

of

incoherent

concepts

and

that

the

instances

do

not

violate

max-restrictions

The

complete

list

of

pre-defined

integrity

constraints

is

contained

in

appendix

A.

We

allow

abbreviations

for

the

following

three

classes

of

user-defined

classification

constraints

disjoint

-LRB-

-RRB-

for

in

-LRB-

I

-RRB-

in

-LRB-

I

-RRB-

false

cover

-LRB-

c

-RRB-

for

in

-LRB-

I

c

-RRB-

in

-LRB-

I

-RRB-

in

-LRB-

I

-RRB-

partition

-LRB-

c

-RRB-

for

disjoint

-LRB-

-RRB-

cover

-LRB-

c

-RRB-

The

disjoint

classification

constraints

are

defined

the

following

way

ic

-LRB-

udc

disjoint

-LRB-

-RRB-

forall

-LRB-

-LSB-

I

-RSB-

in

-LRB-

I

-RRB-

in

-LRB-

I

-RRB-

false

-RRB-

-RRB-

disjoint

-LRB-

-RRB-

Example

Some

examples

of

user-defined

integrity

constraints

disjoint

-LRB-

employee

department

-RRB-

ic

-LRB-

udc

exists-leader-in-department

forall

-LRB-

-LSB-

D

-RSB-

in

-LRB-

D

department

-RRB-

exists

-LRB-

-LSB-

L

-RSB-

rel

-LRB-

L

leads

D

-RRB-

-RRB-

-RRB-

-RRB-

ic

-LRB-

udc

only-young-salespersons

forall

-LRB-

-LSB-

E

A

-RSB-

rel

-LRB-

E

sales

-RRB-

rel

-LRB-

E

age

A

-RRB-

A

-RRB-

-RRB-

ic

-LRB-

udc

forall

-LRB-

-LSB-

D

-RSB-

rel

-LRB-

leads

D

-RRB-

rel

-LRB-

leads

D

-RRB-

-RRB-

-RRB-

ic

-LRB-

udc

exists-employee

exists

-LRB-

-LSB-

E

-RSB-

in

-LRB-

E

employee

-RRB-

-RRB-

-RRB-

The

first

constraint

is

a

classification

constraint

stating

that

an

object

may

not

be

instance

both

of

employee

and

of

department

The

second

constraint

is

a

referential

integrity

constraint

requiring

that

every

department

has

somebody

leading

it

The

third

constraint

is

a

domain

restriction

of

employees

in

the

sales

department

to

persons

younger

than

The

fourth

integrity

constraint

is

a

functional

dependency

constraint

The

leader

is

functionally

dependent

on

the

department

i.e.

there

is

at

most

one

leader

in

any

department

The

last

constraint

requires

that

there

is

at

least

one

instance

of

the

concept

employee

Semantics

The

semantics

of

integrity

constraints

is

defined

according

to

interpretations

in

classical

logic

Updates

We

allow

database

updates

by

adding

or

removing

of

facts

F

and

rules

The

syntax

is

add

-LRB-

F

-RRB-

remove

-LRB-

F

-RRB-

A

transaction

is

a

set

of

updates

Ui

i.e.

transaction

-LRB-

-LSB-

Un

-RSB-

-RRB-

A

re-definition

of

a

concept

has

to

be

executed

as

removal

of

the

old

concept

definition

and

introduction

of

the

new

concept

definition

Example

We

present

an

example

session

for

database

updates

Note

that

updates

may

be

performed

on

both

the

object

and

terminological

component

add

-LRB-

inst

-LRB-

administration

department

-RRB-

-RRB-

The

integrity

constraint

ucd

exists-leader-in-department

forall

-LRB-

-LSB-

A

-RSB-

in

-LRB-

A

department

-RRB-

exists

-LRB-

-LSB-

B

-RSB-

rel

-LRB-

B

leads

A

-RRB-

-RRB-

-RRB-

is

not

satisfied

Following

instance

-LRB-

s

-RRB-

are

violated

exists

-LRB-

-LSB-

A

-RSB-

rel

-LRB-

A

leads

administration

-RRB-

-RRB-

in

-LRB-

administration

department

-RRB-

exists

-LRB-

-LSB-

A

-RSB-

rel

-LRB-

A

leads

administration

-RRB-

-RRB-

The

fact

has

not

been

added

no

transaction

-LRB-

-LSB-

add

-LRB-

inst

-LRB-

administration

department

-RRB-

-RRB-

add

-LRB-

rel

-LRB-

john

leads

administration

-RRB-

-RRB-

-RSB-

-RRB-

yes

rel

-LRB-

john

leads

X

-RRB-

X

production

X

administration

no

add

-LRB-

manager

leader

and

min

leads

-RRB-

yes

SubConcept

employee

SubConcept

worker

SubConcept

employee

SubConcept

leader

SubConcept

allrounder

SubConcept

boss

SubConcept

manager

no

remove

-LRB-

manager

-RRB-

yes

The

Data

Model

as

Deductive

Database

The

semantics

of

a

terminology

and

of

an

object

component

give

rise

to

a

natural

logical

representation

of

our

data

model

For

example

we

can

express

the

concept

definition

employee

ex

works

in

department

as

employee

-LRB-

x

-RRB-

works

in

-LRB-

x

y

-RRB-

department

-LRB-

y

-RRB-

However

in

order

to

express

the

subsumption

and

instantiation

algorithms

as

a

logic

program

we

use

reified

representations

instead

with

ffl

pre-defined

predicate

symbols

e.g.

concept

sub

in

rel

and

ffl

pre-defined

function

symbols

e.g.

and

or

-LRB-

infix

-RRB-

all

ex

min

max

-LRB-

prefix

-RRB-

Therefore

we

write

the

relation

fact

in

the

form

rel

-LRB-

john

works

in

sales

-RRB-

rather

than

works

in

-LRB-

john

sales

-RRB-

The

Pre-Defined

and

the

User-Defined

Database

Our

data

model

consists

of

the

terminological

object

and

integrity

constraint

components

as

described

in

the

previous

three

sections

However

it

may

alternatively

be

considered

as

a

special

deductive

database

consisting

of

facts

deduction

rules

and

integrity

constraints

We

can

characterize

the

data

model

as

deductive

database

in

which

some

deduction

rules

and

integrity

constraints

are

pre-defined

We

therefore

separate

a

pre-defined

from

a

user-defined

database

Pre-Defined

Database

User-Defined

Database

Facts

F

user-defined

Deduction

Rules

R

pre-defined

-LSB-

R

user-defined

Integrity

Constraints

IC

pre-defined

-LSB-

IC

user-defined

Pre-defined

deduction

rules

are

mainly

the

clauses

for

computing

subsumption

and

instantiation

Pre-defined

integrity

constraints

are

those

listed

in

appendix

A.

User-defined

facts

are

the

concept

definitions

of

the

terminological

component

and

the

relation

and

instance

facts

of

the

object

component

User-defined

deduction

rules

are

those

from

the

object

component

Viewing

the

data

model

from

this

perspective

all

techniques

known

from

deductive

databases

are

applicable

Syntactic

Restrictions

of

Deduction

Rules

To

guarantee

finite

relations

and

safe

evaluation

in

the

context

of

deductive

databases

one

typically

requires

that

all

deduction

rules

are

range-restricted

and

stratified

A

deduction

rule

is

range-restricted

if

all

variables

occurring

in

the

rule

also

occur

in

a

positive

user-defined

literal

in

the

rule

body

A

dependency

graph

of

a

set

of

deduction

rules

is

a

directed

graph

G

N

E

where

the

set

of

nodes

N

consists

of

the

set

of

predicates

occurring

in

the

rules

and

pi

pj

E

iff

predicate

pj

occurs

in

the

body

of

a

deduction

rule

with

pi

in

the

head

Edges

are

labelled

as

positive

if

pj

occurs

positively

in

the

rule

body

and

negative

if

pj

occurs

negated

in

the

rule

body

The

dependency

graph

of

the

pre-defined

deduction

rules

is

given

in

figure

A

set

of

deduction

rules

is

said

to

be

stratified

if

the

dependency

graph

does

not

contain

any

cycle

having

a

negative

edge

Stratification

is

needed

to

guarantee

the

existence

of

a

distinguished

minimal

model

the

so-called

perfect

model

The

perfect

model

can

be

computed

following

a

level

mapping

which

is

derivable

from

the

dependency

graph

Unfortunately

a

set

of

user-defined

deduction

rules

containing

negation

in

the

rule

body

is

not

stratified

for

example

the

dependency

graph

of

the

deduction

rule

rel

-LRB-

E

-RRB-

rel

-LRB-

E

D

-RRB-

not

rel

-LRB-

E

leads

D

-RRB-

Terminological

Component

Object

Component

sub

-LRB-

Subsumption

-RRB-

inst

rel

in

-LRB-

Instantiation

-RRB-

-LRB-

-RRB-

-LRB-

=-RRB-

Figure

The

dependency

graph

of

pre-defined

deduction

rules

rel

inst

Figure

The

dependency

graph

of

user-defined

deduction

rules

contains

a

negative

cycle

from

the

predicate

rel

to

itself

In

the

reified

representation

role

names

are

arguments

of

the

predicate

rel

rather

than

predicate

names

In

this

representation

user-defined

deduction

rules

containing

negation

in

the

rule

body

are

not

stratified

in

general

-LRB-

see

figure

-RRB-

We

therefore

need

the

finer

granularity

property

of

local

stratification

A

set

of

deduction

rules

is

called

locally

stratified

if

the

dependency

graph

for

their

ground-instances

does

not

contain

any

cycle

with

a

negative

edge

To

guarantee

local

stratification

it

is

sufficient

to

test

that

the

set

of

corresponding

deduction

rules

in

non-reified

form

is

-LRB-

ordinarily

-RRB-

stratified

In

the

above

example

this

is

the

deduction

rule

-LRB-

E

-RRB-

-LRB-

E

D

-RRB-

not

leads

-LRB-

E

D

-RRB-

Local

stratification

still

ensures

safe

evaluation

and

the

existence

of

a

perfect

model

Efficient

Evaluation

of

Integrity

Constraints

After

a

transaction

all

integrity

constraints

have

to

be

satisfied

For

integrity

checking

the

efficient

algorithms

presented

in

-LSB-

Bry

et

al.

-RSB-

which

are

based

on

-LSB-

Nicolas

-RSB-

for

relational

databases

are

used

It

is

important

that

the

integrity

constraints

are

in

restricted

quantification

form

This

form

guarantees

domainindependence

of

the

integrity

constraints

and

allows

their

simplification

e.g.

only

relevant

constraints

have

to

be

considered

and

can

be

further

simplified

If

any

integrity

constraint

is

violated

then

the

transaction

is

rejected

The

implementation

of

this

efficient

evaluation

of

integrity

constraints

is

described

in

-LSB-

Schumacher

-RSB-

Extensions

of

the

Data

Model

Terminological

Cycles

Until

recently

terminological

cycles

have

mostly

been

prohibited

in

terminological

systems

because

the

semantics

seemed

not

clear

and

the

subsumption

algorithms

run

into

problems

in

the

presence

of

cycles

However

cyclic

concept

definitions

are

certainly

useful

for

example

in

the

presence

of

inverse

roles

e.g.

employee

all

works

in

department

and

department

all

employs

employee

The

concept

definitions

employee

and

department

mutually

depend

on

each

other

The

so-called

descriptive

semantics

introduced

in

section

and

the

definition

of

subsumption

are

still

applicable

in

the

presence

of

terminological

cycles

However

mostly

only

greatest

fixed-point

models

are

considered

resulting

in

a

greatest

fixedpoint

semantics

-LRB-

see

e.g.

-LSB-

Nebel

-RSB-

-RRB-

The

greatest

fixed-point

semantics

seems

more

intuitive

and

results

in

an

easier

subsumption

algorithm

Starting

from

a

primitive

interpretation

the

greatest

fixed-point

can

be

reached

by

a

top-down

computation

In

order

to

deal

with

terminological

cycles

one

has

to

detect

cycles

and

handle

them

correctly

for

subsumption

and

instantiation

w.r.t.

a

given

semantics

The

detection

of

terminological

cycles

is

easy

A

list

of

unfolded

concepts

is

maintained

and

a

concept

is

not

further

unfolded

if

it

is

contained

in

the

list

The

following

procedural

semantics

of

cyclic

definitions

can

be

given

If

a

concept

definition

is

encountered

such

that

a

subsumption

relationship

can

only

be

proven

through

itself

then

-LRB-

-RRB-

it

is

assumed

not

holding

or

-LRB-

-RRB-

it

is

assumed

holding

Both

alternatives

have

been

implemented

in

-LSB-

Birrer

-RSB-

Cycles

may

also

occur

in

the

object

component

where

they

are

dealt

with

accordingly

Subroles

Allowing

roles

to

be

subroles

of

other

roles

increases

the

expressive

power

of

a

terminology

Subroles

are

admitted

in

many

terminological

systems

for

example

in

TF/AF

of

-LSB-

Nebel

-RSB-

Incorporating

subroles

requires

only

slight

changes

to

the

subsumption

and

instantiation

algorithms

but

results

in

less

efficient

inferences

Semantics

Sometimes

it

may

be

useful

to

define

the

semantics

of

an

all-restriction

alternatively

as

E

-LSB-

all

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

which

is

for

example

the

view

taken

in

-LSB-

Reimer

-RSB-

Then

E

-LSB-

all

R

C

-RSB-

E

-LSB-

all

R

C

and

min

R

-RSB-

E

-LSB-

all

R

C

and

ex

R

C

-RSB-

semantics

also

requires

slight

changes

of

the

subsumption

and

instantiation

algorithms

Comparison

and

Outlook

Our

terminological

component

combined

with

the

fact

part

of

the

object

component

are

similar

to

many

terminological

systems

e.g.

-LSB-

Nebel

-RSB-

However

in

comparison

with

-LSB-

Nebel

-RSB-

we

additionally

allow

the

ex

and

or

terminological

constructs

deduction

rules

and

most

importantly

support

integrity

constraints

We

do

not

include

subroles

in

the

main

formalism

and

we

treat

the

disjoint-constraint

as

an

integrity

constraint

rather

than

as

a

part

of

the

terminological

formalism

-LRB-

similar

to

the

cover

and

partition

constraints

-RRB-

Like

most

terminological

systems

we

do

not

include

concept

negation

-LSB-

Schmidt-Schauss

Smolka

-RSB-

suggest

a

complete

subsumption

algorithm

for

a

terminological

language

including

concept

negation

A

comparison

of

some

implemented

terminological

systems

is

presented

in

-LSB-

Heinsohn

et

al.

-RSB-

Our

main

contribution

is

not

to

terminological

reasoning

which

is

already

a

well

explored

topic

but

viewing

it

from

a

logic

programming

perspective

and

integrating

it

with

typical

deductive

database

features

We

can

also

view

our

data

model

as

typed

deductive

database

with

type

inferences

Typical

deductive

databases

are

many-sorted

allowing

no

type

inferences

e.g.

-LSB-

Burse

-RSB-

However

there

have

also

been

efforts

to

consider

polymorphically

typed

deductive

databases

with

type

inferences

e.g.

-LSB-

Cremers

et

al.

-RSB-

A

slightly

different

approach

than

ours

is

the

integration

of

object-oriented

features

such

as

complex

objects

inheritance

methods

and

encapsulation

with

logic

programming

e.g.

LIFE

-LSB-

A

-RCB-

t-Kaci

-RSB-

and

F-Logic

-LSB-

Kifer

et

al.

-RSB-

The

main

difference

to

our

approach

is

that

these

languages

are

designed

for

general

purpose

programming

rather

than

for

data

representation

and

do

not

include

general

integrity

constraints

Future

directions

are

-LRB-

-RRB-

the

support

of

assert-time

inferences

to

speed

up

query

evaluation

-LRB-

-RRB-

the

possible

separation

of

the

notions

of

concepts

-LRB-

types

-RRB-

and

classes

-LRB-

-RRB-

the

incorporation

of

an

explanation

facility

for

subsumption

and

instantiation

and

-LRB-

-RRB-

the

provision

of

support

to

the

user

dealing

with

transactions

violating

integrity

constraints

e.g.

to

suggest

some

correction

updates

or

even

doing

them

automatically

Acknowledgments

This

work

is

partially

financed

by

the

Schwerpunktprogramm

Informatik

project

Hybrides

Wissensbanksystem

We

would

like

to

thank

for

collaboration

on

this

project

Ulrich

Reimer

and

Peter

Lippuner

of

Swiss

Life

and

Hans

Schek

Moira

Norrie

and

Michael

Rys

of

the

database

group

at

ETH

We

are

grateful

to

Roman

Gross

Tomi

Schumacher

and

Andreas

Steiner

for

the

many

discussions

and

helpful

comments

on

drafts

of

this

report

Finally

special

thanks

to

the

students

Edith

Birrer

and

Alex

Pfister

for

their

contributions

to

implementations

of

these

ideas

References

-LSB-

A

-RCB-

t-Kaci

-RSB-

H.

A

-RCB-

t-Kaci

An

Overview

of

LIFE

Springer-Verlag

LNCS

pp.

-LSB-

Badertscher

et

al.

-RSB-

U.

Badertscher

R.

Marti

U.

Reimer

Integrating

Terminological

and

Deductive

Reasoning

In

N.E.

Fuchs

G.

Gottlob

-LRB-

Eds

-RRB-

Logic

Programming

Workshop

WLP

Universitat

Zurich

-LSB-

Birrer

-RSB-

E.

Birrer

Terminologische

Zyklen

Semesterarbeit

Institut

fur

Informationssysteme

ETH

Zurich

-LSB-

Brachman

Schmolze

-RSB-

R.

J.

Brachman

J.

G.

Schmolze

An

overview

of

the

KL-ONE

Knowledge

Representation

System

Cognitive

Science

-LRB-

-RRB-

pp.

-LSB-

Bry

et

al.

-RSB-

F.

Bry

H.

Decker

R.

Manthey

A

Uniform

Approach

to

Constraint

Satisfaction

and

Constraint

Satisfiability

in

Deductive

Databases

EDBT

Springer

LNCS

pp.

-LSB-

Burse

-RSB-

J.

Burse

ProQuel

Using

Prolog

to

Implement

a

Deductive

Database

System

Technical

Report

ETH

Zurich

-LSB-

Cattell

-RSB-

R.G.

Cattell

The

Object

Database

Standard

Release

Morgan

Kaufmann

Publishers

-LSB-

Ceri

et

al.

-RSB-

S.

Ceri

G.

Gottlob

L.

Tanca

Logic

Programming

and

Databases

Springer

-LSB-

Cremers

et

al.

-RSB-

A.B.

Cremers

U.

Griefahn

R.

Hinze

Deduktive

Datenbanken

Eine

Einfuhrung

aus

der

Sicht

der

logischen

Programmierung

Vieweg

-LSB-

Das

-RSB-

S.

K.

Das

Deductive

Databases

and

Logic

Programming

Addison-Wesley

-LSB-

Fikes

Kehler

-RSB-

R.

Fikes

T.

Kehler

The

Role

of

Frame-Based

Representation

in

Reasoning

Communications

of

the

ACM

Vol

No.

pp.

-LSB-

Hayes

-RSB-

P.

J.

Hayes

The

Logic

of

Frames

In

D.

Mething

-LRB-

ed

-RRB-

Frame

Conceptions

and

Text

Understanding

Walter

de

Gruyter

pp

-LSB-

Heinsohn

et

al.

-RSB-

J.

Heinsohn

D.

Kudenko

B.

Nebel

H.-J

Profitlich

An

empirical

analysis

of

terminological

representation

systems

Artificial

Intelligence

pp.

-LSB-

Kifer

et

al.

-RSB-

M.

Kifer

G.

Lausen

J.

Wu

Logical

Foundations

of

Object-Oriented

and

Frame-Based

Languages

To

appear

in

Journal

of

the

ACM

-LSB-

Levesque

Brachman

-RSB-

H.

J.

Levesque

R.

J.

Brachman

Expressiveness

and

tractability

in

knowledge

representation

and

reasoning

Comput

Intell

pp.

-LSB-

Lloyd

-RSB-

J.

W.

Lloyd

Foundations

of

Logic

Programming

-LRB-

edition

-RRB-

Springer

-LSB-

Nicolas

-RSB-

J.-M

Nicolas

Logic

for

Improving

Integrity

Checking

in

Relational

Data

Bases

Acta

Informatica

pp.

-LSB-

Nebel

-RSB-

B.

Nebel

Reasoning

and

Revision

in

Hybrid

Representation

Systems

Springer

LNCS

-LSB-

Norrie

et

al.

-RSB-

M.

Norrie

U.

Reimer

P.

Lippuner

M.

Rys

H.-J

Schek

Frames

Objects

and

Relations

Three

Semantic

Levels

for

Knowledge

Base

Systems

In

Proc

Workshop

on

Reasoning

about

Structured

Objects

Knowledge

Representation

Meets

Databases

Saarbrucken

-LSB-

Pfister

-RSB-

A.

Pfister

Implementation

eines

Terminologischen

Systems

in

ProQuel

Semesterarbeit

Institut

fur

Informationssysteme

ETH

Zurich

-LSB-

Reimer

-RSB-

U.

Reimer

FRM

Ein

Frame-Reprasentationsmodell

und

seine

formale

Semantik

Springer

Informatik-Fachbericht

-LSB-

Reimer

et

al.

-RSB-

U.

Reimer

M.

Rys

H.-J

Schek

R.

Marti

Datenbankbasierung

eines

Frame-Modells

Abbildung

auf

ein

Objektmodell

und

effiziente

Unterstutzung

komplexer

Operationen

Proc

GI

Workshop

Springer

-LSB-

Reimer

et

al.

-RSB-

U.

Reimer

P.

Lippuner

R.

Marti

M.

Norrie

H.-J

Schek

U.

Badertscher

M.

Rys

HYWIBAS

A

Hybrid

Knowledge

Base

System

for

Large

Shared

Knowledge

Bases

Proceedings

Priority

Programme

Informatics

Research

Information

Conference

Module

Knowledge

based

systems

Yverdonles-Bains

pp.

-LSB-

Schmidt-Schauss

Smolka

-RSB-

M.

Schmidt-Schauss

and

G.

Smolka

Attributive

concept

descriptions

with

complements

Journal

of

Artificial

Intelligence

pp.

-LSB-

Scholl

et

al.

-RSB-

M.

H.

Scholl

C.

Laasch

C.

Rich

H.-J

Schek

M.

Tresch

The

COCOON

Object

Model

Technical

Report

Dept.

of

Computer

Science

ETH

Zurich

-LSB-

Schumacher

-RSB-

T.

Schumacher

Integritatsbedingungen

fur

ein

hybrides

Wissensbanksystem

Diplomarbeit

Institut

fur

Informationssysteme

ETH

Zurich

-LSB-

Woods

Schmolze

-RSB-

W.A.

Woods

J.G.

Schmolze

The

KL-ONE

family

Computers

Math

Applic

-LRB-

-RRB-

pp.

A

Appendix

A.

Definition

of

Concepts

and

Roles

concept

-LRB-

C

-RRB-

-LRB-

C

-RRB-

concept

-LRB-

and

-RRB-

concept

-LRB-

-RRB-

concept

-LRB-

-RRB-

concept

-LRB-

or

-RRB-

concept

-LRB-

-RRB-

concept

-LRB-

-RRB-

concept

-LRB-

all

R

C

-RRB-

role

-LRB-

R

-RRB-

concept

-LRB-

C

-RRB-

concept

-LRB-

ex

R

C

-RRB-

role

-LRB-

R

-RRB-

concept

-LRB-

C

-RRB-

concept

-LRB-

min

R

N

-RRB-

role

-LRB-

R

-RRB-

number

-LRB-

N

-RRB-

concept

-LRB-

max

R

N

-RRB-

role

-LRB-

R

-RRB-

number

-LRB-

N

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

-LRB-

C

-RRB-

C

-LRB-

C

-RRB-

C

concept

-LRB-

-RRB-

-LRB-

C

-RRB-

C

concept

-LRB-

-RRB-

-LRB-

anything

-RRB-

-LRB-

nothing

-RRB-

-LRB-

integer

-RRB-

-LRB-

string

-RRB-

-LRB-

boolean

-RRB-

role

-LRB-

R

-RRB-

R

A.

Compatibility

Conditions

E

-LSB-

anything

-RSB-

D

E

-LSB-

nothing

-RSB-

E

-LSB-

C

and

D

-RSB-

E

-LSB-

C

-RSB-

E

-LSB-

D

-RSB-

-LRB-

S.

-RRB-

E

-LSB-

C

or

D

-RSB-

E

-LSB-

C

-RSB-

-LSB-

E

-LSB-

D

-RSB-

-LRB-

S.

-RRB-

E

-LSB-

all

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

-LRB-

S.

-RRB-

E

-LSB-

ex

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

-LRB-

S.

-RRB-

E

-LSB-

min

R

N

-RSB-

fx

D

j

jjfy

D

x

y

E

-LSB-

R

-RSB-

gjj

Ng

-LRB-

S.

-RRB-

E

-LSB-

max

R

N

-RSB-

fx

D

j

jjfy

D

x

y

E

-LSB-

R

-RSB-

gjj

Ng

-LRB-

S.

-RRB-

Cp

C

E

-LSB-

Cp

-RSB-

E

-LSB-

C

-RSB-

-LRB-

S.

-RRB-

Cd

C

E

-LSB-

Cd

-RSB-

E

-LSB-

C

-RSB-

-LRB-

S.

-RRB-

A.

Concept

Normalization

-LRB-

max

R

M

-RRB-

and

-LRB-

min

R

N

-RRB-

nothing

-LRB-

where

M

N

-RRB-

-LRB-

N.

-RRB-

ex

R

nothing

nothing

-LRB-

N.

-RRB-

all

R

anything

anything

-LRB-

N.

-RRB-

min

R

anything

-LRB-

N.

-RRB-

all

R

nothing

max

R

-LRB-

N.

-RRB-

ex

R

anything

min

R

-LRB-

N.

-RRB-

C

or

-LRB-

D

and

E

-RRB-

-LRB-

C

or

D

-RRB-

and

-LRB-

C

or

E

-RRB-

-LRB-

N.

-RRB-

-LRB-

C

and

D

-RRB-

or

-LRB-

C

and

E

-RRB-

C

and

-LRB-

D

or

E

-RRB-

-LRB-

N.

-RRB-

-LRB-

all

R

C

-RRB-

and

-LRB-

all

R

D

-RRB-

all

R

-LRB-

C

and

D

-RRB-

-LRB-

N.

-RRB-

-LRB-

ex

R

C

-RRB-

or

-LRB-

ex

R

D

-RRB-

ex

R

-LRB-

C

or

D

-RRB-

-LRB-

N.

-RRB-

A.

The

Subsumption

Algorithm

sub

-LRB-

C

D

-RRB-

C

is

a

subconcept

of

concept

D

sub

-LRB-

C

C

-RRB-

sub

-LRB-

C

and

-RRB-

sub

-LRB-

C

-RRB-

sub

-LRB-

C

-RRB-

a

-RRB-

sub

-LRB-

and

D

-RRB-

sub

-LRB-

D

-RRB-

sub

-LRB-

D

-RRB-

b

-RRB-

sub

-LRB-

C

or

-RRB-

sub

-LRB-

C

-RRB-

sub

-LRB-

C

-RRB-

a

-RRB-

sub

-LRB-

or

D

-RRB-

sub

-LRB-

D

-RRB-

sub

-LRB-

D

-RRB-

b

-RRB-

sub

-LRB-

all

R

C

all

R

:D

-RRB-

sub

-LRB-

C

D

-RRB-

sub

-LRB-

ex

R

C

ex

R

:D

-RRB-

sub

-LRB-

C

D

-RRB-

sub

-LRB-

min

R

M

min

R

N

-RRB-

N

M.

sub

-LRB-

max

R

M

max

R

N

-RRB-

N

M.

sub

-LRB-

Cp

D

-RRB-

Cp

C

sub

-LRB-

C

D

-RRB-

sub

-LRB-

Cd

D

-RRB-

Cd

C

sub

-LRB-

C

D

-RRB-

a

-RRB-

sub

-LRB-

C

Dd

-RRB-

Dd

D

sub

-LRB-

C

D

-RRB-

b

-RRB-

sub

-LRB-

nothing

C

-RRB-

a

-RRB-

sub

-LRB-

C

anything

-RRB-

b

-RRB-

A.

Correctness

of

Subsumption

a

-RRB-

E

-LSB-

C

-RSB-

E

-LSB-

-RSB-

E

-LSB-

-RSB-

sub

-LRB-

C

-RRB-

sub

-LRB-

C

-RRB-

E

-LSB-

and

-RSB-

-LRB-

S.

-RRB-

b

-RRB-

E

-LSB-

and

-RSB-

E

-LSB-

-RSB-

E

-LSB-

-RSB-

-LRB-

S.

-RRB-

E

-LSB-

-RSB-

E

-LSB-

D

-RSB-

sub

-LRB-

D

-RRB-

E

-LSB-

all

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

-LRB-

S.

-RRB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

D

-RSB-

g

sub

-LRB-

C

;D

-RRB-

E

-LSB-

all

R

D

-RSB-

-LRB-

S.

-RRB-

E

-LSB-

ex

R

C

-RSB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

C

-RSB-

g

-LRB-

S.

-RRB-

fx

D

j

D

x

y

E

-LSB-

R

-RSB-

y

E

-LSB-

D

-RSB-

g

sub

-LRB-

C

;D

-RRB-

E

-LSB-

ex

R

D

-RSB-

-LRB-

S.

-RRB-

E

-LSB-

max

R

M

-RSB-

fx

D

j

jjfy

D

x

y

E

-LSB-

R

-RSB-

gjj

Mg

-LRB-

S.

-RRB-

fx

D

j

jjfy

D

x

y

E

-LSB-

R

-RSB-

gjj

Ng

N

M

E

-LSB-

max

R

N

-RSB-

-LRB-

S.

-RRB-

A.

The

Instantiation

Algorithm

in

-LRB-

I

C

-RRB-

Object

I

is

instance

of

concept

C

in

-LRB-

I

C

-RRB-

object

-LRB-

I

-RRB-

concept

-LRB-

C

-RRB-

sub

-LRB-

D

C

-RRB-

-LRB-

I

D

-RRB-

-LRB-

I

C

-RRB-

Object

I

is

direct

instance

of

concept

C

-LRB-

C

is

a

most

specific

concept

of

I

-RRB-

-LRB-

I

C

and

D

-RRB-

-LRB-

I

C

-RRB-

-LRB-

I

D

-RRB-

and

-LRB-

I

C

or

D

-RRB-

-LRB-

-LRB-

I

C

-RRB-

-LRB-

I

D

-RRB-

-RRB-

or

-LRB-

I

all

R

C

-RRB-

-LRB-

rel

-LRB-

I

R

V

-RRB-

in

-LRB-

V

C

-RRB-

-RRB-

all

-LRB-

CWA

-RRB-

-LRB-

I

ex

R

C

-RRB-

rel

-LRB-

I

R

V

-RRB-

in

-LRB-

V

C

-RRB-

exists

-LRB-

I

min

R

M

-RRB-

-LRB-

I

R

N

-RRB-

N

M.

min

-LRB-

I

max

R

M

-RRB-

-LRB-

I

R

N

-RRB-

N

M.

max

-LRB-

CWA

-RRB-

-LRB-

I

C

-RRB-

inst

-LRB-

I

C

-RRB-

user-spec

-LRB-

I

Cd

-RRB-

Cd

C

-LRB-

I

C

-RRB-

def.conc

A.

Pre-defined

Integrity

Constraints

ic

-LRB-

mic

unique-introduction-of-concepts

forall

-LRB-

-LSB-

C

-RSB-

C

C

-RRB-

-RRB-

ic

-LRB-

mic

use-only-concepts-for-definition

forall

-LRB-

-LSB-

C

D

-RSB-

C

D

concept

-LRB-

D

-RRB-

-RRB-

-RRB-

ic

-LRB-

mic

not-instances-of-incoherent-concepts

forall

-LRB-

-LSB-

I

-RSB-

in

-LRB-

I

nothing

-RRB-

false

-RRB-

-RRB-

ic

-LRB-

mic

max-restriction

forall

-LRB-

-LSB-

I

R

-RSB-

-LRB-

I

R

N

-RRB-

in

-LRB-

I

max

R

M

-RRB-

N

M

-RRB-

-RRB-

ic

-LRB-

mic

concept-existence-for-inst

forall

-LRB-

-LSB-

I

C

-RSB-

inst

-LRB-

I

C

-RRB-

-LRB-

C

-RRB-

-RRB-

-RRB-

ic

-LRB-

mic

role-existence-for-rel

forall

-LRB-

-LSB-

I

R

V

-RSB-

rel

-LRB-

I

R

V

-RRB-

role

-LRB-

R

-RRB-

-RRB-

-RRB-

ic

-LRB-

mic

type-correspondence-for-rel

forall

-LRB-

-LSB-

I

R

C

V

-RSB-

rel

-LRB-

I

R

V

-RRB-

inst

-LRB-

I

all

R

C

-RRB-

in

-LRB-

V

C

-RRB-

-RRB-

-RRB-

A.

An

Example

Database

The

Terminology

department

primitive

concepts

office

department

worker

employee

employee

defined

concepts

all

address

string

and

ex

department

and

and

all

age

integer

and

max

age

leader

all

address

string

and

min

address

and

ex

leads

department

and

ex

office

and

all

age

integer

and

max

age

allrounder

worker

and

leader

boss

leader

address

roles

-LRB-

relations

-RRB-

leads

age

The

Object

Component

inst

-LRB-

sales

office

-RRB-

Sales

is

an

office

and

inst

-LRB-

production

department

-RRB-

production

is

a

department

rel

-LRB-

bob

production

-RRB-

Bob

works

in

production

his

address

and

age

are

unknown

rel

-LRB-

bill

address

london

-RRB-

Bill

has

addresses

London

rel

-LRB-

bill

address

paris

-RRB-

and

Paris

he

leads

the

rel

-LRB-

bill

leads

sales

-RRB-

sales

department

rel

-LRB-

bill

age

-RRB-

and

has

age

inst

-LRB-

john

leader

-RRB-

John

is

a

leader

and

inst

-LRB-

john

worker

-RRB-

a

worker

he

leads

the

rel

-LRB-

john

leads

production

-RRB-

production

department

rel

-LRB-

john

age

-RRB-

and

has

age

rel

-LRB-

mary

age

-RRB-

Mary

has

age

deduction

rules

Everyone

working

in

the

sales

department

works

also

in

the

production

department

Every

leader

of

a

department

works

also

in

the

department

rel

-LRB-

E

production

-RRB-

rel

-LRB-

E

sales

-RRB-

rel

-LRB-

E

D

-RRB-

rel

-LRB-

E

leads

D

-RRB-

The

Integrity

Constraint

Component

Employees

and

departments

are

disjoint

-LRB-

classification

constr

-RRB-

For

every

department

exists

a

leader

-LRB-

referential

integrity

-RRB-

Only

persons

younger

than

work

in

sales

dept.

-LRB-

domain

restr

-RRB-

Every

department

has

at

most

one

leader

-LRB-

functional

dependency

-RRB-

There

exists

at

least

one

employee

disjoint

-LRB-

employee

department

-RRB-

ic

-LRB-

udc

exists-leader-in-D

forall

-LRB-

-LSB-

D

-RSB-

in

-LRB-

D

department

-RRB-

exists

-LRB-

-LSB-

L

-RSB-

rel

-LRB-

L

leads

D

-RRB-

-RRB-

-RRB-

-RRB-

ic

-LRB-

udc

only-young-salespersons

forall

-LRB-

-LSB-

E

A

-RSB-

rel

-LRB-

E

sales

-RRB-

rel

-LRB-

E

age

A

-RRB-

A

-RRB-

-RRB-

ic

-LRB-

udc

forall

-LRB-

-LSB-

D

-RSB-

rel

-LRB-

leads

D

-RRB-

rel

-LRB-

leads

D

-RRB-

-RRB-

-RRB-

ic

-LRB-

udc

exists-employee

exists

-LRB-

-LSB-

E

-RSB-

in

-LRB-

E

employee

-RRB-

-RRB-

-RRB-

deductive databases
framebased languages
integrity constraints
terminological logics