Racer Manual 1 6 PDF

RACER Users Guide and Reference Manual
Version 1.6
Volker Haarslev
Ralf Moller
{haarslev, moeller}@informatik.uni-hamburg.de
University of Hamburg, Computer Science Department
Vogt-Kolln-Str. 30, 22527 Hamburg, Germany
July 26, 2001
Contents
1 Introduction
2 Obtaining and Running RACER
2.1
System Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Sample Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 RACER Knowledge Bases
3.1
Concept Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Concept Axioms and Terminology . . . . . . . . . . . . . . . . . . . . . . .
3.3
Role Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Concrete Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.5
ABox Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.6
Inference Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.7
Retraction and Incremental Additions . . . . . . . . . . . . . . . . . . . . .
13
4 Knowledge Base Management Functions

4.1
14
TBox Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
in-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
init-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
ensure-tbox-signature . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
*current-tbox* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
save-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
find-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
tbox-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
ABox Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
in-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
init-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
ensure-abox-signature . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
in-knowledge-base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
*current-abox* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
save-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
find-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
abox-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5 Knowledge Base Declarations

5.1
5.2
5.3
Built-in Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
*top*, top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
*bottom*, bottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Concept Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
implies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
disjoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
define-primitive-concept . . . . . . . . . . . . . . . . . . . . . . . . . .
23
define-concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
define-disjoint-primitive-concept . . . . . . . . . . . . . . . . . . . .
24
add-concept-axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
add-disjointness-axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Role Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
define-primitive-role . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
define-primitive-attribute . . . . . . . . . . . . . . . . . . . . . . . . .
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
add-concept-assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
forget-concept-assertion . . . . . . . . . . . . . . . . . . . . . . . . . .
29
related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
add-role-assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
forget-role-assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
define-distinct-individual . . . . . . . . . . . . . . . . . . . . . . . . .
31
add-role-axioms
5.4
21
ii
state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
forget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
6 Reasoning Modes
32
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
*auto-realize* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
*auto-classify*
7 Evaluation Functions and Queries

7.1
7.2
Queries for Concept Terms . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
concept-satisfiable? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
concept-satisfiable-p . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
concept-subsumes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
concept-subsumes-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
concept-equivalent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
concept-equivalent-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
concept-disjoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
concept-disjoint-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
concept-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
concept? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
concept-is-primitive-p . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
concept-is-primitive? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
alc-concept-coherent . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Role Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
role-subsumes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
role-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
role? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
transitive-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
transitive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
feature-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
feature? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
symmetric-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
symmetric? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
reflexive-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
reflexive? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
atomic-role-inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
role-inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
TBox Evaluation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
role-subsumes-p
7.3
32
iii
classify-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
check-tbox-coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
tbox-classified-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
tbox-classified? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
tbox-coherent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
ABox Evaluation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
realize-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
abox-realized? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
ABox Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
abox-consistent-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
abox-consistent? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
check-abox-coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
individual-instance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
individual-instance-p . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
individuals-related? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
individuals-related-p . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
individual-equal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
individual-not-equal? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
individual-p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
individual? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
tbox-coherent-p
7.4
abox-realized-p
7.5
8 Retrieval
8.1
46
TBox Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
concept-synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
atomic-concept-synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
concept-descendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
atomic-concept-descendants . . . . . . . . . . . . . . . . . . . . . . . . .
47
concept-ancestors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
atomic-concept-ancestors . . . . . . . . . . . . . . . . . . . . . . . . . .
48
concept-children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
atomic-concept-children . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
atomic-concept-parents . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
role-descendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
atomic-role-descendants . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
concept-parents
iv
8.2
role-ancestors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
atomic-role-ancestors . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
role-children . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
atomic-role-children . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
role-parents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
atomic-role-parents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
loop-over-tboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
all-tboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
all-atomic-concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
all-roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
all-features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
all-transitive-roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
describe-tbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
describe-concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
describe-role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
ABox Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
individual-direct-types . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
most-specific-instantiators . . . . . . . . . . . . . . . . . . . . . . . .
55
individual-types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
instantiators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
concept-instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
retrieve-concept-instances . . . . . . . . . . . . . . . . . . . . . . . . .
56
individual-fillers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
retrieve-individual-fillers . . . . . . . . . . . . . . . . . . . . . . . .
56
retrieve-related-individuals . . . . . . . . . . . . . . . . . . . . . . . .
57
related-individuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
retrieve-individual-filled-roles . . . . . . . . . . . . . . . . . . . . .
58
retrieve-direct-predecessors . . . . . . . . . . . . . . . . . . . . . . . .
58
loop-over-aboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
all-aboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
all-concept-assertions-for-individual . . . . . . . . . . . . . . . . . .
59
all-role-assertions-for-individual-in-domain . . . . . . . . . . . . .
59
all-role-assertions-for-individual-in-range . . . . . . . . . . . . . .
60
all-concept-assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
all-role-assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
describe-abox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
describe-individual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
all-individuals
A KRSS Sample Knowledge Base
62
A.1 KRSS Sample TBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
A.2 KRSS Sample ABox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
B Integrated Sample Knowledge Base
63
vi
Introduction
The RACER1 system is a knowledge representation system that implements a highly optimized tableaux calculus for a very expressive description logic. It oers reasoning services
for multiple TBoxes and for multiple ABoxes as well. The system implements the description logic ALCQHI R+ also known as SHIQ (see [Horrocks et al. 2000]). This is the basic
logic ALC augmented with qualifying number restrictions, role hierarchies, inverse roles,
and transitive roles.
RACER supports the specication of general terminological axioms. A TBox may contain
general concept inclusions (GCIs), which state the subsumption relation between two concept terms. Multiple denitions or even cyclic denitions of concepts can be handled by
RACER.
RACER supports most of the functions specied in the Knowledge Representation System
Specication (KRSS), for details see [Patel-Schneider and Swartout 93].
RACER is implemented in ANSI Common Lisp and has been developed at the University
of Hamburg.
Obtaining and Running RACER
The RACER system can be obtained from the following web site:
http://kogs-www.informatik.uni-hamburg.de/~race/
2.1
System Installation
For the Macintosh execute the self-extracting archive <filename>.sea.

For UNIX and Windows systems decompress the archive le after downloading. For UNIX
use the command: gzip -dc <filename>.tar.gz | tar -xf Under Windows unzip the le: <filename>.zip
This creates the les and directories of the distribution. Then follow the instructions in
the le readme.txt found in the directory <filename>. It is important that you load the
le load-racer.lisp from the Lisp Listener. Do not evaluate or compile this le. This le
declares logical pathnames which are used in the example TBoxes.
2.2
Sample Session
All the les used in this example are in the directory "racer:examples;". The queries are
in the le "family-queries.lisp".
;;;===============================================================
;;; the following forms are assumed to be contained in a
;;; file "racer:examples;family-tbox.lisp".
;;; initialize the TBox "family"
(in-tbox family)
1
RACER stands for Reasoner for ABoxes and Concept Expressions Renamed
;;; supply the signature for this TBox

(signature
:atomic-concepts (person human female male woman man parent mother
father grandmother aunt uncle sister brother)
:roles ((has-child :parent has-descendant)
(has-descendant :transitive t)
(has-sibling)
(has-sister :parent has-sibling)
(has-brother :parent has-sibling)
(has-gender :feature t)))
;;; domain & range restrictions for roles
(implies *top* (all has-child person))
(implies (some has-child *top*) parent)
(implies (some has-sibling *top*) (or sister brother))
(implies *top* (all has-sibling (or sister brother)))
(implies *top* (all has-sister (some has-gender female)))
(implies *top* (all has-brother (some has-gender male)))
;;; the concepts
(implies person (and human (some has-gender (or female male))))
(disjoint female male)
(implies woman (and person (some has-gender female)))
(implies man (and person (some has-gender male)))
(equivalent parent (and person (some has-child person)))
(equivalent mother (and woman parent))
(equivalent father (and man parent))
(equivalent grandmother (and mother (some has-child (some has-child person))))
(equivalent aunt (and woman (some has-sibling parent)))
(equivalent uncle (and man (some has-sibling parent)))
(equivalent brother (and man (some has-sibling person)))
(equivalent sister (and woman (some has-sibling person)))
Figure 1: Role hierarchy for the family TBox.

*r* denotes the internally dened universal role.
! denotes features
denotes transitive roles
The RACER Session:

2
Figure 2: Concept hierarchy for the family TBox.
;;; load the TBox

CL-USER(1): (load "racer:examples;family-tbox.lisp")
;;; Loading racer:examples;family-tbox.lisp
T
;;;
some TBox queries
;;; are all uncles brothers?
CL-USER(2): (concept-subsumes? brother uncle)
T
;;; get all super-concepts of the concept mother
;;; (This kind of query yields a list of so-called name sets
;;;
which are lists of equivalent atomic concepts.)
CL-USER(3): (concept-ancestors mother)
((PARENT) (WOMAN) (PERSON) (*TOP* TOP) (HUMAN))
;;; get all sub-concepts of the concept man
CL-USER(4): (concept-descendants man)
((UNCLE) (*BOTTOM* BOTTOM) (BROTHER) (FATHER))
;;; get all transitive roles in the TBox family
CL-USER(5): (all-transitive-roles)
(HAS-DESCENDANT)
;;;===============================================================
;;; file "racer:examples;family-abox.lisp".
;;; initialize the ABox smith-family and use the TBox family
(in-abox smith-family family)
;;; supply the signature for this ABox
(signature :individuals (alice betty charles doris eve))
;;; Alice is the mother of Betty and Charles

3
(instance alice mother)

(related alice betty has-child)
(related alice charles has-child)
;;; Betty is mother of Doris and Eve
(instance betty mother)
(related betty doris has-child)
(related betty eve has-child)
;;; Charles is the brother of Betty (and only Betty)
(instance charles brother)
(related charles betty has-sibling)
;;; closing the role has-sibling for Charles
(instance charles (at-most 1 has-sibling))
;;; Doris has the sister Eve
(related doris eve has-sister)
;;; Eve has the sister Doris
(related eve doris has-sister)
doris
haschild
betty:mother
haschild
has-sister
haschild
alice:mother
haschild
hassibling
eve
charles :(and brother (at-most 1 has-sibling))
Figure 3: Depiction of the ABox smith-family.

(with the explicitly given information being shown)
The RACER Session:

;;; now load the ABox
CL-USER(6): (load "racer:examples;family-abox.lisp")
;;; Loading racer:examples;family-abox.lisp
T
;;;
some ABox queries
;;; Is Doris a woman?
CL-USER(7): (individual-instance? doris woman)
T
;;; Of which concepts is Eve an instance?
CL-USER(8): (individual-types eve)
((SISTER) (WOMAN) (PERSON) (HUMAN) (*TOP* TOP))
;;; get all direct types of eve
CL-USER(9): (individual-direct-types eve)
(SISTER)
;;; get all descendants of Alice
CL-USER(10): (individual-fillers alice has-descendant)
(DORIS EVE CHARLES BETTY)
;;; get all instances of the concept sister
CL-USER(11): (concept-instances sister)
(DORIS BETTY EVE)
In the Appendix dierent versions of this knowledge base can be found. In Appendix A,
on page 62, you nd a version in KRSS syntax and in Appendix B, on page 63, a version
where the TBox and ABox are integrated.
2.3
Naming Conventions
Throughout this document we use the following abbreviations, possibly subscripted.

C
CN
IN
IN
R
RN
AN
ABN
TBN
Concept term
Concept name
Individual name
Object name
Role term
Role name
Attribute name
ABox name
TBox name
name
S
GNL
LCN
abox
tbox
n
real
integer
Name of any sort

List of Assertions
List of group names
List of concept names
ABox object
TBox object
A natural number
A real number
An integer number
All names are Lisp symbols, the concepts are symbols or lists. Please note that for macros
in contrast to functions the arguments should not be quoted.
The API is designed to the following conventions. For most of the services oered by
RACER, macro interfaces and function interfaces are provided. For macro forms, the TBox
or ABox arguments are optional. If no TBox or ABox is specied, the *current-tbox* or
*current-abox* is taken, respectively. However, for the functional counterpart of a macro
the TBox or ABox argument is not optional. For functions which do not have macro counterparts the TBox or ABox argument may or may not be optional. Furthermore, if an
argument tbox or abox is specied in this documentation, a name (a symbol) can be used
as well.
RACER Knowledge Bases
In description logic systems a knowledge base is consisting of a TBox and an ABox. The
conceptual knowledge is represented in the TBox and the knowledge about the instances of a
domain is represented in the ABox. For more information about the description logic SHIQ
supported by RACER see [Horrocks et al. 2000]. Note that RACER assumes the unique
name assumption for ABox individuals (see also [Haarslev and M
oller 2000] where the logic
supported by RACERs precursor RACE is described). The unique name assumption does
not hold for the description logic SHIQ as introduced in [Horrocks et al. 2000].
3.1
Concept Language
The content of RACER TBoxes includes the conceptual modeling of concepts and roles as
well. The modelling is based on the signature, which consists of two disjoint sets: the set of
concept names C, also called the atomic concepts, and the set R containing the role names2 .
Starting from the set C complex concept terms can be build using several operators. An
overview over all concept- and role-building operators is given in Figure 4.
Boolean terms build concepts by using the boolean operators.
Negation
Conjunction
Disjunction
DL notation
C
C1 . . . Cn
C1 . . . Cn
RACER syntax
(not C )
(and C1 . . . Cn )
(or C1 . . . Cn )
Qualied restrictions state that role llers have to be of a certain concept. Value restrictions assure that the type of all role llers is of the specied concept, while exist restrictions
require that there be a ller of that role which is an instance of the specied concept.
Exists restriction
Value restriction
DL notation
R.C
R.C
RACER syntax
(some R C )
(all R C )
Number restrictions can specify a lower bound, an upper bound or an exact number for
the amount of role llers each instance of this concept has for a certain role. Only roles that
are not transitive and do not have any transitive subroles are allowed in number restrictions
(see also the comments in [Horrocks-et-al. 99a, Horrocks-et-al. 99b]).
2
The signature does not have to be specied explicitly in RACER knowledge bases - the system can
compute it from the all the used names in the knowledge base - but specifying a signature may help avoiding
errors caused by typos!
CN
*top*
*bottom*
(not C )
(and C1 . . . Cn )
(or C1 . . . Cn )
(some R C )
(all R C )
(at-least n R)
(at-most n R)
(exactly n R)
(at-least n R C )
(at-most n R C )
(exactly n R C )
(> aexpr aexpr )
(>= aexpr aexpr )
(< aexpr aexpr )
(<= aexpr aexpr )
(= aexpr aexpr )
(min AN integer )
(max AN integer )
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RN
(inv RN )
Figure 4: RACER concept and role terms (for the attribute expressions aexpr see below).
At-most restriction
At-least restriction
Exactly restriction
Qualied at-most restriction
Qualied at-least restriction
Qualied exactly restriction
DL notation
nR
nR
=nR
n R.C
n R.C
= n R.C
RACER syntax
(at-most n R)
(at-least n R)
(exactly n R)
(at-most n R C )
(at-least n R C )
(exactly n R C )
Actually, the exactly restriction (exactly n R) is an abbreviation for the concept term
(and (at-least n R) (at-most n R)) and (exactly n R C ) is an abbreviation for
the concept term (and (at-least n R C ) (at-most n R C ))
There are two concepts implicitly declared in every TBox: the concept top () denotes the
top-most concept in the hierarchy and the concept bottom () denotes the inconsistent
concept, which is a subconcept to all other concepts. Note that () can also be expressed
as C C (C C ). In RACER is denoted as *top* and is denoted as *bottom*3 .
3
For KRSS compatibility reasons RACER also supports the synonym concepts top and bottom.
aexpr
AN
real
(+ aexpr1 aexpr1 )
aexpr1
|
|
|
aexpr1
real
AN
(* real AN )
|
|
Figure 5: Attribute expressions.
3.2
Concept Axioms and Terminology
RACER supports several kinds of concept axioms.

General concept inclusions (GCIs) state the subsumption relation between two concept
terms.
DL notation: C1 C2
RACER syntax: (implies C1 C2 )
Concept equations state the equivalence between two concept terms.
.
DL notation: C1 = C2
RACER syntax: (equivalent C1 C2 )
Concept disjointness axioms state the disjointness between several concepts. Disjoint
concepts do not have instances in common.
.
DL notation: C1 Cn =
RACER syntax: (disjoint C1 . . . Cn )
.
Actually, a concept equation C1 = C2 can be expressed by the two GCIs: C1 C2 and
C2 C1 . The disjointness of the concepts C1 . . . Cn can also be expressed by GCIs.
There are also separate forms for concept axioms with just concept names on their left-hand
sides. These concept axioms implement special kinds of GCIs and concept equations. But
concept names are only a special kind of concept terms, so these forms are just syntactic
sugar. They are added to the RACER system for historical reasons and for compatibility
with KRSS. These concept axioms are:
Primitive concept axioms state the subsumption relation between a concept name and
a concept term.
DL notation: (CN C )
RACER syntax: (define-primitive-concept CN C )
Concept denitions state the equality between a concept name and a concept term.
.
DL notation: (CN = C )
RACER syntax: (define-concept CN C )
Concept axioms may be cyclic in RACER. There may also be forward references to concepts which will be introduced with define-concept or define-primitive-concept in
8
subsequent axioms. The terminology of a RACER TBox may also contain several axioms
for a single concept. So if a second axiom about the same concept is given, it is added and
does not overwrite the rst axiom.
3.3
Role Declarations
In contrast to concept axioms, role declarations are unique in RACER. There exists just one
declaration per role name in a knowledge base. If a second declaration for a role is given,
an error is signaled. If no signature is specied, undeclared roles are assumed to be neither
a feature nor a transitive role and they do not have any superroles.
The set of all roles (R) includes the set of features (F) and the set of transitive roles (R+ ).
The sets F and R+ are disjoint. All roles in a TBox may also be arranged in a role hierarchy.
The inverse of a role name RN can be either explicitly declared via the keyword :inverse
(e.g. see the description of define-primitive-role in Section 5.3, page 25) or referred to
as (inv RN ).
Features (also called attributes) restrict a role to be a functional role, e.g. each individual
can only have up to one ller for this role.
Transitive Roles are transitively closed roles. If two pairs of individuals IN 1 and IN 2 and
IN 2 and IN 3 are related via a transitive role R, then IN 1 and IN 3 are also related
via R.
Role Hierarchies dene super- and subrole-relationships between roles. If R1 is a superrole of R2 , then for all pairs of individuals between which R2 holds, R1 must hold too.
In the current implementation the specied superrole relations may not be cyclic. If a role
has a superrole, its properties are not in every case inherited by the subrole. The properties
of a declared role induced by its superrole are shown in Figure 6. The table should be read
as follows: For example if a role RN 1 is declared as a simple role and it has a feature RN 2
as a superrole, then RN 1 will be a feature itself.
Superrole RN 1
Subrole RN 1
declared as
element of:
R
R
R+
F
R
R+
F
R+
R
R+
F
F
F
F
Figure 6: Conicting declared and inherited role properties.

The combination of a feature having a transitive superrole is not allowed and features cannot
be transitive. Note that transitive roles and roles with transitive subroles may not be used
in number restrictions.
RACER does not support role terms as specied in the KRSS. However, a
role being the conjunction of other roles can as well be expressed by using
the role hierarchy (cf. [Buchheit et al. 93]). The KRSS-like declaration of the role
9
KRSS
(define-primitive-role RN
RACER Syntax
(domain C ))
(range D))
:domain C )
:range D)
DL notation
( RN.) C
( RN.D)
DL notation
( RN.) C
( RN.D)
Figure 7: Domain and range restrictions expressed via GCIs.

(define-primitive-role RN (and RN 1 RN 2 )) can be approximated in RACER by:
(define-primitive-role RN :parents (RN 1 RN 2 )).
RACER oers the declaration of domain and range restrictions for roles. These restrictions for primitive roles can be either expressed with GCIs, see the examples in Figure 7
(cf. [Buchheit et al. 93]) or declared via the keywords :domain and :range (e.g. see the
description of define-primitive-role in Section 5.3, page 25).
3.4
Concrete Domains
Racer supports reasoning over the integers and over the reals. Names for values from these
concrete domains are called objects. Individuals can be associated with objects via so-called
attributes names (or attributes for short). Note that the set of attributes must be disjoint
to the set of roles (and the set of features). Attributes can be declared in the signature of
a TBox (see below). The following example is an extension of the family TBox introduced
above.
...
(signature
:atomic-concepts (... teenager)
:roles (...)
:attributes ((integer age)))
...
(equivalent teenager (and human (min age 16)))
(equivalent old-teenager (and human (min age 18)))
...
Asking for the children of teenager reveals that old-teenager is a teenager. A further
extensions demonstrates the usage of the real concrete domain.
...
(signature
:atomic-concepts (... teenager)
:roles (...)
:attributes ((integer age)
(real temperature-celsius)
(real temperature-fahrenheit)))
...
10
(equivalent
(equivalent
(equivalent
(equivalent
...
teenager (and human (min age 16)))

old-teenager (and human (min age 18)))
human-with-feaver (and human (>= temperature-celsius 38.5))
seriously-ill-human (and human (>= temperature-celsius 42.0)))
Obviously, Racer determines that the concept seriously-ill-human is subsumed by

human-with-feaver. For the reals, Racer supports linear equations and inequations. Thus,
we could add the following statement to the knowledge base in order to make sure the
relations between the two attributes temperature-fahrenheit and temperature-celsius
is properly represented.
(implies top (= temperature-fahrenheit
(+ (* 1.8 temperature-celsius) 32)))
If a concept seriously-ill-human-1 is dened as
(equivalent seriously-ill-human-1 (and human (>= temperature-fahrenheit 107.6)))
Racer recognizes the subsumption relationship with human-with-feaver and the synonym
relationship with seriously-ill-human.
In an ABox, it is possible to set up constraints between individuals.
(constrained eve temp-eve temperature-fahrenheit)
(constrained doris temp-doris temperature-celsius)
(constraints
(= temp-eve 102.56)
(= temp-doris 39.5))
Now, asking for the direct types of eve and doris reveals that both individuals are instances
of human-with-feaver. In the following Abox, there is an inconsistency.
(constrained eve temp-eve temperature-fahrenheit)
(constrained doris temp-doris temperature-celsius)
(constraints
(= temp-eve 102.56)
(= temp-doris 39.5)
(> temp-eve temp-doris))
3.5
ABox Assertions
An ABox contains assertions about individuals. The set of individual names (or individuals
for brevity) I is the signature of the ABox. The set of individuals must be disjoint to the
set of concept names and the set of role names. There are two kinds of assertions:
Concept assertions state that an individual IN is an instance of a specied concept C .
11
Role assertions state that an individual IN 1 is a role ller for a role R with respect to
an individual IN 2 .
Attribute assertions state that an object ON is a ller for a role R with respect to an
individual IN .
Constraints state relationships between objects of the concrete domain.
In RACER the unique name assumption holds, this means that all individual names used
in an ABox refer to distinct domain objects, therefore two names cannot refer to the same
domain object. Note that the unique name assumption does not hold for object names.
In the RACER system each ABox refers to a TBox. The concept assertions in the ABox
are interpreted with respect to the concept axioms given in the referenced TBox. The role
assertions are also interpreted according to the role declarations stated in that TBox. When
a new ABox is built, the TBox to be referenced must already exist. The same TBox may
be referred to by several ABoxes. If no signature is used for the TBox, the assertions in the
ABox may use new names for roles4 or concepts5 which are not mentioned in the TBox.
3.6
Inference Modes
After the declaration of a TBox or an ABox, RACER can be instructed to answer queries.
Processing the knowledge base in order to answer a query may take some time. The standard
inference mode of RACER ensures the following behavior: Depending on the kind of query,
RACER tries to be as smart as possible to locally minimize computation time (lazy inference
mode). For instance, in order to answer a subsumption query w.r.t. a TBox it is not necessary
to classify the TBox. However, once a TBox is classied, answering subsumption queries
for atomic concepts is just a lookup. Furthermore, asking whether there exists an atomic
concept in a TBox that is inconsistent (tbox-coherent-p) does not require the TBox to be
classied, either. In the lazy mode of inference (the default), RACER avoids computations
that are not required concerning the current query. In some situations, however, in order to
globally minimize processing time it might be better to just classify a TBox before answering
a query (eager inference mode).
A similar strategy is applied if the computation of the direct types of individuals is requested.
RACER requires as precondition that the corresponding TBox has to be classied. If the
lazy inference mode is enabled, only the individuals involved in a direct types query are
realized.
The inference behavior of RACER can be controlled by setting the value of the variables
*auto-classify* and *auto-realize* for TBox and ABox inference, respectively. The
lazy inference mode is activated by setting the variables to the keyword :lazy. Eager
inference behavior can be enforced by setting the variables to :eager. The default value for
each variable is :lazy-verbose, which means that RACER prints a progress bar in order
to indicate the state of the current inference activity if it might take some time. If you want
4
These roles are treated as roles that are neither a feature, nor transitive and do not have any superroles.
New items are added to the TBox. Note that this might lead to surprising query results, e.g. the set
of subconcepts for contains concepts not mentioned in the TBox in any concept axiom. Therefore we
recommend to use a signature declaration (see below).
5
These concepts are assumed to be atomic concepts.
12
this for eager inferences, use the value :eager-verbose. If other values are encountered,
the user is responsible for calling necessary setup functions (not recommended).
We recommend that TBoxes and ABoxes should be kept in separate les. If an ABox is
revised (by reloading or reevaluating a le), there is no need to recompute anything for the
TBox. However, if the TBox is placed in the same le, reevaluating a le presumably causes
the TBox to be reinitialized and the axioms to be declared again. Thus, in order to answer
an ABox query, recomputations concerning the TBox might be necessary. So, if dierent
ABoxes are to be tested, they should probably be located separately from the associated
TBoxes in order to save processing time.
During the development phase of a TBox it might be advantageous to call inference services
directly. For instance, during the development phase of a TBox it might be useful to check
which atomic concepts in the TBox are inconsistent by calling check-tbox-coherence. This
service is usually much faster than calling classify-tbox. However, if an application problem can be solved, for example, by checking whether a certian ABox is consistent or not (see
the function abox-consistent-p), it is not necessary to call either check-tbox-coherence
or classify-tbox. For all queries, RACER ensures that the knowledge bases are in the appropriate states. This behavior usually guarantees minimum runtimes for answering queries.
3.7
Retraction and Incremental Additions
RACER oers constructs for retracting ABox assertions (see forget,

forget-concept-assertion and forget-role-assertion). If a query has been answered and some assertions are retracted, then RACER might be forced to realize the
ABox again, i.e. after retractions, some queries might take some time to answer.
RACER also supports incremental additions to ABoxes, i.e. assertions can be added even
after queries have been answered. However, the internal data structures used for anwering
queries are recomputed from scratch. This might take some time. If an ABox is used for
hypothesis generation, e.g. for testing whether the assertion i : C can be added without
causing an inconsistency, we recommend using the instance checking inference service. If
(individual-instance? i (not C)) returns t, i : C cannot be added to the ABox. Now,
let us assume, we can add i : C and afterwards want to test whether i : D can be added
without causing an inconsistency. In this case it might be faster not to add i : C directly but
to check whether (individual-instance? i (and C (not D))) returns t. The reason is
that, in this case, the index structures for the ABox are not recomputed.
13
Knowledge Base Management Functions
This section documents the functions for managing TBoxes and ABoxes and for specifying
queries.
4.1
TBox Management
in-tbox
macro
Description: The TBox with the specied name is taken or a new TBox with that name
is generated and bound to the variable *current-tbox*.
Syntax: (in-tbox TBN &key (init t))
Arguments: TBN
init
- is the name of the TBox.

- boolean indicating if the TBox should be initialized.
Remarks: Usually this macro is used at top of a le containing a TBox. This macro
can also be used to create new TBoxes.
The specied TBox is the *current-tbox* until in-tbox is called again or
the variable *current-tbox* is manipulated directly.
Examples: (in-tbox peanuts)
(implies Piano-Player Character)
.
.
.
See also: Macro signature on page 14.
init-tbox
function
Description: Generates a new TBox or initializes an existing TBox and binds it to the variable *current-tbox*. During the initialization all user-dened concept axioms and role declarations are deleted, only the concepts *top* and *bottom*
remain in the TBox.
Syntax: (init-tbox tbox &optional (class tbox))
Arguments: tbox
class
- TBox object
- class inheriting from the class tbox
Values: tbox
Remarks: This is the way to create a new TBox object.
14
signature
macro
Description: Denes the signature for a knowledge base.

If the keywords atomic -concepts and roles are used. The *current-tbox* is initialized and the signature is dened for it.
If the keyword individualnames is used, the *current-abox* is initialized. If all keywords are used, the *current-abox* and its TBox are both initialized.
Syntax: (signature &key (atomic -concepts nil) (roles nil) (individuals nil))
Arguments: atomic -concepts - is a list of all the concept names, specifying C.
roles - is a list of all role declarations, thereby also specifying R.
individuals - is a list of individual names, specifying I.
Remarks: Usually this macro is used at top of a le directly after the macro
in-knowledge-base, in-tbox or in-abox.
Actually it is not necessary in RACER to specify the signature, but it helps
to avoid errors due to typos.
Examples: Signature for a TBox:
(signature
:atomic-concepts (Character Baseball-Player . . . )
:roles ((has-pet)
(has-dog :parents (has-pet) :domain human :range dog)
(has-coach :feature t)))
Signature for an ABox:
(signature :individuals (Charlie-Brown Snoopy . . . ))
Signature for a TBox and an ABox:
(signature
:atomic-concepts (Character Baseball-Player . . . )
:roles ((has-pet)
(has-dog :parents (has-pet) :domain human :range dog)
(has-coach :feature t))
:individuals (Charlie-Brown Snoopy . . . ))
See also: Section Sample Session, on page 2 and page 3.
For role denitions see define-primitive-role, on page 25.
ensure-tbox-signature
function
Description: Denes the signature for a TBox and initializes the TBox.
Syntax: (ensure-tbox-signature tbox &key (atomic -concepts nil)
(roles nil))
Arguments: tbox
- is a TBox name or a TBox object.
atomic -concepts - is a list of all the concept names, specifying C.
roles - is a list of all role declarations, thereby also specifying R.
15
*current-tbox*
special-variable
Description: The variable *current-tbox* refers to the current TBox object. It is set by
the function init-tbox or by the macro in-tbox.
save-tbox
function
Description: If a pathname is specied, a TBox is saved to a le. In case a stream is

specied the TBox is written to the stream (the stream must already be
open) and the keywords if -exists and if -does -not -exist are ignored.
Syntax: (save-tbox pathname -or -stream &optional (tbox *current-tbox*)
&key (syntax :krss) (transformed nil) (if -exists :supersede)
(if -does-not-exist :create))
Arguments: pathname -or -stream - is the pathname of a le or an output stream

tbox
- TBox object
syntax - indicates the syntax of the TBox (only :krss is currently implemented).
transformed - if bound to t the TBox is saved in the format after preprocessing by RACER.
if -exists - species the action taken if a le with the specied name already
exists. All keywords for the Lisp function with-open-file are supported. The default is :supersede.
if -does -not -exist - species the action taken if a le with the specied
name does not yet exist. All keywords for the Lisp function
with-open-file are supported. The default is :create.
Values: TBox object
Remarks: A le may contain several TBoxes.
The usual way to load a TBox le is to use the Lisp function load.
Examples: (save-tbox "project:TBoxes;tbox-one.lisp")
(save-tbox "project:TBoxes;final-tbox.lisp"
(find-tbox tbox-one) :if-exists :error)
16
nd-tbox
function
Description: Returns a TBox object with the given name among all TBoxes.
Syntax: (find-tbox TBN &optional (errorp t))
Arguments: TBN
- is the name of the TBox to be found.
errorp - if bound to t an error is signaled if the TBox is not found.

Values: TBox object
Remarks: This function can also be used to get rid of TBoxes or rename TBoxes as
shown in the examples.
Examples: (find-tbox my-TBox)
Getting rid of a TBox:
(setf (find-tbox tbox1) nil)
Renaming a TBox:
(setf (find-tbox tbox2) tbox1)
tbox-name
function
Description: Finds the name of the given TBox object.

Syntax: (tbox-name tbox )
Arguments: tbox
- TBox object
Values: TBox name
4.2
ABox Management
in-abox
macro
Description: The ABox with this name is taken or generated and bound to
*current-abox*. If a TBox is specied, the ABox is also initialized.
Syntax: (in-abox ABN &optional (TBN (tbox-name *current-tbox*)))
Arguments: ABN
TBN
- ABox name
- name of the TBox to be associated with the ABox.
Remarks: If the specied TBox does not exist, an error is signaled.

Usually this macro is used at top of a le containing an ABox. This macro
can also be used to create new ABoxes. If the ABox is to be continued in
another le, the TBox must not be specied again.
17
The specied ABox is the *current-abox* until in-abox is called again or

the variable *current-abox* is manipulated directly. The TBox of the ABox
is made the *current-tbox*.
Examples: (in-abox peanuts-characters peanuts)
(instance Schroeder Piano-Player)
.
.
.
init-abox
function
Description: Initializes an existing ABox or generates a new ABox and binds it to the
variable *current-abox*. During the initialization all assertions and the
link to the referenced TBox are deleted.
Syntax: (init-abox abox &optional (tbox *current-tbox*)
(class standard-abox))
Arguments: abox
- ABox object to initialize.
tbox
- TBox object associated with the ABox
class
- class of the new ABox object, that must inherit from the class
standard-abox.
Values: ABox object

Remarks: The tbox has to already exist before it can be referred to by init-abox.
ensure-abox-signature
function
Description: Denes the signature for an ABox and initializes the ABox.
Syntax: (ensure-abox-signature abox &key (individuals nil))
Arguments: abox
- ABox object
individuals - is a list of individual names, specifying I.

See also: Macro signature on page 14 is the macro counterpart. It allows to specify
a signature for an ABox and a TBox with one call.
18
in-knowledge-base
macro
Description: This form is an abbreviation for the sequence:

(in-tbox TBN )
(in-abox ABN TBN ).
Syntax: (in-knowledge-base TBN ABN &optional (name cl-user))
Arguments: TBN
- TBox name
ABN
- ABox name
name - Package name

Examples: (in-knowledge-base peanuts peanuts-characters)
*current-abox*
special-variable
Description: The variable *current-abox* refers to the current ABox object. It is set by
the function init-abox or by the macros in-abox and in-knwoledge-base.
19
save-abox
function
Description: If a pathname is specied, an ABox is saved to a le. In case a stream is

specied, the ABox is written to the stream (the stream must already be
open) and the keywords if -exists and if -does -not -exist are ignored.
Syntax: (save-abox pathname -or -stream &optional (abox *current-abox*)
&key (syntax :krss) (transformed nil) (if -exists :supersede)
(if -does-not-exist :create))
Arguments: pathname -or -stream - is the name of the le or an output stream.

abox
- ABox object
syntax - indicates the syntax of the TBox (only :krss is currently implemented).
transformed - if bound to t the ABox is saved in the format it has after
preprocessing by RACER.
if -exists - species the action taken if a le with the specied name already
exists. All keywords for the Lisp function with-open-file are supported. The default is :supersede.
if -does -not -exist - species the action taken if a le with the specied
name does not yet exist. All keywords for the Lisp function
with-open-file are supported. The default is :create.
Values: ABox object
Remarks: A le may contain several ABoxes.
The usual way to load an ABox le is to use the Lisp function load.
Examples: (save-abox "project:ABoxes;abox-one.lisp")
(save-abox "project:ABoxes;final-abox.lisp"
(find-abox abox-one) :if-exists :error)
nd-abox
function
Description: Finds an ABox object with a given name among all ABoxes.
Syntax: (find-abox ABN &optional (errorp t))
Arguments: ABN
- is the name of the ABox to be found.
errorp - if bound to t an error is signaled if the ABox is not found.

Values: ABox object
Remarks: This function can also be used to delete ABoxes or rename ABoxes as shown
in the examples.
Examples: (find-tbox my-ABox)
Get rid of an ABox, i.e. make the ABox garbage collectible:
(setf (find-abox abox1) nil)
20
Renaming an ABox:
(setf (find-abox abox2) abox1)
abox-name
function
Description: Finds the name of the given ABox object.

Syntax: (abox-name abox )
Arguments: abox
- ABox object
Values: ABox name

Examples: (abox-name (find-abox my-ABox))
tbox
function
Description: Gets the associated TBox for an ABox.

Syntax: (tbox abox )
Arguments: abox
- ABox object
Values: TBox object
Knowledge Base Declarations
Knowledge base declarations include concept axioms and role declarations for the TBox and
the assertions for the ABox. The TBox object and the ABox object must exist before the
functions for knowledge base declarations can be used. The order of axioms and assertions
does not matter because forward references can be handled by RACER.
The macros for knowledge base declarations add the concept axioms and role declarations
to the *current-tbox* and the assertions to the *current-abox*.
5.1
Built-in Concepts
*top*, top
concept
Description: The name of most general concept of each TBox, the top concept ().
Syntax: *top*
Remarks: The concepts *top* and top are synonyms. These concepts are elements of
every TBox.
21
*bottom*, bottom
concept
Description: The name of the incoherent concept, the bottom concept ().
Syntax: *bottom*
Remarks: The concepts *bottom* and bottom are synonyms. These concepts are elements of every TBox.
5.2
Concept Axioms
This section documents the macros and functions for specifying concept axioms. The different concept axioms were already introduced in section 3.2.
Please note that the concept axioms define-primitive-concept, define-concept and
define-disjoint-primitive-concept have the semantics given in the KRSS specication
only if they are the only concept axiom dening the concept CN in the terminology. This
is not checked by the RACER system.
implies
macro
Description: Denes a GCI between C1 and C2 .

Syntax: (implies C1 C2 )
Arguments: C1 , C2 - concept term
Remarks: C1 states necessary conditions for C2 . This kind of facility is an addendum
to the KRSS specication.
Examples: (implies Grandmother (and Mother Female))
(implies
(and (some has-sibling Sister) (some has-sibling Twin)
(exactly 1 has-sibling))
(and Twin (all has-sibling Twin-sister)))
22
equivalent
macro
Description: States the equality between two concept terms.

Syntax: (equivalent C1 C2 )
Remarks: This kind of concept axiom is an addendum to the KRSS specication.
Examples: (equivalent Grandmother
(and Mother (some has-child Parent)))
(equivalent
(and polygon (exactly 4 has-angle))
(and polygon (exactly 4 has-edges)))
disjoint
macro
Description: This axiom states the disjointness of a set of concepts.

Syntax: (disjoint CN 1 . . . CN n )
Arguments: CN 1 , . . . , CN n - concept names
Examples: (disjoint Yellow Red Blue)
(disjoint January February . . . November December))
dene-primitive-concept
KRSS macro
Description: Denes a primitive concept.

Syntax: (define-primitive-concept CN C )
Arguments: CN
C
- concept name
- concept term
Remarks: C states the necessary conditions for CN .

Examples: (define-primitive-concept Grandmother (and Mother Female))
(define-primitive-concept Father Parent)
23
dene-concept
KRSS macro
Description: Denes a concept.

Syntax: (define-concept CN C )
Arguments: CN
C
- concept name
- concept term
Remarks: Please note that in RACER, denitions of a concept do not have to be unique.
Several denitions may be given for the same concept.
Examples: (define-concept Grandmother
(and Mother (some has-child Parent)))
dene-disjoint-primitive-concept
KRSS macro
Description: This axiom states the disjointness of a group of concepts.

Syntax: (define-disjoint-primitive-concept CN GNL C )
Arguments: CN
- concept name
GNL
- group name list, which lists all groups to which CN belongs to

(among other concepts). All elements of each group are declared to
be disjoint.
- concept term, that is implied by CN .
Remarks: This function is just supplied to be compatible with the KRSS.

Examples: (define-disjoint-primitive-concept January
(Month) (exactly 31 has-days))
(define-disjoint-primitive-concept February
(Month) (and (at-least 28 has-days) (at-most 29 has-days)))
..
.
24
add-concept-axiom
function
Description: This function adds a concept axiom to a TBox.

Syntax: (add-concept-axiom tbox C1 C2 &key (inclusion -p nil))
Arguments: tbox
- TBox object
C1 , C2 - concept term
inclusion -p - boolean indicating if the concept axiom is an inclusion axiom
(GCI) or an equality axiom. The default is to state an inclusion.
Values: tbox
Remarks: RACER imposes no constraints on the sequence of concept axiom declarations with add-concept-axiom, i.e. forward references to atomic concepts
for which other concept axioms are added later are supported in RACER.
add-disjointness-axiom
function
Description: This function adds a disjointness concept axiom to a TBox.

Syntax: (add-disjointness-axiom tbox CN GN )
Arguments: tbox
- TBox object
CN
- concept name
GN
- group name
Values: tbox
5.3
Role Declarations
25
dene-primitive-role
KRSS macro (with changes)
Description: Denes a role.

Syntax: (define-primitive-role RN &key (transitive nil) (feature nil)
(symmetric nil) (reexive nil) (inverse nil) (domain nil)
(range nil) (parents nil))
Arguments: RN
- role name
transitive - if bound to t declares that the new role is transitive.

feature - if bound to t declares that the new role is a feature.
symmetric - if bound to t declares that the new role is a symmetric. This is
equivalent to declaring that the new roles inverse is the role itself.
reexive - if bound to t declares that the new role is reexive (currently only
supported for ALCH). If feature is bound to t, the value of reexive
is ignored.
inverse - provides a name for the inverse role of RN . This is equivalent to
(inv RN ). The inverse role of RN has no user-dened name, if
inverse is bound to nil.
domain - provides a concept term dening the domain of role RN . This is
equivalent to adding the axiom (implies (at-least 1 RN ) C )
if domain is bound to the concept term C . No domain is declared
if domain is bound to nil.
range - provides a concept term dening the range of role RN . This is
equivalent to adding the axiom (implies *top* (all RN D)) if
range is bound to the concept term D. No range is declared if range
is bound to nil.
parents - provides a list of superroles for the new role. The role RN has no
superroles, if parents is bound to nil.
If only a single superrole is specied, the keyword :parent may
alternatively be used, see the examples.
Remarks: This function combines several KRSS functions for dening properties of a
role. For example the conjunction of roles can be expressed as shown in the
rst example below.
A role that is declared to be a feature cannot be transitive. A role with a
feature as a parent has to be a feature itself. A role with transitive subroles
may not be used in number restrictions.
Examples: (define-primitive-role conjunctive-role :parents (R-1 . . . R-n))
(define-primitive-role has-descendant :transitive t
:inverse descendant-of :parent has-child)
(define-primitive-role has-children :inverse has-parents
:domain parent :range children))
Section 3.3 and Figure 7, on page 10 for domain and range restrictions.
26
dene-primitive-attribute
KRSS macro (with changes)
Description: Denes an attribute.

Syntax: (define-primitive-attribute AN &key (symmetric nil)
(inverse nil) (domain nil) (range nil) (parents nil))
Arguments: AN
- attribute name

inverse - provides a name for the inverse role of AN . This is equivalent to
(inv AN ). The inverse role of AN has no user-dened name, if
inverse is bound to nil.
domain - provides a concept term dening the domain of role AN . This is
equivalent to adding the axiom (implies (at-least 1 AN ) C )
if domain is bound to the concept term C . No domain is declared
if domain is bound to nil.
range - provides a concept term dening the range of role AN . This is
equivalent to adding the axiom (implies *top* (all AN D)) if
range is bound to the concept term D. No range is declared if range
is bound to nil.
parents - provides a list of superroles for the new role. The role AN has no
superroles, if parents is bound to nil.
If only a single superrole is specied, the keyword :parent may
alternatively be used, see examples.
Remarks: This macro is supplied to be compatible with the KRSS specication. It is redundant since the macro define-primitive-role can be used with :feature
t. This function combines several KRSS functions for dening properties of
an attribute.
An attribute cannot be transitive. A role with a feature as a parent has to
be a feature itself.
Examples: (define-primitive-attribute has-mother
:domain child :range mother :parents (has-parents))
(define-primitive-attribute has-best-friend
:inverse best-friend-of :parent has-friends)
Section 3.3 and Figure 7, on page 10 for domain and range restrictions.
27
add-role-axioms
function
Description: Adds a role to a TBox.

Syntax: (add-role-axioms tbox RN &key (transitive nil) (feature nil)
(symmetric nil) (reexive nil) (inverse nil) (domain nil)
(range nil) (parents nil))
Arguments: tbox
RN
- TBox object to which the role is added.

- role name
transitive - if bound to t declares that the role is transitive.

feature - if bound to t declares that the new role is a feature, if feature is
bound to t.
reexive - if bound to t declares that the new role is reexive (currently only
supported for ALCH). If feature is bound to t, the value of reexive
is ignored.
inverse - provides a name for the inverse role of RN (is equivalent to (inv
RN )). The inverse role of RN has no user-dened name, if inverse
is bound to nil.
domain - provides a concept term dening the domain of role RN (equivalent
to adding the axiom (implies (at-least 1 RN ) C ) if domain
is bound to the concept term C . No domain is declared if domain
is bound to nil.
range - provides a concept term dening the range of role RN (equivalent
to adding the axiom (implies *top* (all RN D)) if range is
bound to the concept term D. No range is declared if range is
bound to nil.
parents - providing a single role or a list of superroles for the new role. The
role RN has no superroles, if parents is bound to nil.
Values: tbox
Remarks: For each role RN there may be only one call to add-role-axioms per TBox.
See also: Section 3.3 and Figure 7, on page 10 for domain and range restrictions.
5.4
Assertions
28
instance
KRSS macro
Description: Builds a concept assertion, asserts that an individual is an instance of a

concept.
Syntax: (instance IN C )
Arguments: IN
C
- individual name
- concept term
Examples: (instance Lucy Person)

(instance Snoopy (and Dog Cartoon-Character))
add-concept-assertion
function
Description: Builds an assertion and adds it to an ABox.

Syntax: (add-concept-assertion abox IN C )
Arguments: abox
IN
C
- ABox object
- individual name
- concept term
Values: abox
Examples: (add-concept-assertion (find-abox peanuts-characters)
Lucy Person)
(add-concept-assertion (find-abox peanuts-characters)
Snoopy (and Dog Cartoon-Character))
forget-concept-assertion
function
Description: Retracts a concept assertion from an ABox.

Syntax: (forget-concept-assertion abox IN C )
Arguments: abox
IN
C
- ABox object
- individual name
- concept term
Values: abox
Remarks: For answering subsequent queries the index structures for the ABox will be
recomputed, i.e. some queries might take some time (e.g. those queries that
require the realization of the ABox).
Examples: (forget-concept-assertion (find-abox peanuts-characters)
Lucy Person)
(forget-concept-assertion (find-abox peanuts-characters)
Snoopy (and Dog Cartoon-Character))
29
related
KRSS macro
Description: Builds a role assertion, asserts that two individuals are related via a role (or
feature).
Syntax: (related IN 1 IN 2 R)
Arguments: IN 1
- individual name of the predecessor
IN 2
- individual name of the ller
- a role term or a feature term.
Examples: (related Charlie-Brown Snoopy has-pet)

(related Linus Lucy (inv has-brother))
add-role-assertion
function
Description: Adds a role assertion to an ABox.

Syntax: (add-role-assertion abox IN 1 IN 2 R)
Arguments: abox
- ABox object
IN 1
IN 2
- role term
Values: abox
Examples: (add-role-assertion (find-abox peanuts-characters)
Charlie-Brown Snoopy has-pet)
(add-role-assertion (find-abox peanuts-characters)
Linus Lucy (inv has-brother))
30
forget-role-assertion
function
Description: Retracts a role assertion from an ABox.

Syntax: (forget-role-assertion abox IN 1 IN 2 R)
Arguments: abox
- ABox object
IN 1
IN 2
- role term
Values: abox
Examples: (forget-role-assertion (find-abox peanuts-characters)
Charlie-Brown Snoopy has-pet)
(forget-role-assertion (find-abox peanuts-characters)
Linus Lucy (inv has-brother))
dene-distinct-individual
KRSS macro
Description: This statement asserts that an individual is distinct to all other individuals
in the ABox.
Syntax: (define-distinct-individual IN )
Arguments: IN
- name of the individual
Values: IN
Remarks: Because the unique name assumption holds in RACER, all individuals are
distinct. This function is supplied to be compatible with the KRSS specication.
state
KRSS macro
Description: This macro asserts a set of ABox statements.

Syntax: (state &body forms)
Arguments: forms - is a sequence of instance or related assertions.
Remarks: This macro is supplied to be compatible with the KRSS specication. It
realizes an implicit progn for assertions.
31
forget
macro
Description: This macro retracts a set of ABox statements.

Syntax: (forget &body forms)
Arguments: forms - is a sequence of instance or related assertions.
Reasoning Modes
*auto-classify*
special-variable
Description: Possible values are :lazy, :eager, :lazy-verbose, :eager-verbose, nil

See also: Section 3.6 on page 12.
*auto-realize*
special-variable
Description: Possible values are :lazy, :eager, :lazy-verbose, :eager-verbose, nil

See also: Section 3.6 on page 12.
Evaluation Functions and Queries
7.1
Queries for Concept Terms
concept-satisable?
macro
Description: Checks if a concept term is satisable.

Syntax: (concept-satisfiable? C &optional (tbox *current-tbox*))
Arguments: C
tbox
- concept term.
- TBox object
Values: Returns t if C is satisable and nil otherwise.

Remarks: For testing whether a concept term is satisable with respect to a TBox tbox .
If satisability is to be tested without reference to a TBox, nil can be used.
32
concept-satisable-p
function
Description: Checks if a concept term is satisable.

Syntax: (concept-satisfiable-p C tbox )
Arguments: C
tbox
- concept term.
- TBox object
Values: Returns t if C is satisable and nil otherwise.

Remarks: For testing whether a concept term is satisable with respect to a TBox tbox .
If satisability is to be tested without reference to a TBox, nil can be used.
concept-subsumes?
KRSS macro
Description: Checks if two concept terms subsume each other.

Syntax: (concept-subsumes? C1 C2 &optional (tbox *current-tbox*))
Arguments: C1
- concept term of the subsumer
C2
- concept term of the subsumee
tbox
- TBox object
Values: Returns t if C1 subsumes C 2 and nil otherwise.
concept-subsumes-p
function
Description: Checks if two concept terms subsume each other.

Syntax: (concept-subsumes-p C1 C2 tbox )
Arguments: C1
- concept term of the subsumer
C2
- concept term of the subsumee
tbox
- TBox object
Values: Returns t if C1 subsumes C 2 and nil otherwise.

Remarks: For testing whether a concept term subsumes the other with respect to a
TBox tbox . If the subsumption relation is to be tested without reference to
a TBox, nil can be used.
See also: Function concept-equivalent-p, on page 34, and function atomicconcept-synonyms, on page 47.
33
concept-equivalent?
macro
Description: Checks if the two concepts are equivalent in the given TBox.
Syntax: (concept-equivalent? C1 C2 &optional (tbox *current-tbox*))
tbox
- TBox object
Values: Returns t if C1 and C2 are equivalent concepts in tbox and nil otherwise.
Remarks: For testing whether two concept terms are equivalent with respect to a TBox
tbox .
See also: Function atomic-concept-synonyms,
concept-subsumes-p, on page 33.
on
page
47,
and
concept-equivalent-p
function
function
Description: Checks if the two concepts are equivalent in the given TBox.
Syntax: (concept-equivalent-p C1 C2 tbox )
Arguments: C1 , C2 - concept terms
tbox
- TBox object
Values: Returns t if C1 and C2 are equivalent concepts in tbox and nil otherwise.
Remarks: For testing whether two concept terms are equivalent with respect to a TBox
tbox . If the equality is to be tested without reference to a TBox, nil can be
used.
See also: Function atomic-concept-synonyms,
concept-subsumes-p, on page 33.
on
page
47,
and
function
concept-disjoint?
macro
Description: Checks if the two concepts are disjoint, e.g. no individual can be an instance
of both concepts.
Syntax: (concept-disjoint? C1 C2 &optional (tbox *current-tbox*))
tbox
- TBox object
Values: Returns t if C1 and C2 are disjoint with respect to tbox and nil otherwise.
Remarks: For testing whether two concept terms are disjoint with respect to a TBox
tbox . If the disjointness is to be tested without reference to a TBox, nil can
be used.
34
concept-disjoint-p
function
Description: Checks if the two concepts are disjoint, e.g. no individual can be an instance
of both concepts.
Syntax: (concept-disjoint-p C1 C2 tbox )
tbox
- TBox object
Values: Returns t if C1 and C2 are disjoint with respect to tbox and nil otherwise.
Remarks: For testing whether two concept terms are disjoint with respect to a TBox
tbox . If the disjointness is to be tested without reference to a TBox, nil can
be used.
concept-p
function
Description: Checks if CN is a concept name for a concept in the specied TBox.

Syntax: (concept-p CN &optional (tbox *current-tbox*))
Arguments: CN
tbox
- concept name
- TBox object
Values: Returns t if CN is a name of a known concept and nil otherwise.
concept?
macro
Description: Checks if CN is a concept name for a concept in the specied TBox.

Syntax: (concept? CN &optional (TBN *current-tbox*))
Arguments: CN
TBN
- concept name
- TBox name
Values: Returns t if CN is a name of a known concept and nil otherwise.
concept-is-primitive-p
function
Description: Checks if CN is a concept name of a so-called primitive concept in the

specied TBox.
Syntax: (concept-is-primitive-p CN &optional (tbox *current-tbox*))
Arguments: CN
tbox
- concept name
- TBox object
Values: Returns t if CN is a name of a known primitive concept and nil otherwise.

35
concept-is-primitive?
macro
Description: Checks if CN is a concept name of a so-called primitive concept in the

specied TBox.
Syntax: (concept-is-primitive-p CN &optional (TBN (tbox-name
*current-tbox*)))
Arguments: CN
TBN
- concept name
- TBox name
Values: Returns t if CN is a name of a known primitive concept and nil otherwise.
alc-concept-coherent
function
Description: Tests the satisability of a K(m) , K4(m) or S4(m) formula encoded as an ALC
concept.
Syntax: (alc-concept-coherent C &key (logic :K))
Arguments: C
logic
- concept term
- species the logic to be used.
:K - modal K(m) ,
:K4 - modal K4(m) all roles are transitive,
:S4 - modal S4(m) all roles are transitive and reexive.
If no logic is specied, the logic :K is chosen.
Remarks: This function can only be used for ALC concept terms, so number restrictions
are not allowed.
7.2
Role Queries
role-subsumes?
KRSS macro
Description: Checks if two roles are subsuming each other.

Syntax: (role-subsumes? R1 R2
&optional (TBN (tbox-name *current-tbox*)))
Arguments: R1
- role term of the subsuming role
R2
- role term of the subsumed role
TBN
- TBox name
Values: Returns t if R1 is a parent role of R2 .
36
role-subsumes-p
function
Description: Checks if two roles are subsuming each other.

Syntax: (role-subsumes-p R1 R2 tbox )
Arguments: R1
- role term of the subsuming role
R2
- role term of the subsumed role
tbox
- TBox object
Values: Returns t if R1 is a parent role of R2 .
role-p
function
Description: Checks if R is a role term for a role in the specied TBox.

Syntax: (role-p R &optional (tbox *current-tbox*))
Arguments: R
tbox
- role term
- TBox object
Values: Returns t if R is a known role term and nil otherwise.
role?
macro
Description: Checks if R is a role term for a role in the specied TBox.

Syntax: (role? R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Returns t if R is a known role term and nil otherwise.
transitive-p
function
Description: Checks if R is a transitive role in the specied TBox.

Syntax: (transitive-p R &optional (tbox *current-tbox*))
Arguments: R
tbox
- role term
- TBox object
Values: Returns t if the role R is transitive in tbox and nil otherwise.
37
transitive?
macro
Description: Checks if R is a transitive role in the specied TBox.

Syntax: (transitive? R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Returns t if the role R is transitive in TBN and nil otherwise.
feature-p
function
Description: Checks if R is a feature in the specied TBox.

Syntax: (feature-p R &optional (tbox *current-tbox*))
Arguments: R
tbox
- role term
- TBox object
Values: Returns t if the role R is a feature in tbox and nil otherwise.
feature?
macro
Description: Checks if R is a feature in the specied TBox.

Syntax: (feature? R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Returns t if the role R is a feature in TBN and nil otherwise.
symmetric-p
function
Description: Checks if R is symmetric in the specied TBox.

Syntax: (symmetric-p R &optional (tbox *current-tbox*))
Arguments: R
tbox
- role term
- TBox object
Values: Returns t if the role R is symmetric in tbox and nil otherwise.
38
symmetric?
macro
Description: Checks if R is symmetric in the specied TBox.

Syntax: (symmetric? R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Returns t if the role R is symmetric in TBN and nil otherwise.
reexive-p
function
Description: Checks if R is reexive in the specied TBox.

Syntax: (reflexive-p R &optional (tbox *current-tbox*))
Arguments: R
tbox
- role term
- TBox object
Values: Returns t if the role R is reexive in tbox and nil otherwise.
reexive?
macro
Description: Checks if R is reexive in the specied TBox.

Syntax: (reflexive? R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Returns t if the role R is reexive in TBN and nil otherwise.
atomic-role-inverse
function
Description: Returns the inverse role of role term R.

Syntax: (atomic-role-inverse R tbox )
Arguments: R
tbox
- role term
- TBox object
Values: Role name or term for the inverse role of R.
39
role-inverse
macro
Description: Returns the inverse role of role term R.

Syntax: (role-inverse R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
Values: Role name or term for the inverse role of R.

Remarks: This macro uses atomic-role-inverse.
7.3
TBox Evaluation Functions
classify-tbox
function
Description: Classies the whole TBox.

Syntax: (classify-tbox &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Remarks: This function needs to be executed before queries can be posed.
check-tbox-coherence
function
Description: This function checks if there are any unsatisable atomic concepts in the
given TBox.
Syntax: (check-tbox-coherence &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Values: Returns a list of all atomic concepts in tbox that are not satisable, i.e. an
empty list (NIL) indicates that there is no additional synonym to bottom.
Remarks: This function does not compute the concept hierarchy. It is much faster
than classify-tbox, so whenever it is sucient for your application use
check-tbox-coherence. This function is supplied in order to check whether
an atomic concept is satisable during the development phase of a TBox.
There is no need to call the function check-tbox-coherence if, for instance,
a certain ABox is to be checked for consistency (with abox-consistent-p).
40
tbox-classied-p
function
Description: It is checked if the specied TBox has already been classied.

Syntax: (tbox-classified-p &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Values: Returns t if the specied TBox has been classied, otherwise it returns nil.
tbox-classied?
macro
Description: It is checked if the specied TBox has already been classied.

Syntax: (tbox-classified? &optional (TBN (tbox-name *current-tbox*)))
Arguments: TBN
- TBox name
Values: Returns t if the specied TBox has been classied, otherwise it returns nil.
tbox-coherent-p
function
Description: This function checks if there are any unsatisable atomic concepts in the
given TBox.
Syntax: (tbox-coherent-p &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Values: Returns nil if there is an inconsistent atomic concept, otherwise it returns

t.
Remarks: This function calls check-tbox-coherence if necessary.
tbox-coherent?
macro
Description: Checks if there are any unsatisable atomic concepts in the current or specied TBox.
Syntax: (tbox-coherent? &optional (TBN (tbox-name *current-tbox*)))
Arguments: TBN
- TBox name
Values: Returns t if there is an inconsistent atomic concept, otherwise it returns nil.

Remarks: This macro uses tbox-coherent-p.
7.4
ABox Evaluation Functions
41
realize-abox
function
Description: This function checks the consistency of the ABox and computes the mostspecic concepts for each individual in the ABox.
Syntax: (realize-abox &optional (abox *current-abox*))
Arguments: abox
- ABox object
Values: abox
Remarks: This Function needs to be executed before queries can be posed. If the TBox
has changed and is classied again the ABox has to be realized, too.
abox-realized-p
function
Description: Returns t if the specied ABox object has been realized.

Syntax: (abox-realized-p &optional (abox *current-abox*))
Arguments: abox
- ABox object
Values: Returns t if abox has been realized and nil otherwise.
abox-realized?
macro
Description: Returns t if the specied ABox object has been realized.

Syntax: (abox-realized? &optional (ABN (abox-name *current-abox*))
Arguments: ABN
- ABox name
Values: Returns t if ABN has been realized and nil otherwise.
7.5
ABox Queries
abox-consistent-p
function
Description: Checks if the ABox is consistent, e.g. it does not contain a contradiction.
Syntax: (abox-consistent-p &optional (abox *current-abox*))
Arguments: abox
- ABox object
Values: Returns t if abox is consistent and nil otherwise.
42
abox-consistent?
macro
Description: Checks if the ABox is consistent.

Syntax: (abox-consistent? &optional (ABN (abox-name *current-abox*)))
Arguments: ABN
- ABox name
Values: Returns t if the ABox ABN is consistent and nil otherwise.

Remarks: This macro uses abox-consistent-p.
check-abox-coherence
function
Description: Checks if the ABox is consistent. If there is a contradiction, this function

prints information about the culprits.
Syntax: (check-abox-coherence &optional (abox *current-abox*)
(stream *standard-output*)
Arguments: abox
- ABox object
stream - Stream object

Values: Returns t if abox is consistent and nil otherwise.
individual-instance?
KRSS macro
Description: Checks if an individual is an instance of a given concept with respect to the

*current-abox* and its TBox.
Syntax: (individual-instance? IN C
&optional (abox (abox-name *current-abox*)))
Arguments: IN
- individual name
- concept term
abox
- ABox object
Values: Returns t if IN is an instance of C in abox and nil otherwise.
43
individual-instance-p
function
Description: Checks if an individual is an instance of a given concept with respect to an

ABox and its TBox.
Syntax: (individual-instance-p IN C abox )
Arguments: IN
- individual name
- concept term
abox
- ABox object
Values: Returns t if IN is an instance of C in abox and nil otherwise.
individuals-related?
macro
Description: Checks if two individuals are directly related via the specied role.
Syntax: (individuals-related? IN 1 IN 2 R
&optional (abox *current-abox*))
Arguments: IN 1
IN 2
- individual name of the role ller
- role term
abox
- ABox object
Values: Returns t if IN 1 is related to IN 2 via R in abox and nil otherwise.
individuals-related-p
function
Description: Checks if two individuals are directly related via the specied role.
Syntax: (individuals-related-p IN 1 IN 2 R abox )
Arguments: IN 1
IN 2
- role term
abox
- ABox object
Values: Returns t if IN 1 is related to IN 2 via R in abox and nil otherwise.

See also: Function retrieve-individual-filled-roles, on page 57,
Function retrieve-related-individuals, on page 56.
44
individual-equal?
KRSS macro
Description: Checks if two individual names refer to the same domain object.
Syntax: (individual-equal? IN 1 IN 2 &optional (abox *current-abox*))
Arguments: IN 1 , IN 2 - individual name
abox
- abox object
Remarks: Because the unique name assumption holds in RACER this macro always
returns nil for individuals with dierent names. This macro is just supplied
to be compatible with the KRSS.
individual-not-equal?
KRSS macro
Description: Checks if two individual names do not refer to the same domain object.
Syntax: (individual-not-equal? IN 1 IN 2
Arguments: IN 1 , IN 2 - individual name
abox
- abox object
Remarks: Because the unique name assumption holds in RACER this macro always
returns t for individuals with dierent names. This macro is just supplied to
be compatible with the KRSS.
individual-p
function
Description: Checks if IN is a name of an individual mentioned in an ABox abox .

Syntax: (individual-p IN &optional (abox *current-abox*))
Arguments: IN
abox
- individual name
- ABox object
Values: Returns t if IN is a name of an individual and nil otherwise.
individual?
macro
Description: Checks if IN is a name of an individual mentioned in an ABox ABN .

Syntax: (individual? IN &optional (ABN (abox-name *current-abox*)))
Arguments: IN
ABN
- individual name
- ABox name
Values: Returns t if IN is a name of an individual and nil otherwise.

45
Retrieval
If the retrieval refers to concept names, RACER always returns a set of names for each
concept name. A so called name set contains all synonyms of an atomic concept in the
TBox.
8.1
TBox Retrieval
taxonomy
function
Description: Returns the whole taxonomy for the specied TBox.

Syntax: (taxonomy &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Values: A list of triples, each of it consisting of:

a name set - the atomic concept CN and its synonyms
list of concept-parents name sets - each entry being a list of a concept parent
of CN and its synonyms
list of concept-children name sets - each entry being a list of a concept child
of CN and its synonyms.
Examples: (taxonomy my-TBox)
may yield:
(((*top*) () ((quadrangle tetragon)))
((quadrangle tetragon) ((*top*)) ((rectangle) (diamond)))
((rectangle) ((quadrangle tetragon)) ((*bottom*)))
((diamond) ((quadrangle tetragon)) ((*bottom*)))
((*bottom*) ((rectangle) (diamond)) ()))
See also: Function atomic-concept-parents,
function atomic-concept-children on page 49.
concept-synonyms
macro
Description: Returns equivalent concepts for the specied concept in the given TBox.
Syntax: (concept-synonyms CN
&optional (tbox (tbox-name *current-tbox*)))
Arguments: CN
tbox
- concept name
- TBox object
Values: List of concept names

Remarks: The name CN is not included in the result.
See also: Function concept-equivalent-p, on page 34.
46
atomic-concept-synonyms
function
Description: Returns equivalent concepts for the specied concept in the given TBox.
Syntax: (atomic-concept-synonyms CN tbox )
Arguments: CN
tbox
- concept name
- TBox object

Remarks: The name CN is not included in the result.
See also: Function concept-equivalent-p, on page 34.
concept-descendants
KRSS macro
Description: Gets all atomic concepts of a TBox, which are subsumed by the specied
concept.
Syntax: (concept-descendants C
Arguments: C
TBN
- concept term
- TBox name
Values: List of name sets

Remarks: This macro return the transitive closure of the macro concept-children.
atomic-concept-descendants
function
Description: Gets all atomic concepts of a TBox, which are subsumed by the specied
concept.
Syntax: (atomic-concept-descendants C tbox )
Arguments: C
tbox
- concept term
- TBox object

Remarks: Returns the transitive closure from the call of atomic-concept-children.
47
concept-ancestors
KRSS macro
Description: Gets all atomic concepts of a TBox, which are subsuming the specied concept.
Syntax: (concept-ancestors C
Arguments: C
TBN
- concept term
- TBox name

Remarks: This macro return the transitive closure of the macro concept-parents.
atomic-concept-ancestors
function
Description: Gets all atomic concepts of a TBox, which are subsuming the specied concept.
Syntax: (atomic-concept-ancestors C tbox )
Arguments: C
tbox
- concept term
- TBox object

Remarks: Returns the transitive closure from the call of atomic-concept-parents.
concept-children
KRSS macro
Description: Gets the direct subsumees of the specied concept in the TBox.
Syntax: (concept-children C
Arguments: C
TBN
- concept term
- TBox name

Remarks: Is the equivalent macro for the KRSS macro concept-offspring, which is
also supplied in RACER.
48
atomic-concept-children
function
Description: Gets the direct subsumees of the specied concept in the TBox.
Syntax: (atomic-concept-children C tbox )
Arguments: C
tbox
- concept term
- TBox object
concept-parents
KRSS macro
Description: Gets the direct subsumers of the specied concept in the TBox.
Syntax: (concept-parents C
Arguments: C
TBN
- concept term
- TBox name
atomic-concept-parents
function
Description: Gets the direct subsumers of the specied concept in the TBox.
Syntax: (atomic-concept-parents C tbox )
Arguments: C
tbox
- concept term
- TBox object
role-descendants
KRSS macro
Description: Gets all roles from the TBox, that the given role subsumes.
Syntax: (role-descendants R
Arguments: R
TBN
- role term
- TBox name
Values: List of role terms

Remarks: This macro is the transitive closure of the macro role-children.
49
atomic-role-descendants
function
Description: Gets all roles from the TBox, that the given role subsumes.
Syntax: (atomic-role-descendants R tbox )
Arguments: R
tbox
- role term
- TBox object

Remarks: This function is the transitive closure of the function
atomic-role-descendants.
role-ancestors
KRSS macro
Description: Gets all roles from the TBox, that subsume the given role in the role hierarchy.
Syntax: (role-ancestors R
Arguments: R
TBN
- role term
- TBox name
atomic-role-ancestors
function
Description: Gets all roles from the TBox, that subsume the given role in the role hierarchy.
Syntax: (atomic-role-ancestors R tbox )
Arguments: R
tbox
- role term
- TBox object
50
role-children
macro
Description: Gets all roles from the TBox that are directly subsumed by the given role in
the role hierarchy.
Syntax: (role-children R
Arguments: R
TBN
- role term
- TBox name

Remarks: This is the equivalent macro to the KRSS macro role-offspring, which is
also supplied by the RACER system.
atomic-role-children
function
Description: Gets all roles from the TBox that are directly subsumed by the given role in
the role hierarchy.
Syntax: (atomic-role-children R tbox )
Arguments: R
tbox
- role term
- TBox object
role-parents
KRSS macro
Description: Gets the roles from the TBox that directly subsume the given role in the role
hierarchy.
Syntax: (role-parents R &optional (TBN (tbox-name *current-tbox*)))
Arguments: R
TBN
- role term
- TBox name
51
atomic-role-parents
function
Description: Gets the roles from the TBox that directly subsume the given role in the role
hierarchy.
Syntax: (atomic-role-parents R tbox )
Arguments: R
tbox
- role term
- TBox object
loop-over-tboxes
function
Description: Iterator function for all TBoxes.

Syntax: (loop-over-tboxes (tbox -variable)
loop -clause
..
.
Arguments: tbox -variable - variable for a TBox object

loop -clause - loop clause
all-tboxes
function
Description: Returns the names of all known TBoxes.

Syntax: (all-tboxes)
Values: List of TBox names
all-atomic-concepts
function
Description: Returns all atomic concepts from the specied TBox.

Syntax: (all-atomic-concepts &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object

Remarks: (all-atomic-concepts (find-tbox my-tbox))
52
all-roles
function
Description: Returns all roles and features from the specied TBox.
Syntax: (all-roles &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object

Examples: (all-roles (find-tbox my-tbox))
all-features
function
Description: Returns all features from the specied TBox.

Syntax: (all-features &optional (tbox *current-tbox*))
Arguments: tbox
- TBox
Values: List of feature terms
all-transitive-roles
function
Description: Returns all transitive roles from the specied TBox.

Syntax: (all-transitive-roles &optional (tbox *current-tbox*))
Arguments: tbox
- TBox object
Values: List of transitive role terms
describe-tbox
function
Description: Generates a description for the specied TBox.

Syntax: (describe-tbox &optional (tbox *current-tbox*)
(stream *standard-output*))
Arguments: tbox
- TBox object or TBox name
stream - open stream object

Values: tbox
The description is written to stream.
53
describe-concept
function
Description: Generates a description for the specied concept used in the specied TBox
or in the ABox and its TBox.
Syntax: (describe-concept CN &optional (tbox -or -abox *current-tbox*)
Arguments: tbox -or -abox - TBox object or ABox object
CN
- concept name

Values: tbox -or -abox
describe-role
function
Description: Generates a description for the specied role used in the specied TBox or
ABox.
Syntax: (describe-role R &optional (tbox -or -abox *current-tbox*)
Arguments: tbox -or -abox - TBox object or ABox object
R
- role term (or feature term)

Values: tbox -or -abox
8.2
ABox Retrieval
individual-direct-types
KRSS macro
Description: Gets the most-specic atomic concepts of which an individual is an instance.

Syntax: (individual-direct-types IN
&optional (ABN (abox-name *current-abox*)))
Arguments: IN
ABN
- individual name
- ABox name
54
most-specic-instantiators
function
Description: Gets the most-specic atomic concepts of which an individual is an instance.

Syntax: (most-specific-instantiators IN abox )
Arguments: IN
abox
- individual name
- ABox object
individual-types
KRSS macro
Description: Gets all atomic concepts of which the individual is an instance.

Syntax: (individual-types IN
Arguments: IN
ABN
- individual name
- ABox name

Remarks: This is the transitive closure of the KRSS macro individual-direct-types.
instantiators
function
Description: Gets all atomic concepts of which the individual is an instance.

Syntax: (instantiators IN abox )
Arguments: IN
abox
- individual name
- ABox object

Remarks: This is the transitive closure of the function
most-specific-instantiators.
concept-instances
KRSS macro
Description: Gets all individuals from an ABox that are instances of the specied concept.
Syntax: (concept-instances C
Arguments: C
ABN
- concept term
- ABox name
Values: List of individual names

55
retrieve-concept-instances
function
Description: Gets all individuals from an ABox that are instances of the specied concept.
Syntax: (retrieve-concept-instances C abox )
Arguments: C
abox
- concept term
- ABox object
individual-llers
KRSS macro
Description: Gets all individuals that are llers of a role for a specied individual.
Syntax: (individual-fillers IN R
Arguments: IN
- role term
ABN
- ABox name

Examples: (individual-fillers Charlie-Brown has-pet)
(individual-fillers Snoopy (inv has-pet))
retrieve-individual-llers
function
Description: Gets all individuals that are llers of a role for a specied individual.
Syntax: (retrieve-individual-fillers IN R abox )
Arguments: IN
- role term
abox
- ABox object

Examples: (retrieve-individual-fillers Charlie-Brown has-pet
(find-abox peanuts-characters))
56
retrieve-related-individuals
function
Description: Gets all pairs of individuals that are related via the specied relation.
Syntax: (retrieve-related-individuals R abox )
Arguments: R
abox
- role term
- ABox object
Values: List of pairs of individual names

Examples: (retrieve-related-individuals has-pet
may yield:
((Charlie-Brown Snoopy) (John-Arbuckle Garfield))
See also: Function individuals-related-p, on page 44.
related-individuals
macro
Description: Gets all pairs of individuals that are related via the specied relation.
Syntax: (related-individuals R
Arguments: R
ABN
- role term
- ABox name
Values: List of pairs of individual names

Examples: (retrieve-related-individuals has-pet
may yield:
((Charlie-Brown Snoopy) (John-Arbuckle Garfield))
57
retrieve-individual-lled-roles
function
Description: This function gets all roles that hold between the specied pair of individuals.
Syntax: (retrieve-individual-filled-roles IN 1 IN 2 abox ).
Arguments: IN 1
IN 2
abox
- ABox object

Examples: (retrieve-individual-filled-roles Charlie-Brown Snoopy
retrieve-direct-predecessors
function
Description: Gets all individuals that are predecessors of a role for a specied individual.
Syntax: (retrieve-direct-predecessors R IN abox )
Arguments: R
- role term
IN
abox
- ABox object

Examples: (retrieve-direct-predecessors has-pet Snoopy
loop-over-aboxes
function
Description: Iterator function for all ABoxes.

Syntax: (loop-over-aboxes (abox -variable)
loop -clause
..
.
Arguments: abox -variable - variable for a ABox object

loop -clause - loop clause
58
all-aboxes
function
Description: Returns the names of all known ABoxes.

Syntax: (all-aboxes)
Values: List of ABox names
all-individuals
function
Description: Returns all individuals from the specied ABox.

Syntax: (all-individuals &optional (abox *current-abox*))
Arguments: abox
- ABox object
all-concept-assertions-for-individual
function
Description: Returns all concept assertions for an individual from the specied ABox.
Syntax: (all-concept-assertions-for-individual IN
Arguments: IN
abox
- individual name
- ABox object
Values: List of concept assertions

See also: Function all-concept-assertions on page 60.
all-role-assertions-for-individual-in-domain
function
Description: Returns all role assertions for an individual from the specied ABox in which
the individual is the role predecessor.
Syntax: (all-role-assertions-for-individual-in-domain IN
Arguments: IN
abox
- individual name
- ABox object
Values: List of role assertions

Remarks: Returns only the role assertions explicitly mentioned in the ABox, not the
inferred ones.
See also: Function all-role-assertions on page 60.
59
all-role-assertions-for-individual-in-range
function
Description: Returns all role assertions for an individual from the specied ABox in which
the individual is a role successor.
Syntax: (all-role-assertions-for-individual-in-range IN
Arguments: IN
abox
- individual name
- ABox object
Values: List of assertions

See also: Function all-role-assertions on page 60.
all-concept-assertions
function
Description: Returns all concept assertions from the specied ABox.

Syntax: (all-concept-assertions &optional (abox *current-abox*))
Arguments: abox
- ABox object
all-role-assertions
function
Description: Returns all role assertions from the specied ABox.

Syntax: (all-role-assertions &optional (abox *current-abox*))
Arguments: IN
abox
- individual name
- ABox object

See also: Function all-concept-assertions-for-individual on page 59.
60
describe-abox
function
Description: Generates a description for the specied ABox.

Syntax: (describe-abox &optional (abox *current-abox*)
Arguments: abox
- ABox object

Values: abox
describe-individual
function
Description: Generates a description for the individual from the specied ABox.
Syntax: (describe-individual IN &optional (abox *current-abox*)
Arguments: IN
abox
- individual name
- ABox object

Values: IN
61
KRSS Sample Knowledge Base
The following knowledge base is specied in KRSS syntax. It is a version of the knowledge
base used in the Sample Session, on page 1.
A.1
KRSS Sample TBox
;;;===============================================================
;;; file "racer:examples;family-tbox-krss.lisp".
;;; initialize the TBox family
(in-tbox family :init t)
;;; the roles
(define-primitive-role has-child :parents (has-descendant))
(define-primitive-role has-descendant :transitive t)
(define-primitive-role has-sibling)
(define-primitive-role has-sister :parents (has-sibling))
(define-primitive-role has-brother :parents (has-sibling))
(define-primitive-attribute has-gender)
(implies top (all has-child person))
(implies (some has-child top) parent)
(implies (some has-sibling top) (or sister brother))
(implies top (all has-sibling (or sister brother)))
(implies top (all has-sister (some has-gender female)))
(implies top (all has-brother (some has-gender male)))
;;; the concepts
(define-primitive-concept person
(and human (some has-gender (or female male))))
(define-disjoint-primitive-concept female (gender) top)
(define-disjoint-primitive-concept male (gender) top)
(define-primitive-concept woman (and person (some has-gender female)))
(define-primitive-concept man (and person (some has-gender male)))
(define-concept parent (and person (some has-child person)))
(define-concept mother (and woman parent))
(define-concept father (and man parent))
(define-concept grandmother
(and mother
(some has-child
(some has-child person))))
62
(define-concept
(define-concept
(define-concept
(define-concept
A.2
aunt (and woman (some has-sibling parent)))

uncle (and man (some has-sibling parent)))
brother (and man (some has-sibling person)))
sister (and woman (some has-sibling person)))
KRSS Sample ABox
;;;===============================================================
;;; file "racer:examples;family-abox-krss.lisp".
;;; initialize the ABox smith-family and use the TBox family
(in-abox smith-family family)
;;; closing the role has-sibling for charles
Integrated Sample Knowledge Base
This section shows an integrated version of the family knowledge base.

;;;===============================================================
;;; file "racer:examples;family-kb.lisp".
(in-knowledge-base family smith-family)
63
(signature :atomic-concepts (person human female male woman man

parent mother father grandmother
aunt uncle sister brother)
:roles ((has-descendant :transitive t)
(has-child :parent has-descendant)
has-sibling
(has-sister :parent has-sibling)
(has-brother :parent has-sibling)
(has-gender :feature t))
:individuals (alice betty charles doris eve))
(implies *top* (all has-child person))
(implies (some has-child *top*) parent)
(implies (some has-sibling *top*) (or sister brother))
(implies *top* (all has-sibling (or sister brother)))
(implies *top* (all has-sister (some has-gender female)))
(implies *top* (all has-brother (some has-gender male)))
;;; the concepts
(implies person (and human (some has-gender (or female male))))
(disjoint female male)
(implies woman (and person (some has-gender female)))
(implies man (and person (some has-gender male)))
(equivalent
(equivalent
(equivalent
(equivalent
(equivalent
(equivalent
(equivalent
(equivalent
parent (and person (some has-child person)))

mother (and woman parent))
father (and man parent))
grandmother
(and mother
(some has-child
(some has-child person))))
aunt (and woman (some has-sibling parent)))
uncle (and man (some has-sibling parent)))
brother (and man (some has-sibling person)))
sister (and woman (some has-sibling person)))

64

;;; closing the role has-sibling for charles
References
[Buchheit et al. 93] M. Buchheit, F.M. Donini & A. Schaerf, Decidable Reasoning in Terminological Knowledge Representation Systems, in Journal of Articial Intelligence
Research, 1, pp. 109-138, 1993.
[Haarslev and M
oller 2000] Haarslev, V. and M
oller, R. (2000), Expressive ABox reasoning
with number restrictions, role hierarchies, and transitively closed roles, in Proceedings
of Seventh International Conference on Principles of Knowledge Representation and
Reasoning (KR2000), Cohn, A., Giunchiglia, F., and Selman, B., editors, Breckenridge, Colorado, USA, April 11-15, 2000, pages 273284.
[Horrocks-et-al. 99a] I. Horrocks, U. Sattler, S. Tobies, Practical Reasoning for Description Logics with Functional Restrictions, Inverse and Transitive Roles, and Role Hierarchies, Proceedings of the 1999 Workshop Methods for Modalities (M4M-1), Amsterdam, 1999.
[Horrocks-et-al. 99b] I. Horrocks, U. Sattler, S. Tobies, A Description Logic with Transitive
and Converse Roles, Role Hierarchies and Qualifying Number Restrictions, Technical
Report LTCS-99-08, RWTH Aachen, 1999.
[Horrocks et al. 2000] Horrocks, I., Sattler, U., and Tobies, S. (2000). Reasoning with individuals for the description logic SHIQ. In MacAllester, D., editor, Proceedings of the
17th International Conference on Automated Deduction (CADE-17), Lecture Notes in
Computer Science, Germany. Springer Verlag.
[Patel-Schneider and Swartout 93] P.F. Patel-Schneider, B. Swartout Description Logic
Knowledge Representation System Specication from the KRSS Group of the ARPA
Knowledge Sharing Eort, November 1993. The paper is available as:
http://www-db.research.bell-labs.com/user/pfps/papers/krss-spec.ps
65
Index
bottom, 20
*auto-classify*, 30
*auto-realize*, 30
*bottom*, 20
*current-abox*, 17
*current-tbox*, 14
*top*, 19
abox-consistent-p, 40
abox-consistent?, 41
abox-name, 19
abox-realized-p, 40
abox-realized?, 40
add-concept-assertion, 27
add-concept-axiom, 23
add-disjointness-axiom, 23
add-role-assertion, 28
add-role-axioms, 26
alc-concept-coherent, 34
all-aboxes, 57
all-atomic-concepts, 50
all-concept-assertions, 58
all-concept-assertions-for-individual,
57
all-features, 51
all-individuals, 57
all-role-assertions, 58
all-role-assertions-for-individual-in-domain, 57
all-role-assertions-for-individual-in-range, 58
all-roles, 51
all-tboxes, 50
all-transitive-roles, 51
assertion, 9
atomic-concept-ancestors, 46
atomic-concept-children, 47
atomic-concept-descendants, 45
atomic-concept-parents, 47
atomic-concept-synonyms, 45
atomic-role-ancestors, 48
atomic-role-children, 49
atomic-role-descendants, 48
atomic-role-inverse, 37
atomic-role-parents, 50
attribute, 8, 23
66
check-abox-coherence, 41
check-tbox-coherence, 38
classify-tbox, 38
concept axioms, 7
concept denition, 8
concept equation, 8
concept term, 6
concept-ancestors, 46
concept-children, 46
concept-descendants, 45
concept-disjoint-p, 33
concept-disjoint?, 32
concept-equivalent-p, 32
concept-equivalent?, 32
concept-instances, 53
concept-is-primitive-p, 33
concept-is-primitive?, 34
concept-offspring, 46
concept-p, 33
concept-parents, 47
concept-satisfiable-p, 31
concept-satisfiable?, 30
concept-subsumes-p, 31
concept-subsumes?, 31
concept-synonyms, 44
concept?, 33
conjunction of roles, 9
define-concept, 22
define-disjoint-primitive-concept,
22
define-distinct-individual, 29
define-primitive-attribute, 25
define-primitive-concept, 21
define-primitive-role, 24
delete ABox, 18
delete TBox, 14
describe-abox, 59
describe-concept, 52
describe-individual, 59
describe-role, 52
describe-tbox, 51
disjoint, 21
disjoint concepts, 8, 21, 22
range restriction, 9
realize-abox, 40
reflexive-p, 37
reflexive?, 37
related, 28
related-individuals, 55
rename ABox, 18
rename TBox, 14
retraction, 11
retrieve-concept-instances, 54
retrieve-direct-predecessors, 56
retrieve-individual-filled-roles,
56
retrieve-individual-fillers, 54
retrieve-related-individuals, 55
role hierarchy, 9
role-ancestors, 48
role-children, 49
role-descendants, 47
role-inverse, 38
role-offspring, 48
role-p, 35
role-parents, 49
role-subsumes-p, 35
role-subsumes?, 34
role?, 35
domain restriction, 9
ensure-abox-signature, 16
ensure-tbox-signature, 13
equivalent, 21
exists restriction, 7
feature, 8, 23, 25
feature-p, 36
feature?, 36
find-abox, 18
find-tbox, 15
forget, 30
forget-concept-assertion, 27
forget-role-assertion, 29
GCI, 7, 20
implies, 20
in-abox, 15
in-knowledge-base, 17
in-tbox, 12
individual-direct-types, 52
individual-equal?, 43
individual-fillers, 54
individual-instance-p, 42
individual-instance?, 41
individual-not-equal?, 43
individual-p, 43
individual-types, 53
individual?, 43
individuals-related-p, 42
individuals-related?, 42
inference modes, 10
init-abox, 16
init-tbox, 12
instance, 27
instantiators, 53
save-abox, 18
save-tbox, 14
signature, 6
signature, 13
state, 29
subrole, 23, 25
superrole, 23, 25
symmetric-p, 36
symmetric?, 37
taxonomy, 44
tbox, 19
tbox-classified-p, 39
tbox-classified?, 39
tbox-coherent-p, 39
tbox-coherent?, 39
tbox-name, 15
top, 19
transitive role, 9, 23
transitive-p, 35
transitive?, 36
load ABox, 17
load TBox, 14
loop-over-aboxes, 56
loop-over-tboxes, 50
most-specific-instantiators, 53
name set, 44
number restriction, 7
primitive concept, 8
67
unique name assumption, 10

value restriction, 7
68

Racer Manual 1 6 PDF

Uploaded by

Copyright:

Available Formats

Racer Manual 1 6 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Racer Manual 1 6 PDF

Uploaded by

Copyright:

Available Formats

RACER Users Guide and Reference Manual

2 Obtaining and Running RACER

3 RACER Knowledge Bases

Concept Axioms and Terminology . . . . . . . . . . . . . . . . . . . . . . .

Retraction and Incremental Additions . . . . . . . . . . . . . . . . . . . . .

4 Knowledge Base Management Functions

5 Knowledge Base Declarations

7 Evaluation Functions and Queries

Queries for Concept Terms . . . . . . . . . . . . . . . . . . . . . . . . . . .

TBox Evaluation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .

ABox Evaluation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . .

A KRSS Sample Knowledge Base

A.1 KRSS Sample TBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2 KRSS Sample ABox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B Integrated Sample Knowledge Base

Obtaining and Running RACER

For the Macintosh execute the self-extracting archive <filename>.sea.

;;; supply the signature for this TBox

Figure 1: Role hierarchy for the family TBox.

The RACER Session:

Figure 2: Concept hierarchy for the family TBox.

;;; load the TBox

;;; Alice is the mother of Betty and Charles

(instance alice mother)

charles :(and brother (at-most 1 has-sibling))

Figure 3: Depiction of the ABox smith-family.

The RACER Session:

Throughout this document we use the following abbreviations, possibly subscripted.

Name of any sort

RACER Knowledge Bases

Figure 5: Attribute expressions.

Concept Axioms and Terminology

RACER supports several kinds of concept axioms.

Figure 6: Conicting declared and inherited role properties.

Figure 7: Domain and range restrictions expressed via GCIs.

teenager (and human (min age 16)))

Obviously, Racer determines that the concept seriously-ill-human is subsumed by

Retraction and Incremental Additions

RACER oers constructs for retracting ABox assertions (see forget,

Knowledge Base Management Functions

- is the name of the TBox.

Description: Denes the signature for a knowledge base.

Description: If a pathname is specied, a TBox is saved to a le. In case a stream is

Arguments: pathname -or -stream - is the pathname of a le or an output stream

- is the name of the TBox to be found.

errorp - if bound to t an error is signaled if the TBox is not found.

Description: Finds the name of the given TBox object.

Values: TBox name

Remarks: If the specied TBox does not exist, an error is signaled.

The specied ABox is the *current-abox* until in-abox is called again or

- ABox object to initialize.

- TBox object associated with the ABox

Values: ABox object

individuals - is a list of individual names, specifying I.

Description: This form is an abbreviation for the sequence:

name - Package name

Description: If a pathname is specied, an ABox is saved to a le. In case a stream is

Arguments: pathname -or -stream - is the name of the le or an output stream.

- is the name of the ABox to be found.

The specied ABox is the current-abox until in-abox is called again or