[Top] [All Lists]

Re: [ontolog-forum] Requirements of computer language semantics

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Richard H. McCullough" <rhm@xxxxxxxxxxxxx>
Date: Fri, 20 Mar 2009 14:09:06 -0700
Message-id: <EA227A00BDBB40839FCF1637E433EBA5@rhm8200>

----- Original Message -----
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Friday, March 20, 2009 10:49 AM
Subject: Re: [ontolog-forum] Requirements of computer language semantics

> But what I don't see in that list are the reasoning methods
> that link the symbols in the lattices to the sentences in
> mKR, relate the sentences to one another in order to draw
> inferences and detect contradictions, or interpret the
> context specifications of space, time, and view.
> The kinds of reasoning required to relate sentences in
> different contexts to one another, derive implications,
> detect contradictions, answer detailed questions, etc.,
> are extremely complex.  The vagueness in your previous
> notes suggests that you don't do these operations.
> If you don't do that, then all the claims about contexts
> are irrelevant.  Those at-clauses are merely decorations
> attached to sentences.  Any meaning that some human might
> think about them has no effect on what the computer does.
> To return to my original question:  what kind of processing
> do you do with those contexts, how does it relate to the
> lattice of symbols, the inferences among sentences, etc.?
> John
In summary,
the current state of mKE "reasoning" is primitive,
but mKE is still a very useful "assistant".

I expect it will take some time to supply all the info. you are
looking for.  But I will make a start by describing some
of the things that the mKE program does internally with
mKR propositions.
1. mKE names and classifies and stores all propositions.
In addition, it organizes the knowledge in many different ways.
a. all instances and concepts are stored in a
double-linked lattice structure, so that mKE can answer
any kind of inheritance question by walking up & down the
lattice.  begin hierarchy h;  ...; end hierarchy h; groups are
translated into instance/species statements & stored in lattice.
b. all of the properties & values of a given subject are stored together
in associative arrays.  There is a subhierarchy of properties, but
values are not replicated in this subhierarchy because the time
penalty is too high.
c. begin relation r; ...; end relation r; groups are stored in the
lattice as tuple instances, and the "meaning" of each tuple
(specified by proposition list or a Unicon procedure) is added
to the knowledge base.  Meaning is context-dependent, and
can also be changed by a direct assignment
    r has meaning = { proplist };
so tuples can be reprocessed in the light of new knowledge
entered into mKE.  This feature can also be used to do
simple things like selecting a subrelation.
d. method definitions are saved in lattice, to be used in subsequent
invocations.  Methods can take advantage of the generators
and goal-directed evaluation of the Unicon language.
e. environment variables, current concept attributes, method
arguments, n-ary relation arguments  are held in a
namespace stack.  mKE can access terms from
a stack of nested contexts.
2. All of the above propositions & related structures constitute
the current "view", v.   This view can be modified by adding new
concepts to the lattice, deleting concepts, moving concepts.
Any time the input to mKE includes "at view=v", all of its
propositions & associated data structures become the current
3. pipelines like { at view = v1 ...} | { at view=v2 ...};
permit adding  & deleting propositions in the same way
that UNIX pipelines permit filtering files.
4. The behavior of sequences like
    at view=v1 .... at view=v2 ....
depend on the nature of v2.
If v2 has already been defined, it is simply restored to the
current view.  If v2 is a new view, it is "nested" in v1.
The initial propositions  & associated structures of v2
are a copy of those of v1.  Any sentence which does not
have a context (syntactically speaking) automatically
inherits its context from the previous proposition.
5. The iteration statement, e.g.,
    every p isu person; { .... $p ... };
can do most anything you want in the "closed world" context
of the current view.  I have defined, but not implemented,
"open world" iterators which are fairly standard in other languages.
For example
    for all p isu person; { ...
        for some relative ismem family; { ...
            for any school ismem schools attended; { proplist };
6. concept aliases, e.g. "x is y;" are handled by an outer layer
which maps to an internal concept name "z".  All aliases map
to the same data structure which stores all of the properties of
that concept (or instance).
7. mKR has a convenient set of conditionals, e.g.,
    if -then-else-fi  iff  implies
but conditionals are evaluated by a brute force search in the
in the "closed world" of the current view.
To achieve "open world" reasoning, you have to include
some appropriate "open world" assertions in the input
mKR propositions.
8. The values of space, time, view are treated as simple names.
Although the Natural Semantic Metalanguage concepts include
    before, after, above, below, beside, inside, etc.
I have not implemented the evaluation of these relations on
space, time, view.
9. The only "contradictions" currently detected are
"closed world" occurrences of
a. {X isu Y;} and {X iss Z;};    # instance and species
b. X isa Y,Z;                        # multiple genus 
c. {X is Y;} and {X is not Y;}; # aliases
As I'm sure you're all aware, many people do not consider
a. and b. to be contradictions.
Dick McCullough

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>