# KEHOME/doc/MKEtutorial.html
# Jun/15/2014
MKR/MKE Tutorial

MKR/MKE Tutorial
version 8.5

For more details see

Contents

  1. Knowledge Representation
    1. propositions
    2. attributes & values
    3. actions & events & products
    4. relations & infons
    5. parts & partvalues
    6. hierarchies & definitions
    7. conditionals & iteration
    8. methods
    9. arrays
    10. namespace stack
  2. Knowledge Explorer
    1. input/output
    2. questions
    3. commands
    4. assignments
    5. exploring
    6. databases
  3. Concept Formation
    1. context
    2. definitions & pronouns
    3. integration & differentiation
    4. measurement & classification
    5. units & primitives
    6. individual concepts & collective concepts
    7. axiomatic propositions
  4. Semantic Web
    1. XML, RDF, OWL, CycL languages
    2. MKE + TAP
    3. MKE + OpenCyc
    4. MKE + Google
    5. MKE + Amazon
  5. Using Other Languages
    1. Unicon
    2. UNIX shell
    3. Java
    4. REBOL
  6. Method Library
    1. commands
    2. utility functions
    3. MKE internal functions
    4. genealogy relations

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 17).
A sentence is a statement, question, command, or assignment.
The context or sentence may be omitted.  Nesting is allowed,
i.e., the sentence may be generalized to a proposition list.

MKE automatically generates a unique name for every
proposition.  You can assign your own name to a proposition
using this form

	pname :: proposition

When we discuss axiomatic propositions in section 23, you will
see how useful a name can be.

This section briefly describes the basic sentence formats. 
Subsequent sections describe in more detail statements,
questions, commands, assignments, input/output, definitions
and concept formation.

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

	let variable = value;

Assignments are used to change the values of parameters
which control options in representing and processing
knowledge.

There are two basic statement formats.

	subject verb object prepphrase;
	subject do action prepphrase done;

Subject, object, prepphrase may be a single phrase
or a comma-separated list of phrases.

NOTE:
"do" is a verb, but a different format is used because subject and prepphrase are optional. Different verbs are used to denote different kinds of characteristics (properties) of the subject. By enumerating the different verbs, we get nine variations of the two basic statement formats. subject is object; # identity/alias subject isa object with # definition attribute = value; subject isa object; # hierarchy: isa,ismem,... subject isin relation = value; # n-ary relation subject rel relation = value; # binary relation subject hasp part = value; # part subject has attribute = value; # attribute subject do action = event # action out product # product := subject do ... done; of action domain with action characteristic od direct object from initial characteristic to final characteristic done; subject causes object; # interaction Lastly, there is a compound statement which is used to define special groups such as hierarchies and relations. begin gtype gname; # group: hierarchy,relation,triple,... groupstatement1; groupstatement2; ... end gtype gname; Let's look at a few examples. 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 linereturn 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;

An alternate associative-array syntax may be used
to specify attributes (and other characteristics).
For example:

	John[sex] := male;
	Mary[sex] := female;

The associative array notation is especially useful
for GDBM database operations (see section 16).

3. actions & events & products

Actions characterize changes in attributes.
An event is an occurrence (instance) of an action.
A product is the result produced by 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;
Note: "can" may be used instead of "do*".

4. relations & infons

Binary and n-ary relations of entities have a format
similar to attributes, e.g.:

	u:John isin phonebook = u:phonebook_001;
	u:John rel father=u:Sam, mother=u:Susan;
	u:John rel isa person, isa engineer;

NOTE: 
The third example is a direct mapping of the format typically used in RDF and OWL. "u:phonebook_001" is a relation "unit" (or "tuple" or "infon") u:123-456-7890, u:John; The definition of an n-ary relation explicitly specifies the meaning of a relation unit in the current view, e.g.: phonebook is relation with automatic="isa", format=[u:phone:1, u:person:2], meaning={u:$2 has phone=u:$1;}; Meaning is a list of propositions enclosed in braces {}, or the name of a method. (Methods also have format and meaning attributes.) "1" and "2" are local variables whose values are denoted by "$1" and "$2". You may choose other variable names, e.g. "phone" and "person". "$0" is set equal to the name of the infon, i.e., the current instance of the relation. Other local variables are declared using the "local" attribute of the relation (See section 8 for an example). Once the relation is defined, the infons (aka tuples aka relation units) are specified as follows: begin relation phonebook; 123-456-7890, John; 987-654-3210, Mary; end relation phonebook; which produces: u:123-456-7890,u:John isin phonebook=u:phonebook_001; u:John has phone=u:123-456-7890; u:987-654-3210,u:Mary isin phonebook=u:phonebook_002; u:Mary has phone=u:987-654-3210; and u: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. The default value of automatic is "isa". A concept (ususally) 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 11). For example: phonebook is relation with format=[phone:1; person:2], meaning={$2 has phone=$1;}; do read from phonebook.rel done; Relation (and method) meanings can also be implemented as Unicon procedures. A Unicon implementation is declared using the "meaningtype" attribute of the relation (see section 8).

5. parts & partvalues

Attributes, actions and relations are "inseparable"
characteristics of entities.  Parts are "separable"
characteristics.  Parts can be physically separated
from the entity.  When separated, the part becomes
a  new physical entity.  Entities and their parts
are expressed in the same form as other ke
characteristics, e.g.

	John hasp leg;
	leg  isap John;

	television set hasp
	    picture tube = x19_005,
	    tuner = y75;

6. hierarchies & definitions

Knowledge is organized into lists of propositions,
which are the basic knowledge units (knits).
These knits can be conveniently disclayed as
entity-characteristic-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 22.)

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 personhi;
	person;
	/  John;
	/  Mary;
	/  Bill;
	end hierarchy personhi;

A complete hierarchy for the knowledge unit (knit) of section 2 is

	begin hierarchy existenthi;
	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 existenthi;

Hierarchies may be stored in files and read into
Knowledge Explorer using the read command (see
section 11).  For example:

	do read from person.ho done;

The structure of the hierarchy can be changed by
integration and differentiation (see section 19).

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. 
The hierarchy disclay the genus-species relations
between concepts and individuals, but does not indicate
the nature of the similarities and differences between
them.  That is the role of the definition.  In MKR, a
definition has the form

	subject is genus with differentia;

The genus-differentia definition (and several other
forms of definition) are discussed in section 18.

7. conditionals & iteration

(Some examples in this section use methods, questions,
and commands.  See sections 8, 12, 13, 15.)

A conditional statement has the format:

	if proposition then proposition list else proposition list fi;

For example:

	if {unit1 isa concept2;}
	   and {unit1 has attribute3;};
	then concept2 has attribute3;
	fi;

	if John isin phonebook;
	then let . = John; do call od $phone done;
	else do print od "John not in phonebook" done;
	fi;

As another example of the associative array syntax,
the latter conditional can be expressed as

	if John isin phonebook;
	then do call od John[phone] done;
	else do print od "John not in phonebook" done;
	fi;

Iteration statements have the format:
(Note: when is not implemented.)

	while proposition { proposition list };
	until proposition { proposition list };
	every generator   { proposition list };
	when  event       { proposition list };


where proposition and proposition list
are the same as in conditional statements.
Generator is a special proposition which
has one of these formats:

	variable isa   genus;
	variable isalt exgroup;
	variable ismem ingroup;
	variable isin  relation;
	variable in    concept1, ...;

or a variable with a pplist modifier
which has one of these formats:

	variable from first to last;
	variable of array;

Proposition list 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:

	let finished = no;
	while $finished is no {
		...
		let finished = yes;
		...
	};

	let count = 0;
	until $count is 10 {
		...
		count := do add od $count,1 done;
		...
	};

	every p isa person {
	    do char od $p done;
	};

	every pb in phonebook {
	    . is $pb;                    # see section 18
	    do print od "$2, $1;" done;  # reverse order
	};

	every x in person, event {
	    $x isc* ?;  # subhierarchy
	};

	every x from 2 to 4 {
	    do print od $x done;
	};
	every y from 4 to 2 {  # count backwards
	    do print od $y done;
	};
	every index in gdbmarray {
	    do print od $index done;
	};

To exit from every,while,until loops use

	break;

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 13).

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 19
	do delete od John Doe done;

"1" and "2" are local variables.  You can use names
instead of numbers.  "$0" is the name of the event, i.e.,
the current instance of execution of the method.
Other local variables are declared using the
"local" attribute of the method.  For example:

	get info is method with
		format=[person:1],
		local=[addr,mail,tel],
		meaning={
			addr := $1 has address=?;
			mail := $1 has email=?;
			tel := $1 has phone=?;
			do print od "$1 $mail $tel $addr" done;
		};

A special form of assignment is used to return the product
of a method (see section 14).

Method (and relation) meanings can also be implemented as
Unicon procedures.  A Unicon implementation is declared
using the "meaningtype" attribute of the method.  Here is
an example from the genealogy application in the MKE
knowledge base.

  r_birth is relation with 
    label=[pid,sex,birthdate,birthplace,deathdate,deathplace,deathcause],
    format=[person:1,sex:2,time:3,space:4,time:5,space:6,cause:7],
    automatic=ISU,
    meaningtype=procedure,
    meaning=procedure_birth;

The Unicon procedure is invoked as

	procedure_birth(name,dollar_tuple)

where name is the method (or relation) name and 
dollar_tuple is the Unicon table of argument values.
For example, this MKR relation tuple

	begin relation r_birth;
	Jane Doe 1933,female,1933,Kansas,NA,NA,NA;
	end relation r_birth;

produces the following input (in Unicon syntax) to the Unicon
procedure procedure_birth.

	name := "r_birth"
	dollar_tuple["$0"] := "r_birth_321"
	dollar_tuple["$1"] := "Jane Doe 1933"
	dollar_tuple["$2"] := "female"
	dollar_tuple["$3"] := "1933"
	dollar_tuple["$4"] := "Kansas"
	dollar_tuple["$5"] := "NA"
	dollar_tuple["$6"] := "NA"
	dollar_tuple["$7"] := "NA"

If r_birth were declared as a method instead of a relation,
this MKR method invocation

	do r_birth od Jane Doe 1933,female,1933,Kansas,NA,NA,NA done;

would produce the same input to the Unicon procedure.

Methods may use the same preposition-phrase format
as actions.  For example:

	list member is method with
	    format={do list member od member:5
			from list:61,index:62
			to   list:71,index:72
			done;};
	    meaningtype=procedure,
	    meaning=list_member;

For this more general case, the Unicon procedure
interface uses a list for each preposition.  The
mapping to Unicon lists is

	at stvlist {
	    do methodname
		out  productlist  # product := do ... done;
		of   domainlist
		with optionlist
		od   directobjectlist
		from initiallist
		to   finallist
	    done;
	};

and the Unicon procedure is invoked as

	procedurename(methodname,ppobject)

where ppobject is a record whose fields contain all
of the above lists in the same order

	record PPOBJECT (
		stvlist,		# at	$1
		productlist,		# out	$2
		domainlist,		# of	$3
		optionlist,		# with	$4
		directobjectlist,	# od	$5
		initiallist,		# from	$6
		finallist		# to	$7
	)

The method event name is argument $0.

9. arrays

see method.def
associative array expressions
concept[char] := value;  # insert
value := concept[char];  # fetch
do delete od char from concept done;  # delete
concept1[char1] := concept2[char2];  # copy

associative array methods do dump/gdbm od concept to file done;
control structures every char in concept { ... };
ordinary array expressions
list[index] := member;  # insert
member := list[index];  # fetch
list1[index1] := list2[index2]; # copy

list methods do empty od list done;
control structures every index from i to j { ... };

10. 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 are referred to
by number.  For example:

	move isa method with
	    format = {do move od existent:1 to genus:2 done;},
	    meaning = {
		$1 isd $2;
	    };

Each view is a separate name space. (See section 17.)

II. Knowledge Explorer

11. input/output

When Knowledge Explorer starts, it automatically reads the files KEHOME/kb/tabrasa.html KEHOME/kb/ke.html KEHOME/kb/initial.mkr When KE terminates (without an "exit;"), it automatically reads the file KEHOME/kb/final.mkr If KE is executed using ke myfile.ku (or by clicking on myfile.ku) the following files are opened: input file <myfile.ku> output file <myfile.out> error file <myfile.err> log file <myfile.log> If ke is executed with no arguments ke (or by clicking on ke) the following files are opened: input file <input> # keyboard output file <output> # disclay error file <errout> # disclay log file <input.log> The output file will contain: input sentences (unless "let echo=off;") answers to user questions output from user commands output from "check" command (unless "let hcheck=no;" or "exit;") concepts in hfocus list (unless "exit;") The error file will contain: "ERROR" messages critical "WARNING" messages The log file will contain: "INFO" messages requested by "let debug=xxx;" assignment "INFO" messages automatically generated by KE non-critical "WARNING" messages "Internal ERROR" messages You can access other files using the read and write commands. The read command has the format: do read from filename done; You can include a "with" phrase to access files whose contents do not follow the usual conventions, e.g.: do read with relseparator=":" from /etc/passwd done; reads the UNIX "passwd" file, which contains the "password" relation, using a relation separator of ":" instead of the default KE separator ",". The extension of a file has no effect on how Knowledge Explorer processes the file. The file extension is simply a user-friendly way to document what kind of knowledge the file contains. For example .ku knit .cu chit (see section 3) .rel relation (see section 4) .ho hierarchy outline (see section 6) .dir file system directory hierarchy .html,.htm knit (HTML commands are ignored) .nt Ntriple file .rdf Resource Description Framework file .mcf TAP MCF file .mkr MKR script Concepts from the current view may be saved in a file using the write command. For example: let hfocus = [person,event]; do write od $hfocus to save.ho done; writes the "person" subhierarchy and the "event" subhierarchy to the file "save.ho". This can also be written as do write od person,event to save.ho done;

12. questions

True-false questions are constructed by enclosing a sentence within
"if" and "fi;".  For example:

	if John isa man; fi;

Form-based questions are constructed by replacing one or more elements
of a sentence by "?".  For example:

	John has ?;
	Mary has sex=?;
	John do ? done;
	? has sex;
	? has sex=female;

Here are some more complex examples.

	apple ? orange;		# relation between concepts
	sex isa**? existent;	# number of hierarchy levels
	? is ?;			# all definitions
	? has ?;		# all attributes
	John isa* ?;		# all concepts from John to existent
	animal isc* ?;		# animal subhierarchy
	existent isc**2 ?;	# levels 0,1,2 of existent subhierarchy

13. commands

Commands are predefined Knowledge Explorer actions which you can
execute using sentences of the form

	do cmdname
		with command characteristics
		out  command products (outputs)
		od   command arguments (inputs)
		from initial characteristics
		to   final   characteristics
	done;

Note that

	do cmdname ... done;

is really just a shorthand notation for

	ke do cmdname ... done;

Likewise, you can use

	! cmdname ... done;

as a shorthand notation for executing a shell command

	sh do cmdname ... done;


Example commands:

	do usize od person done;	# count units of person
	do check od definition done;	# check for undefined concepts

	password isa relation;
	do read od password		# read UNIX password file
		from /etc/passwd
		with kformat=rel,relseparator=":"
	done;

(See section 11 re UNIX passwd file.)

The complete list of KE commands is obtained by entering:

	ke do  ? done;
	ke hdo ? done;

The definition of any command is obtained by entering:

	cmdname is ?;

"hdo" and "vdo" are two special forms of commands.
"hdo" commands are executed on each concept as ke
walks a path in the knit hierarchy.
"vdo" commands are executed once in each view
as ke walks a path through the views.

The "exec" command is especially useful with "vdo"
since it allows you to execute statements, questions
and assignments in other views.

	vdo exec od {propositionlist} done;

Most of the "hdo" commands were designed to facilitate
the "internal" hierarchy functions that MKE performs.
Here are some of the more useful "external" commands.

	cycprint
	define
	dump
	print
	procedure   # name of a Unicon procedure
	read directory
	write directory

For example, this command prints an alphabetical
dictionary of all concepts in the hierarchy.

	hdo define od existent with alpha done;

NOTE:
Before you print a dictionary, be sure to read all
the definitions from the KEHOME/kb/*.def files.

The "od cname" phrase specifies the direct objects
of the hdo command.  The most useful variants are

	od .	# current concept
	od ..	# current genus of .
	od ...	# current species|unit of .

"od ." is the default and need not be specified
explicitly.

The "with path" phrase is used to specify how ke
walks the hierarchy.  For example, this command
will dump all of the animals in the ANIMAL
subhierarchy.

	hdo dump od ANIMAL with ISC done;

User-defined commands (see section 8) are defined as
methods, e.g.:

	mycommand is method with ...;
	do mycommand ... done;

14. assignments

An assignment has the form

	let variable = value;
or
	variable := value;

which are shorthand notations for

	 ke has variable = value;

The assignment form using the ":=" operator and
the associative array assignments (see section 9)
are both special cases of the production syntax
(see section 3).  The action required to produce
value is implicit.

Assignments are used to change the values of KE attributes,
which in turn control various options in processing
knowledge.  For example,

	let hfocus = [person, event, hierarchy];

changes the list of concepts which will be written to the
output file by the write command.  To obtain a complete list
of KE attributes, enter:

	ke has ?;

To obtain the definition of any particular attribute, enter:

	variable is ?;

To obtain the values of KE attributes, enter:

	ke has variable = ?;	# current value
	let variable = ?;	# current value
	do help od value done;	# legal values
	variable isall ?;	# values used

A special form of assignment is used to return the product
of a method.  For example:

	return Product = $answer;

After setting the value of Product, all remaining propositions
in the method are ignored.

15. exploring

To facilitate the exploration of hierarchies (or lattices) the following pronouns are defined: (Pronouns are special variables -- see section 18)
	/	existent
	..	current genus of current concept
	.	current concept
	...	current species of current concept

/ is a read-only variable. The other (dot) variables can be changed using:
	..  is next;		# next genus of current concept
	.   is myconcept;	# change current concept
	... is next;		# next unit of current concept
When . is changed, ke stores the attributes, actions, etc. of the current concept in dollar variables. If the current concept is a relation infon, ke also stores the argument values in $1,$2,...
Here's an example: $ ke ... ke startup messages ... ke$ at view=myview; # context <at view=myview;> ... input knowledge for myview ... ke$ let echo = off; ke$ . is person; ke$ . isa* ?; person \ animal \\ entity \\\ existent ke$ . isc* ?; person / John / Mary ke$ . is Mary; ke$ . isa* ?; Mary \ person \\ animal \\\ entity \\\\ existent ke$ . has ?; . do ? done; Mary has sex=female; Mary do walk from home to store done; ke$ do print od $sex done; female ke$ exit; ... ke termination messages ... $ A more sophisticated interface for exploring hierarchies uses hdo methods:
	hdo method od directobject
		from initial concept
		to   final concept
		with path
	done;
This command accesses the internal Unicon procedures hwalk() and hdo() which are used to implement many functions in MKE (see KEHOME/src/hwalk.icn.)
NOTE:
"hdo" is a built-in MKR verb. The syntax for using "hdo" is the same as for "do".

Here's an example.
	levels := hdo count from man to existent with ISA done;
counts the number of levels between man and existent as you go up the hierarchy using "isa" links (genus of units and genus of species).

16. databases

When knowledge bases get large, it is important to be able to save previously processed knowledge for fast retrieval. In other words, we need a good database system. MKE utilizes the standard GDBM interface which is built into the Unicon language.


GDBM databases
use associative array syntax
use arraymode to access external databases
use arraykey to handle n-ary relations

Unicon also supports SQL databases, but MKE does not currently make use of this capability.

III. Concept Formation

17. context

Context is specified by

	at space=s,time=t,view=v;

where
	s denotes where action occurs
	t denotes when  action occurs
	v denotes knowledge unit (knit)
A knowledge unit is a named proposition list. It is stored internally as an entity-characteristic-proposition (ECP) hierarchy.

Each knit describes units (concrete individuals) and a genus- species hierarchy of related concepts (abstract classes of individuals). Depending on your purpose, you may choose different units and/or different concepts. There may be different knits/views/contexts which describe the same facts of reality from different points of view.

Each view is a separate name space. When necessary for disambiguation, the view name is used as a prefix to the concept name. For example:

	at view=aristotle {
	    man is person;
	};
	at view=feminist {
	    man,woman isa person;
	};
	aristotle:man is feminist:person;
There are some global names which are known in all views. For example
	views is the set of all view names
	spaces is the set of all space names
	times is the set of all time names

18. definitions & pronouns

A concept or unit (see section 21) definition has the format

	# genus-differentia
	concept isa genus with differentia;
	unit    isa genus with differentia;
or
	# ostensive
	genus isc concept1, concept2, ..., conceptn;
	genus isc unit1,    unit2,    ..., unitn;
or
	# production
	concept := entity do action ... done;
	unit    := entity do action ... done;

where
	"isa" and "isa" specify that the genus is on the
	next hierarchy level above the concept or unit

	differentia is a set of essential characteristics --
	characteristics (or relations of characteristics)
	which distinguish the concept|unit from all other
	concepts|units with the same genus

	ostensive is a complete enumeration of all
	concepts/units which are subsumed by the genus

	":=" means "is the product of", i.e., the
	concept|unit is the result produced by performing
	the specified action
NOTE:
It is important to distinguish between units (concretes) and concepts (abstractions). If the context makes this distinction clear, we can use either of these forms
	x is  genus with differentia;
	x isa genus with differentia;
NOTE:
The definition by enumeration for relations, hierarchies, unithierarchies uses the begin-end group.

Here are a few examples:
(attributes, actions and relations are characteristics)

	# context
	animal do live,move done;
	man has sex, rational;
	man do identify done;

	# definition
	animal isa entity with live, move;
	man is animal with rational;
	knowledge := man do identify od existent done;
	sex isc male, female;
	hierarchy isa group with order="isa", genus=single;
	lattice   isa group with order="isa", genus=multiple;
Pronouns are context-dependent aliases for concepts
or individuals.  A pronoun is a very special kind of
variable.  Ordinary variables are defined by
assignments and referenced by dollar values.

	let x = John;
	$x do go to the store done;

Pronouns are defined by identities and referenced
by name (following common English usage).

	he is John;
	he do go to the store done;

Section 15 gives some further examples of pronouns
which are useful in exploring hierarchies.

19. integration & differentiation

The "isd" and "isi" verbs are used to change relations
between existing concepts, which were established with
"isa" and "isc".  For example,

	John, Mary isa person;
	person isc engineer, teacher;
	John isa engineer;
	Mary isa teacher;

yields the lattice

	person
	/	John
	/	Mary
	/	engineer
	//		John
	/	teacher
	//		Mary

Applying the "corrections"

	John isd engineer;
	Mary isd teacher;

yields the hierarchy

	person
	/	engineer
	//		John
	/	teacher
	//		Mary

The differentiate and integrate commands are used to create
new concepts in an existing hierarchy, using the attributes
of existing concepts.  The general format of these commands is

	do integrate od unit1, ... with attribute1, ... done;
	do differentiate od concept with attribute1, ... done;

Here is an example (with "engineer" and "teacher" now being
"profession"s instead of "person"s):

	John, Mary, Sue, Tom isa person;
	John, Sue has profession=engineer;
	Mary, Tom has profession=teacher;
	do differentiate od person with profession done;

yields

	person
	/	person_profession_engineer
	//		John
	//		Sue
	/	person_profession_teacher
	//		Mary
	//		Tom

Using the identities

	person_profession_engineer is engineer;
	person_profession_teacher is teacher;

yields

	person
	/	engineer
	//		John
	//		Sue
	/	teacher
	//		Mary
	//		Tom

20. measurement & classification

The measure command is used to determine new attributes
for existing concepts.  The format is

	do measure od concept with attribute1, ... done;

The measure command executes a (user-supplied) method
to calculate each new attribute:

	let echo = off;
	every cname isa concept {
	    every attrname in attribute1, ... {
		do measure_$attrname od $cname done;
			# result stored in $Command
		$cname has $attrname=$Command;
	    };
	};
	let echo = on;

The classify command is used to place an "unknown" concept
into an existing hierarchy.  The format is

	do classify od newconcept to oldconcept with attribute1, ... done;

For example:

	Nancy has profession=engineer;
	do classify od Nancy to person with profession done;

yields

	person
	/	person/profession_engineer
	//		John
	//		Nancy
	//		Sue
	/	person/profession_teacher
	//		Mary
	//		Tom

21. units & primitives

Ayn Rand defines a unit as

	A unit is an existent regarded as
	a separate member of a group of
	two or more similar members.

Units are concretes viewed as members of
an abstract group.  The group is a "primitive" concept.
When higher-level concepts are formed from primitives,
the units are also units of the higher-level concepts.

The MKR syntax for units is

	unit,...  isa primitive;
	primitive isc unit,...;

It is important to distinguish between units (concretes)
and concepts (abstractions).  A concept with no units
is a nonexistent, i.e., a contradiction.  A concept whose
units have not been identified is a "floating abstraction".

To specify the analogous relations between higher-level
concepts, the MKR syntax is

	species,... isa genus;
	genus       isc species,...;

To include both cases, the MKR syntax (as used in earlier
sections) is

	x,...   isa concept;
	concept isc x,...;


A hierarchy outline can be used to specify the
unit-primitive relations:

	begin hierarchy myprim;
	genus;
	/  u:unit1;
	/  u:unit2;
	...
	end hierarchy myprim;


Multi-level verbs are useful in questions:

	uname isa* ?;	# all species & concepts
	cname isc* ?;	# all species & units

22. individual concepts & collective concepts

Ayn Rand defines a concept as

	A concept is a mental integration of two or
	more units possessing the same distinguishing
	characteristics, with their particular
	measurements omitted.

The mental integration may either be exclusive (individual)
or inclusive (collective).

For the moment, let's talk about groups instead of concepts.
A group can be either exclusive (exgroup) or inclusive (ingroup).
The existents which are viewed as members of the group are
called units.  Thus

	An exgroup is any one of two or more similar units.
	An ingroup is all of two or more similar units.

In my MKR language, these are expressed as

	exgroup isany unit1, unit2, ...;
	ingroup isall unit1, unit2, ...;

For example

	dog  isany Dutchess, Reno, ...;
	dogs isall Dutchess, Reno, ...;

Note that the corresponding exgroup-hierarchy
and ingroup-hierarchy appear to be the same,
but the relationship of the units is different.

	dog
	    Dutchess
	    Reno
	    ...

	dogs
	    Dutchess
	    Reno
	    ...

The exgroup and ingroup which subsume the same units
are related by

	dogs is all dog;
	dog  is any dogs;


Throughout this tutorial, I have used isa/isc
to relate groups and their memebers, because
the distinction between exgroup and ingroup
was not important.  When/if the distinction
is important, I will use isalt/isany or
ismem/isall.

Returning to concepts, we may now note explicitly that

	individual concept isa exgroup;
	collective concept isa ingroup;

Other common abstract groups are

	enumeration is  exgroup with order = none;
	set         is  ingroup with order = none;
	list        is  ingroup with order = space; 
	sequence    is  ingroup with order = time;
	hierarchy   is  group   with order = "isa", unique genus;
	lattice     is  group   with order = "isa", ambiguous genus;
	filesystem  isa hierarchy;

Particular members of a group can be specified by
using a quantifier-concept phrase.  For example

	a dog		a dogs
	some dog	some dogs
	the dog		the dogs
	any dog		any dogs

Quantifiers can also be used to express nonexistence
and total inclusivity.

	no dog		no dogs
	all dog		all dogs

Classical syllogisms use the quantifiers all, no, some.
The "is" must be translated:
    use "isa" for unit|species-genus relations;
    use "has" for entity-attribute relations;
    use "do" for entity-action relations;
    etc.

23. axiomatic propositions

begin hierarchy axiomhi;
existent;  # universe
/  entity;
//	man;
/  characteristic;  # exists
//	attribute;
///	    conscious;
//	action;
///	    exist;
///	    identify;
/  proposition;
//	Existence;
//	Identity;
//	Consciousness;
//	Identification;
//	Duality;
end hierarchy axiomhi;
Existence :: entity exists;
Identity  :: entity HAS charcteristic;
Consciousness  :: man has conscious;
Identification :: characteristic := man do identify od entity done;

Existence     IS Identity;
Consciousness IS Identification;

Duality :: {entity has power;} IS {entity can act done;};

universe is all existent;  # collective concept (ingroup)
existent is any universe;  # individual concept (exgroup)

IV. Semantic Web

MKE uses shell scripts and Java programs to interface with the standard Java APIs of

24. XML, RDF, OWL, CycL languages

XML is a generalization of the HTML language used for document presentation on the World Wide Web. XML provides a richer structure and meaning than HTML. XML syntax is used by both RDF and OWL.

RDF and OWL are standard knowledge representation languages that were developed by the non-profit organization W3C. Their "name spaces" are a very crude kind of context (view). They have no n-ary relations and no methods. Questions are only available in separate languages such as RDQL. Logical inferences are only available in separate languages such as Euler or Pychinko.

Despite their many deficiencies, RDF and OWL will probably be widely used just because they are standards. RDF is currently used in the Stanford TAP knowledge base.

CycL is a knowledge representation language developed by Cycorp. CycL has the same power as MKR, but its LISP-like syntax makes it harder to read and write. Cycorp's future plans include an English interface to their knowledge base.

CycL is currently used in the OpenCyc knowledge base. OpenCyc includes logical inferences which are intended to mimic human common sense.

25. MKE + TAP

In its default mode (kbmode=mke), MKE interacts with it own internal knowledge base. Changing modes (kbmode=tap) causes MKE to interact with the external TAP knowledge base at the Stanford web site. The RDF translations of MKR statements are stored in the KEHOME/data/ directory. A typical interaction with TAP looks like this.
$ . tap.env
$ ke
ke$ do open cyc od $kehome/data to $kehome/data/mydata.rdf done;
ke$ let kbmode = tap;
ke$ MKR statement;
ke$ ...
ke$ MKR question;
ke$ ...
ke$ exit;
$

In addition to the direct MKE/TAP interface described above, there is a standalone interface (using only Java and UNIX shell). The interface language for "mketap" is MKR. The interface language for "tap" is RDF "simplified statements and questions".

See KEHOME/bin/tap/mketap
See KEHOME/bin/tap/tap
See KEHOME/bin/tap/mkr2tap
See KEHOME/java/tap/*.java
See KEHOME/bin/tap/GetData
See KEHOME/bin/tap/GetResource
See KEHOME/bin/tap/PutData
See KEHOME/bin/tap/rdf2mcf
Usually, the TAP Java API is installed in /home/tap. If it is installed elsewhere, you can use a soft link or modify the KEHOME/bin/tap.env file.

26. MKE + OpenCyc

Interacting with OpenCyc is a little more complicated because you have to define all your terms before use. Thus a typical interaction with OpenCyc consists of a definition session followed by a question session.
$ . cyc.env
$ ke
ke$ let kbmode = cyc;
ke$ ### definitions
ke$ do open cyc from myworld done;
CYC(): do cyc-create od "concept", ... done;
CYC(): MKR statement;
CYC(): ...
CYC(): do write-image to myworld done;

ke$ ### questions
ke$ do open cyc from myworld done;
CYC(): MKR statement;
CYC(): ...
CYC(): MKR question;
CYC(): ...
CYC(): exit;
ke$ exit;
$
See KEHOME/bin/cyc/cyc
See KEHOME/bin/cyc/opencyc
NOTE:
In contrast to OpenCyc, MKE is very liberal about accepting new terms "on the fly" and determining their meaning by context/usage. For example, if "dick do jane done;" is input to MKE, then MKE knows that dick is an entity and jane is an action that was performed by dick.

In addition to the direct MKE/OpenCyc interface described above, there is a standalone interface (using only Java and UNIX shell). The interface language for "mkecyc" is MKR. The interface language for "cyc" is CycL "simplified statements and questions".

See KEHOME/bin/cyc/mkecyc
See KEHOME/bin/cyc/mkr2cyc
See KEHOME/bin/cyc/cyc
See KEHOME/bin/cyc/cycprint
See KEHOME/bin/cyc/cyclist2column
See KEHOME/bin/cyc/cycbind2column
Usually, the OpenCyc Java API is installed in /home/cyc. If it is installed elsewhere, you can use a soft link or modify the KEHOME/bin/cyc.env file.

27. MKE + Google

To use this "private" Google search engine, you need to register with Google to get your own identification key. Your key is stored in the file
	GOOGLE_HOME/googleapi/google.key
To do a Google search, you put this in your MKR script:
! google option arg done;
The available options are The first three options are part of the standard Google API. The last two options are my own additions which I thought you would find useful. The search and cached options return only the first 10 results found by Google.
See KEHOME/bin/google
Usually, the Google Java API software is installed in /home/google. If it is installed elsewhere, you can use a soft link or modify the KEHOME/bin/google command.

28. MKE + Amazon

The KEHOME/bin/amazon command does not require any special Amazon API. It uses the standard product categories defined at Amazon.com. Each category is associated with an internal Amazon Map code.

To search Amazon.com, put this in your MKR script

! amazon category done;
The 32 product categories are
(spaces and "&" are deleted from categories)
See KEHOME/bin/amazon

V. Using Other Languages

29. Unicon

The meaning of an MKR method or relation can be implemented as an MKR script, or as a Unicon procedure. The interface to a Unicon procedure is specified by
	meaningtype = procedure
	meaning = procedure_name
Before the Unicon procedure is executed, MKE does "automatic" declarations and local variable initialization. Then, if
	format=[class:1,...]
the procedure is called as
procedure(name,dollar_table)  # relation
procedure(name,dollar_table)  # method with od directobject in fixed order
and if
	format={MKR proposition}
the procedure is called as
procedure(name,ppobject)      # method with any prepphrases in any order
Usually, the Unicon compiler is installed in /home/unicon. If it is installed elsewhere, the KEHOME/bin/*.env files should be modified.

30. UNIX shell

Local operating system commands can be executed from an MKR script using this format:
	! shcmd with options od directobject
		from infiles to outfiles done;
For example:
	! ls with -lt od *.icn to programs.txt done;
	! sort with -o person.txt od person.txt done;

31. Java

You can execute the Java compiler or the Java run time system
from a shell script or an MKR script.
For example:
	javac getdata.java
	java -cp googleapi.jar "$demo" "$key" "$1" "$2"
Usually, the Java compiler is installed in /home/java. If it is installed elsewhere, the KEHOME/bin/*.env files should be modified.

32. REBOL

REBOL is an internet messaging language.
REBOL provides "one-liner" commands for email, http, ftp, etc.
You can execute rebol from a shell script or an mKR script.
For example:
	rebol -iqsw --do "send $Recipient {found $msg}"
REBOL/Core 2.6.2 is included in the mKE download. The REBOL programs reside in the KEHOME/rebol/ directory.

VI. Method Library

33. commands

See MKE commands
See MKE methods
NOTE:
A number of these "commands" are former "utility functions" or "MKE internal functions", which I decided to make availble to all MKE users.

Here are a few examples.

do clock od label done;
do dump/gdbm od gdbmtable to file done;
do dump/ged to file done;
do find od pattern from subhierarchy done;
do random od list done;
do read rdf from file done;
do simplify lattice od subhierarchy done;
do size od object done;
do sum od list done;
do unique od basename done;

34. utility functions

These are general purpose functions which may be useful to those who write their own Unicon programs for use with the standard MKE system.

See utility functions
See type conversion functions
See Unicon procedures

Here are a few examples:

procedure writes_type(fd,x,label,tail)
procedure writes_type_all(x,label,tail)
procedure writes_any(fd,x,sep,head,tail,join,list0,list1,list2,string0,option)
procedure writes_any_all(x,sep,head,tail)
procedure parse_list(s,sep)
procedure delete_separator(L,sep)
procedure enquote(s,sep)
procedure dequote(s)
procedure remove_bracket(s)
procedure remove_brace(s)
procedure remove_paren(s)
procedure random(arglist)
procedure sum_list(L)

35. MKE internal functions

These are procedures tailored to specific MKE
processing which will be useful to anyone who
wants to make extensions to the MKR/MKE system.
See word and token parsing
See symbol parsing
See symbol unparsing
See word phrases
See name=value phrases
See prepositional phrases
See bselists (enclosed in [] or {})
See Unicon procedures

Here are a few examples:

	interpret_line(line,kformat,dollar)
will parse and interpret a single line as it it were read from the input file. "kformat" specifies the input format. "dollar" controls the optional substitution of dollar variable values.
	nvsub(line,nvtab)
does dollar variable substitutions in line, using the name-value pairs in the Unicon table nvtab. The name-value pairs are of the form
	nvtab["$name"] := value

36. genealogy relations

Unicon implementation for speed
aka.rel
birth.rel, death.rel
child.rel
marriage.rel, divorce.rel

other relations
address.rel
phone.rel
school.rel
work.rel
note.rel

You can easily add your own relations. Just build the definition file my.rel and add "do read from my.rel done;" to family.ku.

Likewise, you can easily add your own report generation functions. Just write a new MKR script "my.mkr", and add two lines to the makefile

	my.txt: my.mkr
		ke my.mkr

Note that there a number of utility functions which process names, dates, times, etc.


MKE home