    # KEHOME/doc/MKEtutorial.html
    # May/21/2003

    #=======================#
    # MKR/MKE Tutorial      #
    # version 5.6           #
    #                       #
    # Richard H. McCullough #
    #=======================#
    For more details see
      KEHOME/doc/MKRgrammar.html
      KEHOME/doc/MKRtoken.html
      KEHOME/src/symbol.icn
      KEHOME/src/token.icn
      KEHOME/kb/tabrasa.def
      KEHOME/kb/ke.def
      KEHOME/doc/API*.*

    Contents
    #======#
    I. Knowledge Representation
        1. propositions
        2. attributes & values
        3. actions & events
        4. relations & infons
        5. parts & partvalues
        6. hierarchies

        7. conditionals & iteration
        8. methods
        9. namespace stack

    II. Knowledge Explorer
        10. input/output
        11. questions
        12. commands
        13. assignments
        14. exploring

    III. Concept Formation
        15. context
        16. definitions
        17. integration & differentiation
        18. measurement & classification
        19. units & primitives
        20. individual concepts & collective concepts

    I. Knowledge Representation
    #=========================#

    1. propositions
    #=============#
    My knowledge representation language, MKR, characterizes
    knowledge as a sequence of propositions with the format

    	at context { sentence };

    The context is specified by space, time, view (see
    section 15).  A sentence is a statement, question, command,
    assignment, or a proposition list enclosed in {}.
    This section briefly describes the basic statement formats.
    Subsequent sections describe questions, commands, assignments,
    input/output (see sections 10 - 14) and definitions,
    concept formation (see sections 15 - 20).

    Comments begin with a sharp sign and extend to the end
    of the line, e.g.:

    	# this is a comment

    An assignment has the format

    	set variable = value;

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

    There are seven basic statement formats.

        subject is object;			# alias

        subject rel object;			# binary relation: isa,ismem,...

        subject isa object with		# definition
    		attribute = value;

        subject haspart part      = value;	# part
        subject has     attribute = value;	# attribute
        subject isin    relation  = value;	# n-ary relation

        subject do action = event		# action
    	with action characteristic
    	out  product			# product := subject do ... done
    	od   direct object
    	from initial characteristic
    	to   final   characteristic
        done;

        subject causes object;		# interaction

        begin gtype gname;			# gtype: hierarchy,relation,ntriple,...
        groupstatement1;
        groupstatement2;
        ...
        end gtype gname;

    For example, here is an action statement:

    	John, Mary do walk to the store done;

    where

    	subject: John, Mary
    	action:  walk
    	final:   the store    # space = the store

    In general, subject, object, attribute=value, etc.
    may be comma-separated lists of phrases.

    NOTE:
    Values may be phrase lists enclosed in square brackets [],
    or proposition lists enclosed in braces {}.

    A phrase is a consecutive sequence of words separated
    by white space.  A word is a consecutive sequence of
    characters which does not include any separators.
    The separators are listed below.

    	white space (blank tab return newline newpage)
    	#
    	" '
    	[ ] { } ( ) < >
    	= += -= *= :=
    	& | ~
    	, ;

    NOTE:
    The following characters may be included in a word:

    	/ \ $ . * ? !

    All statements are terminated with a semicolon.
    One statement may continue over many lines.
    Many statements may be on one line.

    The relation group format (see section 4) is

    	begin relation relname;
    	argument1, argument2, ..., argumentN;
    	...
    	end relation relname;

    The hierarchy group format (see section 6) is

    	begin hierarchy honame;
    	genus1;
    	/   concept1;
    	//      species1;
    	//      species2;
    	...
    	/   concept2;
    	...
    	genus2;
    	    ...
    	end hierarchy honame;

    The number of "/"s specifies the level in the hierarchy.
    White space before and after the "/"s is ignored, and is
    used to make the outline more readable.  You can also
    specify a path from bottom to top of the hierarchy
    by using "\" instead of "/".

    2. attributes & values
    #====================#
    The simplest type of statement specifies an attribute
    of an entity, e.g.:

    	John has sex=male;
    	Mary has sex=female;

    "John" and "Mary" are entities; "sex" is an attribute;
    "male" and "female" are its values.

    Boolean attributes have a value of true or false,
    e.g.:

    	John has alive=true;
    	Bill has alive=false;

    or the equivalent statements

    	John has alive;
    	Bill has not alive;

    3. actions & events
    #=================#
    Actions characterize changes in attributes.
    An event is an occurrence (instance) of an action.
    Only entities can perform actions;
    any existent can have attributes.

    Here is an example of the general action/event format:

    	John do move = move_123
    		od table, chairs
    		from dining room
    		to living room
    	done;

    "move" is the action; "move_123" is the event.
    An event is the occurrence of an action; it identifies
    this particular instance of the action.

    Here are a few more examples:

    	Mary do walk from home to store done;
    	John do run from 10:00am to 10:15am done;
    	Bill do hit od the ball to the fence done;

    The product of an action is expressed as:

    	knowledge := man do identify od existent done;

    ":=" means "is the product of"; i.e., "knowledge" is
    the result produced by "man" performing the action
    "identify" on the object "existent".

    MKR distinguishes an action declaration (meaning that
    an entity has the capability, or "power", to perform
    the action) from an event (an occurence of the action).
    An action declaration adds a "*" suffix to the "do" verb
    and the event name.  Here are some examples of action
    declarations

    	John has power=talk;
    	John do* talk done;
    	John do* walk=walk_123*
    		from home to store
    		done;

    and events

    	John do talk done;
    	John do walk=walk_456
    		from home to store
    	done;

    4. relations & infons
    #===================#
    General relations of entities have a format similar to
    attributes and actions, e.g.:

    	John isin phonebook = phonebook_001;

    where "phonebook" is the relation, and "phonebook_001"
    is the relation statement (or "unit" or "tuple" or "infon")

    	123-456-7890, John;

    The definition of a relation must explicitly specify the
    meaning of a relation unit in the current view, e.g.:

    	phonebook is relation with
    		automatic="isa",
    		format=[phone:1, person:2],
    		meaning={$2 has phone=$1;};

    Meaning is a list of propositions enclosed in braces {},
    or the name of a method.  (Methods also have format
    and meaning attributes.) Once the relation is defined,
    the units are specified as follows:

    	begin relation phonebook;
    	123-456-7890, John;
    	987-654-3210, Mary;
    	end relation phonebook;

    which produces:

    	123-456-7890,John isin phonebook=phonebook_001;
    	987-654-3210,Mary isin phonebook=phonebook_002;
    	John has phone=123-456-7890;
    	Mary has phone=987-654-3210;

    and

    	123-456-7890 isa phone;
    	John isa person;
    	987-654-3210 isa phone;
    	Mary isa person;

    The second group of statements consists of all
    the "automatic" declarations.  Sometimes these
    cause problems, i.e., more than one genus for
    the argument.  To avoid such problems, you can
    change the "automatic" attribute of a relation.
    For example,

    	phonebook has automatic="isa*";

    produces the declarations

    	123-456-7890 isa* phone;
    	John isa* person;
    	987-654-3210 isa* phone;
    	Mary isa* person;

    and

    	phonebook has automatic="none";

    produces no automatic declarations.

    A concept has only one genus, but has many classes.
    (The "*" suffix denotes 0 or more levels in the
    hierarchy; thus any concept at or above John in
    the hierarchy is a class of John:
    	John isa* class;
    See section 6.)

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

    	phonebook is relation with
    		format=[phone:1; person:2],
    		meaning={$2 has phone=$1;};
    	do read from phonebook.rel done;

    5. parts & 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 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-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 20.)

    This statement can be abbreviated as

    	person isc John, Mary, Bill;

    or

    	John, Mary, Bill isa person;

    Hierarchies can also be expressed in outline format, e.g.:

    	begin hierarchy person;
    	person;
    	/  John;
    	/  Mary;
    	/  Bill;
    	end hierarchy person;

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

    	begin hierarchy existent;
    	existent;
    	/	person;
    	//		John;
    	//		Mary;
    	//		Bill;
    	/	attribute;
    	//		sex;
    	///			male;
    	///			female;
    	//		alive;
    	///			true;
    	///			false;
    	/	statement;
    	//		s_attribute;
    	///			s_sex;
    	////				{John has sex=male;};
    	////				{Mary has sex=female;};
    	///			s_alive;
    	////				{John has alive;};
    	////				{Bill has not alive;};
    	//		s_hierarchy;
    	///			{John, Mary, Bill isa person;};
    	end hierarchy existent;

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

    	do read from person.ho done;

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

    Each hierarchy represents a particular view of knowledge,
    a knit, and is labeled with a view name, e.g.:

    	at view = myview;

    The initial contents of a new knit are copied from the
    knit which contains the "at" statement.  The knit that
    contains all other knits is named "tabula rasa".

    The "isc" and "isa" verbs denote relations between adjacent
    levels of the hierarchy.  To specify multilevel relations, the
    following suffixes are used:

    	**n	n levels
    	*	0 or more levels
    	+	1 or more levels

    For example:

    	John isa**2 entity;

    means that John is two levels below entity in the hierarchy,
    and

    	John isa* x;

    means that John is at or below x in the hierarchy.  Any concept
    x which satisfies this relation is called a "class" of John.

    7. conditionals & iteration
    #=========================#
    (Some examples in this section use methods, questions,
    and commands.  See sections 8, 11, 12, 14.)

    A conditional statement has the format:

    	if sentence1 then sentence2 else sentence3 fi;

    For example:

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

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

    Iteration statements have the format:

    	every generator { proposition list };

    where generator has one of these formats:

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

    and sentence uses $variable to denote the particular
    value of variable, and $1,$2,... to denote the arguments
    of the particular infon $variable of a relation.

    For example:

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

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

    	every pb ismem phonebook {
    	    set . = $pb;                # see section 14
    	    do print od "$2; $1" done;  # reverse order
    	};

    8. methods
    #========#
    A method is a user-defined action, with arguments.
    A method is defined in the same way a relation
    is defined (see section 4).
    A method is executed in the same way that a
    KE command is executed (see section 12).

    Here are two simple examples:

    	char is method with
    		format=[existent:1],
    		meaning={$1 is ?; $1 has ?; $1 do ?; $1 isin ?;};
    	do char od Mary done;

    	delete is method with
    		format=[existent:1],
    		meaning={$1 isd nonexistent;};  # "isd" - see section 17
    	do delete od John Doe done;

    9. namespace stack
    #================#
    KE maintains a stack of local argument names for each
    invocation of a method, relation, and every loop.
    For methods and relations, arguments can be referred to
    by name or by number.  For example:

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

    where the meaning could alternately be expressed as

    	$existent isd $genus;

    II. Knowledge Explorer
    #====================#

    10. input/output
    #==============#
    If Knowledge Explorer is executed using

    	ke myfile.ku

    (or by clicking on myfile.ku) the following files are opened:

    	input  file <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>	# display
    	error  file <errout>	# display
    	log    file <input.log>

    The output file will contain:

    	input sentences (unless "set echo=off;")
    	answers to user questions
    	output from user commands
    	output from "check" command
    		(unless "set 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 "set 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:

    	set 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;

    11. 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

    12. 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 10 re UNIX passwd file.)

    The complete list of KE commands is obtained by entering:

    	ke do ? done;

    The definition of any command is obtained by entering:

    	cmdname is ?;

    Most commands are executed only in the current knit.
    These two commands access knowledge in all knits:

    	vdo exec od {sentence} done;
    	vdo find od name done;	# "*" is wildcard

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

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

    13. assignments
    #=============#
    An assignment has the form

    	set variable = value;

    which is a shorthand notation for

    	 ke has variable = value;

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

    	set 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
    	set variable = ?;	# current value
    	do help od value done;	# legal values
    	variable isall ?;	# values used

    14. exploring
    #===========#
    To facilitate the exploration of hierarchies (or lattices)
    the following variables (ke attributes) are defined:

    	/	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:

    	set ..  = next;		# next genus of current concept
    	set .   = myconcept;	# change current concept
    	set ... = next;		# next unit of current concept

    When . is changed, set stores the attributes, actions, etc. of the
    current concept in dollar variables.  If the current concept
    is a relation infon, set also stores the argument values in
    $1,$2,...  See KE User Manual for details.

    Here's an example:
    (Note that ke input prompt is enclosed by <>,
    and echo of input sentence is enclosed by <>.)

    	$ ke

    	... startup messages from ke ...

    	<v_input:.=existent> at view=myview;
    	# context <at view=myview;>

    	... input knowledge for myview ...

    	<myview:.=existent> set . = person;
    	# assignment <set . = person;>
    	<myview:.=person> set .. = next;
    	# assignment <set .. = next;>
    	<myview:..=animal> set ... = next;
    	# assignment <set ... = next;>
    	<myview:...=John> set ... = next;
    	# assignment <set ... = next;>
    	<myview:...=Mary> set . = ...;
    	# assignment <set . = ...;>
    	<myview:.=Mary> $. isa* ?;
    	# question <Mary isa* ?;>
    	Mary
    	\  person
    	\\    animal
    	\\\      entity
    	\\\\        existent
    	<myview:.=Mary> $. has ?; $. do ? done;
    	# question <Mary has ?;>
    	Mary has sex=female;
    	# question <Mary do ? done;>
    	Mary do walk from home to store done;
    	<myview:.=Mary> exit;
    	# exit <exit;>
    	##### exit #####
    	$

    III. Concept Formation
    #====================#

    15. 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

    A knowledge unit is a named proposition list.  It is stored
    internally in an entity-characteristic-proposition hierarchy.

    16. definitions
    #=============#
    A concept or unit (see section 19) definition has the format

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

    where
    	"iss" and "isu" 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 isp male, female;
    	hierarchy iss group with order="isa", genus=single;
    	lattice   iss group with order="isa", genus=multiple;

    17. 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

    18. 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:

    	set echo = off;
    	every cname isa concept {
    	    every attrname in attribute1, ... {
    		do measure_$attrname od $cname done;
    			# result stored in $Command
    		$cname has $attrname=$Command;
    	    };
    	};
    	set 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

    19. 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,...  isu primitive;
    	primitive isp 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,... iss genus;
    	genus       isg species,...;

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

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

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

    	begin unithierarchy myprim;
    	genus;
    	/  unit1;
    	/  unit2;
    	...
    	end unithierarchy myprim;

    Multi-level verbs are useful in questions:

    	cname isc* ?;	# all species & units
    	cname isg* ?;	# species only
    	cname isp* ?;	# units   only

    20. 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 or  unit2 or ...;
    	ingroup isall unit1 and unit2 and ...;

    For example

    	dogz isany Dutchess or  Reno or  ...;
    	dogs isall Dutchess and Reno and ...;
    	dog  isc   Dutchess,    Reno,    ...;

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

    	dogz
    	    Dutchess
    	    Reno
    	    ...

    	dogs
    	    Dutchess
    	    Reno
    	    ...

    	dog
    	    Dutchess
    	    Reno
    	    ...

    By definition, the group, exgroup and ingroup
    which subsume the same units are related by

    	dogs is all dog;
    	dogz is any dog;
    	dogs isall  dogz;
    	dogz isany  dogs;

    The shorthand formats for groups

    	group isc unit1, unit2, ...;
    	unit1, unit2, ... isa group;

    have been used throughout this tutorial.
    Where the distinction between ingroup
    and exgroup is important, we will use
    the following shorthand formats

    	exgroup isany alternative1, alternative2, ...;
    	alternative1, alternative2, ... isalt exgroup;

    	ingroup isall member1, member2, ...;
    	member1, member2, ... ismem ingroup;

    Returning to concepts, we may now note 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", genus=single;
    	lattice     is  group   with order = "isa", genus=multiple;
    	filesystem  isa hierarchy;