# KEHOME/doc/MKEtutorial.html
# Apr/14/2003
#=======================#
# MKE Tutorial #
# version 5.5 #
# #
# Richard H. McCullough #
#=======================#
For more details see
KEHOME/doc/MKRgrammar.html
KEHOME/doc/MKRtoken.html
KEHOME/src/symbol.icn
KEHOME/src/token.icn
KEHOME/doc/userman.htm (1999)
Contents
#======#
I. Knowledge Representation
1. propositions
2. attributes & values
3. actions & events
4. relations & infons
5. parts
6. hierarchies
7. conditionals & iteration
8. methods
9. namespace stack
II. Knowledge Explorer
10. input/output
11. questions
12. commands
13. assignments
14. exploring
III. Concept Formation
15. context
16. definitions
17. integration & differentiation
18. measurement & classification
19. units & primitives
20. individual concepts & collective concepts
I. Knowledge Representation
#=========================#
1. propositions
#=============#
My knowledge representation language, MKR, characterizes
knowledge as a sequence of propositions with the format
at context { sentence };
The context is specified by space, time, view (see
section 15). A sentence is a statement, question, command,
assignment, or a proposition list enclosed in {}.
This section briefly describes the basic statement formats.
Subsequent sections describe questions, commands, assignments,
input/output (see sections 10 - 14) and definitions,
concept formation (see sections 15 - 20).
Comments begin with a sharp sign and extend to the end
of the line, e.g.:
# this is a comment
An assignment has the format
set variable = value;
Assignments are used to change the values of parameters
which control options in representing and processing
knowledge.
There are seven basic statement formats.
subject is object; # alias
subject rel object; # binary relation: isa,ismem,...
subject isa object with # definition
attribute = value;
subject haspart part = value; # part
subject has attribute = value; # attribute
subject isin relation = value; # n-ary relation
subject do action = event # action
with action characteristic
out product # product := subject do ... done
od direct object
from initial characteristic
to final characteristic
done;
subject causes object; # interaction
begin gtype gname; # gtype: hierarchy,relation,ntriple,...
groupstatement1;
groupstatement2;
...
end gtype gname;
For example, here is an action statement:
John, Mary do walk to the store done;
where
subject: John, Mary
action: walk
final: the store # space = the store
In general, subject, object, attribute=value, etc.
may be comma-separated lists of phrases.
NOTE:
Values may be phrase lists enclosed in square brackets [],
or proposition lists enclosed in braces {}.
A phrase is a consecutive sequence of words separated
by white space. A word is a consecutive sequence of
characters which does not include any separators.
The separators are listed below.
white space (blank tab return newline newpage)
#
" '
[ ] { } ( ) < >
= += -= *= :=
& | ~
, ;
NOTE:
The following characters may be included in a word:
/ \ $ . * ? !
All statements are terminated with a semicolon.
One statement may continue over many lines.
Many statements may be on one line.
The relation group format (see section 4) is
begin relation relname;
argument1, argument2, ..., argumentN;
...
end relation relname;
The hierarchy group format (see section 6) is
begin hierarchy honame;
genus1;
/ concept1;
// species1;
// species2;
...
/ concept2;
...
genus2;
...
end hierarchy honame;
The number of "/"s specifies the level in the hierarchy.
White space before and after the "/"s is ignored, and is
used to make the outline more readable. You can also
specify a path from bottom to top of the hierarchy
by using "\" instead of "/".
2. attributes & values
#====================#
The simplest type of statement specifies an attribute
of an entity, e.g.:
John has sex=male;
Mary has sex=female;
"John" and "Mary" are entities; "sex" is an attribute;
"male" and "female" are its values.
Boolean attributes have a value of true or false,
e.g.:
John has alive=true;
Bill has alive=false;
or the equivalent statements
John has alive;
Bill has not alive;
3. actions & events
#=================#
Actions characterize changes in attributes.
An event is an occurrence (instance) of an action.
Only entities can perform actions;
any existent can have attributes.
Here is an example of the general action/event format:
John do move = move_123
od table, chairs
from dining room
to living room
done;
"move" is the action; "move_123" is the event.
An event is the occurrence of an action; it identifies
this particular instance of the action.
Here are a few more examples:
Mary do walk from home to store done;
John do run from 10:00am to 10:15am done;
Bill do hit od the ball to the fence done;
The product of an action is expressed as:
knowledge := man do identify od existent done;
":=" means "is the product of"; i.e., "knowledge" is
the result produced by "man" performing the action
"identify" on the object "existent".
MKR distinguishes an action declaration (meaning that
an entity has the capability, or "power", to perform
the action) from an event (an occurence of the action).
An action declaration adds a "*" suffix to the "do" verb
and the event name. Here are some examples of action
declarations
John has power=talk;
John do* talk done;
John do* walk=walk_123*
from home to store
done;
and events
John do talk done;
John do walk=walk_456
from home to store
done;
4. relations & infons
#===================#
General relations of entities have a format similar to
attributes and actions, e.g.:
John isin phonebook = phonebook_001;
where "phonebook" is the relation, and "phonebook_001"
is the relation statement (or "unit" or "tuple" or "infon")
123-456-7890, John;
The definition of a relation must explicitly specify the
meaning of a relation unit in the current view, e.g.:
phonebook is relation with
automatic="isa",
format=[phone:1, person:2],
meaning={$2 has phone=$1;};
Meaning is a list of propositions enclosed in braces {},
or the name of a method. (Methods also have format
and meaning attributes.) Once the relation is defined,
the units are specified as follows:
begin relation phonebook;
123-456-7890, John;
987-654-3210, Mary;
end relation phonebook;
which produces:
123-456-7890,John isin phonebook=phonebook_001;
987-654-3210,Mary isin phonebook=phonebook_002;
John has phone=123-456-7890;
Mary has phone=987-654-3210;
and
123-456-7890 isa phone;
John isa person;
987-654-3210 isa phone;
Mary isa person;
The second group of statements consists of all
the "automatic" declarations. Sometimes these
cause problems, i.e., more than one genus for
the argument. To avoid such problems, you can
change the "automatic" attribute of a relation.
For example,
phonebook has automatic="isa*";
produces the declarations
123-456-7890 isa* phone;
John isa* person;
987-654-3210 isa* phone;
Mary isa* person;
and
phonebook has automatic="none";
produces no automatic declarations.
A concept has only one genus, but has many classes.
(The "*" suffix denotes 0 or more levels in the
hierarchy; thus any concept at or above John in
the hierarchy is a class of John:
John isa* class;
See section 6.)
Relations may be stored in files and read into
Knowledge Explorer using the read command (see
section 10). For example:
phonebook is relation with
format=[phone:1; person:2],
meaning={$2 has phone=$1;};
do read from phonebook.rel done;
5. parts
#======#
Attributes, actions and relations are "inseparable"
characteristics of entities. Parts are "separable"
characteristics. Parts can be physically separated
from the entity. Entities and their parts are expressed
in the same form as other ke characteristics, e.g.
John haspart leg;
leg isapart John;
television set haspart
picture tube = x19_005,
tuner = y75;
6. hierarchies
#============#
Knowledge is organized into lists of propositions,
which are the basic knowledge units (knits).
These knits can be conveniently displayed as
entity-concept-proposition hierarchies, Such
ECP-hierarchies consist of mutually exclusive concepts,
e.g.:
person iseither John or Mary or Bill;
(For the present, we will consider only individual concepts;
collective concepts will be discussed in section 20.)
This statement can be abbreviated as
person isc John, Mary, Bill;
or
John, Mary, Bill isa person;
Hierarchies can also be expressed in outline format, e.g.:
begin hierarchy person;
person;
/ John;
/ Mary;
/ Bill;
end hierarchy person;
A complete hierarchy for the knowledge unit (knit) of section 2 is
begin hierarchy existent;
existent;
/ person;
// John;
// Mary;
// Bill;
/ attribute;
// sex;
/// male;
/// female;
// alive;
/// true;
/// false;
/ statement;
// s_attribute;
/// s_sex;
//// {John has sex=male;};
//// {Mary has sex=female;};
/// s_alive;
//// {John has alive;};
//// {Bill has not alive;};
// s_hierarchy;
/// {John, Mary, Bill isa person;};
end hierarchy existent;
Hierarchies may be stored in files and read into
Knowledge Explorer using the read command (see
section 10). For example:
do read from person.ho done;
The structure of the hierarchy can be changed by
integration and differentiation (see section 17).
Each hierarchy represents a particular view of knowledge,
a knit, and is labeled with a view name, e.g.:
at view = myview;
The initial contents of a new knit are copied from the
knit which contains the "at" statement. The knit that
contains all other knits is named tabula_rasa.
The "isc" and "isa" verbs denote relations between adjacent
levels of the hierarchy. To specify multilevel relations, the
following suffixes are used:
**n n levels
* 0 or more levels
+ 1 or more levels
For example:
John isa**2 entity;
means that John is two levels below entity in the hierarchy,
and
John isa* x;
means that John is at or below x in the hierarchy. Any concept
x which satisfies this relation is called a "class" of John.
7. conditionals & iteration
#=========================#
(Some examples in this section use methods, questions,
and commands. See sections 8, 11, 12, 14.)
A conditional statement has the format:
if sentence1 then sentence2 else sentence3 fi;
For example:
if unit1 isa concept2
and unit1 has attribute3;
then concept2 has attribute3;
fi;
if John isin phonebook;
then set . = John; do call od $phone done;
else do print od "John not in phonebook" done;
fi;
Iteration statements have the format:
every generator { proposition list };
where generator has one of these formats:
variable in concept1, ...
variable isa genus
variable isalt exgroup
variable ismem ingroup
variable isin relation
and sentence uses $variable to denote the particular
value of variable, and $1,$2,... to denote the arguments
of the particular infon $variable of a relation.
For example:
every x in person, event {
$x isc* ?; # subhierarchy
};
every p isa person {
do char od $p done;
};
every pb ismem phonebook {
set . = $pb; # see section 14
do print od "$2; $1" done; # reverse order
};
8. methods
#========#
A method is a user-defined action, with arguments.
A method is defined in the same way a relation
is defined (see section 4).
A method is executed in the same way that a
KE command is executed (see section 12).
Here are two simple examples:
char is method with
format=[existent:1],
meaning={$1 is ?; $1 has ?; $1 do ?; $1 isin ?;};
do char od Mary done;
delete is method with
format=[existent:1],
meaning={$1 isd nonexistent;}; # "isd" - see section 17
do delete od John Doe done;
9. namespace stack
#================#
KE maintains a stack of local argument names for each
invocation of a method, relation, and every loop.
For methods and relations, arguments can be referred to
by name or by number. For example:
move isa method with
format = {do move od existent:1 to genus:2 done;},
meaning = {
$1 isd $2;
};
where the meaning could alternately be expressed as
$existent isd $genus;
II. Knowledge Explorer
#====================#
10. input/output
#==============#
If Knowledge Explorer is executed using
ke myfile.ku
(or by clicking on myfile.ku) the following files are opened:
input file
output file
error file
log file
If ke is executed with no arguments
ke
(or by clicking on ke) the following files are opened:
input file # keyboard
output file