# KEHOME/doc/MKEtutorial.html # Jun/15/2014
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 "/".
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).
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*".
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).
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;
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.
(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;
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.
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 { ... };
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.)
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
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;
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.
/ existent .. current genus of current concept . current concept ... current species of current concept
.. is next; # next genus of current concept . is myconcept; # change current concept ... is next; # next unit of current conceptWhen . 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,...
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.)
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).
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.
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
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 actionNOTE:
x is genus with differentia; x isa genus with differentia;NOTE:
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.
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
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
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
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.
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)
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.
$ . 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/rdf2mcfUsually, 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.
$ . 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/opencycNOTE:
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/cycbind2columnUsually, 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.
GOOGLE_HOME/googleapi/google.keyTo do a Google search, you put this in your MKR script:
! google option arg done;The available options are
See KEHOME/bin/googleUsually, 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.
To search Amazon.com, put this in your MKR script
! amazon category done;The 32 product categories are
See KEHOME/bin/amazon
meaningtype = procedure meaning = procedure_nameBefore 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 orderand if
format={MKR proposition}
the procedure is called as
procedure(name,ppobject) # method with any prepphrases in any orderUsually, the Unicon compiler is installed in /home/unicon. If it is installed elsewhere, the KEHOME/bin/*.env files should be modified.
! 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;
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.
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.
See MKE commands See MKE methodsNOTE:
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;
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)
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
aka.rel birth.rel, death.rel child.rel marriage.rel, divorce.rel
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