# KEHOME/doc/MKEtutorial.html
# Mar/12/2003
#=======================#
# MKE Tutorial #
# version 5.3 #
# #
# 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
II. Knowledge Explorer
9. input/output
10. questions
11. commands
12. assignments
13. exploring
III. Concept Formation
14. context
15. definitions
16. integration & differentiation
17. measurement & classification
18. units & primitives
19. 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 14). 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 9 - 13) and definitions,
concept formation (see sections 15 - 19).
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 five basic statement formats.
subject is object;
subject has attribute;
subject do action
with action characteristic
out product # product := subject do ... done
od direct object # argument
from initial characteristic
to final characteristic
done;
subject rel object with attribute;
gname is begin group;
unit1
unit2
...
end group gname;
For example:
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, action, initial, final
may be comma-separated lists of phrases.
NOTE:
In some cases, e.g., the value of the "format" attribute,
the list is enclosed in square brackets [].
In other cases, e.g., the value of the "meaning" attribute,
the list of propositions is 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:
/ \ $ . * ? !
Statements are automatically continued to the next line when
there is an incomplete syntactic structure, e.g.:
do/done
if/fi
list with separator = "," or ";"
expressions with & | ~
[...]
{...}
<...>
subject rel object;
rel ::= is isin isa isc ... causes means ...
preposition phrase
preposition ::= at of with out od from to
The relation block format (see section 4) is
relname is begin relation;
argument1; argument2; ...; argumentN
...
end relation relname;
The hierarchy block 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 "/".
The directory block format is
dirname is begin directory;
file1;
file2;
...
filen;
end directory dirname;
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 = [123-456-7890, John];
"phonebook" is the relation, and "[123-456-7890, John]"
is the infon (instance of the relation, or relation unit).
The relations that specify attributes and actions are
special relations, for which "format" and "meaning"
are the same. The definition of a general relation must
explicitly specify the meaning of a relation unit ("infon")
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 or a method which defines
the statements which are to executed for each infon in the
relation. (Methods also have format and meaning attributes.)
Once the relation is defined, the infons are specified
as follows:
phonebook is begin relation;
123-456-7890, John;
987-654-3210, Mary;
end relation phonebook;
which produces:
123-456-7890,John isin phonebook=[123-456-7890, John];
987-654-3210,Mary isin phonebook=[987-654-3210, Mary];
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 9). 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 19.)
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 9). For example:
do read from person.ho done;
The structure of the hierarchy can be changed by
integration and differentiation (see section 16).
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, 10, 11, 13.)
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 13
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 11).
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 16
do delete od John Doe done;
II. Knowledge Explorer
#====================#
9. 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